Aug 162014
 

For no particularly good reason I found myself looking at the boot code for Jordan Mechner’s Prince of Persia, the source code for which was released to the world a little while back. I was flipping through the protection code, and found a comment that said “Motorcycle disk drive“.

Pop motorcycle disk drive

A quick glance at it revealed that, indeed, it is code that is designed to make your disk drive sound like a motorcycle. It pulls the drive head back until it starts hitting the edge and keeps going, which is basically the same thing that happens when you boot a disk (causing the characteristic Apple II booting noise from the drive). This differs only in that it is using specific delays (controlled by paddle zero) to alter the frequency of the motor turns.

That’s kind of a weird thing. When does this get executed?

Backing up a bit, I saw that when the protection check succeeds, control passes to the point labeled “:yippee“, which does the following thing: Check to see if both the open-apple and closed-apple keys and one other key is pressed. If not, everything proceeds as normal, but if so, look up the key in a dispatch table (just below the code pictured below) and jump to the address in the table.

Pop dispatch

Looking at the dispatch table, it has a few different vectors in it. One of them is for “^” which has the address for the motorcycle disk drive routine in it.

Pop dispatch table

So, if you’re holding down (open-apple, closed-apple, and) ^ at this point very early in the boot process, the code to make your disk drive sound like a motorcycle will be executed, rather than Prince of Persia. (This code is quite likely actually written by Roland Gustafsson, rather than by Jordan Mechner, since Roland was mostly in charge of dealing with the disk drives as I understand it.)

There are in fact a couple of other Easter eggs available at this same point in the boot process. OA-CA-return will give you “confusion” and OA-CA-@ will give you “rotcube”, both graphics demos, and OA-CA-! will print a little message from Jordan (Mechner) and Roland (Gustafsson) to Robert (Cook?) dated 8/25/1989 wishing him well at college and then show some randomly colored blocks.

I have yet to see these run in meatspace, though I’ve hand-assembled the motorcycle code and tried it out on an emulator. Which is a ridiculous thing to do, really—this is code that uses hardware banging against other hardware to make a noise. However, if you can compile it, OpenEmulator does in fact do a good job of emulating the sound, though Virtual II didn’t manage it despite otherwise being pretty accurate with its emulated disk noises. Copying and pasting the assembly code below at the monitor prompt will get you the hand-assembled program, though:

6000: A2 60 BD 89 C0 BD 87 C0 BD 80 C0 20 2C 60 BD 85 C0 BD 86 C0 20 2C 60 BD 83 C0 BD 84 C0 20 2C 60 BD 81 C0 BD 82 C0 20 2C 60 4C 05 60 A9 06 85 00 2C 70 C0 EA EA 2C 64 C0 30 F9 C6 00 D0 F2 60 N6000G

The other Easter eggs would take too long to hand-assemble, and I haven’t yet imported the PoP code into a compilable form for any assembler, so I’ve left it at that for now. If anyone has a real disk, real hardware, and a video-capturing machine, I’d be interested to see these Easter eggs actually being triggered.

