My Atari Projects

My Atari Projects (Reverse Chronological Order)


January to April 2023 - It's all Greek to me! 

I have been very fortunate to have been given a beautiful ATX beige box.  I would be the first to acknowledge beige box PCs from the 90s passed me by, I was just not into them at all, and was actually still using my Atari ST as my main computer until the early 2000s.  However look a little closer and you will realise this is not just any beige box, it is in fact a beautifully conditioned Medusa Hades 060.  The very kind gentleman who bestowed this Hades upon me was very generous, and would not accept payment on the premises of known issues and the known delicate nature of the Hades, no matter what I tried.  However I was indeed feeling guilty for such generosity, especially when all original schematics and documentation were intact, not forgetting there were boxes of software from NVDI 4.11 ET4000, Cubase Score, Kobold to N.AES 2.0.  However, this kind soul also had a CRT monitor I used to drool over when I was a teenager, a monitor which Systems Solutions used to sell, an Iiyama Vision Master 17 MF-8617T.  So to allow me to cross his palm with silver I offered to purchase the monitor, as well as a Roland SC88 sound module.  

The known issues of this beautiful machine are as follows:

Medusa Hades upon collection

Aside from the known issues, there are also some general things this Hades could do with after looking at the internals:

So first up I gave the Hades a clean, including the following cards which came with the Hades, the first of which is the ET4000/W32 PCI graphics card.

Then the PCI based Ethernet card, which happens to be RTL8029 based.

The last card to get the Isopropyl treatment is the ROPO-COP ROM port expander ISA card. 

I decided to purchase a few new toys, a new RTC from Centuriontech.eu, as well as some cheap back up 16MB EDO RAM sticks, presently this Hades has 64MB of EDO RAM.  Lastly I also bought an ES1371 PCI sound card, which I can play with in the future.  Again this sound card was cheap.

Other toys purchased include some thermal pads, new heatsinks, a new SCSI cable and DB25 connector which will future proof the Hades SCSI, and a StarTech IDE to CF adaptor which includes Molex cable, 3.5" bay and a backplate.

The motherboard is now clean, as well as the RAMROM chip which was gunked with thermal paste.  A new heatsink has been placed on top of the chip with a thermal pad.

After a further clean of the motherboard, I decided now was as good a time as any to replace the Dallas RTC chip.

The new RTC is now in place and looks good, and the NVRAM settings have been configured using Boot Config 2.01.  The really good news, which I suspected, is that the RTC has of course fixed the retention of the system clock.  Beautifully it has also fixed the printer port issue, it now recognises devices on the SCSI bus, but perhaps most importantly it has fixed the barcode error.  I have to say, I am more than happy with that!  

Incidentally, the barcode error is probably better defined as the 'motherboard error', as the purpose of the error is to attempt to illustrate where on the motherboard there is an issue. 

Next up I decided to test out the StarTech IDE to CF adaptor and create a bootable CF card using the latest HDDriver.  No issues here, so I will run this Hades off of Compact Flash, and build a new boot drive!  This Hades does have an IDE HD, which I will leave in place but disconnect now that I have backed it up.  It also has a 750MB Iomega internal IDE Zip drive which I will leave on the IDE bus, and make use of backing up my boot drive should I ever encounter a CF card crash.

I then removed the IDE to CF adaptor from the 3.5" bay and placed it into the backplate which came with the StarTech 'kit'.  I thought it would be easier to place the CF card on the rear of the Hades in place of the external SCSI port which I won't be using externally, and as I wouldn't be removing the CF card frequently, if at all, I don't feel the need to seat it in the front of the machine.

The boot drive has now been set up, and as with all my TOS based machines I will run the Hades with XBoot.  At the moment this Hades has an ET4000/W32 PCI based graphics card.  The easiest way to set this up was via NVDI and it's built in ET4000 driver, which came with this machine.  I specifically set this up with NVDI 5.03 which has various graphic card driver support out of the box, as opposed to dedicated ET4000 versions.  I will spend more time with the Nova drivers at some point, but I need to find the correct version first.  

So now for some GEMBench testing.  I used GEMBench's TT reference which has no cache, but it seemed the most appropriate given the Hades is a TT clone.  I ran GEMBench from ST RAM, with the cache on and with NVDI, which in this set up is coupled together with the ET4000, so cannot be disabled.  

TOS: 3.06m (English TOS 55)

Resolution: ET4000 at 1200 x 832 in 256 colours

RAM: 64MB

FPU: Yes

NVDI: Yes

EDIT:  I have since realised there is a GEMBench reference for a TT with the cache on... however I am not going to re-test swapping memory modules in and out.

