exxos's Atari, Amiga & retro forum

Badwolf wrote: 26 Nov 2022 22:29

Badwolf wrote: 25 Nov 2022 17:17 This is untested other than in Hatari (with --patch-tos 0 set).
This applies most of the Hatari patch but hard codes the TT-RAM declaration to be 64MB rather than looking at a system variable.
This does not set _FRB

Just tried this on my DFB1 that has on-board flash and it does successfully declare 64MB TT-RAM very early in proceedings. Obviously FASTRAM/MAPROM should not be used with this image, therefore.

I don't know if this would help with the HDDriver problem or not as the examples Markus has tried were both with MAPROM still in the AUTO folder.

Incidentally, I've released a new version of DFB1's flashing application. No real difference to the binary that's been floating around, but the source is now also available:- https://github.com/dh219/DFB/tree/main/DFB-Tools

Cheers,

BW

markus0321 wrote: 28 Nov 2022 10:35 I actually hadn't thought of removing the MAPROM, I'll check it again today when I get home.
Is there a list of supported flash chips for the dfbflash.tpp program, I tried with the MX29F800CTTI-70G but it goes through the programming process supposedly correctly, then shows an error during the test and finally the memory is not programmed at the end?

I changed to AM29F400BB and it works fine but it has only one piece and I wanted to assemble a second DFB1 board for testing.

foft wrote: 28 Nov 2022 12:45 I thought you were using the 512KB 29F400?

I fitted an AM29F800 too a few weeks back and it doesn’t work yet though I left it on my queue to investigate why before posting…

Badwolf wrote: 28 Nov 2022 11:07

markus0321 wrote: 28 Nov 2022 10:35 I actually hadn't thought of removing the MAPROM, I'll check it again today when I get home.
Is there a list of supported flash chips for the dfbflash.tpp program, I tried with the MX29F800CTTI-70G but it goes through the programming process supposedly correctly, then shows an error during the test and finally the memory is not programmed at the end?

I changed to AM29F400BB and it works fine but it has only one piece and I wanted to assemble a second DFB1 board for testing.

I use MX29F800CTTI-70Gs myself, so I think that ought to be fine. Anything with that pinout and the same programming commands should work.

Perhaps it's not clear (as I've not exactly documented the flashing process!), but the DISABLE jumper needs to be set and the DIS FLASH jumper removed on DFB1 for the flash program to work. Ie. Turn off DFB1 but enable flash.

I've thought about allowing flashing when DFB1's active, but since the flashing process relies on consequtive writes for the commands, it seemed like a bad idea in the end.

BW

Badwolf wrote: 28 Nov 2022 13:22

foft wrote: 28 Nov 2022 12:45 I thought you were using the 512KB 29F400?

I fitted an AM29F800 too a few weeks back and it doesn’t work yet though I left it on my queue to investigate why before posting…

Ah, sorry -- you're quite right. I was looking at my shopping list rather than my orders history!

MX29F400.

The 800 should work with the latest firmware, but I'm afriad I don't yet have any to test with.

BW

markus0321 wrote: 28 Nov 2022 13:26 I checked 3 pieces of MX29F800CTTI-70G and each attempt to program the flash ended with a verification error.
after changing to AM29F400 it immediately works without problems for me.

Badwolf wrote: 28 Nov 2022 13:43 @markus0321,

Actually you know what it could be? The erase time.

The flashing process isn't clever. It doesn't wait for feedback from the chip, it just sits and counts to five after erasing.

The 400 series takes 4 seconds to erase, so this is enough

...but the 800 series takes 8 seconds to erase. Perhaps?

https://github.com/dh219/DFB/blob/main/ ... ash.c#L152

This is the line to alter to sleep(10), if you have the means to recompile?

BW