Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

872 Excellent

About Faicuai

  • Rank
  • Birthday October 11

Profile Information

  • Gender
  • Location
    Florida, U.S.A.
  • Interests
    Auto Performance, Photography, Retro-Computing, Audio/Video

Recent Profile Visitors

11,399 profile views
  1. As a matter of fact, no one here (no one) will become famous posting videos, tutorials or any other resources related to upgrade-installs on 35+ years old equipment (without mentioned the limited stream of buyers of such upgrades). It is clear that fame is hardly the (real) reason folks here are devoting quite a good deal of time and attention to share their knowledge and / or experience. It would be delusional to think otherwise. We are all smart enough to know this, already.
  2. No, let me re-iterate what I wrote and meant (no need for space-time-warping of it): Besides introducing a non-reversible (trace cut) change on the power-board, the dumb-ass flashing led is not really needed... especially now that I can hear .ATR sound-synthesis thanks to your BIOS. So why in the world would I recommend cutting the original boards, when I can just soft-enable audio-feedback anytime I wish? That is the choice we really need to leave on the hands of the audience, though, instead of being driven to (right-out) cut their boards... As for reversibility, nothing beats a clean, and untouched motherboard (e.g. no trace cuts, drilled-holes, cut / bent / ripped-out component, after-the-fact patching cables, etc.) Talk about something I definitely can't really recommend openly, especially for equipment of this age, and if you want to keep it in collection-grade status. At the and of the day, anyone here is free to have their machines as ghetto or as tidy as they wish. I rather start from the tidy side, and let the remaining downhill being a personal choice (much healthier approach).
  3. And now, for you what have not been told regarding Incognito's install (mode of devil's details): When planning your install, consider the possibility of full-and-complete reversion, without leaving ANY trace that it was ever installed (if needed to be removed, later). For the above reason, all sampling-wiring (all of it) goes at the bottom-side of the motherboard, where it will all become visible in one stroke, except CPU-board signals (x2) which you pick-up directly there. You should choose beefy / thick wiring, as much as bending/flexing needs allows for routing / fitting jumpers back up to Incognito's headers, on expansion bay. It is strongly advised not to use crappy, overly thin cables, if possible. Much better to buy them prewired, pre-terminated on multi-color ribbons and separate them if needed (Amazon has them). For the same above reason, considering skipping the "flashing-led" install (it is not needed), as it will create a non-reversible modification IF the originally suggested trace-cut is performed on power-board. If you can make it non-reversible on your end, then fine! There is a very HIGH chance that your 800 is over-driving the Luma signal, provided on its Y/C/Composite video port. If this is the case, it will hardly pass a tonality-test range on s-Video NTSC output (e.g. showing full tonal depth from 0 to 15 levels, blowing out bright, the last two), which will reduce effective dynamic-range of your video signal. This problem is cured by replacing R189 (very easily) and, while being a reversible change, it is actually an permanent enhancement, which will also lead to a much better gamma-response / reproduction, once the new resistor is in place. When physically fitting your Incognito board on the expansion bay, either today or in the future, DO NOT EVER, NEVER plug it in any other slot other than the Personality slot, and much less attempt to fire-up your 800 host, while having that baby plugged on the wrong slot. I learned this the hard way, accidentally, while dealing with multiple problems with a defective (chinese) JTAG programmer / header (during CPLD updates). Choose wisely the spot where your .ATR / SIDE image-flipping switch will be installed. The 800 case is superbly designed, and provides plenty of places to install it, out of sight, while still accessing it quickly. The above and a bit more, may be found graphically on the link below, as well as several other (great) install resources stemming from the initial-wave of Incognito installs, back on its introduction days: Have fun and enjoy a truly wonderful and unique upgrade !
  4. Yes! (not a single trace, and not a stupid-looking, protruding cart in the middle-top of your machine, which is inevitable on my 800XLs because of its not-so "radical" design...)
  5. No my friend, that's now what's needed. The 800's MoBo is (in comparison) more of a radical design, next to the cost-cutting / simplified design of the 800XL.The 800 (with its original MMU in place) provides dual floating data-buses, being the second one directly linked to the slot / place where the Personality board goes. What's odd, though, is that once Incognito is installed (as well as its integrated MMU-emulation), those dual buses are replaced by a single one, thus behaving more like a 130XE (that is, in today's Incognito's form). That is a DEEP change, for sure, not easily visible to the naked eye. All-in-all (and because of the 800's architecture), you will be able to enjoy it with Incognito in ways that are not possible with similarly upgraded 800XLs. Thanks to that "radical" MoBo design of the 800, you can hold a large-card like Incognito, and integrate RAM, ROM and SIDE/HD (on PBI-end) expansion, thus leaving not one, but two precious cart-slots empty, and free of any cart-port contention, which does limit my 800XLs / U1MB in a BIG way. As the old say goes: the devil is on the details...
  6. Bingo! Exactly what I've always thought! Make it lower-case, Italic, and proportionally smaller than the last "0" on the right. Classy and minimalistic (instead of a ghetto-like graffiti)
  7. 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!
  8. Well, after meeting almost all of my needs with Ultimate1MB/SIDE I-II and Incognito/SIDE combos, I finally came down to two candidates that would make sense on my current platforms: The!Cart and Ultimate-SD. These two were the ones with the right balance of features and form-factor compatibility (e.g. they run perfectly fine on the ENTIRE line of Atari computers, which is not the case, for instance, with AVG cart, or even my SIDE 1/2). And, at the end, I decided for the Ultimate/SD cart, as it is very easy to add carts to its on-board SD card, as well as having gobs of horsepower under the hood. So much (in relative terms) that a Veronica emulation load has been created for it, so it can enhance the 800/XL/XE with additional processing power, behaving as a co-processor too (!). Generally speaking, anything that has not been designed to fit or run properly on the 800 is automatically off the list (the 800 will be the ONLY system on Atari lineup that will be capable of running these carts with NO cartridge-port contention, when simultaneously using Incognito's internal HD (SIDE) AND the attached multi-cart on LEFT-cart port (something not naturally possible on my 800 XL/U1MB). Having said this, The!Cart and Ultimate-SD will do really well for most users, especially if they already have Ultimate-1MB/SIDE or Incognito/SIDE running.
  9. This is what I am getting on my end (with and without Extensions loaded): On legacy DOS (as booted directly from attached .ATR above, NO DUP-SYS): ? FRE(0): 32782 ? FRE(1): 32782 ... ? FRE(9): 32782 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!
  10. 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!
  11. 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!
  12. Absolutely, no doubt about it: we have already reached end-of-line for this fragmented and non-cohesive approach to designing and building mods, that, at the end of the day, do not really leverage each other, nor the host system's architecture (e.g. PBI BUS, in-rom-support, etc.) We just have enough of these (with some notable exceptions, of course, being Ultimate/SIDE and (especially) Incognito, the most "integral" of the bunch. Time to evolve.
  13. FYI, ran a binary-compare with the 3.9-t11 OS-rom sets with 3.90-t10 and they seem identical (specifically, XL-type). This means that they still fail to load / boot with real IndusGT drives, on real Atari host. I also tried on my 800XLs and exactly same problem (this is with single-density disks, std. Atari-DOS format). Probably not an area of focus on the current .point release, though, but thought of confirming the issue, anyway.
  14. Perfectly fine with whatever modular approach you take, as long as memory-access penalties are kept at a minimum. I wanted (or wondered) about extracting down to the last drop of speed (I hoped it would be obvious from my question). I do wonder, however, if cross-compiler variables-allocation (and other optimizations) could also be incorporated into native 6502 compiler, running directly on Atari host. That's precisely the problem with current code: it does not even read existing (already-set) values of 709,710 locations (!) As an example, you may try on your own adding "SCRDEF=10,160,0,0" to your SDX autoexec.bat, in plain simple 40-col. Then invoke FastBasic editor, and watch what happens. I DO SEE it working well when loading RC_GR8.SYS and CON.SYS with a specific SCRDEF declaration during driver load. However, it does not really work for 40-cols (seems like defaulting to what is hard-coded on OS). Please, let me know what exact FB thread you refer to in the Programming forum, and I will ask this whole chain to be moved there. Cheers!
  • Create New...