fabrice montupet

Thank you, that's great. Is there a new disk based version of XB256/Compiler?

My Favorite old game cartridges (in order): Parsec, TI Invaders, Donkey Kong, Ms Pacman, Burger Time, Popeye and Moon Patrol.

I read all the threads only because I am very interested in all concerning our dear TI-99/4A and I participate when I like to, don't be paranoiac. So catch your breath and don't be surprised if, maybe one day, I answer to a future message from you to share my point of view.

There is nowhere in my message where I were subjective. I tested for a while RXB and XB256 and made my choice. Please, accept that. "ONLY CONSOLE without 32K ", an argument that you constantly put forward in loops and loops on AtariAge, yes it is technically interesting, an especially taste for challenge for you but, for present users, who in here really cares now, we are not anymore in the years 80 where any TI-99/4A expansion cost an arm and a leg. Now the 32 KB expansion costs nearly nothing. Like XB256, if ones want to use RXB, he must get too a FlashROM 99 or a FinalGROM99 that cost . So if ones can buy a such cartridge he can also buy a 32Kb expansion. We see now that price is not a problem anymore. So I personally prefer using a language that offers many powerful graphic and sound features and great performances thanks to compilation, benefiting in addition the 32KB memory space for more elaborated programs than the 16KB of the stock computer can offers.

Your words do not reflect reality and the metaphor is rather lame. The extra steps to compile are so quick and easy to execute that the least gifted user can access. The very few user actions during the process a near always the same that could be done closed eyes, and even could be easily automatized . Compiled, programs run smoother and very quickly, permitting to create more elaborated programs, things that were impossible before. Compilation is acclaimed by most of the current users, because it bring the most important feature that missed them during old days and they want. To realize it one just counts the number of programs made and converted with XB256 compiled and the very few (not to say infinitesimal), made with RXB that doesn't offer the feature. In my point of you, you can add all the subprograms you want in RXB, maybe it could be interesting or practical for some usage, but it will always runs too slow and will continue to be less attractive. I understand your position that intends to defend your product and the purpose you want for it, it's normal and I respect it. But please, be objective.

I think that I still have one that I can trade, I'm not interested by money. Do you have some rare TI99 stuff that you can trade too?

Welcome back Gary 🙂 I wish you the best for your new life.

In the same way, I wonder if there is someone who owns a TI-99/5 or TI-99/4B prototype. I always hoped to contact him to be able to share information between its unit and mine. I can't imagine (I hope!) that there's nobody. I still have many quests but if I had to choose only two holy Grails: A prototype of the TI-99/4 and a mock-up of the CC70.

Yes, the 99/8 is almost impossible unattainable but there is a prototype even more difficult to find: the TI-99/5.

Thank you Harry for this information. I keep it preciously in mind if one day I have to optimize the speed of a future program at its maximum. For my game project in development, I tried the two options and the XB256 compilation feature is so incredible by its performances that I haven't seen any difference in speed. It's so quick! Never mind if one Token more is used when using the null string "". As the CALL PEEK routine is used one time in a subprogram, the one Token more consumed is insignificant.

Thank you very much Harry. That it only works in a compiled program is not a problem as my program uses memory in a way that it already can't be executed under XB, to play with it I systematically have to compile it 🙂

Thank you Michael. So the problem is EXB. I should have verify in EXB. In fact, I never use it anymore since I discovered the excellent XB256 . I wonder what things had in EXB TI developers minds... May be some missing memory space in EXB ROM to do the same as in E/A. In any case, making the same subprogram with different function/behavior is really frustrating. But i will find another way to speed up my program 🙂

Thank you for your help. In fact, I have read the Editor/Assembler manual, page 281, and seen this: "The PEEK subprogram reads bytes from CPU RAM and, starting at the address, assigns those values to the numeric variables in the variable-list. You can read values starting at more than one address by separating the last value in the variable-list from the next address with an empty string ""). For example, the statement CALL PEEK(8192,A,B,C(8),"",-24576,X) places the value from address 8192 (>2000) in A, the value from address 8193 (>2001) in B, the value from address 8194 (>2002) in C(8), and the value from address -24576 (>AOOO) in X." So, Have I missed or misunderstood something?

