Fix RAM Directory for 8201 and T102

[hackerb9]

8201a ran [RNDACC] without error, though the data displayed when it showed the selected word was incorrect.
Word one in WL2022.DO should be REBUS.

And just to see what happens, I ran it on the 102... RNDACC runs, but can't find the file as 'unusual' data is discovered ... likely due to the offset in line 16 being inaccurate as PEEK(1) on the model 102 isn't tested( 167).

Originally posted by @bgri in #14 (comment)

[hackerb9]

@bgri, Please run this version of RNDACC on your PC-8201A and let me know what the three byte encoding it prints out for BTNWR. Hopefully htis is just an off by one error. The bytes for REBUS should be 93, 227, 130. If they all match, then perhaps, there is something funny about the way math is done on the NEC machines. If none of the bytes match, then we have something more serious going on, like reading the address in memory incorrectly from the Ram Directory.

[bgri]

Hmmmm.

[hackerb9]

That's odd. There is an off by one error: the size should be 1098 not 1097, but those bytes (195, 148, 124) don't appear anywhere in my copy of WL2022.CO.

It clearly is somehow related to the right file: the size is too close to be an accident. And any other .CO file would have the LOAD and START addresses set to something real, not zero, which would have triggered a warning message.

When I'm not so tired, I'll think about this more. In the meantime, can you verify that you have the current WL2022.CO file? Is it possible the one on that machine was created by an old version of CMPRSS?

[hackerb9]

I figured it out. Your WL2022.CO file was not created correctly. The space for it was allocated using BSAVE "WL2022.CO",0,1097 but the data was never actually poked into place. Perhaps there was a problem running CMPRSS?

The bytes we're seeing are simply a copy of the ROM that was made during the BSAVE. If you do

? peek(0) peek(1) peek(2)`

I bet you'll see the same numbers (195,148, 124).

The solution is to either run CMPRSS to create WL2022.CO from an existing WL2022.DO (on the NEC or on a remote computer via serial) or you can simply transfer the current WL2022.CO file to the NEC.

[bgri]

Yep, same numbers. Then transferred the version of WL2002.co from the previous comment and it works fine.

So it was a badly-created .CO file. Good to know. And we have another success!

[hackerb9]

That's great! And the T102?

[bgri]

Sorry for the delay. Had issues getting TS-DOS to my 102, then power issues. It all came together this morning though :)

[hackerb9]

Hurray! Closing this issue as fixed.

[bgri]

As an additional comment. Part of the issue I had was when I attempted to remove WL2022.CO using the KILL command: KILL WL2022.CO the 102 would lock up. Also occurred when using TS-DOS to attempt removal or overwriting the file, though that time I heard the relay click.

Of course, this meant a complete restart, configure TERM, read in TS-DOS.DO, Run/install TS-DOS, then read in M100LE.DO, save it, and read in WL2022.CO. Good thing I like playing with these things :)

As for the deleting of the .CO file, something's fishy in the state of Denmark...

[hackerb9]

As an additional comment. Part of the issue I had was when I attempted to remove WL2022.CO using the KILL command: KILL WL2022.CO the 102 would lock up. Also occurred when using TS-DOS to attempt removal or overwriting the file, though that time I heard the relay click.

Of course, this meant a complete restart, configure TERM, read in TS-DOS.DO, Run/install TS-DOS, then read in M100LE.DO, save it, and read in WL2022.CO. Good thing I like playing with these things :)

As for the deleting of the .CO file, something's fishy in the state of Denmark...

Yikes. I wonder if the fishy .CO file was created by an old version of my CMPRSS.BA program before I had added support for the T102. It would have created the file using SAVEM and then (if the program didn't check for errors like it does now), it would start trying to POKE data into the file. I wouldn't have thought that could be a problem as the file address would be zero, meaning it would be harmlessly POKEing into immutable ROM.

I hate to make you the guinea pig, but would you mind trying the current version of CMPRSS on the Tandy 102 and see if it blows up?

[bgri]

I hate to make you the guinea pig, but would you mind trying the current version of CMPRSS on the Tandy 102 and see if it blows up?

I love being a guinea pig -- I've got the hardware, may as well use it. I've added it to the top of my list.

[bgri]

Looks like that got it. New version of CMPRSS created WL2022.CO. Then Killed it from basic.