picoPSU Atari ST replacement guide
I just did a writeup on how to replace the original PSU in an Atari ST/E with a modern picoPSU . I’m quite satisfied with how it came out - click the link for some pretty pictures ;)
38 words
1 minute
PLCC 44 PROM programming with TL866
Even the retro world is moving away from the regular DIP packaging sometimes. The Atari Falcon, and third party ROM boards from Exxos, use the 27C4096 PROM in PLCC packaging to hold TOS (the operating system). The TL866 with its DIP40 socket cannot obviously handle these, but a quick search shows us that there exists many adapter packages available to purchase that will sort out various types of popular socket formats. Including 44 pin PLCC. However, the most common such adapter isn’t meant for PROMs, but for micro controllers (like the AT89C51 used for the example below). While the pin assignment is almost the same, for the critical purpose of programming the NC pins are swapped. $ minipro -p AT27C4096@DIP40 -r test.bin Found TL866A 03.2.86 (0x256) Invalid Chip ID: expected 0x1E00F400, got 0xFFFFFFFF (unknown) (use '-y' to continue anyway at your own risk) If we want to program PROMs with this adapter, we need to perform a slight modification.
208 words
1 minute
Update 2021-07-14: Ben of The Overlanders commented on my Facebook post that there was yet another optimization possible on the depack-routine. I have edited the source listing below.
1439 words
7 minutes
The Atari Mega ST keyboard - finally exposed
When people talk about the Atari ST range of computers, most mean the common form factor of the times where the computer and keyboard were all one unit. This was true for most of Atari’s machines - but for a few exceptions. The Mega ST, the Mega STE and the TT went for a more “business look”, which apparently meant separation of computer and keyboard. The Mega ST computer has a fantastic “pizza box” style, while the Mega STE and TT share a common … something else.
882 words
5 minutes
The tale of high density Atari mystery
The Atari ST, like other computers at the time, had Dual Density disk drives with 720KB of storage. DD for short. Since High Density (1.44MB) appeared shortly after, Atari used such drives in the more top of the lines models Mega STE and TT. Additionally, us enthusiasts and hardware hackers added HD capability to the regular ST and STE range since it was neat to store twice the amount of data on suitable disks (and it worked pretty well cutting a hole in DD disks tricking the drives into thinking they were HD, even though the magnetic layer is slightly different). All the above is of course very well known. However, recently I’ve managed to dig up some less well known information as well as adding new discoveries about our dear 30 year old hardware. This is a post about that. Atari used several different makes of DD drives in the ST computers, but one of the more common is the Epson SMD-380. For the higher end models with HD support Atari however used one model exclusively, the Epson SMD-340. For after market HD modifications of ST:s one drive in particular became quite popular, the Sony MPF-920. If you search online for kits and instructions, that’s the drive you’ll find the most info on. It’s not only the drive that decides whether to write in Double Density or High Density however. The data needs to be clocked faster through the drive onto the disk, and so it’s not enough just swapping in and out the drives mentioned above to choose between DD and HD support. A neat little trick is that the floppy controller used by Atari, the 1772 (made by WD and VL), outputs a DD capable signal when clocked at 8MHz and HD when clocked at 16. In a regular ST it’s always clocked at 8MHz, and in the Mega STE and TT Atari used carefully tested chips that could do 16MHz (and later elected to produce a variant themselves, known as the AJAX chip, that was designed to run at 16). The way to get HD support in a regular ST is thus to clock the floppy controller at 16MHz when writing/reading an HD disk. I might be misremembering, but I think my own first HD mod needed manual selection through a switch and so I needed to select the right position depending on the disk I used. A much better option is of course to ask the drive if there’s a DD or HD disk inserted, and switch clock speed depending on that. This is what’s well documented for the Sony MPF-920 and is how the many different “HD kits” know what to select. Now here’s where things start to get confusing. In many places you can find documentation to the effect of pin 2 of the floppy interface being a density select signal. An output. While that might be true for some drives, my research says that it’s an input . The Atari Mega STE and TT (the Epson 340 drive) does not get told whether there’s an DD or HD disk in the drive, and yet they still have full support for both formats. This part of the mystery took me to an old discussion thread from 2008 which seems to be the first time someone actually looked into how this was done. There’s a memory mapped register, handled by a PAL chip, that the Atari operating system (TOS) writes to to set the clock frequency of the floppy controller. The logical conclusion is thus that TOS switches frequency when encountering errors and retries. In that sense, the after market ST mods did a much better job. The drive told a piece of circuitry what it should use and the clock frequency was then set correctly. Many many ST top cases have been horribly butchered to make room for the normal eject button of most HD drives instead of Atari’s nice slanted cutout. Of course, I wanted to make my tricked out STE (see other posts) read HD disks as well, since I spend a lot of time archiving lost treasures and sometimes come across HD disks. I did not want to butcher the top casing though. Idea: Use the same HD drive as Atari. The front plate and eject button of the Epson 340 and 380 are interchangeable, and the Epson 340 can still be found used online (and after some digging I found that it was also sold by Hewlett Packard under their brand as D2035-60011). I also bought an HD-kit from exxos that seemed to handle some obscure effects (steprate issues) adding HD to ST:s can cause.
1199 words
6 minutes
TL866 firmware updater macOS support
I own a TL866CS IC programmer . Wonderful device - I truly recommend it (and I assume its successor is even better). It’s been known for many years that the company who made them had one hardware revision, and limited the CS revision compared to the A revision purely in firmware. That limitation has of course been hacked for almost as long as the device has existed. Someone going by the name “radioman” detailed many years ago how the bootloader could be reflashed from CS version to A , after which the original software and firmware updates will see the device as the A model in all aspects. To get access to the in-circuit programming abilities, you additionally have to solder a header to the mainboard . radioman’s software is open source, and exists for Linux (QT) and Windows (.NET/QT). People say it works great under parallells or VirtualBox for macOS users. But that’s no fun, is it? I spent the last week changing out libudev for macOS’ native IOKit library in the QT codebase. That’s the only change needed, since libusb has good macOS support. My macOS pull request has now also been accepted and merged into master by radioman. Open source working as intended. And my TL866CS has become a TL866A.
Apple · Code · Development · English · Retro
213 words
1 minute