Dave wrote:
After discussions, the memory map is provisionally as follows (as of two days ago):
$000000 - $BFFFFF 3x 4MB banks - 12MB
$C00000 - $DFFFFF Flash
$E00000 - $FFFFFF Aliases of original QL map.
Screen: $20000..$27FFF on the QL bus, which appears to the CPU in this proposed system at $E20000..$E27FFF and $F20000..$F2FFFF, needs to appear at $020000..$027FFF. With clever mapping and decoding, the memory will be shadowed so reads are from 32-bit RAM and writes go to both 32-bit RAM and slower 8-bit RAM using four write cycles. This way, we'd get the maximum speed benefit while maintaining highest compatibility with code that expects the screen (and other IO) to be at a specific address.
I know, this does mean 12MB will be the RAM limit. That's still three times the Super Gold Card. It would also be a fair bit faster. We're only losing 3MB but gaining a large flash area and a huge compatibility bonus. Also, it's better to under-populate than overpopulate and not use - my original plan was to keep the QL space in the bottom MB and just have the simpler address decoder ignore the RAM there.
As I said in a mail, it is possible to move the start of RAM to a higher address, but some old software will not work. Also, this requires patching of the OS to handle non-contiguous RAM. A bit more about this, below.
Also the question remains about the emulation of ROM in the first 64 of the address map. It is easy to make the first 64k of the fladh area also appear in the bottom 64k. This, however, prevents choice of OS because at the very least the bottom 1k must be reconfigurable (RAM) so a different OS can put it's vectors there. Fortunately it is not too difficult to reorganize the decoder to also do emulation of ROM using RAM there.
Here are some unanswered questions:
How might we expand the expansion bus to add the additional address lines? I know 64-pin DIN41612 will fit in the bottom rows of 96-pin connectors.
The big question is, what would one want them for? In face, address lines are not really of any big benefit, rather data bus lines are. THis would then offer the possibility of solving the next question.
Otherwise, if one really wanted to add address lines, there are several for the taking - primairly the FC lines. Thece cannot be used on the 020 in the same way as on the QL, and in fact as far as I know were never used by external hardware. So, that would in theory give you 3 more address lines. That being said, since in the provisional address map there are only 2 aliases of the original 1M address space, you need only one extra address line to differentiate between the two.
There are other things that might be of more interest - for instance bus speed. This is (by any 020 standard) VERY slow. Even if you have only 8 data bits, if they work 2x faster, it'll be 2x faster - not something to dismiss. Especially considering that we do have some pei=ripherals like IDE that would indeed benefit from it.
How might we expand native QL video hardware capability and retain compatibility?
It is doable to an extent, the same way Aurora does it, using multiple aliases of the same RAM. Aurora has a 256k VRAM organized as 1024x1024 mode 4 pixels (and I am using this as the simpler example). When the original 32k of the screen is addressed, it actually accesses a 512x256 pixel area in the top lefthand corner. This is done by simple address line manipulation on the way from the CPU to RAM.
However, this only works in mode 4 and 8. In the 16 or 256 color mode, this is disabled (writes to the actual VRAM are ignored, but not the shadowing portion which the SGC performs - reason being, QXL style screen emulation can be done in software, as there is still reliable data in the old screen area).
So, something like this can be done here as well.
BUT, first there has to be an address area to contain the data for the 'new' screen. FOr instance, one of the aliases used for the QL map can be used for this, giving up to 1M of screen RAM - enough for 1024x768 in 256 colors, or 1024x512 in 16-bit color. However - keep in mind that the QL window system saves overlapping screens to RAM, so suddenly increasing the screen size by 24x, may make the total amount of RAM slightly tight...
Also, in order for it to be usably fast, it should definitely be 32-bit. That being said, the circuits are not trivial. Some sort of screen timing generator, dual port DRAM (VRAM) is definitely desirable, timing control, DA conversion to get analog color or some digital color output. Think CPLD/FPGA.
The actual original video is what it is, lost cause trying to expand this, it would just become very complicated and still VERY slow.
With more memory comes more slave blocks for mass storage devices. This can slow things down. Strategies for dealing?
Not needed - in fact, it will be faster if the slave block system is suitably used by the driver. Although there is more RAM, it will likely test faster because access is so much faster. The slave block table will be bigger, but this does not impact speed negatively if correctly implemented, in fact the opposite. Reading slaved blocks from fast 32-bit RAM is still MUCH faster than from the original device.
