Hi-res graphics mode in the ZX81

Discussions about Sinclair ZX80 and ZX81 Hardware
Ivanzx
Posts: 16
Joined: Fri May 06, 2016 11:51 am
Location: Frankfurt, Germany

Hi-res graphics mode in the ZX81

Post by Ivanzx »

Hi all, I am starting to discover this interesting machine, I am a ZX Spectrum user since 1989 and still using my +2A here to have fun when real life permits :)

I have a question for those experts in the ZX81: The Hi-res mode was an option available back in the day in the 80s or is some sort of enhancement that was added in this Homebrew era? Is it produced "naturally" within the machine or with some peripheral?

Thanks!
User avatar
Paul
Posts: 1110
Joined: Thu May 27, 2010 8:15 am
Location: Germanys west end

Re: Hi-res graphics mode in the ZX81

Post by Paul »

Every ZX81 with internal memory is hires capable from factory.
That's why dr. Beep hires 1K games run on every ZX81/TS1000 out of the box.
Sinclair 16K RAM extensions need a hardware mod to become hires capable.
Modern RAM extensions are always hires capable.
In the beginning of software development this feature hadn't been discoverd.
It is implemented by replacing the original video driver by own machine language.
kind regards Paul
In theory, there is no difference between theory and practice. But, in practice, there is.
Ivanzx
Posts: 16
Joined: Fri May 06, 2016 11:51 am
Location: Frankfurt, Germany

Re: Hi-res graphics mode in the ZX81

Post by Ivanzx »

Vielen dank, Paul!

So, those hardware mods for the 16K RAM extensions are something new and Homebrew from these last years?

I saw that Quicksilva also had a Hi-res device back in the 80s, right? Was it the same thing?

Thanks again!
User avatar
mrtinb
Posts: 1284
Joined: Fri Nov 06, 2015 5:44 pm
Location: Denmark
Contact:

Re: Hi-res graphics mode in the ZX81

Post by mrtinb »

Hi :-)

There are many different ways for Hi-res on ZX81, and here are some articles to read about the possibilities:
Martin
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube
dr beep
Posts: 1303
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Hi-res graphics mode in the ZX81

Post by dr beep »

Ivanzx wrote:Vielen dank, Paul!

So, those hardware mods for the 16K RAM extensions are something new and Homebrew from these last years?

I saw that Quicksilva also had a Hi-res device back in the 80s, right? Was it the same thing?

Thanks again!
There are several methods of hires. Most common is to create a screen somewhere in memory which is displayed with your own hiresdisplayroutine.
There are also hardware interfaces which give you place in memory where you can built UDG and use them as normal characters.

The hardware has been there for many years. Nothing new.
Hires in 1K is also been proven in 1996 by Wilf Rigter, but games were never coded in hires in 1K until I started to do that in 2011 as a tribute to 30 years of ZX81. This became so addictive that I have now 24 games with some kind of hires in 1K.

To call your own hiresroutine you can see the site from Wilf, but mostly the setting of IX is used and a default return to the normal program.
User avatar
1024MAK
Posts: 3258
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: Hi-res graphics mode in the ZX81

Post by 1024MAK »

From zxdocs.txt
Display Output
--------------

Display Modes
--> Video Text and Blockgraphics
--> Video Pseudo Hi-Res Graphics
--> Video True Hi-Res Graphics

Video Text and Blockgraphics
----------------------------

Overview
This is the ZX standard video mode. The display area consists of 32x24
characters of 8x8 pixels each. The user cannot set single pixels though, only
64 predefined characters can be used. However, some of these characters are
split into 2x2 blocks (4x4 pixel each), allowing to display 64x48 block low
resolution graphics.

Video Memory
Video memory is addressed by the D_FILE pointer (400Ch) in ZX80/81 system area.
The first byte in VRAM is a HALT opcode (76h), followed by the data (one byte
per character) for each of the 24 lines, each line is terminated by a HALT
opcode also. In case that a line contains less than 24 characters, the HALT
opcode blanks (white) the rest of the line up to the right screen border. (Thus
left-aligned text will take up less memory than centered or right-aligned
text.)

