4MB Upgrade & 16MHz Booster progress

[Ragstaff]

[smilie=greencolorz4_pdt_01.gif] There is of course Rodolphe who is heavily involved with all the boosters of late also

Yes, sorry Rodolphe It's generally an unexpectedly good time in the life of the ST as far as hardware support goes

It kinda reminds me of the "FPU" type discussions a while back. While the FPU is fantastic at math stuff, there is almost nothing which uses it. Similar with the DSP, it could may well be possible to add it. Though if the DSP is used for audio stuff, then it needs access to a DAC, so probably better suited on the STE maybe.

Yeah, I understand, the key thing is whether any existing software can benefit. So I was just speculating if any Falcon software that runs in ST video modes could run on an ST with a fast CPU, if it found the DSP present. A bit of conjecture really. I think it would only be worthwhile putting a DSP on an ST upgrade if the answer to that question was "yes". There's no way people would (or should) start writing new ST software that takes advantage of a DSP or FPU... it would only be there to try and boost the ST into (a small part of) Falcon territory.

One good thing about the upcomming V3 series, is the addon port, so if anyone wants to develop a DSP addon or any other addon, then they are free to do a card for it and simply plug it into the V3 expansion port.

Great to see! As the Amazon philosophy goes, it's one thing to make a cool product, but the next step is to make it a platform and let others take it forward....

[exxos]

Yeah, I understand, the key thing is whether any existing software can benefit. So I was just speculating if any Falcon software that runs in ST video modes could run on an ST with a fast CPU, if it found the DSP present. A bit of conjecture really. I think it would only be worthwhile putting a DSP on an ST upgrade if the answer to that question was "yes". There's no way people would (or should) start writing new ST software that takes advantage of a DSP or FPU... it would only be there to try and boost the ST into (a small part of) Falcon territory.

I want to design a kit to play MP3's on the ST. Kind like a SD card with music and sound effects on, then software can control the MP3 "player" and use proper CD quality sound in games. I was on about it in relation to AtariZoll talking about STE sound stuff a few months back. It would be a awesome kit to have and sound is what lets down the ST. But while it could be done, probably less than 5 will ever sell, and someone would have to patch games to use it. Then someone will have to maintain the "sound packs". It just would't be worth the trouble.

One good thing about the upcoming V3 series, is the addon port, so if anyone wants to develop a DSP addon or any other addon, then they are free to do a card for it and simply plug it into the V3 expansion port.

Great to see! As the Amazon philosophy goes, it's one thing to make a cool product, but the next step is to make it a platform and let others take it forward....

Exactly, it costing way to much to keep developing a new booster every few months. Considering they hardly ever sell, its doing nothing but sink me into dept. Once the V3 is done, that will be the final design. Then any addons can be done by anyone and I don't have to get another booster PCB designed and manufactured.


Back to the plot...
As a side note, the V2 boosters will be produced next year. They are the next step in boosters. Similar to the V1.5 booster, only all on one PCB and its a fraction faster as TOS decoding is done on the board. This one offers TOS104/TOS206 on board at 16mhz like the V1.5 booster. The cost of these boosters is really starting to mount up. "all on one" PCB is expensive, the V2 had to be done on 6 layers to get it to fit in the space restraints of the STFM. It will be a big price jump from the V1.5 design which is a smaller 2 layer PCB. More on that at a later time though anyway..

There is some images on my site of the V2 http://www.exxoshost.co.uk/atari/last/1 ... dex.htm#V2

[GadgetUK164]

The v2 looks awesome!!! Have you thought about doing a FPU board at all? Something that could be soldered inline with pins going into the 68000 socket, that way adding a 65881/2 would be possible. I know not much uses it but I am on a crusade to add one into mine one way or another =D I've seen schematics for whats required, I might have a go at creating a board soon.

[exxos]

The v2 looks awesome!!! Have you thought about doing a FPU board at all? Something that could be soldered inline with pins going into the 68000 socket, that way adding a 65881/2 would be possible. I know not much uses it but I am on a crusade to add one into mine one way or another =D I've seen schematics for whats required, I might have a go at creating a board soon.

