Compiling a new Atari OS...

[Ricky Spanish]

@_The Doctor__

 

[_The Doctor__]

No you are cold starting the computer in the beginning of your video, you are not warm starting the computer, which is the reset key on the real machine...

it's not until the very end that you warm started and were running everything including OSS BASIC XE that you did the ROM to RAM copy.

The fresh disk helped but I am not certain at this point because the comparisons mean little when each test session is done differently

Edited April 26, 2023 by _The Doctor__

[Ricky Spanish]

Well going way of into the weeds here and taking away from this excellent thread. Apologies to the OP. 

[reifsnyderb]

@Ricky Spanish and @_The Doctor__ :  I just got back and haven't looked at the problem much, yet.  Looking at the thread, am I correct in assuming there is no problem?

[Ricky Spanish]

2 minutes ago, reifsnyderb said:

Looking at the thread, am I correct in assuming there is no problem?

Can't speak for @_The Doctor__ but on my end the self test screen is corrupted when using a rom to ram handler w/ DOS 2.5.

Not a big deal by any stretch cause I'm assuming most won't bother with a R to R handler. 

 

[reifsnyderb]

16 minutes ago, Ricky Spanish said:

Can't speak for @_The Doctor__ but on my end the self test screen is corrupted when using a rom to ram handler w/ DOS 2.5.

Not a big deal by any stretch cause I'm assuming most won't bother with a R to R handler. 

 

I just tested it in OS R 2 and Altirra.  If I am in BASIC, hit reset, then type "BYE" it locks up.  A ROM to RAM handler can do strange things.  I've found that out with the firmware board and OS 6.01 dev.

[_The Doctor__]

When going from ROM to RAM, protection for warm start reset and other vectors need to be protected so that the system jumps to the ram OS on reset and when self test etc launch they don't twiddle the old OS back on or use formerly free hidden under the OS ram area that is now occupied by the RAM OS

 

I see you verified what I pointed out about stock OS moved to RAM and the self test

Edited April 26, 2023 by _The Doctor__

[Ricky Spanish]

11 minutes ago, reifsnyderb said:

I just tested it in OS R 2 and Altirra.  If I am in BASIC, hit reset, then type "BYE" it locks up.  A ROM to RAM handler can do strange things.  I've found that out with the firmware board and OS 6.01 dev.

I don't have a 600/800XL O/S to test with but this is what it looks like with r2r plus 6.0 O/S

Again.. Not a big deal. 

 

 

Edited April 26, 2023 by Ricky Spanish

[reifsnyderb]

9 minutes ago, Ricky Spanish said:

I don't have a 600/800XL O/S to test with but this is what it looks like with r2r plus 6.0 O/S

Again.. Not a big deal. 

 

 

I am unable to reproduce that.  Ram to ROM + OS 6.00 just locks up when going into self test.  I just checked the source code and it should be only changing bit 7. 

 

There is the possibility that this is related to screen memory and I am pretty sure the screen memory region isn't cleared before use when going into self test.  I'll put a note in the to-do list to clear the screen memory for the self test prior to use.  Maybe that will clear it up.

Edited April 26, 2023 by reifsnyderb

[Ricky Spanish]

14 hours ago, reifsnyderb said:

I'll put a note in the to-do list to clear the screen memory for the self test prior to use.  Maybe that will clear it up.

If its indeed the case then glad to have helped. 

[manterola]

On 4/20/2023 at 11:27 PM, manterola said:

If I remember correctly, you can also just subtract 0x20 to checksum at the end, and then the ROM file should be valid and ready to use with the reverse Option for Basic.

 

Actually, the change needs to be done at the beginning of the ROM.

In this case in particular, to implement the reverse BASIC Option button, the position $04b7 needs to be changed from $f0 to $d0 ($20 difference). But then to make it pass the ROM check we also can subtract $20 to the word (first two bytes Lo/Hi order). So have to change the first two bytes from 1A 64 to FA 63.

 

[w1k]

any news?

[reifsnyderb]

5 hours ago, w1k said:

any news?

I spent a lot of time getting the OS to run off of the 1090XL firmware board.  There needs to be a couple changes made to the firmware board to get it to work better.  I was able to hack the board to get this to work, ordered new boards with the changes, and have the board to assemble. 

 

There are 2 ways to run the OS off of the firmware board.

 

1.  Copy the ROM to RAM:  This works but requires a lot of changes.  For example, the OS uses write tests to determine where the top of RAM is.  If the OS is in RAM, the top of RAM is within the OS region and, therefore, overwritten.  So, a hard limit needed to be put in place to prevent this.  In the end, I was able to get the OS to run in RAM.  Obviously, this won't work with any software that changes PORTB, bit 0.  The changes necessary to make this happen also took up a lot of the available space.  Because of these reasons, I didn't pursue this avenue any further.  So, it was an interesting learning experience at best.

 

2.  Run the ROM straight off of the 1090 firmware board.  This worked the best and required the fewest OS changes.  Once again, any software that makes changes to PORTB, bit 0, will botch this up.

 

So it is clearly possible to upgrade the OS from a 1090XL.  However, software compatibility is a major issue.

 

Then I started looking even more into adding high speed SIO support to the OS.  I think it's possible to do so by re-using or modifying existing code and not use up too much space.  Unfortunately, even with the available documentation, there is a lot of R&D involved in getting this to work.

 

I was able to make even more space by moving some additional self-test code to the self-test bank.  So, I don't think space is a big issue.

 

 

[reifsnyderb]

