adamantyr
-
Content Count
1,852 -
Joined
-
Last visited
Posts posted by adamantyr
-
-
hey Adamantyr, I missed your last post there, that's great to see, thank you.
Thanks Matthew, I was entering them all in fully, just thought I might be able to save some time/space by skipping a few lines if it wasn't needed. That makes sense that the space may not be all 0's something else could be written in there before I send new data to it, and that would be a real pain in the ass to trouble shoot too.
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
-
JOYUP BYTE 4,0
I'm assuming that it is assigning 2 bytes to the label JOYUP?
How many bytes can you assign to a label like this?
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.
C @JOYY,@JOYUP
this compares values in the addresses starting at >8376 to the byte values in JOYUP 4,0?
So since JOYUP contains 2 bytes 4,0, it checks 2 addresses >8376 and >8377?
Yes. The C opcode compares words, not bytes.
Had I not had this example I would have done 2 compares, one for JOYY and one for JOYX,ie
JOYY EQU >8376
JOYX EQU >8377
JOYUPY BYTE 4
JOYUPX BYTE 0
START BLWP @KSCAN
C @JOYY,@JOYUPY
JNE *
C @JOYX,@JOYUPX
But I guess I would have been doing it the hard way. I guess it's no different then when I have a label for a pattern and a DATA with 4 WORDs. It just seemed strange to me to see it done that way. I guess since I seem to know what it's doing is how many bytes I can assign this way. I Did read that DATA can have a max of 4 WORDs, but like I said I didn't find anything on BYTE.
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
-
This is a how best to do this question more then anything.
Ok, I'm using alot of patterns for double sized sprites. If I want to change the image of a sprite is it best the change the pattern address in the ATTRIBUTE TABLE or load in another image into the DESCRIPTOR TABLE.
A 16x16 sprite is 32bytes and sounds like alot to move but is there really much of a hit in speed to do this?
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.
I'm alittle confused by what address is what,
Pattern Descriptor Table is at >800 and starts with pattern >00
Sprite Descriptor Table is at >400 and starts with pattern >80
I'm not sure how much space I have, do I have >800->400 space for sprite patterns which is >400,1024bytes,128 patterns at 4 patterns per sprite =32 sets. I may have 32 sprites but I wont be using 32 different pattern sets so 8-10 will be the same pattern and the Attribute Table for these can point to the same address in the Descriptor Table, RIGHT?
If the Sprite Attribute Table is at >300 and the Sprite Descriptor Table is at >400,
CAN I define patterns at >00 thru >300? which correlates to patterns 0-96 which is another 24 sets of double sized sprite patterns?
If I can do this I have more then enough space for the multiple images I want and can just update the Sprite Attribute Table for the image, If not I may not have enough space and will have to copy patterns from someplaces outside of >400 thru >800 into that address area.
I guess I'm going to build a pattern list for my sprites and see how many I really am going to end up with. Maybe someone can chime in and help me understand my addressing issues and discuss what to do if you have more then 32 double sized sprite patterns.
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
-
When using TID99, what is the real file size?
For example, my Bouncing Babies program shows a size of 49.
I can assume it's not 49 bytes since I know how big the object file is and I can use my powers of deduction to tell it's not 49 kilobyte since I only have 32kb of space.
I see that a 360kb disk has 1440 sectors, so size is the number of sectors of disk spaced used? If so the closest it gets to actual space used is then sector size which I guess is 360kb/1440sectors or .25kb which is 256bytes. If so a program size of 49 would mean a size just under 256*49 or 12544 bytes.
Ok, I guessed as much as I can, so I'll wait to hear from the experts on here.
John
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
-
Another year and TI would have maybe released the 99/8. I think it could have been the game changer for TI. They really addressed every short coming of the 99/4a with the 99/8. A 10mhz 16bit computer when everything else was 8bit and slow, or 16bit IBM and expensive and slow.
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 main shortcomings of the TI99/4a I see were,
No sprite support in basic,
...
As important as sprites would have been inline assembly code, or machine code in basic. Anyone who programmed on the PC back then at 4.77Mhz knows the basic was terribly slow too, but progammers could imbed machine code directly into the basic program. Other computers has POKE commands, some you couldn't do anything without the poke commands like the Commadores.
...
No stand alone diskdrive,
...
16k memory,
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.
Commadore and Atari embrace the entertainment side of the home computer, but It seemed TI didn't want there machines thought of as game machines. They wanted a serious computer to do serious stuff.
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
-
1
-
-
Draft of my review is up on my site. A quote:
"First of all... there's no goblins, glistening or otherwise. Why would you tell me there are goblins when there aren't any? There's no escaping into the cool night air, either. In fact, I don't think the person who wrote that box copy had ever seen the game in action. It's possible he'd never seen a TI 99/4A."
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
-
That's pretty fascinating man.
. I'm interested in your logic behind this. This is accomplished by an offset? Or is it all manual? Bur aren't all your maps are static and not generated by an engine?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
-
I run whatever in MESS, Win994a or Classic99, and videotape (screen area recording) it using Camtasia Studio 5. And then I select "Produce video as gif.
I previously had a look at you circle demo, and it's super. Very smooth. I'll make a gif animation if you don't mind.
Does these trigonometric values support smooth circular movement on a larger scale (like with a diameter of 180 pixels) ?
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.
Still looks good, and sometimes a more dim selection of colors will only add to the atmosphere. Great job. And nice font too.
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
-
Yep, looks good. This must be a editor screenshot - but still looks good.
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
-
The problem with either of these is, how would you "write" data to address >6000 (or the other 3 address)? A cartridge needs to contain a standard header to show up in the 99/4A menu...
I suppose if everyone conceded that address >6000 would *always* return a value of 0xAA then the first technique could work. However, that would make the cart incompatible with existing bank switching code that expects to write to a specific address to get a bank, i.e. >6000 selects bank 0, >6002 selects bank 1, >6004 selects bank 2, etc.
Some sort of compatibility would be required I think. That or a few "modes" that determine what kind of bank switching technique should be used.
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
-
1. Is there any reason to have a real PEB hooked up as well (not at the same time obviously)? Is there anything that the PEB can do that the CF7 can't other than make a lot of noise and run Pascal?
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
-
A momentous occasion!! Crack open the bubbly, get out the fine china and the filet mignon!!! I've been waiting for a long time. You rock, sir!!
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
-
Yes, Leather Goddesses of Phobos and Moonmist require a Supercart.
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 RTYou 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
-
However, if you are running from the 32K RAM expansion, or if your subroutine is in RAM and you now you won't have subroutines calling themselves, this is a very nice way to handle subroutine calling without the overhead of a stack and the stack maintenance instructions. I will certainly be using this kind of thing in the future!
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
-
Have you considered using a 64K bank-switched EPROM for storing your game code?
You would then have a lot of the 32K memory available for storing game statistics, etc.
The PCB's for a 64K bank-switched cartrdige are already widely available.
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
-
Still working on getting another demo version out... Got some controls debugging to do, trying to close off any unimplemented features so they don't break things, and so forth.
The demo won't feature playable combat yet; I really need to finish the hard stuff of control systems, including things like merchants, inns, and so forth. There's plenty of time to play-balance the combat system later.
Seriously thinking now I should probably utilize the 8k CPU memory the cartridge provides... I don't like doing it because it means a base 32k TI is no longer enough, but it would be a load off my mind to have another 8k to work with. I suppose I could find someone willing to put together a bunch of 8k RAM carts to support it.
You can keep an eye on my blog for progress.
Adamantyr
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Assembly and sprites question
in TI-99/4A Development
Posted
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