Nevertheless that's nice!  The ET4000 works quite well with NVDI as you would expect, however the NVDI ET4000 driver and the ET4000 are not very good above 256 colours with certain applications, which is a shame.  I have now installed quite a lot of software on this machine, mostly DTP and word processor software, the usual culprits from Calamus SL to Papyrus X, as well as compatible MIDI software like Cubase Score.

I will dabble with MiNT, notably Mikro's FreeMiNT distro, because I want to conform to TOS rules with partitions so I am not completely tied into MiNT.  This will help safeguard compatibility, at least as much as I can on a Hades, and allow me to switch freely between TOS and FreeMiNT without losing access to partitions because TOS cannot recognise them.

There we have it, one FreeMiNT build later and I am pretty happy with my Medusa desktop, naturally.

Again I thought I would purchase a few more toys, I wanted at least 512MB of EDO RAM in the Hades, and I decided to try out a 2MB ATI MACH64 graphics card.  The RAM was initially problematic as the full 512MB RAM wasn't being recognised, however it turned out to be a dodgy 128MB module, which was eventually replaced.  

Once the issues with my RAM had settled, I fitted the MACH64 graphics card.

A quick crude test and benchmark of the Hades and the ATI MACH64 now with 512MB installed, and clearly the machine has gained in speed over my last benching with the ET4000 and 64MB of RAM.

TOS: 3.06m (English TOS 55)

Resolution: MACH64 at 1024 x 768 in 256 colours

RAM: 512MB

FPU: Yes

NVDI: No

Granted this is a dirty test as the MACH64 is not running alongside NVDI, and the resolution is different due to different available resolutions between graphics cards.  However even without NVDI the MACH64 is faster.  The RAM does increase the speed, but the MACH64 is the main factor in speeding up all of the VDI routines...

 ET4000 MACH64

Display:   1526%       2671%

CPU:          356%            324%

Average: 737%       930%


All that said though there are pros and cons with the MACH64 compared to the ET4000.  The MACH64 is the better card with having more onboard RAM and higher resolutions, however on screen I like some of the available resolutions of the ET4000.   Coupled with NVDI and its ET4000 driver I actually prefer it in terms of usability, and it also appears to play more nicely with fonts handled by NVDI than the MACH64.


Next up is the last purchase of additional toys, an inexpensive PS/2 keyboard from Perixx, and an equally inexpensive USB mouse from the same.  Also a couple of useful extender cables from StarTech, a PS/2 extender and a USB extender given how I am going to have to have the Medusa Hades positioned.  Lastly a TruMouse USB mouse adapter, not super cheap, but it will be useful, and will of course allow me to use USB peripherals such as the aforementioned Perixx mouse.

 That's it, that's the Medusa Hades 060 complete and working how I wish.  Cleaned multiple times, fixed and with a few new upgrades and peripherals, notably running off of Compact Flash with 512MB of RAM, and a choice of an ET4000 or MACH64 graphics card.  A beautiful rare machine!  There will be a few things to play with and do in time, such as seeing how the ES1371 PCI sound card performs, perhaps replacing the PSU, and certainly replacing the two noisy big fans housed inside the case.

October 2022 - Friendly K..AT

Annoyingly my Friend-Chip K..AT is not as responsive as it could be, leaving you to really having to push down on the buttons for this remote to work, especially the Stop button.  I therefore decided to give this K..AT a spray with contact cleaner, and a quick clean with Isopropyl Alcohol.  I do think however it is the seating of this remote which is its predominant annoyance.  So I decided to carefully reseat the PCB inside of the K..AT shell, before tightening the screws, without over tightening, as the buttons do tend be pulled into the casing, meaning when pushing a button, it affects the travel to the contacts.

All in all, that seems to have made this unit function better, although I may try longer machine screws at some point!

October 2021 - ADAS Boot

I managed to get my hands on a Plasmec ADAS D2D recorder with the additional SPDIF IO board a few months prior to obtaining my ADAP II Portable in 2019.  However as I have read, this here machine is indeed very particular in its set up.  It occasionally worked with my GigaFile SD, but 90% of the time it didn't.  

Since moving the GigaFile over to my Falcon, I typically use an UltraSatan SD, however the Plasmec ADAS certainly does not like the UltraSatan, and so the issues continued.

I do not mind troubleshooting these type of things, in fact I quite enjoy it!

The ADAS connects to the ST via the ACSI port, where an Atari TT, Mega or Mega STE would have less issues, on account of having their own internal drives, or in case of the TT a SCSI port as well, on an ST, the ADAS has to first connect to the ACSI port, with an HD connected to the ADAS' ACSI through port.  This is where both the GigaFile and UltraSatan just do not co-operate with the ADAS, they both freeze on boot.

To this end, I decided to test my hard disk drivers, HDDriver and ICD Pro.  I created two bootable SD cards, keeping them as small as possible with the first boot partition as a small GEM partition, and no more than 3 more partitions, totalling 4 partitions.  However booting with both drivers in a vanilla set up with the ADAS attached, just did not work.  No matter what I tried, the ADAS just would not co-operate with the UltraSatan.

