Re: IEEE drive CPU inter-communication

Hi Rob,

looking through my old mails I see this seems to have gone unanswered. (or I 
have overlooked it now, in that case I'm sorry for posting again...)

On Monday 31 August 2015 10:58:06 Rob Clarke wrote:
> Does anyone have any information which describes the basics of the
> processor inter-communication on the IEEE drives? I know the two cpu's
> operate out of phase, and that they share access to some common areas of
> RAM, but it is not clear how tasks are handed off from the DOS
> controller, status receieved etc.

Basically the principle is the same across all the CBM floppy disk drives, so 
I would assume it's the same in the 8280 DOS.

The DOS has a common shared control memory, usually in zeropage. The first few 
bytes are reserved for "command", "drive", "track" and "sector" arrays, with 
one entry each for each shared buffer. The controller writes an address 
(track/sector) and then a single byte command with bit7 set (or cleared, I'm 
sorry I'm writing from memory). A command is something like "read sector", 
"write sector",  etc. The FDC CPU reads this command from the control area, 
and executes it, ignoring all other commands for the other buffers. When the 
FDC is finished, the command is overwritten with an outcome (IIRC zero, or an 
error number), with bit7 cleared (or set, again, from memory).
All that happens because there is a fixed relation between the shared block 
buffers and each entry in the control arrays. If the drive has 5 shared 
buffers, there are 5 command entries and so on. So buffer allocation is done 
on the DOS CPU, not the FDC CPU.

For any further details you can even have a look at the various commented 
VC1541 DOS ROM listings to get an idea how it all works (even though the role 
of the second CPU is taken by the interrupt routine here, the principle way 
how it works stays the same).
> 
> I ask because I'm working on resurecting the 8280 I received a few
> months back. There are RAM issues on the DOS board which are proving
> tricky to isolate and I wanted to take the drive controller CPU out of
> the equation. Removing the second CPU renders the board completely
> inoperable; I assume because a number of signals are left floating.

You should at least replace the CPU with some mechanism that keeps the address 
and R/-W line high, so there are no floating signals that change memory. I am 
pretty sure, though, that the FDC controller is also checked during startup, 
(maybe an own command), so you may be out of luck without replacing the DOS 
ROM where this check is patched out.

Anyway, It might even be best, to use something like a RAM/ROM board in the 
DOS CPU socket that allows you "look into" the drive but does only rely on 
basic signals like power or clock. I have done this with a broken PET, with my 
65816 card. It's a considerable effort though.

Hope this helps
André

       Message was sent through the cbm-hackers mailing list