Allright, I need to scan the pages first... will do it this weekend.Nasta wrote:Yes please!
Hardware detectives for FrankenQL?
- janbredenbeek
- Super Gold Card
- Posts: 668
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Hardware detectives for FrankenQL?
- janbredenbeek
- Super Gold Card
- Posts: 668
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Hardware detectives for FrankenQL?
I've had a look at the diagram and it's really simple. The address lines A16-A19 from the CPU are fed into a PROM which outputs four data lines. Two of these are used to feed the A16 and A17 lines of the 8301 (which are disconnected from the corresponding CPU lines). This 'fools' the 8301 into thinking that the address range $20000-$9FFFF from the CPU is $20000-$3FFFF (i.e. real address minus $20000 offset divided by four). The remaining two lines are fed into a 74LS157 mux which drives the DA8 lines of the 41256 DRAM chips (at pin 1).
One remaining question is how this can refresh the whole DRAM chips since the 8301 only drives DRAM address lines DA0-DA7?
I'll post the diagram later, it's well past midnight now...
One remaining question is how this can refresh the whole DRAM chips since the 8301 only drives DRAM address lines DA0-DA7?
I'll post the diagram later, it's well past midnight now...
- janbredenbeek
- Super Gold Card
- Posts: 668
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Hardware detectives for FrankenQL?
Okay, here the schematics as promised. This is the circuit diagram:
The 82S123 PROM is to be placed piggy-back on IC19, the 74LS157 on IC20. Address lines A16 to A19 from the CPU are fed to inputs 13 to 10 on the PROM, which acts as an address decoder.
The outputs 1 and 2 from the PROM drive A17 and A16 to the 8301 respectively. Outputs 3 and 4 from the PROM drive the A0 and B0 lines to the 74LS157, which in turn drives DA8 to the 41256 DRAM chips at pin 1 via the 33 Ohm resistor.
The 512K memory can be cut down to 128K using the switch.
The 82S123 PROM has the following contents:
There are two tables; the top one is for 128K, the bottom one for 512K. The left column shows the values of A16-A19 from the CPU, the right column the data bits. Bits 0 and 1 drive lines A17 and A16 to the 8301, bits 2 and 3 drive the extra address lines to the 74LS157 and DA8 line to the 41256 DRAMs. Bits 4 to 7 are normally not used but can be used to select additional ROMs or I/O devices (I used it to put extra ROMs in the $F0000-$FFFFF area).
As you can see, bits 0 and 1 (corresponding to A17 and A16 to the 8301) are 10 for addresses $20000 to $5FFFF and 11 for addresses $60000 to $9FFFF so the 8301 is fooled into thinking that the accesses are really at $20000 to $3FFFF. Of course, to address 512K, two additional address lines are needed and these are driven by bits 2 and 3 (and multiplexed to one line by the 74LS157).
Now the big question: How can DRAM refresh work reliably when the DA8 line from the DRAMs is not connected to the 8301 bus? (And yes, I do have a working QL with this mod!)
Jan.
The 82S123 PROM is to be placed piggy-back on IC19, the 74LS157 on IC20. Address lines A16 to A19 from the CPU are fed to inputs 13 to 10 on the PROM, which acts as an address decoder.
The outputs 1 and 2 from the PROM drive A17 and A16 to the 8301 respectively. Outputs 3 and 4 from the PROM drive the A0 and B0 lines to the 74LS157, which in turn drives DA8 to the 41256 DRAM chips at pin 1 via the 33 Ohm resistor.
The 512K memory can be cut down to 128K using the switch.
The 82S123 PROM has the following contents:
There are two tables; the top one is for 128K, the bottom one for 512K. The left column shows the values of A16-A19 from the CPU, the right column the data bits. Bits 0 and 1 drive lines A17 and A16 to the 8301, bits 2 and 3 drive the extra address lines to the 74LS157 and DA8 line to the 41256 DRAMs. Bits 4 to 7 are normally not used but can be used to select additional ROMs or I/O devices (I used it to put extra ROMs in the $F0000-$FFFFF area).
As you can see, bits 0 and 1 (corresponding to A17 and A16 to the 8301) are 10 for addresses $20000 to $5FFFF and 11 for addresses $60000 to $9FFFF so the 8301 is fooled into thinking that the accesses are really at $20000 to $3FFFF. Of course, to address 512K, two additional address lines are needed and these are driven by bits 2 and 3 (and multiplexed to one line by the 74LS157).
Now the big question: How can DRAM refresh work reliably when the DA8 line from the DRAMs is not connected to the 8301 bus? (And yes, I do have a working QL with this mod!)
Jan.
Re: Hardware detectives for FrankenQL?
Exactly - this was my question all along. Something would have to count the low order DRAM address lines through all 512 possible states inside the required refresh period, and with absolute reliability all the time. I am not aware of such a thing. However... I am aware of some 256kx1 chips that used 8-bit refresh (and were internally organized as 4 blocks of 64kx1), this was done in the beginning to get 64k DRAM compatibility and rapid adoption of the new 256k chips.janbredenbeek wrote:Okay, here the schematics as promised...
...
Now the big question: How can DRAM refresh work reliably when the DA8 line from the DRAMs is not connected to the 8301 bus? (And yes, I do have a working QL with this mod!)
Jan.
And of course, these days we'd integrate the PROM and the multiplexer inside a single small GAL chip...
Re: Hardware detectives for FrankenQL?
and here is what I presume is the same thing as a slightly more professional version I picked up in another QL just now:
- janbredenbeek
- Super Gold Card
- Posts: 668
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Hardware detectives for FrankenQL?
I used to have such a memory extension from Micro Peripherals, it was only 256K so this must be a different one.olifink wrote:and here is what I presume is the same thing as a slightly more professional version I picked up in another QL just now:
Jan
Re: Hardware detectives for FrankenQL?
But that was slow "internal" memory extension (as far as I remember).janbredenbeek wrote:I used to have such a memory extension from Micro Peripherals, it was only 256K so this must be a different one.
7000 4E75
-
- QL Wafer Drive
- Posts: 1062
- Joined: Sat Oct 25, 2014 9:53 am
Re: Hardware detectives for FrankenQL?
Yes and in fact any memory expansion - including Oliver's two examples - that rely on the ZX8301 will be of the slow type - aka 'contended', by design.
On a side note - it is surprisingly simple with today's GALs and SRAM availability to add uncontended memory even internally - with a bit of additional wiring and creativity - which is what we QL'ers are about
For example, I built a daughter board with EPROM, SRAM and a GAL that connected to one of the two internal ROM sockets and had 8 or so additional connections for the additional address, R/W and async control lines (DS + DTACK) that runs uncontended in all but the lower 64K of RAM space, which it then shadows for Writes (for 8301 video) and by-passes altogether for Reads.
But I digress.
That second internal expansion of Oliver's is certainly a nicely designed and built unit.
On a side note - it is surprisingly simple with today's GALs and SRAM availability to add uncontended memory even internally - with a bit of additional wiring and creativity - which is what we QL'ers are about

For example, I built a daughter board with EPROM, SRAM and a GAL that connected to one of the two internal ROM sockets and had 8 or so additional connections for the additional address, R/W and async control lines (DS + DTACK) that runs uncontended in all but the lower 64K of RAM space, which it then shadows for Writes (for 8301 video) and by-passes altogether for Reads.
But I digress.
That second internal expansion of Oliver's is certainly a nicely designed and built unit.
Re: Hardware detectives for FrankenQL?
I also got the machine going now, must have been a flaky connection somewhere. It is actually a 512K extension and sits on top of the existing RAM.martyn_hill wrote:That second internal expansion of Oliver's is certainly a nicely designed and built unit.
woha, that does sounds interesting... now I really should play around more with hardwaremartyn_hill wrote:For example, I built a daughter board with EPROM, SRAM and a GAL that connected to one of the two internal ROM sockets and had 8 or so additional connections for the additional address, R/W and async control lines (DS + DTACK) that runs uncontended in all but the lower 64K of RAM space, which it then shadows for Writes (for 8301 video) and by-passes altogether for Reads.