Moving on from the UltraSatan, I had a couple more options.  I have been using mass storage on my ST for years, since 1995 when I purchased a SCSI based 850MB MiniS HD from System Solutions, once a big retailer for the Atari TOS platform in the UK.  I also have a few SyQuest drives purchased new from around 1996 onwards, purchased from the likes of Gasteiner, another well known UK retailer from back in the day.  I therefore retrieved my MiniS HD, connected it up via the accompanying ICD Link II host adaptor, as well as via the ADAS, and at last this combination worked upon boot.  However I would like to recondition my HD, and it is a little noisy on account of its fan, one of the very reasons I switched to SD card based media.  Nevertheless, this gives me options to build on.

The SyQuest drives are noticeably a lot more quiet, so next up I attempted to create a bootable SyQuest cartridge via my SyQuest EZ135.  I have many of these cartridges, and if it means I can get the ADAS to co-operate, then so be it, as it simply will not with my SD card solutions.

First I tried HDDriver (11.08), but unfortunately similar to my ADAP II, it seems to not want to play ball with this combination.  Back to ICD Pro, I partitioned a few small GEM partitions, keeping them with clean sizing (e.g. 10MB each) booted the SyQuest drive via the ADAS, and at last the EZ135 via the ADAS and ICD Link II host adaptor worked.  

However, although the combination between the SyQuest drive, ICD Pro and the ADAS were happy, when running the ADAS software, what seemed random errors and issues kept presenting themselves.  Although not documented, I read in a review the unit apparently only recognises HDs on SCSI IDs 0 through to 3.  Checking the SyQuest drive it was on SCSI ID 5, so I changed this to 0, still no joy.  However after setting the SCSI ID to 1, this seemed to alleviate the issues I was having. 

Testing the Plasmec ADAS software to record audio direct to my SyQuest drive is finally working nicely.  This leaves me with 3 set ups, a bootable SD as my main set up using HDDriver, a bootable SD set up using ICD Pro for my ADAP II, and now a bootable SyQuest set up using ICD Pro for the ADAS.

Why the ADAS is so particular is not so clear, it could be ACSI IDs!?  The ADAS does not appear to have an ID itself, at least if it does it is discrete, not disclosed and cannot be changed.  Yes the hard disk drivers have a bearing, but It is more likely the issue is the length of ACSI cables combined, which are always preferred short, and so is less particular with SCSI devices.  Certainly, like the ADAP II, the key factors to consider were the hard disk drivers, partition types and sizes, ACSI / SCSI ID numbers and the choice of device itself whether ACSI or SCSI.  Either way, the ADAS is now stable, but took a good 16 hours or more to diagnose and remedy.

January 2021 - The ADAP II Portable is Alive!

Late in 2019 I had acquired one of the very few and obscure Hybrid Arts ADAP II Portables from ex Hybrid Arts employee, Chuck Peplinski.  In my eagerness, as soon as I received the ADAP II Portable I powered it up to see if there were any initial issues post shipment.  Stupidly, I totally neglected the machine was switched to US voltage, and as I am not in the US, that went down like a sack of sh£%!  Safe to say, after my initial power up, it swiftly powered down not to power back up again!  Doh!!!!

After this set back was remedied, I made sure the voltage switch on the back of the ADAP II Portable was on the correct voltage, connected it to my ST, and proceeded to set the ADAP II up, however this was during a transition period in my home studio, upgrading the ST, upgrading various studio based synths and samplers et al, as well as refurbishments.  Safe to say I was running into issues across the board.  The ADAP II was in this mix, and would not always be recognised by my ST, but as I found out, this was due to issues I was having with my ST and stability post various upgrades. 

Once the dust had settled with my ST's stability issues, the ADAP II was also now stable at boot, however I was encountering issues with the ADAP II Portable and set up process.  Namely, I could not format my bootable SD card via my UltraSatan, so that the ADAP II Portable could actually record audio to hard disk.  The program used for this, SFSFormat, would simply freeze.  

I therefore decided to use a new SD card and test hard disk drivers, namely HDDriver which is what I typically use, against ICD Pro, what I used to use.  It turned out that I could not get the ADAP II Portable comfortable with HDDriver (at the time HDDriver 11.05), or 'big' SD card sizes with multiple partitions.  This was with both identical partition types, GEM for the bootable partition as I prefer to keep the boot partition relatively small, leaving more capacity for further 'big' partitions, or BGM (Big GEM) partitions.  In conclusion, using a 2GB SD card formatted with no more than 5 partitions using ICD Pro as my driver, was proving to be the optimal set up for the ADAP II.  Voila, running SFSFormat to prepare the SD card for use with the ADAP II Portable now worked, formatting the SD card with Hybrid Arts' proprietary SoundFileSystem.

