Forget paging on a multitasking system that requires position independent and re-entrant code. Nightmare to do, and completely incompatible with any QDOS/SMSQ/Minerva philosophy you care to name.
But here is how you can put some of that RAM to good use: replace and shadow the original RAM, it will make the machine quite a bit faster.
I am guessing that the first 256k of one of the RAM chips would map to the first 256k of the 68008 address map, but chip select to tat chip is disabled, so that the original motherboard RAM, ROM, IO are there as usual.
Instead:
1) Replace top 64k of original QL RAM with expansion ram completely:
- When addresses $30000..$3FFFF appear on the address bus, then:
generate DSMCL=H (disables anything on the QL motherboard at $30000..$3FFFF, which happens to be the top 64 of internal RAM)
select the appropriate RAM chip (enables external SRAM instead)
generate DTACKL=L. (generates the shortest bus cycle)
2) Replace bottom 64k of original QL RAM by shadow RAM:
- When addresses $20000..$2FFFF appear on the address bus, then:
- if read:
generate DSMCL=H (disables reading from the bottom 64k or motherboard RAM, where screen 0 & 1 are)
select the appropriate RAM chip (enables reads from the external SRAM chip)
generate DTACKL=L (generates the shortest possible read cycle)
- if write:
select the appropriate RAM chip (enables writes into the external SRAM in parallel with the original bottom 64k of motherboard RAM)
DO NOT generate DSMCL or DTACKL - the motherboard must generate this because the motherboard RAM must generate the proper timing for the ZX8301 ULA to work and generate the image on the screen.
Part (2) ensures that data written to the screen area is written to BOTH the original RAM and the new external SRAM. The forst part is necessary as the image on the screen is generated from data in the original motherboard RAM. The second part makes an exact copy, which can then be read from the external fast ram, instead of the motherboard slow RAM. Since every write is shadowed in fast RAM, there is no way to ever get different data, unless corruption happens. However, this also implies that the machine will work even if the motherboard RAM has errors! This is because the only thing that ever reads from it is the 8301 ULA, as it generates the image on the screen, so while the image may appear corrupt if there is something wrong there, the QL will still work properly.
Unfortunately there is no good way to 'save' the remaining 128k or SRAM.
I am not familiar with the way the Trump Card starts up and maps it's ROM. Am I correct in remembering there is a 32k EPROM on the original (16k for TK2 and 16k for the floppy driver and other extensions)?
Regarding QVME:
The QVME has 256k of on-board VRAM for the screen, which means a maximum of 1048576 mode 4 pixels. The resolution is programmable in wide limits as long as there is enough RAM for the pixels. I think the maximum at 1280 horizontal is 808 vertical or something like that. It's been a while. It uses an old 6845 CRT controller and a lot of GAL-like simple PLDs to implement the circuit.
Nasta wrote:
I am not familiar with the way the Trump Card starts up and maps it's ROM. Am I correct in remembering there is a 32k EPROM on the original (16k for TK2 and 16k for the floppy driver and other extensions)?
Yes, the TC ROM is 32k, about half being TK2, and half drivers and hardware support routines.
The Trump card actually does some very interesting things during startup.
It cannot map itself to $C000 as it might collide with a plugged in ROM in the ROM slot.
It can also not map to $C0000, the area for expansion card ROMs, as it wants to supply RAM there.
But it needs to be in one of the two places in order for QDOS to properly initialize it. So it "hops" between $c0000 and $10000 during QL startup.
Directly after reset, it maps its ROM to $10000 - $17fff (It needs to be out of the way to be able to allow the QL ROM to do a complete RAM test finding contiguous RAM from $20000 to the Megabyte). Unfortunately, the QL ROM initialization will not find it there.
Then any cartridge ROM that might be plugged in (so, not the TC ROM) is initialized by the QL ROM. This initialization sequence (the first read to $C000 that tries to find a cartridge ROM signature) pages in the TC ROM into a second address range at $c0000 in the expansion ROM area, overlapping the RAM that was there before. (That's done so that the QLs ROM init sequence is able to find it in the next ROM initialisation step)
Once the QL initializes the "expansion card ROM", that code above $c0000 directly jumps to the second ROM copy at $10000. This first read ad $10000 causes the copy at $c0000 to be paged out and again being RAM - We're there.
Minerva scans for ROMs at $0C000, $10000, $14000 and then from top of established RAM (as set by SV_RAMT)
So, Minerva will only find TC at $10000, and never at $C0000. But end result is same
Silvester wrote:Minerva scans for ROMs at $0C000, $10000, $14000 and then from top of established RAM (as set by SV_RAMT)
So, Minerva will only find TC at $10000, and never at $C0000. But end result is same
Yep. Minerva does the ROM scan a bit different from the original ROMS - and happily hits it as well. It does, other than the original ROMs, also check whether it's seen a ROM twice (for ROMs exactly like the TC's that establish mirror ROM areas) and will only initialize it the first time.
Silvester wrote:Minerva scans for ROMs at $0C000, $10000, $14000 and then from top of established RAM (as set by SV_RAMT)
So, Minerva will only find TC at $10000, and never at $C0000. But end result is same
Yep. Minerva does the ROM scan a bit different from the original ROMS - and happily hits it as well. It does, other than the original ROMs, also check whether it's seen a ROM twice (for ROMs exactly like the TC's that establish mirror ROM areas) and will only initialize it the first time.
Tobias
It should not be necessary as Minerva will initialize the ROM when it sees it at $10000 and the read at $10000 will remove the duplicate image right there, so it will not be detected the second time.
It's a bit surprising this, as they might just as well have decoded it at the ROM slot, and then immediately removed it from there the same way as now, and then simply checked in software for the ROM slot contents. I suppose the way it is done is because it fits the logic in the PAL chips used at the time.
In case it passed without others noticing, yes it is possible to (even temporary) disable the ROM slot by anything on the J1 connector via the signal DSMCL. In fact, not only that, anything the logic on the motherboard decodes, and at any location you want - just decoding the required address and pulling DSMCL high before DSL goas low.
Silvester wrote:Minerva scans for ROMs at $0C000, $10000, $14000 and then from top of established RAM (as set by SV_RAMT)
So, Minerva will only find TC at $10000, and never at $C0000. But end result is same
Yep. Minerva does the ROM scan a bit different from the original ROMS - and happily hits it as well. It does, other than the original ROMs, also check whether it's seen a ROM twice (for ROMs exactly like the TC's that establish mirror ROM areas) and will only initialize it the first time.
Tobias
Ah yes, I noticed RES_128 copies ROM at $10000 to RAM at $C0000 before calling OS with A4 at 128K. So that could mean Minerva would see $10000 and $C0000. So as you say it detects replication and rejects copy. Of course QDOS only sees $C0000 copy in RAM.
I was just catching-up on latest conversations and read Nasta's snippet about shadowing the BBQL RAM and thought to confirm that I recently built a memory expansion for one of my old QLs which had some dead DRAM chips and it works very nicely (thanks to Rich for that old Iss5 board!)
The mini-expansion board I made fitted inside the case, with a hairy through-pin connection to one of the ROM sockets (akin to the Minerva Mk1 approach - to reduce number of additional lines needing connection), included a 512KB low-power SRAM IC which shadows the first 128k and provides an extra 256KB of RAM, an 64KB EPROM to replace the 48k ROM and 16k expansion ROMs, a reset-generator IC to support the Battery-backed 8302 and the necessary glue-logic (a 16v8 Lattice GAL). As I wasn't after the largest memory expansion on this unit, I also enabled a 128KB 'page' of the SRAM as Non-volatile (NV), to store my extra toolkits, etc - again backed-up with the battery (a Varta 3.6V device).
The extra lines (A16-A19, DSMCl, DTACKl, RWl, etc) were connected via some IDC cable, looped under the mainboard - bit messy, but all fitted without occupying the expansion bus - thus allowing a Trumpcard/diskdrives to be occasionally connected (the extra SRAM memory & NV memory above 256K is disabled altogether by a DPST switch I brought out to the case-edge so as not to clash with the TC.)
The bottom/video 64K DRAM is shadowed in that split way described below - simultaneous WRs to both the 8301/DRAM and SRAM, without disabling DSMC, whilst RDs completely disable the 8301/DRAM via DSMC being held high.
The next 64k is shadowed completely (WR and RD) disabling the 8301/DRAM - again as per Nasta's explanation.
The next 256KB of SRAM is mapped as expected at 256K in the memory map, contiguous to the shadowed areas, giving 384KB total RAM.
The top 128KB 'page' of the SRAM acting as NV, sitting out of the way at 896k, obviously required some re-mapping of the address lines as seen by the SRAM - the GAL takes care of that. The NV SRAM bit is still a bit flaky (one or two bytes gets corrupted intermittently upon power-up - yet to fully diagnose, but suspect the old PSU or the logic of my gated Chip Select from the reset generator IC).
WR access to the 128K NV page of SRAM is gated through a latch taken from p2-6 of the Hermes IPC, defaulting to disabling WR, and activated/de-activated via the Hermes IPCEXT command from SuperBasic.
Some simplistic repeated RD/WR tests involving the video memory (lots of scrolling) showed a very useful improvement in access speed - I forget how much now - as most screen accesses typically involve as much reading (purely in the zero-WS SRAM) as writing (contended with the 8301) - even when drawing/writing to the screen.
It was a(nother) labour of love, but an interesting proof of concept (having learnt much from Nasta and others' previous expositions!)
Happy tinkering, friends!
M.
[quote="Nasta"]...
But here is how you can put some of that RAM to good use: replace and shadow the original RAM, it will make the machine quite a bit faster.
I am guessing that the first 256k of one of the RAM chips would map to the first 256k of the 68008 address map, but chip select to tat chip is disabled, so that the original motherboard RAM, ROM, IO are there as usual.
Instead:
1) Replace top 64k of original QL RAM with expansion ram completely:
- When addresses $30000..$3FFFF appear on the address bus, then:
generate DSMCL=H (disables anything on the QL motherboard at $30000..$3FFFF, which happens to be the top 64 of internal RAM)
select the appropriate RAM chip (enables external SRAM instead)
generate DTACKL=L. (generates the shortest bus cycle)
2) Replace bottom 64k of original QL RAM by shadow RAM:
- When addresses $20000..$2FFFF appear on the address bus, then:
- if read:
generate DSMCL=H (disables reading from the bottom 64k or motherboard RAM, where screen 0 & 1 are)
select the appropriate RAM chip (enables reads from the external SRAM chip)
generate DTACKL=L (generates the shortest possible read cycle)
- if write:
select the appropriate RAM chip (enables writes into the external SRAM in parallel with the original bottom 64k of motherboard RAM)
DO NOT generate DSMCL or DTACKL - the motherboard must generate this because the motherboard RAM must generate the proper timing for the ZX8301 ULA to work and generate the image on the screen.
Part (2) ensures that data written to the screen area is written to BOTH the original RAM and the new external SRAM. The forst part is necessary as the image on the screen is generated from data in the original motherboard RAM. The second part makes an exact copy, which can then be read from the external fast ram, instead of the motherboard slow RAM. Since every write is shadowed in fast RAM, there is no way to ever get different data, unless corruption happens. However, this also implies that the machine will work even if the motherboard RAM has errors! This is because the only thing that ever reads from it is the 8301 ULA, as it generates the image on the screen, so while the image may appear corrupt if there is something wrong there, the QL will still work properly.
Do you have a comparative benchmark between this shadowed system and a non-shadowed system? Just something simple like lots of random screen reads and writes and etc?
I will re-run some simple benchmarks between my 2 QLs, although the comparison will be very slightly skewed as they use different mainboard versions (Iss5 vs Iss7).
