Steve Davis Snooker on Super Gold Card

[DanDoore]

I have aquired a copy of Steve Davies Snooker on Microdrive cart and it works on my QL (Issue 5 JM ROM), which is good.

However, if I even look funny at carts they tend to give up on me, so I have copied it to floppy am trying to get it to work.

I have an Tetriod Super Gold Card and ROM switcher (currently Minerva 1.98, TK 2.23) so I can fiddle with ROM images

The original boot was this:

Code: Select all

100 a=RESPR(76*1024): b=184320
110 a=RESPR(512): IF a>=b THEN GO TO 110
120 a=196608: c=204800: d=245760: e=212992
130 MODE 8: PAPER 0: CLS: CLS #0
140 LBYTES mdv1_p1,131072
150 LBYTES mdv1_p2,b
160 LBYTES mdv1_p3,a
170 LBYTES mdv1_p4,c
180 LBYTES mdv1_p5,e
190 LBYTES mdv1_p6,d
200 CALL d

The code sizes are:

Code: Select all

Bytes  File
------------
229 boot
25,600 p1
11,008 p2
5,114 p3
2,726 p4
2,294 p5
5,264 p6

So I changed the mdv for flp and it fails to run getting itself into a loop at line 110 until it runs out of memory.

I'll admit first that I don't fully know what that code is doing, presumably trying to allocate space somehow as per https://superbasic-manual.readthedocs.i ... respr.html but after that it then ignores that returned value by setting a to 196608 anyway

Taking that out lets it load and runs under QemuLator happily (4Mb RAM, Minerva 1.98, TK2) with this:

Code: Select all

100 a=196608: b=184320 : c=204800: d=245760: e=212992
110 MODE 8: PAPER 0: CLS: CLS #0
120 LBYTES flp1_p1,131072
130 LBYTES flp1_p2,b
140 LBYTES flp1_p3,a
150 LBYTES flp1_p4,c
160 LBYTES flp1_p5,e
170 LBYTES flp1_p6,d
180 CALL d

..but not on the Super Gold Card in my QL, that locks solid when:

1. Toolkit is not loaded - locks on initial game screen
2. Toolkit is loaded - locks either when starting the demo game in attract mode or when trying to start a game.
3. Toolkit is loaded - going into setup shot and then trying to play with F2 locks when trying to set spin

I've tried disabling cache, loading JM rom with toolkit, with no toolkit, enabling toolkit via tk2_ext/auto_tkf1 on the SGC but there is too much I don't understand at this point: It it playing nasty with memory? Self modifying code - or is it just plain incompatible?

Any pointers very welcome...

[tofro]

A lot of earlier games that didn't account for future extensions do this:

The code apparently is position-dependant, for a fixed load address - that it tries to reach by allocating half-kB-chunks from top down (which can take a while on a SGC...).

The system on the SGC-fitted QL, however, allocates memory for buffers and other administration for additional devices from bottom up, so occupies the desired load address of the program already, so the loop never reaches far enough "down" to reserve memory from that address onwards.

There's not much you can do here - You could, if you're desperate enough, try the following, though:

REMark out all the RESPR stuff and forcibly try and load to the fixed (already occupied) adresses (maybe it makes sense to re-sort the loading to load the highest address (e) first, then downwards, to keep the system operative as long as possible).

If you're lucky, he system stays alive long enough to be able to run the program.

If that still doesn't work, you can try not accessing devices during the load process - That would look a bit like the below:

Code: Select all

100 a1 = RESPR (<length of p3>)
101 b1 = RESPR (<length of p2>)
102 c1 = RESPR (<length of p4>)
103 e1 = RESPR (<length of p5>)
120 a=196608: c=204800: d=245760: e=212992
130 MODE 8: PAPER 0: CLS: CLS #0
140 LBYTES mdv1_p1,131072
150 LBYTES mdv1_p2,b1
160 LBYTES mdv1_p3,a1
170 LBYTES mdv1_p4,c1
180 LBYTES mdv1_p5,e1
190 LBYTES mdv1_p6,d1
191 MOVE_MEM (b1, b, <lenght of p2>)
192 MOVE_MEM (a1, a, <length of p3>)
193 MOVE_MEM (c1, c, <length of p4>)
194 MOVE_MEM (e1, e, <length of p5>)
200 CALL d
210 DEFine PROCedure MOVE_MEM (s, d, l)
220 LOCal i
230 FOR i = s TO s + l STEP 4
240   POKE_L (d + i, PEEK_L(s + i))
250 END FOR i
260 RETurn 

As you might see, the program loads the chunks of code first to "legally" allocated areas in high memory, then copies them down to their desired load addresses and runs them there. This will make the system non-operable as well, but I'd expect it would stay alive enugh to run the game.

[RalfR]

For "MOVE_MEM" he should load DJToolkit 1.16 previously.

http://www.dilwyn.me.uk/tk/djtk.zip

[NormanDunbar]

A vastly underrated toolkit if you ask me.

[tofro]

Probably a bit hefty to ask to load a toolkit for a BOOT program.

If you guys would read the whole code, you'd see it isn't even necessary.

[RalfR]

