@agami

Quote:

agami wrote: I already have the V2 600, V2 1200, and the V4 Standalone.

I know the Vamipre V2 and V4 are the fastest Amiga accelerators ever produced.

Putting a RTG compatible GFX card into this accelerators make them even more usable.

Would you please give us an honest overview about some issues with the Vampires:

1.
What games / demos don't work with the Vampire V2 or V4?
If they don't work is there a workaround?

2.
How good is the frambuffer RTG part of the V2 or V4?
Does it slow down the CPU speed when used?
Are there knows bugs in the driver software?

3.
How good is ECS/AGA emulation on the V4 stand alone?
Is it better than Minimig or still unfinished as the Natami?
Is there a known bug that could be traced back to known problems?

---

I'm asking you because I don't trust official announcements of the Apollo team, I would prefer a honest list of problems and non working software over an untrue 'every thing is perfect' lie.' I'm interested in a Vampire V4 stand alone, but won't buy it until I can trust the software.

@matthey

Quote:

matthey wrote: Sorry you didn't get it. It was a joke. Certain users here have been trolling me about how SAGA doesn't exist and how Gunnar could never have obtained permission to use SAGA from Thomas.

SAGA is just a name, if Gunnar would have used a Minimiig AGA implementation together with a simple framebuffer implementation, he could call it SAGA. After all this could have been a better choice than everything that was available on the Natami.

Last edited by OneTimer1 on 11-Jul-2021 at 03:01 PM.

Quote:

kolla wrote: The title is misleading, it should really be "The Vampire creator leaves the Apollo Team"

There where always two products and teams: Vampire and Apollo


The first Vampire was even started without an core of the Apollo team, but the 68k implementation of the Apollo Team worked better.

I don't know why Igor left, but if he wants to continue with lower priced accelerator boards for Amigas he should do it.

The production of Vampire hardware always lacked behind the demand, hopefully this will change now.

@OneTimer1

Quote:

How good is the framebuffer RTG part of the V2 or V4? Does it slow down the CPU speed when used?

there big difference in Chunk 8bit and Chunk 32bit, 8bit is only ¼ of the data, the more data you need to move, the faster the CPU needs to be.

Chunk (vga/svga) its simple 1 byte = 1 pixel, or 1 integer = 1 pixel, this makes it also fast, no need to convert anything, just write pixel data into the screen data, it’s that simple.

Planar (OCS/ECS/AGA) is complex, 1 pixel is stored in many bytes, you also need lots of shifting, masking (and’ing), and logical operations, or lots of bset, bclr, this is pretty slow. The blitter helps with this, and hardware fill, and line drawing features of the chipset, this tryr to make up for the slowness.

there is one major advantage to planar and that is collision detection, this is where shifting and masking is a wherry nice way to implement pixel exact implementation. Lots of Chunky Games use box collision instead, this is lot less exact. (You can check 16/32 pixels in one and operation, if they are bits.), (mask bitmaps are only on/off, (have pixels, do not have pixels), they store no color values.)

so what I’m saying that you save cpu cycles, when have less complex design, anyhow no game will use chunky unless rewritten to use it, almost no demos will use chunky unless they are updated.

Last edited by NutsAboutAmiga on 11-Jul-2021 at 03:28 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @OneTimer1 Quote: How good is the framebuffer RTG part of the V2 or V4? Does it slow down the CPU speed when used? there big difference in Chunk 8bit and Chunk 32bit, 8bit is only ¼ of the data, the more data you need to move, the faster the CPU needs to be.

OK, this would affect the speed of the GFX functions more pixels and more colour means more data and this is OK, because it will only slow down the system when you are shifting pixels around.

There is another effect, the GFX data going to the monitor must be read out of the RAM, on the Amiga the CPU will lose RAM access cycles when you are using 6 bit planes, I don't believe there is an unlimited memory band width on Vampire systems, that's the reason why I was asking.

Last edited by OneTimer1 on 11-Jul-2021 at 08:17 PM.

OneTimer1 Quote:

I know the Vamipire V2 and V4 are the fastest Amiga accelerators ever produced. Putting a RTG compatible GFX card into this accelerators make them even more usable. Would you please give us an honest overview about some issues with the Vampires: 1. What games / demos don't work with the Vampire V2 or V4? If they don't work is there a workaround?

The Vampire is *not* as compatible as some other FPGA Amigas. There are several reasons for this.

