adamantyr

I use a cross-assembler on my PC, A99. I don't have time to wait for 168k of code to build.

We're not letting you off that easy.

Can't make it today guys sorry!

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.

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.

If someone has a dump utility already written to do the work, great! I'll be happy to run it.

Hmmm interesting! Mine has a later version of XB3 and the micro manager.

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.

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.

That's unfortunate. Am I the only active AtariAge guy with an XB3 cart?

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.

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.

The MSX architecture has definite advantages over the TI, especially where memory is concerned. Plus the sound chip is slightly better. (4x more range so you get two extra octaves) It's not impossible to write such games on the TI, if you use a SAMS card to overcome the memory limitations.

I didn't get one before, even though I was on furlough, and I won't get one now. The peril of making TOO much money I suppose.

Three 360k disks, to be exact. If a 180K version is supported it will have six disks. (Load, Game, four world disks). It goes without saying I would urge the use of TIPI for the best experience. Legends II actually is on three disks. The last disk just contains the character converter and some end game sequences though. In terms of content amount, the two games are the same size.

I asked for the disasm to disk option. It helped find a bug in my game. Fair warning, it will crash your hard disk if left running too long... a minute or two created a 33mb text file.

For my own SAMS development, my application (game) handles basically all the page swaps itself. That generally is the best way to do it if you are less interested in platform development. What I'd like to see though is more cross-assembler work in this area. My present setup uses A99 and does multiple builds of each module with only its dependents so it can copy the binary code into one large binary that is loaded through my special loader I wrote. It would be good if such a system could be "toolized" for easier use by other developers, probably.

Just an observation guys, but if the intent of this thread was to share assembly code samples... It appears it's turned more into a back-and-forth debugging session which is no doubt good stuff, just not related to the thread's original intent.

My super awesome random number generator! First, you need to initialize the 9901 counter at the start of your application: * Set up 9901 counter CLR R12 * CRU base of the TMS9901 SBO 0 * Enter timer mode LI R1,>3FFF * Set counter INCT R12 * Address of bit 1 LDCR R1,14 * Load value DECT R12 SBZ 0 * Exit clock mode, start decrementer Then, the following routines will generate either a 16-bit word size random value, or any value from 0 to max-1. I've set them up to have their own workspace but you don't need to do this if you don't want to. * Random number generator (Range in R3, Result in R4) * Returns 0 to R3-1 RNDNUM DATA VWS,RAND2 RAND2 BL @RNDGEN MOV @>0006(R13),R3 CLR R4 DIV R3,R4 MOV R5,@>0008(R13) RTWP * Random number generator 16-bit (Result in R4) * returns 0-65535 RANDOM DATA VWS,RAND1 RAND1 BL @RNDGEN MOV R4,@>0008(R13) RTWP * Random number generation RNDGEN LI R4,23729 * Load with 15-bit value MPY @RSEED,R4 * Multiply by the random seed AI R5,31871 * Add a 15-bit value to the lower word CLR R12 * CRU base of the TMS9901 SBO 0 * Enter timer mode STCR R0,15 * Read current value (plus mode bit) SRL R0,1 * Get rid of mode bit SBZ 0 * Exit clock mode, decrementer continues ANDI R0,>000F * Filter to 0-15 JEQ RNDGN1 * If zero, skip SRC R5,0 * Rotate seed based on clock value RNDGN1 MOV R5,@RSEED * Copy back to RSEED RT

How do we upgrade by SSH'ing into the TIPI? The usual upgrade path won't go beyond 1.65.

I use a Yeti Blue Microphone myself: https://www.amazon.com/Blue-Yeti-USB-Microphone-Silver/dp/B002VA464S/ref=sr_1_2 My current webcam is a Microsoft Lifecam HD-3000, which can be had still on NewEgg pretty cheaply.

I tried it once, XB just says "SYNTAX ERROR" on the offending line. Your example above isn't quite as crazy, trust me. As I said, they could put both FOR and NEXT on conditionals freely. Your example above, you can see, has to do a NEXT for both logical paths in one line. Their code you didn't have to, so long as you had a NEXT statement at some point to act as a terminator for all FOR loops. Also, particularly maddening was the fact they didn't use spaces as a parser. So you could write everything with no spaces at all, like this: FORI=1TO100:IFI<>10THENEXTIELSEX=X+1:NEXTI

Wow, I missed some drama. Particularly amused by the fact it was borne out of an incorrect assumption of the issue of RES using 32767 as an unknown line marker. Another reason for "IF X THEN" structure is that it saves precious bytes, which on any old BASIC are in short supply. This is why we have shorthand things like the ternary operator in C; saving some room. For the record, I NEVER use the ternary operator if I can help it. And if this convention bothers and offends you, don't ever look at TRS-80 color BASIC or extended color BASIC. They have CRAZY stuff, like FOR NEXT loops declared in logical structures (IF X THEN FOR I=). I think the only reason this doesn't fall apart in a logical catastrophe is they can use "NEXT" without a variable as a permanent terminator to any ongoing FOR loops. Reading the code when translating Space Trek to the TI caused me serious migraines and WTF moments.

I got a copy of that book too. I must have liked it, it survived the purge of "game related" programming books when I got rid of a lot of them. As far as doing a 3D rendering engine on the TI, it's not impossible but there are definite technical problems to solve. You may find that it's not going to be viable applying another engine's approach, mainly because TI's bitmap mode is so completely different from anyone else's it may require a custom solution.