To return to the original topic I think thar you could carefully only use instruction 1 (or 3) in every action for print. If you absolutely need a print-statement in instruction 2( or 4) you should position these actions first in the file.
I noticed in the rotten_v4.sck that you have this at line 902:
occur when at tourney and !flag 17
set_flag 17
print "The duel is SET. Claudius summons CUPS
tosses a pearl in one 'to thy health'
Laertes picks a sharp FOIL of a length
'Come MY LORD' he says. ENGARDE!"
pause
If you switch the position of the print- and flag-statement here and at other places like this you probably will get more message-slots.
I believe that the fix for the compiler could be that if it encounters a print-statement in instruction 2 (or 4) it replaces the statement with a “continue” and puts print in the “subroutine” where it gets to be instruction 1.
I really want to know how these >99 message hacks behave on the original interpreters. It’s very notable that all of the commercial games strictly observe that limit, which makes me wonder if their tiny little minds would be broken by the hack.
Unfortunately, unlike in Z-machine land there doesn’t seem to be any community tool that I can find for “jam an SA .dat file back into a TRS-80 interpreter”, and every other SA-format game I can find for 8-bits uses binary rather than ASCII for most or all of the numbers in the database, so there’s yet another step required there.
From my standpoint of “cosplay designer making S.A.L.A.D. like it’s 1980” I honestly prefer sticking with the 99-message limit for authenticity (and because if I don’t have that kind of limit, my shoddy writing and lack of attention to detail is even more of a glaring flaw!) but I am happy to help with the research portion of it.
I tried the “testadv”-program from higher up in the thread in perlscott and it produces the same result as ScottKit and ScottFree (i.e. you can have more messeges if you’re only use instruction 1 and 3). So there’s a good chance it’ll work in the 8-bit world too.
PerlScott is based on the original BASIC intepreter wich source code was published in Byte 1980 (version 4.6 i believe). with minor changes to support newer dat-files.
In the PerlScott project there is a scan of the Byte listing and a transcription of it so I struggle with the idea that maybe I should try to convert it to C64-BASIC with support for the newer instruction set (v 8.5 I think). Would that even be possible?
pdxiv: Is PerlScott still supported? I tried “GHOST KING” in it and it loaded fine but something is broken, se below:
My princely bedroom. Visible items here:
Wardrobe. Closed door.
Welcome to GHOST KING S.A.L.A.D. #1
Scott Adams Literary Adventure Diversions
This should have been 1980's hottest game
I am PRINCE HAMLET
My father is DEAD, KILLED by my unclefather
What are we going to DO about it?
Tell me what to do
take inv
I'm carrying:
Nothing
Tell me what to do
open ward
OK
My princely bedroom. Visible items here:
*Robe*. Dagger. Closed door.
Tell me what to do
get dag
I've too much too carry. try -take inventory-
Tell me what to do
Thanks for trying perlscott. It looks like there may be something odd with the inventory limit that requires investigation. It helps to have specific examples to go on, like this one. Perlscott is still supported, but I’m a bit behind on following up on bug reports. I hope to allocate some time this afternoon to Scott Adams things, so this is perfect. (I’m also working on an interpreter written in Go, that will be playable using a web browser, to make it easier for people to share their SA engine projects online.)
Thanks, that’s a great discovery. I’ll add it to perlscott.
I went through the old Adams and Howarth games (and a few others old ones) and the “maxload” never appears in those game data files with a value of -1. Not sure if this is a ScottKit-ism, but it makes more sense than setting maxload to 999 or something silly like that. Perhaps ScottFree supports it accidentally, because of overflow of data types? Please note that it’s quite likely that the original Basic implementations for TRS-80 do not support this.
I wonder if you might actually have an easier (and ultimately more productive) time translating things like PerlScott or SK’s interpreter to one of the lightweight compiled languages like XCBASIC.
There might be value in that, to be able to have something running to verify the functionality of the original code, for “historical correctness”. C64 emulators are more diverse and easy to use than the TRS-80 ones i’ve seen too. A word of caution though: I personally underestimated the complexity of the compact BASIC code.
We’ve discovered that SA authoring tools are happy to let you do things that (some) SA interpreters will not like. There’s definitely some finessing necessary to make a game stable above the 99 message soft limit (and notably, Adams and Howarth always stayed within 99.)