Live data from Hacker News

Really Atari ST?

os2museum.com

81–90 of 95 posts

Re: Really Atari ST?

#81

Earlier quoted context omitted.

As someone who didn’t grow up with many floppy disks, how was one able to format a floppy to have a different capacity? I know there’s different “formats” such as DOS, C64, etc, but I don’t understand why ? 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.”

The floppy drive has a stepper motor that controls the placement of the read/write head above the disk. 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…

The disk controller chip let you seek track by track. No fine control at all.

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.

Re: Really Atari ST?

#82

I love how every comment here is about the Atari ST instead of what the post is about, which is where the 069H byte check actually came from.

I do too. We have shared history during really interesting and, for most of us, fun times.

Maybe it will always work this way.

Ok fine.

Re: Really Atari ST?

#83
post #78

Earlier quoted context omitted.

Well, that was the problem. Atari had the MIDI (pro music) and DTP from the start. The mono 640x400 monitor - ultra sharp was a great gig. 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…

The upgrade path for the Amiga chipset ended up being complicated. The 500 and 600 had the ECS chips, that allowed some video modes that were not tied to NTSC, at the cost of a reduced palette. The chipset also competes with the CPU for memory access and this second generation chipset addressed more memory, making the computer effectively slower ("chip RAM" was slow, "fast RAM" was the RAM outside the reach of the ch…

> this second generation chipset addressed more memory, making the computer effectively slower

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.

Re: Really Atari ST?

#84
> Me supposes that, like with the ‘CALL 5’ mystery, we’ll learn the truth eventually.

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?

Re: Really Atari ST?

#85

> (ST refers to Sixteen/Thirty-two, referring to the 68k CPU’s external and internal data width) I thought ST referred to Sam Tramiel - Jack Tramiel's son.

Oh boy, reminds me of the time this Atari fanboy accosted poor Sam in the Palo Alto Pizza My Heart and sputtered my confession of love for the ST at him. He looked at me like I was crazy and told me to leave him the hell alone.

Re: Really Atari ST?

#86
Question to the Atari brain trust: which ST emulator is the most accurate one? I have an old ST app I wrote, which prompts a weird message about ‘getting original roms’ or some such before it quits when run on Hatari. I found a printout of the source a couple of years ago in some forgotten basement, and there is a check for Xbios(2/3) or similar before this prompt. No clue what this was about, after 35 years of writing it. If anyone has some pointers, that would be great.

Re: Really Atari ST?

#87
post #10
post #7

The one thing I like the most about the ST (when compared to, say, the Amiga) is its simplicity. It's vastly less capable, of course, but, in the end, the simplicity pays back by allowing easier expansion. The Amiga was a hard machine to evolve, something that cost Commodore a lot.

I got an Amiga and honestly while it was a great machine, a lot of games were written to support the ST as well so didn't use the Amiga's more advanced capabilities. If you were doing video production and graphics work it paid off but frankly I probably would have been just as happy with an ST. Also the ST gets dinged for being less powerful, but it was actually significantly faster than the Mac at the time and with…

I had a Mac ROM cartridge for the ST, which basically turned it into a Macintosh. And Atari had a 640x400 monochrome monitor that looked just like a Mac - an awesome hack.

Re: Really Atari ST?

#88
post #65

Earlier quoted context omitted.

I think that's oversimplified. TOS was single tasking but two things a) unlike the Amiga a proper 68000 syscall TRAP mechanism was used meaning the OS etc ran using proper supervisor / user separation and b) the application toolkit (AES) built overtop supported message passing and multiple application semantics and c) the graphics subsystem (VDI) was also in theory abstracted away from the physical. In fact the OS co…

The Atari ST could do the same kind of cooperative multitasking as GEM on a PC. I built MicroGNUEmacs as a desk accessory so that I could run it at the same time as other programs.

I always found it odd that the GEM environment supported this kind of cooperative multitasking by default only for desk accessories. The API support for doing it more broadly was there, but the desktop and all the applications were written so they would not be. So even when we got proper multitasking support under MiNT there were few/no applications that behaved well in this scenario.

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.

Re: Really Atari ST?

#89
post #6

Earlier quoted context omitted.

Both DOS and Atari used FAT format. The capacity was identical, but MS-DOS would have trouble reading Atari ST floppies because Atari had followed the published standard and wrote two copies of the allocation table to the disk, and MS-DOS would only write one and overwrite the second one with data and corrupt the disk. The 'extra space' was the space that was supposed to be taken by the redundant file allocation tabl…

I didn’t grow up with floppies, so pardon my ignorance, but two questions: (1) which FAT? I figure it can’t be FAT32, but that still leaves FAT12 and FAT16, both of which Microsoft helped develop. And (2) since Microsoft helped develop it, were they just not following their own spec? Because that doesn’t make sense (not that you’re wrong).

MS-DOS was also not the only DOS on the market. DR-DOS was very popular at the time of the Atari ST. As far as I know DR-DOS also followed the published specification and Digital Research (DR) was Microsoft's biggest competition. Atari also used Digital Reasearch's GEM as their "desktop" GUI. GEM was a direct competitor to Microsoft's new Macintosh-killer product called "Windows". CorelDraw and WordPerfect used GEM, MS Word and MS Excel used Windows.

Draw your conclusions.

Re: Really Atari ST?

#90
post #26

Earlier quoted context omitted.

Star Trek: The Rebel Universe looked far better on an ST than on a PC. [edit] Compare: http://www.atarimania.com/st/screens/star_trek_the_rebel_uni... https://www.myabandonware.com/media/screenshots/s/star-trek-...

I've never heard of this game before. Looking it up, its impressive considering the capabilities of then current hardware.

Yea, I still have floppy disk and manual for mine. 256K of ram and no hard-drive required.

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.

Post reply on HN