So now I have a bootable SD card which I use as my default using HDDriver, and a smaller bootable SD card specific for use with the ADAP II Portable, using ICD Pro.

Testing the DRE software for recording via the ADAP II Portable direct to hard disk, or direct to SD card in this instance, is really snappy given it is SD media, and confirms the ADAP II Portable and upgraded STFM are now stable together, recording audio with no issues.

November 2020 - Testing, Testing - 1, 2, 3

Since replacing my Exxos PSU with a recapped Mitsumi, my ST has been rock solid.  Stupidly though, I have never benchmarked my STFM.  

I have used a TOS switcher for years, since the 90s, along with hard drives, a graphics extension upgrade in OverScan, and RAM upgrades, but my newer upgrades have furthered these, replacing the RAM with Exxos' MMU RAM, a v2.2 Booster, BLiTTER, a replaced TOS switcher, yet still retaining my OverScan board.  The overriding factors of these upgrades for me was of course comparative performance, for crunching audio and MIDI data, but also compatibility, specifically with music and MIDI software in mind.  Given this everything is switchable, and even though I can feel my ST is faster, as it has a noticeable snap compared to stock, it's time I took a look at the figures under GEMBench!


Test 1 - STock Mode

Stock for my STFM is switching it back to TOS 1.04, no OverScan, 8MHz mode with 1MB of RAM and no NVDI 3.02, which is the version of NVDI I purchased new way back when.  It has a slightly smaller footprint than later versions of NVDI, supposed better stability and as superficial as it is, I prefer the way it loads fonts over NVDI 5.03.  All of which are seeming compromises I am happy with on my ST.  My GEMBench reference is equally an STFM with TOS 1.04 and no NVDI.

TOS: 1.04

Resolution: Medium

CPU: 8MHz

RAM: 1MB

BLiTTER: No

OverScan: No

NVDI: No

I work in High resolution 95% of the time, but for the sake of more accurate benching, given I understand many, if not all of the GEMBench referenced tests were performed in Medium, resolution was set to Medium resolution.  As expected, pretty much 100% across the board.

 STock

Display:   100%

CPU:       100% 

Average: 100%

Test 2 - BooSTed Mode

To get an indication of how the Exxos v2.2 Booster alone has increased my STFM's CPU performance, I left everything as per Test 1, but switched the booster to 16MHz.

TOS: 1.04

Resolution: Medium

CPU: 16MHz

RAM: 1MB

BLiTTER: No

OverScan: No

NVDI: No

That's a nice increase!  Overall in 16MHz mode GEM speeds up, VDI and BLiTTING have increased, and notably the ROM access has been sped up by a decent amount to 170% due to the booster and onboard Fast TOS ROMs.

 STock       BooSTed

Display:   100%     148%

CPU:          100%          148%

Average: 100%     148%

Test 3 - BLiTTERrific Mode

Now to see how the BLiTTER has improved performance on my STFM, coupled with the Exxos v2.2 Booster.  In this instance then I am switching the BLiTTER on, with everything remaining as per Test 2 with 16MHz mode left on.

TOS: 1.04

Resolution: Medium

CPU: 16MHz

RAM: 1MB

BLiTTER: Yes

OverScan: No

NVDI: No

Pretty BLiSTering pace with the BLiTTER on for this STFM, improving GEM, VDI speed and of course BLiTTING.

 STock        BooSTed        BLiTTERrific

Display:   100%     148%         268%

CPU:          100%          148%              148%

Average: 100%     148%         199%

Test 4 - BeaST Mode in Medium Resolution

To compare to my stock, boosted and BLiTTED STFM results, I switched everything to what I am calling BeaST mode.  Again I used the same STFM TOS 1.04 with no NVDI reference.   Therefore I switched over to TOS 2.06, OverScan on, 16MHz mode with 4MB of RAM, BLiTTER on and now with NVDI 3.02. 

TOS: 2.06

Resolution: Medium

CPU: 16MHz

RAM: 4MB

BLiTTER: Yes

OverScan: Yes

NVDI: Yes

Results

The results speak for themselves, but that is a nice speed improvement overall.  GEMBench's comparison meters are a little stretched in OverScan mode in Medium resolution, but NVDI has a significant impact on the VDI and BLiTTING routines as you would expect, partnered with the BLiTTER.  Overall, I am impressed with the comparative results.

 STock         BooSTed     BLiTTERrific        BeaST (Med)

Display:   100%       148%   268%         539%

CPU:       100%           148%   148%         148%

Average:  100%           148%   199%         282%

Test 5 - BeaST Mode in High Resolution

