Jump to content
IGNORED

Atari Questions about TOS and the TT


Pentad

Recommended Posts

Hello all,

 

I was wondering if anybody knew some answers to some very old questions about TOS and the Atari TT? I was a kid when they came out but now as an adult some of the decisions seem confusing. I teach Computer Science at a university and also do free-lance technology consulting so when I look back I wonder why Atari did what they did.

 

I'm not trying to start a flame war or insult anyone. I'm just trying to understand why Atari made some of their decisions.

 

The first question I had was the design of Atari TOS. I believe that TOS was written on Apple Lisa computers. This would make since given that the Lisa computer was 68k based (not that they couldn't have crossed compiled it). However, does anyone know why TOS uses instructions that are exclusive to the Motorola 68000? I cannot think of a situation where this would have been a great decision since you limit your ability to use future CPUs by the manufacturer (010-060). I know that Motorola would have clearly outlined which instructions were 'legal' and would be supported on revisions of the CPU.

 

Did Atari control the GEM source code in TOS or was that done by Digital and then imported into TOS?

 

With the Atari TT was TOS still developed on another system or was it written on Atari computers by that point?

 

Why did Atari not include a blitter chip with the Atari TT Graphics Workstation? That seemed so counter productive.

 

Does anybody know who the head programmer was for TOS? Maybe a list of the developers of TOS?

 

Thanks!

-P

Link to comment
Share on other sites

Hello all,

 

I was wondering if anybody knew some answers to some very old questions about TOS and the Atari TT? I was a kid when they came out but now as an adult some of the decisions seem confusing. I teach Computer Science at a university and also do free-lance technology consulting so when I look back I wonder why Atari did what they did.

 

I'm not trying to start a flame war or insult anyone. I'm just trying to understand why Atari made some of their decisions.

 

The first question I had was the design of Atari TOS. I believe that TOS was written on Apple Lisa computers. This would make since given that the Lisa computer was 68k based (not that they couldn't have crossed compiled it). However, does anyone know why TOS uses instructions that are exclusive to the Motorola 68000? I cannot think of a situation where this would have been a great decision since you limit your ability to use future CPUs by the manufacturer (010-060). I know that Motorola would have clearly outlined which instructions were 'legal' and would be supported on revisions of the CPU.

 

Did Atari control the GEM source code in TOS or was that done by Digital and then imported into TOS?

 

With the Atari TT was TOS still developed on another system or was it written on Atari computers by that point?

 

Why did Atari not include a blitter chip with the Atari TT Graphics Workstation? That seemed so counter productive.

 

Does anybody know who the head programmer was for TOS? Maybe a list of the developers of TOS?

 

Thanks!

-P

 

On my phone so can't write much now but..

 

TT is not a 68000, nor is Falcon, so your one question is invalid :)

 

TT skips blitter obviously to save money - cutthroat times! Also, the TT was very fast so presumably they thought a business workstation could run on cpu and fastram alone and save blitter fast ram circuitry for later

 

Che k DadHacker blog for a guy who worked on the OS.. Hes talked about a lot of it; GEM was DR but Atari worked very closely, with DR guys on site.. Parallel hacking on the pieces to make them fit well- GEM was not bolted on. TOS was built on ST hardware as soonas could be - wire wraps and incomplete hardware, made coding tough :) I dont think Lisa was involved at all ?

Link to comment
Share on other sites

Atari ST and followers, so TT have not so much similarity with Apple machines - except using 680xx CPUs and WIMP.

TOS has nothing with Apple, Macintosh. It is made by Digital Research, and is called GEMDOS with reason. It is actually pretty much function equialent to DOS on PCs. Not surprise, as DR made his DOS for PCs, + GEM .

Don't see much sense for 'legal' instructions . Later versions are pretty much compatible - except some stack tricks and similar.

Link to comment
Share on other sites

TT is not a 68000, nor is Falcon, so your one question is invalid :)

 

I made a mistake in my post. TOS was rewritten for the TT and Falcon to support the new CPUs. I apologize, I meant to convey that in my post but it was late. :-)

 

I was wondering about TOS 1.x and the 68k.

Link to comment
Share on other sites

The Atari TT isn't a graphics workstation but a workstation. And the blitter isn't really helping there. You can get much better performance from the cpu.

 

Some users have replaced their 68000 with a 68010 and experienced very few to zero problems.

 

 

Are you sure you are remembering this correct? Let me explain what happened when I did this:

 

In 1990, I swapped the 68k for the 010 in both a 520ST and the later 1040ST and neither computer would work. I believe it had an all white screen. Now I know that Amiga folks -and maybe the Mac folks- were swapping out the 68k for the 010 since they were so cheap and a tiny bit faster. I took the issue up with the local Atari Authorized Dealer and Repair Center and asked them. They too thought it should work and tried the 010 on their ST which produced the same white screen.

 

