@Ron Nicholson:
Why does the Copper run only odd cycles? Would have killed for full speed...
Did you ever consider giving the Copper a burst/block move ability like 68000 MOVEM instruction? Lots of empty top bits in the Copper "move" instruction that could have held a count value.
Was the "Copper danger" bit for Copper blits something that was controversial/a source of discussion in the design team since the Copper can't wait for two different events at once?
Did you ever discuss changing the Copper or perhaps cloning it to add a "Blipper" to basically be a list processor for blitter setup that could be queued up and run async of anything else? (As per what the AAA chipset wanted to add as "Copper interrupts".)
Did you consider adding an MFM decoding option for the floppy controller in hw? From my limited hw knowledge that should be not many gates.
Did you ever discuss a DMA fed interface for the serial port, or at least a deeper transfer buffer than 1 byte? Were you not shooting for higher serial speeds than 16 colours hires could allow?
Was the hw sprite design all you wanted it to be? Re-using and animating sprites means updating the pixel data with the Blitter: Wouldn't it have been more in the spirit to have the hw sprite dma data be a pure list with a pointer to the pixels instead of mixing meta-data and pixel-data? (Though it would cost two extra word accesses and so require two scanlines between each re-use.)
Did you look at ways to have the blitter generate the mask for a cookie-cut from just the bob data itself? So you could preserve more of the precious memory it eats (and perhaps cycles too)?
Were you thinking of interleaved bitplanes from the beginning or did you always imagine doing one blit for each bitplane?
Watching your Amiga30 presentation made me wonder a bit about your design goals for audio: You had "this and that" idea about how to make graphics work with only 32K ram, but audio would easily eat all that and more given half the chance. What were your visions for audio in very little ram? Did you ever look at alternative solutions like something like an added POKEY?
Did you ever look into adding functionality to "wrap"(split) the display horisontally? Games slike Defender would have liked that, and you could already use the copper to do it vertically by just setting new addresses. I would imagine one or two registers similar to DDFSTOP and two registers like the modulo registers would be all that was needed. It would also have been nice to have to keep memory use constant and static.
Can you talk a bit more about how the number of pins were a limit to your design? Was it an absolute limit, or did more pins just cost too much? Was it something you saw changing as your design progressed?
Did you ever look at your creation and think that it should have been 32-bit as that is really all that ever gets shuffled around when it comes to pointers?
Did you consider using the 68010 instead of the 68000? The 68020 shipped while you were working, did that change anything for you?
I'd like to hear about the choices for ram chips and their use. Were there ever discussions about shipping with fastram when it was no longer a console? Did you design the chips around what memory speed was available, or did you design the chips and say "we need memory at _this_ speed" and then assume that would become available? (Badly worded jargon coming up: ) (AFAIK) all ram accesses are of the type "initialize ram row/column and wait until stable, do access, release and wait until stable"; did you ever look into doing multiple accesses in success (like AGA did with 'double CAS')?
In recent times we have seen a number of pre-1000 prototypes and developer models pop up: Could you talk about how the design work went and what bugs you found and corrected between the different chip spins? Why did they change the chip numbers before production?
Big thanks to you and the rest of the team.