There seems to be some odd stuff relating to FPU on the 68000. The CPU doesn't support it, so its like its a "hack" to get it to work at all. Then software has to be written to make use of it. So I don't think a FPU is going to be of any use on a 68000 system. Its not until you get to the 68030 where its worth adding one. Even so, There isn't much software which make use of it.

[exxos]

dev1.jpg

No news here for a long time. Though its almost time to start work again

V3 prototype installed. Programmer sees the board which is a good start

Next is to get it working as a stock 68000 machine, then start adding in code for 32mhz switching and most likely waitstates on the PLCC ROM.

Once I am happy its stable, then going to work on breaking the 32mhz barrier

[exxos]

... and so it begins.... or not , hence the LA

v31.jpg

[GadgetUK164]

Wow, nice update! Looking sweet! A nightmare to debug I imagine!

[exxos]

Wow, nice update! Looking sweet! A nightmare to debug I imagine!

Yeah, it doesn't help as my new LA seems to be faulty from new So work is held up again while I send it back

[GadgetUK164]

Out of interest, have you tested to see how fast these 68020 can go? I've just overclocked the one on the my Amiga accelerator up to 32Mhz (from 27Mhz that I've used it at for a few years), and it's rock solid doesn't get very warm at all. The interesting thing is the chip is marked 16Mhz... It seems like these 020 chips can be pretty heavily overclocked.

[exxos]

Out of interest, have you tested to see how fast these 68020 can go? I've just overclocked the one on the my Amiga accelerator up to 32Mhz (from 27Mhz that I've used it at for a few years), and it's rock solid doesn't get very warm at all. The interesting thing is the chip is marked 16Mhz... It seems like these 020 chips can be pretty heavily overclocked.

Its not so simple as the ST will not run with a out of sync clock by default. I'm going to be working on this problem next week. I'm stuck at 32mhz simple because its the fastest system clock. I've seen Amiga guys claiming 50-70mhz on the 68000, so we shall see..

[GadgetUK164]

I think with the ST there comes a point of diminished returns anyway, ie. unless there's some really long number of cycle opcode, or unless its using ALT RAM, I guess there will be a limit to whats possible. I just found it amazing that a 16Mhz chip can run really well at 32Mhz. I wouldn't be surprised if it can go to 40Mhz with a good heat sink.

[soviet9922]

About that MP3 player idea, maybe this can be used on the ST developing a player of course.
http://amigakit.leamancomputing.com/cat ... ts_id=1078

Yeah, I understand, the key thing is whether any existing software can benefit. So I was just speculating if any Falcon software that runs in ST video modes could run on an ST with a fast CPU, if it found the DSP present. A bit of conjecture really. I think it would only be worthwhile putting a DSP on an ST upgrade if the answer to that question was "yes". There's no way people would (or should) start writing new ST software that takes advantage of a DSP or FPU... it would only be there to try and boost the ST into (a small part of) Falcon territory.

I want to design a kit to play MP3's on the ST. Kind like a SD card with music and sound effects on, then software can control the MP3 "player" and use proper CD quality sound in games. I was on about it in relation to AtariZoll talking about STE sound stuff a few months back. It would be a awesome kit to have and sound is what lets down the ST. But while it could be done, probably less than 5 will ever sell, and someone would have to patch games to use it. Then someone will have to maintain the "sound packs". It just would't be worth the trouble.

One good thing about the upcoming V3 series, is the addon port, so if anyone wants to develop a DSP addon or any other addon, then they are free to do a card for it and simply plug it into the V3 expansion port.

Great to see! As the Amazon philosophy goes, it's one thing to make a cool product, but the next step is to make it a platform and let others take it forward....

Exactly, it costing way to much to keep developing a new booster every few months. Considering they hardly ever sell, its doing nothing but sink me into dept. Once the V3 is done, that will be the final design. Then any addons can be done by anyone and I don't have to get another booster PCB designed and manufactured.


Back to the plot...
As a side note, the V2 boosters will be produced next year. They are the next step in boosters. Similar to the V1.5 booster, only all on one PCB and its a fraction faster as TOS decoding is done on the board. This one offers TOS104/TOS206 on board at 16mhz like the V1.5 booster. The cost of these boosters is really starting to mount up. "all on one" PCB is expensive, the V2 had to be done on 6 layers to get it to fit in the space restraints of the STFM. It will be a big price jump from the V1.5 design which is a smaller 2 layer PCB. More on that at a later time though anyway..

