Terrible Fire Accelerators

[EzdineG]

Originally Posted by alenppc

Did you try flashing them with a different speed firmware/or use different frequencies? I wonder if that could help the ISSI ram work. It's a shame not being able to use it considering how much cheaper it is.

And Happy Birthday plasmab!

I tried every Jed there was. The sparkle firmware does stop this RAM from failing systest, but the card was still somewhat unstable.

I'll have better answers once I obtain another set of Alliance chips and replace them on a board that currently fails with ISSI. I should have done that this time, since I don't know if my previous builds were just duds.

[EzdineG]

Originally Posted by plasmab

Also .. for anyone wanting the CD32 card

PCB Sources are opened up. Jed files to follow.

https://github.com/terriblefire/tf328

and for anyone who wants to get ahead of the game and order some PCBs

http://dirtypcbs.com/store/designer/...tf328-rev1-zip

I havent verified this but i have refactored out all my mistakes from rev 0. Cant be sure they'll work for sure but i've not had a complete failure to date.

We'd need to procure a riser for this, right? Where can a guy nab one?

Thanks for putting this out! Look forward to realizing how bad I need to recap my CD32.

[8 Bit Dreams]

Memory timing may be an answer on my problems with TF cards - since i have 15ns chips

[plasmab]

Originally Posted by EzdineG

We'd need to procure a riser for this, right? Where can a guy nab one?

Thanks for putting this out! Look forward to realizing how bad I need to recap my CD32.

I have a partially completed riser on github in my breakout repo. Otherwise badger Ian Steadman or Kipper2k.

@kipper2k may be persuaded to open source his riser?

[plasmab]

Originally Posted by 8 Bit Dreams

Memory timing may be an answer on my problems with TF cards - since i have 15ns chips

Its all very odd. But i havent tried any other RAM chips and i have a 1 clock cycle delay in there anyways. Its possible i have a bug with OE timing that I just do not see on the RAM i have.

[plasmab]

Originally Posted by EzdineG

I tried every Jed there was. The sparkle firmware does stop this RAM from failing systest, but the card was still somewhat unstable.

I'll have better answers once I obtain another set of Alliance chips and replace them on a board that currently fails with ISSI. I should have done that this time, since I don't know if my previous builds were just duds.

OK. Were your tests always failing on the same ram chip? or by chance were they always failing D31-D16?

[8 Bit Dreams]

These are the just some of many issues

[plasmab]

Originally Posted by 8 Bit Dreams

These are the just some of many issues

DiagROM does not crash with RAM issues. Its always clock , CPU running too fast or bad soldering.

[EzdineG]

Originally Posted by plasmab

OK. Were your tests always failing on the same ram chip? or by chance were they always failing D31-D16?

I attached some images in an older post. Looks like it's random.

http://eab.abime.net/showpost.php?p=...postcount=1213

[Stedy]

Hi,

Can someone amend the DiagROM tests to do something a bit clever?

You need to know if the issues you are seeing are due to read, write or read/write failures of the RAM. A standard memory test writes a known value and expects to read that result, simples. Now the data could be written correctly but read out incorrectly, you'll never know.

To verify the read timing, read a RAM location, maybe 100 times. On the first read, store the random value, repeat the reads to the same location and see if the data read matches the first value. If it does, the problem is on the write cycle, if it does not, it is possibly the read cycle as well. Obviously change the timing of either cycle and repeat until results are good.

If using DRAM, you need to increment past page boundaries to ensure refreshes work and bank select signals work. It is also good, with DRAM, to write to some high order addresses, wait 5-10 minutes and then read the locations and validate the results.

The other tests, are to cool and heat the cards/devices. Try some freezer spray, this speeds up the timing by 10-20%, depending on the technologies. Likewise heating the card gently (to around 50-70C) will slow down the design by 10-20% compared to the nominal at 25C. This is a proven method to find some marginal timing issues, something I've done a lot the last few years.

The final test I do is use a buzzing relay to see how well the design copes with EMI. I have a bit of a reputation of finding faults with equipment.

[Stedy]

Originally Posted by plasmab

I have a partially completed riser on github in my breakout repo. Otherwise badger Ian Steadman or Kipper2k.

@kipper2k may be persuaded to open source his riser?

I have the keyboard firmware working on my CD32 riser now, needs some refinement over the weekend, then I can look at getting a prototype riser, with 2x MCA connectors manufactured shortly. It also has a minimig SCART connector and RS232/TTL serial.

