|
| |
|
Infocom EasyFlash Collection V3.1 [2014] |
Credits :
No credits found
Download :
Look for downloads on external sites:
Pokefinder.org
Summary
Submitted by hedning on 8 February 2016
"I have disassembled, dissected, and modified the latest officially-released C64 interpreters to work with the uIEC without REU, and high-storage Commodore drives with REU or GeoRAM. The v4 interpreter allows the C128-only games to work on a C64.
Infocom games, as released for the Commodore 64, are very tied to the 1541 disk format. Commodore didnt believe that random-access files had any purpose, so the Infocom engineers were forced into using raw-sector access schemes to jump around in the story file. When the REU was released, Infocom modified the interpreter to load the entire story file into RAM, but continued using the raw-sector disk format to maintain backwards compatibility for non-REU owners.
This, naturally, makes playing these games on non-1541 drives somewhat unpleasant. One would have to use d64 emulation, swap virtual floppy images to save games, and so forth.
I have an uIEC. In fact, I have several. I love the uIEC. And I wanted to be able to play Infocom games on it, with as little effort as when I play on a UNIX workstation.
To that end, I have disassembled, dissected, and modified various revisions of the C64 v3/v4/v5 interpreter to work with the uIEC (and other large storage devices). It requires a REU.
Notes:
The 1541/1571 fastload routines were removed.
The story file is loaded from STORY.DAT instead of raw blocks.
To accomodate the above, an REU is now required.
The number of save slots has been increased from five to nine.
Save games are 49-block seq files named SAVEn, where n is 1 through 9
The game can be run from any device number, not just device 8.
REU mirrored register access has been fixed.
TODO: use George Hugs 2400bps RS232 routines to replace printer code
TODO: C128 80 column support
Trivia:
The v4 interpreter, as sourced from the Nord and Bert d64, does something really interesting with the resident size when setting up the virtual memory scheme. If you look at a non-C64-sourced version of N&B with infodump, youll see that the resident size is hardcoded to $AEFF.
Forcing that value with all other v4 games results in a working game, even if the resident size overflows available physical memory. The interpreter already assumes that anything over $F900 (start of $3A00, skipping $D000-DFFF) needs to be paged in from REU/DISK, even if it is resident.
This implies that the lack of support for v4 on a stock C64 was not due to lack of physical memory, but rather lack of available disk space. Infocom could have supported the C64 on all of the eight-bit titles that it released, if theyd embraced the 1581 or went to a multi-disk scheme.
Theres a fair amount of weird stuff in these interps. Theres orphaned code fragments in v3/v4, a Test1 string referenced nowhere in v5, and Im still trying to understand why the author(s) went to separate hi/lo jump tables in v4/v5 rather than continuing with the unified tables in v3.
I have read that the fabled Infocom backup drive that surfaced a few years ago includes complete source code to the various interpreters, including the ones Im reverse-engineering. Id very much like to see that source code.
They made a mistake with the latest official version of the v3 interpreter
since the $DF00 range isnt completely decoded by the 64, there are mirror registers every thirty-two bytes. The v3 interpreter uses $DF28 instead of $DF08 in several places. This isnt a problem with original hardware, but things that emulate the Commodore REU (particularly the 1541-Ultimate) fully decode that memory page. People needing fixed d64 images (i.e., those using the 1541-Ultimate or an emulator) can obtain fixed images here.
The interpreter source code has been sanitized; it lacks all of the #ifdefed code that made it possible to generate the original unmodified interpreters from these sources. That means that the weirder original implementation oddities arent included. I can/will make that available later
it was interesting reading.
Ive concluded that the Apple ][ target was the reference platform, and other 6502 ports were derived from it with differing degrees of Apple-specific code accidentally left in the Commodore versions.
Also, the guy(s) who hacked the Commodore code into the v4 (and by extension v5) interpreter was probably an intern, not terribly familiar with rational code flow. And I do mean hacked subroutines will suddenly jump past a bunch of unrelated code, the elegant word-based jump tables were deprecated in favor of split-byte jump tables, and there was some unholy stuff going on in the virtual-to-physical-address logic. Most memorable was the bit that asked which of seven slots the printer was at.
While I was looking at the SD2IEC docs to see if UI or UJ was the preferred way of getting a 73 status for identification, I noticed this:
Positioning doesnt just work for REL files but also for regular files on a FAT partition. When used for regular files the format is P+chr$(channel)+chr$(lo)+chr$(midlo)+chr$(midhi)+chr$(hi) which will seek to the 0-based offset hi*2^24+midhi*65536+256*midlo+lo in the file.
which means that running from the uIEC doesnt require any RAM expansion. We can just seek to the proper offset in the story file. Itll be a tad slower than running from REU/EasyFlash/GeoRAM, but itll work.
The banking/addressing scheme for GeoRAM is exactly the same as for EasyFlash, so I have implemented that also. Its actually slightly faster than the Commodore REU.
"Saving game files to EasyFlash will not be implemented, at least not by me. Here's why:
The EAPI requires three pages. With careful pruning, I think I can free up enough memory between the end of the interpreter and the beginning of the resident data to accomodate that. I'd remove the printer transcript routine (which I suspect wouldn't be missed), relocate the story selection menu to ROM (where it should be anyway), and a couple of other optimizations.
The self-imposed constraint that I'm working with here is that there will be one executable per version that handles all hardware cases -- uIEC-only, uIEC/REU, uIEC/GeoRAM, uIEC/EasyFlash, EasyFlash-only. This is to make my life easier, as I was having a hell of a time keeping things straight when everything was selectively #ifdef'ed for specific hardware.
I believe that I can bump up the resident start address a page or two. I've tested this with the v3 interpreter with no apparent ill effects, and I don't believe that there are any v3 story files floating around that even come close to hitting the $D000 cutoff. I haven't tried this with v4 or v5 yet.
The second bullet point is a bit more troublesome. The save files are essentially a memory dump of the entire Z-machine state. That's 52 blocks for v3 (so 13k), 66 blocks for v5 (so 16k), and a whopping 131 blocks for v4 (so 32k). Setting aside three to five extra banks per game for savefiles is doable but would permit fewer story files per image.
I honestly think it's better/safer to keep the EasyFlash as a read-only REU substitute, keeping save game functionality on the serial bus. This project started as a way to play Infocom games on the uIEC (with the nice side-effect of removing the need for RAM expansion); since the EasyFlash and the GeoRAM share identical paging schemes, read-only EasyFlash support was easy. Writing save game files to EasyFlash will significantly shorten the lifespan of the EasyFlash and severely reduce the number of games per image. Sorry." |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
