Atari OS versions 4 and 5

[+kheller2]

3 hours ago, phaeron said:

 

 

Are there any other versions of the 810 source, or 815/1050? (815 source got posted a while back, but got mangled a bit by the forum.)

 

I posted a complete version of the 815 code back then. If it’s needed to be reposted again I can do that. 

[phaeron]

30 minutes ago, kheller2 said:

I posted a complete version of the 815 code back then. If it’s needed to be reposted again I can do that. 

Ah, I forgot about that. OK, cross off that one. (Unless the mysterious expansion ROM source with the DSDD80 and 38.4K support shows up...)

[Dutchman2000]

Here's a few more.

REVCX.ASM REVE.ASM

[phaeron]

49 minutes ago, Dutchman2000 said:

Here's a few more.

REVCX.ASM 67.03 kB · 2 downloads REVE.ASM 69.79 kB · 2 downloads

REVE.ASM confirmed as a match for 810 rev. E [AAD220F4]. Assembly syntax is very non-standard but got it fixed up enough to assemble a matching binary with MADS.

 

[+kheller2]

@Albert we should probably split this thread starting with the first 810 source code post. So as not to muddy up this OS thread. 

[+slx]

On 5/30/2024 at 9:20 PM, Dutchman2000 said:

 Revision 4, Version 0 (600XL/800XL/1450XLD)

 

        Add support for SIO fast mode (38400 baud).
        Add resident Help Text Viewer.
        Remove Peripheral Handler Loading Facility.
        07/16/84

       

 

Atari OS Rev 4 (600XL-800XL-1450XLD) 7-16-84.rom 16 kB · 36 downloads Atari OS Rev 5 (800XL-800XLF-900XLF-900XLFK) 9-4-84.rom 16 kB · 36 downloads

Anyone in the know on what that removal means and/or why one would want that removed?

[phaeron]

2 hours ago, slx said:

Anyone in the know on what that removal means and/or why one would want that removed?

The Peripheral Handler Loader allows devices on the SIO bus to send their device handler to the computer either automatically (type 3 poll) or on demand (type 4 poll). For instance, you could plug in a device, and have its Q: device automatically install on boot directly from the device. It supports a relocatable format, so handlers can load at any address in memory. While this sounds useful, there are a few problems:

• They aren't supported by 400/800 computers.
• Relocatable handlers load at MEMLO. There is not often much space available there before MEMLO rises too high to run programs, since standard DOS executables are not relocatable. It would have been more useful to relocate handlers high instead of low, except for the complications with screen memory.
• Type 3 polls are mildly useful as they can be used to autorun code after DOS boots, but type 4 polls are useless because they only work if the application leaves memory free at MEMLO and tells CIO that it supports loadable handlers. Which none do.
• And, last but not least... there are precisely zero devices known to have ever shipped with relocatable handler support.

Thus, the peripheral handler loader is pretty much a waste of ~400 bytes in the low OS ROM. Whether the Help Text Viewer is a better use of that space is a different question....

[drac030]

22 minutes ago, phaeron said:

Thus, the peripheral handler loader is pretty much a waste of ~400 bytes in the low OS ROM.

It has to be added that the relocatable loader there is not, strictly speaking, limited to "peripheral handlers", it can be used to load arbitrary binaries in this format from arbitrary storage. IIRC the OS defines a vector where you can store an address of your "get byte" routine and the loader will use it. @trub experimented with that years ago. The trouble here is that no assembler can generate files in this format, and there is no official entry point in the jump table to run the loader (thus e.g. Rapidus OS defines this entry point to be at $E483).

[+kheller2]

What poll type is the 850 R: and 1030 T: ?

[phaeron]

25 minutes ago, drac030 said:

It has to be added that the relocatable loader there is not, strictly speaking, limited to "peripheral handlers", it can be used to load arbitrary binaries in this format from arbitrary storage. IIRC the OS defines a vector where you can store an address of your "get byte" routine and the loader will use it. @trub experimented with that years ago. The trouble here is that no assembler can generate files in this format, and there is no official entry point in the jump table to run the loader (thus e.g. Rapidus OS defines this entry point to be at $E483).

