Jump to content

JamesD

Members
  • Content Count

    8,545
  • Joined

  • Last visited

  • Days Won

    6

JamesD last won the day on December 16 2010

JamesD had the most liked content!

Community Reputation

2,118 Excellent

About JamesD

  • Rank
    Quadrunner

Profile Information

  • Gender
    Male
  • Location
    Flyover State
  • Interests
    Bit Twiddling, Motorcycles

Recent Profile Visitors

29,925 profile views
  1. JamesD

    PC Game Deals

    https://www.pcgamer.com/the-original-borderlands-is-free-on-steam-for-the-weekend/
  2. BTW, if you didn't see the original post, maybe you blocked me?
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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
  11. The scrolling was done in assembly... but it shows what you can do with BASIC.
  12. JamesD

    PC Game Deals

    Payday2 $4.32 https://www.fanatical.com/en/game/payday-2-ultimate-edition
  13. 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.
  14. THEN and ELSE would have to deal with the same issues as GOTO and GOSUB. Forgot those. RUN linenumber is also a special case
  15. 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.
×
×
  • Create New...