DFBX1 Issues

[stephen_usher]

Thanks.

I'll probably have a look at this next week. At the moment I'm still trying to get over viral bronchitis I picked up from the retro computer festival in Cambridge nearly two weeks ago. Almost zero energy at the moment.

[sporniket]

Yeah. I don't s'pose you have a KiCAD footprint for the cartridge port edge connector and socket do you?

Nope, but I believe @sporniket STE recreation is public somewhere with all the lib for KiCAD.

Yes, you will find the footprint among thess collections : https://github.com/sporniket/kicad-footprints-handmade/

More precisely : https://github.com/sporniket/kicad-foot ... .kicad_mod

[stephen_usher]

Thanks....

One fly in the ointment though, I thought that I had a spare cartridge socket hanging around, but I don't, so not much point starting the project without one of those unobtainium items.

[charon030]

I dug a bit deeper into the non-booting Falcon with the NetUSBee and the DFBx1 running at 50 MHz with Flash enabled.

First, I checked the Verilog code used in the CPLD to get a better understanding of how the accelerator works. It seems there is a delay pipe for the address strobe used for DSACK generation.
https://github.com/dh219/DFB/blob/5db49 ... 1r5.v#L218

I don't think the code for the Exxos board is freely available, so I have to take this one as a reference. There, the delay is set to 80ns at 50 MHz (i.e. four clock cycles - for 40 MHz this makes 100 ns delay, obviously, so no issue there with booting..).

The Flash memory is said to have an access time of 70ns. However, this is taking just a load of a single TTL gate or 30 pF capacitance. I wonder whether the additional NetUSBee in the ROM-port just increases the load / the capacitance on the data bus such that 80ns access time become too aggressive. I mean, it seems to work and crash only after the boot process made some progress already. So it might just be the edge between working/non-working in that case.

If that would be true, potentially a single change could resolve this issue:
wire [1:0] ROM_DTACK = { rom_access | ( lowspeed ? AS_DELAY[4] : AS_DELAY[1] ), 1'b1 };
becomes
wire [1:0] ROM_DTACK = { rom_access | ( lowspeed ? AS_DELAY[5] : AS_DELAY[1] ), 1'b1 };

I'd love to test this assumption. I have all the tools (ISE installed, Xilinx programmer), but no Firmware code Is there a chance to try this jointly?

[exxos]

Have you tested TTram with flash disabled?

If the bus is unstable then I'd assume TTram would also fail not just flash..

When you say doesn't boot, what do you mean exactly? White screen?

IIRC The booster runs at 8MHz during bootup. I forget what point fast mode is enabled. I think it was just before it gets to desktop.

EDIT:
A quick look at the DFB1 code its got a fixed delay.. I'm not sure if things changed in the DFB1X branch.

[charon030]

TT RAM always works for me (40/50 MHz, Flash on/off).

From the code it looks like it takes about 2 seconds before the high-speed mode can be used (500 kHz clock, 2^20 ticks counted):

https://github.com/dh219/DFB/blob/83857 ... b1r5.v#L72

I have the white screen with Atari logo already, then it can stop in the middle of the output "Memory Test", so it could just write a part of it.

I'm just contemplating whether there is a risk of setup-time violations for the 030 when latching the data bus with data from the Flash chip as the margin doesn't seem to be very high when running at 50 MHz.

I didn't look in detail into the SDRAM, but it uses a different control logic and has a very different timing characteristic compared to the Flash chip.

[exxos]

I can't do much as I'm not at home and probably won't be able to look into more for a couple days.

If it is a data bus issue then meanwhile, I'd suggest hacking on another 10k sil on the back of the falcon motherboard sils. Then see if its more stable. The cpu has stronger pulldown current than pullup. So the extra pullup current should solve the problem. If it does, then it would have to be a future mod on DFB1X runs.. So it be useful to know if that is the issue.

[Badwolf]

TT RAM always works for me (40/50 MHz, Flash on/off).

From the code it looks like it takes about 2 seconds before the high-speed mode can be used (500 kHz clock, 2^20 ticks counted):

https://github.com/dh219/DFB/blob/83857 ... b1r5.v#L72

This is an area I know is different between current DFB1 release code and DFB1X. DFB1X swtiches based on the bus control CPU speed register access.

When I implemented that delay I hadn't figured out what the problem was yet so it was a simple timer that is normally sufficient to get past the point that the bus is switched to 16MHz which, as implied by my comment there, takes longer to happen under ET than TOS4.

(the background being the clock switching logic causes at least one half-cycle of half-speed upon switch. This is fine at 16MHz but breaks down at 8MHz)

BW

[charon030]

When I implemented that delay I hadn't figured out what the problem was yet so it was a simple timer that is normally sufficient to get past the point that the bus is switched to 16MHz which, as implied by my comment there, takes longer to happen under ET than TOS4.

(the background being the clock switching logic causes at least one half-cycle of half-speed upon switch. This is fine at 16MHz but breaks down at 8MHz)

BW

Thanks for that explanation. But I don't think I got what you mean with "half-cycle of half-speed upon switch" and why this breaks at 8 MHz but works with 16 MHz.

EDIT: And it was interesting to browse through the Verilog code to get a better understanding how the accelerator works. W.r.t. clocking it does the same as my previous accelerator (PowerUP2). That one clocked the CPU at 32 MHz whenever there was no bus access at 16 MHz happening. That gave a nice boost already. And it explains why I saw practically zero gain in Gembench with the DFBX1 installed while Flash or TT-RAM are not being used. It seems the difference between 50 MHz and 32 MHz is negligible when only ST-RAM accesses happen as the caches of the CPU are too small to process longer periods without ST-RAM accesses.

[charon030]

I can't do much as I'm not at home and probably won't be able to look into more for a couple days.

If it is a data bus issue then meanwhile, I'd suggest hacking on another 10k sil on the back of the falcon motherboard sils. Then see if its more stable. The cpu has stronger pulldown current than pullup. So the extra pullup current should solve the problem. If it does, then it would have to be a future mod on DFB1X runs.. So it be useful to know if that is the issue.

It's not urgent for me. Would it be possible to make a trial with a test-firmware for the CPLD that uses an extra delay cycle for flash accesses, once you have time again? I think it's just a one-liner to change in Verilog (see previous posts). At the same time I don't want to appear too demanding. But it would just be nice to have the NetUSBee usable with full performance of the accelerator. I don't care if access time is 80ns or 100ns. For 40 MHz it seems to be 100ns anyways.

Thanks.