A vastly underrated toolkit if you ask me.

Quite right

[DanDoore]

As you might see, the program loads the chunks of code first to "legally" allocated areas in high memory, then copies them down to their desired load addresses and runs them there. This will make the system non-operable as well, but I'd expect it would stay alive enugh to run the game.

Many thanks for this, the RESPR bit makes sense now as it's allocating top down on the memory map

I changed the boot to load absolutely everything high (1990's DOS reference free of charge) and copy it down with this but no dice - I guess stuff is getting overwritten lower down the memory model

Code: Select all

100 a=196608: b=184320 : c=204800: d=245760: e=212992: scr=131072
110 p1len=25600: p2len=11008: p3len=5114: p4len=2726: p5len=2294 : p6len=5264
120 a1 = RESPR (p3len)
130 b1 = RESPR (p2len)
140 c1 = RESPR (p4len)
150 e1 = RESPR (p5len)
160 d1 = RESPR (p6len)
170 scr1 = RESPR (p1len)
180 MODE 8: PAPER 0: CLS: CLS #0
190 LBYTES flp1_p1,scr1
200 LBYTES flp1_p2,b1
210 LBYTES flp1_p3,a1
220 LBYTES flp1_p4,c1
230 LBYTES flp1_p5,e1
240 LBYTES flp1_p6,d1
250 move_mem d1, d, p6len
260 move_mem e1, e, p5len
270 move_mem c1, c, p4len
280 move_mem a1, a, p3len
290 move_mem b1, b, p2len
300 move_mem scr1, scr, p1len
310 CALL d

320 DEFine PROCedure move_mem(s, d, l)
330 LOCal i
340 PRINT #0;s,d,l
350 FOR i = 0 TO l STEP 4
360   POKE_L (d + i), PEEK_L(s + i)
370 END FOR i
380 END DEFine move_mem

I guess I'm out of luck, is there any way of finding out what is allocated in the memory? But even then I would imagine I am powerless to do anything about it.

[Derek_Stewart]

HI,

I do not think all this moving of code to higher areas of memory will work. You have to remember that game will be written for a 128K QL, so the software will not know about 68020 CPUs, more than 640K of memory

My experience with other games and software, they just do not run in a modern environment.

So, you have to alter the QLs environment to suit. Minerva, may run the software, without the second screen enabled. But best to use JS Roms, which are more standard.

This could mean cutting the memory to 128K with RES_128 command.

Try using the FLP_USE MDV command to give MDV device access to the Microdrive device.

But more than likely, once the use of Floppy disks is used, the FLP controller takes some memory, then the available memory is not enough to run the game.

The only effective solution is to make a vDriveQL MDV image, remove SGC and leaving 128K boot up with a vDrive QL configured as MDV1_ and try and run the game.

Another idea, is to disassemble the game and alter the code to run in a modern QL environment, not easy.

I will dig out my microdrive of the the game and see wha I can do.

[Martin_Head]

Looking at the numbers supplied. You could try loading the game into into Qemulator, but don't do the CALL

then SBYTES flp1_something,184320,66704 (that's if I did the sums right )

This should save everything as one big block, ready to go. That you could LBYTES at 184320 in the Goldcard then CALL 245760

I don't know if this would work, There are some gaps between the blocks in memory. But the addresses given are nice round Hex numbers e.g. 196608=$30000

If it does work, the game is likely to be far too fast on a Goldcard.

EDIT

Just had a look on one of my old floppies, and found the game. This is the boot file

Code: Select all

100 a=RESPR(76*1024): b=184320
110 a=RESPR(512): IF a>=b THEN GO TO 110
120 a=196608: c=204800: d=245760: e=212992
130 MODE 8: PAPER 0: CLS: CLS #0
140 LBYTES flp1_p1,131072
150 LBYTES flp1_p2,b
160 LBYTES flp1_p3,a
170 LBYTES flp1_p4,c
180 LBYTES flp1_p5,e
190 LBYTES flp1_p6,d
200 PAUSE 250
210 CALL d

Just tried it on QPC2, it kind of runs, but way too fast

I don't remember if I had to hack the game to get it to work though.

EDIT 2
Just checked the file sizes, some of mine are different to the ones you give. I don't know if it's a version thing?

[RWAP]

My boot file is:

1 REMark SNOOKER BOOT PROGRAM v2.0
2 :
3 REMark IF YOU HAVE A LARGE MEMORY AND
4 REMark RUN INTO AN OUT OF MEMORY ERROR AT LINE 110
5 REMark TRY CHANGING THE RESPR COMMAND TO ALCHP (TK2 COMMAND)
100 a=RESPR(76*1024): b=184320
110 a=RESPR(512): IF a>=b THEN GO TO 110
120 a=196608: c=204800: d=245760: e=212992
130 MODE 8: PAPER 0: CLS: CLS #0
140 LBYTES flp1_p1,131072
150 LBYTES flp1_p2,b
160 LBYTES flp1_p3,a
170 LBYTES flp1_p4,c
180 LBYTES flp1_p5,e
190 LBYTES flp1_p6,d
200 CALL d

Swapping the RESPR to ALCHP allows access to a different range of addresses which can help