exxos's Atari, Amiga & retro forum

I'm working through the logic now.

I dislike Python I'm finding, especially when dealing with byte data.

I'm going to have to write a set of bit_set() and bit_clear() procedures to clean things up.

Got to the point where I needed to attach the /INT2 interrupt line... Then things stopped working again due to an iffy connection somewhere on the breadboard. *sigh*

Time for bed.

I'm going to have to replace the headers on the RAM board with longer ones. The DuPont connectors just won't stay on and connect reliably with the current ones.

Changed the header pins and the hardware is now reliable.

Got a little further. The system now reads the first sector of the "drive" and decides that it's not bootable.

I found the virtual floppy with the HD formatter on it and I've got it as far as trying to format the first track of the drive, but then it crashes. I'll have to work out what values I'm passing back incorrectly.

stephen_usher wrote: 13 Dec 2022 00:44 Changed the header pins and the hardware is now reliable.

Got a little further. The system now reads the first sector of the "drive" and decides that it's not bootable.

I found the virtual floppy with the HD formatter on it and I've got it as far as trying to format the first track of the drive, but then it crashes. I'll have to work out what values I'm passing back incorrectly.

Sounds like good progress :)

With the help of reading the BIOS source combined with the WD1010-05 data sheet I've got to the point where the formatter isn't crashing!!! :-)

Whether it's doing anything sane is another matter. My other issue is that I'm running out of RAM, or getting very close to doing so.

Anyway...

I just realised that my disk file seek calculation code was totally bonkers so it's not doing sane things.

Hopefully whatever the formatter writes to the drive will all be contained within the first 16 sectors otherwise all bets are off.

At least I'll find out how many cylinders it thinks that it has once the format has finished. (Two hours so far and it's 2/3rds of the way through, and it's not speed limited by the Pico, it's the code in the Apricot which is slowing things down.)

Well, the answer to the question, "How many cylinders on a 10MB hard drive with 4 heads is... 306."

The writing did screw up so it was a useless image but that's OK.

Now I've fixed the issues I'm trying again, but with a 5MB "drive". It won't be perfect as my hard-coded values for the seek are based upon 4 heads rather than two but that won't matter in the short term. Once I know this works I can make a 20MB drive (6 hours format time!) and clone it for later.

Then I hit memory size issues... Now I'm doing garbage collection every loop so that I don't have random memory allocation failure errors when copying data into buffers (because Python is stupidly memory hungry).

In the end a got a format to finish, but into the wrong file and the drive reading now seems broken. I'll have to look at that tonight.

Hit the buffers a little.

(a) The BIOS isn't doing what the BIOS listing I have says it should do, i.e. read the first sector to determine what sort of disk is attached.

(b) When programs use a certain BIOS call (unknown which) I see a flag on the virtual latch, which the BIOS listing says if for activating drive 2, goes low and then the system erroneously reads from the memory buffer a large number of times and then the Apricot locks up. I can't see why. Possibly it's trying to access another I/O address which includes 0x00e0 in the address but I've written code to unblock the I/O ASAP and wait until deselection, so that shouldn't cause a lock-up. The Pi and the data buffers are in read mode so shouldn't be able to affect the data bus. I'm stumped.