exxos's DFB1 trials

[stephen_usher]

Interesting that the "RAM Access" speed has dropped to 89%. Cycle mismatch adding wait states?

[exxos]

Interesting that the "RAM Access" speed has dropped to 89%. Cycle mismatch adding wait states?

I noticed that as well. It could just be down to the version of MAPROM I am using. I am trying to find out what the proper tools are for the thing :shrug:

[exxos]

ahhhh so the buffer on the CPU clock, even though is only like 2ns causes that RAM slowdown :shock: :shock:


40MHz re-test without buffers.

IMG_0714.JPG

With ST536 RAMROM. (BLTFIX doesn't seem to work right it seems as icons are still missing in the first GB6 test)

IMG_0715.JPG

[Badwolf]

Yes, disable flash until you've flashed something.

Yes, the default is a CLKOSC/2 FPU clock.

Yes disrupting the CPU timing could affect RAM speeds, so could fiddling with the clock switching logic as it relies on there being a dead cycle in the 'normal' operation. Switch slightly later and that dead cycle might hit the first access (for example).

No, blitfix won't work. It can't. There are no soft-blitter routines in TOS4.

Otherwise, congrats! It's up and running, albeit the FPU still seems bloody finickity!

:girldance:

BW

[exxos]

Otherwise, congrats! It's up and running, albeit the FPU still seems bloody finickity!

I don't think it is now. It would have to be proven, but I suspect one of the DSACK line is still "low" ( or maybe both ) when the FPU starts it's cycle. The FPU datasheet says there can be a skew between DSACK0/1 . So if DSACK0 is low on the MB and DSACK1 goes low on the FPU, then the CPU completes the bus cycle. When in actualfact the FPU hasn't issued DSACKx yet. It trips up.

What I did was to run DSACK via a FF and not allow FPU_CS to go low until both DSACK are high. I'm sure I tried delaying FPU_CS before by a fixed delay and it didn't work. Anyway the fix seems to be working fine.

249% FPU / 40MHz = 6.225 X 16MHz = 99.6% so it's not like the FPU has even been slowed down by anything.

The only issue is, I can't get the CPU to run right at 50mhz. They keyboard repeat doesn't work and it locks up. Though all my cpus were tested on the TF536. I've ran up to 5.30v and tried freezerpray to no avail. So I think something else is tripping up.

I will try some more cpus tomorrow. But 40mhz CPU & FPU works fine , so I'm happy enough to think about putting them in my store soon :)

[Badwolf]

I presume your use of DSACK0 there was just an example? There is no DSACK0 on the expansion port. XDTACK drives DSACK1 on my board (apart from during DSP access).

Waiting for XDTACK to be high for a couple of cycles ought to be sufficient, therefore.

BW

[exxos]

I didn't know both wasn't on the port. But haven't looked either. I can try XDTACK. Probably won't make any odds if it's the same signal anyway.

[Badwolf]

I didn't know both wasn't on the port. But haven't looked either. I can try XDTACK. Probably won't make any odds if it's the same signal anyway.

DSACKx are derived. XDTACK is what the motherboard provides, so is the better thing to gate against.

If this is genuinely the issue, this should be a very reliable fix and easily backported. :)

BW

[exxos]

DSACKx are derived. XDTACK is what the motherboard provides, so is the better thing to gate against.

Oddly XDTACK doesn't work, but using DSACK0 or 1 does :shrug:

EDIT:

OK a simple delay on FPU_CS seems to also work.. But I am sure I tried all that on the original board and it didn't work. :shrug:

Though I think I be happier still using DSACK for the delay check.

[Badwolf]

Oddly XDTACK doesn't work, but using DSACK0 or 1 does :shrug:

That's interesting, it could mean that the FPU itself is stomping on its own accesses? That said you've changed the whole DSACK[x] logic, as I understand it, so I may be way off-base.

On my boards DSACK[x] was fully derived and there was a dedicated FPU_DSACK input to the CPLD. If you've now gone for an open-collector shared DSACK[x] bus between the CPU and FPU, I don't know what's relaible to sample any more.

BW