Compiling a new Atari OS...

[reifsnyderb]

2 hours ago, MVladimir said:

Thank you, Brian!

Nice to read so qualified answers.

This project is great, waiting for stable release.

Tonight, I started looking into how the Hias patch works as opposed to Atari's high speed SIO and can't find any evidence the Atari method was ever implemented in hardware.  The Altirra Hardware Reference Manual does even refer to any method that Atari implemented in their OS.  As a test, I tried setting up a US Doubler in Altirra.  There was no difference.  That's when I started looking into the Altirra Hardware Reference Manual for more details.  I've also been studying the readme file with the Hias patch and the Atari high speed SIO is completely different. 

 

While writing this, a thought occurred to me that maybe Atari's high speed SIO patch was really for the internal drives used with the 1450XLD.  I think the 1450XLD drives worked through the parallel bus but I also believe that parallel drives still use the SIO code within the OS.

 

I'll start looking into a way to incorporate better high speed SIO support in a future release of the OS.  (i.e.  6.1)

 

Brian

 

[_The Doctor__]

Atari High Speed SIO for XF551 and for 14XX drives, might also extend to other devices and burst transfers maybe. Some putzing about would be needed for understanding how it is supposed to work and how it really works.

[reifsnyderb]

18 minutes ago, _The Doctor__ said:

Atari High Speed SIO for XF551 and for 14XX drives, might also extend to other devices and burst transfers maybe. Some putzing about would be needed for understanding how it is supposed to work and how it really works.

That's a good idea.  Using Altirra, I just tried the XF551 vs a "standard" Altirra disk drive (whatever that is) and there was only a tiny speed difference with the XF551.  I am thinking the XF551 should be almost twice as fast if high speed SIO is involved.

 

Atari's high speed SIO method involves whether or not the OS receives an ACK or a HSACK signal from the drive.  If there is an HSACK signal, it runs at 38,400 baud.  Meanwhile, it appears almost every other high speed SIO involves the drive responding to a $3F command to get it's speed then the SIO is set to that speed.  Atari's implementation does not involve asking the drive the speed.

[_The Doctor__]

try DOS XE and Patched SpartaDOS 3.2X(from XF utils I've put on the forum who knows when ago, that will let you hear and see the difference including SIO reset for density switching on the XF551. It intentionally tries not to switch so copy protected software will still run, people thought it was a major mistake and changed the eproms to 'fix' density issues. Later on people found they could switch density handily by reset and forcing the switch during boot up.

The important part is the SIO speed change method though.

 

Altirra has to have all the real timings and setting made including roms for some devices in order for it to give real world speed comparison, it already makes almost all drives a bit faster evening the speed differences out. So accurate timing et all has to be set and done.

[phaeron]

The XF551 does not have track buffering, so it is dependent upon the disk being formatted with a different interleave for high-speed operation to have an effect. With a standard interleave, the gain from the faster transfer will simply be absorbed by additional time to wait for the next sector to arrive underneath the head. An XF551 cannot read or write consecutive sectors on such a disk any faster than an 810 or 1050. It is possible to read such a disk faster with high speed SIO by requesting the sectors out of order from the computer side based on the interleave pattern, but this is an advanced trick limited to specialized disk copiers.

 

In Altirra, an ATR disk image will always be loaded by default with a standard 9:1 interleave for SD/DD or 13:1 interleave for ED since there is no sector timing information in the image. You either need to format a new disk or reinterleave an existing disk image through the menu on the disk drive entry to see the high-speed difference. ATX images can save the interleave and thus persist the speed difference.

 

The 1450XLD uses an SIO-like protocol for framing but does not use the SIO bus, so baud rates don't apply to it. The 1450XLD firmware also has no support for formatting with a faster interleave, so it appears that Atari never got to the point of taking advantage of the speed of the parallel bus interface (which can handle as fast as 2:1 interleave).

 

[reifsnyderb]

6 hours ago, phaeron said:

so it appears that Atari never got to the point of taking advantage of the speed of the parallel bus interface

This is what I am thinking happened. 

[+kheller2]

The Atari 1050CR (Cost Reduced) floppy drive used the H response. It was being worked on around the same time as the OS (September 84) by Mike Barall.  Since that is probably the only device that would use it it should probably be removed from the OS and something more common put in.  I'm not sure about the XF351 command set, but that was the precursor to the XF551 and from threads here at AA, the code is similar between the two.  I think, but am not sure, that the 1050CR = Atari 1053.    There are 1055 prototypes out there, but I don't think anyway has ever dumped the ROM.  [Don't get confused, the 1055 is the 3.5" SSED drive, the 1053 is the 5.25 DSDD -- backwards from what one would assume the numbers mean.]

 

The 1050CR:

 

PERSEPHONE MINI/MICROFLOPPY DISK CONTROLLER

 

*       This program is the controller for the Atari 1050 CR (cost
*       reduced) minifloppy disk drive and for a possible future
*       microfloppy disk drive.  It resides in the ROM of an
*       Intel 8050 microcontroller.  It's function is to accept
*       commands from the Atari serial bus and to execute them by
*       driving a Western Digital 1770 FDC chip.

...

*       Original Author Mike Barall 09/11/84

 

..

* 48    SET SIO SPEED
*
*       Change SIO baud rate to the rate specified by auxiliary byte
*       #1 (00 = 19200 baud, 01 = 38400 baud).

 

* 72    GET COPY PROTECTION SECTOR
*
*       Step to the track number (0-39) specified by auxiliary byte #1
*       on the first side of the disk and read sector F7.

...

 

*       Byte 10 = SIO bus speed:
*               41 = 19200 baud
*               48 = 38400 baud
*

 

....

**      SIO TIMING

*       At 19200 baud, one bit time is 27.78 CPU cycles (which we
*       take as 28 CPU cycles).  At 38400 baud, one bit time is
*       13.89 CPU cycles (which we take as 14 CPU cycles).

*       The controller is responsible for generating the following
*       delays:
*

 

....

 

*       t5 = delay between transmission of last bit of ACK and
*            transmission of first bit of CMPLT
*               t5 min = 250 us (19200 baud), 750 us (38400 baud)
*               t5 max = 255 sec (handler dependent)

 

 

[reifsnyderb]

21 minutes ago, kheller2 said:

The Atari 1050CR (Cost Reduced) floppy drive used the H response. It was being worked on around the same time as the OS (September 84) by Mike Barall.  Since that is probably the only device that would use it it should probably be removed from the OS and something more common put in. 

This makes perfect sense, now.  I'll get that patch removed and plan for more common high speed SIO handling on version 6.10.

[Caterpiggle]

Hello reifsnyderb,

 

Never mind. I found it the solution ! I have to manual to add the "testos.rom" by "add" click ! 1088K memory on 130XE and it passed ONLY on whole 3 rows then it fallen into glitches display . Wow ... At the end of 3rd row , when it finished the last 3rd row, then glitches ....

 

Is that normal for your "testos.rom"'s limitation ?

Edited April 9, 2023 by Caterpiggle

[reifsnyderb]

1 hour ago, Caterpiggle said:

Hello reifsnyderb,

 

Never mind. I found it the solution ! I have to manual to add the "testos.rom" by "add" click ! 1088K memory on 130XE and it passed ONLY on whole 3 rows then it fallen into glitches display . Wow ... At the end of 3rd row , when it finished the last 3rd row, then glitches ....

 

Is that normal for your "testos.rom"'s limitation ?

It glitched?  Is this on the memory test or somewhere else?  Please provide a description of how to reproduce this and a screenshot.  Thanks!

 

Brian

 

[reifsnyderb]

For now, I am leaving Atari's high speed SIO patch in.  I'll have to map out the entire SIO system before I do anything.  My thought is that some of Atari's high speed SIO code could be adapted for the high speed SIO hardware that was actually used.

 

Given that some expanded memory upgrades result in the expanded memory bank no longer working, I am going to put some verification bytes into the self test bank.  If these verification bytes aren't found, the self test won't load.  This should prevent some crashes in the event the self test bank isn't available.

 

[tzok]

Hiasoft's High-Speed SIO patch is de-facto standard, and using XL OS without it is non-acceptable for many people. This was the main reason for popularity of the QMEG OS. So if I can suggest something, please prioritize including that highspeed-sio routines.

[reifsnyderb]

2 hours ago, tzok said:

Hiasoft's High-Speed SIO patch is de-facto standard, and using XL OS without it is non-acceptable for many people. This was the main reason for popularity of the QMEG OS. So if I can suggest something, please prioritize including that highspeed-sio routines.

I've been studying how the high speed SIO patch works and plan to get it working.  My current thought is that it will be a goal for version 6.10.  Since I don't have any high speed SIO devices, I have to rely on Altirra to verify functionality.

 

 

[tzok]

Good and inexpensive DIY high speed SIO device, which is really worth to have is SDriveMax.

[MVladimir]

Let's think about compatibility. Not everyone has high-speed devices and memory expansions. But OS bug fixes, Option key reversal, keyboard shortcuts added, a simple speed patch, a fixed math package that works with BASIC and TurboBasic are likely to be needed by many owners of standard, unmodified computers.
I think that we need to have two OS modification branches.
One can stop at the current version and define it as "for standard computers". It probably needs to be improved a little, to return the memory check up to 128K to the test part, and probably something else.
The other can be further developed with attention to high-speed devices, memory expansions and other modifications.
Unfortunately, I am not a programmer, I can only state my vision of problems in words.

[reifsnyderb]

17 minutes ago, MVladimir said:

Let's think about compatibility. Not everyone has high-speed devices and memory expansions. But OS bug fixes, Option key reversal, keyboard shortcuts added, a simple speed patch, a fixed math package that works with BASIC and TurboBasic are likely to be needed by many owners of standard, unmodified computers.
I think that we need to have two OS modification branches.
One can stop at the current version and define it as "for standard computers". It probably needs to be improved a little, to return the memory check up to 128K to the test part, and probably something else.
The other can be further developed with attention to high-speed devices, memory expansions and other modifications.
Unfortunately, I am not a programmer, I can only state my vision of problems in words.

My thoughts on an improved OS is that it should be improved to the maximum capability that was possible within the boundaries set by a 16k ROM, the computer's capabilities, and with due consideration of what devices were available at that time.  This OS should also have every bug fix known included as part of the OS.  Finally, and most importantly, software compatibility needs to be maintained.  So, that sets the overall goal of this project.

 

Admittedly, certain goals have been established and other goals have been a little "flexible".  Some goals have changed based upon an improved understanding of why certain OS changes were made.

 

I believe the goal of having all of Atari's OS bug fixes merged into a single OS have been met.

All of Atari's "reasonable" improvements have been added as well.

Software compatibility appears to be good.  However, if any software relies upon non-vectored OS calls, it will break.  But this is not unexpected.

 

The fast SIO patch goals have changed based upon my an improved understanding that what Atari was working on was not the same as what was done by 3rd parties.  That being said, I have been studying Hias's documentation and I don't think it will be very hard to support high speed SIO devices, at "non experimental levels", within an improved OS.  (By "non experimental levels", I mean speeds that would be possible without extreme measures, such as modifying the system board.)  I do need to improve my understanding as to how the SIO system works, however.  I also think Atari's changes can be extended to handle 3rd party high speed SIO support.  It appears to be just a matter of querying the device to determine what the Pokey divisor needs to be.  The device may also need to be told to run at the higher speed.

 

The memory test is a problem, however, in that some memory expansions are just not compatible with having a self test system.  While I'd really like to keep the XE memory test, and spent a lot of time on it, having the self test crash due to a different memory expansion is poor.

 

Because of the issue with an incompatibility between memory expansions and the self test banking, I am planning to add a simple test to ensure that the self test bank is really there prior to executing the self test.  I may also move the ROM test code to the self test bank.  I think a ROM failure would be fairly obvious, anyhow.

 

My thought in regards to having two versions is that most people will probably never change their OS.  People who have made certain upgrades, run high speed SIO devices, have extended memory, etc., will be more interested in exploring another OS.

 

Best Regards,

 

Brian

 

 

 

 

 

 

 

 

 

 

 

 

[MVladimir]

17 minutes ago, reifsnyderb said:

I believe the goal of having all of Atari's OS bug fixes merged into a single OS have been met.

All of Atari's "reasonable" improvements have been added as well.

Software compatibility appears to be good.  However, if any software relies upon non-vectored OS calls, it will break.  But this is not unexpected.

 

My thought in regards to having two versions is that most people will probably never change their OS.  People who have made certain upgrades, run high speed SIO devices, have extended memory, etc., will be more interested in exploring another OS.

The two versions are not quite a correct understanding of my question.
There is only one version, but let's just say - if what is now enough - we use beta3, if more is needed - the next versions. That is, having slightly supplemented beta3 with previously excluded and corrected test options, to say that it is an edited stable system and can be used as a replacement for the original version 3.
That's what I meant by compatibility with the system I currently have on my computers.
I do not have extensions and high-speed devices, but sometimes crashes due to errors of the original system are annoying.
Please try to make beta 3.1 - it will be the same as the original one with a rewritten Self Test page and additions. And this will be a certain completed stage in the work.
Sorry for some persistence......

[tzok]

38 minutes ago, reifsnyderb said:

The memory test is a problem, however, in that some memory expansions are just not compatible with having a self test system.  While I'd really like to keep the XE memory test, and spent a lot of time on it, having the self test crash due to a different memory expansion is poor.

 

Because of the issue with an incompatibility between memory expansions and the self test banking, I am planning to add a simple test to ensure that the self test bank is really there prior to executing the self test.  I may also move the ROM test code to the self test bank.  I think a ROM failure would be fairly obvious, anyhow.

PORT B bit 7 is used by most (all over 256kB) memory expansions, but in conjunction with bit 4.

[Ricky Spanish]

So i guess this isn't for the 1200XL with it's dual ROMS & no built in basic ?

[reifsnyderb]

3 hours ago, MVladimir said:

The two versions are not quite a correct understanding of my question.
There is only one version, but let's just say - if what is now enough - we use beta3, if more is needed - the next versions. That is, having slightly supplemented beta3 with previously excluded and corrected test options, to say that it is an edited stable system and can be used as a replacement for the original version 3.
That's what I meant by compatibility with the system I currently have on my computers.
I do not have extensions and high-speed devices, but sometimes crashes due to errors of the original system are annoying.
Please try to make beta 3.1 - it will be the same as the original one with a rewritten Self Test page and additions. And this will be a certain completed stage in the work.
Sorry for some persistence......

It sounds like we are mostly in agreement but just looking at this from different angles.  The only disagreement appears to be about the extended memory test. 

[reifsnyderb]

1 hour ago, Ricky Spanish said:

So i guess this isn't for the 1200XL with it's dual ROMS & no built in basic ?

It should work with the 1200XL.  My belief is that the ROM would be compiled then split in 2 8k sections...one for each 1200XL ROM.  I don't have a 1200XL to test this on, though.

 

Edit to add:  The 1200XL function keys are part of the keyboard test and will appear if they are pressed.

Edited April 10, 2023 by reifsnyderb

[Mathy]

Hello guys

 

I guess the high speed code has a feature where high speed can be forced to be off.  I know the UltraSpeedPlus OS by CSS/Bob Puff has this feature.  Some software will refuse to run when loaded faster than a standard 1050 will do.

 

Sincerely

 

Mathy

 

[Ricky Spanish]

2 hours ago, reifsnyderb said:

It should work with the 1200XL.  My belief is that the ROM would be compiled then split in 2 8k sections...one for each 1200XL ROM.  I don't have a 1200XL to test this on, though.

 

Edit to add:  The 1200XL function keys are part of the keyboard test and will appear if they are pressed.

Hopefully it'll work. I like what I'm seeing and this'll gimmie an excuse to buy the U1MB ha-ha. 

[kenames99]

I would just want the self test to do what the original does. base 64K memory, keyboard, and music thing. those passing should allow the computer to boot. anything beyond that should be the domain of other hardware test programs, cuz, at this point the system is running and able to load those other programs.

 

Ken

 

my $0.02

 

[reifsnyderb]

I am going to call this release OS 6.00.  I wanted to get this out because I tend to alternate projects and I've spent a lot of time on it.

 

This release includes:

1.  All of Atari's bug fixes and "reasonable" improvements combined from all of the XL and XE branches of it's OS.

2.  Fast Math F+ for floating point operations.  Floating point operations now run more than twice as fast.

3.  A more compact Self Test system which tests everything XL/XE OS R2 tested.  The memory test now tests the break key and, hopefully, displays the bit(s) that failed.  (I don't have bad memory to confirm this.)

4.  The Self Test also displays the video detected and the Atari BASIC version detected.

5.  The CX85 Numeric Keypad can be plugged into joystick port 2 and enabled with CONTROL-SHIFT-3.  (This works with software that uses the OS for keyboard input.)

6.  For 1200XL's, the Self Test will display the function keys once one of them is pressed.

7.  SHIFT-HELP toggles the international character set.

8.  While the left margin is now set to zero, CONTROL-HELP will reset the left margin to zero if necessary.

9. SHIFT-CONTROL-DELETE cold starts the computer.

 

What is not included:

1.  Fast SIO didn't make it yet.  More R&D and testing is needed.

2.  I did not reverse the Option key function as doing so may confuse people. 

 

REV06.ROM

 

 

 

 

 

Screen shot of Self Test screen:

 

 

 

Comprehensive list of changes:

 

;*        Revision 6.00
;*            Merged from Revision 3 (600XL/800XL/1450XLD)
;*                Fix MAXDEV, problems resulting from CRASS65 version,
;*                    initial address for RAM sizing, "Boot Error" message,
;*                    initial address for cartridge equivalence checksum,
;*                    mishandling of SIO NAK, and initializing of CHKSUM.
;*                R. K. Nordin    03/27/84    
;*            Merged from Revision 3, Version 2 (600XL/800XL/1450XLD)                                                                        
;*              Dedicate PDVI ($D1FF) to external parallel device IRQ status
;*                Dedicate IPDVI ($D1CF) to internal parallel device IRQ status                                                                        
;*                Using PDIMSK ($0249) for external parallel device IRQ selection mask
;*                Using IPDIMK ($0254) for internal parallel device IRQ selection mask                                                            
;*                After masking (PDVI, PDIMSK) & (IPDVI, IPDIMK), OR the result
;*                    together, prior to processing parallel device IRQ                                                    
;*                On cold start, initialize PDVI = 0, to avoid potential
;*                    checksum error.
;*                Y. T. JANG, V. WU    02/22/84
;*            Merged from Revision 3, Version 3  (600XL/800XL/1450XLD)
;*                Dedicate the 11 bytes at ACMVAR ($3ED-$3F7) for use as
;*                    a RESET routine area.  On warmstart, the OS will JSR
;*                    to ACMVAR immediately after initializing hardware.
;*                MIKE BARALL        06/08/84
;*            Merged from Revision 3, Version 4  (600XL/800XL/1450XLD)
;*                Make CIO accept device number 0 (like Rev B did).
;*                MIKE BARALL        06/21/84
;*            Merged from Revision 4, Version 0 (600XL/800XL/1450XLD)
;*                In PBK, change DEC BRKKEY to STA BRKKEY.
;*                   Mike Barall 07/24/84            
;*            Merged from Revision 59 (Arabic 65XE)
;*                Shift-Help toggles international character set.
;*            Changes by Brian E. Reifsnyder
;*                Shift-Control-Delete cold starts the computer.            
;*                Control-Help sets left screen margin to 0.
;*                Processing of Control F1 through Control F4 no longer affects PORTB.
;*                Left margin set to 0.
;*                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.
;*                Cleaned up and reorganized KIR.
;*                Re-added F1-F4 keys to the keyboard self test.
;*                Re-wrote the majority of the self test to conserve space.                
;*                Removed PUPBT1 to fix HATABS overlap of first power-up validation byte.
;*                Added a built-in CX85 numeric keypad handler for joystick port 2.  
;*                    Shift-Control-3 to toggle on/off.
;*                Atari BASIC version now displayed on self test screen.
;*                Self test now displays which bit(s) failed the memory test.
;*                Video type displayed on self test screen.

 

 

 

Edited April 19, 2023 by reifsnyderb