Strange Assembly Problem

[Reciprocating Bill]

I've encountered a strange assembly problem:

 

I’ve written an assembly program that is generally working fine, but for one vexing glitch:

 

- Power up TI

- Enter Editor/Assembler

- Load and run mystery program (option 3).

 

The program is completely haywire.

 

Yet:

 

- Power up TI

- Enter Editor/Assembler

- Load some other small source file for editing. (No need to edit or even view the file.)

- Load and run mystery program (option-3).

 

It runs perfectly.

 

I’m a bit baffled, because all memory locations utlilized by the program are properly initialized, so far as I can tell. Yet loading the Sieve source before running the NWO object seems to “intialize” something to a happier state.

 

https://youtu.be/TAz0FXGrOfQ

 

The video is real hardware, but the same behavior is seen in Classic99.

 

The program builds a pattern in Graphics 1 using a simplified Wave Function Collapse algorithm (tile version, 10 tiles), after which six sprites trace some of the pathways the algorithm creates.

 

 

[HOME AUTOMATION]

Firstly... That's not the Editor/Assembler, I'm familiar with!

[GDMike]

Look at your memory addresses in classic 99 debugger

[+mizapf]

1 hour ago, Reciprocating Bill said:

I’m a bit baffled, because all memory locations utlilized by the program are properly initialized, so far as I can tell.

Still, I'd bet everything that there is something uninitialized. Do you have a DSK image to try in MAME for comparison?

[PeteE]

Classic99 debugger has a method of detecting uninitialized memory reads:

Quote

Debug → Detect Uninitialized Memory

Classic99 has the ability to trigger a Breakpoint on read access to RAM that has never been written to. This can help to find uninitialized memory bugs.

 

To use this functionality, simply select this option before launching your program. When uninitialized memory is read, a popup box will display while the emulator breakpoints in the background.

 

Classic99 tracks writes to memory from the moment that emulation is started. At any time you can select Debug->Reset Uninitialized Memory Tracking to clear this tracking. From the moment you select it, ALL RAM is considered uninitialized. If a program is running at the time, including the TI operating system, it is very likely that you will immediately breakpoint for reading uninitialized memory (when in fact, it was initialized before you pressed the button.)

 

The best way to use this feature is to leave it off while you load your program, and to set a breakpoint on the first instruction of your code. When your breakpoint is hit, then select the Reset option, and then continue the program.

 

Edited April 2, 2023 by PeteE

[Reciprocating Bill]

I'm using Tursi's E/A Complete (running out of FinalGrom), which unfurls the Editor and Assembler from GROM rather than reading them from disk, speeding things up considerably. The problem persists with a stock E/A module.

 

Classic99 does detect attempts to read from uninitialized memory way out in the weeds, in the >6000 - >7000 address range (cartridge ROM) - but only during haywire runs. Something is amiss in the chain of events that determine the value of an array index (e.g., R12 in, "MOVB @LIST(R12), R1"), as the value of that index is WAY off. But why, and why fiddling with the Editor first prevents this, remains a mystery.

 

The game's afoot!

[+TheBF]

On 4/2/2023 at 8:04 PM, Reciprocating Bill said:

I'm using Tursi's E/A Complete (running out of FinalGrom), which unfurls the Editor and Assembler from GROM rather than reading them from disk, speeding things up considerably. The problem persists with a stock E/A module.

 

Classic99 does detect attempts to read from uninitialized memory way out in the weeds, in the >6000 - >7000 address range (cartridge ROM) - but only during haywire runs. Something is amiss in the chain of events that determine the value of an array index (e.g., R12 in, "MOVB @LIST(R12), R1"), as the value of that index is WAY off. But why, and why fiddling with the Editor first prevents this, remains a mystery.

 

The game's afoot!

Since you are using R12 as the index to LIST is it possible you are doing some CRU I/O somewhere that is messing up R12?

 

[RXB]

LOL I can tell you exactly what happened as it has happened to me a few times.

I have written with GPL Assembler and the Object code is designed for only GPL but can be loaded by Editor Assembler,

but was designed to be loaded by GPL@LOADER as both are RYTE DATA products along with the GPL Linker.

Anyway I forgot to load the GPL@LOADER and instead just used the EA 3 option so as the memory was initialized you get very random results.

 

See normally the memory is zeroed out but if not you get random results.

You can check this by turning off the P-Box and running it and every time it will be fine, but if not you get weird results instead.

 

I even did this the other day on accident AGAIN!

[apersson850]

Still the thread started like this.

On 4/2/2023 at 5:54 PM, Reciprocating Bill said:

I’m a bit baffled, because all memory locations utlilized by the program are properly initialized, so far as I can tell.

[Reciprocating Bill]

 

I've made some progress, and though these comments and the Classic99’s debugger I’ve learned some things:

 

If a file has been loaded into the Editor, the loader does NOT subsequently zero out CPU RAM (>A000 onward) prior to loading an Option 3 file. Object code is laid right over the source data previously loaded into the Editor. RAM reserved by BSS directives (etc.) continues to display source data in any block that is not explicitly initialized.

 

To give the loader a blank slate into which to load the object, it is necessary to exit E/A, then reenter and go directly to the Option 3 load. I imagine that the Editor's "Purge" command does the same thing. Then it's all zeros.

 

Freakishly, my program functioned properly only when leftover Editor contents were peaking through. In fact, adding code to ensure that every last BSS block (etc.) was zeroed out guaranteed that the program would NOT work, regardless of what had previously been in the Editor. (Obviously, my code needs work.)

 

So my code was running, when it ran, not because I had properly initialized RAM, but because I hadn't properly initialized everything and junk was peaking through. But why? And how often does it happen that accidental junk contributes to a program's functioning?  

 

As a last step, I deliberately initialized the small blocks of RAM in question (30 bytes for three small arrays, plus three 32 byte blocks for workspaces) with arbitrary data that I'd found enabled the program to work. That was successful: the Editor no longer needs to be invoked to run the program. 

 

So I'm in the strange position of having written a program that works, without entirely understanding how it works. 

 

Can't stop there...

 

[Tursi]

Welcome to software!

 

[Reciprocating Bill]

With great help from Senior Falcon I've got this thing working reliably. The primary take home for me is to be aware that the state of the computer may differ each time the E/A loader gets busy. 

[Stuart]

On 4/7/2023 at 10:03 PM, Reciprocating Bill said:

With great help from Senior Falcon I've got this thing working reliably. The primary take home for me is to be aware that the state of the computer may differ each time the E/A loader gets busy. 

So what did you need to do?

[Reciprocating Bill]

The fact the program only ran properly only when certain values were NOT initialized, and therefore assumed random values left behind by the editor (or not), enabled me broadly, and SF very precisely, to determine that the value contained by a single memory location was the culprit. When it was initialized to zero, the program would not run properly. Any other value would let it run.

 

That solved the problem "empirically," although there was a LOT of source to wade through to determine WHY that value was a problem. 

 

That never happened. I had over-built the code that generates the background pattern in an attempt to include all of the elements of the Wave Function Collapse algorithm. While refactoring I found that I could get an identical (and faster) result with a simplified (but less general) version, so pulled out a step (I omitted using the 'entropies' of uncollapsed cells to select which cell would be tiled next). As I simplified the code, out went the offending memory accesses.

 

I asked my Magic 8 Ball whether I was ever likely to put in the effort to solve the original code. It said, "Outlook not so good."   

Edited April 8, 2023 by Reciprocating Bill

[RickyDean]

Shazam!!!