1. The 68080 is more complex and higher performance than existing 68k CPUs. While the 68080 implements several features to improve 68k compatibility, the complexity can mean more bugs and extra performance can cause problems. The same is true of the 68040 and especially 68060 when they were used in Amigas. Many Amiga games have patches for faster 68k CPUs which should improve compatibility on the 68080 also.

2. SAGA has more enhancements than most other Amiga chipset FPGA re-implementations. The CPU core development has had priority over SAGA development as well. SAGA may have more bugs than other chipsets more focused on compatibility but it should be possible to fix them eventually.

3. The Vampire comes with AROS which is not as compatible as the AmigaOS.

It's not always possible to know where glitches come from. The following Vampire SA review talks about compatibility and shows some of the glitches.

The Vampire v4 - A new Amiga
https://www.youtube.com/watch?v=YRr74v2tPzM

OneTimer1 Quote:

2. How good is the framebuffer RTG part of the V2 or V4? Does it slow down the CPU speed when used? Are there knows bugs in the driver software?

The RTG chunky framebuffer uses modern memory which is much higher performance than chip memory in classic Amigas. Removing the chip memory bottleneck and increasing memory bandwidth increases performance. Everything is faster including AGA planar modes. The memory bandwidth is limited at high resolutions, with faster refresh rates and with 32 bit chunky colors but I'm not sure if the chipset would start stealing cycles from the CPU.

OneTimer1 Quote:

3. How good is ECS/AGA emulation on the V4 stand alone? Is it better than Minimig or still unfinished as the Natami? Is there a known bug that could be traced back to known problems? --- I'm asking you because I don't trust official announcements of the Apollo team, I would prefer a honest list of problems and non working software over an untrue 'every thing is perfect' lie.' I'm interested in a Vampire V4 stand alone, but won't buy it until I can trust the software.

The V4 standalone should have the best SAGA compatibility but it may be disappointing if you expect to use any old Amiga game. Vampire accelerators allow to run games on the motherboard CPU and chipset which can be better compatibility. Minimig AGA with TG68 68020 has better Amiga 1200 compatibility than the 68080 with SAGA ever will.

I don't trust Gunnar anymore either and I was on the Apollo team. I have caught him in lies and deceptions. I don't think he is a bad person just another black knight who thinks the end justifies the means. If he had more business sense, he would realize how important integrity and reputation is to a business.

OneTimer1 Quote:

SAGA is just a name, if Gunnar would have used a Minimiig AGA implementation together with a simple framebuffer implementation, he could call it SAGA. After all this could have been a better choice than everything that was available on the Natami.

Sure, but why call another chipset implementation SAGA when SAGA already exists?

OneTimer1 Quote:

There where always two products and teams: Vampire and Apollo The first Vampire was even started without an core of the Apollo team, but the 68k implementation of the Apollo Team worked better.

I don't know if you would call one person a team but if you like to then Majsta was the Vampire team. I'm not aware of him ever called himself that though. The Apollo core was all about improving performance over the TG68 and much of this came from adding caches. More performance improved the performance/price which improved the value of the accelerator. Majsta was amazed at the interest in the Vampire with the TG68 and was overwhelmed with the Apollo core upgrade. That is when Kipper got involved to help with production but this was already as the Apollo team.

OneTimer1 Quote:

I don't know why Igor left, but if he wants to continue with lower priced accelerator boards for Amigas he should do it. The production of Vampire hardware always lacked behind the demand, hopefully this will change now.

I doubt Majsta plans to go back to producing low priced Vampire boards. I expect he was just burnt out and needs a break. This isn't the first time the stress from being overwhelmed has affected his health. He can be hard headed though. Switching to a more expensive Cyclone V earlier like I suggested would have tempered demand reducing the waiting list which has been over a year for some customers. The Apollo core would have been easier to develop in a more expensive FPGA with more resources. I wanted cheaper prices like Majsta but the way to achieve it is to develop in a more expensive FPGA and then make an ASIC and use mass production. Jeff Porter commented about developing the Amiga 500 where dropping the price by half could double demand. An ASIC would not just drop the price but also greatly increase performance. Increasing the performance with an ASIC may double the demand too which may be quadruple the total demand. I like how Dale Luck was talking about interviewing with Amiga and seeing how they were using large scale integration to make the advanced Amiga hardware 1/10 the price of what he was using at HP. Many Amiga developers joined the Amiga team because they wanted to be part of the excitement and passion which the Amiga hardware performance/price would bring. Could Amiga hardware in an ASIC have 10 times the performance at 1/10 the production cost of a FPGA? Could an ASIC be developed for 1/10 the cost of developing the original Amiga and bringing it to market?