Character Data, VRAM Size
Character data in range 00h..3Fh displays the 64 characters, normally black on
white. Characters may be inverted by setting Bit 7, ie. C0h..FFh represents the
same as above displayed white on black.
The fully expanded VRAM size is 793 bytes (32x24 + 25 HALTs, almost occupying
the whole 1Kbyte of internal RAM), an empty fully collapsed screen occupies
only 25 bytes (HALTs).

Character Set
The character set is addressed by the I register multiplied by 100h. In the
ZX81 this is 1Eh for 1E00h..1FFFh, in ZX80 0Eh for 0E00h..0FFFh. Setting
I=40h..7Fh in attempt to define a custom charset in RAM rather than ROM does
not work.

Display procedure Tech Details
The display data is more or less 'executed' by the CPU. When displaying a line,
the BIOS takes the address of the first character, eg. 4123h, sets Bit 15, ie.
C123h, and then jumps to that address.

The hardware now senses A15=HIGH and /M1=LOW (signalizing opcode read), upon
this condition memory is mirrored from C000-FFFF to 4000-7FFF. The 'opcode' is
presented to the databus as usually, the display circuit interpretes it as
character data, and (if Bit 6 is zero) forces the databus to zero before the
CPU realizes what is going on, causing a NOP opcode (00h) to be executed. Bit 7
of the stolen opcode is used as invert attribute, Bit 0-5 address one of the 64
characters in ROM at (I*100h+char*8+linecntr), the byte at that address is
loaded into a shift register, and bits are shifted to the display at a rate of
6.5MHz (ie. 8 pixels within 4 CPU cycles).

However, when encountering an opcode with Bit 6 set, then the video circuit
rejects the opcode (displays white, regardless of Bit 7 and 0-5), and the CPU
executes the opcode as normal. Usually this would be the HALT opcode - before
displaying a line, BIOS enables INTs and initializes the R register, which will
produce an interrupt when Bit 6 of R becomes zero.
In this special case R is incremented at a fixed rate of 4 CPU cycles (video
data executed as NOPs, followed by repeated HALT), so that line display is
suspended at a fixed time, regardless of the collapsed or expanded length of
the line.

As mentioned above, an additional register called linecntr is used to address
the vertical position (0..7) whithin a character line. This register is reset
during vertical retrace, and then incremented once per scanline. The BIOS thus
needs to 'execute' each character line eight times, before starting to
'execute' the next character line.

Video Pseudo Hi-Res Graphics
----------------------------

This method is used to display 256x192 pixels graphics, limited to max 128
combinations within each row of 8 pixels though. Even though not supported by
the BIOS, a couple of games are using this video mode: Rock Crush, Dans
Revenge, Rocketman, Forty Niner, Madjump II, Bipods, Micromouse, and possibly
others.

Basically it is working much like Text video mode, the character height is
reduced to a single scanline, so each tile consists of 8x1 pixels rather than
8x8 pixels. And the screen consists of 32x192 of these 'flat' characters, each
line usually terminated by a RET opcode (C9h), thus occupying 6176 bytes of
memory.

A special display procedure is required which forces the linecntr register to
zero by issuing a very short 'vertical retrace' signal each scanline
(preferably simultaneously to the hardware generated horizontal retrace
signal). In result, only the topmost row of each character will be displayed,
as the topmost row of most of the normal characters is just blank, it'd be
recommended to change the characterset pointer in the I register to another
address in ROM.

