A little late in the reply gamy, but hey, it piqued my interest as memory modules are dirt-cheap these days.
@matthey:
Very interesting thoughts/points!
@mboehmer_e3b:
Interesting counter-points! I realize you're an expert in hardware design, but I have a couple of comments and a couple of questions to bounce off of you, so I can understand better the real issues behind Matth's proposal.
Can you change the Buster time-out values programmatically, or only via hardware hacks?
I'm no PCI/AGP guru, but the conditions you describe for writes being blocked for a pending read, or the opposite, it's clearly a deadlock situation which no bridge or circuitry would allow. It's theoretically possible that no extra read will ever take place, thus those writes are stalled forever. Now, if there's a time-out, after which the writes take place, then everything would continue, but the whole process is delayed, which is what you meant when you said Buster will timeout waiting for that. I guess it could be alleviated by 'dummy reads' or 'dummy writes' interspersed by the software driver.
BTW, isn't it possible to disable delayed transactions? I thought that's what is available for certain PCI configurations which need ISA style timings.
As for read speeds, that has been my experience from the older days programming VGA cards, but I'm not sure if that is still the case for modern cards. For one thing, bit-blitting does reads, so internally the bandwidth for reading IS there, it was the interface bandwidth that was problematic (either smaller bus, like PCI/VLB being 32bit, or ISA being 16bit or 8bit, or smaller and slower bus, all compared to the internal busses which are 256bit or even larger in some cases, and much faster).
As for card setup, you're right, it could be an issue, but my understanding is to get the memory mapped properly you don't need to touch the GPU (and if you do, there's open source code in Linux/BSD for even the most modern cards, since it doesn't touch the propriatery 3D registers), but it's all PCI/AGP register setup. All the necessary code should be in the agpgart.c and related code (PCI, mttr.c, etc).
Lastly for byte-ordering can be an issue too, but as matthey says, this would be a "dumb card", not to be used for display.
@alexh:
I think the only viable way to get hardware to happen is have people pre-pay. Unfortunately that's hard because there aren't many trust-worthy Amiga hardware developers (thinking Ainc, ACT, etc here). I personally want a PPC card or even a CT-60 modified to work on a classic Amiga, and would pre-pay, but I only trust AmigaKit's Matthew for this, because if the project bombs, I feel he'll return me the cash, unlike those others mentioned...
@Kronos:
Interesting alternative. As solid state drives become the norm and get faster, a paged store/virtual memory subsystem could easily be the solution, although limited for IDE based SSDs. But throw in a fast SCSI PPC accelerator (the other can of worms - let's keep it closed for now) and you have a viable memory expansion!
I'm patiently waiting for SSDs to drop in price - I hate HDDs and CDs and their unreliability. We should have had SSDs since the last century... Ugh. I still remember reading articles back in those days of IBMs crystal lattice storage devices. Too bad nothing sellable came out of those projects :-(