Thinking it might be the CPU we put the 010 in an Amiga 500 which booted right up to the Workbench screen. So it appeared the 010 was working fine.

 

The Atari Dealer/Repair Center then called Atari and they were told by Atari that TOS is not compatible with anything but the 68k because TOS calls instructions that are not in the 68010, 020, 030, etc...

 

I assumed this was correct because on the Mac and the Amiga, you could purchase accelerator boards that would sit in the 68k socket but the board would contain an 020 or above plus other enhancements depending on the money you wanted to spend. On the Atari, the accelerators were 68000 CPUs running at a faster clock rate...maybe some cache for the CPU, but not a CPU > 68k.

 

Later, I swear I read that with the release of the TT and then the Falcon, TOS was rewritten to support new items including the newer CPUs.

 

 

-P

Link to comment
Share on other sites

The Atari TT isn't a graphics workstation but a workstation. And the blitter isn't really helping there. You can get much better performance from the cpu.

 

Some users have replaced their 68000 with a 68010 and experienced very few to zero problems.

 

 

Are you sure you are remembering this correct? Let me explain what happened when I did this:

 

 

 

 

-P

 

It could be that you also need to replace the TOS with 2.06... you should be right.

Link to comment
Share on other sites

For the blitter vs 030 try an unaligned blit and compare the TT speed with the STe blitter. You might be surprised at the results ;)

Remember the ST desktop and most apps cheat and align graphical elements on 8 pixel boundaries for performance reasons.

 

The 010 works fine on TOS 2.x on an STe.

I used it for some time but it did cause problems with hd driver necessitating a switch back to the original.

btw you do know the Amiga 1000/500 isn't 100% compatible with the *vanilla* 68k right? ;)

Try executing TAS from chip RAM and see what happens. Kaboom. It's documented in the hardware reference manual.

 

That instruction would have been handy for thread safety on the Amiga.

 

The biggest mistake Atari made with the TT was not including the blitter IMHO. I agree with you 100% there.

 

A 16 or 32 mhz version would have been nice. Especially if it allowed 100% concurrency with the CPU executing code from fast RAM like the Amiga. ;)

 

The ST blitter has an undeserved bad rep but it's actually quite nice. You can hflip bitmaps with it in four passes or perform magnification.

 

I posted some hardware banging C code demonstrating it on atari forum some time ago.

It's a superset of bitblit. Ie it has halftone support on chip and an indirect addressing mode for "tricks" like the above.

 

There are many things said about the Atari blitter that are wrong. Ie people claim it can't do logical operations, it can't shift (no barrel shifter) etc, no bit boundary support. Check the manual out :) It's different from the Amiga one but Atari didn't screw it up.

 

There are some nice features on the TT. It has a hardware flood fill video mode for instance.

 

The Amiga/ST/Falcon/Archimedes etc are all nice. I'm a big fan.

Frank

Edited by frank1974
Link to comment
Share on other sites

You can find the source code to TOS here: http://dev-docs.atariforge.org/

Well at least some of the major parts, AES, VDI. You can then see for yourself the authors names in the comments in the source files. ;)

 

You can also see the internal code word for the blitter in the source ;)

Atari called it the BLASTER. I think it's reasonably elegant though rather than clumsy or random :D

 

Frank

Edited by frank1974
Link to comment
Share on other sites

Thanks for the info! I guess I should have tried TOS 2.06.

 

Does anybody know if TOS was always developed on the Apple Lisa or did the development tools move to STs/TTs after a few years?

 

I know 'Dad Hacker' mentioned that they used Apple Lisa computers at the start but I wasn't sure if they moved to another platform once the ST launched and the Lisa sort of fell apart.

 

 

Cheers!

-P

Link to comment
Share on other sites

1.4/1.6 is supposed to be 68k CPU independent.

Never tried it though.

 

Not correct. Only at 2.06 there is support for higher CPU versions. Although 68010 and 68012 are upward compatible, there is one case where code will fail: move sr to somewhere instruction. It is not privileged on 68000 but is privileged on higher ones. So, if SW performs such instruction in user mode on 68010 it will cause bombs. In TOS 2.06 and higher ones there is special code to override mentioned case, to make older SW runnable.

Link to comment
Share on other sites

1.4/1.6 is supposed to be 68k CPU independent.

Never tried it though.

 

Not correct. Only at 2.06 there is support for higher CPU versions. Although 68010 and 68012 are upward compatible, there is one case where code will fail: move sr to somewhere instruction. It is not privileged on 68000 but is privileged on higher ones. So, if SW performs such instruction in user mode on 68010 it will cause bombs. In TOS 2.06 and higher ones there is special code to override mentioned case, to make older SW runnable.

 

