800 / INCOGNITO: Floating Data-Bus woes...

[Faicuai]

12 minutes ago, orpheuswaking said:

OmG!!

 

Don't wait there like a useless by-stander, and call Animal Abuse! Do something!!!

 

:-))

[_The Doctor__]

I'd say warerat has pretty much nailed it down, and candle will act on what he can.

Warerat had the idea for this sort of thingamajig and has the engineering know how to dissect and construct these devices without issue and more times than not, is spot on with fixes updates and obervations (hardware, firmware alike).

 

As for the dead horse... I'm pleased the horse is now glue and has been used to fix a number of items that really have helped make the incognito as great as it now is. Mooooving on to the cow just means we may get the last few things of udder bliss handled as well... though there is some question as to whether will be getting steak or cheese. I think either will be tasty!

[Faicuai]

UPDATE:

 

Well, just received my Ultimate-SD Cartridge, and put it to work right away (have a bit of mixed emotions about it, though).

 

When I saw Basic/XE imploding when launched on Incognito platform (from SIDE 1/2 in multi-cart mode), it just looked very suspicious to me, especially when I could launch it on my XL / Ultimate's (putting aside the XE-Extensions head-ache).

 

After some work and attention to this matter, the problem did boil down to floating-bus data stored on $D013 and flown-back to $03FA (GINTLK) shadow register. The OS does NOT specifically enforce the nominal "$00" or "$01" values when its watchdog-check compares active-vs-mirrored values (it only enforces "<>0" condition), but the folks at OSS *did* enforce the $01 value (and updated GINTLK accordingly) to secure corresponding OS-checks which, consequently, meant an immediate mismatch on Incognito (e.g. writing $01 on GINTLK instead of $D0, because $D0 (floating-bus data) is what is really mirrored by Incognito). By the time the OS watch-dog runs the check, it encounters $01 on $03FA (GINTLK) and $D0 on $D013 (floating-bus data) making Basic-XE and Extensions crash hopelessly. In short, BasicXE and Extensions would have NEVER worked on 800/Incognito, as originally coded, because of its floating-bus woes).

 

Fortunately, there is a solution. Here's Basic/XE v4.1i, together with its Extensions companion, now fully operational under Incognito. Not only works under direct Atari DOS boot, but it is also compatible with SDX (you can just drop in the .OSS file on your HD-based Basic working directory, and when typing "CAR", Basic/XE will load it from active SDX directory, automatically and flawlessly, which is a critical improvement inherited from 4.1p version).

 

BasicXE-v41i-SDX.car

BASIC XE Extension Disk (A).atr

 

Instead of littering the ROMs and files with NOPs ($EA opcodes), I actually left the core instructions untouched, and let the STA/STX salvos float in the bus (re-vectored them to $A000-$BFFF rom-space), which allows to keep them in place, and immediately reverse the changes with a simple search-and-replace of $BFFC by $03FA. on my binary editor (if I wish to do so, or to later re-vector them again somewhere else). It also ensures a cycle exact execution, just in case.

 

I have not tested v4.1i on my Ultimate's, but can't see any reason why it would not be cross-compatible with that platform, as well.

 

Hope they work for you as well as they are working here. Cheers!

 

 

Edited October 9, 2019 by Faicuai

[_The Doctor__]

@Faicuai

Nice patch around... I like how you work through the problems and come up with solutions without beating the world up (unlike the horse or cow) in the process... I'd want you on the team, any team, anytime!

What happens with Wargames though...

I have not found the original in my boxes of stuff, it must have walked with all the other stuff that was stolen years back.

 

Loving what you do & love how you do it,

_Doc Brown__

Edited October 9, 2019 by _The Doctor__

[Kyle22]

Thanks! I tried it and it works. ?fre(0) gives 33980 and ?fre(1) gives 65520.

Now I must check out FXEP.

:)

 

[Faicuai]

8 hours ago, _The Doctor__ said:

@Faicuai

Nice patch around... I like how you work through the problems and come up with solutions without beating the world up (unlike the horse or cow) in the process... I'd want you on the team, any team, anytime!

What happens with Wargames though...

