Incognito JED experimental upgrade

[candle]

"external os switcher" modes won't work, since memory map at early boot stage is not like in regular atari xl/xe

i think turbo freezer was "patched" to take this into account, but i have no information on syscheck

at this point of time i find it unrelevant

 

[Faicuai]

On 8/30/2021 at 4:26 PM, candle said:

"external os switcher" modes won't work, since memory map at early boot stage is not like in regular atari xl/xe

Ok, thanks, that is in line with what I originally thought, based on tests' results.

 

I actually spent a bit more time testing this case, and (surprisingly) got it working!

 

I set SysCheck-II eternal OS-load to Q-Meg (and S2 to off/off/off), then booted Incognito on my Q-Meg profile (I only modified the math-pack and checksums of Incognito's local Q-meg, so I could invariably confirm if I could move back-and-forth between internal and external OS loads).

 

As soon as I landed on Incognito's Q-Meg default menu, I then set (live) Syschek´s S2 switch to Off/ON/Off and voila! External Q-meg load was banked-in. I then ran Acid800 tests and it fully passed XL-bankimg tests (OS could be banked in and out, as well as local RAM-under-OS and local Basic ROM, too!)

 

So all-in-all, it appears to me that the underlying PBI functionality DOES work, but it may be necessary to pre-set the HW to XL/XE mode before anything else at boot time, for SysCheck to fully work as intended.

 

At this point, I have not found anything else to report. If there is anything else we should be aware of in the PBI-front, please, let us know.

 

Thanks!

[candle]

perhaps bit3 usability in this setup, and joystick ports 3 & 4 operation (please remember that this will not work in basic without custom routines)

 

[Faicuai]

@flashjazzcat

 

FYI, just noticed today that "L" is mot bringing in LOADER when "SDX" is enabled, on Colleen profile (thus rather booting SDX no matter what). This is happening right from power-up.

 

Two work-arounds:

 

1. After booting SDX, typing "CAR" gets me to the loader.

2. Change to a XL/XE profile and "L" does bring the loader. When switching back to Colleen profile, now loader comes in when hitting "L".

 

Is the above behavior as-designed / expected? Or am I missing something already discussed?

[flashjazzcat]

5 hours ago, Faicuai said:

Is the above behavior as-designed / expected? Or am I missing something already discussed?

Totally unexpected. Is this dependent on the JED or the BIOS?

 

Haven't heard a thing from Poland for ten days so I have no idea where we are with the other issues. 800 destined for Australia gathers dust.

[flashjazzcat]

20 hours ago, Faicuai said:

FYI, just noticed today that "L" is mot bringing in LOADER when "SDX" is enabled, on Colleen profile (thus rather booting SDX no matter what). This is happening right from power-up.

 

Two work-arounds:

 

1. After booting SDX, typing "CAR" gets me to the loader.

2. Change to a XL/XE profile and "L" does bring the loader. When switching back to Colleen profile, now loader comes in when hitting "L".

Just tested this with the latest BIOS and the latest JED posted in this thread and I cannot reproduce the issue on the customer 800 sitting on my desk. Will try my own machine later.

 

I updated the BIOS first, couldn't replicate the problem, then updated the JED and still couldn't replicate it. This all sounds fairly alarming, anyway, since the loader should not be accessible via 'CAR' (and it isn't here) when SDX has booted.

 

Try downgrading the JED and using the same firmware and see if the problem persists; that's all I can suggest at this point since I have no idea WTF is going on with this at the moment.

[Faicuai]

3 hours ago, flashjazzcat said:

Just tested this with the latest BIOS and the latest JED posted in this thread and I cannot reproduce the issue on the customer 800 sitting on my desk. Will try my own machine later.

 

I updated the BIOS first, couldn't replicate the problem, then updated the JED and still couldn't replicate it. This all sounds fairly alarming, anyway, since the loader should not be accessible via 'CAR' (and it isn't here) when SDX has booted.

 

Try downgrading the JED and using the same firmware and see if the problem persists; that's all I can suggest at this point since I have no idea WTF is going on with this at the moment.

THANKS for the follow-up and sorry for answering late (beach-time holiday with family).

 

I actually thought about your suggestions, already, and will reset the whole board so I cab start over (as soon as I reach my retro-desk).

 

Cheers!

[Faicuai]

On 9/5/2021 at 2:25 PM, Faicuai said:

 

@flashjazzcat

 

FYI, just noticed today that "L" is mot bringing in LOADER when "SDX" is enabled, on Colleen profile (thus rather booting SDX no matter what). This is happening right from power-up.

 

 

Alright, back from holidays:

 

The anomaly reported above got corrected / eliminated by pressing "D" (defaults restore/reset) right at the offending Colleen BIOS profile (only one among four I have set). I considered this as a simple first-step before embarking on a JED and re-flashing trial-and-error journey.

 

Whatever happens with "D" code-wise may give a clue of what the problem may relate to. The problem looked to me as if  "Loader" was being held by SDX, like any other regular cart, but SDX could not be pulled out of the way (only on that Colleen profile).

 

Looking back at my recent testing activity, I can only think of two out-of-the-norm events that may have induced this anomalous state:

 

1. PBI tests with SysCheck-II (tracking external OS-switch in/out behavior).

2. Accidental Side-2 plug-in on left port without powering down the system. Just had to power-down afterward, nothing else.

 

Nevertheless, and as stated above, "D" defaults-reset from BIOS got everything fixed at the offending profile. Everything now is working as expected.

 

That's all to report on my side.

 

Cheers!

 

[flashjazzcat]

Thanks for the info. I wonder if 'Extsel mode' has some effect here, since I can't think of anything else which gets reset by default settings which could affect the behaviour of the external cartridge. I'll have another look later on just to eliminate this.

 

The 'external' 16K loader cart is disabled as a matter of course if the intention is not to run the loader directly from the BIOS (either via 'Boot to Loader' or explicitly launching the loader). Cartridge management did change, however, both in the JED and the BIOS (partly in order to allow the loader cart to be reactivated by a jump through DOSVEC from a loaded XEX), so I would not be surprised if there's some obscure issue.

[Faicuai]

4 minutes ago, flashjazzcat said:

I wonder if 'Extsel mode' has some effect here

TOTALLY valid, and I completely forgot to mention this (total dumb-ass on my part).

 

Had the exact same thought, and I tried EXTSEL modes before profile-resetting and fiddling with anything... to no effect. Then proceeded with "D" defaults-reset.

 

So whatever "D" affects / touches, not only solved it, but may also hold a clue to whatever may be involved in the anomaly. Admittedly, it takes quite a bit of testing and fiddling, and unlikely to show up that easily, for the majority of the installed base.

 

I will only come back at this, if and only if I can systematically reproduce it.

[flashjazzcat]

OK, well that saves me the trouble of looking. Reset defaults does nothing fancy other than resetting the configuration to default values, so it does look like some setting inadvertently affected loader ROM behaviour.

Edited September 7, 2021 by flashjazzcat

[Faicuai]

Alrighty, it seems we found a new "booboo", here.

 

Summarizing:

1. The problem involves ANY version of Ultimate/SD cart FILE-loader (.XEX, etc.) and latest .JED for Incognito.
2. The problem is fully mitigated if .JED is downgraded to last, most-current known production version (also posted on this thread). Incognito BIOS does not seem directly related to the problem (in fact, BIOS loader works beautifully).
3. The symptom is that .XEX files will crash during or right after loading. Further inspection with Turbo-Freezer (at every step of the process), reveals that files do not seem to be correctly located / uploaded in RAM during actual loading process from cart.
4. As an example, this file can be used as test-target: atbas157.rex. It (should) pre-load @ $4000-$5FFF before processing, yet it appears ~ $20B0, instead.

Since it is systematically repeatable on my end, it seems worth attempting to replicate on someone's end, and if confirmed, figuring out why the latest .JED and Ultimate/SD cart are interfering with each other (pretty strange, I would say). Who knows where this problem could should up, as well.

 

Thanks!

[flashjazzcat]

On 9/20/2021 at 8:27 PM, Faicuai said:

Alrighty, it seems we found a new "booboo", here.

Thanks. Since the Australian Incognito 800 still can't be shipped back to the customer, and since I can't possibly put the new JED on a customer machine yet, I'm going to abandon plugins for Incognito for the time being if nothing gets sorted out in the next couple of weeks (or in whatever time-frame the customer sees fit). It was extremely useful having two Incognito 800s here for testing (my own with SCCC, and the customer machine with the stock CPU board and Sophia 2), but I can't keep the client's machine indefinitely (it arrived here months ago, waited weeks for other parts to arrive, and has now sat doing nothing for over a month). Nor can I clutter the desk with dismantled 800s when I have other work piling up, and I have already fallen way behind owing to a family bereavement and various 'Sod's Law' issues.

[Faicuai]

6 hours ago, flashjazzcat said:

I have already fallen way behind owing to a family bereavement

My best wishes, there. Hopefully calm waters, ahead.

 

From what I read above, I was not sure if you could not send the 800-Sophia II back, while sitting there and killing desk space, etc. But, in any case, I will volunteer my basic assets here (including scope, etc.), for whatever other testing maybe required (in parallel, and in the meantime). For some reason, it seems lately that if there's a "roach" in the kitchen, I will somehow find it... (don't ask my why or how, though).

 

So what I can do is continue reporting all the issues I find (systematically repeatable) on this thread, so at least we have a central place to check them out for resolution, whenever possible.

 

Speaking of which, here comes the next one... 8-)

[Faicuai]

Ok, so it seems we are on a roll, here.

 

Here's the next one, which was accidentally discovered during the last 24 hours, in the midst of unrelated testing:

1. This problem involves:
   • Incognito with latest .JED and latest BIOS.
   • Optionally, Ultimate/SD or AVG cart (it will not matter which).
2. The main symptoms of this one are:
   • a) 130XE RAM (in CompyShop) becomes inoperable or inaccessible (65-128KB banks, at minimum), even at OS Self-Test (!)
   • b) Prince-of-Persia predictably fails right before Palace-screen ONLY in CompyShop. However, RAMBO mode works perfectly.
   • I am presuming that 1.a and 1.b above are linked / related, so solving one, should solve the other. I may be wrong, though.
