Sure, the Amiga chipset could be modified for 8-bit systems but what good is Amiga hardware in a system that can only see 64K without bank switching? A 320x200x16 color screen is 32K just by itself. Once your graphics get big, you need a big address space.
Unfortunately, this problem certainly didn't stop the Jaguar. What good is it to me that it can address 2 MB, if the GPU is fricking four kilobytes ?
- And it doesn't support stack, so you gotta reserve some space for emulating stack.
- And every variable you use is 32-bit integer (otherwise you fall down to 68000 performance levels once you start extracting separate bytes from those 32 bits, or if you load from main slow RAM),
- thus you burn through those 4K almost instantly
- you fit much less code than on 6502, as you don't have 8-bit instructions like INX/INY/CLC, they're 16-48 bits (2 - 6 Bytes)
- don't get me started on how the GPU performance gets butchered once you start splitting&blitting code chunks to the cache using the infamous 64-bit blitter mode...
If I had it my way, I'd rather limit jaguar to 64 KB bank-switching (like on 6502) from those 2 MB, but have those 64 KB for GPU cache. This alone would incredibly upgrade the performance capabilities. If Atari 800 is able to switch banks within 1-2 cycles, I for sure wouldn't mind those cycles if ObjectProcessor would switch to a different bank for each bitmap it processes and displays.
Besides, the memory controller in Jaguar burns few cycles anyway upon crossing the 64-KB boundary, so again - what good is it then again (other than for hibernated-turtle-slow 68000 code)? It only appears as a linear 2 MB system (and only for the arguably hypothetical corner case of 68k coding), but at a significant performance cost the moment you start crossing the 64 KB boundaries with your data (which can be very easily tested).
I would love to have a crowdfunding campaign to design an 8-bit system from the ground up. Design the NMOS chips and everything using ONLY technology from around 1980 (if there's not enough money for chips, then workalike FPGA DIP's could be used in the board). It would be fun to deliver boxed computers from an alternate history, but based on the architecture ideas we'd most like to see in a single machine.
Eclaire XL is attempting something similar, though obviously not to the degree that you want (via FPGA). But I hear ya and agree.
I don't believe we'd be able to find a hundred people, though...
A 320x200x16 color screen is 32K just by itself. Once your graphics get big, you need a big address space.
No, you don't. Now, it may be more convenient from coding perspective, but you don't really need it.
I'm going to see soon myself, as I'll be working with Eclaire's 4x Antic modes (e.g. 320x192x16), but basically the rasterizer needs to be able to work in zones and access one zone at a time. There's some overhead, of course, but same technique has been used at original XBOX where they had to split rendering in certain gfx modes into zones.
Besides, one bank is 16 KB, so we're talking only 2 banks here anyway, so the overhead will be minimal and highly likely masked by fake clipping (e.g. it costs the same amount of cycles whether I clip against scanline 96 or 192 - does the rasterizer really care if that scanline is the last one in bank one or two ? I could ask, but suspect I know the answer to that already ), thus very likely - free.