Last edited by matthey on 11-Jul-2021 at 11:28 PM.

@NutsAboutAmiga

Quote:

there big difference in Chunk 8bit and Chunk 32bit, 8bit is only ¼ of the data, the more data you need to move, the faster the CPU needs to be . Chunk (vga/svga) its simple 1 byte = 1 pixel, or 1 integer = 1 pixel, this makes it also fast, no need to convert anything, just write pixel data into the screen data, it’s that simple.

It depends on how smart is the GPU.

In modern PC GPUs, OS, and drivers, the CPU sends instructions to the GPU then the GPU fetches content data from system memory. CPU feeding content data to the GPU is relatively slow when compared to GPU's scatter and gather units (e.g. DMA move engines, texture, and ROPS units).

CPUs with AVX-512 have scatter and gather instructions.
CPUs with AVX v2 have gather instructions.
CPU's scatter and gather instructions wouldn't match GPU's scatter and gather performance.

DirectX12U's DirectStorage enables the GPU to directly fetch data (and decompress data) from SSD into video memory, hence bypassing the system memory and CPU. CPU is used as a fallback decompression device when the GPU doesn't have Xbox Velocity Architecture's hardware decompression.

NVIDIA Ampere has RTX IO that supports DirectStorage's GPU side hardware decompression as per Xbox Velocity Architecture's requirements.

Sony's PS5 has its equivalent DirectStorage features.

A1200's IDE is pretty dumb since it's PIO, not DMA. PC SATA and NVME are DMA devices.

With exception of Commodore's PIO mode IDE, Amiga OCS/ECS/AGA are largely driven by DMA.

Last edited by Hammer on 12-Jul-2021 at 07:58 AM.
Last edited by Hammer on 12-Jul-2021 at 03:32 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey
Quote:

The Vampire is *not* as compatible as some other FPGA Amigas. There are several reasons for this. 1. The 68080 is more complex and higher performance than existing 68k CPUs. While the 68080 implements several features to improve 68k compatibility, the complexity can mean more bugs and extra performance can cause problems. The same is true of the 68040 and especially 68060 when they were used in Amigas. Many Amiga games have patches for faster 68k CPUs which should improve compatibility on the 68080 also. 2. SAGA has more enhancements than most other Amiga chipset FPGA re-implementations. The CPU core development has had priority over SAGA development as well. SAGA may have more bugs than other chipsets more focused on compatibility but it should be possible to fix them eventually. 3. The Vampire comes with AROS which is not as compatible as the AmigaOS. It's not always possible to know where glitches come from. The following Vampire SA review talks about compatibility and shows some of the glitches.

A modern system like PS5 and PS4 Pro has backward PS4 compatibility mode.

The main reason for PS5's and PS4 Pro's 36 CU GPU selection is the ability to disable half of the GPU for PS4 GPU's 18 CU mode. PS4 compatibility mode also includes down clocking mode.

The same instruction set across GPU generation doesn't guarantee 100% backward compatibility.

MS Direct3D has resource tracking which enables performance scaling across different hardware. MS Direct3D was designed to scale from laptops and desktop PCs, hence Xbox's Direct3D benefited from it.

Xbox Direct3D can scale from 12 CU (retail Xbox One), 40 CU (retail Xbox One X), 44 CU (Xbox One X dev kits), 52 CU (retail Xbox Series X) and 56 CU (Xbox Series X dev kit) that doesn't need PS4 Pro/PS5 backward compatibility method.

Hit-the-metal programming can introduce specific hardware dependency (i.e. the boat anchor effect) and can limit hardware evolution e.g. PS5 vs XSX.

Like PS4 backward compatibility mode, early PC clones include a downclocking "turbo" button for legacy DOS programs.

Last edited by Hammer on 12-Jul-2021 at 07:52 AM.
Last edited by Hammer on 12-Jul-2021 at 07:45 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Hammer Quote:

DirectX12U's DirectStorage enables the GPU to directly fetch data (and decompress data) from SSD into video memory, hence bypassing the system memory and CPU. CPU is used as a fallback decompression device when the GPU doesn't have Xbox Velocity Architecture's hardware decompression. NVIDIA Ampere has RTX IO that supports DirectStorage's GPU side hardware decompression as per Xbox Velocity Architecture's requirements. Sony's PS5 has its equivalent DirectStorage features.

The PS4+ and new XBox hardware are Heterogeneous System Architectures (HSA) so there is no need to load textures into video memory as all memory is the same. The DMA storage controller could perform decompression but textures are usually compressed in storage and remain compressed in memory. CPU code is best compressed with a good variable length encoding like the 68k uses which remains compressed on disk, in memory and in the caches. That only leaves miscellaneous data to be decompressed which I believe is more popular to do in the files system where supported.

Hammer Quote:

A1200's IDE is pretty dumb since it's PIO, not DMA. PC SATA and NVME are DMA devices. With exception of Commodore's PIO mode IDE, Amiga OCS/ECS/AGA are largely driven by DMA.

Many Amiga SCSI cards did not support DMA because of Buster bugs even though it is possible. Sadly, there was never a bug fixed Buster released which allowed performance close to the theoretical maximum of Zorro III because of development budget cuts at CBM which hindered later SCSI devices with increased transfer speeds. The best accelerators had on board memory and DMA drive storage like the P5 CyberStorm MkIII which seems fast with PFS even by today's standards. It is sad that the Amiga custom chips use exotic and efficient DMA but CBM usually sabotaged the advantage with the cheapest possible memory and hardware elsewhere.

Hammer Quote:

A modern system like PS5 and PS4 Pro has backward PS4 compatibility mode. The main reason for PS5's and PS4 Pro's 36 CU GPU selection is the ability to disable half of the GPU for PS4 GPU's 18 CU mode. PS4 compatibility mode also includes down clocking mode. The same instruction set across GPU generation doesn't guarantee 100% backward compatibility.

It's nice that the console manufacturers are thinking about compatibility now. Most of the performance gains are coming from more parallel GPUs with diminishing gains. It's going to become expensive to upgrade consoles enough to make a noticeable difference in performance and graphics. Higher prices and customers not upgrading could eventually lead to a console market crash. I'm aware hardware supply shortages and more people at home because of COVID have currently led to what looks like increased demand for the P5.

Hammer Quote:

MS Direct3D has resource tracking which enables performance scaling across different hardware. MS Direct3D was designed to scale from laptops and desktop PCs, hence Xbox's Direct3D benefited from it. Xbox Direct3D can scale from 12 CU (retail Xbox One), 40 CU (retail Xbox One X), 44 CU (Xbox One X dev kits), 52 CU (retail Xbox Series X) and 56 CU (Xbox Series X dev kit) that doesn't need PS4 Pro/PS5 backward compatibility method. Hit-the-metal programming can introduce specific hardware dependency (i.e. the boat anchor effect) and can limit hardware evolution e.g. PS5 vs XSX. Like PS4 backward compatibility mode, early PC clones include a downclocking "turbo" button for legacy DOS programs.

The downgrade ability of hardware is nothing new. The 68060 allowed to turn off half the caches which gives the same cache sizes as the 68040. The 68060 and 68040V are fully static designs which support lowering the core clock to zero. Most Amiga accelerators had no support for reducing the clock even though this would have been useful for compatibility as well as power management. Newer chips often have temp sensors and can dynamically change core clocks as necessary.

Last edited by matthey on 13-Jul-2021 at 04:51 PM.

@Hammer

Quote:

A modern system like PS5 and PS4 Pro has backward PS4 compatibility mode.

How are we all enjoying that PS2 compatibility in our PS3s today?

_________________
All glory to the Hypnotoad!

@billt

I’m really enjoying mixing my PS2 Singstar disc tunes with the PSN downloaded songs on my PS3. It’s a great party game for Christmas and birthdays! US-centric Sony seems to have thrown Sony London under the bus and expect creatives to become games programmers, artists and composers on Dreams rather than casual rhythm gamers like DDR/Dancing Stage, Rock Band and SingStar of the past! Short sighted!

Last edited by BigD on 13-Jul-2021 at 08:55 AM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@OneTimer1

Quote:

Would you please give us an honest overview about some issues with the Vampires: 1. What games / demos don't work with the Vampire V2 or V4? If they don't work is there a workaround? 2. How good is the frambuffer RTG part of the V2 or V4? Does it slow down the CPU speed when used? Are there knows bugs in the driver software? 3. How good is ECS/AGA emulation on the V4 stand alone? Is it better than Minimig or still unfinished as the Natami? Is there a known bug that could be traced back to known problems?