For a real world test, given I work in High resolution most of the time, it seems logical to bench BeaST mode in the way I will be typically using it.  Therefore, to compare to BeaST mode in Medium resolution, I left everything as per Test 4, but switched to High resolution.

TOS: 2.06

Resolution: High

CPU: 16MHz

RAM: 4MB

BLiTTER: Yes

OverScan: Yes

NVDI: Yes

Results

I am happy with that, it is not FrankenSTein, nor the fastest ST ever, but BeaST here is certainly swift by STFM standards.  I perhaps could get a little more speed out of BeaST mode if I used NVDI 5.03, but I would rather keep to 3.02 on my STFM given its smaller footprint and more pleasant way of loading fonts.  Running GEMBench shows just how quick this STFM now is, comparatively of course, keeping this on a Motorola 68000 which is paramount for me for safeguarded compatibility, as well as being able to switch everything to stock for as full software compatibility as I can expect to achieve.

 STock         BooSTed     BLiTTERrific        BeaST (Med)        BeaST (High)

Display:   100%       148%   268%         539%               684%

CPU:       100%           148%   148%         148%               147%

Average:  100%           148%   199%         282%               317%

Adhoc Test 1 - BeaSTier?

Many clamber for the last and latest versions of products, whether hardware or software, as we blindly believe new means better.  Now that statement is a sure sign of getting older!  Although I will retain using NVDI 3.02 as I have in the last few decades, in the interest of understanding if I can eek a little more performance out of my upgraded STFM (aka BeaST), I shall compare BeaST mode with NVDI 3.02, against BeaST mode with NVDI 5.03.  Therefore, I used the STFM TOS 1.04 with no NVDI reference I have been using throughout these tests, with everything switched up as per BeaST mode in High resolution, replacing NVDI 3.02 with NVDI 5.03.  I did not tamper with fonts, as I did not want to upset my current boot arrangement, hence the default NVDI Monaco font used. 

TOS: 2.06

Resolution: High

CPU: 16MHz

RAM: 4MB

BLiTTER: Yes

OverScan: Yes

NVDI: Yes

There it is!  Surprisingly, despite NVDI 5's extra features, for out and out software acceleration in BeaSTier mode, it is slower, with all of the GEM, VDI and BLiTTing routines either the same, or marginally slower than NVDI 3.02.  Not at all BeaSTier!  So for my preference, not only do I prefer NVDI 3.02 because of its smaller footprint and the way it handles loading fonts, it is also faster as a software accelerator than NVDI 5.03.  NVDI 5.03 may have additional features, and I may not notice the small differences in speed under normal usage conditions, but that's a no brainer given I have used NVDI 3.02 for sometime, and indeed shall keep it that way!

 BeaST (High)       BeaSTier?

Display:   684%                 612%

CPU:       147%                     147%

Average:  317%                      300%

Adhoc Test 2 - MegaTeST

Lastly, as a bit of fun, I decided to pit BeaST against a Mega STE.  BeaST is not going to be as fast as a TT, but a comparative test against a Mega STE?  Incidentally BeaST here can be faster than a stock Falcon, but it is not when running explicit comparative tests.  Nevertheless for this test I kept everything switched on as listed below, removed NVDI and benched it against an uncached Mega STE running at 16 MHz with TOS 2.06, switching back to Medium resolution.

TOS: 2.06

Resolution: Medium

CPU: 16MHz

RAM: 4MB

BLiTTER: Yes

OverScan: Yes

NVDI: No

Well this comparative test has surprised me, the timings benched ahead of a Mega STE, albeit uncached, with only RAM Access and Integer Division results level, not bad!

 MegaTeST

Display:   128%

CPU:       119%

Average:  123%

October 2020 - Project BeaST - What a TOSser!

Recently my Exxos PSU has become unstable.  I am uncertain why this is, whether it is simply a failing component, or whether it has shorted out and is now suffering as a result.  I do have numerous peripherals attached to my ST, from samplers to D2D recorders, switch boxes and expanders of various ilks, however there have been a few moments where my STFM has decided to switch off, and where the Exxos PSU's fuse has blown.  Unfortunately, after much investigation, the Exxos PSU seems to be the culprit of numerous instability issues with attached peripherals.  However it was not the only culprit, I introduced a monitor switch to switch between mono and colour resolutions, however I realised after sometime it was also adding instability.  There were times in OverScan mode, thanks to my OverScan board, when I would experience random crashes.  Now OverScan doesn't work with everything, but it was starting to occur more frequently.  I noticed this when running Steinberg Avalon, when I subsequently played a sample my screen would garble in OverScan mode, and my ST would reset.  It all used to work, and it took me a good few hours to realise it was the monitor switch, maybe with everything combined drawing too much power to remain stable?  Nevertheless, once I removed the monitor switch, OverScan was more stable, and playing a sample in Avalon no longer meant my ST would reset.  Either way, as useful as a monitor switch was, and as beautiful as the Exxos PSU looks, I swapped the Exxos PSU out for a recapped Mitsumi SR98.  This will also give me time to diagnose what is exactly ailing my Exxos PSU, and ascertain how stable my ST will now be.


