adamantyr

There's nothing wrong with your code, you just didn't know one small detail. The contents of VDP register 1 are mirrored in the scratch-pad at @>83D4. During the interrupt stage, it recopies the value at 83D4 into register 1. So if you alter register 1 (which conveniently contains the sprite settings for size) you have to also copy the same value into 83D4 to ensure it doesn't get reset back to it's original value. Adamantyr

I looked into using RLE for character patterns on the TI once... it turned out that any framework for supporting it took up more space than the uncompressed graphics! The problem is that character patterns are highly chaotic most of the time... RLE relies on large blocks of identical data to be truly effective. Color data would probably be more useful to use RLE with. However, probably the least-pain method of getting your graphics and color is to just output them to disk as memory image files and load them in. That necessitates writing up an external editor and a bit of overhead at the start during initialization, but it's well worth it. Having data in the CPU RAM that just gets copied into VDP is a waste! Adamantyr

No problem. Ask me any questions you have on how the layout was achieved. There's actually quite a bit of space in VDP memory for a lot of things, as long as you're not doing full bitmap mode. (Which consumes nearly all of it.) Yeah, I can see why you thought leaving off zeroes would work... after all, you can do it in TI BASIC. But the compiler's a different beast. It has to have everything literally spelled out. On the plus side, it is a heavy ambrosia indeed, to realize that you have COMPLETE control over nearly everything... a welcome change from BASIC where you had to work around things like it using floating point for everything, running interrupts all the time, using most of VDP as stack space for strings, etc. Adamantyr

Not exactly. BYTE is a compiler directive, not an opcode. What it's doing is declaring values, expressed in byte form, at that particular location in memory, rather like the DATA statement in BASIC. The compiler assigns the label "JOYUP" to apply to that specific starting address. The only limit on how many bytes you can have is how much memory the system has. They could also have done it like this: JOYUP DATA >0400 Or this: JOYUP DATA 1024 And it would be identical in behavior. Yes. The C opcode compares words, not bytes. They're compiler directives, so the limitations are actually determined by the compiler. The TI compiler does cut things off after a particular point, so it's better to keep it to 4 words or 8 bytes just to keep things clean. The A99 compiler, for example, has no such limitations, and I had code source that compiled fine in it but had all sorts of weird compiler errors on the TI. I investigated and found it was truncating some of my DATA and BYTE lines that had "passed" in A99. Adamantyr

As an example, here's the VDP mapping for my CRPG: Address Contents Start End 0 0000 255 00FF Pattern Table 256 0100 511 01FF 512 0200 767 02FF 768 0300 1023 03FF 1024 0400 1279 04FF 1280 0500 1535 05FF 1536 0600 1791 06FF 1792 0700 2047 07FF 2048 0800 2303 08FF Screen Table 2304 0900 2559 09FF 2560 0A00 2815 0AFF 2816 0B00 3071 0BFF Sprite Attribute Table 3072 0C00 3327 0CFF Buffer Screen Table 3328 0D00 3583 0DFF 3584 0E00 3839 0EFF 3840 0F00 4095 0FFF Character Graphic Data 4096 1000 4351 10FF File Buffers 4352 1100 4607 11FF 4608 1200 4863 12FF PAB Space 4864 1300 5119 13FF 5120 1400 5375 14FF 5376 1500 5631 15FF 5632 1600 5887 16FF Save Game Data 5888 1700 6143 17FF 6144 1800 6399 18FF Sound Data 6400 1900 6655 19FF 6656 1A00 6911 1AFF 6912 1B00 7167 1BFF 7168 1C00 7423 1CFF 7424 1D00 7679 1DFF 7680 1E00 7935 1EFF 7936 1F00 8191 1FFF 8192 2000 8447 20FF Color Table 8448 2100 8703 21FF 8704 2200 8959 22FF 8960 2300 9215 23FF 9216 2400 9471 24FF 9472 2500 9727 25FF 9728 2600 9983 26FF 9984 2700 10239 27FF 10240 2800 10495 28FF Sprite Pattern Table 10496 2900 10751 29FF 10752 2A00 11007 2AFF 11008 2B00 11263 2BFF 11264 2C00 11519 2CFF 11520 2D00 11775 2DFF 11776 2E00 12031 2EFF 12032 2F00 12287 2FFF 12288 3000 12543 30FF Sprite Pattern Table #2 12544 3100 12799 31FF 12800 3200 13055 32FF 13056 3300 13311 33FF 13312 3400 13567 34FF 13568 3500 13823 35FF 13824 3600 14079 36FF 14080 3700 14335 37FF 14336 3800 14591 38FF Mob Graphics 14592 3900 14847 39FF 14848 3A00 15103 3AFF 15104 3B00 15359 3BFF Reserved for FDC 15360 3C00 15615 3CFF 15616 3D00 15871 3DFF 15872 3E00 16127 3EFF 16128 3F00 16383 3FFF It looks a lot better in the Excel spreadsheet. Adamantyr