Move sr.ea is a user mode problem not a supervisor one ;)

If the OS uses this instruction it won't matter.

 

There might not be a handler in the OS to catch user mode progs using it but the OS should run itself ok on > 68000.

Would be an interesting experiment. Next time I'm near my Ste I'll give it a go.

Link to comment
Share on other sites

However, does anyone know why TOS uses instructions that are exclusive to the Motorola 68000? I cannot think of a situation where this would have been a great decision since you limit your ability to use future CPUs by the manufacturer (010-060). I know that Motorola would have clearly outlined which instructions were 'legal' and would be supported on revisions of the CPU.

Seems like you're making a leap of faith to assume that Motorola's docs would clearly outline which instructions were futureproof or not - you'd have to check really.

 

In any case, maybe the compiler version, or the build flags to the compiler happened to use instructions or alignments that turned out to be incompatible with the later chips. The source code to TOS was IIRC about 60%-70% C and the rest assembly. This was apparently one reason why the VDI/AES routines were so slow in GEM applications, leading to third-party improvements like QuickST (or maybe it was TurboST) and NVDI which used optimised assembly for the bottleneck operations.

 

Also IIRC from the superb Dadhacker blog and other articles, wasn't TOS a port of CP/M, with DR's GEM thrown on top? Note that GEM was released standalone for PC DOS as well, and was eventually crippled by a nonsensical Apple lawsuit, although its modern descendants look nice today :)

Link to comment
Share on other sites

 

Move sr.ea is a user mode problem not a supervisor one ;)

If the OS uses this instruction it won't matter.

There might not be a handler in the OS to catch user mode progs using it but the OS should run itself ok on > 68000.

Would be an interesting experiment. Next time I'm near my Ste I'll give it a go.

 

What I said is from experience. And OS not always runs in supervisor mode - for instance AES must run in user mode (except Trapped function handling code). I did not test it because have no 68010 CPU, but for sure that some SR reading must be in AES (Desktop) code.

 

By experience too: most of games works all time in Supervisor mode, so no SR read problem on 68010 should happen. Exception is game Gravity for instance.

I don't get what you want with "Move sr.ea is a user mode problem not a supervisor one ;)

If the OS uses this instruction it won't matter." . We want that all SW run on our machine, isn't ?

 

Btw. there may be other problems with 68010: if it executes some instructions faster than 68000 it may affect timing sensitive code. However, it is mostly demo and game related.

Link to comment
Share on other sites

...

In any case, maybe the compiler version, or the build flags to the compiler happened to use instructions or alignments that turned out to be incompatible with the later chips. The source code to TOS was IIRC about 60%-70% C and the rest assembly. This was apparently one reason why the VDI/AES routines were so slow in GEM applications, leading to third-party improvements like QuickST (or maybe it was TurboST) and NVDI which used optimised assembly for the bottleneck operations....

Actually, graphic code in TOS is done in ASM too. Line-A, VDI ... But surely not the fastest ASM possible. Plus, it is slowed down with inefficient C-type parameter passing.

Link to comment
Share on other sites

The first question I had was the design of Atari TOS. I believe that TOS was written on Apple Lisa computers. This would make since given that the Lisa computer was 68k based (not that they couldn't have crossed compiled it). However, does anyone know why TOS uses instructions that are exclusive to the Motorola 68000? I cannot think of a situation where this would have been a great decision since you limit your ability to use future CPUs by the manufacturer (010-060). I know that Motorola would have clearly outlined which instructions were 'legal' and would be supported on revisions of the CPU.

 

As said, TOS run on 68030 systems (Falcon and TT, and the 040 and 060 upgrades can use TOS as well), so was certainly not restricted to the 68000. A lot of the development work in Atari (and by other developers) was done on a specially produced class "4160" STs factory equipped with 4mb RAM. I'm not sure if they were originally available to the public, but I have seen a few kicking around since.

 

Did Atari control the GEM source code in TOS or was that done by Digital and then imported into TOS?

 

I'm not sure. Atari did not own any *rights* to it, but to what degree it modified for the platform I'm not sure.

 

With the Atari TT was TOS still developed on another system or was it written on Atari computers by that point?

 

I don't know, but I imagine, given the nature of the TT hardware, a lot of work would have needed to be done on prototypes of the system itself, given that it had some unusual hardware. I imagine other 030 systems were needed for more routine work, possibly Apple or SUN systems, or maybe hacked Mega STes, which share some TT hardware.

 

Why did Atari not include a blitter chip with the Atari TT Graphics Workstation? That seemed so counter productive.

Deemed un-neccessary for a business workstation, and the TT was powerful enough that the CPU could shoulder more work.

 

Does anybody know who the head programmer was for TOS? Maybe a list of the developers of TOS?

 

As has been said, there source code is out there with developer names included :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...