Hi-res graphics mode in the ZX81

Discussions about Sinclair ZX80 and ZX81 Hardware
User avatar
1024MAK
Posts: 3163
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 »

mrtinb wrote:If I understand correctly - True Hires is either
  • a memory expansion with Hires capability,
  • a modified memory expansion, or
  • an internal modification.
The first two are correct, but no modification is needed to have hi-res on the internal 1k (2k) bytes of SRAM. The modification, is to remove the originally fitted SRAM and replace it with a 32k byte SRAM (either fully used, or half used to give 16k bytes). The 16k byte modification is hi-res compatable. The 32k byte SRAM will be if done correctly.
mrtinb wrote: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?
I'm not sure. UDG are less common, as they require the ZX81/TS1000 to be internally modified.

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

Re: Hi-res graphics mode in the ZX81

Post by mrtinb »

I meant:
1024MAK wrote:
mrtinb wrote:If I understand correctly - True Hires is either
  • a memory expansion with Hires capability,
  • a modified memory expansion, or
  • an internal modification addition of RAM circuits.
Martin
ZX81, Lambda 8300, Commodore 64, Mac G4 Cube
dr beep
Posts: 1296
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Hi-res graphics mode in the ZX81

Post by dr beep »

mrtinb wrote:I meant:
1024MAK wrote:
mrtinb wrote:If I understand correctly - True Hires is either
  • a memory expansion with Hires capability,
  • a modified memory expansion, or
  • an internal modification addition of RAM circuits.
Hires needs the amount of memory needed for the screen which sets the hires.
The size of the screen is adjustable, but most common is a screen of 32x192=6144 bytes with the displayroutine to it.
Where the needed memory is located is irrelevant for the computer, but the memory must be able to read the hiresdata.
This is indeed done with the above methods, although I wouldn't alter the internal memory of the machine.

In fact for the software it doesn't matter where/how the memory is arranged. It only needs to be accessible.
The ZX18 has 1K RAM and the TS1000 has 2K RAM inside, so on a TS1000 you could code games with larger hiresscreens without needing a memorypack.

My very first game in hires for the ZX81 used a 32x192 screen, but it worked a bit like a ZX Spectrum.
The game was originally written for the ZX Spectrum where all printing was done by RST 10 and the charactercode in A.
This register held the standard characterset or UDG.

For the game on the ZX81 I only altered the relevant parts of printing and reading the keyboard. Game itself remained as it was. The printing was simply altered in a routine that printed a character from the ROM (ASCII-code31 to 128) or a UDG (ASCII 144>) on the hiresscreen by calculating the startposition and then add 32 for the next line.

Unlike the ZX Spectrum all lines in hires are in order and not by a step 256.
So the game is true hires, although the display is done like UDG on PRINT AT positions.

Your 32x192 screen must start at a number of 32. The only reason for this is that during display the R-register won't go from 127 to 128, but back to 0 and thus displaying a false line of data. When your screen uses other dimensions yu must make sure that ANY line will end #7F or #FF. A screen 16x192 can start on any number of 16.

As for 1K Hires.
1K Hires is only possible with either a small sized screen or a displaymethod that unpacks a compressed screen during display. For each game you need to determine how you will store the screen and code a unpacking displayroutine.

It all started with a small sized screen that 'walked' over the screen and thus showing the parts of a maze where you were. After that all kinds of compression are worked out to make fullsized/halfsized/pixelmovement/charactermovement possible in games fitting 1K.

Best way to start (well that's what I did):
Use a method as described by the pages of Wilf Rigter. Even better, use the setting of IX. Other methods might have problems with modern interfaces (I had to alter my 1K games, now default set of IX).
Use the displayroutine mentioned there and code a simple display. I.e. a continuous counter from 0 to 255 on the first and last cell of the screen and let it run.

When running, you can alter as much as you like. Don't alter the hires screen display. Adding text is possible in lowres before or after the screen. On the screen you could use my PRINT AT from Shogun. Source can be shared.
With the PRINT AT you could also define your own characterset. Instead of pointing to ROM you could point to your own defined characterset.

As for 1K hires routines:
the games and sources can be found in the newgames-section.
dr beep
Posts: 1296
Joined: Thu Jun 16, 2011 8:35 am
Location: Boxmeer

Re: Hi-res graphics mode in the ZX81

Post by dr beep »

RetroTechie wrote: 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.
And yet, in all my 1K games I added framedelays to make the games playable, otherwise the games would run too fast. Only game that has some sort of short in time is MARBLE RACER where the calculation of the correct screenaddress takes 2 intrupts at the bottom making the marble flicker a bit at the bottom.

In the beginning I really thought that the amount of time would make the games less playable, but it is surprisingly fast.
I never use the setting of FAST in my code. Even "the mist of time" in my 2D Monster Maze is just a (few) second(s).

So my advice : as long as you are coding in MC don't get bothered by the speed of the CPU.
Post Reply