Demo of XTRICATOR Pseudo-UDG driver

[David G]

192x256 display.
Runs on a stock, unmodified ZX81 with regular 16K RAM pack and produces 192x256 display. The same resolution as a standard BASIC program, but this one lets you change pixels line-by-line and not just by changes by character, as with standard graphics

As far as I'm aware only one program has ever used escher's brilliant Pseudo-UDG display routine: 1986 Z-Xtricator. And this even though Wilf Rigter explained it 30 years ago! Fruitcake's 2016 ZX81 Celebration seems to have been partly based on the XTRICATOR driver but it seems it is using the Lightning(?) driver


ADVANTAGES
XTRICATOR has these advantages over other pseudo-hires drivers:

• Pixel-perfect hi-res graphics

• Perfect fonts in hi-res mode. Uses the standard ZX81 fonts right in hi-res screens!

• Jumps in and out of hi-res seamlessly

DEMO PROGRAM
This demonstration program is for the XTRICATOR driver

improvement
* shows how to work on 50hz and 60hz machines without TV display rolling

demo of possibilities
* moving line demonstrates smooth scrolling
* sprite (6 lines high) can go up to the top line without a gap

potential game engine
* The accompanying Assembly file builds a bare-bones playfield and lets you move a ship up/down. The ship is the same sprite used in Z-Xtricator

The main weakness may be in vertical lines. The Z-Xtricator game used horizontal lines and three angles of pixel-perfect diagonal lines, but no vertical lines. Of course with its ability to mix standard characters with pseudo-HRG characters you can always use the standard block character-lines like CHR$ 5 and CHR$ 133. Using 'I' you can get 6-pixels vertical ...is it possible to draw vertical lines?

[David G]

Assembly files to assemble the machine language as well as the BASIC lines


SJ ASSEMBLERS
=============
The open source cross-platform Z80 assemblers that support Spectrum/ZX81 development

SJASMPLUS v1.20.3 build command: sjasmplus demo_sj.asm --raw=demo.p
SJASM v0.39j build command: sjasm demo_sj.asm demo.p

GET SJASMPLUS AT https://github.com/z00m128/sjasmplus
Sjasmplus is based on Sjasm, however when developing code it gives much helpful output than Sjasm

GET SJASM AT https://github.com/Konamiman/Sjasm
sjasm v0.42 hangs if something is wrong with the file. USE LATEST VERSION (v0.39j as of 2024 November)


ZX-IDE
======
ZX-IDE for Windows supports plain-text BASIC lines and ZX81 text strings as well as displays the ZX81 character set. For this reason I find the assembly file to be more informative and vastly easier to modify the code. Plus F9 sends the program out to your ZX81 through an audio cable. F8 key builds the file and launches the EightyOne emulator

GET ZX-IDE 1.71.01v at forum.tlienhard.com: ZX-IDE
TUTORIAL at sinclairzxworld.com


PASMO
=====
Pasmo for unknown reason stops on the SJ file:

Code: Select all

pasmo demo_sj.asm demo.p
ERROR on line 54 of file demo_sj.asm
ERROR: Inavlid numeric format

This, even though Pasmo and Sjasm both assemble the same Hello World example with no problems

[David G]

Another advantage of XTRICATOR is the program based on it doesn't take any space for the display. The 6K HFILE display file is generated at runtime, so it doesn't take space on the tape. This results in faster loading than other pseudo-HRG programs

For example, Z-Xtricator is only 7K on tape. But the corporate splash screen (side 2 of the cassette) is 9K and all it does is display a static picture! James talks about this:

the only "improvements" [Software Farm] asked for was adding a screen to choose which keys are used for controls (good) and adding in a huge loading screen with the cosmic cockerel (bad). This later demand was ridiculous since it took twice as long to load the screen as the actual game, and I had to use their old hi-res routine since my routine didn't enable the cockerel to be displayed the same way - so after several minutes loading that screen, once you press a key the 6K display file and old hi-res routine are dumped and the game switches over to Z-Xtricator and the more economical IM2 routine.

SETUP
=====
It's easy to set up. The XTRICATOR routine is self-contained in REM 1. Then your game:

Code: Select all

CALL    $40B8                   ;BUILD_HFILE in XTRICATOR routine  
CALL    $40AA                   ;ENABLE_IM2  in XTRICATOR routine 

DRAWING
======== 
Next to draw something on the screen. Demo has a subroutine to set up a basic playfield:

Code: Select all

CALL    SCREEN0

To draw a single character on the HFILE, demo has a routine called H-draw_Character:

Code: Select all

LD      A,$21                   ;'5'  _5
call    HdrwCHR

HdrwCHR puts '5' in HFILE for each of the 8 scanlines at the position give in HL

Strings of characters are done in a similar way (copy each string to HFILE 8 times)


HFILE Screen Locations
====================
All you need to know is what Row and Column you want. Then let the assembler figure out the exact address

If you want to put a standard character on the screen, use this in your code

Code: Select all

LD      HL,HFILE+3+22*HLINE+2   ;Row 22 Column 2
LD      A,$21                   ;'5'  _5
call    HdrwCHR 