That level of analysis is going to require a lot more time than I have. Certainly something I'd enjoy doing, and maybe one day I will.

Last edited by agami on 14-Jul-2021 at 04:19 AM.

_________________
All the way, with 68k

@matthey

Quote:

The PS4+ and new XBox hardware are Heterogeneous System Architectures (HSA) so there is no need to load textures into video memory as all memory is the same. The DMA storage controller could perform decompression but textures are usually compressed in storage and remain compressed in memory. CPU code is best compressed with a good variable length encoding like the 68k uses which remains compressed on disk, in memory and in the caches. That only leaves miscellaneous data to be decompressed which I believe is more popular to do in the files system where supported.

If the PS4 game didn't track its resources in a friendly manner (i.e. programmer assumes resource will be available at a certain clock cycle based on static hardware performance profile), any future hardware evolution will have a different CPU: GPU resource timing relationship that breaks compatibility for timing sensitive game that assumed static hardware performance profile.

AMD's "Heterogeneous System Architectures (HSA)" Fusion CPU and GPU coupling are NOT tight when compared to AVX SIMD units with the main scalar CPU e.g. CPU FP register to CPU GPR transfer has very low latency. AVX has its purpose.

AMD is nearly silent with HSA PR since Ryzen's release.

PS5/PS4 Pro's PS4 mode backward compatibility method exists for a purpose.

-----
Memory usage comparison from EA DICE lecture from https://www.slideshare.net/DICEStudio/framegraph-extensible-rendering-architecture-in-frostbite



DirectX11, 147 MB.



DirectX12, 80 MB.



PS4, 77 MB.


Xbox One, 76 MB.

Notice PC DirectX12 is closer to the consoles.

Quote:

Many Amiga SCSI cards did not support DMA because of Buster bugs even though it is possible. Sadly, there was never a bug fixed Buster released which allowed performance close to the theoretical maximum of Zorro III because of development budget cuts at CBM which hindered later SCSI devices with increased transfer speeds. The best accelerators had on board memory and DMA drive storage like the P5 CyberStorm MkIII which seems fast with PFS even by today's standards. It is sad that the Amiga custom chips use exotic and efficient DMA but CBM usually sabotaged the advantage with the cheapest possible memory and hardware elsewhere.

My A3000 was with shipped KS 2.04 ROM revision (at least motherboard 7.2 revision or higher) instead of the earlier A3000 revision with KS 1.4 with an older Zorro III support chips revision. A3000's ZIP memory upgrades were done by a local PC vendor at the time since I haven't completely dismantled my A3000.

My local PC vendor has stated A3000's construction is overkill and expensive.

Reaching close to the theoretical maximum is based on several factors.

I plan to move the Shapeshifters hard drive image to TF1260's IDE port when a longer laptop IDE cable arrives. A1200's IDE port is slower than my A3000's SCSI port.

For A1200's timing issues with TF1260, I have desoldered the extra caps from A1200 rev 1.D1.

Quote:

It's nice that the console manufacturers are thinking about compatibility now. Most of the performance gains are coming from more parallel GPUs with diminishing gains. It's going to become expensive to upgrade consoles enough to make a noticeable difference in performance and graphics. Higher prices and customers not upgrading could eventually lead to a console market crash. I'm aware hardware supply shortages and more people at home because of COVID have currently led to what looks like increased demand for the P5.

Raytracing is the future and it has a high appetite for compute power.

Sony is already working with AMD for 6nm UV process node PlayStation.
https://www.tomshardware.com/news/sony-reportedly-prepping-ps5-with-6nm-amd-cpu
PS5's evolution is not stopping.

Killer game titles sell hardware e.g. Crysis helps drive PC GeForce 8 sales. Sony has strong 1st party studios to drive PS5 hardware sales.

Last edited by Hammer on 14-Jul-2021 at 05:41 AM.
Last edited by Hammer on 14-Jul-2021 at 05:40 AM.
Last edited by Hammer on 14-Jul-2021 at 05:39 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@billt

Quote:

billt wrote: @Hammer Quote: A modern system like PS5 and PS4 Pro has backward PS4 compatibility mode. How are we all enjoying that PS2 compatibility in our PS3s today?

