Jump to content

rje

Members
  • Content Count

    572
  • Joined

  • Last visited

  • Days Won

    16

rje last won the day on April 8

rje had the most liked content!

Community Reputation

233 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I wonder if, back then, we somehow knew that business was the niche where the personal computer could thrive? All I remember thinking was wishful: I hope IBM abandons the PC market for good. That sort of thing. Totally irrational. And then a few short years later I get a 386SX-16 for college. So much for Commodore. Back then and now, I feel that the TRS-80 Model III has the most professional look of perhaps any computer, with the CBM 8032 a close second.
  2. Bruce, I've been thinking about it, and you've triggered something in my mind that might work. Wikipedia talks about this structural approach to precedence in math expressions. It's in the same section as Pratt parsers: https://en.wikipedia.org/wiki/Operator-precedence_parser#Pratt_parsing Basically, you in-line replace "+" with the equivalent of ")) + ((" and "*" with ") * (" --- or maybe it's the other 'way 'round. Any rate, it's a mechanical substitution method that works very well for being relatively unintelligent. Example code of a simple C application that handles parenthesisation of basic math operators (+, -, *, /, ^, ( and ) I was thinking, I could do that in the TOKENIZER, and then the compiler could be simpler. That's the right place to "rewrite" the input stream. I should be able to isolate that bit into its own little chunk of code. It could be a nice tradeoff.
  3. The precedence parser function looks like this. It uses a parse table that encodes precedence in atoms. static void parsePrecedence(uint8_t precedence) { advance(); // // The prefix rule MUST exist. // if ( parser_previous->type >= TOKEN_START_OF_ERRORS ) // take care of all the error tokens { // (which DO NOT have Pratt entries!) return; // } // if ( prefixRule[parser_previous->type] == NULL ) { error(TOKEN_ERROR_EXPRESSION_EXPECTED); // "expression expected." return; } (prefixRule[parser_previous->type])(); // // If we're at a lower precedence, then advance and call // the infix rule on the previous token, if present. // while(precedence <= precedenceRule[parser_current->type]) { advance(); if ( infixRule[parser_previous->type] ) // might not exist { (infixRule[parser_previous->type])(); } } }
  4. THAT is something for me to keep in mind. Thank you again!
  5. Thanks, Bruce! I think I can keep the expression engine, which I think was in pretty good shape.
  6. Funny coincidence... I was cleaning up some very old hardware for scrap (our city has an official spring cleaning day), and found.... my AWE64 (CT4380, the old "standard" model) card in an old computer case. Maybe $45 on eBay on a good day. Maybe I oughta keep the card, trash the rest.
  7. I like the AWE32 as well, but for the little games I write, I just want the PSG to have ADSR envelopes, and I'd be happy.
  8. You know, Zero, we've got disk commands in the current MIST-modified KERNAL...
  9. Quoted for truth. On my UNIX machine, scripts are used for creating, processing, and reporting on data, usually in files. It's totally overkill on the X16. But, I want to see it; some ideas may present themselves.
  10. No no, I get it. I mean, C is not the 6502's native language, and a bytecode interpreter is heavy by definition. But it will be a personal achievement, and if it works it will be fun, and JUST MAYBE useful. I was talking with a C64/C128 guy who was writing a very low-level symbol table, with hopes of writing something like AWK from it. And that sparked my imagination.
  11. Well of course I do! But: you're right, a lot of things shells do, don't apply here. Actually, much of it is not complex. Tokenizing into Bank 1 is easy. Symbol tables / hashtables are easy. Even a stack-based VM seems easy. The bit *I* find challenging is compiling to bytecode. I think it's a recursive descent parser, with an expression engine, and a bytecode emitter with forward referencing for handling blocks. Or maybe I can use a stack? Building it in pieces is the way to get it done. ... And perhaps also the way to find out what is useful and what isn't.
  12. I'm letting this sit on the backburner, thinking about it, before I rewrite it. I'm starting to become interested in looking at it again, but I have to ask myself what I WANT out of 8shell. The current work was implementing an interpreter using an existing C project designed for modern systems. As a result there are two problems: (1) The codebase, though not extravagant, is really too "big" / requires too much, for the X16. (2) Partly to head off problems with (1), I made decisions that are a bit incompatible with the original. And of course, one change often cascades into many changes. And so I ran out of energy. Now I'm coming back to it and asking what I WANT, and then planning how to get there. SOFTWARE CONSIDERATIONS It's a Shell This means it's a prompt that you interact with. Call it a REPL if you prefer. This means it IS a command interpreter, even if it's a wimpy one. This means scripting scripts... things that let it access the file system and manipulate data sources. AWK and sed and Perl are my guides here. The result won't be as powerful as them, but if I can capture some of that power in a bottle I think we'll have something. It has to be Useful Being able to sed or awk a file and pipe the output to a new file, or concat an existing file, would just be nice, fun, and might be useful. Throwing other little tools in the mix would enrich this capability. One thing at a time, though, I suppose. HARDWARE CONSIDERATIONS 8SH is NOT made for a ROM Bank. 8SH is greater than 16K, and thrives on calls to the KERNAL. THEREFORE it is by definition something that lives in RAM. 8SH SHOULD leverage RAM banks. Tokenizing commands means storing small tokenized scripts, probably in one RAM bank. In other words, the tokenizer will happily churn along until you reach that 8K limit, at which point the interpreter will fail with a "Bank Overflow" command and force you to cut your scripts down in size and chain them or something. Why only one bank? Because that simplifies things. I can make it more complicated later. Similarly, hashtables will be shoved into other RAM banks... and might not even be hashtables.
  13. Welcome Carcuevas! Enjoy the forum, and please feel free to contribute any questions or suggestions.
  14. rje

    Count your RAM banks

    That's right. The X16 only comes with 512K of the banked RAM. It's socketed so it's easy to add more, and (if I recall right) they're less than $10 apiece.
  15. rje

    Count your RAM banks

    Issue logged. https://github.com/commanderx16/x16-rom/issues/199
×
×
  • Create New...

Important Information

Please review our Terms of Use