DFBX1 Issues

[Kcr060]

Some more testing: turns out that the suddenly non working programs like kobold and others are indeed corrupted. I copied working versions over from my TT and they started. So, this means that for a second time all my data got corrupted.
Next, I removed the hard-drive completely and Emutos again ran into these errors above. So this indeed is a hardware issue and I must assume that my DFB1X is faulty then.
If I disable the card, TOS boots up ok.

[stephen_usher]

The issue with AceTracker seem very similar to the problem I was having and noted in my posting a few days ago.

[stephen_usher]

@VadimK which clock speed is your DFB1X configured to run at? Is it a 40MHz or 50MHz version?

[Steve]

Can I just add, according to the instruction page: https://exxosforum.co.uk/atari/last/DFB1X/

First thing to check is what voltage your PSU is providing. Measure on the motherboard to check, as there will be voltage drop. On the motherboard you need to be 5v, so the PSU will probably need to be something like 5.1v.

[VadimK]

My DFB1X is 50MHz version. Screen corruption is gone but its still unstable. I didn't reported it here because its likely fault of my Falcon. I didnt checked voltage of my PSU, nor installed clock patch yet.

[Badwolf]

While we are on the topic of chips removal: what about the FPU? Not sure whether it was on Exxos page or your wiki but somewhere it was recommended to remove it due to bus conflicts. Is this still true with the Exxos version? If so, would you mind to explain why it's not a problem for TOS ROM (well, except the one described above ;)) but it is for the FPU?

Sure. I recommend removing the onboard FPU as I think it gets activated whenever the external 030 hits its own FPU. That isn't to say it would work if the external one isn't there as I've stopped the address strobe reaching it, but I think I worked out the GALs trigger the FPU enable line purely on the DS strobe, which is not isolated.

Now I'm not 100% sure sure that directly implies the onboard FPU does come out of high-z mode at all, but it would not surprise me if it did and it ties in to some FPU related problems people were having.

The reason I say 'I think' and 'it may' is that I've not actually probed the onboard enable line nor have I read the datasheet in enough detail to know what effect active enable and DS lines without a corresponding AS line would have on the FPU's pins.

Unfortunately I only worked out the FPU GAL logic after implementing my board design so there's no firmware fix for this. Safest to pull the onboard FPU to prevent short circuits somewhere.

Now the ROM on the other hand is relied on threefold. Firstly, when the blitter tries to take anything from ROM it only has access to the onboard version (see Atari logo problem, above), secondly there is a 'disable flash' option which will need the OS to come from somewhere [the flash chip itself is entirely optional] and lastly when DFB1 is in disable mode (eg. to allow flashing, or to revert to stock configuration) the flash ROM is remapped to the expansion address range, so a real ROM is needed to step in.

Btw how sensitive would the DFB1X be to 50 MHz DSP? If it worked, that would surely increase backward compatibility with DSP demos, mine included. :)

Gosh, sorry I've no idea.

The DSP is a bit of a funny one and the very last thing I got to work. There's a long post on it somewhere. It turns out the DSP latches on the deassertion of the write cycle rather than at the start of it and that cycle is controlled by the GALs. I have to therefore stall one (or two?) of the lines by half a cycle so that data is still valid on the bus when the GALs shut down the control lines.

If that timing is altered it's possible it could help (chip deasserts faster, data effectively valid longer) or hinder (half a 16MHz clock cycle is a long time for a 50MHz DSP). If I had to guess I'd say it'd probably be the former, but I wouldn't put much money on it!

I suspect it could be made to work if it didn't, but I'm afraid it'd need someone with a scope and time on their hands!

BW

[Badwolf]

Just flashed Emutos 1.3 to the second bank without errors.
Sometimes it seems to work and sometimes this happens...

I got that exact error in my last video after flashing ET1.3!

I didn't think much of it at the time as I was investigating BlueSCSI, but I wonder if there's an incompatiblity with the latest ET release?

It might be worth trying an older release.

I'm not sure what kobold does, but since it was included on one of PP's disc images I've tried to run it every now and again and I always end up with something getting messed up [this is on my accelerated ST rather than DFB1, BTW, but perhaps there's something in there that doesn't like accelerators?]. It may be unrelated but that sounds like a warning shot to me.

I've had Magic running (and I even spend a fair amount of time trying to make a bootable ROM version -- never qutie got the screen initialisation right, though) but it seemed to need special handling of the TT-RAM.

I'd suggest trying all experiements (not jus MagiC) without the TT-RAM (ie. no MAPROM or FASTRAM.PRG -- BTW, I've never recommended MAPROM) to rule out software problems with altram.

You're not using a SCSI drive are you?

BW

[stephen_usher]

I found that the ROM flash utility crashes on verify if the chip has data in that half already and you try to write a new image to it. The solution is to erase the whole chip and then reflash both images.

[Kcr060]

@Badwolf Hi.
Well, I tried to run Magic in different configurations, including with and without fastram.prg, as well as with and without maprom.prg 1.9 and 2.2. Nothing worked. It ended either with two bombs or just a blank screen.
And concerning the sudden data corruption on my harddisk and CF card (so for a second time on a freshly installed system now): it is not only kobold. Several programs just stopped working, bombing or writing TOS error 34 and 35. When I copied working versions over from my TT, they did start again.
Anyway, I will do some more testing this weekend, but actually I am running out of ideas.
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.

[Darklord]

I'm not sure what kobold does, but since it was included on one of PP's disc images I've tried to run it every now and again and I always end up with something getting messed up [this is on my accelerated ST rather than DFB1, BTW, but perhaps there's something in there that doesn't like accelerators?]. It may be unrelated but that sounds like a warning shot to me.

BW

Kobold is a file utility (and more). It far surpasses the standard file copy/move/delete speeds
of a standard ST. I use the stand-alone version, launched from an icon on my TOS v2.06/3.06
desktops. I don't use the ACC version.

It has many cool features. NeoDesk allows you to use it as a substitute for all the normal file
activities. One really handy thing for is that Kobold will delete all those pesky files that Windows
drops on my SD-cards when I do file transfers. The ones that TOS won't. When I backup my BBS
intermittently, it's over 400 folders and over 8000 files and Kobold does that in *minutes*. I
shudder to think about doing that from the standard TOS desktop. :)

I've been using v3.5 here with my 16mhz AdSpeed equipped Mega ST4, my Mega STe, and my
40mhz Pak 68/3 68030 equipped STacy for years and to the best of my knowledge, have never
suffered from any data corruption due to Kobold.

I can't speak for anyone else's experience but mine has been rock-solid, and amazing transfer
speeds compared to standard TOS.