Just the mere fact it's in the $Cxxx area means it's outside the realm of the original OS.
"Documented" doesn't mean squat. It's still not a recognised legal entry point, and the only usage case would be if you're developing a custom OS and using it from within it.
Anyway - feel free to continue your false beliefs, it's not as if you'll be releasing software that's going to affect people due to them.
Of course I will. I would only correct that it is $C290, instead of $C2A1 (that was from my own memory, just checked my own dissassembly-notes). In fact, $E474 is a mere jump to $C290 (PWS) which is why PWS is declared as official entry point in source code.
$C2A1 is PWS1, which allows to test COLD-START without veriying cart-equivalence (status), which I needed for some particular carts and test scenarios. In BOTH cases, BASE MEMORY will be erased if $0244 is set to $FF first, without even cycling the power switch, which will help anyone here having delays with RAM-content reset.
You don't know the OS deeeply enough, and for that, no one needs to be releasing any software, of any kind.
Do I love the 800.... even I like the XL models...
I would have to agree... as much as I like my twin (identically manufactured and equipped) XLs, it seems clear that, gram-for-gram, byte-for-byte, the 800 has no substitute. Talk about the real McCoy, as I have said before...
Well it certainly does not look like static animated 16 colour C64 screens which anybody with a set of eyes can plainly see. This is what I was replying to in my original post ("it wouldn't look like TV, it would look like full screen C64 animation").
But the FRAME-DROPS are disturbing on those samples. NTSC TV is not like that, not even REMOTELY.
My apologies if I did not clearly emphasize this point.
You could clearly say, on the other hand, that the C64 could play back video at a potentially higher resolution (and more colors?), but not meeting NTSC (broadcast framerates) and possibly NOT being able to do so with its on-board resources... That will not necessarily invalidate it, just frame it in a different implementation context.
The Atari, on the other hand, is more of a show of brute force of all on-board core components in concert, for this specific application. I honestly don't expect anyone here watching lengthy videos on either platform, anyway.
I really like these threads...they do yield some comedy gold occasionally
It seems you missed the point:
NO ONE here will restrain you (in any form or shape) to go back to your kiddie C64 computer (if you own one). You are absolutely free to do so, and that is PRECISELY why you have so many games for it. I am SURE that, among the large heap of kiddie stuff, you may find something worth of your or anyone else's time, for this matter. For the rest, I would wholeheartedly agree that you will find plenty of your comedy-gold material, there.
I know i'd pick the 800XL over the C64 every day as all round home computer lets look at some of piss poor features of C64
Bad and failing PSU
Terrible video out with jail-bars
Crap version of basic
1541 drive that cost almost as much as the C64 yet as slow cassette unit if not slower
Running hot SID AND VIC ll chips
Multiple revision of chips due to costing cutting = poor quality
Over priced games machine
The only advantage i see for the C64 there was more games
Interestingly, that matches very closely my own recollection from the time I (first) worked at a computer shop, selling them (actually selling ANYTHING you can imagine, from Apple, Commodore, Epson, HP, IBM, etc.)
Even my Hong-Kong Rev.C 800XLs (with ALPS keyboard and motherboard with red / integrated resistors on right-side ports), feels a lot better built than anything I handled from Commodore.
Now, the C64 next to the 800 feels like a kids toy, to be honest. Let's not even get there.
PS: one of the machines that could not find a commercial path on the U.S. but was, in my opinion, high up-there in design, performance and expandability was the BBC Micro... It was, as I remember it, the 1400XL of Britain... but in 1981-1982 !!! Graphics & sound aside, it had the architecture for running in circles around the C64, and even our Ataris, especially in some specific (but critical) respects...
I realised the other night that there was no need to disable internal BASIC via the HATABS patch employed for the PBI version notice anyway. The PBI BIOS always gets a crack at the first SIO request regardless of whether any ATRs or hard disk partitions are mounted on the boot drive, so it was sufficient to simply move the BASIC check to the top of the SIO handler. This avoids the awkward issues with Monkey Wrench II.
Here's an update (only the PBI BIOS has changed since last time):
Talk about a sweet and elegant solution!!! It JUST WORKS!!! Monkey Wrench II now boots exactly as INTENDED and just as it does on similar conditions on OS-b (!!!)
When flashing revised XE04-RC OS, then inserting right-cart (e.g. Monkey Wrench II), then setting Incognito BIOS to [SDX=OFF, Basic=OFF, PBI=ON, HD=ON] and pressing "B", followed by "D" and (say) "1" (with NO .ATR attached on APT or SIO sides), Monkey Wrench (or ANY other right-cart) now boots beautifully on A800-Incognito, FULLY initialized, with FREE $A000-$BFFF RAM, and WITHOUT Basic ever appearing, UNLESS you command so at Incognito BIOS, only (!!!)
We now have FULL, COMPLETE support of LEF+RIGHT cart (or for just ANY right-cart), booting on XL/XE mode under Incognito's advanced BIOS, without compromising ANY functionality originally contemplated on Atari OS nor the BIOS itself. Simply BEAUTIFUL !!!
So there it is, the story seems confirmed (I reported this, as well, weeks ago... but nothing like seeing IBM's internal proto-vision of the product!)
Nevertheless, it seems clear that, gram-by-gram, byte-for-byte, the sweet 800 is the real McCoy, and never had any real substitute in Atari line-up, afterwards. I can see why IBM lked it as well (had a more industrial, office-like appeareance, although it looks strange white-colored, instead). Truly the best of the best, in my opinion (and as much as I like my 800 XLs)... And with today's electronics' density, the 800 is a POWERHOUSE for pretty much any upgrade you can conceive! If it does ALL the cool things it does with just a personality board (e.g Incognito), imagine the kind of things we could do on the remaining three expansion slots + PBI bus on Incognito (!!!)
OK: here's some beta firmware with the changes I described earlier. See the readme file for details of the changes since the July 2018 release. Basically:
The loader's FMS driver (i.e. the thing that lets you access the FAT via D1: when you load an XEX direct from the loader) now supports paths and FAT subdirectories. It supports XIO 44 and 48 (CHDIR get GET CURRENT PATH respectively) in a manner generally consistent with SpartaDOS X. No long directory format or RAW directory access or any of that stuff; only what's needed to get full access to the entire FAT volume via the CIO. The supplied version of UFLASH - if run direct from the loader - supports subdirectories in the file selector (same way it does when run under SpartaDOS X).
The BASIC suppression/PBI version notice patch has moved from $8000 to $5000. The presence of right 8K or 16K carts should no longer obstruct management of internal BASIC via the (renamed) 'BASIC State' setting in the main BIOS. Note that the method of BASIC suppression employed to facilitate no-BASIC ATR and HDD boots has not changed.
The loader no longer runs code out of $8000-$9FFF. All RAM-based code has been moved towards the bottom of memory and the FAT directory buffer now starts at ~$5000 and extends up to the bottom of ROM, which is to say the loader's own ROM at $A000 or any other ROM at $8000 which can't be suppressed while the loader is active (which is really an Incognito-specific issue, although the U1MB benefits from the change too).
There's another tool called 'CLI.XEX' which is a simple shell for testing FAT folder tree navigation when run direct from the loader.
Flashed to my own Incognito here without incident. Feedback appreciated.
I am returning from short vacations with kids, today, and will be testing over the next 24-48 hours...
Based on results, I will seriously consider bringing RIGHT-cart boot-manager extensions for the XL/XE series, as well (e.g. ability to recognize and boot merged 8K+8K images with executable code on $8000-$9FFF space).
A HUGE thanks for going the extra mile on what is ALREADY a master-piece!!! It will not go unnoticed...