It's not hard to translate into the format if you already have an executable format that supports high and low relocs, but unfortunately few assemblers do. MADS has too many non-standard quirks in its own relocation mode, for instance.

 

That being said, while it's a flexible format -- it supports LDA #<label and LDA #>label, unlike SpartaDOS -- it's not a very good format, being composed of records that are too small for efficient burst loading. Page zero relocation was also a little too fancy. IIRC, the simple low/high/word relocator I use for some of the handlers on the Altirra additions disk is about a third of the size of the relocatable loader in AltirraOS.

 

2 minutes ago, kheller2 said:

What poll type is the 850 R: and 1030 T: ?

850 uses type 0 poll if you start the computer with no disk drives attached, essentially emulating a simple D1:. If a disk drive is present and DOS 2.0 boots, then its default AUTORUN.SYS pulls R: from the 850 with a type 1 poll (command $3F).

 

1030 boots T: and ModemLink via a type 0 poll when booting without disk drives. This uses one of the longest SIO data frames I have ever seen an Atari peripheral use, $2800 bytes. Otherwise, the T: handler has to be pulled using a 1030-specific command (device $58 command $3C).

[reifsnyderb]

3 hours ago, phaeron said:

The Peripheral Handler Loader allows devices on the SIO bus to send their device handler to the computer either automatically (type 3 poll) or on demand (type 4 poll). For instance, you could plug in a device, and have its Q: device automatically install on boot directly from the device. It supports a relocatable format, so handlers can load at any address in memory. While this sounds useful, there are a few problems:

• They aren't supported by 400/800 computers.
• Relocatable handlers load at MEMLO. There is not often much space available there before MEMLO rises too high to run programs, since standard DOS executables are not relocatable. It would have been more useful to relocate handlers high instead of low, except for the complications with screen memory.
• Type 3 polls are mildly useful as they can be used to autorun code after DOS boots, but type 4 polls are useless because they only work if the application leaves memory free at MEMLO and tells CIO that it supports loadable handlers. Which none do.
• And, last but not least... there are precisely zero devices known to have ever shipped with relocatable handler support.

Thus, the peripheral handler loader is pretty much a waste of ~400 bytes in the low OS ROM. Whether the Help Text Viewer is a better use of that space is a different question....

Thanks for laying out these details about the Peripheral Handler Loader.  I was going to remove it from the OS I modified so as to make more space for more useful features and was talked out of it.  It sounds like the Peripheral Handler Loader was a good idea but was impractical.  I also suspect that, at the time, Atari didn't explain how to use it. 

[+slx]

Thanks for the detailed explanations. It’s always interesting to learn about the many ideas the engineers at Atari had, even if they didn’t turn out to be that useful. Sounds like quite an advanced concept for the time.

[+kheller2]

If NOTHING uses it. Yank it.  400 bytes! woo hoo!

Or create a new poll type   

 

[_The Doctor__]

or figure out exactly what it was to be and make it happen.

[reifsnyderb]

4 hours ago, _The Doctor__ said:

or figure out exactly what it was to be and make it happen.

That would imply I start making SIO devices.....when I am a PBI snob.  

 

Edit to add:  Though, if people would be developing SIO devices that make use of the Peripheral Handler Loader, I would be more favorable to keeping it.

Edited June 2 by reifsnyderb

[reifsnyderb]

4 hours ago, kheller2 said:

If NOTHING uses it. Yank it.  400 bytes! woo hoo!

Or create a new poll type   

 

I am thinking this is a strong case to yanking the Peripheral Handler loader as it sounds like it's really impractical from a memory management standpoint.

[pcrow]

It would have been tough for Atari to convince anyone (even their own management) to produce a peripheral that used the feature, as it would be incompatible with the 400/800, which were a significant portion of the installed base for several years after the XL OS came out.

 

That said, FujiNet needs to support this. 

[reifsnyderb]

1 hour ago, pcrow said:

It would have been tough for Atari to convince anyone (even their own management) to produce a peripheral that used the feature, as it would be incompatible with the 400/800, which were a significant portion of the installed base for several years after the XL OS came out.

 

