exxos's DFB1 trials

[Badwolf]

I have been using Thorsten's 9.3.1 lately for my project (with those options: m68k-atari-mint-gcc-9.3.1.exe -Iincludes -Wall -Wextra -pedantic -Ofast -fomit-frame-pointer -m68030 -fno-common -std=c99) and it does not require an FPU apparently.

Are you sure that switch is actually doing anything? I can't find 9.3.1 available on Thorsten's site any more, but the 9.5 version I've just downloaded doesn't include an m68030 library, just the 000 (default), the m68020-60 version and the coldfire (m5475) version.

I suspect -m68030 is just linking to the 68000 library.

Code: Select all

$ ls -F usr/lib64/gcc/m68k-atari-mint/9/
cc1*       include/        libgcc.a   libssp_nonshared.a  lto-wrapper*  mshort/
cc1plus*   include-fixed/  libgcov.a  libstdc++.a         m5475/
collect2*  install-tools/  libssp.a   libsupc++.a         m68020-60/

BW

[exxos]

Been looking into the intermittent FPU failures and also why 50MHz FPU isn't working.

It looks like the cycle before the FPU access is "sluggish" to finish. Basically when /AS goes high, some of the databus stays low for approximately 50ns. isn't necessarily a problem by itself, it's just what the Falcon is doing :roll: It is compounded by it then takes a further 50ns for the pullups to lift the low to a high. All in all, this seems to be why its tripping up. As the FPU is so fast, its not giving the previous Falcon bus cycle to fully finish before the FPU cycle starts. Something trips up at that point, so I had to add a small delay to the FPU CS to avoid it.

I have been running one board for the past couple of hours and it seems fine. The only consequence is the FPU score has dropped from 311% to 308%.

[exxos]

I have been thinking about the jumpers on things like disabling the booster and flash bank select etc. The "problem" is that currently some features are only doable by physical switches which I am against drilling holes in the case for.

Currently with the case open, you need to disable the booster, so it runs of the motherboard ROM, so then you can flash the ROM images in the DFB1X flash. But once a case is closed there is not going to be any simple way of doing this. Similarly, there is no current way of selecting the flash bank without a physical switch.

In the case of ROM bank, a wire could be added to the PLD to allow software switching of banks. It is not really a very elegant solution because the machine will always boot up in one bank, and you would have to run a program to switch it to the other one. Whereas with a physical switch you can always boot up in the bank you want.. But again I don't like drilling holes in the case for switches.

Similarly, we need to disable the DFB1X to program the flash. I have a workaround for this which would need another wire to the PLD. currently I have been experimenting with SI.CPX and using the 8MHz mode to disable the booster to run legacy software which may run too fast even at a 16MHz bus. Though realistically I think it should probably disable the booster altogether. Which would then allow booting from motherboard ROM to program the flash without needing physical switches.

What I did on flashy clock was store various selections in the NVRAM and load them into the registers during reset. So this way you can always boot up with the OS you wanted without having to switch with the program afterwards. But I don't think it is going to be so simple on the Falcon. Indeed it sounds like something which would take more time than I am really willing to invest in at this point.

So while I think switches is not a ideal solution when the case is closed. Software switching may not be totally elegant either, but I think it is more elegant than drilling holes in the case.

[Badwolf]

I just run a bit of ribbon cable out the cartridge port.

But then I don't go in for elegant. My old Falcon case is full of hacks anyway as I took wire cutters to it back in 1996!

BW

[exxos]

Doing some more experimentation with the actual voltage of the 5V rail. Currently been running about half an hour on 4.8V. This is doing FPU loop test at 50MHz. The CPU is pretty much "burn your finger hot" almost now. 45c according to my thermal meter.

5V has been my default voltage and obviously works fine.

5.2V ~ 50c, FPU is also 50c, PLD 45c. Been running half hour and seems fine.

[JezC]

But then I don't go in for elegant. My old Falcon case is full of hacks anyway as I took wire cutters to it back in 1996!

BW

@Badwolf - sounds like a Franken-Falcon....

[Rustynutt]

Not having the case open?
That's like a meme I'd seen where a lady cook is reading ingredient instructions to use leftover wine, and she says "what the hell is left over wine?" :lol:

On the AB (no photos, it's too scary for sensitive eyes), found a two position 4 pole (?) switch that allows either two pins of the F030 CPU to be either lifted and grounded, or connected back to the MB pads. Works a sort. Really need to catch up on the DFB :)

[chronicthehedgehog]

So while I think switches is not a ideal solution when the case is closed. Software switching may not be totally elegant either, but I think it is more elegant than drilling holes in the case.

What about a wireless switch board? https://uk.farnell.com/dfrobot/tel0140/ ... price=true

Tbh, I've not read the datasheet. Probably totally inappropriate. Just thought I'd throw it in the mix :D

[nokturnal]

Hi, I've installed DBF1X and I spent some time with it, works great :). I've got one issue related to blitter, but I didn't know it.
Symptoms were that after launching hd driver (12.00 in my case) and running PRG files from auto (with XBoot III and also without it) maprom_c was usually launched and freezed right away or programs after it like wdialog/nvdi crashed and some corrupted strings were output to TOS console. I couldn't reach GEM desktop.
I could run wdialog/nvdi from auto and launch maprom_c manually from desktop only. Even when I ran it I couldn't run most programs (I've got for example 3 bombs and after a second 9 bombs), but gembench and yaart worked ok for instance.
Other maprom_c/maprom versions from tf tools behaved in similar way. Without maprom_c boot process was ok, but there was no support for fastram (,which is quite understandable).

Anyway here is the HD Driver screen to watch for:

hddr_12_blitterSupport.jpeg

After I've disabled Atari IDE Blitter support (it was checked before in my case), everything started to work as supposed to.
Also couldn't run image flasher from FIXED archive on DFB1X info site, one downloaded from BadWolf repository worked ok (,but I'm not sure if it wasn't issue related to this ide blitter option).
Also there was little fresher version of maprom_c (2.2, from maprom_old in tft tools), compiled it from sources. Supplied version is v1.9.

[frank.lukas]

DFB1 and Blitter do not work.

Use the patched TOS 4 from Badwolf with Fastram Support or EmuTOS ...