OK, so I'm turning my attention back to the DSP. Why does it work with *only* one board an no others? Must be a quirk of the clock delays, I figured, but instead of trying to replicate that quirk, let's do some measuring.
Noting the details of my investigation here as a record for others.
Firstly, what are the symptoms?
Basically writes don't work. Writes to the DSP data port do not have any effect on the status registers meaning the OS or any other DSP-enabled program tries to write a program to the DSP and sits and waits forever for its acknowledgement.
How do we know?
The way the DSP is exposed to the system there are eight bytes at FFA200 to FFA207. The first four are registers, the latter four are for data (technically only the last three, byte FFA204 is ignored). For the data bytes, nothing happens until a write to FFA207 triggers action.
The most obvious indication of activity on the DSP is after a write to FFA207, the register at FFA202 should change.
By way of example, on a vanilla system after a clean boot, FFA200.l reads:
Writing anything to FFA207 causes that to change to:
This is the important feedback the system needs to know how to respond next. When writing to the DSP from my card, 16MHz,
06 never changes.
The DSP is connected to the system with only an 8 bit port. Data lines 31-24 are therefore active and the CPU needs DSACK0 to be asserted. This means that when using the Falcon expansion bus special attention must be paid to DSP access as for all other motherboard accesses, DSACK1 is asserted when a DTACK is received from the GALs. Secondly, a different algorithm must be used for UDS and LDS. Fortunately these are all seen to be logically sound as a) reads work and b)
one board does work with this logic.
Now possibly because the DSP is odd like this (or possibly because it was a later addition to the spec?) its chip select, data strobe, DTACK and other control lines are not handled by COMBEL: it has its own GAL, U44, although it interacts with the main GALs in a few ways:
- Screenshot 2021-10-28 at 19.52.17.png (261.59 KiB) Viewed 1979 times
U44 is responsible for issuing the DSP's CS and DS signals and generating the DSACK0 line (which ultimately generates the XDTACK line I see on the expansion port).
According to the 56001's data sheet, the Host Enable pin is of most obvious interest:
Host Enable (HEN)
This input enables a data transfer on the host data bus. When HEN is asserted and HR/W is high, H0-H7 become outputs, and DSP56001 data may be read by the host processor, When HEN is asserted and HR/W is low, H0-H7 become inputs and host data is latched inside the DSP when HEN is deasserted. Normally a chip select signal, derived from host address decoding and an enable clock, is used to generate HEN. HEN may be programmed as a general purpose I/O pin called PB12 when the Host Interface is not being used. This pin is configured as a GPIO input pins during hardware reset.
The HEN pin is the XDSP_CS line from U44 and HR/W is the system's RXW line.
To my mind, therefore, it must be all about XDSP_CS.
Here's what we get when we compare XAS (the CPU's address strobe) with XDSP_CS and the clock (stock Falcon):
- Screenshot 2021-10-28 at 20.08.27.png (15.95 KiB) Viewed 1979 times
But here's what we see when my external card tries to write to the DSP (at Falcon 16MHz speed):
- Screenshot 2021-10-28 at 20.06.59.png (14.66 KiB) Viewed 1979 times
Something is very awry!
Now, on the face of it, unless RXW is going high too soon (it's not), I can't see why this still wouldn't work -- albeit in slow motion. But the delay between AS being asserted and XDSP_CS going low is odd. Equally, not shown here, DSACK0 basically mirrors XDSP_CS so why is it taking so long for AS to go back high again?
So I'm going to go away and review the GAL equations and perhaps start messing with my timings. Perhaps emulating my own DSACK0 rather than waiting for the motherboard.
I'll let you know how I get on, but any ideas welcomed.
BW