DFB1r4 design discussion thread

[exxos]

Here are the traces in this CPU-less bus-arb-plus-read configuration:
I can't see anything obviously wrong here, but no DTACK and instead Bus Error right on cue. :(

This is requesting a word read from 0x000000. Going to try some more tricks.

Strange :(

COMBEL should decode address zero regardless of anything else really. :shrug: Is like going down the rabbit hole somehow now :roll:

I cannot really think what else you could try. The only possibly "bad" idea is to simply disable the Falcon CPU old school method, lift and tie reset and halt on it. Then have your board decode ROM space and try again.

You could do a trace on the stock Falcon of every CPU pin (or every expansion header pin at least) and see if there is any clues or anything going on right after reset.

Also a wild guess, maybe try delaying UDS, LDS after AS goes low.

[Badwolf]

Also a wild guess, maybe try delaying UDS,LDS after AS goes low.

Will try that, but the board with a real CPU on it should have had its timings right.

I've run out of time on this tonight -- I forgot I bricked the other board so soldering the bodge wires on the FC lines hasn't helped me X_X

Away for a couple of days now, so it'll have to remain a mystery for a bit, I'm afraid. :(

BW

[exxos]

Also a wild guess, maybe try delaying UDS,LDS after AS goes low.

Will try that, but the board with a real CPU on it should have had its timings right.

I had a quick look at the datasheets, I could have been thinking of write cycles.

You haven't simply got something stupid like bad grounds on your board ? Just thinking while your PLD is putting address zero on the bus, is the Falcon motherboard actually seeing that logic low ? I don't mean looking on a logic analyser either, measure the voltage with your scope..

You probably need 2 scope probes, one on your board for A2 for example, then one on the Falcon somewhere ( possibly on the ACIA pins) then do a "difference" between both probes on your scope to get the voltage difference.

[Badwolf]

Right. I'm back. So quick update:

Turns out I'm a fool and apparently COMBEL does need the FC[2:0] lines driven to decode addresses properly. I didn't wire them up with this board as I, without any justifiable reason in hindsight, thought they served no purpose on the motherboard. Damn.

In retrospect, the FC lines would be needed for the onboard FPU chip select decode, so it was perhaps obvious I needed to pass them through.

Anyway three bodge wires later the Falcon is now decoding addresses and reading from ROM. :oops:

I found and fixed a bus error logic fault in my verilog which now allows the Atari logo to come up and the memory test to pass *but* both IDE and floppy fail to work (the IDE at all and the floppy properly). When the desktop comes up, it's devoid of icons.

Four bombs on inserting a floppy disc at boot.

When the desktop comes up, the screen doesn't redraw unless a blitter event (bus master change) occurs. So moving the mouse has no response unless you hit a menu or if, for example, you click and drag so the rubber band is refreshed. I can see interrupt events being requested and serviced, however.

Diagnostic cartridge fails to boot.

Now, I'm sure I've seen all this behaviour before. But I can't remember what the issue was. My immediate suspicion is the UDS/LDS decode logic is perhaps wrong, but that's taken from a working project so it could mean something upstream of that is faulty (perhaps shorted SIZE[1:0] lines?).

Anyway, progress bringing it up, but we're not there yet. :thumbup:

Anyone with any obvious insight into the symptoms above, in the mean time?

Ta,

BW

[exxos]

In retrospect, the FC lines would be needed for the onboard FPU chip select decode, so it was perhaps obvious I needed to pass them through.

Anyway three bodge wires later the Falcon is now decoding addresses and reading from ROM. :oops:

:dualthumbup: :yay2:

Now, I'm sure I've seen all this behaviour before. But I can't remember what the issue was. My immediate suspicion is the UDS/LDS decode logic is perhaps wrong, but that's taken from a working project so it could mean something upstream of that is faulty (perhaps shorted SIZE[1:0] lines?).

Sounds like DMA / bus mastering issues. That would be relating to BR,BG,BGACK timings. I can only really comment for the ST of course, but are you delaying BG by a couple of clock cycles ? one trick I do is wait for /AS and /DTACK to go high as a reference point as to when nothing is using the bus so then allow BG from the CPU to system.

A lot of this stuff drove me nuts, because you are literally working down to nanosecond levels. Tolerances in the hardware can make or break a design if it is borderline. It is why I basically gave up with original machines because there is just too much variation on everything.

[Badwolf]

Sounds like DMA / bus mastering issues. That would be relating to BR,BG,BGACK timings. I can only really comment for the ST of course, but are you delaying BG by a couple of clock cycles ? one trick I do is wait for /AS and /DTACK to go high as a reference point as to when nothing is using the bus so then allow BG from the CPU to system.

I don't think it's bus mastery for a few reasons.

Firstly, the bus arb code is pretty mature. It's gone through four different card developments. Secondly the blitter is working. In fact the screen only updates *when* the blitter does something (NB. that's not we only see what the blitter does, I mean the redraws only happen after a bit of bus arb). Thirdly, when the mouse is moved I see the interrupts coming in and being serviced but there's no bus arbitration going on at the time. Fourthly the IDE doesn't need bus arbitration at all. Fifthly bus arb isn't needed to boot the diagnostic cartridge (well, apart from the intitial taking over of the bus).

That said, I shall rule nothing out! :lol:

The last one -- the diag cart not booting -- is a big one, though. I haven't had that happen much before. I have seen odd desktop and drive behaviour in the past when I wasn't properly asserting UDS/LDS for the purposes of cache fill, but that's a known quantity now.

Perhaps it's related to the switch to 16MHz?

Quite a few lines of inquiry still.

The only *absolute* positive: the clock switching to 36MHz whilst AS is inactive does still work. Inadvertently tested. ;)

BW

[exxos]

The only *absolute* positive: the clock switching to 36MHz whilst AS is inactive does still work. Inadvertently tested. ;)

Do things work at stock speeds though ?

I assume you have scoped out the clock switching in action?

[Badwolf]

The only *absolute* positive: the clock switching to 36MHz whilst AS is inactive does still work. Inadvertently tested. ;)

Do things work at stock speeds though ?
I assume you have scoped out the clock switching in action?

No they don't.

The clock switching was turned on by accident whilst debugging -- it made no difference but was a pleasing finding that it ported across without hitch. It's back off again now.

I haven't yet ruled out AS/DS timings with respect to the clock line yet (different board, different timings), which is why I'm just trying to run at mobo speeds ATM. One of the reasons I'm musing over the 16MHz switch.

BW

[Badwolf]

Three guesses as to who spent an hour this evening debugging why his board had stopped doing anything at all before noticing one of his bodge wires had fallen off...

[PhilC]

:shock:

:chairsmack: