Yeah there will be a boost in games in general, though its more the math functions which will see the speed. Anything like 3D games will run way faster. Frame rates speed up in castle master a lot at 16mhz. Its mostly ST RAM which is the bottleneck for 16mhz. GEM/TOS runs faster on the larger mod are the CPU can access TOS directly, so both can work at 16mhz, or on the new new design 32mhz. TOS will be seriously fast on that design

I am talking to Rodolphe about the next step, and I have devised a small test to speed up ST RAM. Though there is so much stuff on the go at the moment that it will probably be done when the current 32mhz booster is finished.

Dal wrote:It's been a pleasure watching this develop. To think there were doubts of getting 16Mhz running stable, now you are talking about 32Mhz?? Very impressive - it would sit well in a MegaST.

Glad you find it interesting 32mhz was running for over a hour on my test rig, and you can see from the hack-up of it that if that works good then anything should work Of course long term testing needs to be done, though I think with us moving to the PLCC chips, they are stamped freescale, so hopefully will be a newer mask than the DIP's stamped as motorola.

The problem with 020 is what it breaks! How many will want a faster processor that breaks many games and apps? Not trying to sound negative as I think it's really great, but it could limit market further. I am not sure I would want an 020 because I mostly use the ST for gaming. If there's a PLCC HC processor that doesn't have the instruction set and timing differences then PLCC sounds fine. I just fear that when it ends up being possible it might not be practical.

GadgetUK164 wrote:The problem with 020 is what it breaks! How many will want a faster processor that breaks many games and apps? Not trying to sound negative as I think it's really great, but it could limit market further. I am not sure I would want an 020 because I mostly use the ST for gaming. If there's a PLCC HC processor that doesn't have the instruction set and timing differences then PLCC sounds fine. I just fear that when it ends up being possible it might not be practical.

Its TOS that breaks the software more than the CPU. Though from a practical point of view the Falcon has a 030 which is a totally different CPU and TOS. On that basis it would have been pointless Atari making any other machines other than the STFM. STE broke some games and that still used a 68000.

Will this board work also with TOS roms at 32MHZ? So...it will need 30ns eproms, right?Let's see how much compatible is with games . One question, how much compatible is the new booster at 16MHZ (with TOS and Blitter working at 16MHZ when needed) vs your V1?

Can't say I've tested every game coming and going, but the Pak 68/3 board I use,with its 68030 @ 40mhz, runs a lot of the "adapted" games from Dbug, PPera, andKlaz just fine. That's using TOS v3.06, and running them from an Ultrasatan.

So how much difference would there be in a step back/down to the '020?

qq1975b wrote:Will this board work also with TOS roms at 32MHZ? So...it will need 30ns eproms, right?Let's see how much compatible is with games . One question, how much compatible is the new booster at 16MHZ (with TOS and Blitter working at 16MHZ when needed) vs your V1?

The 68000 will run at 32mhz TOS and CPU, I hope the 020 CPU will also run at 32mhz, though the 020 is probably a year away easily yet.

