exxos's Atari, Amiga & retro forum

Yes, kobold is a great tool and the data corruption does not come from that one.

@Kcr060 did you mention whether this was over IDE or SCSI? Also do you have a clock patch? Have you measured the voltage as suggested earlier?

Kcr060 wrote: 08 Jan 2025 13:47 And to be honest, I am really dissapointed at this point. As I already wrote, I spent countless hours in trying to get it up and running, as well as buying a new Psu and other hardware I didn't actually need - with no effect. I had a perfectly working system before it messed up my HD (of course no backup) and if I don't find a solution soon, I would like to return that card and have a working system again.
I don't know if my card is faulty or if it is the way it is..., but for me it is absolutely unusable as for now.

We'll try to help you work it out where we can, but if you're not in the mood to carry on diagnosing, that's completely fine -- either come back when you are or revert to stock if you prefer.

When you are ready the things that need sorting out first are:

* Which of the problems exhibit when there is no fast RAM declared (this is important, a lot of problems can be fast RAM related -- don't even think about using FASTRAM or MAPROM before you have a stable setup);
* You mentioned HD and CF card. Is this one at a time or both at the same time? Is this all on IDE? If you're using SCSI, say so up front as that's a special case.

Cheers,

BW

BTW, just tried MagiC under DFB1X.

Nothing in the auto folder bar MAGXBOOT on an otherwise clean partition and the first time I had to tap CTRL-ALT-DEL to re-initialse the screen, but otherwise it came up and ran well.

If TT-RAM is available when MAGXBOOT runs then Magic starts up with it allocated already (no FASTRAM.PRG needed).

If it's not declared when MAGXBOOT is run, then it can be added by running FASTRAM.PRG from the desktop (or auto folder).

This is all with IDE and an IDE-SD card adapter.

BW

I have a stock Falcon with FPU, 14MB, TOS 4.04, hddriver 12.06 and at first I had a perfectly working ide harddisk, but this miraculously got completely corrupted after I installed the dfb1x and started fumbling around with it. I wanted to test the performance and tried to run badmood, but that had graphics glitches after a few seconds of game and then the picture dissappeared completely. After a coldboot it said "warning: bad rom crc in chip e" for the first time, which then happened quite frequently.

Soon after that my system didn't boot up any longer and it turned out that the harddisk was full of errors. I tried to repair it with correct.prg and Diamond Edge, but there were too many. Also tried to recover the data on the PC, but that also wasn't possible.

I then bought a new PSU from centuriontech, and installed a new system, but that didn't change anything. Still the system didn't run stable and from the beginning Magic did not boot.

Next thing I bought was an ide buffer, but it didn't fit with the harddisk, so I had to buy some cf adapter plus cf card. That at least seemed to solve the bad rom crc message. Magic still didn't boot and program corruption started to appear again. Emutos 1.3 doesn't work stable even without hd installed.

I tried different versions of fastram.prg and maprom.prg with no effect. Trying also different boot orders besides the correct one: Maprom, wdialog, nvdi.

I don't know, if there is a clock patch. I left the upper shielding partially installed and insulated the fpu of the dfb1x just in case it would touch the metal. I will uninstall the shielding and post a photo on the weekend.

My NVRAM is original and hence empty. Also I do have a SCSI zip drive 100 connected, but that seems to work OK still.

@Badwolf no offense, any help is highly appreciated. I definitely want a working falcon with the accelerator. It's just that my expectations were to buy a working expansion, like plug & play which didn't turn out to be that simple.
And as I mentioned before, I think it is great, that there are enthusiasts like you, bringing out new hardware and software for our beloved Atari systems.
I will install a test system from scratch on the weekend and test without maprom, as you suggested. I now got only one cf card with its reader directly connected to the ide buffer without a cable and a zip drive on SCSI.

Sorry for the long post, tried to keep it short though.

And one more weird thing: the somehow corrupted programs like kobold and others won't start and post error messages like TOS error #34 and #35, but if I start checking the CF harddisk with correct.prg and Diamond edge they do not find any errors. Unlike when the first data corruption happened with my 2.5" mechanical HD. There were hundreds of errors.
If I copy working versions of these programs over from my TT, the programs do start again.

Kcr060 wrote: 09 Jan 2025 09:42 And one more weird thing: the somehow corrupted programs like kobold and others won't start and post error messages like TOS error #34 and #35, but if I start checking the CF harddisk with correct.prg and Diamond edge they do not find any errors. Unlike when the first data corruption happened with my 2.5" mechanical HD. There were hundreds of errors.
If I copy working versions of these programs over from my TT, the programs do start again.

DiamondEdge etc. only know about the filesystem "database" entries and not the data in the files themselves so there's no way that they can detect corruption inside those.

Kcr060 wrote: 09 Jan 2025 09:15 I have a stock Falcon with FPU,

I very much suggset you remove your on-board FPU. I think this has been the guidance from around the launch of DFB1X.

14MB, TOS 4.04, hddriver 12.06 and at first I had a perfectly working ide harddisk, but this miraculously got completely corrupted after I installed the dfb1x and started fumbling around with it. I wanted to test the performance and tried to run badmood, but that had graphics glitches after a few seconds of game and then the picture dissappeared completely. After a coldboot it said "warning: bad rom crc in chip e" for the first time, which then happened quite frequently.

Bad ROM CRC?

That shouldn't ever happen unless you've been hacking TOS and could be a sign of bad clocks or poor contacts.

Soon after that my system didn't boot up any longer and it turned out that the harddisk was full of errors.

Also I do have a SCSI zip drive 100 connected, but that seems to work OK still.

Whilst I'm not sure your internal IDE should be corrupted, the SCSI drive certanly under HDDriver will unless you have AB40FIX in your AUTO folder. Files copied from it will likely be corrupted too.

I don't know, if there is a clock patch. I left the upper shielding partially installed and insulated the fpu of the dfb1x just in case it would touch the metal. I will uninstall the shielding and post a photo on the weekend.

You should not attempt to use DFB1(X) with the top shielding on. It will foul it and likely short something out or overheat. I would have thought it impossible to fit the shielding as the board greatly exceeds the width of the cut-out.

You need to know if there's a clock patch too. It's likley the clock signal strength to the board is not sufficient if there isn't one in place and could yield all sorts of errors if cycles are being dropped. This is more likely if you have an on-board FPU (which should be removed for bus contention issues anyway).

@Badwolf no offense, any help is highly appreciated. I definitely want a working falcon with the accelerator. It's just that my expectations were to buy a working expansion, like plug & play which didn't turn out to be that simple.

No offence taken. This is a shame, however. It means expectations are not being properly set on the store and is a valid bit of feedback, I think.

These are hobbiest projects sold for 30 year old beta-test level computers. Whilst DFB1 is designed to be as plug and play as possible, I don't think there's ever been any attempt to guarantee that either on my part (the designer of the original) or Exxos' part (the builder & licencee of the X version) and perhaps that ought to be made clearer, so sorry about that.

I'll try to set expections now, then. We (the forum members) will be willing to help you if you're interested in debugging this. We receive no financial benefit from your sale, nor for doing this. There is a limited pool of Falcons with an even more limited pool of DFB1Xs out there we will not have necessarily seen or be able to guess at your issues exactly. This will be a case of you doing the work with us offering guidance only.

If this is not what you want to do, I suggest declaring this now so no-one's freely-given time is wasted.

On the other hand if you'd like to continue and learn a bit more about your machine then this is a good start.

I will install a test system from scratch on the weekend and test without maprom, as you suggested. I now got only one cf card with its reader directly connected to the ide buffer without a cable and a zip drive on SCSI.

I'd suggset:-

* remove your (motherboard) FPU;
* remove any SCSI devices;
* remove the top shielding;
* disable the onboard flash (the second jumper from the right, IIRC);
* clean the expansion header contacts on the motherboard and the expansion socket contacts on the DFB1 with a squirt of contact cleaner and then reseat the board a handful of times;
* disable your auto folder.

This will reduce your configuration to a straight CPU accelerator.

Then run through your tests. If you see problems in this configuration there is no point enabling more (it will simply confuse things).

If there are no problems we can start enabling features, but I think we'll wait for your feedback on the above first to see if there are still problems and what they are.

BTW, TOS error #35 is the generic corrupted program error message and is exactly what you get if data is being lost during write.

Regards,

BW.

@Badwolf Thank you very much. I will do all the things you suggested. I will have some time on the weekend and we will see how far I get :-)
Concerning the shielding I followed this guy:

https://nokturnal.pl/2023/07/atari-falc ... -expansion

He also left the shielding. It fits.
My idea behind that was simply to do the least mods possible to the machine and thus keep it in the most original state.
I mean, I removed only the top from the upper shielding, just like seen in the link above.

Interestingly I had no SCSI issues so far. At least I did not realize any.

And by the way, the acceleration itself seems to work as the benchmarks show.

With the DFB1X the shielding doesn't touch anything other than the top of the FPU socket so it's safe. The other shielding rests upon the CPU heat spreader and so acts as a heatsink, so that's also safe.