Fun things to do with an MC68EC020....

[Dave]

I'll be on the QL Forum chat this evening, if anyone wants to shoot the breeze/chat/commiserate/bounce thoughts around

[Peter]

I am using the latest 1.98 Minerva image - I don't know how modded that is to accommodate the '020.

Should be completely working with 68020.

Like Sinclair, I'm a firm believer in "do it in software" - if he had stayed closer to his roots with the QL it would be a much simpler machine.

Especially the coprocessor was unnecessary, and not Sinclair-style in my opinion. The whole hardware could have become less complex, cheaper, and better signal quality, because the smaller size would have allowed a better PCB layout. ZX Spectrum with Interface 1 had shown how much simpler keyboard and RS232 interfaces could be.

[Dave]

I couldn't agree more, Peter. I was planning for this to be a 6-layer PCB so I could have proper power and ground and much less cross-talk.

[Peter]

What is it now? Wire-wrap or also PCB?

[Dave]

It's a wire wrap board damaged by crushing during storage.

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.

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.
How might we expand native QL video hardware capability and retain compatibility?
With more memory comes more slave blocks for mass storage devices. This can slow things down. Strategies for dealing?

Please remember, I am doing this as a hobbyist in spare time. This is not a business venture or anything resembling a plan.

[Nasta]

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.

[Peter]

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.

But Dave would probably have to use the existing drivers! From Q68 experience, I can only warn about this issue.

The problem is: The first read of a file becomes painfully slow on a system with lots of RAM! Especially with long files, you seldom read the whole length of them repeatedly, so there is zero benefit having it all in slave blocks.

As soon as memory is withheld from the Slaveing mechanism, speed of the first read becomes normal.

Not that Slaveing needs to be completely disabled, but it must be limited, and software expertise would be required to implement this for Dave.

Peter

[Nasta]

TBH I don't exactly remember how slaving is used in the old drivers. I do remember that originally the slave block table was limited to 32k in Minerva due to a bug, but that was soon fixed (word index was used). I seem to recall there is some sort of linear search, initially? Is this what limits the first read, or does the driver attempt to buffer the whole file regardless of how much is actually read?

[janbredenbeek]

TBH I don't exactly remember how slaving is used in the old drivers. I do remember that originally the slave block table was limited to 32k in Minerva due to a bug, but that was soon fixed (word index was used). I seem to recall there is some sort of linear search, initially? Is this what limits the first read, or does the driver attempt to buffer the whole file regardless of how much is actually read?

Old drivers indeed do a linear search, which slows down with lots of memory if the block you want has not yet been loaded into slave blocks. According to the QPC manual special measures have been taken on that implementation of SMSQ/E to avoid this problem.

Jan.

[Peter]

And the special measure is limiting slave block usage. To 1 MB if I remember correctly.