Really Atari ST?
os2museum.com
os2museum.com
[EDIT ADD] Ok had a dig around and the tool most used was Fastcopypro - https://sites.google.com/site/stessential/disks-tools, was useful to do fancy formats for extra capacity if you had good quality discs as well as copying/backing up discs
The rule was if you wanted to move files between systems, you had to format the floppy on MS-DOS, then you can use it everywhere. If you formatted on the Atari and used it on MS-DOS, you would end up using it nowhere.
Draw your conclusions.
Thinking back on it now, I'm surprised that I didn't damage the disk with the heat of the iron. Then again, maybe I did and didn't notice because I was 12.
Did I lose files on fake doublesided disks? Yes. Did I lose files on real doublesided disks? Also yes.
Totally worked. Capacity increased. Until one day your files were corrupted. And that day often came soon!
Might have been that brand. I remember seeing what it did and then figuring out how to get a hole in the 3.5" disk without cracking the plastic.
I have heard about how formatting a floppy involved placing the tracks and how modern hard drives have “hard sectors”, but for some reason, it’s not “computing.”
Then there was sectors, which was common to have 8, though again you could with better quality discs (quality did get better ahead of the standards) you could go with 9 sectors and higher - https://www-user.tu-chemnitz.de/~heha/basteln/PC/usbfloppy/f....
Of course, you could think of it as over-clocking - was no guarantee you get that extra capacity, and the early days - it was really luck, but like most things, quality improves and such avenues of formatting became more accessible.
In the ST era, the control of that motor was directly under the control of the operating system. For an 80 track disk, the movement required to step between tracks was a certain known amount.
If you formatted the disk with the tracks spaced closer together, by altering the stepper movement during that process, you would 'magically' get more space.
No, it was under control of a stepper motor driver circuit located directly on a Floppy drive pcb. This driver in turn received instructions from a dedicated Floppy drive controller (WD1771 and compatibles).
> For an 80 track disk, the movement required to step between tracks was a certain known amount.
"certain known amount" being one step per track
>If you formatted the disk with the tracks spaced closer together, by altering the stepper movement during that process, you would 'magically' get more space.
Above is incorrect.
Its impossible to move HEAD stepper motor between tracks. Floppy drive has a STEP (/STEP) and DIRECTION (/DIR) pins. All you are able to do is pick direction and step one track at a time. Step distance is Fixed. The whole point of using a stepper motor is you dont have to worry about head tracking/alignment.
The only personal computer Floppy drives with flexible head positioning all used voice coil head actuator - Floptical, LS-120/240, Zip drives etc.
You could format extra tracks, if you felt lucky. Usually you could get away with couple extra. I never did this with any files I valued.
I recall the default format was 9 sectors, 80 tracks, 2 sides with 512 bytes per sector = 720KB, and you could push up to sometimes 82/83 tracks and maybe 10 or 11 sectors to get more out of a diskette.
Actually, I think my ST originally came with a single-sided floppy drive and had to be upgraded.
Sad thing was, due to the early single sided models, many games would limit to 720k so as to not limit there market. That saw games that would happily fit upon a single double sided disc, cast upon two floppies forcing switching. So that small batch of single sided initial release systems, really did have a legacy impact that lasted for years and did it no favours.
The standard 720KB 3.5' floppy disk as used by the Atari ST used 80 tracks of 9 sectors.
With these tools you could format with, say 11 sectors instead of 9 and boost capacity to 880KB (I think the Amiga was doing that as standard).
[1] https://en.wikipedia.org/wiki/List_of_floppy_disk_formats
Edit: another unrelated practice was buying up cheap(er) single-density disks, which were distinguished by the lack of a marker hole opposite the r/o protection slider, and used only one side of the medium for data. By drilling it out, one could trick the drives into using both sides, which usually worked out just fine. Mentioned here [1]
Spinwrite still exists, though in the early days/versions it was the golden tool for tuning up a system and could make huge differences. Like double your drive speed and more in some instances, but talking late 80's early 90's here when interleaving was thing and mid 90's 1:1 became the norm and made it moot. https://www.grc.com/Spinrite.htm
But I still love it. Without the ST I wouldn't have discovered programming and all the highs (and lows) that it brings. Looking back now, I'm surprised people were able to get as much out of it as they did.
Also memory was much better organized than Amiga - without the speed penalty.
And the simplicity of Shifter (the "GPU") allowed for really awsome 'beyond the dream' hacks, which were unavaliable on Amiga due to much more capable - but limited in 'hacking' video chip.
And then the first upgrade - Atari STE - amazes today with full control 8-channel 50kHz MODs... While mc68k CPU stayed at 8MHz!
I will follow you down the ages, through age extension tech, uploading of consciousness, to the eventual universe spanning one mind!
Always I will appear, always I will prevent your foolish, unjust and untrue claims from spreading unchecked.
Amiga is better ; she is the best. Your Atari smells of milk!! Amigas rule!
(what part of early computing culture did not have inane fan wars?)
It was the Falcon who had incredible sound capacity with its matrix channel mixer and DSP.
When we talk software mixing, STE maxed out CPU at 8 channels 50kHz, here's an example: http://yerzmyey.i-demo.pl/YERZMYEY-Octopush_ATARI_STe.mp3
Even plain 520 ST can do a lot on this YM chip.
Amiga 500 on the other had could a bit of this but only with 12kHz samples, and no volume control per channel, also those pesky filters.
Amiga 1200/4000 could do same - as per much faster CPU, but... they still left the old audio 8-bit chip in it :/
Other packages (DBE tracker?) allow the STE to play 32channel mods albeit not at 50Khz
All Amigas except the A1000 could turn the high-pass filter off, and pretty much everything tended to do this.
[edit]
Compare:
http://www.atarimania.com/st/screens/star_trek_the_rebel_uni...
https://www.myabandonware.com/media/screenshots/s/star-trek-...
Although to be fair CGA wasn't intended to be used on monitors. It was intended to be used on smeary composite video sources where you could expand the palette using artifact colors. Even then the graphics were terrible, but you could at least get a green.
It definitely required you to have lost many times before you could complete it though; the galaxy was too large for you to explore fully in the time granted by the mechanics.
The actual substance of the article is neat, but I don't have much to say about it beyond that...
Maybe it will always work this way.
Ok fine.
Also the ST gets dinged for being less powerful, but it was actually significantly faster than the Mac at the time and with an add-on could even run Mac applications.
I never even had a colour monitor for my ST. The paperwhite monochrome screen was to die for back then, and sure beat the interlace hi-rez experience on the Amiga.
And the ST was a few hundred bucks cheaper. Price per mhz, it was a great machine.
My take is that both the Amiga and the Atari had a plethora of expansions and, without having any numbers to show, I think the Amiga won out in the expansion race, from 040 cards for the A500 (AFAIK no 040 was available for any Atari until much later) to the Video Toaster.
Both machines were hard to evolve because both their designs encouraged software that was tightly tied to the hardware. VIDEL and AGA were both desperate and, ultimately, fruitless attempts at having the cake and eating it: sticking to custom chips was needed to keep backwards compatibility, but they made the machines both too expensive and too underpowered to be competitive.
Additionally, having the copper, sprites, scrolling, HAM and planar graphics modes meant that backwards compatibility is harder - just look at the difficulty of emulation for both of them.
The Amiga graphics layout is also (slightly) more difficult to work with, there's a trick for the ST to do quick chunky-to-planar (C2P) conversion, check out the texture mapping in Thunderdome demo (http://www.pouet.net/prod.php?which=64503)
All said, yes the Amiga had more expansion cards for it, but the central bus system was a bottleneck as for the majority of Amigas, you had to use the built-in graphics, if you look at the a1200, the AGA chipset was a poor upgrade over the original chipset, hampered by backwards compatibility and the expense to needing to add a separate (fastram) bank to bypass the system bus for speed.
As far as retargetable graphics goes (ie. VGA-style cards), the ST was ahead as GEM allowed this from the start. That combined with the much simpler design allows a newer machine to be much more powerful as it has to worry about backwards compatibility less.
The Atari Falcon bears this out, a stock Falcon can manage to run Quake2 at 10FPS odd, a stock a1200 even with fastram can't get close. The Falcon was actually developed using an ST with a processor socket, bearing out the simpler architecture could be abused more :)
TBH the Falcon could have been much more, but Atari were broke and cheaped out on the 16bit bus, could've had 24bit VIDEL at 800x600 and run Quake2 at 15-20FPS for £500 in 1992. Add a cdrom with multiTos (effectively unix with a GEM frontend) and you'd have a competitive machine even against the PC of the time.
Amiga went the road of being console turned computer, and the expansions only created havok with support. Even A500 Plus had issues.
Sadly - it also affects community - the IP rights for Amiga are mess, the recent issue with Terrible Fire extensions - for some reason a lot of bad blood in a very bold and interesting system made by Atari engineers.
And, of course, there was what seems like a cocaine-fueled endless sequence of management blunders that drove the company into the ground.
ECS could address more chipmem but wasn't slower than OCS. You couldn't add fastmem in the trapdoor port, but that didn't matter much since those expansions weren't good enough to impact the speed (trapdoor fastmem was usually called slowfast). The problem was rather one of incompatiblity: some programs written in the 512+512 kbyte era simply assumed they could allocate fastmem, which typically wasn't available on the 500+ and 600.
> After ECS came AGA, which pushed the boundary further again (but, at this point, memory constraints were not so terrible).
AGA, like ECS, could address 2 megs of chipmem. However, it had higher bandwidth and was much faster than ECS.
My point is that even though the ST/e was, as you say, a simpler design in many aspects, Atari still had to equip the Falcon with a YM chip and put support for planar 15 kHz video in VIDEL to maintain backwards compatibility. They faced the same problem as Commodore: their machines were mainly home computers used for games and other software that banged the metal and people expected this to work when upgrading. They also shared a lot of the same problems when upgrading the architecture even slightly, such as with the A3000 and TT030: programs that didn't work with newer versions of TOS/DOS and programs that didn't work with 020/030.
Both platforms are expandable with things like RTG graphics cards, sound cards, CPU cards etc. (in fact I'd argue the Amiga architecture with Zorro, video slots and CPU daughterboards was designed to be vastly more expandable than the Atari) but for most users that didn't matter: if the games they wanted to play didn't work, what point was a 24-bit display that cost more than the computer itself?
Besides, even without keeping backwards compatibility, rolling your own silicon was no longer a viable option financially. Tramiel's vertical integration was a good idea in the 1980:s but the hardware market had shifted. Commodore could've made a triple-A machine but it still wouldn't have been competitive, neither in price nor in performance. The niche markets utilizing the unique features of Atari (MIDI) and Amiga (DTV) weren't large enough and a new architecture that would deprecate all or most existing software (and many peripherals) used by hobbyists would probably only serve to push the home user base towards the PC anyway.
These things meant that later the Atari community and Atari themselves were able to extend the OS in a proper multitasking almost Unix-like direction (MiNT and MultiGEM) and bring it to new hardware, and new display formats and architectures, etc. Provided the applications being run were cleanly written (well, that's a big caveat...). For example -- we can now run TOS/GEM on an Amiga, that's pretty neat (though totally pointless).
In true Tramiel fashion they shipped the cheapest simplest thing they could. But it was something they were able to iterate on -- unfortunately they just did this too slowly. As others have pointed out, the Amiga had amazing hardware from the go, but its architecture became somewhat tied to that original hardware. It was more like a video games console than a workstation. They had a few years headstart on everyone else and then having (then dated) specialized hardware became a liability, not an advantage.
I built MicroGNUEmacs as a desk accessory so that I could run it at the same time as other programs.
I never saw uemacs compiled as a DA. That would have been a nice trick. The only microemacs I used on my ST was not a windowed application, was console only.
I chose the MicroGNU variant as it did parenthesis matching better than the alternatives. I ran it alongside Franz Lisp that I had also made into a GEM application.
That's triply dumb, because of the typo noted in the article, and also because executable Atari ST bootsectors had a checksum that should be computed instead of silly heuristics, but most importantly because most Atari ST disks had no executable bootsector, but the entries concerning disk layout were still valid.
It sounds exactly like the fractal of incompetence Microsoft would implement, and it would explain why we Atarians had to use disks formatted on a PC for data transfer, even though the formats were nominally the same. Funny to read about that, because back in the day, I thought the ST somehow formatted disks "wrong".
TOS was tolerant of both big and little endian FAT
While MSDOS tolerated only little-endian.
However the GEM desktop's formatting utility formatted big-endian only.
So to get a floppy readable on both you formatted under MSDOS. Or used a better formatting utility on your Atari that let you choose little endian mode.
My dad and I don't have what you might call compatible decision making processes, so there were many times I was disappointed by his decisions growing up. But that machine taught me DOS, the next one got me onto Windows (answering the question, "How could I possible fill up a 43 Megabyte hard drive?") and those got me my foot in the door at one of the best jobs I ever had.
I'm still a little jealous of all of the Atari and Commodore fans out there, that I didn't get to participate. But if I'd had my way I would probably be worse off and still not be able to participate because I don't think anyone but me has ever mentioned the Adam unless I fished for it. Kids are dumb.
This "CALL 5 mystery" sounds interesting, but I couldn't find anything about it. Perhaps somebody who knows what it's about would have more luck?
I thought ST referred to Sam Tramiel - Jack Tramiel's son.
I wrote this code in the ST BIOS. It's been 35 years, and I don't remember all the details, but I'm pretty sure it was a "Hail Mary" and was not well tested. It appeared to work, and we moved on to more important things. Certainly our really small QA staff (or 5-6 people? certainly less than 10) was not testing it. And we definitely had more important things to make work.
We put the ST together in about ten months; that was from absolutely zero software and no hardware to being available on shelves in stores. I still don't know how we did it. Most of us were working 80-100 hour weeks (and the software people like me were living away from our families, working with Digital Research in Monterey on finishing GEM and porting stuff over).
Every few years I run into Derek Mihockha and he gives me grief about this, and then smiles.