The V1 booster just boosts the CPU, the larger booster card (i'm just going to call it V2) will have fast-tos also, that will run at 32mhz. I doubt fast-tos will break anything much so doubt there will be any compatibility issues. I can't say about 16mhz blitter issues, as only done a quick mock up of the circuit which will be in the V2 booster. I doubt it will break anything, but its switchable back to 8mhz anyway so no big deal either way.

DarkLord wrote:Can't say I've tested every game coming and going, but the Pak 68/3 board I use,with its 68030 @ 40mhz, runs a lot of the "adapted" games from Dbug, PPera, andKlaz just fine. That's using TOS v3.06, and running them from an Ultrasatan.

So how much difference would there be in a step back/down to the '020?

The 020 is more like the 68000, only it has a small instruction cache built in. Its more TOS which breaks things. If stuff is fixed to work on the 030 CPU and also still works on the 68000, then I doubt there will be many issues with the 020. The 020 is just a slightly more efficient 68000. TOS versions break things more than the CPU. Like you say though, a lot of games are being fixed to run on more machines anyway.

I thought about his just last night, I might try the one Exxos just sent me in my Amiga 500+. The first issue is finding a clock that's double the 7.14Mhz CPU clock speed. I need to look at the schematics and stuff to see if theres a 14.28Mhz clock somewhere. I guess if it's only switching to 14.28Mhz when not asserting, it will probably work, but I suspect will break a lot of games etc from what I've read.

EDIT: It needs a bit more thought as apparently the 68000 outputs some 'E clock' or something with is 10% of the CPU clock, to feed the CIA chips.

Looks like E clock will need a divide in speed then. Though I don't know how it works on Amiga. Surely E clock will get messed up as the CPU switches to 7mhz and 14mhz anyway ? We don't have this problem on Atari

As a small update. I wanted to try TOS at 32mhz so put my booster card back to basics to try it out with the HC CPU. Worked at 16mhz as expected. Though 32mhz did not work. Mostly it just was left at the white screen with a row of bombs. Removing one of the GAL's had using GLUE to decode TOS then worked. But to cut a long story short, the 32mhz clock hasn't got enough jungle juice to drive the GAL logic. This probably won't be a problem when we move over to the ATF chip, but even so, we are going to buffer the 32mhz clock and the 16mhz clock to make sure the clock is stable. I don't like things running "border line" so that is what we are working on at the moment. I should have the clock patch on my test board sorted by the weekend. Though with Rodolphe having to update the PCB design again, and even with production delays, Its probably going to go quiet on this thread for a while as there isn't much else to be done until the PCBs are produced. I'm getting busy with my day job also so my free time will rocket down until after xmas now anyway. But I will post any news on here if there is any before xmas.

exxos wrote:Looks like E clock will need a divide in speed then. Though I don't know how it works on Amiga. Surely E clock will get messed up as the CPU switches to 7mhz and 14mhz anyway ? We don't have this problem on Atari

I'm a bit surprised, actually. The keyboard interface and MIDI interface both use 6850s that need the E clock to run below about 1.14MHz. Maybe it's enough that the processor slows to 8MHz during the access of the registers and that allows an E clock cycle to be long enough.

Searching around, I found that the Amiga uses the E clock to run a timer that's used to step the disk drive motor and this has inconvenienced a few 14MHz Amiga projects as it causes problems with disk drive head movement.

The solution is a bit more difficult than dividing the E clock in half, unfortunately.

The ACIA are driven from GLUE at 500khz I think. Same chips used in the falcon where they normally get boosted to 1mhz (from memory). It is something which I mentioned a few days back. As running them twice as fast might free up a cycle or 2 on the bus so the CPU can start its next task quicker, as the ACIA's are running faster. Its something I need to try out. If it does not do anything, then its a bit pointless doing it really.

exxos wrote:Looks like E clock will need a divide in speed then. Though I don't know how it works on Amiga. Surely E clock will get messed up as the CPU switches to 7mhz and 14mhz anyway ? We don't have this problem on Atari

I'm a bit surprised, actually. The keyboard interface and MIDI interface both use 6850s that need the E clock to run below about 1.14MHz. Maybe it's enough that the processor slows to 8MHz during the access of the registers and that allows an E clock cycle to be long enough.

Searching around, I found that the Amiga uses the E clock to run a timer that's used to step the disk drive motor and this has inconvenienced a few 14MHz Amiga projects as it causes problems with disk drive head movement.

The solution is a bit more difficult than dividing the E clock in half, unfortunately.

The E clock is used when the 68000 "talks" the the ACIA. The 500KHz clock is the base clock use for the serial speed on the ACIA.As the CPU slows down to 8MHz when accessing the ST bus , the E clock is back to the expected values.So it should work as nothing else is talking to the ACIAs but the 68000 (and it does as the current booster works).Rodolphe

I never saw the point of speeding up the ACIAs like Nemesis and CT60 did on the falcon. I used to think why would it matter that the keyboard runs faster as its fast anyway. Though I am thinking these days, if it runs faster, the CPU can get data from them faster, and it frees up some bus time. So while the ACIAs probably will not show any speed boost, its possible the CPU may show a small sign of a speed boost some where. Its something I will try out soon. Though I am sceptical that it will show any difference in benchmark results.

I have buffered the 32mhz clock from the clock gen circuit on the motherboard, to a fast logic buffer, and as per Rodolphes suggestion, routed the buffered clock back to the shifter. This means cutting or breaking pin 2 off the shifter from the motherboard to allow the shifter to use the buffered clock. The 32mhz clock generated is pretty poor on the ST. Its barely capable of driving the shifter let alone anything else. So now the current hash up has a good stable 32mhz clock. Rodolphe is doing mods to the PCB to also buffer the 16mhz clock.

Though I have run into a problem with the HC CPU in relation to running at 32mhz. My initial testing was running 32mhz just on the CPU, and it seems happy to run at that speed. Though its now my current belief that the CPU cannot run for multiple cycles at 32mhz, in particular when accessing TOS. Normally the CPU runs fast for probably 4 cycles at a time when just using /AS to set faster speeds. Though when the CPU accesses TOS ROMs, the CPU spends a huge amount of cycles at 32mhz. Currently, TOS206 does not get as far as the Atari logo, but just gives 2 bombs, quickly followed by a row of bombs. I am assuming TOS is running some instructions, at least enough to generate the bombs, but does not run long enough to get as far as to bring up the Atari logo.

The GAL logic and ROM's are easily capable of running at 32mhz, and the entire thing works perfectly at 16mhz. So I can only conclude its a red herring that the HC CPU can operate at 32mhz. I think there was a "T28" booster at some point, running at 28mhz, so that is probably the max speed of the CPU. Though if that wasn't running fast-TOS then the CPU might only be able to sustain 24mhz.

So there are probably 3 possible ways to look at this now. Firstly, worst case, the CPU runs at 16mhz only. Second case is we let the CPU operate at 32mhz only based on /AS. This might not be stable for many hours of running, My machine was running Gembench for over a hour without any problems, but it does not mean it can run 32mhz for endless hours. This really needs to be tested out...

The 3rd case, is, this is still only using the older Motorola DIP 68000 CPU. I am assuming the PLCC CPU is a newer mask of the DIP 68000, though there does not seem to be any clues about this from my searching around. Motorola changed name to Freescale, So I have purchased the Freescale stamped CPUs and assume they are a newer production run, and hope its a newer mask which can operate faster than the older DIP Motorola CPU's.

It's possible there may be some other problem as to why the CPU will not operate at 32mhz with the ROMs, but I've spent 2 days looking at this, and I cannot really find any problem anywhere. Considering it runs at 16mhz fine, and GAL/ROM can easily operate over 32mhz, I can only really conclude the CPU cannot run constantly at 32mhz. People around the net claim 40-60mhz Though they do not exactly state what CPU you are using, I assume DIP Motrola 68HC000. Though I am also thinking maybe their testing is flawed.

The PLCC CPU's have not arrived, yet, hopefully they will turn up before xmas, and if I can find a 68000 PLCC to DIP adapter then I can at least try it on my current setup. My concern is I do not want to put the V2 PCB's into production if there is a possible problem somewhere. So my main focus now is to try the PLCC CPU only based on using /AS for the 32mhz switch and soak test it for several hours.

I could really do with a hack for GemBench4 so it cycles all the tests constantly if anyone is good at hacking stuff..

exxos wrote: I think there was a "T28" booster at some point, running at 28mhz, so that is probably the max speed of the CPU. Though if that wasn't running fast-TOS then the CPU might only be able to sustain 24mhz.

AFAIK, the T-series by Jim Allen at Fast Technology had accelerator boards that ran at:

16mhz20mhz25mhz28mhz36mhz

I've got a T25mhz board that I used in my STacy before I installed the Pak 68/3.

Here's some pics of the 28 and 36mhz boards:

T28 accelerator.jpeg

T28_36.jpeg

HTHs.

You do not have the required permissions to view the files attached to this post.