Fat PS3 includes PS2 hardware which is a dead weight for PS3 games.

PS4 has software PS2 emulation for Sony's Online store's resell PS2 games.

Last edited by Hammer on 14-Jul-2021 at 05:45 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

Sure, but why call another chipset implementation SAGA when SAGA already exists?

Sure, but why call the project Apollo when Apollo accellerators and 68k Apollo computers already exists?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Hammer Quote:

If the PS4 game didn't track its resources in a friendly manner (i.e. programmer assumes resource will be available at a certain clock cycle based on static hardware performance profile), any future hardware evolution will have a different CPU: GPU resource timing relationship that breaks compatibility for timing sensitive game that assumed static hardware performance profile. AMD's "Heterogeneous System Architectures (HSA)" Fusion CPU and GPU coupling are NOT tight when compared to AVX SIMD units with the main scalar CPU e.g. CPU FP register to CPU GPR transfer has very low latency. AVX has its purpose. AMD is nearly silent with HSA PR since Ryzen's release. PS5/PS4 Pro's PS4 mode backward compatibility method exists for a purpose. ----- Memory usage comparison from EA DICE lecture from https://www.slideshare.net/DICEStudio/framegraph-extensible-rendering-architecture-in-frostbite

Yes, any slow down could cause 3D glitches even if from different resource handling. Newer hardware is less likely to have the problem as there are usually more resources and bandwidth. Getting rid of the CPU to GPU bottleneck with HSA helps too as pointers to textures and scenes can be quickly passed to the GPU with a function call (kind of like the AmigaOS quick message pointer passing vs UNIX style slow memory copy messages but on a much larger scale). Notice that most of the resource management including improved modularity is happening in CPU core code even though the resources are often used by the GPU. The CPU cores are doing more work than earlier hardware which is why single thread performance and SIMD unit performance are important which are strengths of x86-64 processors.

Hammer Quote:

My A3000 was with shipped KS 2.04 ROM revision (at least motherboard 7.2 revision or higher) instead of the earlier A3000 revision with KS 1.4 with an older Zorro III support chips revision. A3000's ZIP memory upgrades were done by a local PC vendor at the time since I haven't completely dismantled my A3000. My local PC vendor has stated A3000's construction is overkill and expensive. Reaching close to the theoretical maximum is based on several factors.

The Amiga 3000 used DMA which reduced CPU load but it was still limited to 5MiB/s transfers (theoretical) because it didn't support fast or wide SCSI. Sadly, for an Amiga this was considered good.

Hammer Quote:

I plan to move the Shapeshifters hard drive image to TF1260's IDE port when a longer laptop IDE cable arrives. A1200's IDE port is slower than my A3000's SCSI port. For A1200's timing issues with TF1260, I have desoldered the extra caps from A1200 rev 1.D1.

The Amiga 1200 slow PIO IDE is about as cheap as it gets. Sadly, the Amiga 4000 had the same hardware and no SCSI. The only saving grace of cheap IDE on the Amiga is that programs are small but this discouraged streaming multimedia use which was supposed to be one of the strengths of the Amiga. The biggest Amiga4000 use was only a Toaster after all.

Hammer Quote:

Raytracing is the future and it has a high appetite for compute power.

Some raytracing is the future but it may be better to use sparingly to reduce power. A smaller chip fab process gives more transistors for parallel processing but power reductions are diminishing due to current leakage.

HammerQuote:

Fat PS3 includes PS2 hardware which is a dead weight for PS3 games.

Only the very earliest PS3s had the PS2 EE hardware.

kolla Quote:

Sure, but why call the project Apollo when Apollo accellerators and 68k Apollo computers already exists?

Gunnar was already using the "Apollo" name when I was asked to join the team. Some of the Apollo team members suggested changing the name to something less used. Gunnar also called his core the Phoenix core sometimes which is so much better and more original. Is he a marketing genius or what?

Amiga 600 + Vampire 600 running Phoenix core
https://www.youtube.com/watch?v=v1yMMhFtU68

Last edited by matthey on 14-Jul-2021 at 10:45 PM.

@matthey

Quote:

