@Michael_Barry That looks promising. At least I know it’s not a completely impractical idea.
@oldben I’ve heard of Pascal P-code, but have never used it. I don’t remember it being available for any of the 8-bit computers I owned.
Did it work on tape-based machines?
@drogon Infocom’s Z-machine was designed to be used on systems with a disk drive to load data during play. I want something that works with tape-based systems.
Level 9’s A-machine would likely be a good fit, but I’d need to reverse engineer that system as the source code is not (yet) available.
Looks like you might be after the ultimate holy grail of “write once, run anywhere”… Which Java was supposed to be, but it won’t run on 8-bitters… However…
Plasma may be at least worth a read:
The other thing (close to my heart) is BCPL. This traditionally compiles into a bytecode (In the same way P-System Pascals, Java, and (I think) Python and in then interpreted on the target machine.
Can it run on tape systems? Yes - the BBC Micro had a working BCPL implementation which could let you boot the system off an internal ROM, then load the editor from tape, edit your code, then run the compiler off tape to compile then link your code.
BCPL is on-going and while it might be an interesting challenge to make it work from tape on a Beeb again it can be done.
And mentioned above; Java and Python. There are micro Python version(s) out there too.
All you need to do is write your “Basic” in your universal implementation language - or use it directly.
Or, since you’re interested in Adventure games (as am I), then you write a “portable” compiler/interpreter then port it to each platform 8, 16, 32, 64 bits, etc. as required.
For the smaller systems then cross compiling would probably be acceptable.
There are some adventure game writing kits out there which I’m sure you’ve found - I think at least one is open source, but it’s a while since I’ve looked.
Hadn’t there been such a common-ground BASIC subset that would run on multiple popular machines with the help of subroutines at well known line numbers for any machine specific tasks? I try to remember what this was, but I can’t recall at the moment, while I’ve certainly seen sources for this. It must have been associated to some newsletter or magazine, I guess. Also, I don’t know what computers were actually supported.
(This would have been limited to simple, line oriented input and output, and only the simplest kind of conditions, of course. Even things like AND and OR would have been to be avoided, I suppose. But it would have been good enough for a [rather simple] text adventure.)
Anyway, this would probably be the way to do it:
Identify a close to universal subset (not “IF…THEN <line-number”>, or “IF … GOTO”, but “IF … THEN GOTO”; no ELSE, only simple INPUT and PRINT, FOR…NEXT, assignments using LET, etc)
probably single-character variable names only
only simple, one-dimensional arrays
define a library of subroutines for any complex operations and their line numbers, reserve some variable names for data exchange (clear screen, find string in another string, get a random number for a given range, etc)
implement the library for any target computer
identify a viable memory limit
write the control code, AKA “the program”, using the identified subset and sticking to memory limits (including the subroutine library)
an effective program consist of the control code and the reusable library code. Meaning, this would be still dedicated to a specific computer, but it would provide a common platform for type-in programs.
But, I’m afraid, the practical limitations are quite severe…
Why not use an (existing) emulator?
Text adventures (without gfx) should work on most computers when using few and simple instructions.
Like the ones from Creative Computing.
But you will always have limitations (different file formats, media, screen resolution etc).
So you would have to make adjustments for most machines, and so you are close to emulators.
We might have a somewhat similar vision. Starting a year and a half back I developed Continuum 93, a fantasy retro computer having in mind many of the points you also expressed the difference being I wrote the CPU from scratch along with its assembly instructions architecture. It’s a versatile little machine, maybe you’d like to take a look at some of the specs.
The vision for it is indeed enabling developers to write retro-games the old-fashioned way, but with some modern twists and helpers and offcourse be able to deploy on other platforms/handhelds. This is still an ongoing process and I also plan on implementing BASIC interpreters/compilers for it. Maybe even a C compiler if time allows me. Or, anyone willing to write their own, they can also pick that up.
But, as the author, I am also biased in favor of my own project and looking at your efforts, I think it’s best for you to look around and see what others have done as well. Here’s a nice list that someone on this forum was also kind enough to show to me: GitHub - paladin-t/fantasy: A curated list of available fantasy consoles/computers.
Maybe it helps crystalize what you envision doing, whether it would be adopting one of those existing projects or writing your own. If you plan on writing your own, try to aim writing it as simple as possible, without external libraries that you might have difficulties with when trying to go cross-platform.
That being said, (and coming back to my bias) I do think Continuum is a very good platform for you to write such games, so I’d welcome you to give a critical look at this project. We also have a minuscule community that’s growing and someone even wrote the first game for it.
If you decide to write something on your own, I’d also be interested to see your project (and I’d probably not be the only one), so don’t be a stranger.
Wow. There’s a lot of potentially useful info here. I’ll try to respond to as much as I can.
@drogon Write once run anywhere is kind of what I’m aiming for, as long as “anywhere” only includes platforms with a keyboard.
Adding more platforms to FreePascal would be one way of achieving that. Another would be to add more interpreters or virtual machines to an existing text adventure system.
Yet another would be to create the 8-bit virtual machine I originally mentioned.
PLASMA does look interesting. I’ve added to my (many) bookmarks.
BCPL is helpful as an example of what can be done. The language itself would be less useful to retro enthusiasts than BASIC though.
I know about most of the more popular existing text adventure (aka interactive fiction these days) systems, but most require a disk drive.
@NoLand I would likely start off by testing a small subset of BASIC, but I would be aiming for Minimal BASIC. I believe that Vintage BASIC follows that standard reasonably closely.
Of course, before that I am hoping to set my sights a little lower and attempt a simpler system.
@davidb I have that repository bookmarked. One of the possibilities I have been considering is attempting to reverse engineer Level 9’s A-code system, as it was designed for 8-bit tape-based systems (unlike Infocom’s Z-machine).
Others are actively exploring the old games and one of the Austin brothers is trying to get all the original code together and update the tools for modern machines. Nobody seems to know how long that might take though.
The main problem is that only the opcodes they used are (mostly) known. The coding language is a mystery and the only virtual machine is for modern computers.
To complicate matters, there were 4 different versions of the virtual machine created over the years.
@mainframetom If you mean an existing virtual machine, then there aren’t any publicly available for the machines I wish to support. There are emulators of the physical machines though.
I’m only interested in creating text-based programs, so that should reduce the number of differences between machines. I might add graphics capabilities to a couple of them, but I wouldn’t attempt it for every platform.
Others with greater knowledge of such systems could potentially expand the code, if they wanted graphics badly enough.
Whatever I come up with should be able to produce code for physical machines, preferably by loading from physical tape or a digital recorder. There are existing utilities to convert program files to an audio format.
Yes, I’m still looking for a similar system to the one I mentioned in my previous thread.
@EnthusiastGuy I hadn’t considered supporting fantasy computers. It’s an interesting idea.
If I manage to get something up and running for real retro machines, I will explore doing the same for fantasy emulators, depending on what programming tools are available for them.
If you find a good way of accomplishing that for several other hardware computers, I’d be happy to offload the implementation of it for my machine and take care of that. I also designed a flavor of BASIC for Continuum, but there can be as many implementations as one wants. Keep us in the loop and good luck!
I think that other than FORTRAN (and maybe Algol) BCPL ought to be the ultimate in retro languages - however in terms of popularity I suspect I can count the number of active users with 2 binary digits, and I’m one of those 3…
As for writing an adventure in it - one fairly famous MUD was written in it once upon a time… (MUD2, Essex)
But sadly, popular, it’s not, but it does run on 8 through 64 bit systems… Just write/adapt the bytecode interpreter then write a portable run-time library and off you go …
One other thing I’ve just thought of though - Lua. It’s “embeddable” in other languages and systems, but I really don’t know much about it.
Most owners (or former owners) of 8-bit home computers are likely to be at least slightly familiar with BASIC as it was usually available as soon as the machine was switched on.
Books and magazines of the time also rarely used anything other than BASIC in program listings.
From what I remember, Pascal was probably the second most popular language of the time.
Lua might be an option for those that have used it for modern game mods, but I don’t know of a version small enough to run in 64Kb or less.
There is a language called Nelua that compiles to C though, so it might be possible to use it with an 8-bit C cross-compiler.
Going back to your original post - for many reasons…
I am a big fan of adventure games - being brought up on the original Colossal Cave, then Zork, Infocom, some of the Scott Adams ones then MUDs. I even wrote my own MUD which ran online for the best part of 20 years. I could write several books on that one…
Some thoughts out-loud - maybe critical but not intending to criticise… Writing adventures and creator systems is something close to my heart too - sadly now I lack the time to take it much further - for now, anyway…
So the aim is to write some sort of adventure game creator and execution system - but you wanted tape?
I’m going to suggest that that’s not feasible or practical today. The Infocom ones needed a back-end disk paging system just to deal with the rich textual environment, so without that, you end up with tiny adventures with a minimal wordset or you start to use a compression techniques which adds to the code complexity.
People do still use tapes on old systems though - but almost all I’ve seen are really PCs with sound card outputs and the tapes being digitised and stored as files on the PC. Old computers have a multitude of disk emulators now too - from the “flux” level to complete re-implementations using modern parts. I suspect very few people use actual floppy disks now.
Could you bootstrap it off tape by loading the core interpreter, then the word-list, then the map/database and room descriptions? What about custom code triggered by actions…
Then… Basic or a basic-like language. Because you want others to write their own adventures or because you find it easy to write in Basic yourself… Maybe that’s a limitation?
Writing/developing on the target or an external system? Todays programmers are often brought up on using an IDE running on their desktop - to produce code for different targets, but back in the day - An exception might be Infocom though - they used a PDP-10 (at least initially) to do the development then they had a target execution environment for every system. Not sure about the Scott Adams one but it looks like he did something similar - a common game file then custom machine run-times.
Wind on a year or 2 and people were writing in Basic in their home PCs - not always fast but it worked.
Round about the early 90s MUDs started to gain popularity due to this new-fangled thing called “The Internet”. Mostly still text based when the PC ones were moving to graphics. These were mostly written in C, running on “borrowed” work or university systems like Sun workstations and other (typically) Unix systems. Mine first saw the light of the 'net in late 1992…
Where does that leave us today?
I’d love to port my MUD engine to a retro system - but it’s written in C (the engine) and the actual “world definition” is written in a intermediate language - a C-like thing which handles lists and database objects natively. The world is a database which holds text or code or lists of database objects. The code is compiled into a bytecode.
Then there is the parser - if verbs and nouns were good enough for Colossal Cave then …
Kill Dragon
What with, your bare hands?
Yes.
Amazing.
How deep do you want to go? That can become very complex very quickly. For the most part, I stuck to the old verb/noun thing, but it could parse stuff like
unlock door with skeleton key
but it was fairly brute-forced - the parser looked for the keyword “with” then returned a left side and a right side. The left side was searched in the room contents and the right side searched in the players inventory… Not the best, but very workable and if it all matched then a function bound to the left side was called. It was good enough.
Returning from that rabbit-hole…
Could this be done on an 8-bit micro? Sure. Infocom did it - separate dev. environment, per-system run-time.
The hard part is writing the per-system run-time.
But lets say we target systems that already have Basic (maybe this is the intention?) Back in the day the magazines published big (and they got very big) posters detailing the difference between Basic dialects on different systems - most systems that run a Microsoft Basic were very similar - Pet, Apple II, TRS-80, Various CP/M systems, OSI/UK101 and so on. The changes were minimal. Other systems with their own Basics were more troublesome - ZX Spectrum, BBC Micro and so on. String handling was often an issue too.
Memory sizes too. The Beeb was criticised for only having 32K of RAM at the time when the Apple II had 64K, the Spectrum 48K and so on, however you can run Zork on a Beeb…
So - you create a common language/descriptor system then write the world generator and a set of run-time subroutines for every different Basic platform then have the generator crank out optimised code for each platform and “link” in (ie concatenate) the “library” for each platform and off you go.
If only life were that simple…
I’d like to do it again, but the target - it would be easy to target modern MS Windows or Mac, or Linux - but the old/retro systems running 8-bit Basics? I’d probably write a run-time to interpret the game world/database, etc. but how many different systems, how long have I got?
Plan B: Make your own little 8-bit SBC with the sole intention of running a text-based adventure game - VGA graphics, USB keyboard enough RAM - open source or sell it… Uptake… Single digits.
Bear in mind that Zork started off on a mainframe that had WAY more memory than home computers of the time, so the whole running off a floppy thing was more or less forced.
In contrast, other people were programming text games that simply fit in memory from the start, because … well … that’s all they had.
That said, here in the USA we had floppies everywhere.
I guess, if it’s dedicated to text adventures, it may be worth going down the assembler route for the parser. How many (important) platforms are there? 8080 (includes 8085, Z-80), 6502, 6800. These may be compiled from a common C-source, machine specific is probably just the memory location of the runtime code and any data sections. Notably, this may be from the same code as used for any more modern platforms.
With this out of the way, the remaining engine (in BASIC) is really about the UI, room definitions, and high-level stuff. Some of the room/inventory logic may be pushed as byte-code to the same assembler runtime as the parser.
Regarding parsing, you may want to have a look at the “Hobbit” and its “Inglish” parser, which was quite esteemed at the time. There are probably articles on this to be found…
Edit:
The logic behind this: all the internal heavy-lifting can be done in machine language, there’s just a handful of platforms to support, since all systems of a type are basically the same, as long as the code is running headless. This code is arguably easier to write and share in a language like C. What is machine specific, on the other hand, is really the user interface and any machine specific customizations (e.g., character encoding), which are arguably easiest done in BASIC. Here, BASIC provides already a direct implementation of any machine specific handling and limitations should be less felt.
This really leaves the question, where to best implement anything that is specific to a particular adventure, but the same for any platform. Should this be pushed to a common back-engine, or is this better left static and these aspects should be thus implemented in BASIC? As this is probably more of a philosophical question, there is no general advice. But, again, there should be common tasks which run entirely internal and headless, where byte-code may become of interest.
Oh sure. Zork itself was/is huge. It was effectively split into 3 for the microcomputer release - using floppy disks.
We had floppies in the UK, but often due to the cost (dollar to GBP plus hefty import dutys and tax and postage) they were almost out of the hobbyist reach in the UK. The popularity of the BBC Micro (late 1981) started to change that. Very few could afford one of the “holy trinity” of Apple/PET/TRS-80 at that time.
As for micro adventures - I do have a Sharp PC1211 (aka TRS80 Pocket Computer) and there were adventure games for it - a challenge in both RAM (1.5KB) and display…
