Anybody here with Apple ][ experience?

Technical Development Interpreters
81

Your profile photo suggests you are younger than me. And kids didn’t have much use for ProDOS. And I was a kid in those days, too :slight_smile:

ProDOS was basically that file system where, if I copied a binary pirated game onto it from DOS 3.3, the game no longer worked. I learned much later this was to do with the games placing themselves across memory areas reserved by ProDOS.

For adults using word processors and stuff, the storage niceties of ProDOS plus having directories and file metadata was probably all great.

I never really learned much about ProDOS 'til I wrote my Apple II IF Leadlight. That’s when I discovered the BASIC garbage collection in DOS 3.3. could take seconds every turn when RAM was full (which was straight away) whereas the garbage collection in ProDOS was instant and invisible. So I moved the game to ProDOS early.

-Wade

1 Like
82

LOL, my profile photo showed up as a default because of some random google account I set up 15 years ago, so it’s an old picture. I’m old enough to have been working the same day job for 30 years.

1 Like
83

ProDOS would make it easier to use a large story file (bigger than what DOS 3.3 could support). It could jump to different parts of large story file and load the required code into your Z-machine interpreter’s memory. You wouldn’t have to deal with sectors (or blocks as in ProDOS) directly. But, it’ll cut into the amount of free space for your interpreter.

1 Like
84

Hmm. Doesn’t ProDOS usually live in the language card? Right now my interpreter is about 8k and lives from E000-FFFF, and I bank all memory between 200-BFFF since it’s the largest contiguous region. Now I currently don’t use any of the aux memory above D000 because that’s where my interpreter is running from. But if ProDOS ran from there, and could fill memory from secondary storage for me without eating too much of the 200-BFFF region, that’s a possibility.

I guess the other issue is then my interpreter is no better than a hacked-up Infocom interpreter if it’s depending on somebody else’s copyrighted OS image.

Keeping in the style of the rest of my interpreter, I was hoping some of these modern secondary storage solutions might expose “media” larger than 140k through a ROM interface in the C100-C700 area.

Hmm, poking around a bit, the description for Total Replay says:

Total Replay runs on any Apple ][ with 64K RAM and Applesoft in ROM. Some games require 128K. Some games require a joystick. Total Replay will automatically filter out games that do not work on your machine.

Additionally, you will need a mass storage device that supports SmartPort calls and can mount a 32 MB ProDOS hard drive image. This is supported by all major emulators; if you are lucky enough to have a real working Apple ][, you can mount it with a CFFA3000, Floppy Emu, MicroDrive, BOOTI, Xdrive, [SP]SD, or similar adapter.

So I need to figure out how to make SmartPort calls, hopefully without a full OS install.

Looks like the Apple IIc reference manual documents SmartPort calls. That’s exactly what I need here, and instantly simplifies my life trying to access more than 140k. I’ll probably need to have a version that uses Disk ][ stepper motor etc directly for Z3 stories and maybe Z5 stories (using both drives to get up to 280k of storage) but for Z8 at least I think only a SmartPort makes sense.

-Dave

85

Okay, thanks to all the wonderful feedback on this thread, I’ve been able to focus on the Apple 2e (128k, no more) as a suitable target platform.

Now, my next question — how many Apple 2-era machines still in use today have some way to support SmartPort? From what I can tell, most/all modern secondary storage devices that make a compact flash card of some kind look like old media all use the SmartPort protocol, which also seems to be quite simple to use at least at the block level.

(Essentially, I would probably support Z3/Z5 stories on either Disk ][ or SmartPort, but Z8 stories would definitely require SmartPort unless somebody has a better idea)

(And honestly, Z5 would be easier to support only on SmartPort as well, otherwise the story file has to be split across two drives and my control logic gets a lot more complicated)

Thanks,

-Dave

86

Most Apple II software comes on 140KB disk images, so that’s the default setup (whether physical or emulated). The IIe requires special hardware to support SmartPort, so my impression is that most active IIGS users have some kind of (usually emulated) SmartPort hard drive, but most IIe users do not.

Infocom’s solution for Z5 was to load all memory-resident parts of the game from Disk 1, ask the user to switch disks, and then do any subsequent disk paging only from Disk 2. This requires only one drive and no special logic, so this is my preferred solution. (Dual-drive setups used to be standard for business software, but the games market tended to target single-drive setups as the lowest common denominator, so a lot of games machines today only have one emulated floppy drive.) Whether you can actually run a full 256 KB game this way depends on the terp design and memory layout; Infocom’s Z5 interpreter used a custom 18-sector format to fit more data onto Disk 2, a technique which also doubled as copy protection.

3 Likes
87

If you have two drives, you want to keep a save disk in the second one, anyhow.

2 Likes
88

They do support the SmartPort protocol, but that’s in addition to having a Disk II protocol for machines which don’t support SmartPort. Which as prevtenet indicated, is effectively most pre-IIGS machines.

-Wade

89

Okay, so SmartPort isn’t the panacea I was hoping it would be.

I guess I need to figure out what the biggest V5 stories were that were released on Apple 2.

My plan was to load the first 44k of the story into memory (main 44k), and then the aux 44k would be used as VM backing for the remainder of the story.

If Infocom managed to cram the rest of the V5 story onto a second disk, then they presumably loaded more than 44k of the story in order for that to happen.

18 tracks is 4.5k per track instead of 4k, or 157.5k for a standard 35 track disk. Even if I loaded the first 88k of the story into permanent memory, and used the 4k banked (8k total) as my entire VM backing, I don’t think I could handle a full 256k story file (256k-88k is 168k, and the disk holds 157.5k)

So I’m guessing the practical story limit was smaller than that. But trinity is 261,484 bytes (story length 0x3fd6c) so that blows that theory? They must have figured out how to get more than 157.5k on that second disk, or you had to swap disks occasionally?

Right now my design doesn’t use the aux language card memory, because that’s where my interpreter is running from, so that’s 16k I’m effectively wasting. That 16k could contain more of the static story data, but it’s backed by the VM system since it can’t be read directly.

So I load the first 44k of the story into main memory (1000-BFFF), then the second 44k of the story into aux memory (1000-BFFF), then the next 16k of the story into aux language card memory. That means 104k of memory is filled with static story data. Then I use the 2 x 4k language card banks at 0xD000, and the 2 x 2k at 0x0800-0FFF (both main and aux) as 12k of VM backing store for the remaining 152k of story data on the second disk.

(Or let 156k live on the second disk, and only load 100k of story data, leaving 4k more for backing store)

That 16k of story data in aux language card memory would only be accessible through the VM system (but is still faster than pulling it in from disk).

So… yeah, it’s doable. You’d have to swap disks on a single drive system to save though.

(Looks like a combination of either using 40 tracks instead of 35 tracks, and/or spacing tracks 0.75 tracks apart instead of a full track - given that you won’t ever be rewriting them again - are other options). 35 tracks becomes 46 tracks if you space the tracks closer together, and would let you put 207k on a 140k disk, read-only. Wonder if that actually works on most hardware, or more to the point, works on modern flash-based emulations. Does the WOZ format support more than 35 tracks? Yeah, it looks like it does.)

