JamesD

Malevolence Free https://freebies.indiegala.com/?ref=freebies

This War of Mine and Moonlighter will be the next Epic games for free.

The Ubisoft UPLAY app is promoting their upcoming Uplay+ service by offering a free trial. You can sign up now, and in September you'll get an email, and will be able to try out the service from Sept 3rd - Sept 30th for free. "Cancel anytime"... which probably means you'll have to give them payment info, and you will be billed if you don't cancel. It would be a good time to take some of their games for a test drive.

Limbo is the latest freebie from EPIC games

https://www.pcgamer.com/the-original-borderlands-is-free-on-steam-for-the-weekend/

BTW, if you didn't see the original post, maybe you blocked me?

Because MS BASIC (at least the versions I've looked at) store the current line number, rather than a pointer to the current line. That means there is no other way to find the linked list the lines are part of. Why does it store current line number instead of a pointer? I haven't figured that out yet. A few bugs have been introduced over several versions, and once I track those down I might find the source of this madness. If not, it may just be a bad design choice.

If you mean it searches through the linked list looking for line numbers, that is the same. I added ELSE to my custom version of the interpreter, but it would be faster without it since it doesn't have to check to see if there is an ELSE. It just starts at the next line if the line number is greater than the current line. The original code searches for the end of the current line before starting the line number search. My version just starts checking line numbers using the pointer to the current line.

Integer BASIC is not a MS BASIC, so it is very different. I'd be writing an interpreter from scratch. Supporting integers is on my list of wants, but it requires a lot of changes to the parser. Some of the changes I've mentioned will actually make supporting integers easier in the long run. The big issue with integers, is that I need to create an integer math library, searching for integer variables in variable storage space, possibly modify the stack frame, modify expression evaluation, etc... so it's no simple task. As I said, I may use tokens to identify different variable types to simplify parsing, even if I'm not thrilled with the idea. Ultimately, the best way to speed up a BASIC program is with a compiler. I've made progress with several projects in that area, and I may even ditch further interpreter optimizations once those are done.

I think all Microsoft BASICs are like this. I looked at what it would take to add computed branches (GOTO variable) to the MC-10. It would be relatively easy to look up the value of a variable, convert it to a 16 bit int, and then search for that line number. The key difference, is recognizing the first non-space character after the GOTO or GOSUB is a letter rather than a number, and you have to make sure it's not a string variable. But this would make the interpreter larger, and a lot of things Microsoft did were due to size.

That is exactly what I first considered, but using different tokens instead, simplify's parsing at run time. I may still do this do to some other issues it would solve.

One nice thing about using pointers, is that if you want to push the line number to the stack instead of the pointer, you can. You'd have to look up the line for every iteration of the for loop though.

As of the latest changes to the MC-10's BASIC, Ahl's Benchmark seems to run in 1:06. Down another second... ish... I'm hand timing here. Almost every other program has shown much more improvement with each revision, which indicates the bottleneck is SQR and ^. And I've only exceeded the 8K ROM size by 191 bytes, most of which is a larger token jump table.

Another new BASIC game. Guess I should edit the title of the thread https://www.cankenmakeit.com/2019/07/new-game-for-coco-1-2-and-3-nightmare.html

The scrolling was done in assembly... but it shows what you can do with BASIC.

Payday2 $4.32 https://www.fanatical.com/en/game/payday-2-ultimate-edition

FWIW, MS BASIC keeps the current line number, and it uses that in FOR NEXT loops. I changed it so it keeps a pointer to the current line, and FOR NEXT loops now use a pointer, and it skips the line search.

THEN and ELSE would have to deal with the same issues as GOTO and GOSUB. Forgot those. RUN linenumber is also a special case

A lot of this is subject to change based on what the code actually does/will be vs what we think. 🤪 And the "unintended consequences". This is the current code I'm dealing with. The initial parse JSR will be ditched when I move that to the tokenization stage. GOTO jsr LE6B2 ; parse line number into BINVAL ldx CURLIN ; get address of current line ldd BINVAL ; D = target line number subd 2,x ; subtract current line # bhi LE628 ; branch if target > current ldx TXTTAB ; point X to beginning of program LE628 jsr LE3BB ; search for the numbered line bcs LE642 ; issue a ?UL ERROR if not found dex ; point X to previous line's terminator stx CHRPTR ; set new parser position LE630 rts ; resume at the target line After the change to ints and pointers, the GOTO function should look something like this for the first call (GOTO INT). ;*** GOTO 16 bit integer line number GOTO ldx CHRPTR ; point to current character ldaa #GOTOP ; TOKEN for GOTOP funtion staa ,X ; update the token ldd 1,x ; target line number ldx CURLIN ; get address of current line subd 2,x ; subtract current line # bge LE628 ; branch if target >= current ldx TXTTAB ; point X to beginning of program LE628 jsr LE3BB ; search for the numbered line bcs LE630a dex ; point X to previous line's terminator pshx ; save the pointer to the stack pulb ; put the pointer in D pula ; could use XGDX on 6303 instead of stack ldx CHRPTR ; point to current parse character std 1,x ; save pointer after GOTOP std CHRPTR ; set new parser position LE630 rts ; resume at the target line LE630a ldx CHRPTR ; point to current parse location ldaa #GOTO ; revert back to GOTO token sta ,x bra LE642 ; issue a ?UL ERROR if not found The code should look like this for once the pointer is set. ;*** GOTO Pointer GOTOP ldx CHRPTR ; get current parse address ldx 1,X ; get new line address (GOTOP token address +1) stx CHRPTR ; set new parser position rts ; resume at the target line The RTS will have to be replaced with different code since this was specific to the current implementation, but if this code can be moved in front of the main loop it ends up calling, it can just go away. Three instructions for a GOTO is pretty efficient for an interpreter, and a massive improvement over what it does now. GOSUB and GOSUBP will need to be a little longer to push the return stuff onto the stack, and GOSUBP might be able to fall through into this.

Chipset upgrades would have certainly helped the Atari, but some of those projects bit the dust in cost cutting measures even before Tramiel came in. Amy certainly would have upped the sound game vs the SID, but it would have upped the price at a time when computer prices were falling. The time to add the Amy would have been with the XL line, as you need a significant number of machines with it built in to get significant software support for it. Any later, and software support would be a lot more limited. By the time the XE line rolled around, it would probably have to be integrated with other chips to keep costs down. It's really sad Amy got cancelled, it could have also sold to arcade game manufacturers, giving Atari another source of revenue during the "crash". It would have at least given Atari the appearance of continued innovation. A built in 80 column mode was needed to compete with the IIe, but 1985 would have been very late, as Apple had a commanding lead in business software by then. That type of upgrade was needed with the XL series along with other additional graphics features. If you improve the graphics, sound, and business capability of the system in 1983, Atari would stand a much better chance in the market going forwards, but they really needed to introduce cheaper machines right on the heels of the C64 , maybe in 1982 before the C64 had such a glut of software. The XEGS was too toy like with the pastel colors, and weird angled slot on the top. It was made to be a game console, and nothing else. Plus, it wasn't released until 1987, which is way late in the game. Had they put the cartridge slot, and more normal looking buttons on the front, it could have been a small pizza box style machine that could fit under a low profile monitor stand, or in a tv stand. You could also fit a low profile external 3.5" drive right next to the machine had they released one. Support 128K like the 130XE but with only 64K installed on cheaper models, and offer an optional keyboard with a numeric keypad. Then sell it in bundles like they did in the past. Include a built in game with the entertainment package, built in Atariwriter (or similar) with the personal setup, and for the premium system, include Atariwriter(?) or Assembler(?) built in + keyboard with the numeric pad + 128K already installed. Atariwriter should have been upgraded to at least support more RAM. This is the machine that should have come out instead of the the 65XE, and 130XE. Just a thought.

In my case, the MC-10 (and most other 8 bit MS BASICs) only support the short floating point format. There isn't any precision option, though calculations use an extra byte for greater precision. There are ROM functions to convert ASCII to float, float to 16 bit signed int, float to unsigned int, and float to 8 bit int.. among other things. It's easy enough to manipulate, but it's time consuming. There really aren't any ints until after numbers are converted. Well... I'm dealing with MS BASIC. For one thing, MS BASIC stores line numbers as ASCII. I wanted to move the ASCII to 16 bit int number conversion to the line tokenization stage, then the ASCII conversion (which I've already sped up) is done up front since it's a costly operation. That alone would offer a decent speed improvement. Changing int line numbers to pointers would eliminate line number searches every time GOTO or GOSUB is encountered. Converting to ints during tokenization also means line lengths aren't altered at runtime by switching from line numbers to pointers. I also plan to remove spaces during tokenization to simplify runtime parsing. At runtime, whenever a token is encountered, the normal interpreter does a range check on the token, then calls an error hook if it's a bad token, or calls the function. I enlarged to the token index table so the range check can be skipped, and it just does the jump to the function, or error hook for bad tokens. If the normal ON/GOTO/GOSUB calls directly jump to a function that converts line numbers to pointers, it just automatically assumes it has to convert before continuing. The line lookup is completed, the int is changed to a pointer, and the token is changed to the alternate token. Then if possible, I'll position the code so it drops into the pointer version of GOTO or GOSUB to make the jump. Eliminating spaces during tokenization guarantees that the 16 bit line number will immediately follow the token, so we don't need to search for the INT. From then on, when that GOTO/GOSUB function is encountered, the function that expects pointers is called, and it just loads the address to continue executing from as the next two bytes if the flag for ON isn't set. ON has to do a comma skip, and a check for the end of the list of line pointers, so it will be slower, but not by much since it can just test every third byte (if spaces are removed) as it searches for the line number to call. Any syntax error should be barfed out during tokenization, and any unknown line number will be barfed out during the line number lookup. Anyway, this change to GOTO and GOSUB could save thousands of clock cycles over the current interpreter every time one is encountered. Everything time consuming is done during tokenization, or just once. Well, in theory anyway. Actual coding may be more difficult. (unintended consequences are sure to follow) That leaves expression evaluation, and variable look ups as the big bottlenecks, and solutions aren't quite so easy. Improving variable lookups, would speed up a lot of things.

Du-Oh! Yeah, you are correct. MS BASIC always normalizes the number so you can't just grab the first 16 bits and expect it to be the line number, but there is already a ROM call to get an unsigned 16 bit int.

@linville, here is a youtube of Rommel's Revenge from someone else you should be able to see. I would have loved this as a kid.

BTW, I have VIZIO tvs, and the company got caught tracking users, and selling the data without telling people they were doing it. Or something like that anyway. I still use the weather app but that's about it.

FWIW, I have a ROKU express that is a few years old, and it works pretty well. The one disadvantage, is that if you have a lot of apps on it, there isn't enough built in memory to hold them all. If you access an app that isn't in storage, it has to download the app again. The newer ROKU express has a lot more internal storage, so it's not much of an issue. My ROKU 3 lets you plug in an SD card, so that's never an issue on it. I haven't tried any of the models that support composite.