UDG
====
To draw pseudo-UDG characters instead of standard characters is just a matter of changing the CHR on each scanline. The ship is a 3-byte-wide sprite:

spriteSHIP.png (11.18 KiB) Viewed 8447 times

Code: Select all

;bit-patterns                 bytes
;00000000 00000000 00000000   00 00 00  '                        ' 0 scan line
;00000000 00000000 00000000   00 00 00  '                        ' 1
;00001111 11110000 00000000   0F F0 00  '    ±±±±±±±±            ' 2
;01111100 00011000 00000000   7A 0A 00  ' ±±±±±     ±±           ' 3
;11111111 11111111 11110000   FF FF F0  '±±±±±±±±±±±±±±±±±±±±    ' 4
;11111111 11111111 11110000   FF FF F0  '±±±±±±±±±±±±±±±±±±±±    ' 5
;11111111 11111111 00000000   FF FF 00  '±±±±±±±±±±±±±±±±        ' 6
;00001111 11111111 00000000   0F FF 00  '    ±±±±±±±±±±±±        ' 7

Search for those bit patterns in CHR table in the ROM starting at $1E00 (not all bit patterns are in the standard character set ... but these are)

Those bytes belong to these CHR

Code: Select all

db $00,$00,$00
db $00,$00,$00
db $02,$01,$00
db $2A,$3D,$00
db $80,$80,$04
db $80,$80,$04
db $80,$80,$00
db $87,$80,$00

FASM_Z80.zip (ZX81rom.asm) has the ROM disassembly in searchable form (thanks PokeMon!). Then you can search for the bit pattern. If it is found, you can use that CHR

Code: Select all

; ------------------------
; THE 'ZX81 CHARACTER SET'
; ------------------------
...
L1E00:
...
; $01 - Character: mosaic       CHR$(1)

        DEFB    %11110000
        DEFB    %11110000
        DEFB    %11110000
        DEFB    %11110000
        DEFB    %00000000
        DEFB    %00000000
        DEFB    %00000000
        DEFB    %00000000

For the bit-pattern 11110000, it is found in several characters including 01 and 04. Note that it is used in the display (standard display or HRG) on a scanline basis, so the sprites can use different CHR mix-and-match

[siggi]

Hi David
meanwhile I do not have "a stock, unmodified ZX81 with regular 16K RAM pack", but 56K/64K Zeddies
But then XTRICATOR does not run on my machines, because the "ghost DFILE" in 48K region (which is in my Zeddies remapped to the real DFILE at 16K during /M1=LOW) contains multi-byte opcodes, where the 2nd and 3rd byte is taken from 48K region (/M1 is not LOW for them).
The usual "solution" for Dr Beeps games (which use a similar DFILE) is, to copy the whole program to 48K to have the correct 2nd and 3rd byte there..

Would this also work for XTRICATOR? Or are the 2nd and 3rd byte of the opcodes modified at runtime, so making a copy of them prior to the start of the program does not help.

Would it be possible to make a copy of the DFILE at runtime? How?

Thanks
Siggi

[David G]

hmm ... an interesting problem. never used a ZX81 with more than 32K RAM


When you say 2nd or 3rd byte, are you referring to the opcodes in the Hires Display File? (HFILE is my nickname for it)

XTRICATOR creates the HFILE at runtime, within the 16-32K block. After it is created, the three opcodes at the beginning of each line of HFILE are not modified. I tried it in the EightyOne emulator and it doesn't work at C500. Although the on-screen messages appear in memory, the three opcodes are missing


there is one thing I do not understand about the XTRICATOR routine: the HFILE is at $6500 (in the upper half of 16-32K block) but the display routine Jumps to $E500. I assume this is a shadow of 6500 as it is exactly 8000 higher. and is within the 32K-48K block where no actual RAM is there ...


Wilf's comments

POP HL ;HL = E500
...
JP (HL) ;jump to 6500 above 32K

The routine does seem to be executing code there. The code at 6500/E500 is:

Code: Select all

CD9640

And indeed, execution transfers to $4096 as seen with the debugger. It has been my understanding that any opcodes above 8000 will not execute without the M1NOT circuit modification, but there it is

[siggi]

there is one thing I do not understand about the XTRICATOR routine: the HFILE is at $6500 (in the upper half of 16-32K block) but the display routine Jumps to $E500. I assume this is a shadow of 6500 as it is exactly 8000 higher. and is within the 32K-48K block where no actual RAM is there ...


Wilf's comments

POP HL ;HL = E500
...
JP (HL) ;jump to 6500 above 32K

The routine does seem to be executing code there. The code at 6500/E500 is:

Code: Select all

CD9640

And indeed, execution transfers to $4096 as seen with the debugger. It has been my understanding that any opcodes above 8000 will not execute without the M1NOT circuit modification, but there it is