As fate would have it, at the same time I have indeed been a TOSser, and forced a floppy disk into, and out of my floppy drive.  Safe to say my floppy drive is not sounding too good.  Are the Atari gods telling me go for a GOEX?  Anyhoo, I decided to have a poke around my Epson SMD.  Everything inside looked intact, however I did find a piece of metal under the hub, never a good sign, it appears to be from my floppy disk, so removed it.  While my floppy disk drive was naked, I decided to give it a good clean.


Time to put the housing back and hope that pesky piece of metal isn't important, whatever it was from, floppy disk or drive.

While my STFM was apart, I also thought it prudent to give it a quick clean, and also see to some small things which have been on my mind.  Namely, clean the underside of my AutoSwitch OverScan upgrade as it does have some corrosion, and attach a few ties to tidy the wiring.  OverScan does not really have a home as it is not socketed, it used to simply be stuck with tape to where there was free space for a socketed BLiTTER.  Now I have a socketed BLiTTER, and the motherboard has been cleaned, I can see the state of the underside of the OverScan board.  However with a soft bristled toothbrush and some rubbing alcohol, the corrosion was soon obliterated, lovely jubbly!

That's better, a little more clean and tidy!  From henceforth I dub this ST the BeaST!  I'll say it again, what a TOSser!

The BeaST fully clothed once again.

August 2020 - Project C64 - I am SID to Death of This!

What on earth is this doing here!  Well it may not be Atari, but my Commodore 'LukHash' C64C housed in a C16 case has a problem.  This C64 is customised by LukHash, with 2 pots for predominantly Cynthcart, a 1/4 jack output, gold paint job and cyclical LED.  However I am not getting any sound, and it seems fair to assume the SID chip has overheated, a common problem!

Luckily I already have a couple of spare SID chips, my favourite 2 SID revisions, an 8580R5 and a 6581R4AR.  Each SID revision has its own flavour of sound, these are my personal favourites.  I am glad I have these, as these things are getting expensive! 

At some point I will fit either my SID2SID, or most likely my SIDFX, the latter will enable me to have both my 8580R5 and 6581R4AR and mix between both of them.  For now though, I replaced what I believe is my failing 8580R5 with my spare 8580R5, and this time placed a heatsink on it.

Back together and tested.  Yes my original 8580R5 SID had overheated!  This has taught me a lesson as I was holding off putting a heatsink on it, and that's what I get for holding off, booooo!  Never mind, my LukHash C64 is happy again, as am I. 

December 2018 - Project FUBAR - Ahhh Nuts!

During 2017 and 2018 I had purchased the Exxos 230v PSU, Funky PLCC68 adaptor board and BLiTTER, 4MB MMU RAM, and I believe the last v2.2 16MHz Booster including Fast ROM for my STFM.  The idea was to update this ST's motherboard, given it is special to me since I have owned it since 1988, replacing my 4MB Marpet RAM with the Exxos 4MB MMU RAM given its supposed improved stability, and add a hardware switcher to switch between 1MB and 4MB.  Similarly, update the PSU, add a BLiTTER, retain my OverScan ST graphics board, and add the v2.2 Booster allowing me to switch between 8 and 16MHz, as well as TOS 1.04 and TOS 2.06.  I considered EmuTOS, but I have noticed some software I use is not compatible with EmuTOS, post testing using Hatari, and I did not want to introduce further compatibility issues despite EmuTOS gratefully still being supported.  Nevertheless, with all of the hardware switching I would be able to run an accelerated STFM, but switch back to stock for full software compatibility.  Not for everyone, as it will incorporate hardware switches, but this is a working machine and not a shelf queen, so I am comfortable with that.  However I would not, and will not take this approach with the Falcon, as it is a lot more scarce than an ST. 

To this end, I sent my Atari away to be upgraded as I was a little overwhelmed with the prospect.  In retrospect that was a mistake, as I sent my ST away knowing the upgrade was being done by a capable technician, but who turned out to be not completely au fait with the Atari ST.  

My nervous fears were realised, and I received my ST back not exactly fully assembled, a chipped case, not working, £120 down and 1.5 months later.  I think there are some lessons here across the board, notably to listen to yourself.  

However, after assembling my Atari and inspecting, I soon realised the ST was powering up, however was not booting or firing up the floppy drive.  After e-mailing Exxos, he pointed out what should have been obvious, but which I did not notice, that being one of my TOS ROMs socketed from my old TOS 2.06 switcher upgrade was still present.  I also noticed on my original AutoSwitch OverScan board, one of the additional wires had come unsoldered from where the 'Old DE' wire solders onto the motherboard.

