Odd behaviour loading 180.xex via Side3

[TJ76]

Side3 has been generally a joy to use so far, particularly after applying recent updates @flashjazzcat has provided addressing SD compatibility issues which fixed problems I had with a couple of 16gb Sandisk Ultra cards.  

 

One odd thing I spotted.  I happened to try loading up 180.xex after someone mentioned the game on one of the forums / FB groups, and fancied rewinding the brain for a bit of reminiscing.  Tried it a few times via Side3, and thought had corrupted Xex file, as after my turn, followed by computers turn, the game would crash with change of colors as attached.  Earlier tried removing Side3 and plugging my Sdrive Max back in and loading it that way, and game was fine and I played to the semi-finals with no issues.

 

Weird one - any thoughts what's going on here.  Can post 180.exe if required, but just a general one from fandal or homesoft I  think, so not sure file specific issue.  Image below shows point of crash.

 

 

 

 

Atari 800XL rev D 

Ultimate 1MB 3.11 RC_221020

Sophia DVI Sophia_C_1280x1024old.pof 

Side3 0.17_221022

 

[flashjazzcat]

12 hours ago, TJ76 said:

Weird one - any thoughts what's going on here.  Can post 180.exe if required, but just a general one from fandal or homesoft I  think, so not sure file specific issue.  Image below shows point of crash.

I can reproduce this on a 1088XEL without SIDE3 (loading the XEX via the XEL loader straight from the CF card). No idea what's causing it yet, but it's not specific to SIDE3.

 

[TJ76]

5 hours ago, flashjazzcat said:

I can reproduce this on a 1088XEL without SIDE3 (loading the XEX via the XEL loader straight from the CF card). No idea what's causing it yet, but it's not specific to SIDE3.

 

Interesting.  I know little about 1088XEL e.g. did not know had own loader.

 

I popped the Side3 into another 800XL REVE which has no Ultimate 1MB or other mods in it, and reproduce same behavior.   So that XEX only likes loading via SIO for some reason?  Anyway, not one to prioritize I'm sure, and thanks for looking. 

Edited October 25, 2020 by TJ76

[Wrathchild]

Looking at the 180 load process under Altirra, there is some odd behaviour after the first segment is initialised as after the RTS the program counter is set to the top of the stack?

 

 

 

The Homesoft version loads with lots of little segments, but shouldn't interfere with the cart's xex loader so maybe try that

180! (Homesoft).xex

[flashjazzcat]

