Classic99 and TI BASIC odd behavior

[InfernalKeith]

Apologies if I missed this being mentioned earlier.  Given that most people don't try to write full-up TI BASIC programs any more, I could see it possibly not having come up yet.

 

I'm finishing my Tollkeeper game in Classic99, and several times now, after saving, several lines get truncated or garbled.  I've been editing right off the command line and SAVEing as I go, not expecting an issue like this, and I have already had to do some weird cut-and-paste action from a previous SAVE displayed on my screen via TIDir to fix what got "eaten" by the glitch.

 

My theories are 1) it's some anomaly caused by having a TI BASIC program this close to memory full, or 2) I've had my PC on for many days, and maybe that has something to do with it?  I closed and restarted Classic99 and it did it to another few lines of code.

 

 

[jrhodes]

Can you capture this behavior in a screenshot or video clip?

[+Vorticon]

I assume you have the latest version of the emulator? Your copy might have gotten corrupted somehow and it might be worthwhile re-installing it.

I honestly very much doubt this is a Classic99 issue as it has never come up before. @pixelpedant coded a large TI BASIC program recently (Hells Halls) and did not report any such issue either.

[InfernalKeith]

I think a reinstall might have fixed the issue (in the chaos of freaking out over my listing being messed up, I think I downloaded the latest version at one point but didn't actually extract it till this morning).

 

It was a weird glitch that reminded me of when my console used to overheat in the 80s when I'd work on stuff for hours.  As a quick example, I'd save code with these lines:

 

110 GOSUB 1000
120 GOSUB 1500
130 GOSUB 4000
140 GOSUB 2000
150 GOTO 130

And when I rebooted and reloaded, I had:

 

110 GOSUB 1000
120 GOSUB 1500
130 GOSUB 4000
140   LOG
150 LL2     LOG

This was happening at 2-3 places in the code each time I cut-and-pasted the correct code back in and saved.

 

So far this morning with the updated install, I am not getting any errors, but I won't have time till this evening to fully dig in and get back to work.

 

Probably operator error combined with a corrupted file, from the looks of things.

 

 

 

 

 

[SteveB]

Accurately emulated overheated RAM chip ... ???

[+TheBF]

1 hour ago, SteveB said:

Accurately emulated overheated RAM chip ... ???

@Tursi is good. Real good. 

[+pixelpedant]

Yeah, I've never experienced this kind of corruption with either Hell's Halls or its sequel, and in both cases, I'd have Classic99 left running for literally a month without corruption.  With versions of Classic99 dating back a couple years, all the way up to today. 

 

Especially in the case of Hell's Halls, I was (while using all available memory) pushing nearly all updates by just pasting modified lines into Classic99.  But this issue never arose. 

 

That's not really the case with the sequel though.  There, I need to tokenise externally and reload the program nearly every time I update, as the program uses all characters which can be typed on the TI-99 (including all non-printable characters which may still be typed).  And a large subset of those (like 176-198, all of which a TI-99 can type) have no ASCII representation.  So they can't just be pasted into Classic99. 

[+RXB]

Only issue I have had was not really Classic99 fault, Windows 10 does updates and makes files "READ ONLY" so makes a mess of Classic99 working properly.

Big problem is Microsoft refuses to fix this issue that OS X or Linux or Unix does not have.

 

This is proof of just how bad Windows is as a OS in that a error they know exists will never be fixed as the problem in baked into the OS!

[InfernalKeith]

I wish I had thought to grab video before I did the update, but it was doing this thing where I'd paste the correct lines back in, get another error, and when I went to list, a different line (one that had been ok before) would start listing like

 

 

200 GOSUB 

 

    LEN  

   ON ERROR EWROIJ  EFIO3   R40GIU#ytgj#

 

but it would just keep scrolling and printing nonsense, and I couldn't FCTN-4 out of it.

 

It definitely gave me flashbacks to losing stuff in my cassette-only high school days, which prompted the 2am panic in the first place.

 

As it is now, I'm "only" getting a MEMORY FULL even after CALL FILES now, so I have some work to do.

 

 

[senior_falcon]

6 hours ago, Vorticon said:

Your copy might have gotten corrupted somehow and it might be worthwhile re-installing it.

I honestly very much doubt this is a Classic99 issue as it has never come up before.

1980 gamer had a problem very similar to this where lines would do strange things. One time he had a long program that would only let you list one line at a time. If you deleted that line, then another line could be listed, and so on. Something had happened to the pointer to the line number table and by changing the pointer in the scratchpad the program could again be listed. There were disappearing lines, and essentially the same problems that Keith was having. He was using XB256, so we naturally figured it had something to do with XB256 and the interrupt routine. But I went through it with a fine tooth comb and could see nothing that might cause such behavior. So since something similar happened in TI BASIC, it could be something with Classic99 after all, although smart money would still be on XB256 causing the problem

The trouble with problems like this is that they are so infrequent that troubleshooting is virtually impossible.

[+Vorticon]

I guess it's time to @Tursi's input...

[InfernalKeith]

1 hour ago, senior_falcon said:

The trouble with problems like this is that they are so infrequent that troubleshooting is virtually impossible.

I am in awe of everyone who puts together these tools we use, for little reward and lots of heartache.  I can only imagine what testing something this size is like, with a relatively small user base.

[senior_falcon]

I just discovered some additional odd behavior in Classic99. I can load the most recent RXB as a "user" cart. This runs fine as my one line program shows. If I then load a rom cartridge with the compiled version of TML demo, the two entries for RXB are still in the menu, followed by TMLDEMO. It appears the groms for RXB are still there. Of course, RXB will not run without the roms. TMLDEMO runs fine because that is what is in the roms.

It looks like this can be fixed easily by zeroing out the groms.

Edited April 22 by senior_falcon

[senior_falcon]

OK, this is getting really weird. Here is a short video showing the computer in TI BASIC. I choose XB 2.9 G.E.M. and you can see the options on the menu. I press 2 for XB 2.9, then type CALL HELP, which is only available in XB 2.9 G.E.M.

I then choose the user cartridge TMLDEMO, which is 4 banks if that matters. The computer resets to the master title screen, then press a key and the main menu comes up, but with RXB on the menu!!

What in the blue blazes is going on???

 

[jrhodes]

1 hour ago, senior_falcon said:

OK, this is getting really weird. Here is a short video showing the computer in TI BASIC. I choose XB 2.9 G.E.M. and you can see the options on the menu. I press 2 for XB 2.9, then type CALL HELP, which is only available in XB 2.9 G.E.M.

I then choose the user cartridge TMLDEMO, which is 4 banks if that matters. The computer resets to the master title screen, then press a key and the main menu comes up, but with RXB on the menu!!

What in the blue blazes is going on???

 

You've caught the RXB virus apparently

[Tursi]

On 4/20/2023 at 9:57 AM, InfernalKeith said:

I wish I had thought to grab video before I did the update, but it was doing this thing where I'd paste the correct lines back in, get another error, and when I went to list, a different line (one that had been ok before) would start listing like

 

 

200 GOSUB 

 

    LEN  

   ON ERROR EWROIJ  EFIO3   R40GIU#ytgj#

 

but it would just keep scrolling and printing nonsense, and I couldn't FCTN-4 out of it.

 

It definitely gave me flashbacks to losing stuff in my cassette-only high school days, which prompted the 2am panic in the first place.

 

As it is now, I'm "only" getting a MEMORY FULL even after CALL FILES now, so I have some work to do.

 

 

TI BASIC is such that certain types of corruption will move if you delete lines. I had an old cassette program that did it back in the day that I could never fix as a result of that.

 

Are you using CALL FILES when you get the corruption, or running with the stock memory layout? If you are using CALL FILES, with what disk layout and what count? I'm aware of one weird behaviour with call files that I need to track down, though I need to check my notes to see if it is TI disk controller or Classic99 disk controller. If you're using one, it's worth trying the other briefly just to see. (It's enough to make any of DSK1-3 a TI controller, even if you are not using it, so far as the CALL FILES goes.)