Paging @HiassofT

 

I was playing around with the High Speed SIO patch, on OS R 6, and while running MULE found out that one of the voices still plays when loading the game from the setup screen.  So, I took Atari's OS R 2 and found out that it does the same thing.  So, for example, with a Happy 1050 emulated one of the last tones played is playing for around 18 seconds while the game loads.  Is there a simple fix for this?

 

Thanks!

 

Brian

 

[_The Doctor__]

on real hardware and emulation?

[reifsnyderb]

2 minutes ago, _The Doctor__ said:

on real hardware and emulation?

Emulation.  I don't have any high speed SIO devices, unfortunately.

[_The Doctor__]

@reifsnyderb

ah so then that leaves you with setting up the emulator to the exact timing modes / full emulation settings along with whatever roms etc.

what sound are you hearing, the SIO beep or some music from pokey?

high speed and burst modes can sound like staccato blasts and higher pitched longer tones. 18 seconds is a long time of continuous tone...

Edited May 22, 2023 by _The Doctor__

[reifsnyderb]

Just now, _The Doctor__ said:

ah so then that leaves you with setting up the emulator to the exact timing modes / full emulation settings along with whatever roms etc.

what sound are you hearing, the SIO beep or some music from pokey?

It's POKEY music.  The last tone playing as I hit the start button.

[_The Doctor__]

That is quite strange, something is definitely amiss.

[reifsnyderb]

1 minute ago, _The Doctor__ said:

That is quite strange, something is definitely amiss.

It's definitely not the SIO loading staccato beeping noise.  When loading MULE, you have to wait until the melody is playing on the setup screen.  Then press start.  The last note, of the melody, will be sounding continuously and the loading staccato beeping noise is also heard at the same time.  That last melody note will play until the game starts.

[HiassofT]

The highspeed SIO code only touches pokey channels 2 and 3, channels 0 and 1 aren't used/needed by the SIO code so are left intact.

 

So if the porgram running didn't disable sound on channel 0/1 before calling SIO it will continue playing. I'd like to call that an issue of the program then (it shouldn't assume SIO will mute channels 0/1).

 

Very likely you'd have similar issues with PBI devices which don't use POKEY for SIO at all so won't clear any channels (but still accessing sectors on a HDD could take some time so you'd hear the channels playing as well for a while).

 

so long,

 

Hias

Edited May 22, 2023 by HiassofT

[reifsnyderb]

27 minutes ago, HiassofT said:

The highspeed SIO code only touches pokey channels 2 and 3, channels 0 and 1 aren't used/needed by the SIO code so are left intact.

 

So if the porgram running didn't disable sound on channel 0/1 before calling SIO it will continue playing. I'd like to call that an issue of the program then (it shouldn't assume SIO will mute channels 0/1).

 

Very likely you'd have similar issues with PBI devices which don't use POKEY for SIO at all so won't clear any channels (but still accessing sectors on a HDD could take some time so you'd hear the channels playing as well for a while).

 

so long,

 

Hias

That all makes perfect sense.  Thanks for the info as that has to be what is happening.  It's odd, however, that MULE doesn't do the same thing without the patch, but computers can be odd.  🙂  Is there enough space to make it a feature request for the next version of the patch to turn off channels 0/1 just to be sure?

 

Thanks!

 

Brian

 

[_The Doctor__]

It's kind of a weird thing, because you can silence SIO beeps, and some games/demos play music or animations during loading... depends if they are set up to do so, I am not sure how HSIO deals with any of it... does it leave everything as it was or does it change some things. Would changing any of HSIO break anything, I know on some HSIO loaders etc, the choice is HSIO on or HSIO off as a user choice. That choice allows you to load non HSIO friendly software.

Edited May 23, 2023 by _The Doctor__

[reifsnyderb]

2 hours ago, HiassofT said:

The highspeed SIO code only touches pokey channels 2 and 3, channels 0 and 1 aren't used/needed by the SIO code so are left intact.

 

So if the porgram running didn't disable sound on channel 0/1 before calling SIO it will continue playing. I'd like to call that an issue of the program then (it shouldn't assume SIO will mute channels 0/1).

 

Very likely you'd have similar issues with PBI devices which don't use POKEY for SIO at all so won't clear any channels (but still accessing sectors on a HDD could take some time so you'd hear the channels playing as well for a while).

 

so long,

 

Hias

I just confirmed that the same problem occurs on a patched OS, on real hardware, when no fast SIO hardware is present.

[reifsnyderb]

Ok.  There is no longer any POKEY tones still playing if the High Speed SIO patch is applied to the OS.  I fixed it with the following:

 

;    SPACE    4,10
;**    SIO - Serial Input/Output
;*
;*    ENTRY    JSR    SIO
;*
;*     NOTE
;*        $E971 is entry point for High Speed SIO Patch.
;*
;*    MODS
;*        Original Author Unknown
;*        1. Bring closer to Coding Standard (object unchanged).
;*           R. K. Nordin    11/01/83
;*        2. Set SIO to $E96E so as to silence all POKEY music prior to SIO call.  Actual beginning of
;*            SIO is still at $E971 so as to ensure compatibility with High Speed SIO Patch.
;*          Brian E. Reifsnyder   5/24/2023

FIX $E96E
SIO    =    *    ;entry
    JSR    SAS        ; Silence POKEY.

FIX $E971

;    Initialize.

    TSX
    STX    STACKP    ;save stack pointer
    LDA    #1    ;critical section indicator
    STA    CRITIC    ;indicate critical section