fabrice montupet

Thank you for your answer, I'm not sure that the problem comes from emulators. The problem happens totally random. On a same level (the program is a game), all can work perfectly during numerous minutes or hours, then graphic corruptions can suddenly appear. I stop the program, re-run it and all is OK again...for a time.

Yes, actually I have not tested with Mame. In fact, it is not installed on my computers because I don't use it (it's really a good emulator, a great job but it doesn't corresponds to my needs, I'm sincerely sorry). As the problem is present on Classic99, ti994w (and also on js99'er), I ended to conclude that the problem was with XB256. To precise: I use ti994w for all my developments. Classic99 comes in one step: the compilation and I use occasionally Js99er for debugging and dump operations: Precious helps!

I would like to talk again about a problem mentioned before and on which there was no answer. I had many display problems passing several addresses/string patterns using only one CALL LINK ("VWRITE") routine so, I changed my way of use: During more than 4 months, I ran my XB256 program successfully with no problem using this other method: CALL LINK("VWRITE", memory address1, string1) :: CALL LINK("VWRITE", memory address2, string2) :: CALL LINK("VWRITE", memory address3, string3) :: CALL LINK("VWRITE", memory address4, string4) Today, to earn some memory, I retried the previous method, using this: CALL LINK("VWRITE", memory address1, string1,memory address2, string2,memory address3, string3,memory address4, string4) ...And I quickly had graphic problems again (erratic oblique moving of sprites and garbage in several char patterns). This this very frustrating.

Very didactic! I keep this documentation preciously, thank you 🙂

Thank you for your moderation and the cleaning, I appreciate.

I was always impressed by the powerful of Forth and always would have liked to learn programming with it , but I never had the courage to start. I hope one day. So I want to salute your will power and enthusiasm.

Apart of this, I succeed to make TRACE5 working with my program. As the ti994w emulator offers the way to manage the speed execution with a great flexibility, it is very easy to read all the lines in execution displayed in only 5 lines without missing one. The routine alters the top left part of the screen and in some cases, it can be a problem if it erases characters that are necessary for the program execution. A fine solution could be to be able to insert a value at the routine call permitting to select the TRACE5 area position among the four corners of the screen. Without replacing a sort of TRACE in a log file, this routine does a great job and can be extremely useful. It joins preciously in my developing tools. Thanks Harry 🙂

I'm trying a way, inspired by Harry in the thread "Recursive example XB" where he proposes to read the address that contains the line number in execution. I'm currently testing with the emulator's debugger as it can create a log file.

In the case of a solution that alter a part of the screen, the good solution is proposed by Harry with TRACE5.

Oh! It's very interesting, thank you 🙂

I don't use RXB and I will not intend to. Please, could we end RXB mention in this thread, thank you.

Keep it mind that this has for me no interest if this is for RXB.

Thank you, it's interesting! But the TRACE5 uses a part of the screen to display lines numbers (and this is what I would like a such tool doesn't). That said, it crashes when I load it with ti994w and when programming I only use this emulator.

Since some time, I have in mind a function that could be implemented into XB256 or TiCodED, if it is considered interesting. TI Basic offers the TRACE function that, in theory, is very useful to detail the behavior of a program when running and to catch possible bugs, unexpected routes. But TRACE has a big default that makes it unusable in most of the time: the listing of the lines in execution destroys the screen content that often makes graphical programs impossible to run correctly. Could be possible to make a sort of TRACE that creates a log file on a disk that contains all the lines executed until the program stops? I think that this log would be rich in information for any XB developer. Has my proposal some sense?

I also thought about this when read the message but I thought myself that Joe has surely also thought about it. Without seeing the entire code of game it is difficult to give an advice about a way to make different and quicker.

Yes, in numerous cases GOSUB and GOTO are irreplaceable, the goal is just to avoid them when it is possible.

Can't tell you, I don't use the SUB statement. Yes, compilation reduce but does not eliminate according to the tests I made on the XB256 game I am working on and that heavily consumes computer resources (I have to continuously do my best to optimize the code on each feature I add to keep the game playable so I try all the paths). But, the best thing is to ask to Harry to confirm.

104... It's impressive. GOSUB AND GOTO are statements that I try to reduce their number as possible it can be done (when it's possible) because they are source of execution slow down. I see that they are not a problem for Avaris II 🙂

It is just due to a German "Video Chess" cartridge used in the 99/4A in use. When we insert "Echec", the French "Video Chess", the main screen is also modified.

As far as I'm concerned I can't say as I don't use MAME, all I can say is that XB 2.9 G.E.M. works fine with Fred's ti994w emulator.

In my Timer subprogram I use the value 248 because the main program branches to many other subprograms so have many things to do. In the Timer subprogram I also added the check for the automotion projectile sprites to be prevent appearing on the other side of the screen when they have reached a border.

Seems that it is the best solution that we use 🙂 The other solution proposed by Harry is really clever too, I will make some tests using it to see the pro and cons of these each tricks.

Focusing on the subject of the thread, is someone uses some other tricks to get a timer on XB?

It is the trick I also use for my game in progress, I find it very very efficient. The sprite is moving at 240th line, hidden 🙂

@FarmerPotato : That could be fine!