Do not assign to MID$() for NEC compatibility about m100le HOT 5 CLOSED

It occurs to me that we could use POKE to write to strings if NEC's BASIC had VARPTR(). However, I am pretty sure it does not.

So another idea occurs to me. What if the program allocated a small data file in RAM just for temporarily holding variables. Since we already have the routine for finding a file's address in RAM storage, it should work easily and be cross platform. The only problem might be if the program doesn't exit cleanly and an ugly temp file is left behind in the directory.

To allocate 64 bytes of memory:

10 IF ID=148 BSAVE "TMPFIL.CO", 0, 64 ELSE SAVEM "TMPFIL.CO",0,64

To access that memory:

20 WL$="TMPFIL.CO"
30 GOSUB 2000
40 TF=WA
50 IF (TF=0) OR (PEEK(TF+2)+256*PEEK(TF+3) != 64) THEN ERROR 6
60 TF=TF+6
70 A1=TF: A2=TF+5: WF=TF+10: SO(1)=TF+16 [... etc ... ]

from m100le.

Neat! I like this solution :)

I was looking at item 9 on this page: https://www.web8201.net/m100nec.asp As a way around it... but I like your approach!

from m100le.

Neat! I like this solution :)

I was looking at item 9 on this page: https://www.web8201.net/m100nec.asp As a way around it... but I like your approach!

Yeah, item 9 is a bit ugly looking, though I'm not confident using a temp file for string storage won't be even uglier.

Another possible solution: Item 5 gives a VARPTR implementation which might (or might not) be cleaner. I believe VARPTR allows one to get the memory address of a string and manipulate it.

Pros:

• Strings are strings and can be printed as such.
• No worry about accidentally leaving a temp file behind.
  Cons:
• Perhaps less portable than a RAM directory
  • Written in machine code
  • Does this code work on all NEC models?
  • Does VARPTR exist on all other Kyotronic computers?
• the machine code may be too confusing to try to use or debug.
• Requires treating NEC computers differently.

from m100le.

Hmm, still more of a workaround for the NEC. Would be nice to use the tempfile or, how much room do we need? There is room in the LCD buffer RAM that's accessible. Basically 20 bytes (if my math is right) of display RAM that's outside the LCD viewing area, but is addressable.

P. 154-155 from the NEC Technical Reference

from m100le.

LCD buffer sounds like a cool trick, but probably is not very portable. Also, the code for getting the data in and out might be kind of ugly.

I've been thinking more about using a data file in the RAM Directory as a way of allocating storage and I realized that the data in there would persist if M100LE didn't delete it. Meaning, if you want to keep track of a streak or have a histogram of results, that would be easy to do.

On the other hand, POKEing and PEEKing data is not the most elegant way to be addressing the bytes of string. Particularly when it comes time to print the string, instead of simply printing it, we'd need something like:

FOR T = X TO X+5
  PRINT CHR$(PEEK(T));
NEXT T

It might make sense to instead use an array of characters. Such as A1$(1)="A": A1$(2)="B": A1$(3)="C"... That could be the most portable and probably wouldn't be too slow for manipulating and printing the variables.

from m100le.