Compiling a new Atari OS...

[+kheller2]

1 hour ago, reifsnyderb said:

Do you have any thoughts on the use of LED 1 or to just keep it to indicate the keyboard is turned off?

Well, it would be cool if L1 was for D1 and L2 for D2:

Maybe L1 for PBI access (or swap them, L1 for SIO).

 

[reifsnyderb]

2 minutes ago, kheller2 said:

Well, it would be cool if L1 was for D1 and L2 for D2:

Maybe L1 for PBI access (or swap them, L1 for SIO).

 

Making L1 for D1 and L2 for D2 is possible.  But the drives have lights, too.  Using L2 for SIO also covers printer I/O and any other SIO I/O.  (i.e.  Fujinet)

 

The 1200XL doesn't normally have a PBI, though.

 

I briefly considered having L1 used to indicate if the CX-85 system was enabled.  But, that probably wouldn't get used much and is rather obvious.  I don't know that the keyboard disable and screen disable are used enough to make it worth using the LED for, either.

 

Swapping to L1, for SIO, and L2 for something else isn't a problem.

 

One limitation is that it has to be something the OS either controls or goes through the OS.  Another option would be to indicate the OS is in RAM.

 

Any other thoughts? 

 

 

 

 

 

 

[+kheller2]

I was wondering if L2 could be used to denote access to RAM under ROM.  It would be nice if it could be used for RAMDISKs/RAM banks but that option is gone given this only works for systems w/o banked memory.  Or did I misunderstand that?  There are plenty of Rambo 1200XLs out there... and your OS basically is going to turn a 1200 into a 800XL anyway, well, with the right MMU and BASIC.

[reifsnyderb]

Just now, kheller2 said:

I was wondering if L2 could be used to denote access to RAM under ROM.  It would be nice if it could be used for RAMDISKs/RAM banks but that option is gone given this only works for systems w/o banked memory.  Or did I misunderstand that?  There are plenty of Rambo 1200XLs out there... and your OS basically is going to turn a 1200 into a 800XL anyway, well, with the right MMU and BASIC.

This could only be used for 64k systems, yes.  This is because PORTB, bits 2 and 3, are either used for memory banking or the LEDs.  On 1200XLs, with banked memory, the LEDs normally blink due to memory banking.

 

It could be used to show the state of PORTB bit 0 (which is set to 0 if the RAM is being used) but this would only be possible if the OS makes this change or is aware it is running within the RAM under ROM.

 

There is a possibility is to load my OS into the 1200XL's RAM under ROM via a cartridge.  (This is something I am working on right now.)  So, having a LED lit up to show that the OS is running on RAM is a possibility.

 

On 1200XL's, with memory banking, my OS wouldn't attempt to control the LEDs as that would change memory banks.

 

 

 

[_The Doctor__]

LED on when computer has display off and giving full processing speed. Only let it blink or show activity if there is a way to do so without consuming any resources/cycles.

Edited September 8 by _The Doctor__

[reifsnyderb]

7 minutes ago, _The Doctor__ said:

LED on when computer has display off and giving full processing speed. Only let it blink or show activity if the is a way to do so without consuming any resources/cycles.

That's another great option.  There is a key combination the 1200XL has to do that.  (control f2)  It would be easy to tie that in so that the LED is on in that case.

[ACML]

Been following this thread on and off, but it definitely has me intrigued.  Two suggestions for L1.  One is already doable, the other is probably not possible due to size constraints, but it would be cool none the less.

 

1)  Keep F1 to indicate screen OFF.  Also, having L1 indicate the international character set would be a good use.

 

2) Reaching for the stars on this one.  The Fast Math is great, but some software, manly games, require the slowness of the Atari floating point routine.  In a perfect world of infinite space, I know this would take up another 2K, have both floating point routines and L1 would indicate which math FP routine is being used.  Kind of like the old turbo key on our 1990s 286 IBMs.  Is there away to have just the fast math FP routine, but when say F1 is pressed, it puts in a delay to mimic the speed of the old FP routine and L1 signifies the old FP routine?

 

 

Edited September 8 by ACML

[reifsnyderb]

33 minutes ago, ACML said:

Been following this thread on and off, but it definitely has me intrigued.  Two suggestions for L1.  One is already doable, the other is probably not possible due to size constraints, but it would be cool none the less.

 

1)  Keep F1 to indicate screen OFF.  Also, having L1 indicate the international character set would be a good use.

 

2) Reaching for the stars on this one.  The Fast Math is great, but some software, manly games, require the slowness of the Atari floating point routine.  In a perfect world of infinite space, I know this would take up another 2K, have both floating point routines and L1 would indicate which math FP routine is being used.  Kind of like the old turbo key on our 1990s 286 IBMs.  Is there away to have just the fast math FP routine, but when say F1 is pressed, it puts in a delay to mimic the speed of the old FP routine and L1 signifies the old FP routine?

 

 

HIAS High Speed SIO replaces the international character set.  I like your idea about the floating point math routine, and it would be nice to have the option, but there isn't any space.  The floating point math routine takes up 2k of space.  Adding delays would be tricky as there are many entry points to the floating point math routine and there isn't any jump vector table for it.

 

Between Fast Math F+, and Altirra BASIC, there is a huge difference in the speed of BASIC games.

 

 

 

 

 

 

 

 

[reifsnyderb]

On 9/8/2024 at 7:50 PM, ACML said:

Been following this thread on and off, but it definitely has me intrigued.  Two suggestions for L1.  One is already doable, the other is probably not possible due to size constraints, but it would be cool none the less.

 

2) Reaching for the stars on this one.  The Fast Math is great, but some software, manly games, require the slowness of the Atari floating point routine.  In a perfect world of infinite space, I know this would take up another 2K, have both floating point routines and L1 would indicate which math FP routine is being used.  Kind of like the old turbo key on our 1990s 286 IBMs.  Is there away to have just the fast math FP routine, but when say F1 is pressed, it puts in a delay to mimic the speed of the old FP routine and L1 signifies the old FP routine?

 

 

 

I've been re-thinking this one.  I just ported Fast Math F+ to ca65 and compared the binary.  Since the origin is set multiple times, and I used a macro to set the origin, the result of the compile results in a slightly different binary.  I checked the differences, using both the ROMs and the source code, and the only differences are because there are now zeros before each origin change.  The resulting 2k ROM patches into the OS without incident.

 

My thought here is that it may be possible now to add delay loops at either the entry or exit points of each math routine.  When running at high speed, the delay loops are skipped.  When running at "normal" speed, delays are implemented so as to lower the execution time for the sake of compatibility with BASIC programs.  A flag could be used to toggle between high speed and "normal" speed.  This type of delay only would require a small amount of space in the main OS region.

 

I've also found that page zero location $FB is supposed to be either RADFLG or DEGFLG to toggle between degrees and radians.  A search both through Atari's OS source, as related to the floating point routines, and Fast Math F+ shows that it isn't used.  I am thinking that this location could be re-purposed so as to be a flag to toggle the speed.  Setting $FB to $00 would be fast and setting $FB to $80 (or higher) would be normal speed.  This way, high speed would be the default.  A keyboard command, using a function key on the 1200XL, could then be used to toggle the flag and set the LED.  Shift/Help could be the toggle for other XL/XE systems.  (Shift/Help was what Atari used, on later OS versions, to toggle character sets.)

 

 

 

 

 

Edited September 10 by reifsnyderb

[_The Doctor__]

I would double check that the dedicated calculation programs from Atari don't use those flags, even though the OS does not contain the routines the dedicated programs might use those flags. I'd be careful also as the other sweet sixteen stuff may surface one day. Just something to check, not saying it is the case.

[reifsnyderb]

9 minutes ago, _The Doctor__ said:

I would double check that the dedicated calculation programs from Atari don't use those flags, even though the OS does not contain the routines the dedicated programs might use those flags. I'd be careful also as the other sweet sixteen stuff may surface one day. Just something to check, not saying it is the case.

I haven't found any place in the floating point math code that uses those flags or $FB.  I just checked the 1450 XLD source code and it doesn't use it either.  I only found a reference in Fast Math F+ whereby it was no longer used and Mapping the Atari states:

 

251     FB     RADFLG

      Also called DEGFLG. When set to zero, all of the trigonometric functions are performed in radians;

      when set to six, they are done in degrees. BASIC's NEW command and RESET both restore RADFLG to radians.

 

But Mapping the Atari has had some inaccuracies.  Either way, that address is supposed to be reserved for floating point use.

 

All that doesn't mean, of course, that somebody didn't use it for something and then still used the floating point code anyhow.  I also did a search, late last night, and didn't find any place where $FB was suggested as being a usable location for a page 0 address.  Maybe it was hidden in plain sight for all this time?  

 

I'd love to see all the Sweet Sixteen stuff emerge.   🙂

 

 

 

 

 

 

 

 

 

[_The Doctor__]

Did you say the macros are pre pending zero's in the binary code in some recursive manner? That's a space waster and could push things out. Did I misinterpret?

Edited September 10 by _The Doctor__

[drac030]

28 minutes ago, reifsnyderb said:

I haven't found any place in the floating point math code that uses those flags or $FB.

Right, because $FB is used by SIN(), COS(), ATAN() located inside Atari BASIC.

Edited September 10 by drac030

[reifsnyderb]

30 minutes ago, _The Doctor__ said:

Did you say the macros are pre pending zero's in the binary code in some recursive manner? That's a space waster and could push things out. Did I misinterpret?

Yeah, you misinterpreted.  The original code has a lot of ORG statements so as to line everything up.  I replaced them with a FIX macro that fills the gaps with zeros.  There isn't much space wasted.

 

Here's the result of the compile script:

 

 

Edit to add:  I verified all gaps with the source code to make sure they were accounted for.

 

 

 

Edited September 10 by reifsnyderb

[reifsnyderb]

5 minutes ago, drac030 said:

Right, because $FB is used by SIN(), COS(), ATAN() located inside Atari BASIC.

Ok.  It's a flag used by Atari BASIC then?  I'll have to keep looking.  I'd really like to use a page 0 flag so as to keep things a little faster.

[reifsnyderb]

Here's the Fast Math F+ source code as ported to ca65:

 

FastMathFP.asm

[reifsnyderb]

I slightly customized the Fast Math F+ code to permit it to be "throttled" by the OS.  I just need to add some code to KIR to permit the change via the keyboard.

 

Benchmarking, with @drac030 s SysInfo gives the following results for Floating Point testing....

 

Note:  The standard is 100 for an 600XL or 800XL.

 

OS without extra "throttling" code (i.e.  OS 6.19):

Addition:  172

Subtraction:  170

Multiplication:  262

Division:  278

 

OS Pre 6.4 without being "throttled" back:

Addition:  164

Subtraction:  163

Multiplication:  261

Division:  277

 

I was careful to use instructions that limited the number of processor cycles used.  As a result, only 12 extra processor cycles are added to check a flag to see if the floating point math pack should be ran at full speed or not.  Since the floating point math code is packed so tight, this extra code has to be located in the OS.  Had there been extra space, around 1/2 as many processor cycles would have been needed.  So there was a slight performance hit for this extra code. 

 

When OS Pre 6.4 is "throttled" back, the floating point math speed for all benchmarks is 100.

 

Also, I found and fixed an OS bug related to the location of some of the system tables.  So, the next version will have improved software compatibility.

 

 

 

 

 

 

 

 

 

[reifsnyderb]

So far, the next OS is looking good.  I ran some tests running it from RAM on a 1200XL by using the new extender cartridge I put together.

 

One of the tests is the AHL test and I decided to run it both in turbo mode and standard mode.  (The OS boots up in turbo mode.) 

This was also with Altirra BASIC.  (Atari BASIC is much slower.)  The top result is when running in standard mode and the

bottom result was in turbo mode.  LED1 worked fine as a turbo light.  (It is possible for other software to test for banks and for LED1

to get out of sync.  This can be cleared up by toggling turbo mode on and off.)

 

 

MULE loads and runs just fine as well.   😎

 

 

 

 

 

[reifsnyderb]

Fast Math F+ source code as is modified to run on OS 6.4 and above.

FastMath.asm

 

[freetz]

Just out of curiosity, are you still planning to add 1K ATASCIIBlaster or is the remaining space now filled with (understandably) more relevant stuff? 

Just asking because otherwise I'd wait for this before I burn the OS-ROM for the Atari of my kids :)...

[reifsnyderb]

4 minutes ago, freetz said:

Just out of curiosity, are you still planning to add 1K ATASCIIBlaster or is the remaining space now filled with (understandably) more relevant stuff? 

Just asking because otherwise I'd wait for this before I burn the OS-ROM for the Atari of my kids :)...

I was looking into adding the ATASCIIBlaster to the 1090XL OS Extender card.  However, I ran into some issues getting it to run in that environment and didn't continue.  (I did get the sound playing but the video wouldn't come up.  My guess is that it may have taken another day to track down the remaining issue or issues as I couldn't find any obvious reason it wasn't running.)

 

I am still debugging the next OS version and adding an ability for any RAM-based OS loader to pre-set a configuration byte.

 

 

 

 

[freetz]

Ah, right, sorry for mixing the two up! Let me know if there's anything I can help with in case you want to continue with it, but of course I'm also totally fine if that's too much effort.

[reifsnyderb]

Since changing the functionality of Fast Math F+ and re-adding keyboard LED support for the 1200XL seem to be bigger changes, I decided to release this as version 6.40.

 

Changes are as follows:

 

;*      Revision 6.40
;*        Added a scan, upon cold start, to see if RAM banks exist.
;*        Keyboard LED 2, on a 64k 1200XL, now lights up during SIO access.
;*        Set TPFV, NTSC/PAL, and tables at $EE1D to identical memory locations as OSR2
;*          to improve compatibility with other software.
;*        Set tables, starting at $FB04 to identical memory locations as OSR2
;*          to improve compatibility with other software.
;*        Fast Math F+ has been customized so as to be able to have it's speed throttled by the OS.  By default, Fast Math F+
;*          is running at high speed.
;*        Added the capability to slow down the speed of Fast Math F+ so as to run at the same speed of Atari's standard
;*          floating point math pack.
;*        Keyboard LED 1, on a 64k 1200XL, now lights up when Fast Math F+ is running at high speed..
;*        Control/F4, on an Atari 1200XL, and Shift/Help now toggle the speed of the floating point math pack.
;*        OSCFG1 is now set by the value in LNFLG when loaded into RAM.  OS can now be configured upon load.
;*        Brian E. Reifsnyder (9/12/2024)

 

I discovered that SysInfo didn't work and tracked down the problem as being the OS tables need to be at a fixed location.  So, as per the change log, I set the OS tables to a fixed location.  My belief is that any other software, that relies on those internal tables, should now be compatible.

 

OS640.rom

 

OS640.s

 

The modified Fast Math F+ needs patched in after the source is compiled.  I left it like this so that I wouldn't have to go through Fast Math F+ and change all the labels to ensure they are compatible with the OS source.

 

If anyone has any feature requests, please feel free to let me know.

 

 

 

 

 

 

 

 

[reifsnyderb]

I was looking through the AtariMania FAQ about modified OS versions here:  https://www.atarimania.com/faq-atari-400-800-xl-xe-what-modified-versions-of-the-atari-os-were-released_71.html

 

I noticed that many modified OS's had cassette baud rate changes.  While it's probably not a major feature request (lol), I figured I'd add it anyhow.  Tonight, in Altirra, I tested a pre-6.41 OS version at 600 to 1200 baud.  I do understand that speeds above 900 baud may not be practical due to tape drive hardware.  But, why not?

 

The baud rate is "throttled" by setting address 600 with the baud rate.  The baud rate is either the value x 10 or the value x 100 as follows:

 

Baud Rate, Setting:

600,60

650,65

700,70

750,75

800,80

820,82

850,85

900,90

950,95

1000,10

1100,11

1200,12

 

The OS still defaults to 600 baud.

 

 

 

[reifsnyderb]

JMPERS now work with the 800XL Re-make board.   🙂