130XE Reverse Option Key for Basic

[tjlazer]

Bump!  Anyone get a 100% working ROM made yet?  ;o)

[1050]

You sure are a persistent cuss.

Not that this alone is a bad thing, it's actually a very good thing.

 

So no, I don't have a 100% working rom file. I have only emulator and I can't confirm the work done on a real machine which is where this altered XE OS rev. 3, CRC-32 of 29F133F7 originally should work fine. I start with that version and apply the hi-speed SIO patch to it with no switches used. It should have every toy Hias put in his patchrom.exe process. Then manually I do;

 

offset 0x0000 new checksum for 0x0002 thru 0x1fff region in little endian order - new checksum-16bit is actually 0x841e but in rom has the reversed order 1e, 84 as first and second byte of the rom file. This is the last thing done along with verifying that the last half of the rom file has it's correct checksum too.

offset 0x049f D0 for F0 to reverse the function "Press Option at Boot up for DOS" - DOS is now the non optional option if you get what I mean there...  This will effect the behavior of a real machine when a boot is attempted and you have no drives turned on. I disremember exactly how it's different but it can spin you around when you don't remember such applicable things in the midst of confusing behavior of what used to be a solid working Atari system now showing the auto self-test instead of BASIC ready prompt, if I guessed right. The auto self-test of course leads one to conclude it found something broken and nothing is actually broken.

offset 0x0fff Hias signature for hi speed SIO patch applied
offset 0x13a8 altered banking byte bit table to 0, 4, 8, c to fix four full banks of extended memory test
offset 0x1939 starts Marslett copyright text string denoting the fastchip math pack

 

The fastchip math pack is not working right with TurboBasic - this can be tragic for some, but it resides at;

offset 0x1800 thru 0x1fff

in case one would care to use a hex editor and correct that code with the original and re-compute and store the front half checksum.

 

selftest code resides;

offset 0x1000 thru 0x17ff

 

SIO hi-speed patch resides;

offset 0x0c00 thru 0x0cff

with hooks into code;

offset 0x02b3 thru 0x2b5

and

offset 0x2971 thru 0x2974

and

offset 0x3c20 thru 0x3c22

 

Things I've learned this time thru is that it must have been Newell alone that offered the broken version of the Marslett math pack. Perhaps he even 'tweaked' it not understanding Marslett's use of way non-standard means to extract the data he wants, he was masterful at doing that too. Marslett's source code is so far away from the published rom code as to not be applicable at all in my hurried opinion. Tebe's mads release has his version of commented source code for the Marslett math pack and it's brilliant work. Hias's hi-speed code is also brilliant, correcting both checksums in the rom effortlessly.

 

The above Option change and fix for banking bits in the self test would be applicable to XEGS code. Mathy's 1 meg XEGS would need some further adjusting of values to test four of his banks however since his uses a non-standard banking byte table. Even instead of odd, IIRC. More than four banks for everybody would require a different display screen and a different test, this self-test 'toy' is not well suited for expansion and not very useful either.

 

I haven't tested it on an emulator since it's so full of patches that the emulator will step on it and break it, this makes that use not so very smart to begin with. It is then 100% untested. There are already reports that the fixed extended ram test fails on some selected emulator memory expansions. And that this aspect does not apply to real Atari machines anyway.

 

v3_85_hi_op_ma.rom  - does contain fixed extended memory self-test
CRC-32 9DA106D3

v3_85_hi_op_ma.rom

 

 

 

[tjlazer]

Never been called a Cuss before lol. Thanks for the update! I’ll give it a try in my Atari 1200XL with 32-in-1 OS ROM!

and Rambo 256k RAM!

 

[tjlazer]

ok tested it in Atari800Win PLus 4.1 just for shits and giggles even know I know you said it would break and this is what I got.   When I try it with 128k it goes through the memory test and when it's done the screen goes blank.  Never shows the 4 large boxes at the bottom.  BUT if I select a 320k RAMBO it works!  (The Compy makes it crash.) 

 

I will try it in my 1200 with 32-in-1 OS next on real hardware and let you know!
 

Edited August 27, 2019 by tjlazer

[tjlazer]

Tested the ROM in Altirra and it works fine in 130XE mode!

[+Nezgar]

3 hours ago, tjlazer said:

When I try it with 128k it goes through the memory test and when it's done the screen goes blank.  Never shows the 4 large boxes at the bottom.  BUT if I select a 320k RAMBO it works!  (The Compy makes it crash.)

Hmm.. I have also replicated that behavior in Altirra with this OS:

• Works fine in 130XE mode.
• Works fine in 320K Rambo mode
• Works fine in 576K Rambo mode.
• Blank screen in 320K Compy Shop mode.
• Blank screen in 576K Compy Shop mode.

Banking bytes at offset 0x13a8 in the original ROM were the following, which would have incorrectly tested bank 0 and 1 while toggling BASIC on and off I guess..

 