I have found a problem in my XB256 compiled program, it concerns CALL PEEK. If I write: CALL PEEK(W,P) :: CALL PEEK (W+64, Q) , when compiled the program gives the good values to P and Q. But if I write: CALL PEEK(W,P,"",W+64, Q) , the compiled program gives good values to P but not to Q, so I wonder if the empty string "" between two variables and permitting to read values starting at more than one address works with the compiler.

You're right. Although the TI-99/4A has better graphics possibilities that the ZX Spectrum, the TMS9918 has limitations too. But using its features would offer the sensation and the pleasure to use a TI-99/4A and not a ZX Spectrum. That said, effectively, finding people for doing graphics can be a problem. I will try to free some time to do, Raphael is an excellent tool for that.

I agree with you. I don't play with ZX Spectrum games because I find its graphics limitation ugly. I think that a TI-99/4A port of Spectrum games should bring graphical improvements to exploit the TMS-9928 VDP otherwise might as well to play Spectrum games (for those who like this computer) directly on a Spectrum. That said the port work make by Rasmus is impressive, as always.

I haven't forgotten you. I am sorry for the delay but I have first to resolve a problem in my game before giving its code. Thank you for the interest about my question.

Of course, I well know that my alternative solution isn't the best one, it just permitted me to go forward in my development and may help some others that will encounter the same issue, in a waiting of a definitive solution. I will extract a part of my code with the VWRITE routines in use and that cause some trouble for being studied.

I'll do that to understand the problem. That said, my alternative solution by changing the order of the addresses written completely suites me 🙂

In this program I only use SCREEN1.

Continuing to investigate ... 🙂 As the game is very big, I have isolated a part of it that contains VWRITE routines and I ensured that this little part runs in loops to force the problem appears. In this part of the program, I made some modification in the way to call the VWRITE routine and I have found an interesting thing: Step1 : If the line containing the routine is written like this: CALL LINK("VWRITE",1104,F$(19+R1),1408,F$(15+R1)&F$(31+R1)) , I quickly get garbage on some characters in the screen. Step 2: If the line containing the routine is written like this: CALL LINK("VWRITE",1104,F$(19+R1)) :: CALL LINK("VWRITE",1408,F$(15+R1)&F$(31+R1)) No problem appears, even after very long minutes running. But no surprise for me because it is the way that I have found to correct the problem. Step 3: I tried something else: CALL LINK("VWRITE",1408,F$(15+R1)&F$(31+R1),1104,F$(19+R1)) I was surprised to see that no garbage appeared too, even after very long minutes running. As the program worked fine, I stopped it and modified the line as in the step 1: the problem immediately re-appeared. Then I stopped the program, modified the line as in the step 3 and all worked fine again. So, it seems that the appeal address order play a role in the problem manifestation.

It happen's both in XB256 and compiled, after a moment that can be one minute or more, but sometimes I can use the program during 15mn without any problem (I don't play during a long time because the game is in development) I think remembering that one time it appeared under the minute. I"ll take a screenshot.

A precision: There is a difference between the two codes, mine uses array variables. Like this: CALL LINK("VWRITE",1408,F$(16+R2)&F$(32+R2)) :: CALL LINK("VWRITE",1104,F$(20+R2),1016,F$(24+R2)) --> That works fine CALL LINK("VWRITE",1408,F$(16+R2)&F$(32+R2),1104,F$(20+R2),1016,F$(24+R2)) --> Ends to make some garbage on the screen after some time.

For testing, I used Classic99 and ti994w (as I said in my previous messages). And of course I use the latest version of them. Got the same result.

It's systematic. Each time I integrate more than two different addresses in the "WRITE" routine, the screen ends up being damaged after a few moments. Maybe your test is not done in the same context as mine. My program consumes more memory (about 1.6Kb remains for stack and 1,8Kb for program when running) and there are many graphics operations between the variable settings and their use in the WRITE routine.