Tools for creating retro tape-based parser games?

The original Basic source code from Scott Adams published in Byte Magazine (PerlScott/basicinterpreter.bas at master · pdxiv/PerlScott · GitHub) isn’t as fully featured as the later incarnations of the interpreter, missing 5 conditions and 12 commands that are typically present in newer game data files. If those conditions and commands are avoided during the authoring, I’m sure the original Basic code could be made to work with minimal effort.

…However, I have suspicions that there are newer Basic interpreters around for the TRS-80 and other platforms which are more feature-complete. (I just never bothered venturing that far down into the digital archeology rabbit hole to verify that.)

Adding to what others are saying;

I’d be tempted to write my own “mini basic” which could be (fairly) easily ported to various 8 bit systems then write my games in that, so that they could be developed on windows, then ran on the target machines.

The mini basic would not need floating point nor any scientific functions, and instead perhaps have some helpful stuff for these kind of games, eg a 2 word parser.

For cassette tape operation, I’d be less inclined to worry about text compression (although that could be added) and instead make my games out of “levels”, where each, so-called, “level” is a new basic program that loads and plays. This way, you wouldn’t run out of memory on any system. But, of course, the game design would have to be around these levels.

So clearly, you need some continuity across levels, which would be a set of flags/states and some objects. Ideally as few objects as possible crossing “level” boundaries.

To give an example, and to keep things really simple, perhaps each level has a single final “treasure” that you must get. Say there are 4 levels, then there are 4 treasures, and these objects are present in all 4 level parts, but none of the other objects exists outside their own level. Now you can get the 4 treasures in any order.

Or, even simpler, the levels are sequential, so it can be assumed that you have all “treasures” from the all previous levels at each start.

some stuff;

A while back i wrote a mini-basic for embedded hw, and for fun(?) i ported it to the trs-80. I’m planning to check it into github after a cleanup. But that might be a good start candidate (just a few pages of C code & very low memory usage).

2 Likes

nd to expand on this crazy idea of why a trs-80 basic;

my own mad plan was to write a “star trek” game, where you could “beam down” on planets, and each planet would have its own mini game in basic. Obviously, there’d be only enough memory for one such game at a time.

And “winning” each mini game would have a reward, which would be a added to the main game. Stuff like, extra torpedoes, cloaking devices, phaser boost, and so on…

They’d be a bit like adventure games, but a bit of graphics too.

2 Likes

Check out TinyBasic. Dr. Dobb’s Journal has tons of information about it. I think archive.org has copies of it.

I’m not sure how useful creating a Level 9 development tool would be, considering that new interpreters would also have to be made for each supported platform. I would need a lot more information on how their system worked to even attempt it.

As for creating a bunch of mini BASIC interpreters, I feel it would make more sense to create a mini BASIC cross compiler or transpiler that runs on a modern machine and creates native code for the retro machines.

That’s an idea I’ve been thinking about on and off for a while, but I’m unsure how practical it would be.

There’s also TAB, ThinBasic Adventure Builder. Not too popular.

I’d probably just build some kind of framework that is portable across multiple BASIC dialect.

Unless there have been some recent changes, TAB and the games built with it only run on Windows computers.

I had envisioned a combination of mini programming language and a prebuilt adventure framework.

Unfortunately, the standard version of BASIC on 8-bit computers was interpreted (so much slower than machine code) and used up a chunk of the available RAM. For example, the Commodore 64 had only 38Kb or so free (out of 64) if BASIC was in memory.

There were third party BASIC compilers available for some machines, but I doubt they are easy to get hold of these days.

1 Like

8-bit computers typically have 16-bit addresses, meaning an address can only point to 65536 (64 K) different bytes. But a C64 has 64 KB of RAM, 8 KB of Basic RAM, 8 KB of Kernal RAM, 4 KB of character ROM, and 4 KB of memory-mapped I/O circuits. Obviously this doesn’t all fit in 64 KB. The solution is called banking. E.g. the programmer can choose whether 8 KB of RAM or the 8 KB Basic ROM is visible at $A000-$BFFF. That is, a machine code programmer can choose. If you’re using Basic, the Basic ROM has to be visible. And the Basic ROM relies on functions in Kernal ROM, so that has to be visible too, etc. So, in effect, all the RAM is available but you can’t use it all from Basic. Some Basic programmers added machine code routines which can use all that extra RAM. For an adventure game you might store a dictionary and perhaps object tables under ROM.

The Plus/4 is quite similar but works around this limitation, giving the user ~60000 bytes of RAM accessible from Basic.

1 Like

I would love to see a Level 9 format development system. If I remember correctly, @8bit_era was working with the Austin brothers to preserve their development tools, as well as the source code for their games, so maybe something will come of that.

1 Like

Yes, I asked about that last month in another thread and it was still being worked on then.

As there’s no ETA for that, I’m currently looking into using SDCC or z88dk with a language that compiles to C. For example, Nim has been already been used successfully with SDCC.

1 Like

Mike Austin is still working on it and at this point I am not sure if this system will be very accessible. Mike doubts it. If you guys aim to target tape, I can only recommend using DAAD. It takes a single source file with a brilliant language and compiles it to various 8-bit and 16-bit systems, including even DOS. It is unfortunately not available for every obscure system out there but it works with the majority of the home computers that were popular in Europe. The 8-bit interpreters all support tape operations, which are these systems:

  • Commodore 64
  • Commodore Plus/4 (and C16 with 64k)
  • ZX Spectrum
  • Amstrad CPC
  • MSX