That said, FujiNet needs to support this. 

Then FujiNet would be incompatible with the 400 & 800.

[pcrow]

2 hours ago, reifsnyderb said:

Then FujiNet would be incompatible with the 400 & 800.

Well, I was mostly joking.  Though it wouldn't be a horrible feature to have as an option.  I'm not sure what it would be useful for, but having an auto-load that doesn't rely on the disk image is an interesting idea.  If the load process includes calling an initialization routine, then it could really do pretty much anything.  I never knew this feature existed until this thread, so I find the whole thing intriguing.

[reifsnyderb]

1 hour ago, pcrow said:

Well, I was mostly joking.  Though it wouldn't be a horrible feature to have as an option.  I'm not sure what it would be useful for, but having an auto-load that doesn't rely on the disk image is an interesting idea.  If the load process includes calling an initialization routine, then it could really do pretty much anything.  I never knew this feature existed until this thread, so I find the whole thing intriguing.

A 1090XL card could do an auto-load.  It has a ROM that can be auto executed upon boot-up.

[+kheller2]

15 hours ago, pcrow said:

Well, I was mostly joking.  Though it wouldn't be a horrible feature to have as an option.  I'm not sure what it would be useful for, but having an auto-load that doesn't rely on the disk image is an interesting idea.  If the load process includes calling an initialization routine, then it could really do pretty much anything.  I never knew this feature existed until this thread, so I find the whole thing intriguing.

Wouldn't you be doing the same thing the 850 and 1030 do when no disk is present?

 

[Kr0tki]

On 5/30/2024 at 9:20 PM, Dutchman2000 said:

       Here are versions 4 and 5 of the Atari 8-bit OS, I'm not sure if these were already out there or not so here they are with notes. These were compiled from source code found on a tape backup of the Data General mainframe HCD used.

 

        Revision 4, Version 0 (600XL/800XL/1450XLD)

 

        Add support for SIO fast mode (38400 baud).
        Add resident Help Text Viewer.
        Remove Peripheral Handler Loading Facility.
        07/16/84

        Revision 5, Version 0 (800XL/800XLF/900XLF/900XLFK)

 

        Revert to Rev. B device handlers (E:, C:, P:, S:, K:),
        (with bug fixes) to eliminate need for Translator.
        Remove parallel I/O support.
        Fix keyboard display in self-test.
        09/04/84

 

Atari OS Rev 4 (600XL-800XL-1450XLD) 7-16-84.rom 16 kB · 42 downloads Atari OS Rev 5 (800XL-800XLF-900XLF-900XLFK) 9-4-84.rom 16 kB · 44 downloads

Thank you very much! I guess I'm gonna need to update my OS source package pretty soon. 🙂 Be aware though - after assembling the OS ROM, its checksum values at $C000-$C001 and $FFF8-FFF9 should be set to proper values, and the checksums in your ROMs are left unset. Without the checksums, the OS will go straight to Self-Test upon booting.

 

Another, more important issue, is that your Rev. 5 ROM does not exactly match the OS 5 sources published years ago by Curt Vendel. May I ask you to repeat the "ask and ye shall receive" procedure and provide the OS 5 sources of yours?

[Dutchman2000]

Here are the ASM, IMG and Dataio files of OS REV 5. 

OS.ASM OS.DIO OS.IMG

[thorfdbg]

On 6/2/2024 at 12:09 PM, kheller2 said:

What poll type is the 850 R: and 1030 T: ?

None of the above. The 850 reacts as disk drive if no other disk is found on the serial chain, or reacts as device $50 on the command '?' to read boot parameters. It responds with the bytes to be placed into the DDEVICE and following ($300).

[+kheller2]

7 hours ago, Dutchman2000 said:

Here are the ASM, IMG and Dataio files of OS REV 5. 

OS.ASM 319.24 kB · 9 downloads OS.DIO 44 kB · 8 downloads OS.IMG 64 kB · 8 downloads

The ASM looks to be the same as Curt's.  but that binary you provided is not.