There is some images on my site of the V2 http://www.exxoshost.co.uk/atari/last/1 ... dex.htm#V2

[exxos]

About that MP3 player idea, maybe this can be used on the ST developing a player of course.
http://amigakit.leamancomputing.com/cat ... ts_id=1078

Interesting! What I was thinking was putting it internally and hooking it into some RAM address to select and play files. Seems they used the parallel port, similar kind of idea though.

I think with the ST there comes a point of diminished returns anyway, ie. unless there's some really long number of cycle opcode, or unless its using ALT RAM, I guess there will be a limit to whats possible. I just found it amazing that a 16Mhz chip can run really well at 32Mhz. I wouldn't be surprised if it can go to 40Mhz with a good heat sink.

My results on 32mhz are a bit conflicting at the moment. The STFM doesn't like 32mhz so I had to slow it down a bit, so not much advantage. Though from past results, jumping from 16mhz to 32mhz still gave a good boost in speed. There is some huge list somewhere which lists instructions vs how many CPU cycles they take. Every mhz counts so far it seems!

After 32mhz it becomes a problem with speed of stuff. I'm running down to 20ns ROM's to keep up with 32mhz ROM access now. alt-ram be pusing to get 32mhz out of it aswell. So anything over 32mhz is likely going to be CPU only boost, like integer division which can be 100's of cycles long.

I'm still trying to break past the 32mhz barrier, basically need to run out of sync CPU clock which is proving to be near impossible. Though even if it is possible, likely ROM & RAM will have waitstates. So in effect still 32mhz. The CPU may take 50mhz, though im not sure what gains there will be vs 32mhz.

[exxos]

Some small progress today. Using a 16mhz external oscillator I get bombs. Yesterday TOS wasn't even trying to boot. So while bombs is bad, its actually good as it shows at least that TOS is trying to boot up, but crashes at some point later.

I haven't had much time to debug why my dev-board using the ATF chip refuses to work yet. My new logic analyser was faulty, so I had to return it. So its holding up progress So I had to build a quick bodge up to do some testing.

161.jpg

162.JPG

[exxos]

As I keep being asked about STE boosters I have 2 in development.

V1 STE - 32mhz capable simple booster with 32mhz Fast-TOS & CPU. This has been sent off for a couple of prototypes so hopefully they should be avalaible in the near future.

V2 STE - 32mhz CPU & TOS with IDE and Fast-Ram @ 32mhz.

More info on my site.
http://www.exxoshost.co.uk/atari/last/1 ... m#MAY22016

Thanks to everyone who has been making purchases lately. As promised, sales results in more hardware development

[GadgetUK164]

Thanks for the update =D Will check out the links!

[guus.assmann]

Hello,

After quite a lot of work, I'm now trying to get a Mega ST board to work on 16Mhz.
What's not clear:
I think it should be possible to reconnect just the DE and 2Mhz clock, with the rest of the board "as is"
So I disconected the trace from the glue and shifter to the MMU.
And I put this into an 74AS00. Input from GLUE and Shifter to NAND and output to MMU, also inserted 2Mhz clock)
But I'm not sure this is correct, input and output wise that is.
If I remove the 74AS00 from the socket and bridge the in/out, my MegaST boots ok.

What I've done so far, that works ok on two boards:
Upgrade to 4MB with 60Ns Ram's. (SMD on one board and module on the next, they were MegaST 1)
Replaced 74LS244 and 74LS373 by F types. (In socket)
Put CPU in socket and replaced with 16Mhz one.
Put floppy controller in a socket, so it will be possible to make the 1.44Mb patch.
Replaced all IMP chips (not DMA yet) with other manufactures.
Got socketed Tos 1.04 Roms.
Replaced the pulls ups by 3k3 ones. (or put 10K in paralell with 4K7 and vice versa)
Put a 1k in parallel to R4, to modify reset.

Can someone please tell me what's in and out regarding the DE line on MMU, Glue and Shifter.

BR/
Guus Assmann

[troed]

