Compiling a new Atari OS...

[reifsnyderb]

26 minutes ago, ivop said:

That's Radeon I guess, so it should do OpenGL.

 

Nice. GDI is slow though. It would be better to get Direct3D9 or 11 working.

 

Sorry, that dpkg command was to find out which package installed glxgears

 

Install it with your package manager or with apt-get install mesa-utils.

 

 

Edit: you can check /var/log/Xorg.0.log to see which driver X.org loads and see if the GLX module is loaded.

 

$ less /var/log/Xorg.0.log

 

and grep (with my output shown)

 

$ grep -i glx /var/log/Xorg.0.log
[    12.359] (II) "glx" will be loaded. This was enabled by default and also specified in the config file.
[    12.359] (II) LoadModule: "glx"
[    12.361] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[    12.371] (II) Module glx: vendor="X.Org Foundation"
[    12.534] (==) NOUVEAU(0): GLX sync to VBlank enabled.
[    12.819] (II) Initializing extension GLX
[    13.037] (II) AIGLX: Loaded and initialized nouveau
[    13.037] (II) GLX: Initialized DRI2 GL provider for screen 0
 

I installed mesa-utils and  /gdi is no longer needed.

 

There isn't a Xorg log under /var/log.

 

Thanks!

[reifsnyderb]

15 minutes ago, kheller2 said:

For OS starting points you basically have two places to start from:

BB000001 Rev. 2 (1983-05-10) [XL]

or

BB000001 Rev. 3 (1985-03-01) [Late XE] / BB000001 Rev. 4 (1987-05-07) [XEGS]

 

Incorporating some of the changes from BB000002 Rev. 3 (1984-03-27)  might be useful.  But I would not venture into any other 14xx revision as the others appear to be designed for the TONG board booting, and then M. Barrall went and did a lot of additional work on other features.

You could do the CIO #0 fix, move the device handlers around to their B location etc.. (but that might break XL OS games that violated the same standards and the B people),

fix the 130XE memory test, and if you are going to keep the selftest keyboard then the layout should be modified to re-include F1-F4.

 

Note that REV 4 has a fast SIO mode ... take a look at how that was done.

 

 

BB000001 Rev. 4 (1987-05-07) might be the best place to start to support the most computers.

 

I saw there is a version with fast SIO code.  However, they also removed PBI support.  So I didn't pursue it figuring that space was made for fast SIO code by removing PBI support.

 

The TONG board booting appears to only be the addition of support for internal PBI devices.  While it doesn't take up much space, I didn't put it in as I doubt anything out there uses it except for a few prototypes in the wild.

 

Are you thinking F1-F4 support should be kept?  My thought was that it appears people serious enough about a 1200XL to modify it probably banked the memory....thereby making some of the F1-F4 support unnecessary.  Maybe F1-F4 support should only be in the self test?

 

What I ended up doing was to take the XL/XE OS R.3 and incorporate missing fixes that had been added to the OS R3 1450XLD OS.  I was thinking about starting with the XL/XE OS R.4 and decided against it because the primary change is to make it keyboard aware.  It wouldn't be hard to do a diff between my current source and see if the keyboard aware code could be re-added. 

 

Either way, I still need to get the current version to both compile and link.....

 

 

 

 

 

 

 

 

 

 

[ivop]

55 minutes ago, reifsnyderb said:

I installed mesa-utils and  /gdi is no longer needed.

 

There isn't a Xorg log under /var/log.

 

Thanks!

I suppose installing mesa-utils pulled in all the GLX dependencies. Not sure why you don't have an Xorg log file, but I guess it's no longer needed as you now have OpenGL working, which is what Direct3D is mapped to by wine

Edited February 13, 2023 by ivop

[reifsnyderb]

30 minutes ago, ivop said:

I suppose installing mesa-utils pulled in all the GLX dependencies. Not sure why you don't have an Xorg log file, but I guess it's no longer needed as you now have OpenGL working, which is what Direct3D is mapped to

Well, the video could be better as it's a little "shaky".  But, it's usable.   🙂

 

Edit:  I just adjusted the video settings, in Altirra, and it's great!  Also, the Atari OS, prior to working on support for the Fast Math, is now working in Linux, on Altirra with wine.   🙂

 

Edited February 13, 2023 by reifsnyderb

[ivop]

1 hour ago, reifsnyderb said:

Well, the video could be better as it's a little "shaky".  But, it's usable.   🙂

 

