More on the IIGS...

Wow, failed again.

I came across a program that will use the PC parallel port and communicate with the IIGS via the game port. I happen to have a 25-pin to 9-pin adapter, so I hooked it up and tried it out. After entering a short program on the Apple II (remember, moving files still sucks) and starting up the PC program, I wasn't able to get it going.

However, the IIGS gameport connector is different than that on the original Apple II series, so maybe this is to be expected.

Anyway, Lisa brought home some more disks (people are scrounging for them so they can get rid of them) so I've got more software and a number of blanks, so that's improving. I just need to start doing the PMA transfer. (That's PC -> Macintosh -> Apple IIGS and doesn't stand for anything else that can fit the PMA acronym...)

Resource forks, part II

Well, if I had the right software on the Macintosh, I guess I could have removed the resource fork right away in the beginning.

If I could copy files to the IIGS without corrupting the file, I could run something called "unforkit".

If the IIGS had a serial connection that was standard, I could transfer files via a serial cable and totally skip the intermediary step (need to figure this one out).

Unfortunately for me, that's putting the cart before the horse. (The byte before the bit??)

Fortunately, I hung on to my old Apple II books - and I have a number of references on the internals of ProDOS. I even have the Apple Exercisor disk that came with the Apple ProDOS technical reference.

I figured out how to hack the resource fork out of the file. It's not pretty, and I don't want to do it all the time. "unforkit" will make it more palatable, but I don't want to continue with the PC -> Macintosh -> IIGS triangle since it generally sucks.

Details of the surgery are as follows (and, remember, I fortunately have software that helps me out with the low-level details):

1. Locate the file by scanning the directory, the storage type is $5 (presumably indicates the resource fork). This is the high nibble of the first byte (just before the filename - the lower nibble is the length of the filename).
2. Go to the block identified in the key block pointer field (offset $11/$12).
3. This block does not list other blocks as expected: a) I think the first byte is the "real" storage type. b) The 2nd and 3rd byte are the real key block. Double-check it.
4. Patch the real key block into the directory entry and change the storage type back. The storage type can be $1 (1 block file), $2 (2-256? blocks) and $3 (257+ blocks).

Note that this procedure leaves some dangling blocks that won't go away until the disk is reformatted (or you tweak the used block table manually), so it's best to use an expendable disk.

Not something to do just for fun. That got me into the GS Shrinkit which handles resource forks without any difficulty, so I think I'm done with the hacks.

Resource forks?

I finally got some disks that boot created. First I needed to scrounge around for 800K 3.5" floppies. Then the Macintosh disk creator program failed to create bootable disks. People told me to use a program called DiskDup+ to create the disks. Fortunately, that worked.

Now I'm trying to get some additional software over to the IIGS, but its not what I expected. If I copy files from a PC to the Macintosh to the Apple IIGS, they don't work. What I've found out is that the Macintosh is magically adding a resource fork to the file. As far as the IIGS is concerned, the file is corrupted.

Back to the drawing board...

First MediaMVP patch!

I spent way too much time on this, but it bothered me that the on-screen display (when toggled) would show how far into a recording I was but wouldn't show me the total length of said recording. I also tweaked the OSD display a bit...

C is like another world for me - one that I haven't visited for a good 10 years. I mostly do Java, so this took some remembering. But I did it!

We'll see what th guru's think. It'd be cool to have it become part of regular distribution!