[Tursi]

@senior_falcon I'm going to paste my usual "what does the debug log say?"... though I know it's hard to read with the new debug window. I would recommend using an external debug monitor to be able to capture the long lines - DebugView works and I use it sometimes myself. You can also run from Visual Studio to capture.

 

In the second one, since you're loading user entries, without seeing your Classic99.ini and/or the debug log we are only guessing what is going on. But the INI version only loads what you tell it to. Did you maybe drop it in there as an experiment, or accidentally lose the header that might separate the two carts?

 

In the first one, you're using user->open. That will search for all possible matching filenames (C/D/G/8/9/etc) and load them. The debug log will tell us what it found.

 

[InfernalKeith]

> I had an old cassette program that did it back in the day that I could never fix as a result of that. 

 

 

Does this mean I can give up on this fool's errand and rewrite this damn thing in XB? 

 

 

[InfernalKeith]

I'm trying to remember the exact sequence of things, but one bit of corruption did pop up even before I was using CALL FILES.  It was a weird overwrite of a PRINT statement that I attributed to a typo, something like

200 PRINT "TOLLKEEPER" : : : : :

 

turned to

 

200 PRINT "TOLLKEE"TOLLKEEPER" : : : : :

 

I fixed it and it stayed fixed, but I think the corruption in multiple lines started when I typed CALL FILES before loading.  At that point I was just trying to cut and paste from TIDir into Notepad to make sure I didn't lose pivotal lines.

 