Lastly, and this is laughable, the expert who was supposed to perform these upgrades would you believe didn't solder the v2.2 Booster to the motherboard.  I hate text speak, but WTF!  Here we go then, with assistance from Mutant Caterpillar, time to fix this and get this ST shoe shine clean.

1. My STFM pre upgrade, sporting a non switchable 4MB Marpet RAM board, TOS 1.04 to TOS 2.06 switcher and AutoSwitch OverScan hiding under the shielding.

2. My STFM post being sent away for an upgrade and returned in pieces, now assembled but not booting.

After tinkering around off and on for a few months, the longest period of time my STFM had been out of action since 1988 when it was purchased, it was nearing completion.  Nevertheless my floppy drive decided to give up the ghost, I am sure out of spite.  As I was desperate to get my upgrade done, I managed to find a replacement case for my chipped case, and also purchased an internally refurbished floppy drive, yes floppy drive!  I have used mass storage on my ST since the 90s, and indeed I did not go for a Gotek, I personally did not want a Gotek for my needs as I am not a fan of these drives in home computers.  If there is an occasion I need to go back to the original source of software, then I actually like floppy disks, which incidentally I have backed up on a couple of hard drives, so will now never lose them.  I also have no need for images, as I can run 99% of my software from HD.  Goteks also look ugly in an ST due to the non standard floppy cut out on the ST casing, even with a bracket, they are just not for me, no, no, no!  I have only seen two Gotek conversions I like, and that was by Robert Tercsi, and now the GOEX by Centurion Technologies.  Hmmm GOEX, I may be tempted by that at some point in time.   Strangely enough though, I don't happen to mind the Gotek in music equipment, idiosyncratic perhaps.  However my opinions aside, the refurbished floppy drive wasn't exactly in sparkling condition, so time to get the floppy drive and STFM case in good condition.


3. Applied white vinegar and left overnight to help de-rust the metal floppy drive case, before scrubbing and applying some rust remover spray.

4.  Not bad, but there is rust still present.

5.  Time to break out the Dremel and apply some metal polish.

6.  That's more like it, much better.  After more polishing however, I decided to give this a spray!

7.  I really did not want to take the floppy drive to bits, so carefully masked up and sprayed with some readily available metal paint.

8.  Spray painting done and masking tape removed.  That's a job well done, quite pleased with the refurbishment of my sourced floppy drive.

9.  Next up, luckily I found an STFM case to replace my damaged case returned by the courier from my failed upgrade.  However it was slightly discoloured, so again time to get busy with the spray paint.  Therefore I masked up the top case.

10.  Similarly I masked up the bottom case.

11.  Many will tell you various RAL colours are a match to the ST casing, ranging from RAL 7044, RAL 7038, RAL 7032 and RAL 7030 to name those which often get mentioned.  I have now performed some testing of these colours and splashed out the money on various RAL paints to get to the bottom of the colours people tend to mention are a match.  I tested RAL 7038, RAL 7032 and RAL 7030.  It was clear RAL 7044 would be too light, so I did not try, given RAL 7038 was already too light and 7044 is lighter.  The categoric answer is none exactly match, it is interesting to finally know the answer, so the only thing you can do is colour match to be exact as possible.  This was also proved and backed up by the company that colour matched my paint who confirmed there is no RAL match.  However you may not be too disappointed with these RALs, depending how particular you are, at least where RAL 7030 and 7032 are concerned.

12.  The bottom casing also painted.  A really nice finish, this is what I was worried about, as the ST case is not a gloss, but not a flat matt which gives a rough finish, it's somewhere in between, in fact exactly the finish my spray painting turned out to be.  Research and preparation is the key if you are not an expert!

13.  Now it is time to re-house my motherboard into its new case.  The motherboard  is now working and recapped with some valuable help, along with the Exxos 230v PSU, Funky PLCC68 adaptor board and BLiTTER, switchable 1MB to 4MB MMU RAM, switchable v2.2 16MHz Booster and Fast ROM, as well as my OverScan ST. 

14.  Finally done, that was a roller coaster project, but happy that I now have what I deem my perfect ST.  I prefer the STFM because of its compatibility with older software, and now I have a newly powered ST, recapped, now switchable between TOS 1.04 and TOS 2.06, 8 and 16MHz, 1MB and 4MB, BLiTTER on or off, as well as OverScan on or off, and in minty fresh condition.

September 2015 - Project Falcon - The Falcon Flies Again 

Time to set up the Atari Falcon.  I had always wanted a Falcon, and managed to acquire a nice conditioned bird circa 2012.  It had no hard drive, so as I finally had the room to set it up alongside the Atari ST, I decided to add a dual IDE to Compact Flash adaptor.