3. The easiest way to replicate 1.a) is to:
   • Set BIOS profile on 576KB CompyShop mode and XL/XE OS of choice.
   • Load attached .XEX file from BIOS LAODER, and select "RAM" test ( XETESTR2.xex )
   • Notice that Bank-Testing will NOT be performed (message absent in text-window), ending quickly in "PASS".
   • What normally happens, instead, is that after base-memory is checked, x4 BANKS are tested on 130XE mode.
4. To optionally test 1.b), all is needed is:
   • Set BIOS profile on 576KB CompyShop mode and XL/XE OS of choice.
   • Insert AVG or Ultimate/SD cart, and load PoP June version ("bugs fixed') SIC or MegaCart images.
   • Wait for it to run, as it will crash (blank-screen) right after "Vizier / iron-fist" story-line.
5. ALL of the above symptoms are FULLY mitigated when rolling-back to latest-known Production .JED (as I have confirmed today).
6. ALL of the above issues DO NOT show on my 800XL / Ultimate1MB, when performing identical tests on 576KB CompyShop mode.

 

Hopefully, the above list is simple and clear enough to quickly replicate and confirm the problem on anyone's end. However, if results are different, please, post them here, too (that would be head-scratching, to say the least).

 

Anyway, there we go!

[flashjazzcat]

49 minutes ago, Faicuai said:

From what I read above, I was not sure if you could not send the 800-Sophia II back, while sitting there and killing desk space, etc.

Correct. The sentence is ambiguous. I meant that I can't send the machine back to the owner with the new JED on it while there are unresolved issues with said JED. I have presented him with a set of possible outcomes/workarounds, including shipping it back with the original JED pending an in-field update at some point in the future. We will see what's best for him.

49 minutes ago, Faicuai said:

So what I can do is continue reporting all the issues I find (systematically repeatable) on this thread, so at least we have a central place to check them out for resolution, whenever possible.

Absolutely. I don't want to close down or abandon the discussion; I just mean that I can't develop/announce/provide functionality that isn't yet in a relase state.

49 minutes ago, Faicuai said:

But, in any case, I will volunteer my basic assets here (including scope, etc.), for whatever other testing maybe required (in parallel, and in the meantime).

That's helpful. The very fact you were instantly able to replicate the primary issue (DS1305 NVRAM readback) definitely cut to the chase.

21 minutes ago, Faicuai said:

Hopefully, the above list is simple and clear enough to quickly replicate and confirm the problem on anyone's end.

I'll devote time to further testing when the next debugging session happens, if it happens.

Edited September 22, 2021 by flashjazzcat

[Faicuai]

On 9/22/2021 at 1:24 PM, Faicuai said:

The main symptoms of this one are:

• a) 130XE RAM (in CompyShop) becomes inoperable or inaccessible (65-128KB banks, at minimum), even at OS Self-Test (!)

 

 