[Update: Antoine Vignau pointed out that the secret keys were already documented in the crack documentation, and pointed to a disk image that allows you to play with the Easter eggs by pressing 1-5 upon startup: Brain Trust's Prince of Persia crack. Still was neat to discover myself, of course!]

Jun 252014
 

I recently got ahold of a couple of CompuMart catalogs, sent to me from across the country. Ironically, the actual CompuMart location was only about a 10 minute drive away. I know nothing about it, but I can see on Google Maps that it is clearly long gone.

Compumart 2014 gmap

But never mind. I have no knowledge of CompuMart apart from these catalogs, but the catalogs are pretty cool. A very compact collection of information, pictures, prices on quite a wide range of computers of the early 1980s. The Summer 1980 edition pre-dates the Apple ///, and the Winter-Spring 1980-81 issue announces the Apple ///. Also included are KIM-1 ads, Atari, Commodore PET, HP-85, really quite neat.

So, without further ado:

  • CompuMart Summer 1980 Microcomputer catalog (300dpi, or 600dpi)
  • CompuMart Fall-Winter 1980-81 Microcomputer catalog (300dpi, or 600dpi)
Compumart summer 1980 Compumart fall winter 1980 81
Jun 122014
 

Pretty much everybody in the Apple II community is aware of Beagle Bros, the prolific and playful early software company with a sense of humor and a hacker spirit. But it’s probably not nearly as well known that they actually did test the waters with an IBM PC title as well. FileMover was that title. I got ahold of a copy of it, kind of crushed but still shrink-wrapped.

Filemover box wrapped Page 1

This thing is rare. To find one still wrapped is even more rare, but it doesn’t do a lot of good wrapped. So, I opened it up, and here is what I found. First, the box panels:

Filemover box Page 1 Filemover box Page 4
Filemover box Page 2 Filemover box Page 3

Inside the box was the disk, along with a little insert with instructions (though still Apple-centric) on what to do if the disk goes bad, a sticker, the manual, and a wall poster. With Apple titles, the wall poster was generally some useful programming information, likes “Peeks & Pokes” or 6502 opcodes. In the FileMover package, the wall poster has some Pascal programming information on one side, and the disk treatment warning graphics on the other.

Filemover disk Page 1 Filemover disk Page 2
Filemover disk problems Page 1 Filemover disk problems Page 2
Filemover sticker Page 1 Filemover sticker Page 2
Turbo pascal poster Page 1 Turbo pascal poster Page 2
Filemover manual  

The program itself is a relatively straightforward file handling utility, allowing you to delete files, rename them, move them around, etc.

Filemover splash
Filemover directory

The disk includes the Pascal source code for the program, as well as a couple of other things. There’s actually an “Easter Egg” of a sort as well. There’s a hidden file called DONTREAD.ME, which you can see in the file listing above, but which does not appear in a regular DIR of the disk. If you TYPE DONTREAD.ME, you get a secret message. I’m going to reveal it here.

Filemover dontread me

Anyway, although the program itself is ok, it’s probably mostly interesting due to the fact that—as far as I know, at least—it is the only program Beagle Bros ever released for the PC. And the Pascal source code is probably interesting to look through as well. Someday I might do that.

Here are links to all the stuff. When I tried to run this under FreeDOS, it didn’t work, but it did work under DOS 3.3 at least. I captured the disk image using a Kryoflux, although the image is not protected. At the moment, the disk image is a bit larger than it needs to be I think, but it did work under emulation.

Jun 112014
 

I’d always been fairly aware of the Peelings II magazine back during the early 1980s when the Apple II was going strong, because they advertised fairly aggressively in things that I did read, but for some reason I’d never really read any of the issues. Probably this is because the magazine wasn’t sold on any newsstands I had easy access to, and I was never motivated to subscribe. Looking at it now, though, it’s pretty interesting. It’s essentially a magazine of reviews, and as such, it provides quite a bit of useful information for the modern-day retrocomputing enthusiast.

Peelings ii v4n1 7

I looked around a bit, but I couldn’t find any issues scanned online. I have exactly seven issues of the magazine, the first 7 issues of 1983. The issues don’t have dates on them (apart from “1983”), but it appears that Peelings II came out 9 times per year.

So, I scanned the ones I have. And they are linked below. They’re scanned at 600dpi, so the files are fairly large.

Peelings ii v4n1 Peelings ii v4n2
Peelings ii v4n3 Peelings ii v4n4
Peelings ii v4n5 Peelings ii v4n6
Peelings ii v4n7  
Jan 232014
 

Softalk was one of the most highly regarded computer magazines focused on the Apple II series of computers, running from September 1980 until August 1984. They’ve been mentioned here before. In the later years, however, the publishers branched out to a couple of other platforms. There was a second magazine called Softalk for the IBM PC, which was—well—Softalk, for the IBM PC. But there was also a Softalk magazine devoted to the Mac, upon its release. This was ST.Mac, which is etymologically “Softalk” with a filetype/extension “.Mac”, although it also seems to have gone by “Saint Mac” as well.

Stmac

ST.Mac launched just after the original Macintosh did, its first issue covered February 1984. Monthly issues followed, although unfortunately not for long—the whole Softalk enterprise pretty much stopped after August 1984, including both the original Apple II Softalk magazine and ST.Mac. So, all in all, there only were seven issues of ST.Mac, which might explain why even Mac enthusiasts often have never heard of it. I certainly hadn’t until pretty recently, despite having loved the Apple II Softalk for over 30 years.

The magazine is primarily focused on the Macintosh, but also considers Lisa within its scope, and it’s one of the best/only places to find magazine print ads relating to Lisa products. It’s also interesting to see some of the contemporaneous discussion, not all of it positive. I can say myself, having been fairly deep into the Apple II world at the time of the Mac’s introduction, that upon my first experience with a Mac (I think it may have been a “Fat Mac”, the second iteration that had 512K rather than 128K), I wasn’t actually swept away in the way people were supposed to have been. As a child (but one already pretty handy with the command line), it felt kind of slow and limited. True, there were a lot of dots per inch, but I still took it to be mostly a toy computer aimed at novices, and I pretty much ignored it for the next five years until I the Macs gained software and traction and speed (at which point I bought the SE/30, which I still consider to be basically the pinnacle of the compact Macs). And some of that kind of reaction can be seen in some the letters that got printed in ST.Mac, too, though of course the focus of the magazine was mostly the positive and new developments on the Mac platform, right as it was getting its start.

Anyway, I have now scanned the entire short run of this little magazine, and it is definitely interesting to read in retrospect. So, without further ado, here they are. The main links below are to the smaller 300dpi scans (around 70MB), and better, larger, 600dpi scans (around 260MB) are linked separately if that’s of interest.

Stmac feb1984 Stmac mar1984
Stmac apr 1984 Stmac 1984 may
Stmac 1984 jun St mac 1984 jul
St mac 1984 aug  
Jan 202014
 

Here is Quick File /// for the Apple ///. I imaged the disks and scanned the manual, since I didn’t find an existing manual scan online. The disks weren’t protected, and were actually already available on apple3.org, but these are (presumably identical) images of my own disks. The program does work in Sara OS X, but note that in order to get the “tab” key to work, you need to press Ctrl-I, since pressing the actual tab key seems just to emit an “i” character.

I have two of these, one open, and one still wrapped. The open one didn’t have the slipcover, and I haven’t convinced myself to open the wrapped one yet. So there is no scan yet of the slipcover, but I may either open it or try to scan through the plastic.

Qf3 box wrapped

Nevertheless, this is what I will find inside the box if I wind up opening it:

Qf3 box open

Strangely, the manual is called Quick File /// Sampler. It sounds like that would be some kind of auxiliary manual used to point out aspects of the example files, but it is in fact the only manual there is with Quick File ///.

From playing with it briefly, it seems like it’s a pretty well-thought out database system, given its goals. It’s not a spreadsheet, but it can do basic total calculations in reports, and there is no kind of cross-table linking or relations. It also seems particularly novice-oriented, there is quite a bit of onscreen help and opportunities to undo mistakes.

Qf3 splash

Qf3 sues cards

Anyway, here are the files:

Qf3 manual Qf3 addendum

Qf3 boot disk

Qf3 program disk

Qf3 sample disk

Qf3 packing list Qf3 sla Qf3 auir
Dec 142013
 

I finished up a few more scans of On Three, so here they are. I decided in the interest of collecting things together that I would post the whole volume in this post. I still need to scan June 1987 and re-scan March 1987, I’ll insert them in this post later once I have. I have also put up a static page with all of the scans I know about collected together for convenience.

Mike Maginnis scanned and posted a few of these issues earlier, which then made their way onto the asmiov Apple II archive site. I’ve fetched those for this collection—the ones Mike scanned are marked in the list below with an *.

On3 v4n1 On3 v4n2 1987 On3 v4n3
On3 v4n4 On3 v4n5 On3 v4n6
On3 v4n7 1987 On3 v4n8 1987 On3 v4n9
On3 v4n10 On3 v4n11 1987 On3 v4n12 1987
Dec 142013
 

Back in the summer of 1987 or 1988 or so, my family took a road trip across the country. This was a painful prospect, I couldn’t possibly bring my computer with me, and it wouldn’t be a lot of good anyway for the car. Fortunately, a business colleague of my mother’s had a programmable calculator to lend me for a couple of weeks. This was the Casio FX-730P.

Fx730p side top

I played a lot with this on that trip, although I don’t really remember what exactly I was doing with it, just remembered the ability to program on the road fondly. But now, 25 years on, I wanted to get one again. I didn’t know the model number of course, and looking around now, it turns out that there were many of this type of programmable calculator made at around that time. But, although perhaps it is just the fact that this was the one I learned on as a child, I find most of the other ones kind of ugly by comparison. I really like the colorful function bars, the placement of the keys. It’s one of the nicest looking in its class I think.

The FX-730P has 8K of memory built in, although it can be expanded to 16K with an additional RAM module, and it has a connector in the back for connecting peripherals such as a printer and a tape recorder for loading/saving data and programs. A little while back I tried to get a Raspberry Pi to communicate with the FX-730P, although I didn’t really get off the ground. It is not easy at all to find the peripherals for this thing now, though, so trying to do some kind of modern interface is probably where the future lies.

I do however have the box and manuals, which I’ve scanned. There is an existing scan of the manual out there, but it’s pretty low-quality. This one is much better, though it’s bigger. I may re-scan a couple of pages of the manual at some point, but for now:

Casio fx 730p box and contents

I haven’t really done much with this yet, apart from typing in some of the example programs from the manual, but I am looking forward to playing with this more. The inability to load and save things might drive me to resume the tape interface project again sometime soon, we shall see. More as it develops.

Dec 112013
 

I tried making some nibble copies of Origin Software’s Autoduel to run in an emulator, and of course it didn’t work. So I figured I’d try my hand again at boot tracing. Tricky stuff. There are a couple of hints out there about how to make the Autoduel disk copyable (see Computist #38, which refers back to the Ultima IV soft key in Computist #28, and “Toinet”‘s discussion of Ultima IV), but for the most part they don’t talk about what it’s doing, they just talk about the end result, what you need to change to defeat the copy protection. I will instead see if I can delve into the copy protection itself.

Using Virtual II’s Inspector, I managed to trace a bit down. It is kind of long and involved figuring out what everything does, even when it turns out to be innocuous. Let me just hit the highlights here.

When I try to boot the nibble copy, it just hangs. Why?

When it boots, it starts at $801, which loads in a few more sectors, and then jumps into it at $B700. The first kind of neat trick they did here is that the 26-byte program at $B700 takes everything in memory from $B71A onward and EORs it with $E6. So, you wouldn’t be able to find the code on the disk, because it’s all been (weakly) encrypted. Once the decryption is done, execution falls into the decrypted code at $B71A.

Autoduel decrypt b700

If we set the breakpoint at $B71A and let the decryption execute, we get much more sensible code there.

Autoduel decrypted b71a

Now we can actually look at what’s happening. And I did, but I won’t go into all the gory details here. The code at $B71A basically sets a bunch of parameters (and disables Reset), calls $B793, and then goes to $9D82, which is surely a DOS 3.3-like entry point. So, the next bit of trickery to be concerned with is what happens at $B793, where the rest of DOS is loaded.

The instruction at $B793 is just a JMP to $B800, but the first thing that happens at $B800 is that it goes back and modifies $B793 so that it starts with a LDY $B7E5 instead of a JMP $B800. So $B793 will be a useful routine, in fact it is going to be where execution continues shortly.

Autoduel address check b800

After it’s “un-patched” $B793, a counter is set to 7, and the disk is checked to see if it is write protected. If it isn’t, execution is diverted to $B830, which heads off to $B76B. This is fatal, if we look at what $B76B does, it moves a chunk of code from $B779 to $E0 and executes it. The chunk of code that it moves there just wipes out RAM and hangs in an infinite loop.

Autoduel move kill code b76b

Autoduel kill code e0

So, that’s the source of the hang I was getting, triggered just by the fact that the disk was not write protected. But write protecting the disk doesn’t solve the problem, it just moves us on to the next stage of the copy protection.

If we pass the write protection test, the next thing it does is call $B83E, store the result, call $B83E, and compare the result with what we stored the first time. If we get the same result for each pair of calls, the counter is decremented, and it tries again. Once it has made seven attempts, we are again sent to the kill code at $B76B. So, now the question is, what is $B83E looking for and returning?

Looking at what’s happening here at the beginning, it’s pretty clear. It’s looking for address marks D5 AA 96 on the disk. Then it loads four more nibbles, but throws them away (they should be the volume number and track number of the address it found).

Autoduel b83e t0s0 check

Continuing on after that point, from $B86E, it then looks for the nibble sequence AA AA, which would indicate that it is looking at sector zero. If it wasn’t looking at sector zero, it goes back and tries to find another sector. If it did find sector zero, then it loads up five more nibbles and returns with the last of them. These should be the checksum and then the address field closer, which on a DOS 3.3 disk is generally DE AA EB. So if this were a DOS 3.3 disk, we’d expect it to return EB.

Autoduel b83e t0s0 check end

In actual fact, the nibble stream I captured on side one of the disk has an address field closer of AF A5 AA for track 0 sector 0. Ultimately what this means is that every call to $B83E is coming back with AA. It is always the same, and so eventually the retry counter reaches zero, memory is wiped, and the program hangs.

At this point, I don’t actually know what they did to the original Autoduel disk to result in having the address field closer on track 0, sector 0, come back with an inconsistent third value. But I did know how I could fake it, and maybe this is how it was done on the original disk as well, although it was not captured by SST if so. What I did is found the stream of sync bits at the end of track zero (a whole bunch of FF nibbles), and stuck D5 AA 96 96 96 96 96 AA AA 96 96 96 96 96 in there in the nibble image using a hex editor. Breaking that down, it is the address field header D5 AA 96, four throwaway nibbles (96), the two AAs that the routine is looking for to identify sector zero, and five more throwaway nibbles representing the slots for the checksum and the address field closer. The important thing here is that the last nibble is not AA (I chose 96, but anything but AA would work).

This will now pass the protection check at $B800, and I didn’t have to modify any of the code. When it is looking for sector zero, sometimes it will find the real one and get AA as the last nibble and sometimes it will find my fake one and get 96 as the last nibble. They won’t match, and so execution continues back at $B793 without ticking down the counter and hanging.

The code at $B793, after having been modified by the routine at $B800, goes through and loads the rest of DOS, which it does through repeated calls to $B7B5, which stifles interrupts and passes control to $BA00. This is all basically just RWTS calls. However, trying to boot the disk at this stage still doesn’t work, it just grinds. So, there’s still one more level of protection somewhere.

I had observed above that the address field closers on the front side of the disk were abnormal, they generally start with AF, and then it varies, but they are not the usual DE AA EB. The address field closers on the back of the disk are DE AA EB, though. So, that’s a natural place to look, based on the experience with the Electronic Mailbag I detailed earlier. And it turns out Autoduel does a very similar trick. Deep in the heart of the RWTS routines, we find the part that reads the address field at $BE4D. It’s a little hard to follow, but it’s looking for D5 AA 96, grabs and decodes the next eight nibbles (volume, track, sector, checksum), and then starts looking for the closer at $BE8C.

Autoduel rwts addr closer

If it finds DE, the job is done, nothing else is checked. This would happen if we were reading the second side of the disk. The carry flag is cleared to indicate no error, and we’re out. If it doesn’t find DE (and it would have found AF on the front side of the disk), then it does that same thing I saw on Electronic Mailbag, it waits a couple of cycles then sees if it has gotten enough bits in (even before the whole nibble is read) to exceed 00001000. If it has, it reports an error. So again, I think what must have happened on the real disk is that there were some extra zeros written here to delay the arrival of the second nibble. In an emulated nibble image, this is not really an easy option.

Probably at this point, I could have tried to go through the entire nibble image and replace all of the initial two nibbles in the address field trailers with AF 00. That might work. It seems like a drastic change to make, but it has the advantage that the protection code could be left untouched. Because the address field closers are not really consistent in my image of the first side, though, a simple search and replace wouldn’t work. Moreover AF 00 is not a valid nibble sequence, so it relies on the emulator being willing to overlook that. Perhaps a simpler alternative would be to change those AFs to DEs in the first nibble of the address field closer, but it’s still not an easy search and replace to perform as far as I can tell using the hex editor I’m using.

One thing that does work, though it requires patching the code, is changing the CMP #$DE (which gives the second side an automatic pass) to AND #$8E CMP #$8E, since both DE and AF are 8E when ANDed with 8E. This gives both DE and AF an automatic pass. So if you’re sitting at the breakpoint that catches that very first write protection check, you can alter BE91 to 29 8E C9 8E F0 07 EA EA EA EA EA D0, which results in this:

Autoduel rwts addr patch

This leaves a little bit of protection in place to catch genuine disk errors (though I guess those are unlikely using an emulator), while allowing either AF or DE to be satisfactory first nibbles in the address field closer.

So, with the nibble image modified to contain the additional fake sector zero header on track zero, and a breakpoint set at the write protection check so I can set the negative flag and patch BE91 as above, resuming from there allows Autoduel to boot. This leaves the disk in pretty much its originally protected state, minus whatever bit delays were allowing it to actually pass the protection and accordingly, minus the check for them.

Autoduel splash screen

The last step is to write my new code back out to the nibble image. Again, I have the problem that this is a nibble image I’m trying to modify (because I want to leave the protection as close to intact as I can), and so replacing those 12 bytes is not a simple task.

Following the same procedure I used before with Electronic Mailbag, even after EORing it all with E6 to re-encrypt it, didn’t seem to work, I was still unable to find the nibble stream I needed in the Autoduel nibble image. So I’ll have to leave this project here incomplete, but at least with a beginning of an understanding of where the checks are and what they’re checking for. There may be something else going on (though the nibble image preserved it, since the disk boots). For the moment, the image is only usable by setting a breakpoint and modifying the code in place, then resuming the boot. Perhaps I’ll come back to it. The short version of how to get the disk to boot as-is in Virtual II: Set a breakpoint at $B81C, boot, set the negative flag, replace BE91 with 29 8E C9 8E F0 07 EA EA EA EA EA D0, and resume.

  • Autoduel side 1 (nibble image, still won’t boot without live patching of memory)
  • Autoduel side 2 (nibble image, works fine, a DSK might be fine too)
Nov 282013
 

MUSE Software is probably most famous for Castle Wolfenstein, already a fairly early game for the Apple II platform, but they got their start much earlier. In 1978, MUSE was already producing quite a few titles on cassette, back when their name stood for Micro Users Software Exchange.

Mazegame tape 4

Already by 1979, they’d switched to referring to themselves as The Muse Software Company or The Muse Company, and then by 1980, MUSE Software, which stuck until the end. I tend to refer to them as MUSE now. The company had an interesting history, and there’s lots to say about them. Someday I’ll write more, though others have already written about them. Ed Zaron, Silas Warner, and Jim Black started the company, and Ed and Silas wrote pretty much everything during the early years.

There’s a nice overview of Silas Warner’s story at the Digital Antiquarian (Silas Warner and Muse Software), and the audio from Silas Warner’s presentation at KansasFest 1992 was preserved and made available. Softalk February 1982 has a company overview (Exec Muse) but I haven’t scanned it yet.

This post here is not about Maze Game (the picture of the tape above was just to show that MUSE was originally an acronym), though I’ll do a post about that later, but rather about ABM, one of the titles that MUSE released shortly before Castle Wolfenstein. Silas Warner speaks a bit about it in the KansasFest talk, I’ll transcribe what he said here.

ABM was written [...] just before we started Castle Wolfenstein. [...] As far as we knew it was a straight license from Atari Missile Command. Basically we wrote it and then Atari — we knew Atari was going to come back and someday say “We want a license fee from you,” but we figured we could get a few sales in before they actually demanded it. They came back, demanded a license fee, we paid it, and ABM came on that. By the way, there’s an interesting story about the title of ABM. We built a scrolling thing that would print up “ABM” in black and white squares using the text screen. So it would come up and then the rest of MUSE software and all that would come up. The “ABM” would scroll up from the bottom, real quick. Well, we made a mistake in that program, and instead of “ABM” scrolling up from the bottom and stopping, “ABM” would scroll up from the bottom — blip blip blip blip, up continuously. And we thought this looked so good that we kept it in the game, only adding a counter so it would do that five times.

The packaging for ABM was a simple white cardstock with red and black ink, sold in a baggie, the disk the standard Dysan disk (that MUSE pretty much always used) with a typewritten label. The instruction card on my particular copy had been folded in the middle, but was otherwise in remarkably good shape. Both the instruction card and the disk read “Audiovisual licensed from Atari.”

ABM packaging

I made a nibble copy of the disk image, and a scan of the card, which are below. The nibble image works fine in Virtual II.

ABM splash screen

ABM title screen

The gameplay is pretty much just Missile Command. The screen shot below is taken from the self-running demo that starts if you don’t start playing, incidentally. I’d like to think I’d do slightly better if I were actually playing.

ABM game play