Hardware detectives for FrankenQL?

Nagging hardware related question? Post here!
User avatar
janbredenbeek
Super Gold Card
Posts: 631
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Hardware detectives for FrankenQL?

Post by janbredenbeek »

Nasta wrote:Yes please! :)
Allright, I need to scan the pages first... will do it this weekend.


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Hardware detectives for FrankenQL?

Post by Nasta »

No hurry - and thanks!


User avatar
janbredenbeek
Super Gold Card
Posts: 631
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Hardware detectives for FrankenQL?

Post by janbredenbeek »

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...


User avatar
janbredenbeek
Super Gold Card
Posts: 631
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Hardware detectives for FrankenQL?

Post by janbredenbeek »

Okay, here the schematics as promised. This is the circuit diagram:
circuit.png
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:
prom.png
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.


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Hardware detectives for FrankenQL?

Post by Nasta »

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.
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.
And of course, these days we'd integrate the PROM and the multiplexer inside a single small GAL chip...


olifink
Chuggy Microdrive
Posts: 69
Joined: Tue Oct 30, 2018 7:35 pm

Re: Hardware detectives for FrankenQL?

Post by olifink »

and here is what I presume is the same thing as a slightly more professional version I picked up in another QL just now:
IMG_20181205_115312.jpg


User avatar
janbredenbeek
Super Gold Card
Posts: 631
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Hardware detectives for FrankenQL?

Post by janbredenbeek »

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:
I used to have such a memory extension from Micro Peripherals, it was only 256K so this must be a different one.

Jan


User avatar
RalfR
Aurora
Posts: 872
Joined: Fri Jun 15, 2018 8:58 pm

Re: Hardware detectives for FrankenQL?

Post by RalfR »

janbredenbeek wrote:I used to have such a memory extension from Micro Peripherals, it was only 256K so this must be a different one.
But that was slow "internal" memory extension (as far as I remember).


4E75 7000
martyn_hill
Aurora
Posts: 924
Joined: Sat Oct 25, 2014 9:53 am

Re: Hardware detectives for FrankenQL?

Post by martyn_hill »

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.


olifink
Chuggy Microdrive
Posts: 69
Joined: Tue Oct 30, 2018 7:35 pm

Re: Hardware detectives for FrankenQL?

Post by olifink »

martyn_hill wrote:That second internal expansion of Oliver's is certainly a nicely designed and built unit.
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: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.
woha, that does sounds interesting... now I really should play around more with hardware :shock: although I can happily solder somebody else's stuff into any machine I've never got as far as to build a PCB of my own. So I'm looking at doing a ROM port EPROM dongle as the first project, that shouldn't be too hard :? what could possibly go wrong ;)


Post Reply