exxos's Atari, Amiga & retro forum

This is some very crappy cam footage and afraid.. I was trying to get the camera to stay upright to show me changing the GAL but it kept falling over.. I did not have any time to do a better video because the battery was running out and frankly I couldn't be bothered :lol:

Point being, you can see the GAL has been changed, the one with a white sticker on this showing the problem GAL. The one without the sticker, is the one out of my test board. That GAL will run all day and the machine will not crash.. And yet stick some other GAL in, and it barely gets past the Atari logo.

I spent two weeks on this last year to trying figure out the reason why. It has nothing to do with the speed of the GAL, all the rise and fall times look exactly the same between a working and nonworking GAL. I pretty much cannot find any noticeable difference between the two.

While I have been using dubious sources of the GAL22V10... I also tried the ATF22V10 As they are still in production, but if I remember rightly I had even more trouble with those. The original batch of GAL's in the original V1's sold a few years back, all works perfectly fine. I really don't know why. But batches of GAL's I bought last year, basically saw something like 1 in 20 working. With them costing a minimum of £2 each.. thats £40 worth of chips and £40 ontop of the booster price.

So while I have 50 of these boosters built, and I regularly get people asking me "when will it be available".. They will be available when I find some GAL's which work.. which in about two years so far I have been unsuccessful in doing.

I will however spend the next couple of days investigating this issue again...But I am really not sure what else I can do which I have not already tried..

I have been scoping out the 8MHz as things normally circulate around that. So far the "problem GAL" tries to boot but only when there is 50pF on the 8MHz clock. Now that in itself is a problem I had from the STFM's.. In that as soon as there is " less load" on the 8MHz line, it gets really noisy and starts to malfunction. A capacitor normally solves this but I want to look into this deeper (Again) and documented better...

What I am currently looking at is the rise and fall time, and the undershoot...

Firstly the original 8MHz..

Next is with 50pf (boots)

Next 220R .

Now investigating with a diode clamp.. I could only find a 4148.. not good enough.. and only a slight variation from the original image...

I tried a schottky diode, My those things must have a couple of farad capacitance on them!! :lol: Oddly the machine booted like that..

This one just had a pull-up resistor of 1K to 5V and it booted again...

220R pull up.. no boot just garbage on screen. It is important to look at the "DC offset" here rather than the waveform itself..

440R pull up and machine boots again..

So at this point, I do not believe it is a rise or fall time issue, or a "sync" issue as that doesn't really change without a capacitive load. So so why not put a buffer on it to clean it up ? well that would clean it up, it does not resolve the loading issue "ST side". it would still need a capacitor or something there anyway. Actually had a epic of this on the STFM boosters as well years ago.


This next one is with a 50pF load ST side, then in series with 220R.. machine boots.

Same as above but with 440R. boots.

A lot more images added in the above post.This is all the drama I had to go through with the "plug in" STE boosters as well.

While it gets to desktop with this particular GAL.. it does not mean it its stable ( will test it out more thoroughly tomorrow).. But even so, changing the GAL means all these tests have to be done again normally. It is like you have to literally "tune" each GAL to each individual booster.. Again this is why it is so incredibly time-consuming to get these up and running.


Showing the diode clamp...


Showing what's going on with the e10.jpg in the previous post.


A nice crash screen...

Another nice crash screen..

A crash screen which is trying very hard to be pink! :thumbup:

I did a small tweak in the firmware and have run it about 15 loops now...

So I need to find some SMT resistors around 500R next.. and some caps.. now I did order some caps a few weeks ago.. as to where they gone ... :roll:

I can remember the fun and games we had trying to get the 40Mhz STE booster I got from you to work. In the end we dropped it back to 32Mhz and switched the GAL out.

Mine was slightly different in that it would run stably at 40Mhz, but my CosmosEx wouldn't work stably with it until we dropped it to 32.

These things are difficult, though I have to say the very first one I had from you runs perfectly at 32Mhz and has never missed a beat.

@rubber_jonnie yeah 40mhz running was stable, but there was simply no way to sync properly to the bus on bus grant stuff ( a GAL just hasn't got enough logic to do it ) , hence the DMA screwed up. But the speed itself wasn't the problem. On the 32MHz stuff, it switches to 8MHz on any bus access ( excluding ROM) so it acted like a stock system then.

Aside from that, the plugin idea was causing to many problems, iffy connections, different sockets etc. It would need a total redesign to get 40mhz working. Its just not worth the time and cost for the sake of a few MHz. I would need to do 3 versions to fit the 3 socket brands I know of. Considering is maybe only sell 5 a year.. I'd never get even close to getting my money back producing multiple versions.

If anything, the SEC booster would be the way to go. But I barley have more than a few days a year to work on it :( maybe next year I may ask @Icky if he wants to do the STE PCB for it.

I left it on all night, looking good :)

Will start testing out some CPU's today.


EDIT: Just passed LOOP 220.. Has been going a good 12+ hours now..

exxos wrote: 30 Apr 2020 09:32 @rubber_jonnie yeah 40mhz running was stable, but there was simply no way to sync properly to the bus on bus grant stuff ( a GAL just hasn't got enough logic to do it ) , hence the DMA screwed up. But the speed itself wasn't the problem. On the 32MHz stuff, it switches to 8MHz on any bus access ( excluding ROM) so it acted like a stock system then.

Aside from that, the plugin idea was causing to many problems, iffy connections, different sockets etc. It would need a total redesign to get 40mhz working. Its just not worth the time and cost for the sake of a few MHz. I would need to do 3 versions to fit the 3 socket brands I know of. Considering is maybe only sell 5 a year.. I'd never get even close to getting my money back producing multiple versions.

If anything, the SEC booster would be the way to go. But I barley have more than a few days a year to work on it :( maybe next year I may ask @Icky if he wants to do the STE PCB for it.

@exxos Completely agree, the extra 8Mhz just isn't worth the time and effort to cover all bases.

If I can help in any SEC booster testing, I am definitely up for it.

rubber_jonnie wrote: 30 Apr 2020 10:25 @exxos Completely agree, the extra 8Mhz just isn't worth the time and effort to cover all bases.

If I can help in any SEC booster testing, I am definitely up for it.

:thumbup: I've not tested ultrasatan, but this is basically the original design now anyway, so it should not really need any further testing.

I'm going to try my best to try and get a couple these in my store over the next few days as I am not going to be at home next week so be able to do any Atari work.

A thought just popped in my head...In that people criticise such boosters because it does not speed up ST-RAM.. which is long story short near impossible anyway.. BUT.. Consider this...

The CPU does some cycles like this

>RAM ACCESS< >RAM ACCESS< >INTEGER DIVISION< >RAM ACCESS< >RAM ACCESS<

For arguments sake, let's just assume the RAM access takes a fixed 2 cycles every time and the integer division takes 200 cycles..

So the analogy above then becomes...

2-2-200-2-2 cycles.

Now if we increase the CPU speed to 32MHz (8MHz x4)

While the CPU has to emulate the 8 MHz cycles for the RAM access we are just going to still call them 2 cycles.. But now as the CPU is running four times faster, 200 / 4 = 50 cycles...

So the new timing then becomes..

2-2-50-2-2 cycles.

No doubt some people would still complain about this ;) because this is basically very specific scenario which again generally only happens with 3D games like frontier which use a lot of integer divisions. A similar thing can also happen with ROM access no doubt.

So while this analogy does not increase ST-RAM speed per-se, the "available bandwidth" to RAM is somewhat increased because after the integer division we get to the next ram access a lot sooner.