Just found this… https://www.kansasfest.org/wp-content/uploads/apple_ii_inform_paper.pdf which indicates that the Infocom V5 interpreter would load the first 98.5k of the story, meaning they always left the remainder of the 157.5k on the second disk. Those are pretty close to my numbers above.

90

So my next question is… which is more likely to work on actual hardware:

  • Using 40 tracks instead of 35
  • Using three quarter tracks

The latter seems a little dicey, honestly, since normal tracks are two stepper motor phases apart, meaning you’d need to align to a 3/4 track by keeping two adjacent phases active to split the difference.

91

You’re askiing pretty specialist questions now that few are likely to be able to answer!

On real hardware, we know normal drives can handle 36 tracks. 37 is starting to take liberties. 40, you’ve knocked out most older drives, probably more. So compatibility’s starting to dive.

Re: three quarter tracks, one of the premier crackers of Apple II software said ‘The reliability of three-quarter tracks is questionable.’ Admittedly they said it in brackets. They said it in a super in-depth article on deprotection in this very weird PDF.

The article also discusses a technique Infocom used to fit a Mind Forever Voyaging in less space on the Apple II, saying they used a combination of custom track-sized-but-slow-reading sectors, and having the player reading prose while some loads were occurring.

-Wade

1 Like
92

I dunno, you came up with some pretty good answers there in my opinion!