Edit:  I just adjusted the video settings, in Altirra, and it's great!  Also, the Atari OS, prior to working on support for the Fast Math, is now working in Linux, on Altirra with wine.   🙂

That's good to hear Pretty strange that Ubuntu didn't install the GLX libraries with a default installation.

[+kheller2]

2 hours ago, reifsnyderb said:

I saw there is a version with fast SIO code.  However, they also removed PBI support.  So I didn't pursue it figuring that space was made for fast SIO code by removing PBI support.

 

The TONG board booting appears to only be the addition of support for internal PBI devices.  While it doesn't take up much space, I didn't put it in as I doubt anything out there uses it except for a few prototypes in the wild.

 

Are you thinking F1-F4 support should be kept?  My thought was that it appears people serious enough about a 1200XL to modify it probably banked the memory....thereby making some of the F1-F4 support unnecessary.  Maybe F1-F4 support should only be in the self test?

 

What I ended up doing was to take the XL/XE OS R.3 and incorporate missing fixes that had been added to the OS R3 1450XLD OS.  I was thinking about starting with the XL/XE OS R.4 and decided against it because the primary change is to make it keyboard aware.  It wouldn't be hard to do a diff between my current source and see if the keyboard aware code could be re-added. 

 

Either way, I still need to get the current version to both compile and link.....

 

 

 

While I haven't dived into the code, I always get confused between "internal" and "external" PBI devices.  They are all PBI devices, are they not?  Remember, the stock XL OS works just fine in a 1450 with speech and modem.  There were modifications done for how to handle booting when the drive door was open or closed, and how to transfer data in general to a PBI floppy.  

 

The reason I mentioned using the XEGS code is because there are apparently a lot of XEGS's with bad OS ROMs, and well, a nice working one for them would be great.  Semantics really. 

 

Compile and Link?  well... on my Mac I type "make" after installing the appropriate cc65 etc..  (I know you know this. 😀).  I have no idea how to do anything on Windows.  I gave up on that OS after XP and have been strictly UNIX and Mac since at least the early 00s.

[reifsnyderb]

1 hour ago, kheller2 said:

 

While I haven't dived into the code, I always get confused between "internal" and "external" PBI devices.  They are all PBI devices, are they not?  Remember, the stock XL OS works just fine in a 1450 with speech and modem.  There were modifications done for how to handle booting when the drive door was open or closed, and how to transfer data in general to a PBI floppy.  

They are all PBI devices.  While documenting the PBI, I found a couple addresses reserved for internal devices.  They are $D1CF and $0254.  Revision 3, Version 2, of the XLD series source code has them.  I suppose it's possible they weren't used anyhow.  The idea is kind of redundant.

1 hour ago, kheller2 said:

 

The reason I mentioned using the XEGS code is because there are apparently a lot of XEGS's with bad OS ROMs, and well, a nice working one for them would be great.  Semantics really. 

It shouldn't be too hard to put the XEGS code back in, if necessary.  I just confirmed the only difference between OS R. 3 and OS R. 4 is the support for the external keyboard and built-in game.

 

1 hour ago, kheller2 said:

 

Compile and Link?  well... on my Mac I type "make" after installing the appropriate cc65 etc..  (I know you know this. 😀).  I have no idea how to do anything on Windows.  I gave up on that OS after XP and have been strictly UNIX and Mac since at least the early 00s.

I was keeping Windows around mainly for games.  It was nice to have a 2 minute boot-up time this morning, though.  Maybe I'll start shutting my computer off at night.

[reifsnyderb]

What is a "Peripheral Handler Loading Facility"?  Is it used?  Why were they able to remove it?

 

I found a note about the XLD R4. OS:

 

2.4.6. Rev. 4 (unknown signature) (1984-07-16)

Called "Revision 4, Version 0" in the source comments.

Another revision for the 600XL/800XL/1450XLD that did not go to production, it is the first one dated after Jack Tramiel bought the Consumer division of Atari, Inc. from Warner on 1 July 1984. It was developed by Michael Barall and contained the following changes:

Add support for SIO fast mode (38400 baud).

Add resident Help Text Viewer.

Remove Peripheral Handler Loading Facility.

 

The web page is:  https://seriouscomputerist.atariverse.com/media/htm/Atari 8-Bit OS - Read Me.htm

 

Edit:

 

 

I found this description in the source code.  I am still unclear as to why it could be removed....

 

 

