STE BOOSTER POWERED BY ALTERA TEST

[exxos]

IMG_1700.JPG (477.07 KiB) Viewed 10343 times

Finally got the STE booster powered by a Altera chip! For those not keeping up, I have moved away from "Coding" PLD's to drawing circuits instead. The Altera IC is a copy of my STE booster design (which uses a 22V10 GAL) only the GAL was coded, the Altera is "drawn".

My first attempt failed..

IMG_1697.JPG (194.78 KiB) Viewed 10343 times

IMG_1698.JPG (402.96 KiB) Viewed 10343 times

Though things were not as they appeared to be.

This is again a problem relating to parity simms. Foolish me, I grabbed a set "close to hand" as I had been testing simms in that particualr STE, so wasn't any in it. I managed to boot at 16MHz, though I had a read error on my floppy drive. I was moving it about and the STE started running perfectly. Odd! Incidentally, the same simms work fine on a stock 8mhz setup.

Turns out the 16MHz wire when going near the simms caused it to go into melt down. In fact even 2 inches away was enough to cause issues. Removing the parity simms for my own simms and there was no issuses, regardless of where the 16MHz wire was!

A video of it failing can be found on my chan here

I had to make some small circuit changes as well with the booster logic. Oddly the same changes in the Atmel PLD caused slow downs. Though in the Altera it just went from being stable to very unstable. GB6 benchmarks matched what I had on my site as test speeds using the original GAL logic so everything is running perfectly as it should now

Another odd side-effect was I had to put a small SMT buffer on the STE booster PCB to clean up the GAL's output. Now with the Altera , the signal was actually better without the SMT buffer! In fact I even took out the 56R resistor I had to the CPU clock.

Overall, so far, its a big thumbs up for Altera. Things so far work a lot better. It also proves I have got the hang of Altera's design software

Next up "to do", is to move to the 3.3V core version. The 5V one is basically obsolete now, but the 3V core still seems to be in production. This basically means the whole IC runs on 3.3V, but it can accept 5V inputs. This will make it really easy to interface to 3.3V SRAM and other stuff needing 3.3V.

After looking at the Altera devices, the 7000 series become really expensive for a larger IO device. Looking some more, the MAX II series seem to be a reasonable price and offer good IO interfacing.

Capture.PNG (85.67 KiB) Viewed 10343 times

It's only available in TQFN100 type packages, so a PCB will have to be done to test it out driving ROM and SRAM.


..wrap..

[exxos]

I had a few moments free tonight so I thought to remove the BG, BGACK, BR lines from the "condition" logic. Normally I run the CPU at 8mhz if any of those lines are low. Though for some odd reason I had to do that on the STFM. Oddly on the STE, at least so far, it doesn't seem to care about those signals.

[keli]

First of all, excuse me if this has been discussed before, but I have a few questions about speed throttling and the asynchronous nature of the 68000 bus.

I notice that all of your boosters (and most other solutions I've seen floating around on the net*) work by lowering the CPU clock frequency when accessing slower hardware, ie. RAM and memory mapped IO.

That made me think a bit. The 68000 bus is supposed to be asynchronous (apart from the 6800 peripheral control features... back to that later**). But I see there is a timing issue .

Slow devices can insert wait cycles by delaying /DTACK. If /DTACK is low, the 68000 will assume the data are ready already in STATE 7 (which is the second half of the fourth clock cycle). If /DTACK is asserted any later, the read will happen on the next clock. This is of all good and dandy at 8Mhz. Fast devices can even assert /DTACK much earlier than at STATE 5, as the CPU will not touch the data until in STATE 7. (Simplified hobbyist 68000 designs even could get away by hardwiring /DTACK to GND if all devices were least as fast as the CPU.)

The problem comes when the CPU is running faster than whatever is generating /DTACK is assuming. At 16MHz, the CPU's STATE 7 arrives when at the original speed we would be half way through STATE 4. Also even if /DTACK is asserted a late as possible to avoid wait states in the original case (STATE 5), the CPU would attempt to read the data half a clock cycle too early, or in 8Mhz STATE 6.

So at this point, wouldn't delaying /DTACK (and possibly /BERR) until one CPU clock cycle before the data are available instead of slowing the CPU down?

I'm not sure if this would make any difference performance wise, as the CPU will be waiting for the data in both cases, but depending on how fast you can switch the clock frequency, you might gain half a clock cycle... or not.

*) It seems that the AT-Speed accelerator sold commercially back in the day employed a solution similar to what I suggest instead of the speed bump solution.
**) Back to the 6800 bus -- The /VPA signal indicates to the CPU that is should switch to a 6800 peripheral cycle, which means that the E pin will act as a clock for the peripheral device. The E pin is clocked at CPU clock / 10. Some of the devices may actually be able to handle speeds up to 1Mhz, so a CPU clocked at 10Mhz may not need any changes. Higher speeds would probably require the CPU to be throttled down to 8-10Mhz when /VPA goes low.