VDP Register 5 stores the location of the Sprite Attribute Table. This is 32 4-byte long records, one for each sprite. VDP Register 6 stores the location of the Sprite Pattern Table. This is up to 2048 bytes in size, and can be located at any 2k interval in VDP. You can even overlap it with the character pattern table, which is what is done in TI Extended BASIC. That means you can have up to 64 sprite patterns of 16x16 size if you want. If you have all your sprite patterns in a single table, just change the attribute table. If you have a few spare patterns you're swapping out, you can either have a rotating pattern that you change directly, or you can have a second sprite pattern table, which you can change to with a single register write. Writing 32 bytes isn't that much of a hit, unless you do a lot of them in a "real-time" moment, like between video frames. It sounds like whatever source you were using (Molesworth?) failed to mention that the sprite pattern table does NOT need to overlay the character pattern table. Read over the TI Tech Page section on the VDP chip, that should give you a good background on the technical: http://nouspikel.group.shef.ac.uk//ti99/tms9918a.htm Adamantyr

The later Databiotics cartridges (Sold in Triton/TM Direct catalogs from the mid-80's to early 90's) were a mix of impressive work and utter crap. Good ones are: - Spot Shot (Dragonflyer) - Red Baron Flight Simulator - Junkman Jr. A very bad one, though, is Star Trap. I bought this game expecting a cool Star Wars type simulation game... instead I get something I could write in TI Extended BASIC and with about as much excitement as watching mold grow. Adamantyr

It's measured in sectors, each of which is 256 bytes. There is a one sector header for each file on the disk, so your program consumes 48 sectors. Divide by 4 and you get the size in kilobytes, 12k. Adamantyr

I'd like to think so, but at the time, the home computer market was crashing... The TRS-80 Color Computer 3 was a similar design, a fast 8-bit machine, that came out too late and with too little support. I have a feeling the TI-99/8 would have gone the same route. Also, TI still wasn't catering to independents and 3rd party developers, and given their chip architecture was completely different from the 6502, it would have been difficult to court them. The lack of machine language support in BASIC was part of their drive, I think, for a more user-friendly language. I'd definitely argue that TI BASIC was one of the easiest to learn... Look at any other computer manual, and behind the cute illustrations was a mess of technical jargon and architecture that would be completely incomprehensible to the layman. The 16K VRAM was entirely a cost-cutting decision... The TI design was done in the late 70's when static RAM was still extremely expensive. A lot of people forget that the Commodore 64 came out several years later, and could take advantage. The real pain was that the TI engineers failed to include upgrade paths to circumvent the TI shortcomings. I guess they thought they'd fix all that in the TI-99/8. I'd say that was TI's greatest mistake, a lack of focus on what customers they wanted. They had aspirations as a business and professional machine, and yet they failed to provide the necessary elements (disk drive, memory) that would be necessary to succeed against Apple. They really wanted an "everything" computer when most of the market didn't really care, they just wanted pretty graphics and sound. (Most adults at the time who didn't work with computers at work thought of them as expensive toys.) Adamantyr

Wow, sounds bad. I got some ancient TI catalog FULL of cassette games for TI BASIC that I'd never heard of anywhere else. Mind you... I expect most of them were crapware. Great site, though, I look forward to more reviews. You should do a review of all the Not-Polyoptics titles, I'd love to hear more about them. Every one I've seen has been pretty darn impressive, considering the platform they were written for. One of these days I do want to do a nice strategy game in assembly on the TI... No, bad designer! Finish current project first! Adamantyr

Yes, I use an offset value (0, 1, or -1) to determine if each row is displaced by that amount, incrementally. (So the first row is 0, second row is N, third is N+N, etc.) I only slant left or right; up and down would be twice as much work to implement, and doesn't really gain anything. My maps are static, but they're still stored as a linear array, like a square map. I just project them differently. The big headache with this technique is adjusting the placement of objects, coordinate-wise. Static locations are fine; it uses the same system as square maps do, the difference being that N rows up or down is also N columns displaced, depending on if you go up or down. But if a mob unit, for example, has to move, I have to remember that it's actually moving diagonally up and down so it looks like it's moving cardinally. Like I said, it can be confusing, hence the screenshot to illustrate what I mean when I say "slanting". Adamantyr

Here's a feature that has always been present, but I never really had a way to illustrate it... Slanted maps! Basically, I do a left or right slant on map data, which lets me generate maps with a diagonal flow. The main value with this is you can create maps like coastlines without a lot of wasted space due to the square map not following the land contours. I hadn't had any slanted maps in the demo, but because it's a fundamental engine part, I figured I should add a few just to test it out. Here's what one would look like: Mind you, DRAWING these sort of maps is hard. I had to modify my map editor so that the cursor still goes straight up/down, because otherwise plotting maps was really difficult. Adamantyr

Not at all, thanks! I haven't tested it to that degree, but I'm guessing as long as you're on the scale of the TI screen, it should remain pretty accurate. The demo doesn't test out "skipping" angles, which would speed up movement. What you're seeing is tracking every angle as it increments the radius. Yes, for an afternoon's work it's pretty decent. I had particular trouble coming up with a "ruined" tile, it was too easy to make it look like garbage. I eventually got that "worn but still distinctly a stone wall" with a lot of trial and error. Yes, I actually adapted the font from Ultima IV. I originally had it as a 6x7 font, but it was too thick and visually distracting on a black screen, so I made it 5x7 instead. Adamantyr

Thanks. And thanks for the blow-up on that... how do you make those animated GIF's? I doubt anyone's even looked at my circle routine in the special effects thread... This particular shot is a ruined fort at the top of a frozen mountain pass that will be in the demo. It's probably not the best shot to show off the tileset, since there's a lot of white and gray... Adamantyr

After playing Final Fantasy II on the SNES, I decided I needed to add a new tile set to the CRPG to support castles and fortresses. Granted, a great deal of tile space is getting wasted on purely visual stuff... and it really shouldn't be "line of sight" blocking either... but eh, it looks way better. Adamantyr

Well, the best starting point would be to look at how other cartridges handled it. Extended BASIC has two 8k pages. The Asgard Super XB3 cartridge had four 8k pages. And the Superspace II cart did something... How did Jon squeeze 512k, or 64 pages, into his cart I wonder? 128 bytes of header dedicated solely to that? Adamantyr

A fantastic idea, Matt! That would really open up possibilities for development in a cartridge format. I'd totally buy in on one. You should investigate the old Superspace II cartridge, which provided up to 4 banks of 8k bank-switched RAM. I believe they did the bank-switching as one of the following: - The first address in the RAM space (>6000) contained the active page, and writing to that address would trigger a bank-switch - The first four address spaces were used to track each individual page From a personal standpoint, I'd really prefer the first technique. I don't own one of these, so I don't know for certain how it worked. They're hard to procure these days; I've been keeping an eye on eBay for over a year with no luck. Adamantyr

If you have to interact with older media like floppy disks, a PE Box will still be needed. So a CF Reader is of little use for software porting to the PC; you'll need RS232 or floppy drives to manage that. Case in point, though, I currently have my TI in my closet, but I left my PE Box in "long-term storage", aka Mom and Dad's. Adamantyr

Wow... I checked my site's hit counts for the day, and I was 324. Normally I average 10-25. Understandable, since I update my blog infrequently and my last update to the CRPG site was nearly three years ago. Still, 300? Sheesh! Feel free to post any oddities or bugs you find with the interfaces and controls... the only thing I can definitely guarantee won't work is the combat. You can move around the map all you like, but if you try casting a spell or firing a bolt at a guy, expect a crash. Adamantyr

Better re-cork the bottle, the Demo isn't finished yet. It's version 0.60. When it's 1.0 it's done. Adamantyr

Okay, I reached a point in code that I was saying ‘Okay, that’s enough, just get a demo out there for people to complain about’. You can download it on my CRPG site at http://www.adamantyr.com/crpg/demo.htm Also, check out the new article on all the updates that went into it at http://www.adamantyr.com/crpg/article_10.htm Adamantyr

Ok I know you answered this before, but indulge me. What is a Supercart again? What games require one? Tempest A Supercart is, basically, an E/A cartridge with an 8K RAM chip in it. Usually with a battery to preserve the RAM contents, although it's not strictly necessary. The main value of it is to give the TI a little boost of memory. The more advanced carts, like the Superspace II, actually had multiple 8K pages, which you could switch between. The TI Extended BASIC cartridge has two 8k pages, but it's possible to have more. Adamantyr

Well, I'm really focused on trying to get my CRPG done before getting side-lined, but I can share this: I plan to use sprite graphics to create special effects in combat. One of my requirements was the ability to have them move in circles. I also did not want to use the nasty floating-point mathematical functions. So I wrote my own integer-based system: * Data block for trigonometric values TRGDAT BYTE 0,6,12,18,25,31,37,43 BYTE 49,56,62,68,74,80,86,92 BYTE 97,103,109,115,120,126,131,136 BYTE 142,147,152,157,162,167,171,176 BYTE 181,185,189,193,197,201,205,209 BYTE 212,216,219,222,225,228,231,234 BYTE 236,238,241,243,244,246,248,249 BYTE 251,252,253,254,254,255,255,255 * R0 = Radius * R1 - Angle (0-255) * R2 = Position Adjustment TRIGX AI R1,64 ANDI R1,>00FF TRIGY MOV R11,*R10+ MOV R1,R3 SRL R3,6 JEQ TG1 CI R3,1 JEQ TG2 CI R3,2 JEQ TG3 MOVB @TRGDAT(R1),R2 SRL R2,8 AI R2,-256 ABS R2 MPY R0,R2 DIV @W256,R2 NEG R2 JMP TG4 TG1 MOVB @TRGDAT(R1),R2 SRL R2,8 MPY R0,R2 DIV @W256,R2 JMP TG4 TG2 MOVB @TRGDAT(R1),R2 SRL R2,8 AI R2,-256 ABS R2 MPY R0,R2 DIV @W256,R2 JMP TG4 TG3 MOV @TRGDAT(R1),R2 SRL R2,8 MPY R0,R2 DIV @W256,R2 NEG R2 TG4 RT You supply your radius and angle, and it returns an X and Y position adjustment in R2. I have a demo here as a MESS disk image. You can use TI99Dir if you want to extract the files to Classic99. 1. Insert the E/A cartridge (or set the ROM, whatever) 2. Select option #3 3. Type in "DSK#.CIRCLE" where # is the disk you've extracted the files to 4. Press and hold any key Adamantyr

A very interesting technique... essentially, you're tagging every subroutine with a return-stack word value! The advantage of not having CODE and DATA segments in TMS9900 architecture. However, I do see some drawbacks to the technique: - Subroutine count vs. general stack size. Usually you have a lot less layers of return stack than count of subroutines. - Debugging. At least with a stack, you only got ONE place to look. This has come in handy when my CRPG has gone off into ROM land and I need to see where it came from. - Memory speed. With a stack you at least have the option to put it into the 16-bit scratchpad. A little harder to do with subroutines For my own CRPG, I use R10 as well for a return address stack pointer. Currently I allocated 32 bytes to it for 16 levels of return stacking, but I'll reduce it to match the maximum level reached when the core engine work is done. I have a lot of subroutines, and if they do nothing but branches or BLWP's, I don't store the return address for that particular case. I'll probably enlist aid here on the forum to help "optimize" the final source code. I'm trying to program efficiently NOW, but you know how it is. Sometimes you just want it to bloody WORK, and you'll figure out how to make it work BETTER later. Adamantyr

Mainly, I'd have to re-factor the entire project from scratch, something I'm really not willing to do right now. Bank-switch programming is a total departure from the current model... the 8K Superspace carts would just give me a different 8k for data, and I can continue using compiler/SAVE utility which would just run the code into the lower 8k once the top 24k is filled. Also, I'm not interested in any emulator for development except Classic99... I've no idea if it supports this particular arrangement yet. Adamantyr