6 Jul
2014
6 Jul
'14
8:47 p.m.
I still haven't figured out how to get interrupts from the uPD765 FDC in
the Quay. I think they're probably routed via a Z80-PIO input, but no luck
so far.
While the DMA support in the uPD765 is by design optional, they clearly
*really* intended that interrupts be used. The Quay boot ROM just uses a
very long fixed delay after the recal before doing a read. That's
obviously not great if you want good performance.
I tried several unsuccessful approaches to waiting for a recal or seek to
complete before finally noticing that the FDC will reject the "sense
interrupt status" command as illegal if there isn't a pending interrupt.
Now my code issues that command repeatedly until it does not report an
illegal command.
Has anyone found an easier way to use the uPD765 without interrupts?
6 Jul
6 Jul
11:14 p.m.
On 07/06/2014 08:47 PM, Eric Smith wrote:
I still haven't figured out how to get interrupts
from the uPD765 FDC in
the Quay. I think they're probably routed via a Z80-PIO input, but no luck
so far.
While the DMA support in the uPD765 is by design optional, they clearly
*really* intended that interrupts be used. The Quay boot ROM just uses a
very long fixed delay after the recal before doing a read. That's
obviously not great if you want good performance.
I tried several unsuccessful approaches to waiting for a recal or seek to
complete before finally noticing that the FDC will reject the "sense
interrupt status" command as illegal if there isn't a pending interrupt.
Now my code issues that command repeatedly until it does not report an
illegal command.
Has anyone found an easier way to use the uPD765 without interrupts?
It can be done. Take a look at main status register, which can always
be read. Bits 0-3 are set while seeking (if the drive select feature of
the 765 is used (the PC doesn't), you can have up to 4 simultaneous
seeks in progress. Bit 4 will tell you if a read or write is in
progress; when you're not using DMA, bit 5 will tell you when it's safe
to read the result status. Bits 6 and 7 control the direction and
status of the data bus.
Where things get sticky is the case of tying the READY input to the 765
active, so drives always look ready. The controller will hang and will
require a hard reset to get back to business.
Hope this helps.
--Chuck
11:31 p.m.
On Mon, Jul 7, 2014 at 12:14 AM, Chuck Guzis <cclist at sydex.com> wrote:
It can be done. Take a look at main status register,
which can always be
read. Bits 0-3 are set while seeking (if the drive select feature of the
765 is used (the PC doesn't), you can have up to 4 simultaneous seeks in
progress.
That was the most obvious thing from reading the datasheet, so it was the
first thing that I tried. However, the behavior I seemed to be getting was
that the uPD765 wasn't clearing the seek in progress bits until after it
both asserted the interrupt AND I gave it the "sense interrupt status"
command. If I just waited for the seek in progress bits of the main status
register to clear, they never did, and my code would hang.
I haven't actually put a logic analyzer on it, so it's possible that my
analysis of the problem isn't entirely correct, but putting the "sense
interrupt status" command into the loop allowed it to complete.
7 Jul
7 Jul
12:45 a.m.
On 07/06/2014 11:31 PM, Eric Smith wrote:
That was the most obvious thing from reading the datasheet, so it was the
first thing that I tried. However, the behavior I seemed to be getting was
that the uPD765 wasn't clearing the seek in progress bits until after it
both asserted the interrupt AND I gave it the "sense interrupt status"
command. If I just waited for the seek in progress bits of the main status
register to clear, they never did, and my code would hang.
Hmmm. Is the interrupt request pin brought out in a register so that
you can poll it?
I know that the Tandy low-end PCs did without DMA, but I think even the
IBM Peanut used interrupts.
But I'll twiddle a few bits when I get a chance and see if I can come up
with a definitive answer.
--Chuck
2 a.m.
On Mon, Jul 7, 2014 at 1:45 AM, Chuck Guzis <cclist at sydex.com> wrote:
Hmmm. Is the interrupt request pin brought out in a
register so that you
can poll it?
If it is, I haven't found it yet. I've tried to find where the interrupt
line goes using a continuity checker, and haven't found it going anywhere,
but that seems unlikely.
1:02 p.m.
I still haven't figured out how to get interrupts from the uPD765 FDC in
the Quay. I think they're probably routed via a Z80-PIO input, but no luck
so far.
That would make a lot of sense. IIRC the Z80-PIO can produce a Z80-style
vectored interrupt on change of state of some of the inputs. Another
favourite trick was to use a spare channel on a Z80-CTC, pre-loaded with
1, so that on the first clock pulse (i.e. the IRQ singnal from some other
IC) it decrements ot 0 and genereates a Z80 interrupt.
How hard would it be to trace out the scheamtic sof this board? My
experience is that it is often quicker and less frustrating to do the lot
than to attempt to see what happens to one signal. When tracign the
complete scheamtic, you can often 'eliminate' large numbers of ICs --
teven TTL gages, etc, to things like the adress decoder, laving only a
few parts that are invovled with mystey signals.
[...]
Has anyone found an easier way to use the uPD765
without interrupts?
Some years ago I wrote a program in Turbo Pascal that directly drove the
PC flopppy controller. I found it much easier to use a trivial interrupt
handler (I think it just set a boolean variable) than to figure out if
there was a way round it.
-tony
2:39 p.m.
On Mon, Jul 7, 2014 at 2:02 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
Another
favourite trick was to use a spare channel on a Z80-CTC, pre-loaded with 1,
I hadn't thought to check for that. There is a Z80-CTC present.
How hard would it be to trace out the scheamtic sof
this [Quay MPS-90F]
board?
I've mostly been able to find other signals of interest using a Rho
Enterprises low-voltage continuity tester, without having to remove the
board from the machine. Removing the board is a hassle and the serial
daughtercard is soldered in place so I can't get to everything even if the
board is removed. The two big mysteries that I haven't resolved that way
are the FDC interrupt and the SIO clock.
The SIO clock situation is interesting because the SIO is on a daughtercard
that's soldered into a PIO footprint on the main board. There's no BRG on
the daughtercard, and no sign of rework on the main board to route CTC
outputs to that PIO footprint. Also the continuity tester didn't reveal
any connections between the main board CTC and the daughercard SIO clock
inputs.
8 Jul
8 Jul
4:12 p.m.
On Mon, Jul 7, 2014 at 2:02 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
I am pretty sure I have a Philips Prestel/Viewdata set that uses that
trick as part of the bit-banged serial input fro mthe modem...
Another
favourite trick was to use a spare channel on a Z80-CTC, pre-loaded with 1,
I hadn't thought to check for that. There is a Z80-CTC present. How hard would it be to trace out the scheamtic
sof this [Quay MPS-90F]
board?
I've mostly been able to find other signals of interest using a Rho
Enterprises low-voltage continuity tester, without having to remove the
board from the machine. Removing the board is a hassle and the serial daughtercard is soldered in place so I can't get
to everything even if the
board is removed. The two big mysteries that I haven't resolved that way
When I did the HP910B, I desodlered the connetions between the 4 PCBs in
the main ROM and separated them. Given that the ROM PCB iteself is very
much layout-crtiical (if I had damaged a connection to an internal leyer
there would eb no way to repair it, this was stressful. But I did it. And
it worked afterwards.
I suspect that desolderign your RS232 board is a lot easier.
are the FDC interrupt and the SIO clock.
The SIO clock situation is interesting because the SIO is on a daughtercard
that's soldered into a PIO footprint on the main board. There's no BRG on
the daughtercard, and no sign of rework on the main board to route CTC
outputs to that PIO footprint. Also the continuity tester didn't reveal
any connections between the main board CTC and the daughercard SIO clock
inputs.
Waht is on this dughterboard? Could ie be that the SIO runs at a fexed
baud rate produced, say, by dividing down the proceessor clock?
-tony
3819
days inactive
3820
days old
7 comments
3 participants
participants (3)
-
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
spacewar＠gmail.com