View Single Post
Old 01 February 2016, 19:27   #29
Registered User
Join Date: Jun 2010
Location: PL
Posts: 1,653
Originally Posted by grond View Post
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...
No sense to be upset - if you have dedicated HW and access to it as CPU instruction then fine for me - this approach was started in Intel 860 and later evolved to MMX and further extension.

Originally Posted by grond View Post
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).
Nope - easily this can be made as in Falcon - just use DSACK - at a cost of performance.

Originally Posted by grond View Post
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.
I believe that Xerox Alto was inspiration for everyone...
HP use some specialized ASIC to perform fast raster operation as laserprinter works under real time constrains.

Originally Posted by grond View Post
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.
All this sound like Xerox Alto where blitter was microcode based (implemented on CPU made from ordinary TTL 74181).
pandy71 is offline  
Page generated in 0.04092 seconds with 10 queries