But realistically, I’ll stick to 18 sectors per track since that’s enough for Z5 games.

Z8 games will probably only run on an emulator or something with SmartPort support. But from what’s been said above, it sounds like most Apple 2e’s don’t have native SmartPort support and the typical hardware to emulate drives doesn’t automatically grant it.

Thank you.

-Dave

1 Like
93

A few adjacent comments -

  • In practice, maintaining a decent cache size may end up being more important for floppy-based playability than strictly supporting 256 KB games. 90% of I6 Z5 games are under 200 KB, but most are not optimized for disk layout, so they may grind too much to be playable anyway with a small cache. But, experimentation required.
  • Emitting weird track formats to .NIB/.WOZ files works, but will somewhat reduce compatibility with user setups. The situation has been improving over time, but I still see a lot of “I can’t figure how to load .NIB files” threads in user groups.

For new PunyInform releases (which are likely to be your biggest user category) the ideal release format is probably two 140 KB .DSK images for a .Z5 file that would typically be <150 KB. This would significantly improve compatibility over the existing Puny-BuildTools target (which I think uses Vezza and requires a Z80 softcard?) But, this approach wouldn’t work for large Z5 files like Curses.

3 Likes
94

Can anybody point me at documentation on how booting from SmartPort devices work? By tinkering with Virtual ][, it seems like the first 1024 bytes of an .hdv file is loaded into memory at $800, although I’m not sure what happens after that. In particular, the byte at $800 doesn’t seem to matter (it’s not a sector count like it is with $C600 boot routine), although it looks like it still jumps to $801 to run your boot code.

I assume after that, you make further SmartPort calls. It seems like SmartPort is supposed to be at $C500, but I imagine the correct address is made available, perhaps in the X register?

Thanks,

-Dave

EDIT - Did some more testing. Execution definitely starts at $801, and the value at $800 doesn’t seem to matter. The loader seems to load four sectors, in order, from the start of the .hdv file, without any ProDOS interleave. Actually, the value at $801 seems to have to be 1. On entry, A is 1, which might be the SmartPort unit number we’re booting from. X contains $50 if the SmartPort was in slot 5.

95

Okay, so I foolishly trusted the google AI summary and big surprise, it’s wrong.

.hdv files are not in ProDOS order. They are just a linear disk image, which means they can trivially support Z8 files. Boot code seems to load the first 1k at $800 then jump to $801. So from there I copy my code up to the language card and then read the rest of the interpreter to there and then read the story file into memory like before.

My plan is still to come up with a two-disk solution for Z5 files but I can do that once everything else is solid.

1 Like
96

Managed to get SmartPort reads working, and chased enough bugs out of my VM implementation (and had to dummy up @sound_effect) so that Lurking Horror works. Nothing that wasn’t a solved problem in 1987, but still the most complex piece of assembly language code I’ve written in my 45-ish years of computing.

Trying to mentally prepare myself for rewriting all the property and object routines to support V4/5/8 since that’s the next logical step. Performance on Lurking Horror already isn’t fantastic but it’s certainly playable.

(I have three memory models currently - 0, which has no aux memory support and the game must be 44k or smaller, 1, in which the game must be 88k or smaller, and 2, which supports up to 128k with VM; the first 44k of the story is permanently resident, and the aux 44k provides VM backing store)

-Dave

2 Likes
97

So from your last couple of posts, are you saying you discovered the .hdv file format doesn’t actually have any particular operating system requirements? Does it require Smartport access or no?

-Wade

98

I’m going off how Virtual ][ behaves. If I put an interleave in the data like I did for disk images, it didn’t work. The only way I can mount an hdv file there is as an “omnidisk” under an emulated SCSI card on a 2e.

Reading up on the various modern replacements they seem to happily emulate anything. Some of them require separate smart port “hardware” in a different slot (softSP).

Dave

99

It’s been slower progress the last few weeks, but steady. Getting Z4/5 functionality in place, with my goal still to be Anchorhead playable on an Apple 2e (with SmartPort, since that’s the only thing large enough to hold the story file). I have object functionality pretty much complete, just working through the necessary changes to my property routines.

-Dave

3 Likes
100

David, I just wanted to thank you for making this project happen! I have several classic Apple //s (//gs and //c), and it’s great to see this work filling a need for the Apple II. Very much appreciated.

4 Likes