*    Subroutine to load, relocate, initialize and open a
;*    "provisionally" opened IOCB. This routine is called
;*    upon first I/O attempt following provisional open.
;*    It does the final opening by simulating the first
;*    part of a normal CIO OPEN and then finishing with
;*    code which is in CIO.

 

 

Edited February 13, 2023 by reifsnyderb

[HiassofT]

4 hours ago, ivop said:

Not sure why you don't have an Xorg log file

The default desktop on Ubuntu is GNOME and that uses Wayland instead of Xorg for a while now - hence no Xorg log files.

 

so long,

 

Hias

[_The Doctor__]

battery back up ups... then you won't kill your' crap, you can shut down, or have it shut itself down safely enough

 

Edited February 14, 2023 by _The Doctor__

[reifsnyderb]

34 minutes ago, _The Doctor__ said:

battery back up ups... then you won't kill you crap, you can shut down, or have it shut itself down safely enough

 

Now you tell us.  🙂

[+kheller2]

1 hour ago, reifsnyderb said:

What is a "Peripheral Handler Loading Facility"?  Is it used?  Why were they able to remove it?

 

I found a note about the XLD R4. OS:

 

 

Remove Peripheral Handler Loading Facility.

 

The web page is:  https://seriouscomputerist.atariverse.com/media/htm/Atari 8-Bit OS - Read Me.htm

 

Edit:

 

 

I found this description in the source code.  I am still unclear as to why it could be removed....

 

My guess would be the ability to auto download the 850 R: and P: handlers and the 1030 Terminal program when you boot those devices (instead of a disk).  

[_The Doctor__]

Polling and handler download, XLD would have it's own serial and parallel ports internal modems and drives, you could still do SIO bins for devices if you liked as not all facilities for that are gone. That's my take/story and I'll be happy thinking just that

[reifsnyderb]

Sounds like a good idea to keep that "Peripheral Handler Loading Facility" then.  My thought was to leave it in.  But, I figured I'd ask.

[phaeron]

The peripheral handler loading facility allows devices to supply their own device handler in response to an automatic type 4 poll from CIO on a device it doesn't recognize. In theory, this means that you could attempt to access Q:, and the handler for the Q: device would automatically be downloaded from the device. There's an entire infrastructure for downloading relocatable code over SIO and hooking it into the OS.

 

In practice, this requires both a device that responds to type 4 polls and software that supports handling the notification from CIO that a handler needs to be downloaded. AFAIK there are zero instances of either in the wild. I had to write custom versions of both to test a reimplementation of the peripheral handler loader. If you were to remove the peripheral handler facility, you would have difficulty finding anyone who noticed, and if you were to keep it, to actually exercise it.

 

The one gotcha is that there is a small utility routine associated with the handler loader that needs to be kept. The vector is $E486 (PENTV) and it is used to install new CIO handlers in HATABS, even without the handler loader.

 

[reifsnyderb]

17 minutes ago, phaeron said:

The peripheral handler loading facility allows devices to supply their own device handler in response to an automatic type 4 poll from CIO on a device it doesn't recognize. In theory, this means that you could attempt to access Q:, and the handler for the Q: device would automatically be downloaded from the device. There's an entire infrastructure for downloading relocatable code over SIO and hooking it into the OS.

 

In practice, this requires both a device that responds to type 4 polls and software that supports handling the notification from CIO that a handler needs to be downloaded. AFAIK there are zero instances of either in the wild. I had to write custom versions of both to test a reimplementation of the peripheral handler loader. If you were to remove the peripheral handler facility, you would have difficulty finding anyone who noticed, and if you were to keep it, to actually exercise it.

 

The one gotcha is that there is a small utility routine associated with the handler loader that needs to be kept. The vector is $E486 (PENTV) and it is used to install new CIO handlers in HATABS, even without the handler loader.

 

Perfect!  Thanks!  That sounds like it's reasonable to remove to free up some space.  It also sounds like another area where Atari was years ahead of it's time.

[_The Doctor__]

What poll type does Fujinet respond to?

[reifsnyderb]

Well, I am a little new to 6502 assembly language....but I have figured a few things out.  Since the international character set appears to be needed, I figured I'd add the Shift/Help toggle as was in Arabic XL OS.  The 1200XL control key code has been re-added.  I ended up re-organizing the Keyboard IRQ code in the process as it was rather messy.  Also, the source code for the Arabic XL OS had the Control/F4 disabled due to the Shift/Help toggle.  I guess they figured they didn't need it.  So, that's what started the re-org of the code.  For the time being, I put aside the Fast Math code as I got stuck on a compiler/linker error that I can't yet find a solution for.  I'll paste it back in when I figure it out.

 