First I managed to find a new Atari Falcon hard drive bracket, thank you Rupert from ST-Freakz, this was key for me.

I then carefully scrutinised and purchased a dual IDE to Compact Flash adaptor, which I wanted to ensure fitted the bracket, as I don't like the adaptors which just flap around inside the case.  As I learned from my father, do a job properly or not at all, and I now endeavour to follow this mantra.

Lastly, after doing a bit of research, I purchased two 4GB SanDisk Ultra CF cards, they also nicely match the adaptor.

1. All parts delivered, including Uwe Seimet's HDDriver.

2. Lined up the dual IDE to CF card adaptor with the internal hard drive bracket and screwed down inside the Falcon.  Inserted the master and slave SanDisk Ultra CF cards, despite the photo, the slave card inserts the alternate way up to the master, and connected the adaptor.

3. Fitted the Atari Falcon case back together, beautiful, easy job done.  The SanDisk Ultra's work with no issues after initially having a problem trying to locate the drive with HDDriver, but after some tinkering, all resolved.

August 2015 - Project  Retr0bright  - Colour Me Bad(d), Oh Dear!

In 2015 I decided to Retr0bright both my spare and actively working Atari STs as follows.


Spare STFM

I took the decision to brighten up my Atari STs.  This was a conscious choice after reading many threads, reading about Retr0bright's potential lasting effects, damaging effects and peoples own opinions etc...  However my opinion, if it is something you want to do, read up on it and educate yourself.  Weigh up the pros and cons and do it.   If it is something you don't want to do, then of course don't take the plunge!

My first experiment I tried a mixture of spray painting and Retr0brighting my spare STFM.  Here are my results:

1. Firstly I cleaned the case, glued up some cracks and began to mask up the top case.

2. Masked up the bottom case.

3. I found a spray paint that seemed to be a reasonable match to 'Atari grey' which I read somewhere, Rust-Oleum Painters Touch Stone Grey.  However since doing this, I have read RAL colour codes that have the potential to be a match to Atari grey are:


4. Sprayed up the top case.

5. Sprayed up the bottom case, not bad!

6. Put it altogether and what do you get?   Hmmm, a dis-coloured keyboard is what you get!

7. Mixed up some Retr0bright, using an old blender keeping to this recipe:

- 500ml of Hydrogen Peroxide 12%.

- Heaped tea spoon of Xanthan Gum.

- 2 table spoons of Glycerine.

- Blended for 1 to 2 minutes.

- Added a flat table spoon of Oxy and blended again for 1 minute.

- Dismantled the keyboard and applied the Retr0bright with a 1" paintbrush, and applied plenty of patience re-applying so not to dry out in the sunshine.  No cling film or any such methods. 

8. Put it altogether and...well not too bad!  It's not a perfect match, and the finish is not quite silky smooth as the ST finish, but good results as an experiment on my spare STFM!

Main STFM

After the lessons learned from spray painting and Retr0brighting my spare STFM, and having some leftover Retr0bight mixture, I decided to Retr0bright my main Atari ST.

1. First I dismantled my Atari and carefully cleaned the motherboard for the first time in 20+ years!

2. I masked up the top case.

3. Masked up the bottom case.

4. I Retr0brighted the keyboard in the same way as in my first experiment, and this time both parts of the ST casing, again leaving all parts in the sunshine, and re-applying the Retr0bright so not to dry out.  Similarly no cling film methods.


5. I washed off the Retr0bright carefully from all of the parts, but not careful enough and damaged my STFM badge.  So as this Atari is special to me, and is 'enhanced' with 4MB, a TOS switcher and OverScan, I thought I would treat it with a 4160 badge.  Sacrilegious, well maybe!  However the results were nice, with no blotching using this Retr0bright method.

Tips

1.  Use a food grade Hydrogen Peroxide.

2. From my experience never use a high percentage (12% max.).

3. Always use a liquid formula, it helps reduce the chances of streaks and blotches.

4. It is important to spend time mixing the formula, and remember mixing the ingredients doesn't produce a magical solution, they only serve to provide a mixture for easy application and to agitate, that's all.

5. The cling film method only serves to keep the mixture moist, it is not needed as it is just an alternate method which for me personally, could encourage a blotchy finish.  In fact I have seen people try so many methods, soaking, baking, it's all a little over engineered.  Stick to the simple methods, but each to their own, if it works for you, then good job.

6. Don't use harsh baths for quick results, although bathing can be safe if diluted.  This leads me onto my final tip.

7. Think about what you are doing, so take it slow, don't rush it and expects good results.  Allow one day, if not two.  I have used this method enough times now to appreciate the results on all manner of objects, from my music gear to trainers, even my dearest mother's kitchen appliances.


Facts

© 2015 - 2021 Atari TOSser. 'All rights reserved' - written content