Search the Community
Showing results for tags 'ti994a'.
Found 3 results
EDIT: Current release 4/25/20 can be found here Hello! Long time no see! Due to the coronavirus outbreak my schedule has conveniently been freed up, and I've started to port VePseu to the TI-99/4a! Attached is the progress so far.. Kinda sad I couldn't make a raster engine like BUILD or DOOM, but floating/fixed point is kinda a pain to implement and multiplication/division isn't signed like addition/subtraction, so I didn't feel like tackling that beast just yet. Is it possible? more than likely. Would it be playable? Not so sure The cart limitations are very similar to the original VeSpeu, in that I aim to keep the whole shebang under 4k. The code I'm working with also uses the upper 4k of the cart for RAM (specifically, as a video buffer so we don't have to access the slow VDP to manage basic graphics, you'll see why). The basic render code is done and only takes up around 1520 bytes *including an uncompressed map. I also plan to implement basic RLE or possibly simplified gzip compression on the maps as well, i'll just need to see how that goes.. Here's the basic to-do list Optimize code so it can run at 60/50 fps Comment the code Code Java-based development tools for maps, sprites, etc. Implement basic compression Make walls prettier Increase map size from 16x16(maybe, depends how tight optimization has to be) Minimap(maybe, depends if I have trouble moving through maps. Colored walls are a thing now) I do tend to have a habit of not finishing projects, I'm aware of this, but I still plan on optimizing the code a little and commenting the code before releasing the source. The TI-99 does have a lot more room to implement a game compared to the Atari 2600, and I already have a few in mind The source will be licensed under the BSD 3-Clause Revised license, and I'd love to see a game or two made with it! Plan on the code/binary to be released within a day or two, but don't quote me on it...
just messed around with a new feature @senior_falcon put in XB256, the ability to display multicolored fonts easily and quickly. and I got it to SIX full alpha font set colors. the TI99 now has an easy way to display up to 6 different alpha fonts on the same screen! way it works is you can type the the characters you want from the color character set directly with the offset CALL LOAD(9596,xxx). this enables you to just type the letters you want to display in this fashion: CALL LOAD(9596,(offset for chr set)):: CALL LINK("DISPLY",4,1,"TEXT goes HERE") this opens up using six different color characters per program. also can redefine the characters. could make a map typing in simple characters to display complex redesigned map characters. mix and match upper and lower case. lots of uses. get the latest copy of XB256 in this thread: _________________________________________________________________________ here is a reference guide and a copy of the demo. USE WITH XB256 Moves the character sets: 10 CALL LINK("SCRN2") 20 CALL LINK("VREAD",5376,255,P$) 30 FOR I=4096 TO 4608 STEP 256 :: CALL LINK("VWRITE",I,P$):: NEXT I 40 CALL LINK("VWRITE",5376+256,P$):: CALL LINK("VWRITE",5376+512,P$) Character Set Definition: Char Set 1 - Normal char set CALL LOAD(9596,192) Includes Numbers & special character COLOR SET 02-08 Only Char Set 1 has numbers NOTE: these next ones you would want to redefine ^ (or some chr in set) as space since inserting a space will give a different color from color set 1. Char Set 2 - Lower case char set Type lower case character set. COLOR SET 09-12 Char Set 3 CALL LOAD(9596,192) COLOR SET 13-16 Char Set 4 CALL LOAD(9596,416) COLOR SET 17-20 Char Set 5 CALL LOAD(9596,224) COLOR SET 21-24 Char Set 6 CALL LOAD(9596,0) COLOR SET 25-28 Example program: 10 ! MCFTEST2 12 CALL LINK("SCRN2")::! THIS SETS UP SCR22N 2 IN XB356 14 CALL LINK("VREAD",5376,255,P$)::! COPY IN STANDARD TI99 CHR SET 20 FOR I=4096 TO 4608 STEP 256 :: CALL LINK("VWRITE",I,P$):: NEXT I::! COPY OUT CHR SET TO NEW LOCATIONS 22 CALL LINK("VWRITE",5376+256,P$):: CALL LINK("VWRITE",5376+512,P$) 24 !SET COLOR OF CHR SETS:CS=1ST COLOR SET, F=FOREGROUND COLOR, B=BACKGROUND COLOR 25 CS=17 :: F=4 :: B=16 :: GOSUB 1000 26 CS=21 :: F=2 :: B=14 :: GOSUB 1000 27 CS=25 :: F=9 :: B=12 :: GOSUB 1000 29 CS=13 :: F=7 :: B=11 :: GOSUB 1000 :: CS=09 :: F=10 :: B=1 :: GOSUB 1000 30 FOR I=0 TO 255 :: PRINT CHR$(I);:: NEXT I ::!PRINT ALL CHRS 32 CALL LOAD(9596,192):: CALL LINK("DISPLY",1,1,"ATTENTION^TI^ENTHUSIASTS")::!PRINT TEXT WITH OFFSET 33 CALL LOAD(9596,416):: CALL LINK("DISPLY",2,1,"YOU^CAN^DISPLAY^TEXT^IN") 34 CALL LOAD(9596,0):: CALL LINK("DISPLY",3,1,"DIFFERENT^COLORS") 35 CALL LOAD(9596,96):: CALL LINK("DISPLY",4,1,"USING XB256 IN SCREEN2") 36 CALL LINK("DISPLY",5,1,"with lots of colors") 38 CALL LOAD(9596,224):: CALL LINK("DISPLY",6,1,"UP^TO^SIX^COLOR^SETS") 40 GOTO 40 1000 FOR I=0 TO 3 :: CALL LINK("COLOR2",CS+I,F,B):: NEXT I :: RETURN::! THIS SETS COLORS IN COLOR SET
I didn't want to hijack the 512K cart thread, so I thought I would post this here: I actually have a cart, custom built for me by Jens-Eike (it's with him in Germany) that is a 64K bank-switched cart with 1K of ram permanently mapped in to the end of the cart ROM space (so there is 7K or ROM per bank, and the same 1K of RAM in every bank). It also has two hardware stacks on it but there's issues with the stacks - we can do a push (post increment) but pops are proving very tricky (pre-decrement) - something to do with a lack of appropriate signals in the cart port to trigger the pre-decrement, so that might not make it into the final design. We'll have to see. It's a shame because the stacks are lovely: Simply write to an address (I think it's >7FFE) and it pushes that value to the hardware stack. Do a read from the same address and it does a pop! The RAM for the stack is taken from the 1K of RAM. Of course, you don't need to use them if you don't want them, but I want them for a TF V2.x which would have a hardware stack (and thus be faster). It's currently implemented in discrete logic, but I'd be happy to hear to from anyone that is willing to tackle the problem with programmable logic. As I say, there are issues that need to be solved. I spoke with Gary Smith about it here in the UK. He has looked at the problem and agrees that it's a tricky one. He has a tentative solution using flip-flops to induce a delay (if I have understood it correctly) between detecting a read from the stack port (triggering an address decrement) and performing the read. I'd like to get the whole thing into one chip: That is: 64k ROM, 1K RAM and all logic. If anyone is interested is doing a design please let me know. Jens-Eike and Gary has expressed an interest, but it's hard to keep the momentum going - understandable enough... We all have lives outside of the TI