Thursday, 31 August 2017


PeST is the acronym for PS2 Enumerator for the Atari ST.

It enables any PS2 mouse to be used with the Atari ST / STF / STFM / STE / Mega / Mega STE / TT / Falcon etc. PeST is completely automatic and fully plug and play. No drivers required.

A clever unique internal software design allows 4 speed options to be selected for up to 4 times faster than any regular Atari mouse.

PeST was originally produced in 2005-2010 and was discontinued in 2012 due to lack of demand. However after a recent poll, a lot of people expressed interest in a new production run of these. So I have started to make up a limit number of PeST's which will be on sale in my store in due time.


Monday, 21 August 2017


After much consideration for almost 2 years now, I have opened up my own forum.

This forum is for current hardware developments of mine (but can include 3rd party stuff also) and to offer support for my products.  There will also be general hardware fixes and tweaks and repair guides among other things.

I decided to open this forum as my blog was a bit to limited to do what I want.  My website holds a lot of information, but didn't really fit to a blog of daily or weekly announcements or activities. A lot of my blog posts just become "lost" over time with no real way to organise or find posts. I feel a lot of good information is just being pushed out of existence! A forum would allow me to do much more and fill in the gaps for support between my blog and website.

Other groups and forums I may use have just become to much trouble to keep track of things. People are making repeat suggestions all over the place and I can't keep up with it. Not only that, people are just repeating the same things over and over which just becomes annoying after a while. So if people have suggestions for something like the STFM remake project, then post on my forum!

There is also the countless emails I get each week, where basically I am just repeating myself on the same subjects over and over.  Mostly such people try to get help on forums, then give up and email me directly for help.

Overall, a new support portal is needed to centralise all my work and offer support to people. This way, rather than repeating myself to various people on various topics, people will be directed to my forum instead.  So when I reply, other can benefit from the reply.  This will save me a lot of work long term.

The forum rules are strict and we will not tolerate any BS , negativity, or arguing with others. I am personally sick to death of all the negativity and BS on other forums that I rarely go on other forums any more.  Forums are supposed to be a fun friendly place and I just don't see that any more with any forums, not just Atari ones.  Far to many people have left because of such issues, including myself and nothing ever gets done about it.

Its 2017 and its time to start over.  Lets get back to quality work and make new friends, learn new things and help each other.  Leave all the negativity and BS at the door!

My forum will be WIP (work in progress) for some time while I update it. I hope others will join and help make the forum a success!



Monday, 14 August 2017


While testing out a booster prototype I found that it refused to work with the 68HC000 CPU.  I first thought that there was some problem with my PLD code. Later I had bypassed the PLD totally and hardwired the 68000 DIP socket to the PLCC socket.  So my PCB was basically a DIP to PLCC adapter. Problem was, it just refused to work.  Oddly though, a older TTL (IE original PLCC CPU) worked fine.  To which point I blamed the 68HC000 CPU for being faulty.

Several CPU's later, and I couldn't figure it out.  The motherboard and booster "adapter" worked fine with a TTL CPU. But adding in CMOS (HC) CPU refused to work.  I decided to test those CPU's in my STE and they all worked fine.  This made  no sense at all.  How could the CPUs test fine in my STE but not work in my simple adapter PCB ?!

I dug out a original V2 booster and it booted right up first time.  With the HC CPU.  So clearly the issue wasn't some compatibility issue with the CPU itself and the motherboard.  I even tried a second motherboard and that behaved exactly the same.  So the motherboard itself wasn't the problem. Just 2 motherboard refused to work with my HC CPU, but would work with the V2 booster which did use a HC CPU.  Again, this made no sense.

So I took out the CPU from the V2 booster, it was known working setup of course, and put in another one of the HC CPU's I had been testing.  The V2 booster did not boot up.  I tried a few more CPU's.. booster wouldn't boot at all.  At that point I tried the boosters original CPU (that worked) in my new V2 design and it did not boot, still.

I thought to go back to "square 1" and put back the known working CPU back into the original V2 booster to make sure I had not broke anything or had a bad connection. To my amazement, the booster refused to work! WTF is going on ?!  I tried the original DIP CPU back in the motherboard and it booted right up. So clearly not a motherboard problem.

So now I had re-tested all the HC CPU's back in my STE and each one worked fine.  So at this point I had assumed that I had managed to kill the V2 booster. Though that did not really add up since the boosters own CPU refused to work in a simple DIP to PLCC adapter.  But wait it gets better! Placing the original TTL CPU into the V2 booster worked, and even worked in my DIP to PLCC adapter (which was the next gen V2 booster hacked that way).  So clearly the CPU's were not faulty, The boosters were not faulty,  but the CPU's refused to work in the boosters ?!  The same CPU's had been used countless times for years in my booster projects! This all made no sense at all.

