DFB1 Support thread

[markus0321]

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

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.

[Badwolf]

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

[foft]

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]

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]

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

I always set the jumpers the same as you described.

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. I now have a second DFB1 and it behaves the same way, maybe my flash chips are damaged?
I don't have the adapter with me now, so I can't check it in the programmer. I have the AM29F800 at my place and I can check them, but I would have to find them first.

[markus0321]

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

Okay, then I'll check again at my place with the latest program.

[Badwolf]

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.

OK, that sounds like perhaps the programming command is different on the 800. I'll have a look at the manual. Perhaps we might need a slight firmware tweak (ATM the top address line A19 [IIRC] is hard coded to 0).

BW

[Badwolf]

@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

[markus0321]

@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

I changed from 5 to 10 compiled and it works.
Now I have MX29F800 programmed with EmuTOS.

IMG_20221128_185049.jpg (81.09 KiB) Viewed 1505 times

IMG_20221128_191442.jpg (70.95 KiB) Viewed 1505 times

[foft]

Awesome. Could you post the binary please? I’ve not got a compiler set up on my Falcon yet. Is vbcc the one to use?