CBM as first chars in a binary file rings very familiar to me, I looked at basic/xzip hexdump, but things becoming strange:
CBM80 was the “magic signature” identifying an autostart cartridge, but the actual signature was:
XXYYCBM80
where XX is the cold start vector of the cart, and YY is the warm start vector. Not our case, but the next two bytes are intriguing: 00 0C. that is, C000 in the little-endian world of 6502/6510… and C000-CFFF are the 4k of C64 RAM sandwithced between the basic and I/O…
but the file is 12827 bytes long, and from C000, ends at F21B, overwriting the I/O aerea (= major mess on a C64) prior of writing partially in the RAM under the kernel ROM, a thing whose don’t make sense… (continuing the research)
Thanks for another hacking night outside IF coding
There are a bunch of z3 PunyInform games which are smaller than Minizork 1, and which shouldn’t be more demanding in terms of dynamic memory etc.
Library of Horror (35-ish KB) is on if-archive.
The games in The Airlock Collection have had a bit of extra attention to make them small and performant on 8-bit hardware: The Airlock Collection (Game files under /Modern in the zip, get a z3 version of Fantasy Dimension from The Fantasy Dimension by johanberntsson )
Bumping this to ask a quick question. What C compiler and prerequisites are required to build the IBM terp in DOSBox/Dosemu? If anyone can assist me in this endevor, I’d appreciate it. (Also, Incase @8bit_era might be reading this, as much as it sucks, DOS Frotz doesn’t run everywhere, and it might be a good idea to allow the Infocom terps to be bundled with DOS releases for the Puny Build Tools, as was recently done for the AppleII.)
Good point. I can add that feature as a hack to the Puny BuildTools, as I did for the Apple II. In fact, a binary of Infocom’s DOS interpreter comes already shipped with the Puny BuildTools, it’s just unused. Will need to look into it though. I don’t remember if it supports both z3 and z5 or only a single target architecture. The interpreter coming with the BuildTools has been modified to load STORY.DAT rather, as it was often common with Infocom games, something like STATIONF.DAT.
I will update the Puny BuildTools thread once done.
Out of curiosity: on which DOS machines did you experience Frotz not working? I always thought that Frotz on DOS is the safest option to make all DOS enthusiasts happy.
A significant difference between Frotz and Infocom’s terps is that the Infocom ones usually (always?) swap static memory in from disk. Frotz long ago switched to loading all of static memory to the host’s RAM. This can be hard on machines with very limited memory. I’ve been experimenting a bit with reimplementing that lost code to ease the load on such machines, in particular the IBM PC and XT.
During the Infocom era gate$'s stupidity about RAM was still to be proven (I must recheck scores of computer-related magazines of 1980s for a real historian’s timeframing, but ISTR the 640k PC and 1M AT was more or less the norm late 80s) and during Infocom’s golden era, 1983-5, the PC and XT norm was 256kb, and a 192k PC was still relatively common. (and happened a drought of 256k chips during the mid-80s)
DOSbox isn’t designed for precise emulation of early PCs (early-mid 80s vintage, but if if I find some time, I’can try some experimenting with PCem (whose isn’t precisely a stable emulator…) to see what is the practical minimum configuration for 16-bit DOS frotz.
DOSbox unfortunately isn’t really designed with precise emulation of any PC in mind. It pretty much does the bare minimum to play DOS games. There are tons of things that could be done to make the emulation better but if it doesn’t directly affect a DOS game, then it won’t get done. Even fixes for games proceed at a glacial pace.
It’s worth noting that there are a lot of different versions/ports of DOS Frotz, some of which are pickier than others. For my Compaq Portable II (286 processor, 640k RAM, CGA graphics, MS-DOS 5), I found the one that worked best was Stefan Jokisch’s original version of DOS Frotz 2.32 (available here). This may not work with <640k RAM, however.
I am currently working on making Infocom’s interpreters available for the DOS target. I did some testing with the .Z3 interpreter I already had, unused in the interpreters portfolio of the Puny BuildTools, and a friend of mine tested it on a variety of machines, even on an unexpanded original IBM PC from 1981. Runs great on anything you throw it at.
On the weekend, I also had a look at Infocom’s MS-DOS XZIP interpreter, particuarly Interpreter 6 version J, which is the interpreter that came with BorderZone. It has a low memory footprint but also takes advantage of stronger machines. Had to hack it a bit to remove all game references from it but other than that it runs just fine. Tested it with Ghosts of Blackwood Manor to see if it fully supports Z-machine colours, which it does.
I might even make these interpreters the new standard, since the BuildTools only target .z3 and .z5. and the interpreters are super small yet still provide all options you would want them to have.
I am still uncertain about Frotz. I do love Frotz but so far I don’t know what the hard limits are on DOS machines.
“Memory upgrades were provided by IBM and third parties both for socketed installation in three further onboard banks, and as ISA expansion cards. The early 16 KB mainboards could be upgraded to a maximum of 64 KB onboard, and the more common 64 KB revision to a maximum of 256 KB on the motherboard.”
I can’t quite imagine a Z-code interpreter running an Infocom game “great” (Stefan’s words) on a system with 16 KB of RAM.
true that the PC was available initially in 16, 32 or 48k, usable only with IBM ROM BASIC/BASICA and the cassette (capable only of LOAD and SAVE, without filenames… so, was practically useless) but for running DOS 1.00 64k was needed, and under DOS 1.10 you needed more than 64k, and with 2.0 192 or better, 256k allows real work.
Yes, it has 128kb and runs DOS 2.0. “Unexpanded” probably was the wrong term to describe the machine. I should have said “untouched since it had been bought”.
No, definitely not on a 16kb machine. But we are talking about the German IBM PC, which was noy available as a 16kb version. The smallest you could buy here was 64k. There were also 128kb and 256kb versions on the market. I doubt anything would run great on a 16k machine.
