Guten tag,
Sorry I will reply in English today as my German is 35 years old and too basic for the topic at hand.
DFB1 does also not pay any attention to the /EXPAND line. I don't know enough about the CT60 (I have never owned one) to know why this matters for it but not for DFB1. I remain slightly skepitcal about EXPAND being a problem at all and tend to agree with Rodolphe that it should have no effect really.
BUT there is one area where I can see it could. Perhaps CT60 generates its own BERR signal for the lower 16MB range rather than relying on the motherboard's 128 clock cycle timeout? [nb. from memory it's 128 cycles -- about 8 microseconds, but I may be misremembering and it may be only 4microseconds]
DFB1 does not synthesize its own bus errors apart from at the top of TT-RAM. It relies on the motherboard to assert BERR and EXPAND is, of course, still connected to the motherboard.
Perhaps CT60 is not like this and, for some reason, Nova requires a very, very slow bus access from time to time?
BW
Hi David,
I don't recall the details since we worked on this more than 20 years ago, but as far as I remember Rodolphe was expecting expansion cards to create /DTACK within 4 cycles. Since Nova needs to honour the ISA protocol (I think I read that I/O can take up to 12 cycles), this was an issue. Nova uses a 74LS164 for timing control and we tried modifying the GAL as well as using a different LS164 output, but nothing worked. He concluded that the card (interface) is too slow and since this was also the time when CTPCI became available, he stopped looking into the issue.
Maybe someone with better hardware knowledge than me can make it work, I also don't own a CT6x anymore and only one Falcon with a DFB1.
Wolfgang
Neueste Beiträge