Thanks Steve,
Yes, the ROM+FPU has been removed (after flashing TOS404 to a bank)
The PSU is at 5v exactly. I'm aware of this being (maybe) an issue - but probably can't do much about it just yet. Will look at it separately.
Testing it in a second Falcon seems to boot more reliably. Trying to get some tests PARCP'd over to verify it is actually running at the indended speed.
You will not be able to post if you are still using Microsoft email addresses such as Hotmail etc
See here for more information viewtopic.php?f=20&t=7296
See here for more information viewtopic.php?f=20&t=7296
DFB1X bare bones build
Re: DFB1X bare bones build
@dml just to confirm, and that's measured at the DFB1X header? (the voltage)
Re: DFB1X bare bones build
After noticing a sticky cache-off bit in NEWDESK.INF, the performance tests confirm 50MHz.
Have not had time to configure a test for ALT ram but everything else seems to be working. So that's another win for today.
Have not had time to configure a test for ALT ram but everything else seems to be working. So that's another win for today.
Re: DFB1X bare bones build
Hiya.dml wrote: ↑Sat Mar 29, 2025 4:44 pm An immense amount of trial-and-error later, managed to deduce that:
- the DFB1X board is OK
- my soldering is OK
- the CPLD appears to be pre-flashed (thanks exxos!)
- flashing TOS was successful
- the CPU seems to be faulty, or at least refuses to boot at either 40 or 50MHz. It is now booting to the desktop with a second CPU at 50MHz.
Good news!
I have to preface anything I say with the caveat that the DFB1X does have some mods over DFB1 that I don't necessarily know about, so take with a pinch of salt, but I can certainly answer the flash programming question.
I use (and have only ever used as can't get Impact [ISE's programmer] to work) xc3sprog. It's probably available in most Linux distros. I have it on my VMWare Debian box and on Raspberry Pi.
This is the command I use (in a script) for flashing JEDs:
Code: Select all
xc3sprog -c jtaghs2 -p 0 -v "$1"
The initial Atari logo is drawn by blitter, so could be. This a difference between DFB1X and mine as on mine the flash is only available to the CPU. I wouldn't be able to suggest much other than to perhaps try the latest EmuTOS 512k snapshot in flash? You'll get no blitter contention there as it autodetects TT-RAM and does not use the blitter in that case.It doesn't *always* boot successfully - sometimes just a white screen, sometimes white screen with garbage in the first scanline... looks like an Atari logo blitter conflict to me.
Despite me having plugged and removed different boards so many times I still find I get poor contacts between the expansion pin headers and DFB1 sometimes. A decent dose of contact cleaner and a few goes at reseating may be all it takes. If one of the bus arbitration pins is a bit of a sticky from some flux residue in the connector you could see symptoms like yours.While this is not a perfect result, it is a lot better than 10 potentially different unknown things causing a black screen so I'm calling that a win for today.
I must say the only problem I had with the DFB1X Exxos sent me was the occasional crash booting EmuTOS. But then I found out I was meant to remove the onboard TOS.


BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: DFB1X bare bones build
Badwolf thanks for the response!
I'm kinda glad you are recommending xc3sprog because I was about to head in that direction, even started looking for the PIs. I probably need to get that working anyway for another project but it is helpful to know that I can flash FW on the DFB1X if I need to (or in case of accidents :p )
I'm a bit burned out today with various random things on top of today's Atari rabbithole festival (I won't list them all) but I'll reply properly tomorrow sometime.
Cheers,
dml
I'm kinda glad you are recommending xc3sprog because I was about to head in that direction, even started looking for the PIs. I probably need to get that working anyway for another project but it is helpful to know that I can flash FW on the DFB1X if I need to (or in case of accidents :p )
I'm a bit burned out today with various random things on top of today's Atari rabbithole festival (I won't list them all) but I'll reply properly tomorrow sometime.
Cheers,
dml
Re: DFB1X bare bones build
Another day and another exciting new problem -_-
I ran the FPU test at 50MHz and everything passes except the trig functions at the end, which IIRC is typical if the FPU is clocked too high.
I fitted the JC1 jumper (which as far as I understand, drops the board to 40MHz) and the same tests pass. So far so good.
I remove the FN40 FPU (carefully, with an extraction tool) and prepare to test with a different FN40 FPU.
I remove the JC1 jumper and boot the machine. I'm greeted instantly with a ROM error after the Atari logo:
"BAD ROM CRC IN CHIP E"
Not expected. Anyway I replace the JC1 jumper for 40MHz and boot the machine. It starts normally. The tests pass at 40MHz.
I remove the JC1 jumper for 50MHz and try again, same ROM error.
I remove the second FPU and replace it with the original one. Still the same behaviour - machine won't boot.
I remove the FPU entirely and try again. Boots normally.
So something changed after physically swapping the FPU and swapping it back. Before the swap it would to boot at 50MHz but the final trig FPU tests failed. Now that same FPU won't let the machine boot at 50MHz with a ROM CRC error. Cleaning the pins with wire brush, fibreglass brush, deoxit etc. doesn't change anything. The pins obviously have contact because 40MHz will pass.
Obviously the FPU is no good at 50 so that was a lost cause but I'm still a bit concerned at the behaviour change? Mainly concerned that the behaviour before was consistent, and now it has changed, but is also now consistent. Has anyone seen this error before on one of these boards?
I ran the FPU test at 50MHz and everything passes except the trig functions at the end, which IIRC is typical if the FPU is clocked too high.
I fitted the JC1 jumper (which as far as I understand, drops the board to 40MHz) and the same tests pass. So far so good.
I remove the FN40 FPU (carefully, with an extraction tool) and prepare to test with a different FN40 FPU.
I remove the JC1 jumper and boot the machine. I'm greeted instantly with a ROM error after the Atari logo:
"BAD ROM CRC IN CHIP E"
Not expected. Anyway I replace the JC1 jumper for 40MHz and boot the machine. It starts normally. The tests pass at 40MHz.
I remove the JC1 jumper for 50MHz and try again, same ROM error.
I remove the second FPU and replace it with the original one. Still the same behaviour - machine won't boot.
I remove the FPU entirely and try again. Boots normally.
So something changed after physically swapping the FPU and swapping it back. Before the swap it would to boot at 50MHz but the final trig FPU tests failed. Now that same FPU won't let the machine boot at 50MHz with a ROM CRC error. Cleaning the pins with wire brush, fibreglass brush, deoxit etc. doesn't change anything. The pins obviously have contact because 40MHz will pass.
Obviously the FPU is no good at 50 so that was a lost cause but I'm still a bit concerned at the behaviour change? Mainly concerned that the behaviour before was consistent, and now it has changed, but is also now consistent. Has anyone seen this error before on one of these boards?
Re: DFB1X bare bones build
You cleaned the ROM chip and socket and reseated it?
Re: DFB1X bare bones build
Yeah. Sorry. In my mind I thought the socket in the top left corner was the rom. But that is clearly for the 68882. The rom is smt so strange that it get crc error.
EDIT: AHA! I got it mixed up with ST536 where Exxos put a rom socket.
EDIT: AHA! I got it mixed up with ST536 where Exxos put a rom socket.