@candle:

 

After some deeper testing, just wanted to formally report and confirm that 576KB CompyShop mode is inoperable / broken with latest beta- .JED

 

The problem is (for sure) base-memory (0-64KB) corruption when using/accessing extended 512KB memory. Verified in two ways:

 

1.  TKS Pagefind RAM+Timing tests (Option "1") for SDX results:

 

 

 

2. A simple copy of my 512KB Incognito ROM file from one APT partition to another one, on Incognito's HD, will result in a corrupted / unusable copy (the file will not be the same as the original). This pretty much seals it. It does not happen when switching to Rambo-mode.

 

At this point, I have ruled out problems with my local HW / host, because these anomalies disappear when reverting back to production .JED.

 

Sounds to me that this needs immediate attention (hope you can replicate the above results on your end).

 

Thanks!!

 

 

[candle]

can't confirm

 

xetstr2.xex you've linked above works for quite some time, then displays testing banking, and then finally "PASS"

 

the only other piece of software i know that utilises compy shop memory upgrade is "video blits"

 

i can't find software you're reffering to on last pictures, if you could just post it here, it would be nice

 

and pardon my ignorance, but i don't know what to do with "*.rex" files

 

[Kyle22]

Any chance of a joystick port cable to flash Incognito JED image, or does the 800 need to be off?

