REMINDER - Stay logged in for at least 2 hours a week to get whitelisted.
Also it helps build a picture where our "good traffic" is coming from for detection scripts.
:o)
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
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.
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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2 FrontBench The Frontier: Elite 2 intro as a benchmark
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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2 FrontBench The Frontier: Elite 2 intro as a benchmark
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
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 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.
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
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2 FrontBench The Frontier: Elite 2 intro as a benchmark
This is the line to alter to sleep(10), if you have the means to recompile?
BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2 FrontBench The Frontier: Elite 2 intro as a benchmark