There is the copy of the 16-32K ram region (due to inclomplete address decoding of ram of a 16K Zeddy)!
Then the code equal to the code at 16-32K is executed (despite A15 is set), but ULA then (while opcodes are read from address having A15=1) replaces opcodes having bit 6 reset by opcode NOP. Only opcodes having bit 6 set (like HALT or CALL) are executed as usual.

Due to a complete address decoding of ram in my Zeddies, the upper ram (48-64K) is NOT a copy of the lower ram(16-32K). The ram decoder logic remaps the upper ram to lower ram only during M1=LOW. This allows a display as ususal during normal lowres display, because the lowres DFILE contains only single byte opcodes (HALT), being remapped during opcode fetch to lower ram.
But if multi-byte opcodes are in DFILE (like CALL xx), then only CALL (CD) is read from low ram during opcode fetch, but XX is read from upper ram (because M1 is HIGH).

Siggi

[David G]

ULA then (while opcodes are read from address having A15=1) replaces opcodes having bit 6 reset by opcode NOP. Only opcodes having bit 6 set (like HALT or CALL) are executed as usual.

Thank you for the explanation, i was not aware of this

i think BIT 6 opcodes are any in these two ranges:
70-7F which includes all LD reg,reg LD, (HL),reg, LD reg,(HL) and HALT
C0-FF many, many opcodes including JPs CALLs RETs

As an aside, I wonder what kind of a machine code program can be coded to run from just these opcodes ...

Due to a complete address decoding of ram in my Zeddies, the upper ram (48-64K) is NOT a copy of the lower ram(16-32K). The ram decoder logic remaps the upper ram to lower ram only during M1=LOW. This allows a display as ususal during normal lowres display, because the lowres DFILE contains only single byte opcodes (HALT), being remapped during opcode fetch to lower ram.
But if multi-byte opcodes are in DFILE (like CALL xx), then only CALL (CD) is read from low ram during opcode fetch, but XX is read from upper ram (because M1 is HIGH).

So if we create two copies of HFILE, one at C500 and another actual copy at E500, will it display on your Zeddies?

[David G]

The demo runs fine on the emulator ZesarUX 11 beta 1

I have uploaded a new Beta version of ZEsarUX, 11.1 Beta 1.

You can download compiled versions for Mac and Windows from:

https://github.com/chernandezba/zesarux ... 11.1-Beta1

This was my first time trying ZesarUX and i am impressed. It has what I suppose is a ZX Spectrum-like interface but with a full window system with menus. Never fear though, it emulates the ZX81 and supports keyboard navigation of the menus -- no mouse needed

I tested the ZX81 "machine" setting using ZesarUX for Windows

Install ZesarUX
Run ZesarUX
press F5 to bring up the main menu (or click the middle of the ZesarUX screen)
select Machine/Sinclair Research/ZX81
The machine reboots and we are greeted with the familiar K prompt

To quit ZesarUX:
* press F5 then F10
or
* click the middle of the ZesarUX screen to bring up the main menu then click Exit
or
* click the X in the ZesarUX window


To load a program
F5/click the middle of the ZesarUX screen to bring up the main menu
select Smart load
navigate to a P file and select it


Now demo.p (pseudo-HRG demonstration) ran fine, but with a blank display

from the ZEsarUX FAQ:

ZX-80 & ZX-81
-------------

Q: My ZX80 or ZX81 game uses hi-res resolution but ZEsarUX does not show the display well.
A: Enable Real Video Setting. Real Video is a feature that uses a bit more cpu from your machine but displays the emulated machine as it should.

F5/menu
settings/display
select Real Video

To my surprise, it runs DEMO.P with no horizontal shifting of the display -- It fits within the standard borders of the emulated display. The picture is not offset to the left as in EightyOne

Next surprise: it is running at 50hz (as expected), but i could find no setting within ZEsarUX for a 60hz display to match my kit-built ZX81 which is configured for 60hz

DEMO.P does not run with 32K RAM in ZEsarUX:
Menu/Settings/Hardware/Memory Settings
ZX80/81 16K RAM in 8000H
But it runs fine with standard 16K


All in all, ZEsarUX is a nice ZX81 emulator which runs every program i tried

[siggi]

So if we create two copies of HFILE, one at C500 and another actual copy at E500, will it display on your Zeddies?

I think, that would solve the problem, if the COPY of HFILE is also updated, whenever a multi-byte opcode (consisting of 2 or 3 or 4 bytes) is changed in HFILE during runtime. This update in COPY must not be interrupted, otherwise an invalid opcode will be executed!

[David G]

Very good

This is working in EightyOne and ZEsarUX emulators, please let us know if it works on your hardware

instead of

Code: Select all

CALL    L40B8                   ;BUILD_HFILE in XTRICATOR routine
CALL    L40AA                   ;ENABLE_IM2  in XTRICATOR routine

it is modifed to

Code: Select all

CALL    L40B8                   ;BUILD_HFILE in XTRICATOR routine
LD      HL,$E500                ;for 48K machines: Build a second HFILE in actual RAM
CALL    L40B8+3                ;                                  
CALL    L40AA                   ;ENABLE_IM2  in XTRICATOR routine

As a plus, it still works on 16K