Need help reverse engineering Timex Store Demonstrator ROM file

[XavSnap]

HI,

Kicad project/Gerber files:
https://forum.abandonware.org/viewtopic ... 758#p38758

Have fun...

[jipock]

The link appears to be broken.

[XavSnap]

Hi jipock,

May be your VPN, try the FTP directory (Kicad minor updated files 11/03/2022 - Issue 1.0):
http://zx81.ordi5.free.fr/CartesZx81/Ti ... onstrator/

Have fun.

[dessony]

XavSnap,

Good job creating a certain folder. However, where is a bill of material (parts listing) for the Timex Demonstrator ROM?

Thank you very much in advance.

Cheers,
DesSony

[XavSnap]

Hi DesSony,

Just have a look to the wiring diagram to get proper components values.

Note: D1= 1N4148 or equ.

[David G]

Back in 82 or so, Timex made a merchandising kiosk that retailers could purchase. It included a TS1000 and a demonstration program on EPROM. You can watch the demo program on YouTube.

A year or so later, one could purchase just the EPROM demonstrator module from E. Arthur Brown.

This is fascinating. Back in the day, i had no idea what Timex was doing as I had an actual ZX81 purchased mail order from New York. It wasn't until I started seeing newspaper circular ads for the Timex/Sinclair 1000 for $40 that i paid any attention

I wonder why they did this in a custom ROM? As everything in the program would appear to work on standard hardware

... a BASIC program with machine code embedded in REM statements.

A couple of folks in the US and Portugal have tried to turn it into something that can load/run on an emulator but not with much success....

Help?

Here's my first take on disassembling StoreDemo.p. This ASM file compiles into an exact byte-for-byte copy of the original P file

StoreDemo_original.asm

BASIC and Machine language source file for ZX81-IDE

(17.52 KiB) Downloaded 275 times

I notice that the machine language routines store its variables in the regular BASIC space, so when loading on standard hardware, it overwrites itself causing crash. Basically it's the first thing it does

So instead of RUN, type GOTO 500 to see one of the animations

screenshot

[David G]

The StoreDemo BASIC program can be made to run on standard hardware, so I was thinking of why it was put into a ROM package. This is my speculation:

* no need for a cassette tape to load the program
* no need for RAM packs
This make it fairly easy for a store manager to set up. If the power goes out, the program is still in ROM. Just start it back up.


About RAM usage, the program needs less than 1K RAM for the display file. And it needs RAM for the BASIC variables, the stack and other WORKSPACE use. I'm sure it will run with the standard built-in 2K that all Timex/Sinclair TS1000 had

The BASIC program is about 7K but that's in ROM. Maybe it would even work with 1K machines? Just plug the ROM into a ZX81?


The reason it crashes when RUN is:

* designed for residence in the DEMO ROM address in the $2000 block, so all the Machine Code routines are there. The BASIC program makes USR calls, so it will call into some unknown code when RUN on standard hardware. CRASH

* the program uses space where BASIC program normally resides

The first is USR 8322 which sets up a new DFILE (display file) in RAM. In the space where StoreDemo.p is loaded on standard hardware. If you change the USR 8322 to USR 16514, the M/L code will then run, but will immediately overwrite itself. CRASH

Next, the M/L variables -- including those set by POKE statements -- are in RAM, overwriting part of the normal program area


To get StoreDemo.p to run without the DEMO ROM:

• Use a 16K rampack

• REM out the USR 8322 line. This is for creating a new DFILE (display file) in RAM, and isn't needed with a program loaded into RAM. After this, the program will RUN and do the first animation, but later crash

• Update all the USR statements. Add $2000 to each address, which is the difference between the DEMO ROM (address $2000) and the standard machine (address $4000)

• The M/L code uses relative jumps, so only need to update the few CD (call) lines

• The M/L variables need to be moved. Since there is a lot of zeros at the end of each REM, pick one. Update all references to these (these are addresses $407D-$408E). Also update the POKE statements to match

So basically, anything that references $2000-$3FFF (8192-16383) needs to be changed. In both the machine code and the BASIC program

[XavSnap]

Hi,

In the "SHUTTLE" display...
Line REM#11: Some buffered values erase the thirst basic line header.

Code: Select all

	     LD      BC,(407FH)
	     ADC     HL,BC
	     LD      A,(4081H)
	     LD      (4089H),HL
	     LD      HL,(4083H)
	     LD      (4087H),HL
	     LD      HL,(4085H)
	     LD      (408BH),HL
  

And in the line#13 ... again.(call the line #11)

Code: Select all

	     LD      HL,00D5H
	     LD      (407FH),HL
	     LD      HL,0009H
	     LD      (4081H),HL
	     LD      HL,267CH
	     LD      (4083H),HL
	     LD      HL,0002H
	     LD      (4085H),HL

We had to move this values in the printer_buffer @ 403DH,403FH...
the address up to 4082H erase the first routine.

I have already tried to change them, but all routines are in different REMs.
The better way to change this buffer bytes is to make a single REM to change all illegals offsets.

STORE.P

(9.3 KiB) Downloaded 238 times

[David G]

Yes a single REM is more efficient. And then can also get rid of all the extra space in each REM, which is currently hundreds of bytes. Difficult to do without special tools, but somewhat easy with a PC-based assembler

I've been working for a while on ZX81-resident tool to combine REM statements, to generate REM statements on demand, and to move a line from one program to another


Anyways, here are some screenshots from StoreDemo

BIGPRINT.jpg (4.41 KiB) Viewed 3989 times

POWER1.jpg (5.74 KiB) Viewed 3989 times

MATH GAMES1

Another example of BIGPRINT

[David G]

(looks like there is some kind of limit to Attach Files?)

StoreDemo follows the ZX81 standard of 22 screen lines + 2 edit lines (24 lines total). A lot of machine language programs will use the whole 24 lines, but the SHUTTLE animation only uses 22 lines

SHUTTLE1.jpg (2.86 KiB) Viewed 3966 times

SHUTTLE2.jpg (3.23 KiB) Viewed 3966 times

SHUTTLE3.jpg (2.93 KiB) Viewed 3966 times

CHART.jpg (10.98 KiB) Viewed 3966 times

POWER2.jpg (11.44 KiB) Viewed 3966 times