Atari BadSector "A" Project Diary
The command header 5 byte sequence is not been received
correctly. After some experimentation, switching from edge triggered to
level sensitive interrupt fixes things up. Note that the interrupt routine
is not exited until the stop bit occurs at which time the Data Out wire
is high. I am using a 5 byte array in internal RAM to capture the command
header. Code in the main module allows me to print out key variables and
display them in the TELIX window.
A data frame is 128 bytes or 256 bytes for double
density. I have reserved the top of the RAM for a 256 byte data packet
buffer. In the interrupt routine DPH is hard coded, but DPL is loaded from
an internal RAM variable (essentially a pointer). Set this variable to
zero and increment every time a byte is received. After some though I realise
that I can use the same buffer for both the command header and the data
Using the code for receiving a byte the code for
sending a byte is created. I started to write the code for receiving a
read sector command. The code uses the send byte routine to send an ACK
byte back to the Atari. The Data In wire is not yet connected, but when
the Atari is reading from the floppy drive the same code will be executed
on the hard disk controller and the acknowledge byte is sent back. On my
scope I can compare the floppy Data In with the Data In generated from
the hard disk controller to see that the timings are correct. I posted
some questions to comp.sys.atari.8bit asking how I could code a loop to
continually read (or write) a sector using the SIO routines. Some clever
person suggested using the RPM command which appears in several DOSes.
I end up going through all my floppies trying to find any strange DOSes
I may have. I eventually come across SmartDOS, which has the RPM command.
When executed the SIO command to read a sector is continuously sent (if
there isn't an error) and this is invaluable in getting the scope to re-trigger
often enough to see the waveforms clearly.
I have all the basic SIO elements to code up the
routines for read ("R"), write ("W" and "P") and status ("S"). When I try
to get the device to respond to a write sector command the Atari is returning
an error code. Re-reading the various documents I have I realise that when
sending back a 128 byte sector data packet, there must also be a 129th
byte which is the checksum.
I reserved one of the internal RAM locations (8-15)
to hold a running transmit checksum and added some code to the send byte
routine to update this checksum. After starting in C, once again it was
obvious that it was much more efficient to code the checksum calculation
in assembler. Basically the new byte is added to the current checksum byte.
If there is a carry out (i.e. the result is >256) then the 8 bit value
is incremented by one (i.e. the carry is added back in). This is trivial
to code in assembly language, but very inefficient in C.
In order to solve a timeout problem when the Atari
was reading a sector from the hard disk, a number of delays needed adding
in the appropriate places (as clearly described in the Atari Hardware Reference
Manual). I successfully wrote a sector and read it back again. Nearly there.
The code to support the format instruction (single density) was added.
Of course no formatting is actually carried out, but all sectors are initialised
with all zeroes. Using SmartDOS I was able to format the hard disk as a
floppy disk drive. I then changed the drive number from D2: to D1: and
successfully booted DOS from the hard disk drive.
A switch has been added to one of the remaining spare
port pins. This is used to tell the software which drive number is selected,
D1: or D2:. The drive can now only be formatted when it is in D2: mode.
Added support for the PERCOM block read and write
commands. These commands are not supported by the stock Atari 1050 drive,
but appear to be used by the 1050 enhancement upgrades such as the "Happy
Mod". My own 1050 is a Happy drive. I know that the coding of these commands
is very poor. Nevertheless I try to implement switching into double density
mode and reporting this correctly in the "S" (status) command. Of course
I can't yet do double density IO!
I realised that there is a way to save 3 port bits
by changing the hardware. Since the 74HC573 latch has been used to latch
the address bits, then the bottom 3 bits can be connected to the IDE drive
to be used as address bits. I re-wired the circuit board, then went about
testing the upgrade by changing the software. Each of the 8 main registers
in the IDE drive now each have there own memory mapped address. This is
a much better scheme than using 3 port bits as pseudo address bits, and
faster too! It only took half an hour or so to update the software and
prove that it all was still working.
Return to Atari Projects home page