Jump to content

adamantyr

+AtariAge Subscriber
  • Content Count

    1,718
  • Joined

  • Last visited

Community Reputation

1,244 Excellent

About adamantyr

  • Rank
    Stargunner
  • Birthday 07/16/1975

Profile Information

  • Gender
    Male

Recent Profile Visitors

31,306 profile views
  1. Yeah, unit tests only make sense if you're writing libraries that are independently loaded, or using some kind of complex infrastructure that allows it. My CRPG work has made me WISH for regression tests at times, just so changes I make don't break something I forgot about.
  2. What is the use context? Can you assume the byte count will always be a minimum size? Unrolling the copy loop with a check to see if the count is odd or even first seems the best approach. I see two options: A static option (with it doing a consecutive 8 or 9 byte push, for example, based on even/odd and a wrap up for remainders). You'll lose some time in prep-work but make up for it with large enough unrolls. Self-replicating code that will in a memory block just replicate the "movb *r0+,*r1+" for as many iterations as possible. The prep work could be much longer, so it's a balance of time to create the unrolled loop verses the speed gain of not having a status register check and decrement.
  3. I use a cross-assembler on my PC, A99. I don't have time to wait for 168k of code to build.
  4. We're not letting you off that easy.
  5. I have my doubts that the XB3 cartridge/images has any support for AMS. If it did, why wasn't it documented in the manual? Without that, you wouldn't even know how to utilize it properly. Maybe such code exists, but I'd be surprised if it was on the released version. Maybe a work-in-progress ROM set. Given the cartridge came out at the same time Asgard finally closed down, there was a lot of chaos going on.
  6. Based on the TI Tech Pages (which admit they don't have the schematics to look at), it was substantially different enough to not be a simple change that could be hacked in. In particular: It could only be 128K or 512K (probably because it had only one memory chip) The area >2000-3FFF could not be paged (?) The most significant bit was permanently set to one, so page 0 would in fact be page 128 (??) That's significant enough that wiring up the SAMS card would require a re-write of anything do to with expanded memory. And given we don't have source code, not happening. Just use RXB instead.
  7. If someone has a dump utility already written to do the work, great! I'll be happy to run it.
  8. Hmmm interesting! Mine has a later version of XB3 and the micro manager.
  9. Good to know, thanks Tursi! I just tested my cart and it works with TIPI and SAMS and it worked fine. Even managed to load my CRPG through both XP3's auto-loader and the provided E/A module.
  10. I think the issue is not the dump, but the architecture of the cartridge itself and how the two EPROMS are utilized. Which means someone with knowledge of such things would need to disassemble the cartridge.
  11. That's unfortunate. Am I the only active AtariAge guy with an XB3 cart?
  12. I think the XB3 Supercart was pretty unique. We'd have to get Gary to share more details. In the connecting thread above, he mentions he was going to put up schematics on his site (O-P-A.biz) but I just checked there with no luck.
  13. Interesting, the manual scans that were provided on that thread are from MY copies. I know this due to some oil stains on one of them that came out in the scan process. I put them up on WHTech years ago. I did test a couple years ago if my XB3 supercart would recognize my SAMS card, and it didn't. This is likely because either the cartridge lacks the AMS recognition capacity (it certainly isn't mentioned in the manuals) or it only recognizes the original Asgard cards, which had a slightly different architecture from SAMS.
×
×
  • Create New...