Dave wrote:All those tasks need to be handed off, since they're aimed at an 8-bit bus.
I used a couple of SRAM chips I had laying around, so no refresh is even necessary. They're quite cheap now. Address decoding is fairly trivial, but I'm unsure about the 8302 decoders.
If somebody out there with amazing skills
would do a CPLD that would do all those things... Or if Nasta would resurface and finish the Goldfire.... I have 25 FPGAs that were ordered for that, and a bunch of magnetics....
As for the memory map, sometimes I get to a firm dislike of Sinclair Research's design methods.
Even if DRAM was used, refresh does not need to be done the way it used to be as most DRAMs have an auto-refresh mode, one just has to run a cycle every so often. In fact, this is implemented in the Aurora, and does 4 refresh cycles for every horizontal synch pulse.
Dave, the GF is a far mor complex piece of hardware than a SGC for instance. There is a lot more of the footwork that has to be done by the CPLDs because the 68060 CPU that was intended to run it, has no dynamic bus sizing and doing that part the simple way will severely cripple it's performance.
The other major problem is that while the CPLDs intended to be used on are still available, the development programs (compiler) are not. This was a major issue to begin with and the reason why the project was never finished even when parts were ordered.
Other parts such as the superIO chip, sound chip and LAN can still be found alhough prices have gone up since these are no longer used by mainstream hardware.
Finally, there is the issue of a rather large chunk of code that needs to be written to support the hardware even at the basic level of maiking it boot correctly.
The GF specs added a lot of new resources, such as multiple level interrupts, and dual CPU support, as well as a bunch of hardware trucks to make it fast with old hardware and even faster with new one (such as selectable access speed over the 8-bit bus, caching and shadowing, and 32-bit multiplex bus support).
BTW re running the 68EC020 at 24 instead of 25MHz, this saves one oscillator because the floppy controller works at 24MHz.
Regarding the ZX8301, the grand majority of what it does is generate the video timing and read the video RAM continiously using 4-byte burst reads (which it buffers internally) to generate the screen image. The rest is fairly trivial decoding (simple logic) and in fact this was duplicated and extended in the Aurora, so that a ZX8302 can be used for other functions. The ZX8302 is actually a more complex chip from the tandpoint of the various types of logic and circuits implemented in it.
A propeller chip is not exactly suitable for a replacement of the ZX8301 but doing that is undeed a testament to the ingenuity of the people that have done it, it probably squeezes out the last ounce of propeller performance to work.
Perhaps the simplest way to make a replacement (for the moment forgetting any estension of the video resolutions and color support) is using dual-port static RAM. This used to be expensive, but 32k or 64k is nowadays considered small so one might be able to find parts fairly cheaply. The plus side is that this RAM behaves just like any static ram but can be read and/or written from both ports at the same time and asynchronously.
Another way to do this would be to implement a 32-bit Aurora. In fact, this is not as difficult as it may seem - the video generation logic in the Aurora is divided into two PLDs, one of which is responsible for connecting the CPU side of a VRAM (DRAM with one standard and one serial output port) and video timing generation in the vertical direction (display lines). The other is responsible for repackaging what comes out of the serial read side of the VRAM into pixels and horizontal timing. The CPU and timing logic is practically independent of bus size, so using a 32-bit VRAM instead of 8-bit gets you there, but the part that packages the read data into pixels must be re-done (it's actually the least complicated part). Because a 32-bit version of the Aurora was a project planned to immediately follow the GF, I even got some 16-bit VRAM for it (so 2 16-bit chips would be used to get 32-bit access, the total capacity would have been 1M).
It should be noted that a small CPU such as a PIC or AVR could be used to generate the required timings very flexibly. I n a similar manner such a CPU and a bit of dual port RAM (to interface between the QL whatever flavor it may have and this small CPU) can be used to emulate the ZX8301 and IPC, for instance, and offer much more functionality at that.
