RAMPACK and Hi-RES mod ?

Discussions about Sinclair ZX80 and ZX81 Hardware
albertusj
Posts: 77
Joined: Sat Aug 18, 2012 12:44 am
Location: Somerset-West, South-Africa
Contact:

Re: RAMPACK and Hi-RES mod ?

Post by albertusj »

McKlaud wrote: Fri Nov 01, 2019 6:53 am To be honest I've made this mode with 1N4148 diodes and it works without any issues.

Regarding NAND gates logic, the circuit would be as shown below:
Hi friends,
A while ago I built a ZX81 16K RAM pack using a design from Grant Searle. It works perfectly, but hi-res programs display rubbish. So I tried to modify the DIY pack for hi-res by using the NAND based circuit from this post. I inserted the NAND hi-res circuit (McKlaud) between /RD on the edge connector and OE on the 62256 of my pack (Grants' design below). I also connected the RFSH from the edge connector to the first NAND gate (McKlaud). It still displays nonsense with hi-res programs but works fine otherwise.

I am technical, but I struggle to get my head around how hi-res actually work on a hardware level. Any help would be very appreciated.
Attachments
upgrade16kSchematic.jpg
ZX80/ZX81/ZX Spectrum
McKlaud
Posts: 329
Joined: Tue Dec 19, 2017 10:02 pm
Location: St Albans, UK

Re: RAMPACK and Hi-RES mod ?

Post by McKlaud »

I have never mentioned about NAND gate for /RD and /RFSH. AND gate is needed, so 2 diodes and resistor can do the trick. This AND gate is essential for external RAM packs built with dynamic RAM chips.
Claudius
----------
User avatar
1024MAK
Posts: 4212
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: RAMPACK and Hi-RES mod ?

Post by 1024MAK »

albertusj wrote: Mon May 16, 2022 4:34 pm A while ago I built a ZX81 16K RAM pack using a design from Grant Searle. It works perfectly, but hi-res programs display rubbish.
If you are building your own RAM pack using a SRAM, I think (not tried this, or at least, if I have, I forgotten the results) you don’t need any extra circuitry. Your design should completely ignore the /RD line. That is, make no connection to it. On the SRAM chip, connect the /OE control line (pin 22) to the /CE or /CS control line (pin 20). Both these are then driven by the output from the address decoder (U1A and U1B) in the diagram you posted. You also can completely ignore the /RFSH line.

To understand the high resolution display on a ZX81 (or very similar ‘clone’ machine) you have to understand how the display is generated by the hardware.

For normal video generation, very basically the Z80 processor instruction fetch cycle is used (maybe abused) to generate the address in memory where the video data is in RAM (the display file) then to get this data. However, the ULA captures the data read from the memory and then overrides the data seen by (and read by) the Z80. The data that the Z80 sees is the instruction code for a NOP (no operation). The data captured by the ULA (the character code from the display file in RAM) is used to form the address in ROM for the pixel data for the current video line (the ROM pattern table address).

Immediately after the Z80 instruction cycle, the Z80 performs a DRAM refresh cycle. What the Z80 documentation is not clear on, is that the address generated by the Z80 during a refresh cycle is made up of the R (Refresh) register (address bits 0 to 7) and the I (Interrupt) register (address bits 8 to 15). However, due to the series resistors in some of the address lines, the ULA can override some of the Z80 address lines and presents the part of the address that it formed using the data it captured earlier plus the value of a counter for which row of the character pixel data is needed (0 to 7). The address seen by the ROM is now the complete address for the relevant row of pixels of the relevant character in the ROM. The ROM responds and outputs the pixel data. The ULA captures this and puts it in a parallel to serial shift register. At every video pixel clock (6.5MHz), the ULA shifts the shift register by one bit and outputs it to the video display, hence drawing the screen one bit at a time.

There are various pseudo and real high resolution video display systems. For the pseudo hi. res. the only change is that a custom software routine generates the video rather than the ROM code. See the link below for more details.

For the real high resolution video display systems, as well as using the relevant custom software routine, the hardware is used differently. And if using an external RAM pack, hardware changes may be needed. This is because now we want the pixel data to come from RAM not from the ROM. So we need the RAM to provide data during the Z80 refresh cycle.

The RAM that provides the pixel data (rather than the character display file) must respond and provide data when either the Z80 is reading data (instruction and data read cycles) OR during the Z80 refresh cycle.

Note references in the earlier posts to AND gates are due to negative logic being used. This is equivalent to OR with positive logic.

The I and R registers are used as pointers to the hi. res. display file data in RAM.
During the hi. res. video routine the Z80 executes NOP instructions in video memory (but not in the display file), then in the following refresh cycle, the address generated with the R register (on A0-7) and the I register (on A8-A15) is presented to the RAM. The resulting data is loaded into the ULA video shift register, which shifts the video pixels out as normal.
The Z80 continues program execution (increments the program counter) and the R register (as normal) and repeats the process again until the whole high resolution screen has been shown.

Wilf Rigter describes the video system in detail here ;-)

Note that modern SRAM chips are much faster than older technology SRAM chips. Access times can be much, much faster. This may cause timing problems in some circumstances.

Mark
User avatar
siggi
Posts: 961
Joined: Thu May 08, 2008 9:30 am
Location: Wetterau, Germany
Contact:

Re: RAMPACK and Hi-RES mod ?

Post by siggi »

1024MAK wrote: Mon Jul 04, 2022 11:39 am Note that modern SRAM chips are much faster than older technology SRAM chips. Access times can be much, much faster. This may cause timing problems in some circumstances.
Mark
Indeed. I STRONGLY recommend to connect the ram's /OE only to /RD AND /RFSH, never directly to GND or /CE!
Siggi
My ZX81 web-server: online since 2007, running since dec. 2020 using ZeddyNet hardware
http://zx81-siggi.zx-team.org/ZxTeaM
Post Reply