If you're curious about emulating even older apple devices (Clickwheel iPod), I worked on an emulator for a few months called `clicky`. Very nifty project, given the weird and undocumented architecture of those early iPods
Any chance I could borrow this code for my (very WIP) classic clickwheel iPod emulator? I've actually got an experimental WASM build of it up and running, so this would be super appropriate!
Just to clarify, the first link is me and my teammate who developed this at https://www.ae.studio but with that said, you are correct that we didn't include the license from work we leaned on, we hadn't added any documentation to Github yet. We'll update it to reflect that.
One of the coolest technical aspects of early Infocom text adventure games is that most games weren't actually written using native assembly code for the platforms they ran on, and were instead compiled down to "z-code", a bytecode which ran on the "z-machine" virtual machine architecture. Z-machines are pretty niftly little bits of tech, as while they have a lot in common with regular 'ol machine code, the z-machine spec also includes dedicated instructions for fetching text input from the user, outputting text to the console, saving/loading data to disk, etc...
Having games target the abstract z-machine platform made it incredibly easy for Infocom to port games across platforms, as instead of re-writing every game from scratch, they could simply write a z-machine interpreter for said platform, and immediately gain access to their entire adventure game catalog!
A happy side-effect of all this is that it's super easy to run these classic adventure games on modern platforms, as instead of emulating the UI/UX of a 80s microcomputer, it's possible to write a z-machine interpreter that takes full advantage of modern GUIs.
One of my personal favorite modern z-machine interpreters is `encrusted` [1], which is written in Rust that runs on the Web thanks to WebAssembly. As a fun side-project, I ended up forking the project and making `embcrusted` [2], a z-machine interpreter that can run on embedded platforms without a full C-library. In a weekend or two of hacking, I was able to port a z-machine interpreter to my mechanical keyboard, in order to get the "authentic" experience of playing a text-adventure game through a teletype :)
I was reading an article about the Z-Machine recently [1], and I was quite surprised that in addition to being a virtual machine, it also implemented virtual memory! Thus, pages could be swapped in and out of disk as needed. (Since CPUs like the 6502 didn't have a hardware MMU, I guess this was an explicit software step -- i.e. a called function that would check if the page was loaded, and if not, arrange for its load.)
With a virtual machine, virtual memory, and (for the time) a great natural language parser, it shows that the Infocom folks learned their craft in world of academia, high-end computer hardware, and ideas, instead of the more amateur (at the time) world of microcomputer enthusiasts.
While cool in a way, it was also annoying that infocom games in the day took several seconds, then started the disk to load whatever the next response was.
The limited parsers of the competition responded almost instantly to input. The limited parsers were enough for everything needed, most everyone I knew just used the two word sentences even though more complex ones would work.
> then started the disk to load whatever the next response was.
In addition on some systems with smaller disks (eg. C64) needed the story file to be split up over two disks, because the story file and interpreter wouldn't both fit on one disk. So you were switching the floppy disk at various intervals as well. With the C1541 being no speed demon to begin with it was not fun. I remember being much happier playing it on CP/M and DOS machines later.
I used to play a lot of z-machine text adventures on the original iPod Touch with an app called Frotz. It was pretty cool to see stuff from the 80s running on a modern tiny portable computer like that.
In my youth I used to use BCD to handle large numbers and mathematics, so bit/byte representations have always been of interest. In that regard, I really appreciated the Infocom text compression.
Use your favourite seach engine to look up ZSCII which, roughly, is three characters per two bytes (five bits each) with special markers to switch between three different 'alphabets' for what characters the ZSCII bits represent.
Edit: Coincidentally there's a British quiz show called Only Connect, and a few days ago one of the contestants offered xyzzy as an answer to a question where they had to provide the fourth entry in a sequence. The host had never heard of it, and expected a different answer, but it fit and they got the points.
[clicky](https://github.com/daniel5151/clicky) is an emulator for Clickwheel iPods I worked on in the many boring months between University graduation and starting full time work.
Unlike retro consoles/handhelds, there doesn't seem to be much nostalgia in the public consciousness for OG iPods - which is fair, given that most people just see them as antiquated MP3 players. That said, some of the later models did have some pretty neat little games which have yet to be preserved, and can only be played by owning the original hardware.
It was a lot of fun hacking away at the project, and I'd made a surprising amount of progress given that I'd opted to roll my own full-system emulator (in Rust!) as opposed to using something like QEMU.
Who knows, maybe when I have more free time I'll revisit the project and keep pushing it closer to completion. Not sure when though - emulation is a real time hog when you're also juggling a full time job!
I actually had to wrestle with this exact effect while working on wideNES [1]. By saving a screenshot of the screen at each frame alongside with it's PPUSCROLL value, it's possible to gradually build-up a map of the level as it's explored. Moreover, on subsequent playthroughs of the same level, it's possible to sync the map with the on-screen action, effectively enabling a "widescreen" mode for old NES games (with certain limitations).
Lots of games used funky scrolling mechanics, typically to create status bars, but of all the different games I tested with, TLOZ was by-far the weirdest, requiring an entire special case to get working!
I don't have any screenshots of my own, but some japanese website recently covered wideNES, posting screenshots of it working with the original Legent of Zelda.[2]
Sometimes is really expensive for the server to determine the size of the response before actually responding, e.g. some database lookups where it may not be known how many rows are returnable until the lookup is actually done.
Then there are situations where response content length is not known, such as streaming over HTTP.
Last, if a certain "Accept-Content-Length" became standard, like 8MB, developers (such as those for the ad industry) would just create javascript libraries that would download large files in 8MB chunks and sidestep it.
You could probably run an async loop which slices up painted frames and compares hashes of the slices to find identical slices to anchor and stitch similar frames together, still maintaining separate layers in case a better match is found later on. Something like that should solve for games like SMB.
https://github.com/daniel5151/clicky