I haven't ever messed with the disk controller settings, so whatever their defaults are is what I have going.  I haven't really had time to work on it since all this happened, so I don't know if reinstalling the base program fixed it for sure, but I'm off Monday and Tuesday and hoping to get it back under control memory-wise then.

 

 

[SteveB]

6 hours ago, senior_falcon said:

What in the blue blazes is going on???

Have you tried it on a fresh installation and with a locally stored fresh XB 2.9 and TMLDEMO? 

[1980gamer]

On 4/20/2023 at 1:58 PM, senior_falcon said:

1980 gamer had a problem very similar to this where lines would do strange things. One time he had a long program that would only let you list one line at a time. If you deleted that line, then another line could be listed, and so on. Something had happened to the pointer to the line number table and by changing the pointer in the scratchpad the program could again be listed. There were disappearing lines, and essentially the same problems that Keith was having. He was using XB256, so we naturally figured it had something to do with XB256 and the interrupt routine. But I went through it with a fine tooth comb and could see nothing that might cause such behavior. So since something similar happened in TI BASIC, it could be something with Classic99 after all, although smart money would still be on XB256 causing the problem

The trouble with problems like this is that they are so infrequent that troubleshooting is virtually impossible.

Yes, I was also have some save issues.  Data being corrupted.  I don't know if these were connected in any way?
I have been bogged down at work and not working on any TI projects for 2 months at least.

 

I do plan to start back at it very soon as I have 5 projects pretty far along.

 

I just did some backups of things as my laptop has been flaky that past few days.

[Tursi]

12 hours ago, InfernalKeith said:

> I had an old cassette program that did it back in the day that I could never fix as a result of that. 

 

 

Does this mean I can give up on this fool's errand and rewrite this damn thing in XB? 

 

 

[Tursi]

12 hours ago, InfernalKeith said:

I'm trying to remember the exact sequence of things, but one bit of corruption did pop up even before I was using CALL FILES.  It was a weird overwrite of a PRINT statement that I attributed to a typo, something like

200 PRINT "TOLLKEEPER" : : : : :

 

turned to

 

200 PRINT "TOLLKEE"TOLLKEEPER" : : : : :

 

I fixed it and it stayed fixed, but I think the corruption in multiple lines started when I typed CALL FILES before loading.  At that point I was just trying to cut and paste from TIDir into Notepad to make sure I didn't lose pivotal lines.

 

I haven't ever messed with the disk controller settings, so whatever their defaults are is what I have going.  I haven't really had time to work on it since all this happened, so I don't know if reinstalling the base program fixed it for sure, but I'm off Monday and Tuesday and hoping to get it back under control memory-wise then.

 

 

I would not expect reinstalling to have any effect unless your system is virus infected. The symptoms aren't random enough. Eventually I should sign the executable... but just in terms of general updates, nothing has changed in a decade that should affect VDP RAM.

 

Remember after typing CALL FILES, you need to do a NEW before you load. Are you doing that?

 

Is memory full without the CALL FILES? What value are you entering?

 

[Tursi]

There is a strange Classic99 bug with CALL FILES(1) that I recorded some years ago - and I have no reason to believe it went away. CLIP and SPEECH stop working, which makes no sense. I've not had a chance to look into it, but that is why I am so focused on CALL FILES in your symptoms.

 

[+RXB]

16 hours ago, jrhodes said:

You've caught the RXB virus apparently

Was this needed?

What value does this have other than to disparage me?

 

GOOGLE: 

What does disparage mean?

 

 

1 : to depreciate by indirect means (such as invidious comparison) : to speak slightingly about. 2 : to lower in rank or reputation : degrade.