It was the weekend, I spend the weekends with my girlfriend where I ranted on about all this not making any sense. She suggested maybe the new CPU's are damaging the sockets somehow which would explain why the V2 booster, worked one moment, and refused to work after some CPU changes.   Though this did not really make sense as to why the CPU's worked in the STE. But at least it was a new direction for me to think on.

As all my Atari stock was at her flat, I found out the old TTL 68000 CPU's and the newer HC CPU's as used in the STE boosters and said these are the CPU's they are identical.  she looked at them and said they aint. Like, what ?! She noticed the HC CPU's pins were actually thinner and a slightly different shape! Odd I thought.. She also suggested again that maybe the new ones are damaging the sockets..

So I routed though some kits and dug out a socket from the blitter kit and let her look at those.  I also thought, well, those CPU's work in the STE boosters, so I took a socket out  of one of those kits as well.  She looked at both sockets and both CPUs and noticed the HC CPU fits in one socket but not another.  But the old CPU actually fit in both sockets.. like, WTF ?!

The sockets were slightly different.  One socket had pins which were more '\' shaped.  The other socket pins were more bent, like 'Y' shaped, well, half the 'Y' shape that is. Basically not a straight pin.  I thought the "slanted" pins would contact better if the CPU pins were bent. Though maybe it was the CPU pins on the newer HC CPU being thinner which for some reason did not like one particular socket, basically the slanted pin ones. Though this did not really make sense either.

She later found that the older CPU's fit fine in both sockets, but the newer CPU was a really tight fit in one socket, but not the other one.  I looked into this and what I found next actually shocked me.

The HC CPU while it had thinner pins on the bottom, I would assume it was done to aid in SMT manufacturing. So the slated pin sockets would be contacting at a angle more on the bottom of the CPU pins. Which would make it seem a bit suspect if it would contact properly or not. Though oddly that wasn't the issue.. it gets better...

The HC CPU pins on the side are actually WIDER than the original CPU, so the contact area should be better on the 'Y' shaped pins. Though this did not fully explain things either..

I looked at my website at my guide to removing the STE CPU socked and found they were also the 'Y' type pins (or bent pins as I am just going to call them).  So this was painting a picture that those slanted pin types are causing some problems.   It would make sense since the older TTL types had wider pins and the bottom than the HC types and would contact better.   So I thought I had finally found the problem.. only it wasn't actually that either.. and it gets better still...

The slated pin sockets have tiny plastic "spacers" between the pins.  I assume just to keep them in position. What I never realised until today, is that those plastic parts actually slot in between the gaps on the CPU pins themselves.  This doesn't sound like a big deal but it was actually...

The slanted pin sockets, the plastic spacers (as I call them) being thicker, and the HC CPU pins being wider (at the top) actually resulted in the plastic parts of the socket, pushing the pins inwards to the point where the CPU's would no longer make contact in the other PLCC sockets.  Oddly the older TTL types had  wider space at the top, so it would never matter for those, which is what I found.

At some point in all this, I found also that once a HC CPU was tried in a slanted pin socket, not only did the socket bend the CPU pins out of shape, but it also distorted the plastic spacers and did at some point cause the original TTL CPU's not to work either.   At that point I thought I had killed my V2 booster or motherboard by placing a faulty CPU in it.  but it just wasn't so. So now we have the answer to all this chaos!

The original CPU's (TTL type, or even GLUE, MMU chip etc) will work in either type of socket without problem.  BUT, the HC CPU's will ONLY work in the 'Y' shaped (bent pin) type of sockets.  If you try and place a HC CPU into the '\' shaped (slanted) pin sockets, it will damage the socket AND damage the CPU pins.

The slight "red herring" in all of this was all the CPU's worked in the original Atari PLCC sockets even though the CPU pins were actually bent and wouldn't work in any other socket! So lesson learned that newer sockets are not better than the ones in the 80s.

I guess its also annoying that now any sockets I buy, I have to really check they are the bent pin types before using them in any booster projects. Of course such sockets do not matter with older chips.

I think also there is some split blame here.  I can blame the slanted pin sockets for bending the CPU pins, Or I can blame the HC CPU's for damaging the sockets! Or maybe this is just down to tolerances.  Maybe the sockets are on the max tolerance along with the CPU.  Just so happens that "both" of them being on tolerance extremes that they can actually damage each other. Madness!