And if you want to start developing right away, just use my mate Uto’s DAADready! Package, it comes with everything pre-configured including examples and a modern compiler. The text compression is pretty good and you can even define better tokens. There is literally no reason to wait for the Level 9 tools other than for the sake of having it preserved. When DAAD resurfaced in Spain (the Spanish version), it took years until the system was made whole again, the missing interpreters recovered, the English template files recreated, modern compiler with a better syntax written and a package published which made the whole system accessible. The same is likely going to happen with the Level 9 tools before you can actually use them the way you intend.

DAADready is available here. You probably don’t know it yet but this is likely what you want. If you want to create an interpreter for a system that is missing, ping me. We have sources for both 6502 and Z80 based systems for you as a starting point.

1 Like

Thank you for this link. I have wanted to experiment with DAAD for some time. I have an old C64 and a RC2014 (Z80) that I like to fiddle with.

1 Like

DAAD Ready is a joy to use, especially in conjunction with a syntax highlighting tool when editing your source (such as Chris Ainsley’s one for VScode). A common source and instant testing across all the various formats with the bundled emulators. Anyone coming to DAAD now has it easy! :slight_smile:

3 Likes

Unfortunately, the more obscure platforms are my main focus. If yet another Spectrum game were to be released, it would likely be a non-event, but a new text adventure for the Sharp MZ-700 or Enterprise 64 would be noticed (at least by some).

I will likely get around to looking at DAAD more closely just for the sake of curiosity, but I wouldn’t be likely to use it much unless more of the source was available or it could output to a more universal compiler, such as SDCC.

I’ve won two Crash Smash awards with Hibernated. One for the classic, DAAD based game, one for the Director’s Cut last year, which was a rewrite using the Z-machine. The rewrite has been downloaded more than 15.000 times now on itch since 2021 with the majority loading the Spectrum and C64 version. I wouldn’t classify a release for those systems a non-event, especially when it’s an accessible game, there is going to be lots of attention.

I understand of course when your heart beats for a different machine. There are still people out there loving the Jupiter Ace, the Oric and the Dragon32. With Hibernated though I targeted about more than 30 different classic systems and for some obscure ones like the Osborne or the DEC Rainbow there were IDK, like 5 downloads. So there is a bond between obscurity and effective target audience. This is something one needs to be aware of. On the other hand I was very surprised about the TRS CoCo. I was chatting with @fredrik (I think) about this release and he was like: the 5 CoCo users out there will appreciate it. One week after the CoCo port was out I’ve been invited to CoCo Talk, a live stream format where literally hundreds had tuned in and it turned out that the CoCo scene (in the US notably) is extraordinary massive. Anyway, go for it. It’s been some time since the Sharp and the Enterprise saw proper releases. I tried to get the Enterprise Z-machine interpreter running some time ago but I failed. So no Enterprise from me

PS: These systems may not be targeted with the Level 9 tools I believe so looking into SDCC is probably not a bad idea. Personally I prefer z88dk though. Its nearly C90 compliant and its whole standard library backbone is written in ASM, craftting very efficient binaries from your C code.

Just my two cents as usual :blush:

1 Like

I will likely get around to looking at DAAD more closely just for the sake of curiosity, but I wouldn’t be likely to use it much unless more of the source was available or it could output to a more universal compiler, such as SDCC.

The new DAAD compiler (DRC) is completely open source GitHub - Utodev/DRC: A new compiler for DAAD adventure writer. For ZX Spectrum, Commodore 64, Amstrad CPC and PCW, MSX, MSX2, MSDOS, Amiga, Atari ST and HTML.

You can also check out the sources of my graphic adventure Rabenstein. GitHub - ByteProject/Rabenstein: 8-bit and 16-bit text-/graphic adventure written with DAAD

And if you really want to write a new interpreter, I can provide you with 6502 or Z80 sources of the interpreters as a starting point.

I know this doesn’t allow you to target SDCC or z88dk but it’s not that there is no DAAD source available.

I seem to recall that CP/M was available on the Enterprise, if you owned a disk drive (which I didn’t), so that might be an option for playing Z-machine games.

Level 9 did create a version of their A-machine for the Enterprise, as I remember playing Snowball, Return to Eden and Colossal Adventure on that machine. I don’t believe they released anything for the Sharp or Dragon machines though.

Hopefully, the Level 9 tools will still be able to produce output for the Enterprise at least.

As for DAAD, it’s the lack of source code for the interpreters that has put me off, as that is where I would need to add new platforms.

It’s also not clear what language they are written in. Pascal or some dialect of BASIC would be good, but I’d rather chew my own arm off than write code directly in C.

A-Code has evolved over time as far as I understood Mike. So it might be that what is going to be released, won’t necessarily be able to target the Enterprise. The compiler runs on the Atari ST I believe and at that time the Enterprise was not relevant anymore. But fingers crossed it’ll allow you what you’re after.

The DAAD interpreters are made in 6502 and Z80 Assembly language. You will struggle to make it small and/or performant enough if you use a higher level programming language like C or a inferior language like BASIC.

1 Like

I have virtually no experience of assembly language, although I did find a series of Z80 assembly tutorials for the Enterprise and others.

Sadly, there is no mention of the Sharp MZ series, but the Sam Coupe is covered.

Lantern is specifically designed for tape-sized games.

Amstrad, A2, BBC, C64, CP/M, TRS-80 1/3/4, Spectrum all listed as supported platforms.

1 Like