Can someone please tell me what's in and out regarding the DE line on MMU, Glue and Shifter.

My take:

Glue outputs DE to MMU and Shifter. For 16Mhz you should only need to "halve" the output to MMU, to Shifter it should connect as before.

I think. We did discuss this a lot previously in the thread.

/Troed

[exxos]

It all started way back here in 2014 http://atari-forum.com/viewtopic.php?f= ... 75#p264418

Problem after getting it working was it wasn't stable, where I ultimately found the clocks were just to slow (long rise times) so it was actually "skipping" a 8mhz cycle that the GLUE saw and causing the 16pixel shift in the display as arne saw.

One reason I built the dev-board as it has lots of io's , so it could run any code along with run the clocks all via the PLD for buffering. But later I thought it would involve a lot of track cutting on the motherboard to replace the clocks, or possible the MMU could be removed and a buffer board put there instead. Problem then is the 32mhz line also needs buffering, so the MEGA buffer would be better as it buffers the 32mhz and 16mhz lines on the shifter. But then its back to removing the MMU or lots of track cutting again.

The 4MB MMU RAM upgrade was created in part in preparation to this upgrade. Though Its got somewhat complicated to install which is why i stopped working on it. You might get lucky and it may work to some degree. Though the clocks need buffering which is the next step. Its not something I have had time to try yet.

[exxos]

I've seen too many systems being too complicated and therefore too faulty.

Arne, is your machine still working with that mod ? It would be interesting to see what the GB6 results are with it as it may show more realistic speeds than previous versions.

If I ever get time, I will see if I can resurrect my machine and add the buffering to see if it makes it more stable.

[exxos]

Just a small update here, this project isn't dead and I am still working hard into booster stuff. I just do not update the forum with step by step progress anymore and it takes up to much time.

The old page is here which covers work up until the end of last year.
http://www.exxoshost.co.uk/atari/last/16mhz/index.htm

This years work is covered on page 2
http://www.exxoshost.co.uk/atari/last/16mhz/index2.htm

Basically the round up is I have the CPU running ASYNC finally and had it running at 25MHz. I couldn't go any higher (didn't have anymore osc's to hand) but the CPU E-clock running faster causes the ACIA to screw up. After a lot of work, I gave up and decided to do a new test board using the 68SEC000.

This CPU needs a little more "work" as some signals are missing, but the good news is that its almost wired up the same as the 020 CPU. This makes it a little easier to adapt the CPU as there is actually working code examples and also it is possible it wouldn't be much more work to move to the 020.

Now people people get twitchy, The 68SEC000 is still a 68000 core, its just more like a EC version, so some pins are missing, but the same pins are missing on the 020 and get emulated.

According to what I read on the Amiga threads, they claim 50-100MHz is possible with the SEC CPU. If that is true or not, not idea. Though I think the SEC is likely a later production run over the 68HC000 so it should overclock better. We shall see.

I need to look at ROM's again as I am using 55ns ROMs which are about as fast as I could find in 5V, but that struggles to keep up with 32MHz speeds. So if I can find a faster ROM, then higher ROM speeds can be done, otherwise , regardless of CPU speed, the effective ROM speed might be maxed out at about 40MHz. I'd rather not get into adding waitsates for stuff, but this depends on what parts are obtainable. I think someone did suggest some microchip ROM's last year, but can't remember who or what.

SRAM is also hard to find in 5V types. I think I used some 2MB devices and used 5 of them on my board for 10MB. Those were 45ns so again its going to start maxing out somewhere around 40MHz.

Likely I will look into 3.3V buffer chips again, I did look last year and did half plan what I wanted to use. I think 3.3V world may give me a few more options with ROM and SRAM.. though work for another day..

I have designed a fast-ram board which will work at 32MHz easily. Though with me working on the CPU issues, the fast-ram will have to wait. Also similar with the IDE, I've designed a new IDE circuit myself which conforms to proper IDE timing spec, so all those odd stability/write issues with various interfaces should hopefully be no more. Again while I have designed it and simulated it, no time to build and test it yet.

I am also aware people want various features, like flash ROM and the ability to switch the booster on/off in software. What I am thinking is having TOS206 as default (or first block) and then a user programmed block which can be written with EMUTOS or whatever.