[exxos]

The 68000 is a async device and actually runs that way in the ST. The problem is DTACK can arrive at a random point. It can arrive at S1, S4, S10, or whatever. When the CPU is clocked at 8mhz, DTACK arriving early doesn't matter, the CPU will "see" it at S4 or there abouts and terminate the cycle. When DTACK arrives later, the CPU just sits waiting for DTACK and completes the cycle after.

Problem is, if you now run the CPU on its own clock, even 8mhz, it will still mess up with when it "sees" DTACK. So the CPU could read DTACK at in effect S3 or S5.. Basically just doesn't work.

You can re-sync DTACK (I have wrote volumes on my this on my site recently) so the CPU only sees DTACK on the 8mhz S4 state. Though the CPU was probably sat waiting for DTACK for along time already. If you check the Amiga LUCAS document, they do exactly that. Though its a lot more complicated on the ST.

For the 68000, again I wrote epics on the VPA stuff, I gave up in the end. But you have no choice but to slow the CPU down during VPA cycles. Technically the ACIA can run a lot faster, where the CPU clock is about 20mhz. So 2mhz about maxes out the ACIA.

In anycase, while you can run the CPU at 16mhz, 20mhz, or whatever, all the time, you have to slow down all the other signals like DTACK etc. But I found its not so simple and you can actually make the system slower if you read DTACK to late. Though when people run the 030 for example, they dont generally offer a 8mhz mode, so they never see they are actually reading DTACK in the wrong place. I wrote some about that also.

So for the 68000, there really is no point in slowing down all the signals like DTACK and re-syncing when you can just slow down the CPU clock, and everything is 100% compatible with timings. You can also easily switch back to 8mhz mode.

The only advantage of syncing is you can run the CPU on its own clock, though as I found on the 68HC000 it maxes out at 38mhz anyway, so using the 32mhz clock works out well.

The 020 is more complicated as it uses 3 states not 4, so some resyncing is needed, as from what I have seen, without the cache on, the system on 8mhz actually runs slow, like RAM at 95% because of resync issues. There could also be issues with RAM access so I have been told, due to how the 020 and 030 works.. but the problem with sync is still there either way.



Above the 020 running 8mhz, cache on and cache off. You can see its not syncing correctly and gives 95% RAM speed. Int-div is lot more efficient on the 020, so huge gain there.

With the cache on, it covers up the sync issues. This is why I did not re-use anyone else's designs or code because it needs a lot more work to fix the issues. This is why it takes me so long to "re-produce" things like the 020 boosters , because I am working from the "ground up" and diagnosing and testing everything myself.

All the boosters I see sync to the 8mhz clock, but that isn't actually correct, DTACK should be read in "mid point" in the 8mhz clock (high or low, I forget) because you "miss" the proper time the CPU should be latching the data. I did my async code to use the 8mhz clock (falling edge) then one or 2 CPU clock cycles( say 20mhz or so) to get the correct timings. Others would sync to maybe the rising edge of the clock which is some 100ns later, and you actually delay DTACK and it results in the 95% RAM speed. If you latched earlier on the 8mhz cycle then you are to early, in effect RAM speed would be 105% and you get corrupted data. Again I documented this on my site.

So it really depends on what you want to do, and how accurate you want things to be. For the 020, it can probably run 50mhz, its a 3 clock bus cycle, so you have no choice but to sync signals. Though so far, I have not seen any design which I was happy with.

For me, I mostly work on the 68000 anyway, running async is pointless, just downclock the CPU and save huge headaches.

The exception for this is the 68SEC000 which wires up more like a 020, I hope one day to test this CPU and gain more raw MHz power from the 68000 core. Currently, I am maxed out at 32MHz on the STE. The SEC CPU should do 50mhz.. but will then need sync code, which I have written and tested, but no time lately to atually try the SEC CPU.

The bulk of my work is documented on my site in more detail.
http://www.exxosforum.co.uk/atari/last/16mhz/index.htm

[Icky]

Hi Exxos. You mention different types of 68000 and maxing out at 38MHz and never being able to hit that magic 40Mhz. I noticed that there are various types of the clocked versions such as the MC68HC000FN20 which has a 20MHz clock. I have one of these in my MegaSTE which runs fine but does this type of chip lend itself towards the magic 40MHz.

[exxos]

Hi Exxos. You mention different types of 68000 and maxing out at 38MHz and never being able to hit that magic 40Mhz. I noticed that there are various types of the clocked versions such as the MC68HC000FN20 which has a 20MHz clock. I have one of these in my MegaSTE which runs fine but does this type of chip lend itself towards the magic 40MHz.

68000 maxes out at about 24Mhz, 68HC000 maxes out at 38MHz.

I want to move to the 68SEC000 where Amiga people claim 50-80MHz is possible, but its not a straight swap. It wires up like a 020. Not difficult to do, but with myself working on multiple projects, it's on the "to do list" to try out.

Once I have finished the new ST FM booster and happy it is all working at 32 MHz, then doing a new design this CPU should be pretty simple. I am still undecided which IC to use, though for the moment the boosters will continue to use the Atmel I think.

The problems come into effect when I need to interface to 3.3 V devices. In which case, the Altera will allow me to interface both voltage levels easily. Though this device does get rather expensive in larger pin counts.

[Icky]

I hear you about all these multiple projects and so little time to do things in. We all have day jobs etc and having a passion to solve problems in the Atari ST space is admirable. I like your mantra of keeping things simple and looking at the 68SEC000 instead of opening more cans of worms with other 020 / 030 type of boosters.

[exxos]

I hear you about all these multiple projects and so little time to do things in. We all have day jobs etc and having a passion to solve problems in the Atari ST space is admirable. I like your mantra of keeping things simple and looking at the 68SEC000 instead of opening more cans of worms with other 020 / 030 type of boosters.

Yes you are exactly right, you only have to look at my website to see any problems I have had even with the just the basic CPU. It is better to debug all the issues on a simple setup rather than over complicating it right from the start. Debugging issues is a nightmare as I am constantly fighting noise on countless signals on the motherboard. This is ultimately why I decided to start remaking the motherboard.

There is also the fact that I want to keep maximum compatibility with software, which is why I want to max out the 68000 as much as possible first. Of course there becomes a point where access to ROM is going to need wait states, so there is a point of diminishing returns with higher speeds.

The 030 is of course a really good CPU, more efficient core, and data and instruction caches, and can even access 32 bit. But of course this will break some compatibility, but that is the price you pay for a faster machine.

Though like I said ultimately, the SEC CPU wires up like a 020 anyway, so the 020 is almost a direct replacement, other than the pinout etc. The 030 isnt much different really either. Will just have to see how things work out's go along...

A lot of other people are working on accelerators also, so I think there will be a little boom of them may be a year or two's time anyway. So I am no rush to start working with these CPUs.