The Atari ST was designed and developed very quickly. By all accounts it was about a year. That’s is not much time and it meant that some things were not readily available when it finally shipped.
One of these things was documentation. Sure, you could get the Developer’s Kit from Atari itself, but this was a $400 package ($1100 in 2024) that consisted of a C compiler and a bunch of poorly written documentation. That was a lot of money for anyone that was not a professional.
Most of the docs Atari did include were just photocopies of documents from Digital Research about GEM, which were not always directly related to the ST itself. It certainly made learning about the new machine pretty difficult.
Of course, this was still miles better than what the old Atari did when the 400/800 were introduced, which was nothing. Back then, Atari did not release any technical documentation for the computers, preferring to keep it all in-house. If you signed an NDA with them, they would provide materials for you, but you were not allowed to reveal it to the public.
This is why it took so long for Atari 8-bit magazines to appear: no one knew how to program the darn things! Eventually Atari did release De Re Atari by Chris Crawford in 1982 and that opened the floodgates to software and magazines.
At least with the Developer’s Kit, magazines could write about how to program the ST, which was a help. But progress was slow as alternative C compilers were slow to appear.
However in late 1985, things started to change with the release of a variety of new books from Abacus Software. Unknown to those in the Atari world, Abacus was a producer of books and software for the Commodore 64.
In fact, that was a common trend as many Commodore 64 vendors would jump on board with the Atari ST.
These books were actually written by Data Becker, a German company, and published by Abacus. At first, everyone was excited about these books as they looked rather professional and much, much better than the loose-leaf collection of documentation in the Developer’s Kit.
But then the reviews started coming in: the books were not great and had lots of errors. Still, I think they were somewhat popular because there just was not much else at the time. Even the newer C compilers that started appearing did not often have full ST programming docs, so books like these remained necessary.
And the Abacus books did not have any competition until Compute! got into the game with their excellent Technical Reference Guides in 1987.
Personally I did not have the Abacus books back at the time. I only got my first ST in 1989, so by then there was much more information available. I also started with Personal Pascal which had pretty good docs for its custom GEM API. And by then most C compilers also had pretty thorough documentation.
Today I have three of the Abacus books (with links to scans on the Internet Archive):
There were other books as well as the full set goes from 1 through 13.
Of those, I think the only other ones of interest to me are Graphics & Sound (#7), 3D Graphics (#12) and Disk Drives: inside and Out (#13).
I’ve read through the books I have and they are a bit of a tough read, being rather dry. In part 2 of this post I will go over these three books I have in more detail. Be sure to subscribe if you’re interested!
Data Becker was huge in Germany and Austria and you‘d see their rather simple white and red book covers in every computer store and every nerd‘s room. They‘d print books about almost every aspect, I do have one about the ST that came out before the machine was available at retail and basically just described the machine and showed a couple of screenshots, but had no programming info whatsoever. One of their 8-bit books (Atari 800XL PEEKS and POKES or so contained lots of undocumented addresses that the US Atari gurus had warned not to use years before.
Some of the Abacus books can be downloaded from https://archive.org/details/ataristmanuals
Back in the day, I had two of the early Abacus books. Those together with the Megamax C manual got me to where I was developing, in C, final projects for grad school. Then after graduation, I had a unique set of constraints at my job: on PCs, be able to process interrupts with zero latency while also providing a GUI. Because Windows was non-deterministic with interrupts, I sat down with Microsoft C 6.0 for DOS and wrote a GUI from scratch -- mimicking somewhat the GEM API that I had grown so familiar with. Here is what it looked like: https://www.semitracks.com/reference-material/failure-and-yield-analysis/failure-analysis-package-level/figures/acoustic-microscopy-figure-9.gif