Jump to content

Faicuai's Photo

Faicuai

Member Since 5 Apr 2011
OFFLINE Last Active Apr 10 2019 7:49 PM

#4255634 Can you go home again?

Posted by Faicuai on Wed Apr 10, 2019 7:33 PM

If you are asking it, is because, deep inside, you already know the answer.

 

Gram-for-gram, byte-for-byte, the 800 has NO substitute and, loaded with incognito, you will NEVER ever look back.

 

Go home!

 

post-29379-0-78192000-1369677578.jpg  post-29379-0-30485500-1369677559.jpg  IMG_3495.JPG




#4201349 Power on off wait times

Posted by Faicuai on Sat Jan 19, 2019 8:17 PM

never-mind.... Faicuai corrected his mistake, and the rest of it was ok... but I think we should all still program/release software none the less ;)


Yes, so in summary for anyone needed a fast base-ram erase WITHOUT cycle-powering and waiting for ANYTHING (for XL/XE OS):

1, Store $FF (255) in $0244 (580).
2. Jump to either $E474 (58484), or directly to OS documented PWS entry point, $C290 (49808), which is where $E474 will take you, anyway.

Bam! Full reset, and base memory is ALL clear, until the first NON-RAM address.


#4201330 Power on off wait times

Posted by Faicuai on Sat Jan 19, 2019 7:43 PM

/headdesk.
 
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.


#4200522 Last of the Incas

Posted by Faicuai on Fri Jan 18, 2019 7:24 PM

attachicon.gif Last Of The Incas.png

 

Unreleased, never completed, Atari 8-bit game, "Last of the Incas", by Atari/Chris Crawford from Feb - Mar 1984.

 

Source Code .PDF: attachicon.gifLast Of The Incas.pdf

 

attachicon.giflast-of-the-incas.zip

 

 

 

 

 

SICK !!!

 

Gotta LOVE these out-of-the-hat rabbits!




#4198805 classic battle atari 8bit vs commodore 64

Posted by Faicuai on Wed Jan 16, 2019 1:49 PM

Stand alone.  Should work on any machine, at least I think anything 64kB or above.  Latest version is 2.25, and can be found at http://drac030.krap.pl/en-si-pliki.php

 

latest version (2.25) DOES NOT work properly. That is, it DOES NOT detect AXLON 1MB expansion correctly in Colleen mode, whereas 2.24 works perfectly.

 

Thought you should all know.




#4198540 classic battle atari 8bit vs commodore 64

Posted by Faicuai on Wed Jan 16, 2019 7:47 AM

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...




#4198275 classic battle atari 8bit vs commodore 64

Posted by Faicuai on Tue Jan 15, 2019 7:25 PM

 

Easy as pie:

 

1. Fire up your Incognito or Ultimate-1MB setup under SDX, with PBI=ON and HD=ON on advanced BIOS.

2. on SDX prompt, load System Information 2.24 (SI 2.24), and set IO to OS, and DMA=OFF.

3. Run HD performance teds (preferably on empty HD / APT partition on SDE 1/2).

 

That gives you an idea of MAX attainable performance, but WITHOUT knowing exactly the logical structure / size of records being moved (overhead).

 

I will post a direct screen-shot from actual HW, later, once I have a bit more time for pix. capture, upload, etc. Note that all my timings are NTSC (!)

 

That's all.

 

Here they are:

 

IMG_3493.JPG IMG_3491.JPG  IMG_3495.JPG




#4197945 classic battle atari 8bit vs commodore 64

Posted by Faicuai on Tue Jan 15, 2019 10:45 AM

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"). 

 

Understood.

 

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.




#4197938 classic battle atari 8bit vs commodore 64

Posted by Faicuai on Tue Jan 15, 2019 10:38 AM

Which test yields the figures you're observing?

 

Easy as pie:

 

1. Fire up your Incognito or Ultimate-1MB setup under SDX, with PBI=ON and HD=ON on advanced BIOS.

2. on SDX prompt, load System Information 2.24 (SI 2.24), and set IO to OS, and DMA=OFF.

3. Run HD performance teds (preferably on empty HD / APT partition on SDE 1/2).

 

That gives you an idea of MAX attainable performance, but WITHOUT knowing exactly the logical structure / size of records being moved (overhead).

 

I will post a direct screen-shot from actual HW, later, once I have a bit more time for pix. capture, upload, etc. Note that all my timings are NTSC (!)

 

That's all.




#4194284 Is possible to upgrade the memory on the Atari 800 ?

Posted by Faicuai on Wed Jan 9, 2019 6:14 PM

Hi someone knows if possible/how to upgrade the ram on the Atari 800 to get it compatible to the Atari 800 XL 64k ?

Maybe some product that is for sale ?, or a hardware hack ?.

 

:D

 

Here, you can have a little taste, while you prepare U.S. $250 to $300 to convince an existing Incognito owner to sell his board:

 

http://atariage.com/...tive/?p=2762116

 

As an owner of twin 800XLs and 800-i, no doubt the 800 is the real McCoy, in that group.

 

IMG_3360.JPG

 

Cheers!




#4193980 classic battle atari 8bit vs commodore 64

Posted by Faicuai on Wed Jan 9, 2019 11:42 AM

 

Yeah, just that tiny, uninmportant little detail.

 

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.




#4193866 classic battle atari 8bit vs commodore 64

Posted by Faicuai on Wed Jan 9, 2019 8:11 AM

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
 
:-D


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...


#4191261 New (alt) BIOS for Ultimate 1MB/Incognito

Posted by Faicuai on Sat Jan 5, 2019 3:02 PM

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):

attachicon.gifIncognito Beta Test 050119.zip

 

ROMA VICTOR !!!

 

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 !!!

 

Our work here is now done!




#4187172 Atari 8-Bit as a Legitimate Business Machine

Posted by Faicuai on Sun Dec 30, 2018 4:56 PM

Apparently a picture of an early IBM proposal based on the Atari 800:
 
https://plus.google....sts/ZHLeJ1nQpZq



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 (!!!)

GREAT story, here!


#4184477 New (alt) BIOS for Ultimate 1MB/Incognito

Posted by Faicuai on Wed Dec 26, 2018 10:59 AM

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.
 
attachicon.gifIncognito Beta Test 261218.zip
 
Flashed to my own Incognito here without incident. Feedback appreciated.

F-Beautiful (!!!)

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... ;-)