[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Creating Apple /// boot disks using MacADT



jjj wrote:
On 2008-01-20 01:57:03 -0800, dempson@actrix.gen.nz (David Empson) said:

jjj <jjj.@.i.o.com> wrote:

On 2008-01-19 02:17:36 -0800, "Michael J. Mahon" <mjmahon@aol.com> said:

It's easy enough to look at block 1 and be sure...

There are lots of slips possible when Apple II tools are used
to capture/transmit Apple /// disks, since you can be pretty
sure that the images have not been verified to boot SOS since
originally being archived.


OK I looked at Block $0001 on the Apple /// System Utils disk. It was
just full of zeroes.


That's not going to boot an Apple ///.

However, Block $0000 is exactly the same as Block $0001 of the ProDOS
disk.


Was that a type? I'd expect block 0 of a SOS disk to be the same as
block 0 of a ProDOS disk.

SOS doesn't use block 0 and ProDOS doesn't use block 1.

A "dual boot" disk will have the ProDOS boot code in block 0, and the
SOS boot code in block 1.

A ProDOS-only boot disk will have ProDOS boot code in block 0 and
probably zeros in block 1.

A SOS-only boot disk will have SOS boot code in block 1 and probably
zeros in block 0.

A disk which isn't set up to boot either OS (formatted and has a
directory, but no boot blocks) could have arbitrary junk in both blocks
0 and 1.

So, I copied Block $0000 of the Apple /// disk into Block $0001 of the
Apple /// disk, but I still get the IO ERROR.

Then I tried this: I copied Block $0000 and $0001 exactly from the
ProDOS disk to the Apple /// disk. Still, IO ERROR.

If I try to boot the Apple /// from the ProDOS disk, it gives a
different error: SOS KERNEL NOT FOUND.


This implies that ProDOS disk contains the Apple /// boot code in block
1. It attempts to load a file called SOS.KERNEL (or something like
that).

Not sure what is going on with the I/O ERROR messages, but that usually
means the disk is unreadable, or it tried to access a nonexistent block
(block number out of range).

Perhaps there is a problem at a later point on the Apple /// disk.

The weirdest thing is that in Block $0000 of the ProDOS disk, line 010
says the first part of my e-mail address: "JJJ.@.I" What the hell?! How
could my e-mail address be in there?


What do you mean by "line 010"? What address offset? What are the actual
byte values at that point? (ASCII is ambiguous - might have the high bit
set or clear.)

I don't have a working Apple II system on hand to check if that is
normal.

I am guessing that somehow my FTP program is messing up the disk
images, since why else would part of my email address be in there? Or
is it just the weirdest coincidence of all time? I'm just using Fetch
to get these DSK files from asimov.net. But why would it put part of my
e-mail address but not the whole thing?

It's only on the ProDOS boot disk. But also I formatted a blank disk
with ProDOS and "JJJ.@.I" is also on that one! I'm putting my money on
crazy coincidence...

Incidentally I noticed the Kernel file starts in Block 7 on the Apple
/// System Utils disk.


That's arbitrary.

The directory is blocks 2-5, and the volume bit map is block 6. The
first file saved on the disk will normally start at block 7 but it just
happens to be the SOS Kernel.


Incidentally I took apart the disk drive in the Apple ///. It appears as though the white flywheel which contains the groove that moves the read/write head is worn out. The little groove doesn't catch at the very end of it. So it's not able to move the head back and forth apparently. Hence it seems to only be reading the first block or two but it cannot read the rest of the disk. I think this is why I'm getting the errors.

That would certainly do it, as it tries to read beyond track 0 while
loading the SOS kernel.

Normally, the seek cam is never turned far enough "inward" to cause
the cam follower to leave the groove, and when it is seeked "out", it
encounters the "track 0" stop that prevents further stepping and
therefore also keeps the follower in the grove.

Therefore, the follower (ball bearing?) should always remain in the
groove of the cam.  If it is not in the groove, you can move it
manually until it is, and thereafter it should always remain there.

Strong vibration or shock could conceivably get the follower out of
the groove, but the normal "recalibration" seek at boot time should
re-seat it if it within its normal range of travel.

I took apart a Disk ][ but it does not have screws in the right places to mount it into the Apple ///. So I think I will try and manually replace just the wheel part but they look different somehow. I think I might be screwed but I will keep trying.

I wouldn't rush to replace the cam.  For one thing, once it is moved
on the stepper motor shaft, you will need to realign the drive.  For
another, I've never seen cam damage in an Apple II drive, and would be
surprised to see it in an Apple /// drive.

Study the cam and follower carefully to see if you can determine just
what has happened and why.

Can you describe or photograph the situation in detail?

As for the boot blocks, I don't know what to tell you. I think it's just a coincidence about the JJJ.@.I thing. The J's are 4A 4A 4A or something like that.

Still, even when I copy the SOS boot block into Block 1 it gave me the same errors, so I don't know what to tell you. Unless maybe I need to put the zeros in Block 0 for it to work? But I think the disk drive is bad, so I will keep working and get back to you guys.

No, you can leave block 0 alone.

If the drive won't seek, then that's probably the problem.

-michael

NadaPong: Network game demo for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."