If EMUTOS builds don't use the full flash area (assume there will be a few bytes free at the end of the ROM free) then I will likely use that as a booster register to store settings, such as the boot rom block choice and booster on/off etc.

Please don't ask me "when will this be valuable" as I produce so many kits now my time working on the booster stuff is getting down to just a few days a year currently. I have people waiting for 3+ months for the Falcon PSU's and I have a few Falcons coming in for repair soon as well. So I likely won't have time to work on boosters for 2 or 3 months. Progress is posted as it happens on my site, currently I am working on the new 68SEC000 PCB layout which is almost finished.

Though if anyone wants to save me some work, have a look into ROM and SRAM, see what's available speed and size wise, of course they need to be low cost. 45ns or better, and 16bit. Ideally 5V, but 3.3V could be a option. The best IC is something 16bit with 4MB or more RAM, less IC's is less soldering, less PCB routing and keeps costs down etc. With space in the ST's case being so limited, getting it all to fit is a huge battle. So less IC's means more chance of it being possible to fit in the original case.

[mrbombermillzy]

I was struggling with getting some high speed ram for a project on a Commodore machine a while ago.

Depending on how many boards you need to make, you might find getting hold of some old 386/486 cache RAM may do the trick, although it might need a fair few IC's to make up to 8Mb or whatever.

Watch out too, as many mobos were fitted with fake cache ram chips.

[exxos]

Someone else did suggest that also. I think it would be a bad idea to try and use caches from stuff which can't be replaced. I mean SRAM should be around for a while yet, FPGA there likely always will be alternatives.. Mostly it would be better to use the 030 , but seems a bit of a waste of a CPU just for that.

fast-ram (alt-ram) is a more reliable method, though no clue if games run in alt-ram. Not something I have looked into. Though speeding up the MMU is possible and double clocking the RAM which would give a constant boost over the whole RAM area, not just 8K routines here and there running faster. While the cache RAM might run faster in the 030 clocked at 50MHz or whatever, I think compatibility wise and speed wise, double clocking ST-RAM would be a better solution, at least for legacy software and games.

I did half wonder what the max overclock of the MMU would be, Will try and test this when I get time. Might even be possible to add a burst mode to the MMU to clock even higher during CPU transfers, but not sure on this because of the shifter timings.

Rodolphe says at some point he will look through the MMU code from suska, see what the MMU is actually doing and what is "missing" pin wise. I don't really see the MMU as actually doing very much. Assume most of its logic is refreshing the DRAM, which wouldn't be needed with a SRAM based design. I might Email wolfgang see what he says about it....

[ijor]

Rodolphe says at some point he will look through the MMU code from suska, see what the MMU is actually doing and what is "missing" pin wise. I don't really see the MMU as actually doing very much. Assume most of its logic is refreshing the DRAM, which wouldn't be needed with a SRAM based design. I might Email wolfgang see what he says about it....

I mostly completed MMU reverse engineering since our email exchange months ago.

Basically MMU controls the RAM and the connection between RAM, SHIFTER and the main CPU bus. RAM refresh is a rather small part of MMU. I'd say that the main MMU task is handling the different time slots for RAM access. There is a giant mux for addressing the RAM depending on the current cycle, the memory configuration, and the current value of the corresponding counter or the address at the CPU address bus. It also, obviously, controls the 4 TTL buffers that separate the RAM from the main cpu bus.

Several hardware registers and counters that are described as being part of other chips, live actually inside MMU. They are all address registers used to access RAM. It also controls SHIFTER and produces the main 8 MHz, and the 4 MHz clocks.

[joska]

fast-ram (alt-ram) is a more reliable method, though no clue if games run in alt-ram.

They typicall will not, with the exception of games that are using GEM.

However - is this a problem? No demos will work with any sort of acceleration. Most games will only suffer. A few will work better. I don't think many people will install an accelerator just to play games, especially not if it's not possible to switch back to 100% compatible stock mode which is required by most recent demo productions.

I would assume that if you're in the market for an accelerator for an ST(E), you probably want to compile faster or have a smoother experience when using GEM apps. And maybe use MagiC or MiNT to multitask apps. And then you never can have too much RAM.