There will be another riser card with 1xMCA and 1xPCI style connector for future accelerator cards. All variants will be open source.

[plasmab]

Originally Posted by Stedy

Hi,

Can someone amend the DiagROM tests to do something a bit clever?

You need to know if the issues you are seeing are due to read, write or read/write failures of the RAM. A standard memory test writes a known value and expects to read that result, simples. Now the data could be written correctly but read out incorrectly, you'll never know.

To verify the read timing, read a RAM location, maybe 100 times. On the first read, store the random value, repeat the reads to the same location and see if the data read matches the first value. If it does, the problem is on the write cycle, if it does not, it is possibly the read cycle as well. Obviously change the timing of either cycle and repeat until results are good.

If using DRAM, you need to increment past page boundaries to ensure refreshes work and bank select signals work. It is also good, with DRAM, to write to some high order addresses, wait 5-10 minutes and then read the locations and validate the results.

No DRAM involved here. @Chucky may want to improve the tests?

The other tests, are to cool and heat the cards/devices. Try some freezer spray, this speeds up the timing by 10-20%, depending on the technologies. Likewise heating the card gently (to around 50-70C) will slow down the design by 10-20% compared to the nominal at 25C. This is a proven method to find some marginal timing issues, something I've done a lot the last few years.

I have frozen with butane and put the heat gun on things my side. I'll be honest though i am not claiming bullet proof hardware. Just repeatable on the parts I spec. You cant really adjust the timing much on those CPLDs. I could possibly put more specs on the output pins. At the moment I have only spec'd the clocks. The RAM CPLD is optimised for size because of the SPI code in there. It may work better without it and optimise for speed.

The final test I do is use a buzzing relay to see how well the design copes with EMI. I have a bit of a reputation of finding faults with equipment.

This is not something i'm supporting. I see these accelerators as something you'd use in a home environment for gaming. I've never found any Amiga reliable enough for anything else anyway.

[Mr.Flibble]

Just a quick update, I built up one of the relocator boards - it's a touch tricky soldering around the socket overlap, but do-able with plenty of flux and going sparingly with the solder.

You might need to bend/resolder the cap at C816 otherwise it'll stop the board going into the cpu socket properly, but clearance looks good up to the big caps at the top of the board.

Just going to check clearance for closing the case now...

Edit: Looks good - keyboard is well clear, no issues closing the case - pics to follow.

Edit 2: Pics attached.

[EzdineG]

Originally Posted by Mr.Flibble

Just a quick update, I built up one of the relocator boards - it's a touch tricky soldering around the socket overlap, but do-able with plenty of flux and going sparingly with the solder.

Awesome, thanks!

[EzdineG]

Originally Posted by Stedy

Hi,

The other tests, are to cool and heat the cards/devices. Try some freezer spray, this speeds up the timing by 10-20%, depending on the technologies. Likewise heating the card gently (to around 50-70C) will slow down the design by 10-20% compared to the nominal at 25C. This is a proven method to find some marginal timing issues

Possibly anecdotal, but the ISSI RAM boards could loop Frontier's attract usually once at cold boot. After a few minutes of use they would immediately crash after loading and wouldn't revert to the previous behavior until cooled - and I'm not talking about overheating chips. We've already established it is most likely timing related, so these may just be slightly outside acceptable limits.

[plasmab]

I noticed a possible problem on the Rev 3 firmware.. I've not got time to test it myself but here is a rev3 ram cpld jed for anyone wanting to try it out.

*removed because it was broken and i dont want to waste people's time*

SPI port is removed and its optimized for speed.

[mattymuc]

Thanks Stephen for the CPLD update. Because all of my Rev.3 are unstable I installed it on one and now, no FastMem is detected at all.
So with this CPLD update FastMem is disabled

[plasmab]

Ok I'll have another look. I didn't test


Sent from my iPhone using Tapatalk

[plasmab]

Ok try this set.. i noticed that the source i used to build the jeds had a screwup in rev3 ucf files that might have caused the issues in timing we've seen.

https://www.dropbox.com/s/qz872rv7kk...tf530.zip?dl=0

[mattymuc]

Ok, the 2MB FastMem are back now. But I can't start to workbench from IDE or from Floppy. DiagRom now reports FastMem errors. I get different errors on each run. I did not had errors with the last firmware that had unstable IDE.
I will try another TF530 with the new firmware later.