Yes, any slow down could cause 3D glitches even if from different resource handling. Newer hardware is less likely to have the problem as there are usually more resources and bandwidth. Getting rid of the CPU to GPU bottleneck with HSA helps too as pointers to textures and scenes can be quickly passed to the GPU with a function call (kind of like the AmigaOS quick message pointer passing vs UNIX style slow memory copy messages but on a much larger scale). Notice that most of the resource management including improved modularity is happening in CPU core code even though the resources are often used by the GPU. The CPU cores are doing more work than earlier hardware which is why single thread performance and SIMD unit performance are important which are strengths of x86-64 processors.

The shared memory model has disadvantages



Without a significant size cache on the GPU side, the context switching between CPU and GPU can degrade the overall memory bandwidth and GPU's burst mode memory operation.

Unlike the older GCN GPU like Polaris GCN, the VEGA GCN and RDNA v1/v2GPU's ROPS are connected to the L2 cache. NVIDIA's Maxwell ROPS has an L2 cache link. Refer to immediate render mode tiled cache rendering.

Xbox One X GPU's ROPS has 2 MB render cache semi-custom modification in addition to baseline Polaris IP's 2MB L2 cache.

Baseline GCN and Polaris ROPS are directly connected to memory controllers.
Baseline GCN TMUs are connected to L2 cache, hence AMD's PR push for Async Compute and TMU(read-write) path.

PC RDNA 2 GPU has a multi-MB Infinity Cache (L3 cache).



For PS4's Kill Zone Shadow Fall, HSA CPU+GPU workload is relatively small when compared to discrete CPU and GPU workloads.

With PCI ResizeBar, the PC CPU can access the entire GPU's VRAM like HSA without a 256 MB window translation layer, but fusion CPU-GPU workloads are relatively small.

My point, there are workloads that benefited from the discrete memory model and there are workloads that benefited from the shared memory model.

For PS5 CPU, Sony has asked AMD to reduce AVX resources. AMD 4700S APU which is PS5 APU for the PC market shows slower Cinebench R20 AVX scores when compared to Ryzen 7 4750G Pro's CPU.

Quote:

The Amiga 1200 slow PIO IDE is about as cheap as it gets. Sadly, the Amiga 4000 had the same hardware and no SCSI. The only saving grace of cheap IDE on the Amiga is that programs are small but this discouraged streaming multimedia use which was supposed to be one of the strengths of the Amiga. The biggest Amiga4000 use was only a Toaster after all.

A1200's IDE port is good enough for the full-motion video Time Gal anime Laserdisc port.

Quote:

Only the very earliest PS3s had the PS2 EE hardware.

Note why I stated the "fat" PS3.


Quote:

Some raytracing is the future but it may be better to use sparingly to reduce power. A smaller chip fab process gives more transistors for parallel processing but power reductions are diminishing due to current leakage.

For raytracing, NAVI 31 is about 2x faster when compared to NAVI 21 XTX. GeForce RTX 3080 Ti shows the improvement path for raytracing when compared to RX 6900 XT(NAVI 21 XTX).

Relentless PC GPU evolution continues.

For the Amiga retro market, certain design principles need to be considered e.g. CPU should have its dedicated memory pool e.g. Amiga's fast ram for the CPU which minimizes memory sharing issues with the graphics processors.

Last edited by Hammer on 09-Jun-2023 at 04:34 PM.
Last edited by Hammer on 16-Jul-2021 at 04:42 AM.
Last edited by Hammer on 15-Jul-2021 at 05:18 AM.
Last edited by Hammer on 15-Jul-2021 at 05:03 AM.
Last edited by Hammer on 15-Jul-2021 at 04:59 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

So it shouldn’t be so surprising that he reuse the term SAGA (Super AGA) for his own chipset implementation. The questions now are…which SAGA from here on? Open source (as “promised”) or not? And how long before Thomas Hirsch is out again?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Quote:

kolla wrote: @Hammer What's with the off-topic pointless rambling? Indeed, if you want to experience the best possible Internet experience on 68k Amiga, you get that by using either NetBSD or Linux/m68k. If you go for Linux, I suggest starting with Debian, and then a chroot environment with a meta distro (for example Gentoo/Portage), so you can build yourself up to bleeding edge. I recommend it.

My point was the "out of the box" experience.

Using CaffeineOS's Miami TCP/IP stack, I was able to use NL-2511CF Mercury WiFi and NetSurf 3.9, AmiFox, and VNC client, but encountered a few reset PCMCIA issues. I purchased a Gayle adapter that fix the PCMCIA reset bug.

Last edited by Hammer on 09-Jun-2023 at 04:35 PM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)