DFB1r4 design discussion thread

[exxos]

I'm not too concerned about the AltRAM at the moment as I'm going to rewrite the controller again for this board (different capabilities). I'm more upset it can't even get out of reset above 45MHz -- that seems odd.

Have you checked the reset signal on your scope ? Things I have seen are it can kinda pulse high and low rather than the supposed low then high. Its rising edge is normally slow as well so it causes the logic to malfunction as your into noise margins then.

Putting a lower value pull up on reset might be worth a try. One trick I did was to run reset from the system via the pld to the CPU, but via a chain of say 10 flip flops. Use system reset to reset all 10 (low), and just tie the first FF to logic high. So if the reset glitches, it will reset the chain. Then it will only reset the cpu when reset is stable for 10 clock cycles.

[Badwolf]

Have you checked the reset signal on your scope ? Things I have seen are it can kinda pulse high and low rather than the supposed low then high. Its rising edge is normally slow as well so it causes the logic to malfunction as your into noise margins then.

Putting a lower value pull up on reset might be worth a try. One trick I did was to run reset from the system via the pld to the CPU, but via a chain of say 10 flip flops. Use system reset to reset all 10 (low), and just tie the first FF to logic high. So if the reset glitches, it will reset the chain. Then it will only reset the cpu when reset is stable for 10 clock cycles.

Thanks, Exxos. Haven't done any investigation on it yet, TBH, as was going down other items on the bring-up list, but thanks for this. Should give mea couple of avenues to explore. :-)

One thing I had thought about (but again haven't measured) was power draw. My 5V line is already a bit low so perhaps whacking up the speed could be taking it out of spec.

Cheers,

BW

[Badwolf]

Have been playing with the FPU -- can't make it work ATM. Not sure what's up yet -- will have to solder on some debug lines, I think.

But a thought crossed my mind. IIRC exxos has stated a few times that powering the FPU without a clock line can cause silicon-bye-bye.

My FPU clock is driven by the CPLD... I suspect the clock stops when I refresh the CPLD... I'm seeing a problem here.

Does anyone (@exxos ?) have any more information on this no-clock-no-likey issue? I'm thinking I might have to hard wire it to the 16MHz line whilst developing.

BW

[exxos]

While I was testing FPUs in my otherwise stock Falcon, I found that when the clock was not present it would kill them.

This came about because I was using the little overclocked board which was supplying 64Mhz clock into the FPU. I think I had bad contacts on it as just randomly die. If you times I forgot to plug the board in (16Mhz was cut under the FPU) and none of those ever worked..

https://www.exxosforum.co.uk/atari/last/FPU/index.htm

Of course I did not do massive amounts of testing because it was getting expensive :) I probably wrote about it in more detail *somewhere* but yeah, pretty much no clock = dead FPU IIRC.

[Badwolf]

*grumble, grumble, grumble*

Never bloody easy, is it?

*grumble*

BW

[exxos]

*grumble, grumble, grumble*

Never bloody easy, is it?

*grumble*

Nope. Week 4 for me and i've not been able to print a test square properly yet :)

[Steve]

Not to add any confusion on purpose, but I did have a faulty clock line on my Falcon FPU before (which I repaired) but luckily my FPU did not die. It must have been one of the stronger FPUs who lived through hard times and survived.

[Badwolf]

Not to add any confusion on purpose, but I did have a faulty clock line on my Falcon FPU before (which I repaired) but luckily my FPU did not die. It must have been one of the stronger FPUs who lived through hard times and survived.

Well I've already programmed my CPLD with the FPU in place, so fingers crossed mine's survived those brief bursts, like yours. I'll rig a bodge wire to the motherboard clock whilst debugging, I think.

Ta.

BW

[Badwolf]

So a little bit of progress in the short time I've had today.

Exxos's reply prompted me to rig an accelerator block. I've based it on reset and the first access to the bus control register of the COMBEL. When reset goes low, the clock is blocked from bursting to full speed. On first access of the bus control register, the clock is allowed to gear up. Seems to work well enough for now and I've got the 50MHz oscillator booting :-)

Not too terrible on the GB6 scores:

IMG_4757.jpeg

Some tasty AltRAM speeds on NemBench:

IMG_4759.jpeg

23.6 on @czietz's Coremark is the best I've achieved yet.

IMG_4758.jpeg

And a solid 3600 frames on the Frontier Intro benchmark.

IMG_4761.jpeg

That said, this is my old and very inefficient (in terms of CPLD space) SDRAM controller and there's the occasional problem still. Frontier hung a couple of times. Doom under MiNT has been hit and miss, so that's still a target for attention.

Whether that comes first or the FPU will depend how deep I feel like going next time out, I think.

But a decent night's work, I reckon -- providing I've not toasted my FPU :?


Cheers,

BW

[exxos]

Good progress :dualthumbup:

Edit:
Now I think about it, I think my early boosters had a odd issue with clocks during reset. I had to run the CPU at 8Mhz during reset else it wouldn't boot. But when reset went high I could then switch to 16mhz just fine. I don't think my SEC booster had that problem though and it ran 64mhz and up fine.

I assume you isolating AS30 from access zero and you decoding it yourself ? Only thing I can think of currently. As if the ST decodes zero then it will be based on 8mhz clocks and keep DTACK low for A while..