View Single Post
Old 01 February 2016, 12:18   #27
Registered User

Join Date: Jun 2015
Location: Germany
Posts: 411
What breaks old and badly written programs on fast hardware is the lack of a reliable blitter wait. A lot of code was written to start a blitjob, then do something and start the next blitjob assuming the blitter was already done with the preceding blitjob. Now if the CPU is very fast, the first blitjob won't be done when the next one is set up. This is already something you can notice when using an 060 or running code in UAE with the right settings.

This problem is one of synchronising two asynchronous processing units, the CPU on the one hand and the blitter on the other. As far as I understand SAGA will solve this puzzle by having all of the custom chips inside the FPGA. Firstly, this will make vampire RAM effectively superfast chipmem (some hundreds of MB per second vs. 7MB/s in AGA). Of course, only two (or eight?) MB of the vampire fastmem will appear as chipmem as many programs avoid this slow mem and there are limitations in the hardware registers.

Having the custom chips inside the FPGA will put the CPU caches behind both the actual CPU AND the custom chips making "chipmem" cachable as the CPU caches will change when the custom chips change any of their content. However, this would still cause a headache in many cases which is why there won't be a blitter in the old sense. Please let me explain before you get all upset...

Commodore added the blitter because the 68000 sucked at bitplane manipulation. The 68020 had the (slow) bitfield operations added because of this (it is said that Motorola added them due to a special request from Hewlett-Packard who used the 68k for their laser printers). However, using an 020 for a home computer in 1985 would have required a 32bit subsystem where 16bit already was a costly step ahead (AFAIK the Atari still had some 8 bit periphery for this same reason). So instead of using an 68020 they decided to build a blitter that could deal with the bitplane manipulation easily and at low cost. As we know, this blitter was superfast and amazing in 1985 but all but hot in 1995. The blitter was long outrun by fastblit CPU patches even when Commodore was still alive. From about 1990 on the blitter was mostly a legacy thing required for compatibility. My understanding now is that the blitter will be emulated by the CPU in SAGA without any possibility of the user noticing. This means that writing to the relevant blitter registers will simply trigger a CPU routine which will carry out the blitjob in very high speed (remember, superfast CPU with superfast pseudo-chipmem) and then just continue to do its normal CPU work. The "code" for this will not be visible to the Amiga system. From a program's perspective the blitjob will be done the moment it gets started. Thus, there won't be any need to wait for the blitter and the CPU just cannot finish faster than the blitter. Of course you wouldn't use the blitter to process FullHD images which are chunky anyway. The blitter will only be able to work on the few MB of pseudo-chipmem which can't hold any of the RTG screenmode data.

As the apollo core will have all 68k instructions (and not only a subset as all traditional 68k CPUs did), has transparent caches (note how benchmark programs believe the CPU to not have any caches at all) and resolves the blitter issue in a totally transparent way, compatibility with existing (badly written) software will be much better than that of any of the previous accelerators in existence.

Eventually the RTG screen will be overlaid on the custom chip screens and both will be available through the digital video output of the vampire. Transparency of the RTG screen can be set by some mask turning the RTG into some kind of a 3rd playfield.

Of course, all this is just a roadmap and nothing you would buy included with the vampire available for sale now.
grond is offline  
Page generated in 0.03896 seconds with 10 queries