That Homesoft version fails even quicker for me, but thanks for those observations regarding the stack. I've already started looking at the title in Altirra and the data is getting completely out of sync at some point during the load. Since the XEX loader requires only $700-$9FF, there seems to be no address space conflict, but I have seen some very strange methods used in a few problem ATRs I've also been looking at (such as calling SIOV from code at the top of the stack and assuming there won't be any JSRs in the SIO handler... of course there are when the PBI handler is called, resulting in the calling code being totally wiped out).

 

Quite an interesting one, this... it has my full attention.

 

[flashjazzcat]

Hilarious... sort of. Simply clearing out the entire stack area with $00 before loading the executable allows the game to work properly. I mean, I despair at times.

 

[Wrathchild]

I've also knocked up a quick version from the CAS on AtariMania.

The big section uses exomizer to maintain not loading under $2000.

So this uses zeropage at the end but hopefully doesn't need the clearing that you've found.

 

 

180.zip 180darts.xex

[flashjazzcat]

4 minutes ago, Wrathchild said:

So this uses zeropage at the end but hopefully doesn't need the clearing that you've found.

Great - thanks. That appears to work fine with the prior version of the loader. I'll leave the fix in for compatibility reasons, of course.

5 hours ago, TJ76 said:

Anyway, not one to prioritize I'm sure, and thanks for looking. 

Fixed. See the update in the SIDE3 preorder thread.

[TJ76]

1 hour ago, flashjazzcat said:

Great - thanks. That appears to work fine with the prior version of the loader. I'll leave the fix in for compatibility reasons, of course.

Fixed. See the update in the SIDE3 preorder thread.

I love this community.  For what I saw as a trivial issue with a single XEX file, the level of attention and desire to find out what's going on and swiftly fix just shows the heart that goes into these products.  Sadly lost I feel with modern corporate software companies. 

 

Works great.  Still get wiped out by Jammy Jim in the final, but don't expect anyone can help me there

 

 

[Wrathchild]

 yes, very strange that he's on a nine dart finish and chooses 2 x treble twenties and an eleven to leave 10!

[flashjazzcat]

12 hours ago, TJ76 said:

I love this community.  For what I saw as a trivial issue with a single XEX file, the level of attention and desire to find out what's going on and swiftly fix just shows the heart that goes into these products.  Sadly lost I feel with modern corporate software companies. 

Without any hyperbole, I can tell you that this comment has made my day.

[KPeter]

Hi Jon,

 

I hope I correctly accessed to "SIDE3 pre-order" communication group. I try to answer to 1.-3.

 

1. Nothing to do with me. Lotharek should have told you this. DLT/Candle are responsible for SDX/RTC drivers.

2. BASIC XE extensions work with OSS 'type B' BASIC XE cart, but not with 034M type for reasons I do not know. I suggest using BASIC XE 4.1.

3. Are you using U1MB and the U1MB-SIDE3 firmware I published in the pre-order thread? Again - I told Lotharek to direct you to this. Presumably

 

1. I already sent notification to DLT. My finding: They used an old version of TD.COM with date 4-08-16 (TD.MAN 7-05-20), rather a

    newer version in SDX449 (COM: 13-03-17; MAN: 17-07-16), so it was mixed up.

2. I am using BASIC XE 4.1 cart and the compatible Extension disk, completely functioning on ULTIMATE Cart. (I copied all folders with files from

    ULTIMATE Cart SD card without any changes on them). Using same CAR (4.1) file and totally same Extension file on ATR in SIDE3 fails,

    like it behaved in SIDE2 OSS, before Eric corrected the code using BASIC testprogram sent to him.

3. Yes, I updated U1MB with U1MB-SIDE3 firmvare also SIDE3 with files, what you put in this Forum last week.

 

If you remember from past, when we had personal communication, I always wrote you with intention to help you, not to disturb you and you appreciated it

with words, "I need someone like you, who are testing my software". My intention was never different! I always value your great work!

 

Peter

[Wrathchild]

5 hours ago, KPeter said:

I hope I correctly accessed to "SIDE3 pre-order"

You needed this thread: 

 

[flashjazzcat]

8 hours ago, KPeter said:

I try to answer to 1.-3.

As Wrathchild points out: please post in the appropriate thread, and instead of posting my terse response to your similarly abrupt PM enquiry without any context, please post your original queries so that the appropriate parties can attempt to address them.

 

I already said that testing is valued and needed, but unfortunately it is not physically possible for me to singlehandedly channel all discourse on every aspect of this product via emails and personal messages.  SIDE3 is a collaborative project, and I would hope that after sales support is no different.

 

[drac030]

10 hours ago, KPeter said:

I already sent notification to DLT. My finding: They used an old version of TD.COM with date 4-08-16 (TD.MAN 7-05-20), rather a

    newer version in SDX449 (COM: 13-03-17; MAN: 17-07-16), so it was mixed up.

This bit is interesting. To my knowledge, last changes to TD.COM were done in 2016 (CVS commit timestamp 2016-08-04 21:47, file size 1319 bytes), so what "newer version" (yet from 2017) is being talked about here? @trub?

Edited October 29, 2020 by drac030

[trub]

TD is the same (from 2016). Please provide the image with the newer date for comparison.

 

However the problem is not with the TD, but with the SDX driver for the clock chip in SIDE3.

Unfortunately, I don't have a working SIDE3 at the moment to update it.

 

Also, the SDX version 4.49e placed by the manufacturer in SIDE3 should be considered an alpha version.

[_The Doctor__]

interesting about TD, I thought there was a tweak done to it since '16 as well... am I thinking 5 years ago as if were just a couple?

also didn't FJC come up with a nice clock driver or fix that worked across most of all the differing clock types out there including the super sdx carts etc.

all vaguely rattling around in my thoughts..

[flashjazzcat]

1 hour ago, _The Doctor__ said:

also didn't FJC come up with a nice clock driver or fix that worked across most of all the differing clock types out there including the super sdx carts etc.

I wrote a DS1305 RTC driver for Sparta 3.x, BeweDOS and RealDOS.

 

All TD does is read the date and time via the RTC driver; the TD line is therefore wholly abstracted from the clock hardware.

 

For info: one bug (the TD line interfering with SD card IO) was caused by CRITIC not being set in the LSIO driver (SIDE3.SYS). I had assumed SDX would set this prior to calling the driver, but it doesn't. Setting CRITIC prevents the TD line from calling the RTC driver during the VBL while critical IO is taking place, which is important, since accessing the clock right in the middle of a FIFO sector transfer did not go well.