[candle]

800 needs to be on, but i can't program itself, so you would need another one to get the job done

 

this concept of using joystick port for programming these old cpld chips has been in my mind for quite some time, there is serial vector format (SVF) https://www.xilinx.com/support/documentation/application_notes/xapp503.pdf that would be convinient to do just this, but software on atari side is missing

if anyone is willing to develop it - let me know

 

[Faicuai]

13 hours ago, candle said:

xetstr2.xex you've linked above works for quite some time, then displays testing banking, and then finally "PASS"

Ok, this is not happening on my end, no matter what I try (I already had tested VideoBlitz since it is, indeed, my go-to-test for separate Antic ram-access, and it did work).

 

However, the problem here is corruption of main-memory during typical banked-memory access, in such mode (Compyshop)

 

I am going to repeat my tests here today ASAP, with my spare Incognito (extra board) and make sure I am also replicating the problem there. I will also post for you all test SW, here.

 

(NOTE: you can rename .REX to .XEX, as it is fully executable, sorry for not being clear).

 

[+Stephen]

4 hours ago, candle said:

800 needs to be on, but i can't program itself, so you would need another one to get the job done

 

this concept of using joystick port for programming these old cpld chips has been in my mind for quite some time, there is serial vector format (SVF) https://www.xilinx.com/support/documentation/application_notes/xapp503.pdf that would be convinient to do just this, but software on atari side is missing

if anyone is willing to develop it - let me know

 

@mytek has a JOY2PIC programmer that loads a custom ATR on the Atari, and uses the joystick port to program various PIC chips.  Perhaps the code can be easily modified to handle this?

[+mytek]

1 hour ago, Stephen said:

@mytek has a JOY2PIC programmer that loads a custom ATR on the Atari, and uses the joystick port to program various PIC chips.  Perhaps the code can be easily modified to handle this?

I can't take credit for this, besides suggesting the concept. It was thanks to @dmsc that it became a reality. He coded the program that creates the PIC flashing file that is loaded and run on the Atari. He also developed the hardware that plugs between the joystick port and the PIC chip via a serial programming interface. My only claim to fame on this project was laying out the PCB.

 

JOY2PIC project

 

[+Stephen]

Apologies to dmsc - I did not recall who did the hardware/software, just wanted to get the info out.  Too many new toys, which is always a great problem to have.

[Faicuai]

4 hours ago, Faicuai said:

I am going to repeat my tests here today ASAP, with my spare Incognito (extra board) and make sure I am also replicating the problem there.

@candle

 

Alright!

 

So I swapped out my current Incognito board (latest production, with on-board HD-led near its top pin-header) and replaced it with back-up from your 2nd-batch production. Proceeded to flash latest BIOS firmware and latest .JED, and it is 100% CONFIRMED: my back-up Incognito board also shows the exact same base-memory corruption when running certain tasks on 576K CompyShop mode. The mitigation to the problem is also exactly the same: ROLL-BACK to prior (production) .JED.

 

To avoid any confusion, let us all make sure we are seeing the same HW/SW config. for these tests. Here's a screen-shot from my BIOS info. screen:

 

 

 

Last but not least, here's an .ATR with MEMCHECK. Please, configure system for 576K CompyShop mode, BASIC=enabled, attached .ATR as D1: and boot SDX from it, so it will catch CONFIG.SYS and AUTOEXEC.BAT from it. Run with INTERNAL basic option, from main menu, then Test #1 from following menu:

 

Scratchpad-SDX-180K-I.atr

 

The problem will also show with simple operations in SDX: attempting to COPY a large file from one place to another (internal HD, .ATR, RAMDISK, etc.) will yield in a CORRUPTED copy, that is, the original and copy files will not be the same).

 

Let's hope this helps replicating the problem easily on someone else's end, too.