Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

637 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

10,742 profile views
  1. Obesity... at its FINEST !!! Great work, already had a run with it!
  2. Oh!!! Did not capture / read that it was your camera the one introducing such massive deviations from on-screen rendition... I hear you, I know exactly what you mean (same struggle here, at times...) It's all good then! Cheers and keep them coming!!!
  3. Mhmmm... Saw your image and it kind of looked odd (to me).... So decided to run .exe image on actual 800 + color-calibrated NTSC Analog-to-Digital video path (800->DVDO iScan->Viewsonic VP930b) and this is what I got (photo from iPhone, real image is much warmer and top blue band is much paler, in reality): In actual image/ screen, all browns appear much more brownish, and yellows much more yellowish.... but there is NOTHING red, of any kind. This is, again, a full NTSC frame from actual 800 hardware.
  4. If you have an ideal benchmark with the above intent on mind, I would run it here on all MS Basic versions (for Atari), as well as Atari Basic and Altirra Basic. In my opinion, MS Basic is almost ALWAYS faster than Atari Basic, and a moderately slower than Altirra Basic (on all the tests I have ran, so far). MS Basic comes with its own FP package, so has little dependence with system rom FP pack.
  5. As long as it contributes to attract top talent, spur f-awesome ideas and... bring back Candle, I say ABSOLUTELY, TOTALLY YES (!!!)
  6. Very nice and interesting discussion, to say the least... But, if I were on to this path, I would have started by simply taking a look at Apple's INTEGER Basic... That thing is REALLY FAST, considering the time and age and Apple II's 1.0 Mhz clock-speed... How things got implemented there, is probably a good starting point... Cheers!
  7. Sorry for taking so long to address this, but here are the results of Test 2 (complete SEPARATE and extracted out of the whole suite, typed in exactly as original test with 3-digit line numbers and no shortcuts, with the addition of ANTIC=OFF/ON commands), on Altirra Basic 1.56 (8K), and both XL03 and XE04 16K system ROMs tested with Incognito: XL03 ROM (High-Performance FP pack): 2.8 secs. XL04 ROM (Altirra FP pack): 2.0 secs. As predicted, no significant deviations in performance. Cheers!
  8. NICE!!!! Just got back from Europe (vacations) and still trying to catch up here and P.M.s (I even have some testing homework to do!) Well, just the fact that FastBasic now effectively supports arrays of Bytes, Integers (x2 bytes) and Float sets it on a class of its own... ...and, boy, would you look at those exec times! Almost THREE seconds shaved from my last recorded run! THANKS for this update!
  9. Not trying to make things worse, but... Here's something I have yet to disclose, since my last ad-hoc pilgrimage to Borregas Avenue (on my last vacation trip to the Bay area). I actually decided to go down to the San Jose area, and search for Best Electronics' place. After ending up in a tiny sh_t hole (to my continuous disbelief), I decided to venture inside of it, just hoping to buy two (expensive) items they had in-stock. After coming in, a rather short / skinny figure (with an Atari-emblem buckle on his belt, with Asian / Oriental facial features) emerges out of a TON of rubble and crap sitting all over the place. Filthy as hell, it was horrific to the eyes, but hey (I said to myself) "this is a bygone-era business, so don't expect anything fancy out of it..." Guess what? After almost not being able to breath in there, I was told I COULD NOT ORDER anything there, nothing could be delivered to me there, on the spot, and I better go back to on-line email for ordering.... I was like WTF (!?) I came here to spend almost $100 in obsolete technology and you still have the balls to tell me you can't sell me anything there? Fortunately, I already had bought quite a good # of parts and spares, so... sadly, that day was R.I.P. "Best" Electronics, for me...
  10. There will NEVER be a factor of x2 difference... especially since I packed ALL TESTS in a SINGLE source listing, which means adding a TON of line numbers to the tests I ran, which do not exist in the individual tests (e.g. my suite is heavier!) Just wait until I have the chance to extract Test #2 lines, and run them separately from the suite, with Altirra Basic 1.56 and Altirra FP package, as well as the very-high performance XL/OS FP package... all still contained in stock 16KB + 8KB rom space... 🙂
  11. Europe, multi-country... with family... Packed-days, back-to-back... you can imagine....
  12. Of course, not a problem (although I am traveling overseas, vacations, and will be back mid July). I will try to do it sometime via RPD on Win10, and check results. In the mean time, the sources are posted since day #1, and anyone can jump into them with Altirra Basic 1.56 and Altirra FP package (no interest on Atari Basic, as it is simply a very well known and solidly engineered dead-weight). If we insist on Atari Basic, I will also be interested, however, in equating ROM usage space to the HIGHEST driven by the machines on the test group. In other words, if the BBC uses 32K space for OS+Basic, I want the EXACT SAME space for the Atari, and use any other package that meets such criteria (I don't mind if any other versions or machines do the exact same, with the ABSOLUTELY BEST TOOL available, as long as we remained on the INTERPRETER domain). If you only have Altirra 3.20 Emulator, that is fine for running on your own, assuming that you use Avery's XL OS replacement. In this way, you should be able to check the difference on your end, at will. However, I anticipate (at this point) little impact, though, if the increment in time is estimated from current 1.9 secs, assuming the ingredients I originally disclosed (Altirra 1.56 + Altirra FP). Cheers!
  13. Absolutely correct. Atari Basic (and ANY derivative that pursues direct or replacement-grade compatibility) MUST BE and IS an <= 8192 bytes ROM package. Period. Not one byte more, maybe less. Now, that its design follows the premise of using the FP package as far as you can get away while NOT exceeding those 8219 bytes, is in fact a design and implementation decision that pertains ATARI BASIC. In that sense, the FP package is an OS RESOURCE, and NOT an Atari Basic one. And this on itself, introduces a HUGE benefit which is nothing else than performance elasticity (which seems completely overlooked here). You can optimize the 8K package (without ever touching OS resources) and still obtain higher performance. On the other hand, you can optimize OS resources and also obtain higher performance without EVER touching the 8K Basic Package itself. Now, You can optimize both and you will get fireworks!. This, however, CANNOT be achieved with Turbo Basic, MS Basic, etc. As an opposite example, I actually wonder if Fast Basic-I (Integer only package) actually uses the OS FP package for ANYTHING... It seems to me it does not at all (will have to trace deeper) and it is, in fact, SMALLER than 8192 bytes, altogether (!)
  14. The BBC micro runs its OS and Basic in a THIRTY TWO (32) KBytes ROM package. We do not need to discuss anything else here, other than hypothetically allowing Atari basic to be implemented in same ROM space, for instance. That is a discussion we can certainly have. The Atari ROM package was designed and conceived under a different vision, and you can of course have a Basic Package relying entirely on integer computations, if anyone really wishes so... In the case of the Atari Basic, they decided to over-rely on the FP package for the sake of space, but that is a decision pertaining that particular implementation / model, though. You don't need to resort to distorting rhetoric as an attempt to disqualify an irreductible, and unquestionable point: more ROM space can easily lead you to better performance and extra optimizations (which the BBC Micro very well exploits). In the above results summary, I already managed to extract higher speed from the Atari, by sticking to 16+8 KB rom space. Now, if you can prove that one of the two ROM banks on the BBC is half empty, that is a different story, though...
  • Create New...