Hi-res graphics mode in the ZX81

[1024MAK]

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.

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

[mrtinb]

I meant:

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.

[dr beep]

I meant:

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]

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.

[WayneM]

Hi Guys. Sorry to come in late, but just to let you know, the dccnet links to the hires and display explanations no longer work.

I also have some ideas for new hires and color graphics I wanted to share with you and ask you about?

I had an interest in kickstarting a community effort to make a new retro game console computer version of the zx81 with simple circuit additions, to show what could have been manufactured at that time. A design that could even had been done years before at the time of the Atari VCS introduction. New simple graphics and sound with multi resolution tiling techniques, and display list and vectors, and 80 column hires support. A low cost game card technique and wireless IO that could be used with controllers. Then shrink the circuit to watch size. But, unfortunately I've been too sick, and have to limit the commercial ventures to another second phase retro design. However, I have a few simple ideas that might be applied to an existing zx81. There are a lot of knowledgeable people here, so I thought I would share them:

These use the ability to only draw little bits of the screen in 1k. They also come from my interest in modding the Atari 2600.


Simple colour:

Using the composite output, a simple circuit to interpret every two pixels as one of 4 colours, and lay in a chroma dude band onto the signal. Could be entirely analogue. I hate these ultra low resolution modes (128 pixels accross, but 160 is possible). But, it might be possible to insert signaling in the line that turns it on or off, sets up a 4 colour pallet out of 256 colours, and change the pallets during horizontal sync, even in line, with the circuit filtering out all such signaling before passing it to a TV. There is also hold and modify techniques, like the Commodore Amiga 4096 colour mode tried. The ability to do colourful game characters.

Simple colour 2:

The circuit could be enhanced to produce all video timing, leaving the zx81 with more CPU, and only to briefly signal the circuit it is ready to start a line or frame. Then the zx81 only has to time to drop in the graphics at the right time (see the software blitter and sprite section). I remember the Commodore Amiga TV modulator might have used some simple little timing chip worth checking out.

The following modes are suitable for vector graphics, particularly 512+ pixel modes. For vector graphics some anti-alaising blur could be added to the circuit to reduce the rough staircasing affect. Even in simple mode, using a vector command mode, with a delayed output, the outline of the pixels next too the hires pixel can be averaged and blurred. The interlaced pixels above and below the programmer could issue blur pixels.


Simple colour 3:
8 and 16 colour.

This will work on American Television, but is more for PAL. This is from ideas from my Commodore 64 days. An interlaced frame on TV is made out of two fields. You could change the colour for the whole screen by one colour at a time, so that each interlaced field renders a seperate colour, rolling back to the first colour after the last colour. You can make red green and blue primary colours, rolling where each colour last appeared, which should help with flicker. But, on PAL TV's, there is an interlace line buffer, and when both lines are the same intensity and difference colours, the two lines adopt the same colour without flicker. As this would use the same intensity monochrome output, then 8 colour hires is possible with less flicker. On a complex circuit you could have a frame buffer and pallet, and interpret the monochrome as solid colour pixels in a new frame, in the buffer. But, I favour the very simple plug into the tv output and play circuit.

Using the 4 colour pixel mode, or hold and modify mode, simple colour 2 can produce 16 or more colours using two alternating fields.

The control info can be hidden in the start of each horizontal line, reducing the screen size a bit, after the circuit filters that out. But, apparently 320 pixels accross is possible, so plenty of space to hide it. Otherwise for hidden signaling in the frame, you would have to be check to see if there are circuit features which could do it.

Some sound:

Artificial signaling on the video signal, is interpreted as frequency sound by the simple colour circuit and filtered out, but producing a sound signal from the information.

Complex Colour:

A frame buffer could be set up to interpret each interlaced field as a horizontal pixels. This would give 512-640 pixels accross by 192+ pixels high. In this, the rolling interlace field colours, and hold and modify, modes can be transformed into solid graphics on the buffer. A 128 by 96 256+ colour mode could be made, with 256+ pixel horizontal 16 colour pixel objects mixed in, and more complex scenes constructed and held in the buffer. A hold and modify scene mode, could use transparent pixels to hold the scene value and active pixels to flip value. However, as the buffer can now do automatic timing of the signal, data and signaling from the video port is no longer strictly needed. A off or on pixel can be a pure write, or one of them flips and the other issues commands, like pallet. The program only needs to time when it writes through its update, or issue a command to update the current buffer to screen, eliminating timing (like how some TV's and Monitor's buffers now support). The processing on the zx81 is then nearly 100% free for programs.

Scrolling:

Scrolling becomes possible on a complex system, but also on a simple system with a time delay circuit. By moving by the half pixel, on the simple colour circuit we can implement a pseudo 512+ pixel mode, with pixels shifted half a pixel accross the next screen. It would be messy, but would work enough. With enough memory, this gives word processing (sorry forgot about membrane keyboard for a moment) and 80 column text and graphics adventure capability. Speaking of keyboards, has anybody ever tried a thin keyboard that sticks on the top of the existing keyboard, and a USB 1.1-12 mb/s port for that, controllers and USB stick storage, through the expansion port?

The simple, or complex circuit, could be used with any computer, and do graphics. It is treating the TV out, as a high speed IO interface.


Is software blitter or sprites doable?:

Obviously, especially for the simple colour, it's not possible to do a full screen of complex graphics, unless you do some time based design or repeating graphics, on a 1KB system. But, this was not about that, but to have a number of little objects and some features. Not Sonic the hedgehog, but more like joust, Pacman, grid runner or maybe defender, with smooth moving hires graphics. These things can already be done with character based tiling, but being able to move by the pixel instead.

I forget the z80 from years ago. Does it have a facility to use multiple registers to add shifted bytes together, then output that data to the video section? Ideally, if 24 bits of registers could be aligned, then shifted object data could be overlaid, constructing three bytes at a time as a rolling buffer, with the current byte being written shifting between them in a rolling fashion.once the last byte is rendered, the first byte becomes the next byte and receives overlapping data. The data only needs to be prepared before it writes to the screen, then outputted. Or stored and outputted latter, as it is preparing the next objects. A software blitter. But, whatever way it can be done.

Incase memory expansion and upgrades?

Has anybody ever developed a large memory expansion daughter board that goes in a chip socket (with the chip piggybacked on it), bank switchable ROMs or replacing the main chip with something supporting hires graphics, modes, blitter?, sound and colour? There seems to be a lot of socketed chips in some of these systems.

Anyway, after reading what's been said here, that's my take on enhancing the zx81 into a little programmable games console. I frankly believe infrared controllers, printable organic electronic game rom cartridges, and a dark rainbow metallic like horizontal stripped case with keyboard would be interesting.

Imagine what the Spectrum people could do?

But, this is about making it play early 1980's games well. Like the later spectrum could, but with no colour clash. I actually like the style of some of the chroma 81 coloured games, and you could do that sort of look on the simple one, even with some cool gradient coloured striping on objects, and 256-512 colour gradient coloured background.

Thanks.

[hsjinst]

here is a copy of a simple program i wrote back in 1984.
it uses Nissim Elmaleh's sw-hi-res routines
I was able to transfer it from a tape I had.
I am still working on the original Demo from Nissim.
its machine code in the first REM statements.
you can list from line 2 to get the calls for the various graphics routines.
after it starts with a RUN command, it builds a graphic workspace in REM line 3.
you can edit from line 10 on, but need to save it before running, you can't go back after a break or end.