I have not found the original in my boxes of stuff, it must have walked with all the other stuff that was stolen years back.

 

Loving what you do & love how you do it,

_Doc Brown__

Likewise Doc, looking forward to have you around, always!

 

As for Wargames, it would be wonderful if you could find your copy... although my prediction is that it will NEVER run (as originally coded) on 800/Incognito, NOT EVEN in Colleen mode, as the dual floating-data buses (data held on bus on empty addresses < $C000, vs. data held on addresses >=$C000) have been stripped from current Incognito implementation (it resembles the 130XE floating data-bus, instead).

 

Addressing the above will certainly require important re-work at CPLD level, but it is unclear if there are still resources / space left for the additional code / fixes (being $D013/TRIG3 the most important one, now, so we don't get floating-data on flown back to GINTLK ($03FA).

 

I also have some other cool (and useful) things on the pipeline, which I will share later. It will be fun, I think. ?

 

Cheers!

[Faicuai]

2 hours ago, Kyle22 said:

Thanks! I tried it and it works. ?fre(0) gives 33980 and ?fre(1) gives 65520.

Now I must check out FXEP.

 

This is what I am getting on my end (with and without Extensions loaded):

 

1. On legacy DOS (as booted directly from attached .ATR above, NO DUP-SYS):
   • ? FRE(0): 32782
   • ? FRE(1): 32782 ...
   • ? FRE(9): 32782
2. On SDX 4.49c, with ENV, Ult-Clock and DOSKEY installed:
   • ? FRE(0): 35262
   • ? FRE(1): 35262 ...
   • ? FRE(9): 35262

Let me know how it goes with FXEP. Besides GINTLK/TRIG3 equivalence-vectors, the rest of the ROM (and .ATR) packages are intact, with absolutely no changes whatsoever to their logic or code-base. They should run as intended.

 

FORGOT to say: this Basic/XE package (with its corresponding extensions) is WICKED-fast, relatively speaking (!) I have already run a series of tests targeting every achiles-heel that I can shoot from my arsenal, and I am really impressed... even beating Altirra Basic 1.56 in some particular tests, and coming close to the much larger / extensive Altirra Basic/Extended. I will be testing more closely vis-a-vis with Basic/XL but with a super-charged FPP package only accessible by it (Basic/XE has its own already, and "FAST" is not enabled unless you let it load the extensions!)

Have fun!

 

Edited October 10, 2019 by Faicuai

[Faicuai]

On ‎10‎/‎10‎/‎2019 at 1:51 AM, Faicuai said:

This is what I am getting on my end (with and without Extensions loaded):

 

1. On legacy DOS (as booted directly from attached .ATR above, NO DUP-SYS):
   • ? FRE(0): 32782
   • ? FRE(1): 32782 ...
   • ? FRE(9): 32782
2. On SDX 4.49c, with ENV, Ult-Clock and DOSKEY installed:
   • ? FRE(0): 35262
   • ? FRE(1): 35262 ...
   • ? FRE(9): 35262

Let me know how it goes with FXEP. Besides GINTLK/TRIG3 equivalence-vectors, the rest of the ROM (and .ATR) packages are intact, with absolutely no changes whatsoever to their logic or code-base. They should run as intended.

 

FORGOT to say: this Basic/XE package (with its corresponding extensions) is WICKED-fast, relatively speaking (!) I have already run a series of tests targeting every achiles-heel that I can shoot from my arsenal, and I am really impressed... even beating Altirra Basic 1.56 in some particular tests, and coming close to the much larger / extensive Altirra Basic/Extended. I will be testing more closely vis-a-vis with Basic/XL but with a super-charged FPP package only accessible by it (Basic/XE has its own already, and "FAST" is not enabled unless you let it load the extensions!)

Have fun!

 

Correction (apologies in advance):

 

Available RAM (as reported) above is with or without Extensions loaded, and (when loaded), without issuing "EXTEND" command.

 

Once "Extend" has been issued, I am getting the following results:

 

? FRE(0) reports 34,504 bytes free

? FRE(1) reports 65,520 bytes free (matching your numbers, as well).

 

So memory allocation in extended mode (XE-128K) appears to be working correctly, as well!

 

Cheers!