BBC Micro file format bugs

[ahope1]

The bugs reported in the old Sourceforge thread persist:

https://sourceforge.net/p/grackle/bugs/6/

[tautology0]

Ah yeah; I actually found this recently myself - it seems to not get the start room correct. Looks like I may have to remind myself how my code works :-)

[ahope1]

@tautology0 Actually, when you save a game as non-runnable (by choosing "D" in the save dialogue), it looks like Beeb GAC doesn't actually save the start-room in the game data file at all!

(But even if you export the game as a runnable game (by choosing "R"), the start-room seems to be stored only in the runnable machine-code file (filename specified by the user), rather than in the game data file $.DATA (which is exported by GAC and then read by the runnable code).)

You might need to add a parameter to grackle so that users can specify the start-room on the commandline (with a default of 1).

[tautology0]

I finally got around to adding getopt to the command line - it only took about 8 years ;-)

Now its -l to dump the file and -s room for a start room. If you're running a beeb game it will assume it's room 1.

BBC Micro isn't working yet; there's something screwy with the high priority actions which I need to debug.

[ahope1]

@tautology0 Thanks! I'll have a go with the new version ASAP.

Btw, I've run into another problem while trying to use grackle on a simple two-room test game -- see LTEST04 on the attached .SSD disc-image. The dump aborts with "Abort trap: 6".

LTEST01.ssd.zip

[ahope1]

Btw, this is off-topic, but it looks like there might be a bug in Beeb GAC:

http://stardot.org.uk/forums/viewtopic.php?f=54&t=14335&p=191499#p191499

[tautology0]

That one appears to be auto detecting as C64; so I added a -t flag to override type detection (BBC Micro is -t 4). It attempts to decompile, but makes a real mess of it.

It looks like I need to delve into the guts.

I honestly don't know how grackle would respond to the bug, as the main engine of it was written from my interpretation of the manual and bytecode.

[tautology0]

That push doesn't work, as the autodetect function does a lot more than I thought. But I found the problem - it was that the C64 detection was a bit too sloppy; pushed a quick fix and it decompiles now:

> Low priority condition 1:  IF (VERB (VERB 9:"L")) LOOK  WAIT  END
> Low priority condition 2:  IF (VERB (VERB 10:"INVENTORY")) MESS (MESSAGE 239:"You are carrying ") LIST (WITH ) WAIT  END
> Low priority condition 3:  IF (VERB (VERB 11:"QUIT")) QUIT  OKAY  END
> Low priority condition 4:  IF (VERB (VERB 12:"TEXT")) TEXT  OKAY  END
> Low priority condition 5:  IF (VERB (VERB 13:"GRAPHICS")) PICT  LOOK  OKAY  END
> Low priority condition 6:  IF (VERB (VERB 14:"SAVE")) SAVE  OKAY  END
> Low priority condition 7:  IF (VERB (VERB 15:"LOAD")) LOAD  LOOK  WAIT  END
> Low priority condition 8:  IF (((NO1  < 10)  AND VERB (VERB 7:"GET")) ) GET (OBJECT NO1 :"") OKAY  END
> Low priority condition 9:  IF (((NO1  < 10)  AND VERB (VERB 8:"DROP")) ) DROP (OBJECT NO1 :"") OKAY  END
> Room condition 1 for room 1:  IF ((1 IN 2) ) MESS (MESSAGE 1:"The gun is in the other room. ") LF  HOLD (500) END
> Room condition 2 for room 2:  IF ((1 IN 1) ) MESS (MESSAGE 1:"The gun is in the other room. ") LF  HOLD (500) END

[tautology0]

And... Grackle has the bug; which is very strange!

[ahope1]

@tautology0 That is indeed very strange! Presumably the only way that this could have happened is if you wrote your GAC interpreter in C by closely following a disassembly of the machine-code GAC interpreter from the original GAC disc? I can't think of any other possibility! Can you?! It's baffling. (It would be a staggering coincidence if you wrote your interpreter in C without any reference whatsoever to the (Beeb-specific?) machine-code and yet managed to reproduce the same bug!)

I wonder if the same bug is present in other 8-bit machines' versions of GAC..?

Thanks for fixing the autodetect!

[tautology0]

I wrote it from scratch using the manual as its major reference source and what I found from reverse engineering the Spectrum format. Some stuff I did reverse engineer using a disassembler on the Spectrum. Graphics were reverse engineered from the BBC version of random and were never really supported.

This was about 12 - 15 years ago, so memory is fading somewhat.

[ahope1]

@tautology0 Is it possible you got param1 and param2 the wrong way round here?:

case (39): // AT param1=popint(); printf("param1 %d\n",param1); param2=popint(); printf("param2 %d\n",param2); true=find_object(param1,objects,header->objects); if (objects[true]->location == param2) { pushint(1); } else { pushint(0); } break;

It might explain why IF (1 IN 1) works but IF (1 IN 2) doesn't..!?

But I'm really not very good at C, so I could be talking rubbish.

[ahope1]

@tautology0 Actually it looks like there is indeed a bug in GAC, which, strictly speaking, grackle ought to reproduce, so I think you might have to reverse the last change you made to the C code:

http://www.stardot.org.uk/forums/viewtopic.php?f=54&t=14335#p191595