So, here's the changes so far:

 

 

;*        Revision X (600XL/800XL/65XE/130XE)
;*        Added the following fixes and changes from Revision 3 (600XL/800XL/1450XLD) through
;*            Revision 3, Version 4  (600XL/800XL/1450XLD)
;*
;*          Fix TXEB table for XE banking.
;*            Added IDCPU back to First 8k ROM Identification and Check
;*            Fix initial address for RAM sizing to $4000 (16k).
;*            Fix initial address for equivalence cartridge checksum to $BF00.
;*            Correct mishandling of NAK.
;*            Initialize PDVS to zero.
;*            Accept device number 0 (like revision B did)
;*        BASIC loaded when Option key held down.
;*        Processing of CNTLF1 through CNTLF4 no longer affects PORTB.
;*        Shift-Help now toggles international character set.
;*        Reduced KRPDEL from 48 to 20 for NTSC and from 40 to 20 for PAL.
;*        Reduced KEYREP from 6 to 4 for NTSC and from 5 to 4 for PAL.
;*      Brian E. Reifsnyder    02/14/2023

[reifsnyderb]

The Peripheral Handler Loading Facility has been removed and initial Altirra testing looks promising.  On the surface, nothing looks broken, anyhow.  (M.U.L.E. runs....what more could you want?   🙂   )

 

I didn't give this a revision number, yet.  So, I just called it "X".

 

When I remove something from source code, I always comment it out first and permanently remove it later.  So, here's the latest source:

 

source.s

 

Here's the rom:

 

testos.rom

 

I'll look at adding in Atari's high speed SIO changes next.  It looks like what they did was rather rudimentary and limited to 38,400 baud.  But it would be an improvement.  I don't have any hardware to test it on, though, as my 1050's are unmodified.

 

Once I add Atari's high speed SIO changes, I'll put it on an EPROM and test on real hardware.

 

A thought I had was that given the special function key features of the 1200xl, it would be nice to have some of them on other Atari's.  (i.e.  The screen display toggle to speed up processing?)  However, I don't know of any usable key combinations that would never conflict with something else.

Edited February 14, 2023 by reifsnyderb

[reifsnyderb]

Ok.  Following the source code and adding Atari's 38,400 SIO wasn't bad.  I've just been comparing Atari OS source code that has the feature to the branch I am working on and adding it in.  The peripheral needs to support it, of course.  Also, I don't have a good way to test it.  So, if somebody is willing to test, that would be great.

 

Here it is:

testos.rom

 

Changes thus far:

 

;*        Revision X (600XL/800XL/800XE/65XE/130XE)
;*        Added the following fixes and changes from Revision 3 (600XL/800XL/1450XLD) through
;*                Revision 3, Version 4  (600XL/800XL/1450XLD)
;*          Fix TXEB table for XE banking.
;*            Added IDCPU back to First 8k ROM Identification and Check
;*            Fix initial address for RAM sizing to $4000 (16k).
;*            Fix initial address for equivalence cartridge checksum to $BF00.
;*            Correct mishandling of NAK.
;*            Initialize PDVS to zero.
;*            Accept device number 0 (like revision B did)
;*        Added the following changes from Revision 4, Version 0 (600XL/800XL/1450XLD)
;*            Removed Peripheral Handler Loading Facility.
;*            Add support for SIO fast mode (38,400 baud).
;*        BASIC loaded when Option key held down.
;*        Processing of CNTLF1 through CNTLF4 no longer affects PORTB.
;*        Shift-Help now toggles international character set.
;*        Reduced KRPDEL from 48 to 20 for NTSC and from 40 to 20 for PAL.
;*        Reduced KEYREP from 6 to 4 for NTSC and from 5 to 4 for PAL.
;*      Brian E. Reifsnyder    02/14/2023

 

 

I am thinking it would be useful to display the OS version on a self test screen....

 

[Mathy]

Hello Brian

 

2 hours ago, reifsnyderb said:

The Peripheral Handler Loading Facility has been removed ...

...

A thought I had was that given the special function key features of the 1200xl, it would be nice to have some of them on other Atari's.  (i.e.  The screen display toggle to speed up processing?)

 

