Zip Chip is an accelerator chip for the Apple //. What follows is 6502 assembly language. You have been warned.
To enable maximum acceleration of everything except the joystick port, the Apple speaker, and slot 6:
LDA #$5A STA $C05A ; write 4 times to unlock chip STA $C05A STA $C05A STA $C05A LDA #$FF STA $C05B ; enable Zip Chip LDA #$80 STA $C05E ; disable I/O delay LDA #$40 STA $C05F ; normal joystick speed, fast language card LDA #$41 STA $C05C ; all slots fast except S6 and speaker LDA #$00 STA $C05D ; CPU at full speed LDA #$A5 STA $C05A ; lock chip
To disable all acceleration:
LDA #$5A STA $C05A ; write 4 times to unlock chip STA $C05A STA $C05A STA $C05A LDA #$FF STA $C05A ; disable Zip Chip
These routines work on both the Zip Chip 4000 (4 Mhz) and Zip Chip 8000 (8 Mhz).
As followers of my del.icio.us links may have noticed, there was a hysterically funny tutorial on using the Apple //e as a serial console making the rounds a few weeks ago. It was from this tutorial that I learned about ADTPro, a kick-ass modern copy program for the Apple //e (not to be confused with classic copy programs for the Apple //e). What can you say -- in 2007 -- about actively developed, GPL-licensed software for the Apple //e? It rocks my world. It's so actively developed, there has actually been a minor update since I last installed it. (Sadly, there is no apt-get for the Apple //e.)
Anyway, once I dug my Apple //e out of my attic and bought a bunch of Apple //e hardware and waited and waited and installed it and configured the dip switches properly... seriously, what can you say, in 2007, about configuring dip switches on a serial board plugged into slot 2 of the computer you grew up with? I'm as giddy as a schoolboy. What was I saying? I have no idea.
This: I have backed up my Apple //e disks. Mostly DOS 3.3 and Apple Pascal disks, since the ProDOS ones were mostly just AppleWorks documents which I transferred to 400K 3.5" floppy disks, and later 800K floppy disks, which I later converted to disk images on an pre-iMac Macintosh (i.e. one with a floppy drive). I repeat: I have backed up my Apple //e disks. I've been meaning to do this for about 25 years now, and now I've done it. And to verify them, I've successfully installed KEGS and booted the disk images that I transferred from my Apple //e.
Other than the stupid text adventures, silly graphic effects, and volumes of bad poetry and short stories, there might be something in that collection worth publishing.
The thing I remember most about the Apple ][ was the sound of the disk drive as it was booting up. It had this wonderful [d-d-d-d-r-r-r-r] sound and then it sort of... well, of course it depended on the bootloader. For Apple DOS, it would load up the disk operating system from the first three tracks, tracks 0 through 2. It would only do about half of track 2, and then track 1, and then half of track 0, and then it would seek all the way out to track $11. (And by "track $11" I mean 17. $11 in hex. 1-1.) It sounded like [doot-doooot-doot-chhhhhh].
I recently came across a PDF of a scan of a book called "Beneath Apple DOS" which was the seminal book. I had long since lost track of my copy. It's just amazing. It has all the info about what happens when you first load up a disk. Obviously, you can turn the computer on, or you can hit open-apple + control + reset (now called "command + control + reset"). You could type PR#6 and that would load the bootstrap code for Slot 6, which was the disk drive, the 5.25-inch disk drive slot. Of course, if you were already in the assembler, then you could type C600G, which would start loading the same bootstrap code as PR#6.
The very first byte of track 0 sector 0 of every 5.25-inch Apple ][ disk was a sector count for how many sectors the ROM in Slot 6 at C600 should load off the disk before handing off control. Usually it would just load the first sector, and then it would pass control to that which would be sort of a primary bootstrap to load about 8 more sectors off of track 0, and then that would be enough to load the rest of the operating system off of track 2 and track 1 and the rest of track 0, and that would be enough to load up the disk catalog or run the start program or whatever.
Beagle Brothers came out with Pronto-DOS, which was some patches against Apple's DOS 3.3, which was much faster. It only used one sector out of track 2, and so when it booted up it went [d-d-d-d-r-r-r-r] [dt-doooot-doot-chhhhhh] It was like a grace note. In fact, it was a grace note. It was a sixteenth note. If you think of each sector read as a sixteenth note, it was reading one sector off track 2, and then going back and reading all of track 1, and then all of track 0, and then seeking out again to the disk catalog on track $11.
Of course, retail games, most of them had their own bootloaders that weren't based on Apple DOS because they didn't need all of the functions that DOS provided like loading and saving programs. They needed the memory. It took several pages of memory and it stayed memory-resident the whole time you had the disk loaded. And they needed that memory for their games and their data and such.
They usually had custom bootloaders so they sounded like all kinds of things. They had all sorts of funky things centered around copy protection where they would write data to the disk in strange ways. There were things called half tracks and quarter tracks. Things like Karateka by Broderbund stored everything on quarter tracks and it was the most amazing sound to listen to the original disk boot up.
And of course, in lots of cases pirates would come and interrupt the bootloader on the game and seek out to maybe the end of track $22 or $21 where the original game hadn't stored any data and they would go store their own picture or crack screen or whatever. So you would hear, when the disk booted up, you would hear just a little bit of [dt dt] loading the initial bootloader and then it would seek all the way out to the end of the disk and it would go [dt dt chhhhhhhhhhhhhhhhhhhhhh dt] and then show the crack screen and then come all the way back and load the rest of the game.
A lot of what I did was hacking on stuff, and the ultimate hacking tool for poking around -- not for cracking, but for just fiddling around and seeing experimenting with bootloaders and stuff -- the ultimate tool was Copy ][+ by Central Point Software. Just an amazing program. And it had a disk editor that would let you see individual sectors of individual tracks and then disassemble them and show you the machine code listing, the 6502 assembly language listing, of the programs on those tracks. So I spent a lot of time in Copy ][+, hacking around and fiddling with bits and disassembling things and seeing how it worked.
Of course, you could only boot a disk off of one drive, even if you had two disk drives, you could only boot off one of them. And so you had to boot Copy ][+, and it would go [dt dt dt dt dt dt dt dt dt] and then come up with its main menu. And then at that point you could take the disk out, and you could put whatever other disk you wanted to play with, and you could load up the disk editor. Copy ][+ was all stored in memory. You could load up the disk editor, and if it was a DOS 3.3 formatted, Apple DOS formatted disk, you could get a catalog listing and you could follow individual files around as they were stored on the disk. You could go to the next sector of this particular file, or you could go to an absolute track and an absolute sector. So I spent a lot of time in track 0, sector 0, fiddling with things and looking at bootstrap code and bootloader code.
In 1983, my father took a sabbatical and bought an Apple //e to write a book. It was my first computer.
In 1989, I got an Apple ][gs for Christmas, and my parents sold our Apple //e to a family friend.
Today I got word that she is done with it, having finally upgraded and completely migrated to a computer with more than 128K of memory. Within the next few weeks, she will be sending my first computer back to me, in full working order.
Why are we so attached to the things we're attached to?
Jason Scott: The Annotated Real Pirate's Guide. Following my essay this weekend about What the past will look like someday, Jason Scott of TextFiles.com pointed me to this wonderfully nostalgic trip down memory lane. Well, for some of you, anyway. I wasn't ever involved in the whole BBS scene as a kid. But anyone who grew up with an Apple //e will no doubt find something familiar here.