0 00000000

2 00000010

4 00000100

6 00000110

 

@1050 looks to have correctly patched it to:

0 00000000

4 00000100

8 00001000

C 00001100

 

So... lets see whats getting written to $D301 (54017)... sitting at an ATARI BASIC prompt (after booting with OPTION since normal function is reversed in this OS), we see $FD or 11111101 here:

Bit 0 = 1: OS ROM enabled

Bit 1 = 0: BASIC ROM enabled

Bits 2,3 = 1: Fourth 16K bank of extended 64KB selected

Bit 4 = 1: deny CPU to access extended bank

Bit 5 = 1: deny ANTIC to access extended bank

Bit 6 = 1: unused in RAMBO 256/320K default=1, used by Compy Shop 320K or higher

Bit 7 = 1: disable self test ROM

 

During the main part of the memory test, $d301 (54017) = $7D or 01111101

All the same, except bit 7 has now changed from 1 to 0 to enable the self test ROM.

 

Then at some point when self test completes the 40th block (since BASIC is enabled) and crashes with blank screen, I see:

$6D or 01101101: Bit 4 has changed from 1 to 0, allowing CPU access to the extended bank, and it seems to execute some OS ROM code for a little bit before halting..

 

In standard 130XE mode I see these values at $d301 when at each of the 4 blocks:

block 1 = 63: 01100011

block 2 = 67: 01100111

block 3 = 6B: 01101011

block 4 = 6F: 01101111
 

I'm not skilled enough with the Alitrra debugger to see what's going haywire.. The only difference in hardware behaviour should be bit 5 or 6, but I don't see self test changing that... I do recall that even the stock Rev 3 OS goes funky once it hits that stage as well with a real Rambo 512K, but that shows ANTIC garbage on the screen, not a blank screen...

[phaeron]

The Compy Shop expansions reuse the self-test bit as a banking bit when expanded memory is enabled. This disconnects it from the self-test enable to prevent the self-test ROM from overlaying the extended memory. This is ordinarily the desired behavior... except when someone oddly writes self-test code that actually requires the self-test ROM to overlay the extended memory window. The result is that the self-test banks itself out and crashes.

 

[+Nezgar]

Ahhh... thanks @phaeron I get it now... so as soon as the self test flips bit 4 to access the extended memory, the self test ROM also gets disabled.

 

I forgot Compy shop 256K+ uses bit 7...

 

Edit: so is this also how bit 1 is overloaded, as in BASIC will never be ON while extended memory is active? (And I guess also Bit 6 in the XEGS for game rom...)

[Faicuai]

19 minutes ago, phaeron said:

The Compy Shop expansions reuse the self-test bit as a banking bit when expanded memory is enabled. This disconnects it from the self-test enable to prevent the self-test ROM from overlaying the extended memory. This is ordinarily the desired behavior... except when someone oddly writes self-test code that actually requires the self-test ROM to overlay the extended memory window. The result is that the self-test banks itself out and crashes.

 

Just completed a run on XE-r03 and XEGS-r04 OS loads, on both Incognito and Ultimate/1MB platforms, and they all fully complete Self-Test on either RAMBO or COMPY memory-models.

 

No crashes to report, of any kind.

Edited August 27, 2019 by Faicuai

[+Nezgar]

5 minutes ago, Faicuai said:

Just completed a run on my XE-r03 and XEGS-r04 OS loads, on both Incognito and Ultimate/1MB platforms, and they all fully complete Self-Test on either RAMBO or COMPY memory-models.

 

No crashes to report, of any kind.

I'm confused... How do they succeed in COMPY memory modes when enabling CPU access to banked memory will disable the self-test ROM? (and then causing the crash as above?)

[Faicuai]

1 minute ago, Nezgar said:

I'm confused... How do they succeed in COMPY memory modes when enabling CPU access to banked memory will disable the self-test ROM? (and then causing the crash as above?)

No crashes, no blank-screens, no nothing... just runs fully (48 blocks of linear base-memory, and then four 16K blocks of extended memory-banks).

 

...Unless Incognito's / Ultimate MMU-layer is playing a trick we are not aware of, yet...

[phaeron]

U1MB/Incognito emulate a slightly different Compy variant that latches the BASIC and Self-Test bits when extended RAM is disabled and then holds them when extended RAM is enabled, allowing those bits to be reused for banking bits. Not all Compy-compatible extensions do this -- some just disable BASIC and/or self-test when extended RAM is enabled. This determines whether the self-test crashes in this scenario.

 

[Faicuai]

5 hours ago, phaeron said:

U1MB/Incognito emulate a slightly different Compy variant that latches the BASIC and Self-Test bits when extended RAM is disabled and then holds them when extended RAM is enabled, allowing those bits to be reused for banking bits. Not all Compy-compatible extensions do this -- some just disable BASIC and/or self-test when extended RAM is enabled. This determines whether the self-test crashes in this scenario.

 