Damn.  PHLF sounds like a very nice feature to have.  If it's one of the things where Atari was way ahead of it's time, why remove the possibility to use it?  Who knows, maybe we can use/load OS extensions with it.  Guess what would have happened if somebody years ago had removed PBI support.

 

I've been reading articles on how to add the F1-F4 keys to non-1200XLs since Atari 8 bit specific magazines were available in stores way back when.  So all those features (F1-F4, Shift-F1-F4 and Ctrl-F1-F4) should just work on any other XL/XE(GS) that still has the OS Atari put in to it at the moment the computer was manufactured.

 

Sincerely

 

Mathy

 

 

[reifsnyderb]

20 minutes ago, Mathy said:

Hello Brian

 

 

Damn.  PHLF sounds like a very nice feature to have.  If it's one of the things where Atari was way ahead of it's time, why remove the possibility to use it?  Who knows, maybe we can use/load OS extensions with it.  Guess what would have happened if somebody years ago had removed PBI support.

I figured that since it was never used, there isn't any hardware to use it, and I doubt anybody would ever make hardware to use it, that it would be ok to remove to make space for something else.  I'd think the way to add any OS extensions would be to do something like what they did with the 850 or to use a PBI card.  Either way, I do save incremental versions of my changes.

 

Edit to add:  Given what I've gone through documenting the PBI interface, it may be even harder to document the PHLF and I don't recall ever reading anything about it.

 

Edit to add:  Atari was so far ahead of it's time.  Many of the features they had were 10 to 15 years ahead of PC compatibles.  There were no IRQ jumpers, DMA jumpers, address jumpers, config.sys files, and application configuration settings to deal with.  It  was true plug and play.

 

20 minutes ago, Mathy said:

I've been reading articles on how to add the F1-F4 keys to non-1200XLs since Atari 8 bit specific magazines were available in stores way back when.  So all those features (F1-F4, Shift-F1-F4 and Ctrl-F1-F4) should just work on any other XL/XE(GS) that still has the OS Atari put in to it at the moment the computer was manufactured.

Do you have any thoughts as to what keys they used in place of the F1-F4 keys?  It wouldn't be hard to add that support back in....especially since I cleaned up that rat's nest of spaghetti code that was used for the F1-F4 handler code.  Personally, I'd love to see some of the keys available.  For example, Home and cursor to start of physical line would be useful.

Thanks!

 

Brian

 

 

 

Edited February 14, 2023 by reifsnyderb

[_The Doctor__]

Hard to say since it just works is how such a thing is expected to act. Very few ever dig deep enough to realize it, but you are treading on USB territory with PHLF. Would one consider that higher SIO rate and burst mode might make PHLF a bit more useful. Since so very few ever heard of it, and knew even less about it, it's now being brought to the spot light, this invariably leads to folks not only making use of it, but finding ways to abuse it so they can get some crazy wonderful result. I think I see where @Mathy is coming from. A tough undertaking of OS modification without hampering things.

[reifsnyderb]

9 minutes ago, _The Doctor__ said:

Hard to say since it just works is how such a thing is expected to act. Very few ever dig deep enough to realize it, but you are treading on USB territory with PHLF. Would one consider that higher SIO rate and burst mode might make PHLF a bit more useful. Since so very few ever heard of it, and knew even less about it, it's now being brought to the spot light, this invariably leads to folks not only making use of it, but finding ways to abuse it so they can get some crazy wonderful result. I think I see where @Mathy is coming from. A tough undertaking of OS modification without hampering things.

If space wasn't an issue, I'd leave it in.  Without it, there is now almost 1k of usable space in the OS.  My thinking is that if we compare this to the PBI, I removed something that is completely undocumented and has never been used.  Then, when I look at the PBI documentation that was available before I compiled it, I found so many errors that took it days of study, and a few false starts, to figure out.  (Admittedly, I could have still missed something.)  Since we have so few hardware developers, I doubt anyone will miss it.  I'd love to be proven wrong, though.

 

Another thought is that keeping the PHLF in would be like making a 8MB memory card that is completely unsupported by any software available.  Could something be written to use it?  Sure.  Will more than one or two people want it?  Probably not.

 

Edit to add:  Atari did, eventually, remove PBI support too.  😞

 

So, that being said:  What would be more useful to add that would be something cool to have now?

Edited February 14, 2023 by reifsnyderb

[reifsnyderb]

Ok.  It's running on my 600XL with my 64k PBI upgrade.  (PBI memory doesn't need PBI support in the OS.)