Another tweak is that when you disable the booster no LEDs are on. So now when writing to the flash in that mode, all the LEDs now flash just as a indicator the board is actually responding!
exxos's DFB1 trials
Re: exxos's DFB1 trials
Another couple of tweaks to the firmware done now. Was a better control which BW did for booting up. It waits for the 8/16MHz register access now, rather than a fixed delay which I saw could potentially cause problems. Ironically the PLD usave is now 51%. so close to being able to fit in the smaller PLD!
Another tweak is that when you disable the booster no LEDs are on. So now when writing to the flash in that mode, all the LEDs now flash just as a indicator the board is actually responding!
Another tweak is that when you disable the booster no LEDs are on. So now when writing to the flash in that mode, all the LEDs now flash just as a indicator the board is actually responding!
Re: exxos's DFB1 trials
Tested a few more CPUs, currently they are starting to lean towards the majority are only going to work at 40MHz
I'm not really sure why this is because they were all thoroughly tested on the TF536. I have them on test for a long time and also heated them up for 30 seconds with my gas soldering going to verify reliability.
My only theory is that the TF536 is a 8/50mhz switch whereas the falcon is 16/50. You would ordinarily think that heating up the CPU what caused it to fail the same as 16/50 would. Sadly this does not seem to be the case
even that does not entirely make sense because I can run TTram test on the TF536 and would run easily all day.
On the Falcon the CPU's fail pretty much immediately. It is possible there could be some other strange "bug" going on somewhere but I have no ideas what.
It is not something which is a huge problem at this point anyway. I still have a lot more testing to do but it is likely looking that the majority of the DFB1 are going to be 40mhz. Now I don't know if this is a CPU limitation exactly or something else causing it. It is also entirely possible that those 40mhz boards could be made to work at 50 MHz if it turns out to be a simple firmware fix.
I'm not really sure why this is because they were all thoroughly tested on the TF536. I have them on test for a long time and also heated them up for 30 seconds with my gas soldering going to verify reliability.
My only theory is that the TF536 is a 8/50mhz switch whereas the falcon is 16/50. You would ordinarily think that heating up the CPU what caused it to fail the same as 16/50 would. Sadly this does not seem to be the case
On the Falcon the CPU's fail pretty much immediately. It is possible there could be some other strange "bug" going on somewhere but I have no ideas what.
It is not something which is a huge problem at this point anyway. I still have a lot more testing to do but it is likely looking that the majority of the DFB1 are going to be 40mhz. Now I don't know if this is a CPU limitation exactly or something else causing it. It is also entirely possible that those 40mhz boards could be made to work at 50 MHz if it turns out to be a simple firmware fix.
Re: exxos's DFB1 trials
Testing is going more slowly than I thought. Currently I am just testing FPU's to see which ones run at the rated 40MHz or can overclocked to 50MHz. Trying to test the FPU and CPU at the same time as a nightmare because I do not know which ones will or won't work out what speeds. So I have to do them all individually one at a time. Then retest the pair of them in a different board
The ones which I have deemed will only run at 40MHz (as stamped) will have a red dot on them. This does not mean they are faulty, it just means they will not over clock. This means they will be placed into the 40MHz CPU boards.
Currently I have about 5x 50MHz FPU's and about 5x 40MHz FPUs.
The CPU's I am just writing on them 40 or 50 so I don't get any of them mixed up and ultimately the end user knows what speed have deemed stable for that particular CPU.
Because of all this I have only managed to get 2x 40MHz boards and 1x 50MHz board fully built and tested so far.
Things are somewhat slowed down because I only actually have one Falcon I can test this stuff on
I have also started doing a "landing page" for it on my website. It's still WIP though... https://exxosforum.co.uk/atari/last/DFB1X/
The ones which I have deemed will only run at 40MHz (as stamped) will have a red dot on them. This does not mean they are faulty, it just means they will not over clock. This means they will be placed into the 40MHz CPU boards.
Currently I have about 5x 50MHz FPU's and about 5x 40MHz FPUs.
The CPU's I am just writing on them 40 or 50 so I don't get any of them mixed up and ultimately the end user knows what speed have deemed stable for that particular CPU.
Because of all this I have only managed to get 2x 40MHz boards and 1x 50MHz board fully built and tested so far.
Things are somewhat slowed down because I only actually have one Falcon I can test this stuff on
I have also started doing a "landing page" for it on my website. It's still WIP though... https://exxosforum.co.uk/atari/last/DFB1X/
Re: exxos's DFB1 trials
I have been doing a little bit of research of sorts. Oddly the Falcon seems to actually boot up in 8MHz mode until it basically gets to desktop. I don't really understand the reasoning for that because I would have thought it would not really matter. All its doing the slowing down the booting of the machine considerably
Maybe there are some other technical reasons for this but no idea.
I guess this is one of those things where a patched TOS404 could fix that issues.. or break everything ...

EDIT:
So in the TOS sources it has
But there is no bit6 
I guess this is one of those things where a patched TOS404 could fix that issues.. or break everything ...
EDIT:
So in the TOS sources it has
Code: Select all
bset #6,ABSW($FFFF8007)
Re: exxos's DFB1 trials
Could be one of the reasons the ct60 needed a patched tos 4.04. recently I think the sources were released? I think. Not sure if that might be helpful. I think @mikro has them.
Re: exxos's DFB1 trials
@Badwolf I took to bits my original Falcon to test also. This one has my little FPU hack PCB for 50MHz or something. This machine is that old it has not even got a clock patch and I have not even changed the RTC.. This Falcon I purchased from new originally somewhere in the 1990s ( 1MB machine!) . I'm not even sure the power supply was even recapped on this one. It has been out of service for a long time.
Re: exxos's DFB1 trials

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
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Re: exxos's DFB1 trials
@exxos Don't think the heatsink on the processor is on my original Falcon
Definitely needs one of your PSUs in there if you've not recapped that original power supply.
I also like the homebrew nature of the insulation for the IDE HDD replacement
Definitely needs one of your PSUs in there if you've not recapped that original power supply.
I also like the homebrew nature of the insulation for the IDE HDD replacement
Re: exxos's DFB1 trials
You missed the PSU heatsinksJezC wrote: Tue Jun 27, 2023 2:43 pm @exxos Don't think the heatsink on the processor is on my original Falcon![]()
I think do a proper job for that is somewhere around my Year 2000 "to do list"JezC wrote: Tue Jun 27, 2023 2:43 pm I also like the homebrew nature of the insulation for the IDE HDD replacement![]()
Re: exxos's DFB1 trials
That switch is really early on in TOS.exxos wrote: Tue Jun 27, 2023 11:55 am So in the TOS sources it hasBut there is no bit6Code: Select all
bset #6,ABSW($FFFF8007)![]()
Something, if a solution or related issue can't be discovered, I can easily test. I boot in "stock" configuration at "16MHz", with it jumping to 32MHz as soon at the bus control bit is read. I've not given that much though as its not been an issue here (non DFB).
But don't think the 8MHz startup is due to TOS, it's the COMBEL. The configuration bit only switches the COMBEL to full clock at that point.
Off the expansion bus, I'm finding 46 and 48MHz a limiting speed here. Of course not a DFB. I'm leaning towards that (expansion bus, or GALs, or whatever) to be a limiting factor. Where, have no clue.
It's taken years to admit that