For example, setting I=0Ch would select the area 0C00h..0DFFh (in steps of
eight: topmost rows of chars #0, #1, #2 at C00h, C08h, C10h, etc). The machine
code bytes in this memory region are then used as 'randomly' predefined pixel
rows, which may or may not match the programmers requirements. Each of the 64
rows may be inverted as normal text characters, so theoretical a total of 128
different 8-pixel rows can be used, practically less because most likely a
couple of rows will be duplicated.

As the interrupt based BIOS display procedre at 0038h does not support above, a
raw software based handler is used in most cases, that's why each line is
terminated by a RET rather than HALT opcode.

Video True Hi-Res Graphics
--------------------------

This mode produces a 256x192 pix graphics screen, and, unlike Pseudo Hi-Res, it
allows to set each pixel separately. The downside is that it does not work with
most external RAM Paks (memory expansions can be quite easily upgraded by using
two diodes and a resistor though, see chapter Hardware Modifications for
details).

However, it does work with internal RAM and with modified RAM Paks.
When using internal RAM, take care about these two limitiations: Only a small
picture will fit into 1K memory (so the display procedure must increase
horizontal and/or vertical blanking times), and external RAM must be
disconnected (as it'd otherwise disable internal RAM).

The true hi-res technique is used by the games Guus Flater, Starfight, and by
some demos such like WRX1K.

The general idea is to move the character set into RAM at 4000h..7FFFh by
setting I to 40..7Fh. Now this does NOT work as expected, ie. as
(I*100h+char*8+linecntr) as for text mode. Both the executed opcode (character
number) and the linecntr value are ignored. Instead, pixels are directly read
from memory at (IR). Each eight bits of each byte represent eight pixels. The
picture is defined in form of a common monochrome bitmap.

The bitmap data can be located anywhere in RAM, and as it is not 'executed' as
in other display modes, only raw data is required (ie. and no HALT or RET
opcodes need to be attached to each line). Note that only the lower seven bits
of the R register are incremented by the CPU; care should be taken that it does
not overflow within a line. For example, a bitmap of 256 pixels width (32
bytes) should be aligned to 32 in memory.

The main display procedure should load the MSB of the current bitmap line into
the I register, and the LSB into the A register, then jump to a dummy D_FILE
display procedure in memory with A15=HIGH. This dummy procedure should copy the
LSB from A into R register, and then execute a stream of 32 NOP opcodes (00h:
Bit 7 indicates not inverted output, Bit 6 disables blanking, data is directly
read from (IR), so that the character number in Bit 0-5 is ignored), and return
to the main procedure - which'd then issue some delays, prepare new address in
I and A and start over with the next line (using the same dummy procedure
again), until the whole screen has been displayed.
User avatar
RetroTechie
Posts: 379
Joined: Tue Nov 01, 2011 12:16 am
Location: Hengelo, NL
Contact:

Re: Hi-res graphics mode in the ZX81

Post by RetroTechie »

Welcome to this ZX80/81 forum, Ivanzx! :)

There's "true" hi-res, and "pseudo" hi-res.

In the case of pseudo hi-res, the patterns displayed on screen come from the ZX81 ROM. Depending on exact scheme, the programmer has some freedom in selecting which set(s) of pattern(s) from the ROM to use. Obvious choice will be those patterns that best match the program's desired graphics. Programs that use pseudo hi-res can often be recognized because some of the graphics look 'damaged' / slightly corrupted / 'off', even when you know the program has loaded correctly. Advantage is that pseudo hi-res works with unmodified ZX81's & RAM packs. So if that's all you've got & see it displaying hi-res graphics anyway, it will be a pseudo hi-res scheme.

With true hi-res, the patterns displayed on screen come from RAM. So in this case, programmer has more freedom to select (design) the graphics. Drawback is that true hi-res only works with internal RAM (factory 1K), or modified RAM packs.

There's many different hi-res schemes, and each will have its own limitations & memory requirements. But practically speaking: hi-res -> 16K RAM (or more) needed.

Several programs used pseudo hi-res early on. For example Forty Niner is (c) 1982. And IIRC I saw a 1K hi-res demo back in the day. Which would have been ~1984 at last, since that was when my dad got a ZX Spectrum & the ZX81 was shelved or sold. Therefore I kind of doubt that Wilf Righter was the first to demo it. Even a README from him says this:
The original WRX16 code was developed in 1986 by the author and was used as a core routine in several commercial programs for the ZX81.
So the technical possibility was known early on, but 1K + hi-res is such a severe limitation, that hardly anyone dared venture there. Until Dr. Beep in recent years... :ugeek:

The 1 thing to keep in mind is that the ZX81's screen generation is largely software based. Which means it takes a lot of CPU time. The flipside of the coin is that screen generation is very flexible.
RWAP
Posts: 1334
Joined: Thu May 08, 2008 8:42 am
Location: Stoke-on-Trent, UK
Contact:

Re: Hi-res graphics mode in the ZX81

Post by RWAP »

Steve McDonald posted the following comment on facebook (where a feed from this forum is repeated) and I thought it would be worthwhile repeating it on here:
Hi there. Agree with almost all of this posting. However, it may be wilf's read me file has been interpreted a little bit inacurately here.
Reason I mention this is back in 1987, after they had heard of my pseudo high res games rock crush and dans revenge (which used a similar scheme/driver to rocketman), I had some contact from Fred Nachbaur , Greg C Harder and others and was brought up to date on the Canadian /US scene at the time. The buzz at the time was wilf's WRX true high res core routine and a modified Hunter board called the SCRAM BOARD- an 8k static WRX compatible memory board that resided in the shadow rom area 8-16k in the memory map.
I was sent one of these great little boards made by Larken Electronics in Canada along with a lot of paperwork.
I still have all the vast documentation and magazine articles sent to me about all this - one day I shall scan them for everyone who is interested.

There were indeed a few commercial games that used the WRX core routine but the major point here is it was indeed Wilf who invented it and I was told by Fred that for example his game Dungeon Of Ymir that used the WRX CORE, also has a royalty payment attached to it for every sale. Point being these were licensed commercial games using wilf's core with his permission and paying a royalty fee for commercial use of it. Only right i suppose.

Just adding a few comments just to shed a bit more light on the quote in wilf's readme that's all.

Ps. I didn't realise until this month that true high resolution was possible without hardware on an factory 1k zx81 - amazing!
User avatar
1024MAK
Posts: 3258
Joined: Mon Sep 26, 2011 10:56 am
Location: Looking forward to summer in Somerset, UK...

Re: Hi-res graphics mode in the ZX81

Post by 1024MAK »

In hardware, the feature that allows software to generate hi-res graphics is the exact method(s) used to enable the RAM chip(s) [what hardware logic controls the chip enable / chip select and output enable pins for SRAM, or what hardware logic controls the /RAS and /CAS pins for DRAM). If the RAM is enabled for both normal CPU reads AND for the CPU DRAM refresh cycle, it is hi-res capable.

As produced from the factory, Sinclair 16k RAM packs are not hi-res capable. A simple modification soon changes that.

But modern RAM expansions are hi-res capable (ZXpand, Pokemon's expansion RAM) and the DIY internal RAM modification is hi-res capable.

Mark
User avatar
mrtinb
Posts: 1284
Joined: Fri Nov 06, 2015 5:44 pm
Location: Denmark
Contact:

Re: Hi-res graphics mode in the ZX81

Post by mrtinb »

dr beep wrote:There are several methods of hires. Most common is to create a screen somewhere in memory which is displayed with your own hiresdisplayroutine.
There are also hardware interfaces which give you place in memory where you can built UDG and use them as normal characters.
If I understand correctly - True Hires is either
  • a memory expansion with Hires capability,
  • a modified memory expansion, or
  • an internal modification.
And if I understand correctly - a Hires program will work on any of these.

But how about UDG? There seems to be
  • a UDG from dk'Tronics,
  • Quicksilva with support for UDG, and
  • custom boards with EPROM or RAM for UDG.
Are these UDG boards compatible?
Martin
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube
Post Reply