Jump to content

Scott Robison

Members
  • Posts

    740
  • Joined

  • Last visited

  • Days Won

    32

Everything posted by Scott Robison

  1. I've not watched the video yet, so maybe you already have or already plan to, but a discussion of the differences between the 8080 & the Z80 would be interesting as part of the videos. Then of course is the opportunity to leverage both 6502 & Z80 in on the C=128.
  2. I wish I'd seen that 24 hours earlier after stumbling through most of those steps myself to start work on my interpreter!
  3. I think I've done all I'm going to do with BASIC PREPROCESSOR with the update just posted. It's not the prettiest or more friendly tool ever, but it works. I uploaded another sample that generates Armstrong numbers just as an illustration of labels and "long" variable names. If you're curious: An Armstrong number is a number such that the sum of the digits raised to the power of the number of digits is the original number. For example: 123 is not an Armstrong number because 1^3 + 2^3 + 3^3 = 36, and 36 is not equal to 123, the original number. 153 is an Armstrong number because 1^3 + 5^3 + 3^3 = 153, and 153 is equal to 153, the original number. They are not useful, just interesting and a bit of a "hobby" of mine since I was first introduced to them in college. Finding efficient ways to test all possible numbers for Armstrongness is an interesting exercise in algorithmic analysis, especially when you consider that Armstrong numbers can be up to about 60 digits long (theoretically, in base 10).
  4. And if they wanted it pronounced garaje, or jiraffe, or ...
  5. Pronunciation is definitely going to vary depending on one's native language. I recall a tagline I used to see regularly on BBS message boards and relay networks: "Choosy perverts choose GIF" (which works because of a series of commercials in the US [at least] that used the tagline "Choosy Moms Choose Jif", which they completely botched recently in a promotion with giphy). It's interesting (not surprising) that we were so fond of GIF files at the time as being such high quality when there are so much better solutions available today. Progress marches on.
  6. That's how I used to feel when people would refer to ROM game console cartridges as tapes.
  7. And I agree in large part with that. Conveyance of the idea is more important than the pronunciation. We try to pronounce the names of people correctly, and regardless of my thoughts on it, there is a movement to allow people to select their preferred pronouns. Thus I think that it is worth trying to get proper nouns right and go with the preference of the person who defined the name when possible. I also try not to get too worked up about it when I hear someone get it wrong unless I think they are doing it deliberately as a sign of disrespect (in which case I'm not talking about the name of an inanimate object, I mean their preferred pronunciation of their name or preference of pronoun). My youngest child is biologically male, but identifies female and prefers she/her. I often don't get it right, but I don't get it wrong because I want to hurt feelings, I get it wrong because this child was my male offspring for 20 years before a choice was made. I think the intent is a huge consideration. My own name (Robison) does not have an N in the middle. My family pronounces it "RAH-bi-sen". Most people it seems pronounce it as "ROW-bi-sen" if they notice the missing N, or "RAH-bin-sen" if their mind fills in the missing letter because they see what they expected. Pronunciation can be hard, especially in a language such as English with many exceptions to rules because of how much vocabulary we steal from other languages and other various reasons.
  8. That is a better argument than the "garage" example I so often hear used. It makes at least as much sense as "Bill" being a diminutive form of "William". I've read that the rules of pronunciation are much more varied when it comes to proper nouns. One can declare that the name "Bob" should be pronounced as "Sue" (though I will definitely look at them funny). Ultimately: https://www.newtimes.co.rw/children-education/master-sound-when-g-pronounced-j-or-g
  9. When I hear a "discussion" about the pronunciation of GIF, someone almost always tries to compare it to "garage" as though that is the only sound G can make. As though people go around pronouncing "giraffe" as "grr-aff". It brings to mind a second season episode of Star Trek The Next Generation, when Dr Pulaski addresses "Data" with the pronunciation "dah-ta". When he corrects her, she asks "what's the difference" to which he replies "one is my name; the other is not".
  10. Exactly. 80 is a good limit for this type of editor especially. Create them as pascal-style of strings where each line has a length byte followed by a fixed maximum length then it is "easy" to "draw" the string without actually having to use an actual BASIC string type.
  11. My limited experience with it so far agrees with you that SEQ doesn't seem to be a thing yet, and that's using the bleeding edge github source. My thought had been to use the RAM banks for text. For simplicity, probably to divide them into maximum line lengths that I would support and avoid strings. I fear garbage collection in this version of BASIC if most characters wind up destroying and creating multiple strings in the heap. If I was going to use actual BASIC strings though, I think I would use one array element per line, not per word.
  12. I think it was Scott's dev tool. Our last names are similar.
  13. God bless you for knowing how to properly pronounce GIF.
  14. You and I are kindred spirits, because I was thinking of a pseudo vi-inspired editor. I'm not a fan of vi, really, so I'm not sure, but it was my thought. I was thinking to use back arrow or british pound for the esc character if I went that route. And I do enjoy the punny name. It's not so punny that I have to groan, and it is cutesy.
  15. There might be some terminals or systems that render ASCII or 8859-15 control codes, but technically by the standard they have no visible representation. $00-$1F and $7F-$BF in ASCII are not printable in that context. Even though many of them aren't valid C source characters, for example, people will often include them anyway because compilers will not complain (it is either undefined or implementation defined behavior, I can't remember which off the top of my head. That's not to be confused with the screen codes, which are distinct from the XSCII encoding.
  16. As it turned out, that was a lazy hack on my part that wound up being useful. Since a label may be defined on a line by itself (or not) there needs to be a line number to associate with the label, as I don't really know at the time of parsing what the next generated line number would be. So rather than making the system more complex, I just had it generate a REM so that I could target the line.
  17. Perhaps. It's my own brand of OCD feeling like the first character defines the type of the "name" (definition or expansion). I was thinking about possibly other ones as well, this is just as far as I got when I decided to share it. "+" to add to symbol table, "-" to look up in symbol table. Maybe "!" to declare a long variable name that can be mapped to a short two character name. It's very much a thought exercise seeing just how far I can get with pure BASIC, which I already violated to call the crunch routine in ML.
  18. That is also another way it could be done. I was looking for a "self delimiting character" so I didn't want to use brackets, though I agree they are more readable. My scanning code is so simple and it trusts that @ is matched with @, " is matched with ", and that anything between the open and close character is part of the label. I could use apostrophe instead of @ as a "more readable self delimiting character".
  19. History. Mechanical printers / teletype / whatever often required a CR to return the carriage (the print head did not move necessarily, but the paper like in a ancient typewriter), then a LF to scroll the paper one more line. Windows does it because DOS did it. DOS did it because CP/M did it. CP/M wasn't about translating control codes from an abstract set of commands to a device specific set of commands, which is why many printers in the day had jumpers that you could set to customize how it would respond to things like ESC sequences and CR & LF & etc. I actually still use stand alone CR frequently when writing console mode / terminal mode programs to continuously update the same line with updated status information in a long running process.
  20. Given that the platform is embracing more characters than the 8-bits of old, I think the right "text file source code EOL standard" should be "one or more characters in the set CR or LF". So it could handle plain old 8-bit CR terminated lines, Unix-y LF terminated lines, and DOS/Windows CRLF lines. Then tokenizers / parsers could easily skip blank lines as meaningless (unless of course someone decided that a blank link should be a syntactic construct, in which case they'd want to be more judicious). As for ASCII vs PETSCII, it would be nice if there was some sort of a BOM character like exists for Unicode that could be used as the first character in a file to identify the encoding. For those who do not know (I'm not trying to talk down to anyone, we just all approach this with different backgrounds), original Unicode was a strictly two byte per character encoding. There was no UTF-8. The problem presents itself: Are my characters in little endian or big endian order? U+FEFF was defined as a "Zero Width No-Break Space" character which means it is just white space, so easily ignored by most language processing software. U+FFFE (the reversed form of U+FEFF) was defined at some point as "noncharacter" that should not appear in unicode text. So U+FEFF became the simple way to determine which character encoding was in use. With PETSCII vs ASCII, we don't have the byte ordering issue, but sniffing the encoding would still be useful. According to https://www.pagetable.com/c64ref/charset/ we have several flavors of SPACE in PETSCII: $20: Normal Space Character (SP in either ASCII or PETSCII) $A0: No-Break Space (NBSP in either IEC-8859-15 or PETSCII, the two native encodings on x16) $E0: No-Break Space (NBSP in PETSCII but a-grave in 8859-15) None of those are particularly useful for differentiating between ASCII vs PETSCII. Another solution is what many editors support, which is to include a magic comment as the first line of source code that encodes metadata about the file. I think this is our best bet. In BASIC source code like my BPP.BAS file, I could include a first line like: REM ENC=PETSCII EOL=CR To signal the compiler that my file is in PETSCII encoding and uses CRLF as the end of line marker. In C one might create a line like: /* ENC=8859-15 EOL=LF */ In ASM code maybe: ; ENC=ASCII EOL=CRLF And so on. I would suggest that the "de facto" standard for x16 source: 1. Looks at the beginning sequence of characters up to the first CR or LF character. 2. The characters should be unshifted alphabetic characters so that uppercase ASCII and uppercase PETSCII (in graphics charset) map to the same set of character codes $41 - $5A. If in mixedcase PETSCII, it would be lowercase letters. 3. Valid encodings that should be recognized by all x16 compatible software should be ENC=PETSCII, ENC=ASCII, ENC=8859-15. 4. Valid end-of-line types that should be recognized by all x16 compatible software should be EOL=CR, EOL=LF, EOL=CRLF. 5. The valid character set of these NAME=VALUE pairs should be limited to alphabet (codes $41-$5A), digits, equal sign and hyphen with spaces appearing before and after each. 6. This allows for easy extension to include new attributes we might not consider now that would be generally useful, or for individual software to define their own custom NAME=VALUE pairs for their own use. This is just stream of consciousness ideas that does not obligate anyone to define a rigidly enforced standard. But it could be useful.
  21. I agree that a standard would be good. If you download my plain text BPP.BAS file and look at it, you'll see it is "ASCII/PETSCII" compatible with the one exception that it does use CRLF line endings because I edited it on Windows. My solution to that problem, because line ending wasn't a huge consideration for me, is that I consider CR *or* LF to be a line ending character. So when preprocessing BASIC text that originated on Windows, I wind up with line numbers 0, 2, 4, 6, etc. Had I used just one or the other, I should have used each line number (0, 1, 2, 3, etc). Except for empty lines, which I do not emit. Because I've not tested it extensively, I am not sure what it would do with some corner cases such as "non empty line that only has space characters in it". I think, because of the way I leverage the BASIC crunch routine to tokenize the line, it might skip that, but it wasn't important to my proof of concept so I didn't dig deeper, esp since the program is dependent on the bleeding edge github, I think.
  22. I was a TA for a FORTRAN class circa 1988, back when FORTRAN 77 was still the standard. I think the hardest thing about FORTRAN would be the type system. It is build around the idea of numerical computing and has a lot of operators and types to support various precisions of integer, real, and complex numbers. FORTRAN 77 didn't support recursion, so that would be a plus for the 6502, but I think that's about the only real win that it would have. But I'm 30+ years out of experience with old FORTRAN and no experience with FORTRAN 90 or newer. BASIC was inspired by FORTRAN, so it isn't that it couldn't be done, I just don't see anyone wanting to write the types of programs that you would want to use FORTRAN for on a 6502. But someone might!
  23. Assembly is what it is because every CPU has it's own vendor defined syntax, and then different people create assemblers that create variations on that syntax for different reasons. Assembly (and by extension machine language) is as non-standard as things get. C is often used these days as portable assembly language, because it is in theory "standardized". The hard part of C is that it has a difficult syntax with some unintuitive operator precedence to people coming from other languages. int * a, b; // looks like you are creating two integer pointers, but really you are creating one pointer (*a) and one plain integer (b) I prefer to write these declarations as "int* a" instead of "int *a". The latter is what is really happening, but the former reads better to me. Until you try to declare two in one line. I'm just used to reading declarations like these from right to left: "a is a pointer to an integer". Or to get even more complicated: "const char* const p" is "p is a constant immutable pointer to a character that is itself constant / immutable". Most people who use C use postfix increment and decrement operators (i++ or i--) because that's what they learned. I prefer ++i and --i. The argument can be made that the prefix form is potentially more efficient. But the bigger win in my mind is that it reads more naturally: "i++" reads "i increment" whereas "++i" reads "increment i". The latter makes a lot more sense to my native English speaking mind, though I'm sure there are other languages where the reverse might be true. There are times where you need the postfix, and that's fine, but when either will suffice, I choose it to read most naturally to me. There is no reason why one cannot have a close to the metal language that can be portable like C that has a more intuitive syntax than C. I like C++ and use it primarily in my day job, but it has the same issue dialed up to 11 in some ways.I've been thinking lately about defining a "portable assembly language" or "pseudo assembly language" that trades all the TLA in 6502 assembly for operators.
  24. Obviously there are better ways to do this, but back when I had my C=64, I didn't have the benefit of an extra computer on which to do dev work. I'm already cheating a little bit there as I admit above using an external text editor, but I could have created the text file without it, so I'm allowing it. Text editing is the only external task I'm allowing myself thus far. So my first substantive program is BASIC PREPROCESSOR. It is pure basic plus one ML routine, which I did completely with the MONITOR in the emulator then copied the bytes to DATA statements. My second program will be BASIC EDIT. Not a competitor to x16 edit, but something very simple that can edit small text files. I will write it in BASIC PREPROCESSOR syntax so it will serve as the first "big" example of BASIC PREPROCESSOR. My intent is to write the smallest possible editor I can that allows me to add text, remove text, save files, and load files. Once I have that done I will try to do all my dev "natively" in the emulator (which is a contradiction in terms, but it is hopefully clear enough in context). I do this not because it is the "best way" ... just because if I'm going to go retro, let's go retro!
  25. It should, though I've honestly not tried it yet. Just the simplest stuff. Let me check! {time passes} Yes! The program works by looking for @ symbols. Just as a normal string is delimited with quotation marks, labels are delimited with @ symbols in my preprocessor. So when it encounters a label outside a string, it replaces it with the line number (or something approximating the line number). As for how to enter a BPP file, yes, you'd need a text editor like x16 edit or some such. This is the one place I cheated. x16 edit isn't working for me (I suspect because I'm running bleeding edge emulator I built after cloning github). So I used a text editor on my Windows machine, saved it into a sdcard image, and then ran it from there. So this is not ready for primetime probably if one wants to use it in r38. It is just barely ready if you are using bleeding edge emulator. Or at least it is for me.
×
×
  • Create New...

Important Information

Please review our Terms of Use