Well, there it is (Incognito's and Ultimate's MMU layer, in action)...

 

However, common-sense tells us that just because more of the same 16K banks have been added to the existing ones, the host machine should behave differently with respect to its baseline memory configuration. 

 

In other words, a 130 XE-like machine should complete its core OS functions, whether it has or not extended memory. That should be transparent, and most likely the desired scenario, putting aside any memory selection / banking limitations that may arise from the enforcement of this premise.

 

My 0.02c

Edited August 27, 2019 by Faicuai

[tjlazer]

Tested working on my 1200XL with 256k ram!

[Faicuai]

4 hours ago, tjlazer said:

Tested working on my 1200XL with 256k ram!

 

When you launch VideoBlitzXE demo, what do you see on your screen?

[tjlazer]

Atari 130XE, and it gets stuck. Does’t work with regular Rev C ROM too.

[Faicuai]

18 hours ago, tjlazer said:

Atari 130XE, and it gets stuck. Does’t work with regular Rev C ROM too.

Your black / frozen screen (on VideoBlitz-XE) is not due to your OS revision.

 

It is due to the fact that your current RAM expansion does not support true XE memory-access model (for ANTIC's access to extended RAM). Therefore, your expansion is most likely the RAMBO type (<=320K), and that's why your SELF-TEST seems to have a chance to reach completion.

 

The key point on hand, here, is that SELF-TEST should full complete regardless of your machine configuration, and regardless of the expansion's memory-model employed (RAMBO, CompyShop, etc.), and without ANY modifications to OS core-routines.

Edited August 29, 2019 by Faicuai

[_The Doctor__]

actually some memory tests should check for proper separate ANTIC access, but certainly not crash... while under utilized it was a great concept

Edited August 29, 2019 by _The Doctor__

[Houdini]

I wanted to do a sort of "Lite touch" version of the XL OS where I only reversed the OPTION key and kept everything else as is. I've been getting back into using real disk drives lately and a lot of protected disks don't like the high speed patch. (How unfortunate. ) Big shout out to JAC!, who's ROM patcher I used to compute the proper checksum, so it will pass the built in memory check. Also a huge shoutout to tf_hh and his amazing SYSCHECK device, which made doing this 10 times easier! 

 

XL_Option_Reversed.ROM

[reifsnyderb]

17 hours ago, Houdini said:

I wanted to do a sort of "Lite touch" version of the XL OS where I only reversed the OPTION key and kept everything else as is. I've been getting back into using real disk drives lately and a lot of protected disks don't like the high speed patch. (How unfortunate. )

 

I've encountered the same problem with the new OS 6.1 I put together.

 

It's possible to compile the OS to default the high speed patch to run at normal speed by default and only run at high speed after shift-control-h is pressed.  shift-control-n would then toggle the high speed patch back to normal speed.  The flag is at $0111.  If $0111 is $00 then the high speed patch runs at high speed.  If $0111 is $FF then the high speed patch runs at normal speed.

 

I am thinking about making normal speed the default.....unfortunately.

Edited August 7, 2023 by reifsnyderb

[Houdini]

Here's a crazy thought... (And beyond my capabilities...) What if the ROM could somehow tell if it was running on a real 8-bit or an emulator? It could default to normal speed for real hardware and high speed for emulators. 🤔

[reifsnyderb]

24 minutes ago, Houdini said:

Here's a crazy thought... (And beyond my capabilities...) What if the ROM could somehow tell if it was running on a real 8-bit or an emulator? It could default to normal speed for real hardware and high speed for emulators. 🤔

The very idea of an emulator is for the firmware, operating system, and software to behave as if they on real hardware.  If the emulator is good, the emulated system won't be able to figure out it's not on real hardware.

Edited August 7, 2023 by reifsnyderb

[_The Doctor__]

HSIO should fall back on it's own to standard speed but it can still be an issue for certain stuff. Normally high speed in OS or pbi rom is more compatible than any DOS or OS ram Patch

hot key switch at start up is still a good idea, just gotta pick your key. (I still haven't rediscovered the list)

and software control is still a thing.

Edited August 7, 2023 by _The Doctor__

[Houdini]

On 8/7/2023 at 6:15 PM, reifsnyderb said:

The very idea of an emulator is for the firmware, operating system, and software to behave as if they on real hardware.  If the emulator is good, the emulated system won't be able to figure out it's not on real hardware.

It's been my experience that ANY system designed and built by humans has at least one flaw, and more often many flaws. The hardware has flaws the emulator does not and vice-versa. 

[flashjazzcat]

On 8/7/2023 at 11:17 PM, _The Doctor__ said:

HSIO should fall back on it's own to standard speed but it can still be an issue for certain stuff.

The exact reason we have this:

A few devices are sent into a state of confusion by the high-speed detection strategy (acking things they shouldn't ack, etc) which nevertheless works perfectly with real disk drives.