... that only makes it worse.
DFB1r4 design discussion thread
Re: DFB1r4 design discussion thread
Oops. Too late!
Anyway reflowed, sanded lightly (*cough*), buzzed out my board. Still not working.
I suppose it could be a bad 2x25 female header, or a voltage that looks low on the probe but is ambiguous to COMBEL.
Anyone know a good place to probe A16-23 on the motherboard?
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: DFB1r4 design discussion thread
I would just ordinarily cheat.. Just have one probe on the known address lines on your booster board, and just run the other probe around the the board CPU on continuity test.
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: DFB1r4 design discussion thread
Trying to apply more brain to this, I can't think of single stuck (high) line that would cause a bus error on a longword read.
0x000001: reads ok
0x000002: reads ok
0x000004: reads ok
0x000008: reads ok
0x000010: reads ok
0x000020: reads ok
0x000040: reads ok
0x000080: reads ok
0x000100: reads ok
0x000200: reads ok
0x000400: reads ok
0x000800: reads ok
0x001000: reads ok
0x002000: reads ok
0x004000: reads ok
0x008000: reads ok
0x010000: reads ok
0x020000: reads ok
0x040000: reads ok
0x080000: reads ok
0x100000: reads ok
0x200000: reads ok
0x400000: reads ok
0x800000: reads ok
So it seems much more likely to me that a substantial proportion of lines must be reading as high.
It doesn't seem to be the motherboard as the DFB1r3b2 still works so what on the board could cause multiple (likely higher order) lines to read as 1 instead of 0, even though they seem to probe well enough?
Theories so far:
* Lines aren't driving low enough. Will have to crack out the scope to test this one.
* Something wrong with the data strobes? AS we know is getting through. We're not sure about the address lines, but AFAIK the only other players in the exchange with the mother board is UDS and LDS. Does anyone know what happens if no data strobes are issued, for example? These again read logically OK, but I think I'll need the scope on them.
* Timing? Perhaps AS or DS are missing some Combel timing gate? Clutching at straws now.
The (noisy) scope is probably not an option for a Sunday night in the living room so one other option is I pop the chip and write some firmware that just tries to read 0x000000 every few hundred cycles and see how that gets on.
I hate computers!
BW
0x000001: reads ok
0x000002: reads ok
0x000004: reads ok
0x000008: reads ok
0x000010: reads ok
0x000020: reads ok
0x000040: reads ok
0x000080: reads ok
0x000100: reads ok
0x000200: reads ok
0x000400: reads ok
0x000800: reads ok
0x001000: reads ok
0x002000: reads ok
0x004000: reads ok
0x008000: reads ok
0x010000: reads ok
0x020000: reads ok
0x040000: reads ok
0x080000: reads ok
0x100000: reads ok
0x200000: reads ok
0x400000: reads ok
0x800000: reads ok
So it seems much more likely to me that a substantial proportion of lines must be reading as high.
It doesn't seem to be the motherboard as the DFB1r3b2 still works so what on the board could cause multiple (likely higher order) lines to read as 1 instead of 0, even though they seem to probe well enough?
Theories so far:
* Lines aren't driving low enough. Will have to crack out the scope to test this one.
* Something wrong with the data strobes? AS we know is getting through. We're not sure about the address lines, but AFAIK the only other players in the exchange with the mother board is UDS and LDS. Does anyone know what happens if no data strobes are issued, for example? These again read logically OK, but I think I'll need the scope on them.
* Timing? Perhaps AS or DS are missing some Combel timing gate? Clutching at straws now.
The (noisy) scope is probably not an option for a Sunday night in the living room so one other option is I pop the chip and write some firmware that just tries to read 0x000000 every few hundred cycles and see how that gets on.
I hate computers!
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: DFB1r4 design discussion thread
My board covers the onboard CPU, irksomely.
Bah! It also covers P13, the pull-up pack for the top order lines. Grr.
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: DFB1r4 design discussion thread
OK, turns out the SDMA chip has all the address lines pointing straight forward so is easily accessible without the floppy in place.
A1 to A23 all buzz out with no evidence of shorts.
UDS and LDS buzz out to the GAL at U62
=> The connector is fine and so is the contact to mobo.
Focus shifts now on logic levels and timing & maybe I need to triple check the bus arb so the UDS/LDS translation GALs come into play.
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: DFB1r4 design discussion thread
Documenting the troubleshooting, reflowing the expansion and changing a fan whilst I'm at it.
Plus bonus recollections of the travesties I wreaked upon the poor beast back at university...
BW
Plus bonus recollections of the travesties I wreaked upon the poor beast back at university...
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: DFB1r4 design discussion thread
Frustrating!
Custom firmware that just does bus arbitration and then sets A and drives AS & UDS low every now and again -- no change, bus error.
Perhaps something fundamentally wrong with my firmware?
OK, let's port the old DFB1r3b2 firmware. Known good. Popping that board in works a treat.
*an hour and a bit later*
Gaaaaah!
It *has* to be hardware on my new £50 set of boards. But what? What could cause this bloody odd behaviour? I need a flash of inspiration, I think.
BW
Custom firmware that just does bus arbitration and then sets A and drives AS & UDS low every now and again -- no change, bus error.
Perhaps something fundamentally wrong with my firmware?
OK, let's port the old DFB1r3b2 firmware. Known good. Popping that board in works a treat.
*an hour and a bit later*
Gaaaaah!
It *has* to be hardware on my new £50 set of boards. But what? What could cause this bloody odd behaviour? I need a flash of inspiration, I think.
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: DFB1r4 design discussion thread
I assume your falcon still boots as stock ?
No idea if you need LDS as well as should be 16bit access to ROM ?
No idea if you need LDS as well as should be 16bit access to ROM ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
Re: DFB1r4 design discussion thread
Yes, boots with the DISABLE jumper set, boots with no board at all, boots with one of the older boards in place.
(LDS is also set, by the way, I'm only probing the one)
I think frustration got the better of me last night. What else could be going on?
For example, does anyone know how the COMBEL works? Will it assert BERR after 100 AS cycles even if it's already asserted XDTACK? Would this be the expected behaviour if XDTACK were being inadvertently driven high throughout?
I should check to see if XROM2 is ever asserted. Although that's a hell of a thing to probe!
If all else fails, I've another (lesser -- only a 144) CPLD and if I can canibalise an old board for a voltage regulator, I could build a partial second board to drive the lines in firmware again.
What larks.
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark