Compiling a new Atari OS...

[+gnusto]

Just now, reifsnyderb said:

I use the keyboard and memory checks.  But, that being said, what do you have in mind for the space?

I get that they are useful, just that I don't think they are common on a per-boot basis. So you could make a decision to run them only when you need them, meaning they don't have to be there all the time.

As for what to put there, that's an excellent question...which I don't know an answer for really. A loading routine for fonts? Rasta image display? string manipulation code? Consider some straws grabbed.

[+gnusto]

Oh and now I see @_The Doctor__ actually suggested removing it for something more common use way back in the beginning of the thread. Well great minds and all that, amirite??

[reifsnyderb]

5 minutes ago, gnusto said:

Oh and now I see @_The Doctor__ actually suggested removing it for something more common use way back in the beginning of the thread. Well great minds and all that, amirite??

Yes, but there was no good idea as to what to do with the memory.  So, I figure the best option is to condense the self test by optimizing the user interface.

 

The self test actually used a lot of memory outside of the self test bank as well.  This memory can be free'd up.  One possibility, for which I already have working code for, is to have a built-in CX-85 Numeric Keypad driver. 

 

I am open to other ideas, of course.

 

Somebody did mention machine code monitor software.  I doubt that would be useful for a large number of people.

 

Best Regards,

 

Brian

[kenames99]

32 minutes ago, gnusto said:

I get that they are useful, just that I don't think they are common on a per-boot basis. So you could make a decision to run them only when you need them, meaning they don't have to be there all the time.

As for what to put there, that's an excellent question...which I don't know an answer for really. A loading routine for fonts? Rasta image display? string manipulation code? Consider some straws grabbed.

I think the keyboard test at least should be included in the OS, I am also in favor of a resident memory tester for at least the base 64K. bad keys make it hard to load other programs, so does bad memory. machine code monitor only useful to programmers. assembly programmers anyway.

 

Ken

 

Edited March 25 by kenames99

[Teapot]

14 minutes ago, reifsnyderb said:

I am open to other ideas, of course.

 

I don't know how much space there is outside the banked section.

 

Fast line drawing?

 

An E: patch for faster editing? Like HYP.COM or EFAST.COM do.

 

[kenames99]

38 minutes ago, gnusto said:

I get that they are useful, just that I don't think they are common on a per-boot basis. So you could make a decision to run them only when you need them, meaning they don't have to be there all the time.

As for what to put there, that's an excellent question...which I don't know an answer for really. A loading routine for fonts? Rasta image display? string manipulation code? Consider some straws grabbed.

this area of the OS is not well suited for drivers but not impossible. I would not like to see any drivers there.

[+gnusto]

1 hour ago, kenames99 said:

I think the keyboard test at least should be included in the OS

Our experiences must differ. I have 3 8bits that I use regularly and it's been at least a year since I used any diag test, shrug.

[kenames99]

I have >15 Atari computers and all but 2 have bad keyboards, including 2 800 that both have bad keyboards but those stick, not fail to make contact like the membrane ones.I also like when the mem test comes up and reports bad memoy. so, yes, our experience differs although I would rather have not had keyboard problems at all.

 

Ken

 

[HiassofT]

I, too, was happy that the memory test reported issues on several occasions and have used the keyboard test a lot of times on various Ataris, either because of crappy membrane or keyboard cable issues.

 

And I also use the audio visual test a lot when I quickly need to check if audio and video out (or a/v in on the TV/amp/capture device/...) works.

 

So, I'd say too, leave the self test as is.

 

so long,

 

Hias

Edited March 26 by HiassofT

[_The Doctor__]

If the replacement test set covers all those bases and takes up less space doing a better job, what's the rub?

Edited March 26 by _The Doctor__

[kenames99]

No problem if it covers the bases and is smaller too. Works for me.

 

Ken

 

[reifsnyderb]

On the surface, it doesn't look like much changed.  Thus far, the sound test is working as well as most of the keyboard test.  I just have to implement the shift and control keys yet as well as the function keys.

 

 

The sound test has Atari's usual tune.  Instead of a special screen, "V1" through "V4" are highlighted, depending upon the voice.  For the sound test, most of the original code was re-used after all of the video-related code was removed.

 

The keyboard test will also include F1 through F4, but they will only show if they are pressed.  With the exception of the Reset button, all of the console keys work as well as the Help key.  I also figured out how to get the break key test working as well...so a break key test is included.

 

I have fragments of the original memory code still in the OS so I can reference them later and so that they take up space to give me a more realistic estimate of how much space is available.

 

Presently, there are still 334 bytes of space left in the self test bank.  As I still have the disabled memory test code taking up space, and not included in the 334 bytes free, I expect there will be plenty of space to re-implement the memory test code.  Since I was able to move almost all of the self-test code into the self-test bank, there is now a region with 385 bytes free in a non-banked region of the OS. 

 

I am planning to re-install the CX-85 Numeric Keyboard driver back into the non-banked region of the OS.  However, if somebody has a better idea for the use of this space I am very open to suggestions.  (I can now use a 1090 card for the CX-85 but it's still nice to be able to use it in a plug-and-play fashion with built-in support in the OS.)

 

It is my plan for the version of BASIC to be displayed below the OS version.  I may also be able to squeeze in an indication of the detected installed memory as well.

 

In the original code certain sections were duplicated due to a minor change.  For example, the Space Bar display had a normal and inverse video version of it.  The new code only has one version of the Space Bar and inverts it with an EOR command.  I think that some more bytes can be re-claimed but the point of diminishing returns is nearby unless some really tight self extracting compression code were to be used.  Unfortunately, some code has to be implemented several different ways as there were enough differences that it would have been miserable to make it all one function.  (i.e.  The break key code, console key code, "long key" code (i.e. space bar), and code for all the other keys.)  One example planned is that I may be able to re-claim another 8 bytes by handling the title "SELF TEST" without the leading and trailing zeros as was done originally.

 

Removing all of the display list code for the extra 3 screens really helped to reduce the amount of code needed as well.

 

I also wrote a small program to patch in the Fast Math code, after the ROM has been compiled, to replace the Math Pack.

 

In addition, the following changes were implemented or will be re-implemented:

 

;*        Revision 5.99
;*            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.
;*                Fixed TXEB table for XE bank testing as per TXEB notes in Revision 3 (65XE/130XE)
;*                Re-wrote the majority of the self test to conserve space.               

 

 

 

 

 

 

 

[reifsnyderb]

Keyboard test seems to be working.  Here is a copy of the latest OS ROM:

 

testos.rom

[ascrnet]

On 3/27/2023 at 4:37 PM, reifsnyderb said:

I am planning to re-install the CX-85 Numeric Keyboard driver back into the non-banked region of the OS.  However, if somebody has a better idea for the use of this space I am very open to suggestions.  (I can now use a 1090 card for the CX-85 but it's still nice to be able to use it in a plug-and-play fashion with built-in support in the OS.)

 

I would focus on making better detection of damaged RAM, extended RAM detection, speed improvements in SIO port for floppy and cassette. 😅

[reifsnyderb]

2 hours ago, ascrnet said:

I would focus on making better detection of damaged RAM, extended RAM detection, speed improvements in SIO port for floppy and cassette. 😅

 

I am planning on improving the detection in that I hope to be able to pinpoint the bad chip on systems that are still using DRAM chips.  This should be possible as each chip handles a single bit in a byte.  Atari does have an SIO improvement for floppy disks that I haven't put in yet due to space constraints.  Testing for an extra 64k, as the 130XE had, is planned.  However, since there are so many other options for extended memory, I think it would take up too much space to implement a thorough extended memory test.

[tzok]

Basically there were 2 popular memory expansions for XL/XE series - ICD RAMBO (aka Wizztronics), and Compy Shop (aka Newell). There were also some exotic expansions based on old Axlon from the original 400/800 series with 16kB banks.

 

http://www.atarimania.com/faq-atari-400-800-xl-xe-what-types-of-memory-upgrades-are-there-for-the-atari_68.html

[reifsnyderb]

4 hours ago, tzok said:

Basically there were 2 popular memory expansions for XL/XE series - ICD RAMBO (aka Wizztronics), and Compy Shop (aka Newell). There were also some exotic expansions based on old Axlon from the original 400/800 series with 16kB banks.

 

http://www.atarimania.com/faq-atari-400-800-xl-xe-what-types-of-memory-upgrades-are-there-for-the-atari_68.html

I am aware of that page and have read it thoroughly many times.  (More than 1/2 of that page is XL/XE RAM expansions, too.)  To handle all of the possible expansions would require a lot more space than what I have available.  On a more positive note, I suppose any use of PORTB bit 7, for extra RAM banking, would not require consideration.   🙂 

 

Edit to add:  After thinking about this some more, some expansions may only bank with PORTB bit 7 when PORTB bit 4 is set to 0.  So, PORTB bit 7 would work normally until bit 4 was set to 0.  So, this is just yet another possibility to test for. 

 

Edited March 29 by reifsnyderb

[w1k]

flashed with u1mb and tested on atari 800xe

 

 

[+kheller2]

3 hours ago, reifsnyderb said:

I am aware of that page and have read it thoroughly many times.  (More than 1/2 of that page is XL/XE RAM expansions, too.)  To handle all of the possible expansions would require a lot more space than what I have available.  On a more positive note, I suppose any use of PORTB bit 7, for extra RAM banking, would not require consideration.   🙂 

 

Edit to add:  After thinking about this some more, some expansions may only bank with PORTB bit 7 when PORTB bit 4 is set to 0.  So, PORTB bit 7 would work normally until bit 4 was set to 0.  So, this is just yet another possibility to test for. 

 

>I< would focus on stock memory testing, including the 130XE (so 128K max).  If you can add the general 256K expansions that would be good, but there are already several memory expansion identification tools and a good RAM tester too (I thought there was one in a OS ROM replacement diagnostic tool in another thread here).

Free space is good space for future enhancements. 

Has anyone tested the high speed routine yet or how it determines if a device supports it?

Anyone test this OS version with some PBI devices?

[reifsnyderb]

47 minutes ago, w1k said:

flashed with u1mb and tested on atari 800xe

 

 

 

Good to see it working on another system.   🙂

 

 

 

 

[reifsnyderb]

15 minutes ago, kheller2 said:

>I< would focus on stock memory testing, including the 130XE (so 128K max).  If you can add the general 256K expansions that would be good, but there are already several memory expansion identification tools and a good RAM tester too (I thought there was one in a OS ROM replacement diagnostic tool in another thread here).

Free space is good space for future enhancements. 

Has anyone tested the high speed routine yet or how it determines if a device supports it?

Anyone test this OS version with some PBI devices?

I'll test it with my 1090 card for the CX85 Numeric Keypad as soon as I get a couple more parts in.  That will allow for testing PBI identification of the device, executing the firmware on the device, and executing an IRQ on the device.

 

I was thinking today that since Atari had a high speed SIO patch that maybe that would be a good use of the extra space.  I can patch it in but don't have the hardware to test it with.  (Atari only added the high speed SIO after they eliminated support for something else.)

 

 

 

 

[_The Doctor__]

Actually in the video he appeared to have difficulty with selection being too quick and no memory test was done. I think he muttered weird, strange or difficult (could not leave sound channel tests) and shuts down when the mem test didn't happen. Appears it may be PAL machine.

Edited March 29 by _The Doctor__

[reifsnyderb]

1 minute ago, _The Doctor__ said:

Actually in the video he appeared to have difficulty with selection being too quick and no memory test was done. I think he muttered weird or difficult and shuts down when the mem test didn't happen

The memory test isn't implemented yet.  Also, I should probably add something to allow the sound test to be aborted.  Right now, if you are running the sound test you have to wait until it's finished.

[flashjazzcat]

The code employed to establish the amount of extended memory need not correlate in terms of size to the number of banks being tested:

 

http://atariki.krap.pl/index.php/Obsługa_standardowego_rozszerzenia_pamięci_RAM

 

That's a generic routine which will provide a table of PORTB values for most common RAM expansions.

 

[Irgendwer]

On 3/25/2023 at 1:44 AM, reifsnyderb said:

Somebody did mention machine code monitor software.  I doubt that would be useful for a large number of people.

It depends. The OS from the "ROMDISK" of Ralf David had a single line one.

Great to apply game patches, like number of lives or unlimited ones...