Either way, I now know that all PLCC IC's have differences along with the PLCC sockets.  The difference are so tiny at a first glance they would go un-noticed. Though I had to post about this as this drove me nuts for 2 days. Hard lesson learned... Never assume anything is as you think it is, and even a innocent PLCC socket can have tiny differences that can stop something from working and test your sanity..

Here are the images.. (click for larger image)







Friday, 11 August 2017


It quickly came apparent that my first design was simply to large :(  So a total re-think was in order.

This is only a "quick" layout to see how things would route.  What we have now is the BLITTER, CPU, GLUE,ROM under the PSU. This space is actually wasted and no real room for any expansion card. So it makes sense to route there.

The MMU sits just in front of the PSU, the ST-RAM card is also there and the bus isolators under the ST-RAM card to save space.

The shifter is now located right next to the monitor output along with the RGB drivers.

One change which was suggested by Rodolphe was replacing the RS232 area with a MAX232 IC.

The MAX232 did not have enough IO's so the MAX238 was used.  The good thing about this IC is that it is more compact, the 1488 and 1489 drivers are no longer needed.  Also the TL497 voltage generator is also no longer needed as it is built internally in the MAX238. So overall it saves on a lot of parts and PCB space.

(original circuit)

There is a MAX235 which is exactly the same as the MAX238, but it does not need the external capacitors. I was going to use that but its easily twice the price of the MAX238 :(  So no use in spending £5+ on a IC where 4 cheap capacitors can be used instead.  So the current design now uses the MAX238.

I am also now working to align the connectors to their proper locations as well as improving the IC layout.  I hope this will allow me to reduce the PCB space to half the size so making a prototype will cost a lot less.

There are also a couple of resistors packs which are linked all over the place. I may remove those into individual resistors or 2 smaller resistor packs. No use in having tracks running right across the board just for a pull up resistor.

I am still considering what to do about the TTL chips.  They could easily be replaced by a GAL. Though problem then becomes more routing across the board to go to 1 GAL.  A lot of gates in each IC are not even used. Or can be done with less gates.  There is also the slight issue that it makes the design a little more complicated as GAL's would need to be programmed instead of basic TTL chips.  Though considering in the future there will be a big PLD for the booster logic. I suspect overall I will moved to GAL's instead of dedicated TTL chips.

Monday, 7 August 2017


100% routed :)

Well maybe not exactly as I have a epic amount of tidying up to do yet.  I also need to add in de-coupling caps and the reset switch has gone AWOL.

The "back" IO connectors are basically in the right place. Though I need to measure a real motherboard and make them align with the case properly.  The Cartridge and midi ports are just plonked on just for testing.  As this board is a lot smaller than the original, Then alignment doesn't matter at this point.

I will probably add in a single IO expansion port onto this. Then at least at some point I can route the alt-ram stuff into a card.  Once working, I *might* add that into the next design as a stock feature. Or it may be a custom IO card which may fit under the PSU.   Currently there isn't any room for anything under the PSU, not a expansion card anyway. Though I think a right angle connector which is dedicated to alt-ram would easily fit there.  Then at least its not taking up a main expansion port then.

It has become apparent that the TTL chips, inverters etc, are actually getting in the way of "good" routing.  There isn't much I can do about that. Though I am half wondering about replacing them all with a couple of generic 22V20 GAL's.  Then at least I can make the layout of the chip better to suit my PCB layout.  As it stands, the TTL chips are actually making the design a bit of a mess :(

Similar with the ST-RAM card. Because the Falcon card is 32bit, this means a lot of double routing to convert to 16bit.   There isn't much that I can do about that. Though the bus isolation buffers are also a huge mess of tracks. Again, I may just replace them with a larger PLD. Though I am not sure at this point if its a good idea to move away from dedicated TTL chips or not.  For example, I don't want to force people in the future to use Altera chips (which is what I am using currently).

Ultimately, there will be some more "glue" logic. Which will contain the booster logic. That will be Altera most likely. Though at least it is a optional extra.

So the plan now is to finish off the current design. Lots of messing about with stuff to do now. But it is 100% routed now!

I had a program running to check time to route it, and its about 28 hours! 36,000 left button mouse clicks and mouse moved about 3.5miles!  Considering the work involved I think 28 hours is a huge accomplishment. Of course it will take a lot more time to add in the booster logic, IO expansion headers and other stuff. Though at least this is something now which is almost ready to be prototyped!