I don't think that's what he meant. So instead I sat down and sketched out how far you could get by making every aspect of the system as dynamic as possible, and got a vision of a system that basically erases its existence from the end user's perspective.

If you push everything absolutely as hard as you can, you can end up in a world that looks like a slightly more powerful bob-based system than the full system you actually have.

Which feels like a letdown, but I also think it's inevitable.

@mcmartin So to clarify - I do not consider the built-in "autoincrement" sprite DMA reuse to be very useful. Because they have to be contiguous lists, as soon as sprites start moving, you end up copying a lot of data around very frame - either rearranging sprites in a single DMA channel, more moving sprite data from one DMA channel to another.

It gets even worse if you want 15-colour and/or wider sprites.

At that point, might as well just blit them :-)

@mcmartin The way you solve this is to have the Copper feed the sprite hardware. So each frame the CPU's setting up command lists, but the data stays where it is.

I think comparing the Amiga to the 8-bit Ataris is... sure. Same designers, after all. But its actual contemporaries were the Megadrive and SNES which had vastly better sprite tech. Without the Copper, it can't keep up.

@mcmartin So maybe that's the fundamental disagreement. You decided you'd try to push the thing to its limit without using the Copper.

I long ago decided the Copper is the heart of the machine, and of course I'd be using it! So I never really tried NOT to use it.

@TomF Going back to check, the restriction I set myself was "keep chip memory as static as possible during ordinary operation."

But just to make sure: do I understand you correctly that you'd be fabricating a fresh Copper list every frame, ending each one with a write to COP1LC to flip to the next frame's list? And that this list would include the necessary palette and SPRnPT writes to reset the sprite DMA state for each instance of each sprite?

@mcmartin Correct. Every frame, I would be constructing a whole new Copper list (to be executed on the following frame) that commanded the sprites, the blitter, the framebuffer scroll/distort, and the various colour palette changes on the appropriate scanlines.

So I take that as a fixed assumption. Once you start with that mind-set, you slot all the other pieces of the machine in around that assumption.

...

@TomF And that's the real disagreement, spawned, I think, by me coming to the system late. Once I consider that workflow, it *quenches* rather than kindles any passion for the platform. It puts me back in the place I reached swiftly with the other 16-bits: "oh, it's a modern system, but worse and more inconvenient."

Now, sometimes that's what I want - I plan to play with m68k coding idioms a bit next year and the A1200 will be ideal - but UAE ends up becoming DosBox in a way Mesen just doesn't.

@mcmartin Part of this is why I helped invent my own, called #Mega68k. It's the A500 as I would have liked it to have been built, with the lessons learned 20 years later. No bitplanes. Make the Copper the center of everything. Make it better. Make the Blitter simpler, but more flexible. Put some decent sprites in it. It's the spirit of Amiga without all the annoying stuff.

One day we'll ship it. One day.