Jump to content

geek504

Members
  • Content Count

    94
  • Joined

  • Last visited

Posts posted by geek504


  1. 24 minutes ago, Ender said:

    Kernal routines start with "FF" and on the X16 $AB1E would be in RAM

    After some Googling, I found that STROUT is found in BASIC ROM on the C64 ($A000-BFFF). It's part of the BASIC PRINT command that outputs a string.

    Commander X16 BASIC ROM is found at $C000-FFFF in Bank #4. I need to find out the address of X16's STROUT and how to JSR to that address... maybe that FARJSR subroutine?

    Further analysis of X16 BASIC ROM source code, I found the start of STROUT routine in ~\x16-rom-master\basic\code7.s but it doesn't give me an address.


  2. Quick question from you C64'ers... (I'm from Apple-land):

    I found many references to the routines below:

    CHROUT = $FFD2
    STROUT = $AB1E

    But in X16 Programmer's Reference: Commodore 64 API Compatibility

    Quote

     

    $FFD2: BSOUT – write character

    $FFF0: PLOT – read/write cursor position

     

    $FFD2 is given a different name BSOUT... why?

    Why not use STROUT directly? Is it compatible with X16? It uses a different memory address... it's not ROM?

    Is PLOT the routine used to set LOCATE (or HTAB/VTAB)?

    Why did the thread's "Hello World" explicitly print a newline? Couldn't the NEWLINE be added to the string? Do you even need it?

       ; print newline
       lda #NEWLINE
       jsr CHROUT
       rts

    Quote

    $FFCF: BASIN – get character 
    $FFE4: GETIN – get character from keyboard

    Lastly, does BASIC's GET command use BASIN or GETIN? Is there a keyboard strobe that needs to be reset before reading in the character?


  3. On 10/9/2020 at 6:57 PM, geek504 said:

    After checking out most lexers/parsers it seems to me that Lark is the sweetest thing since apple pie!

    So sorry @desertfish for my being severely side-tracked on helping you out with Prog8!

    I just had to explore Lark a little bit... which ended up being a lot... I just wrote an Integer BASIC (aka Woz's Game BASIC) parser using Python and Lark in a single file with only 160 lines (36 lines for the BASIC program and 111 lines for the grammar) and it parses without error Woz's BASIC Breakout game! Beautiful syntax tree automatically generated... dare I go on and actually write the 65C02 assembly compiler for it?

    LOL! I'm so tempted to do it and check the benchmark against Prog8 et al. 😉


  4. 1 hour ago, MontyHall said:

    I have cc65/bin in my path.

    You need other directories defined as well... here's my Windows batch file I run before compiling with cc65:

    Quote

    set CC65_HOME=c:\cc65
    set CA65_INC=c:\cc65\asminc
    set CC65_INC=c:\cc65\include
    set LD65_LIB=c:\cc65\lib
    set LD65_CFG=c:\cc65\cfg
    set LD65_OBJ=c:\cc65\obj
    set PATH=%PATH%;c:\cc65\bin

     


  5. 1 hour ago, MontyHall said:

    What's the performance penalty of using cc65 C over pure assembly?  Have to admit would like to rapid prototype in C w/o the assembly albatross.  Would you say cc65 C is 2x slower?  It certainly can't be worse than basic 2.0.

    Just don't do a printf() version of "Hello, World!" That'll generate a binary of at least 2,000 bytes! Use CHROUT or STROUT instead with assembly or C using a specific X16 library.


  6. On 10/10/2020 at 11:18 PM, SlithyMatt said:

    You can lose that CMP #0 instruction. It's unnecessary. The LDA before already sets the Z bit the exact same way.

    Point noted, just as the stx/ldx SaveX could be replaced by the most efficient phx/plx to save a few bytes more. Sometimes a more verbose code explains better than an efficient code 😉 Efficient code sometimes look like magic!


  7. 45 minutes ago, SlithyMatt said:

    2061 = $080D

    It's simply the start of the machine language program. Before that is just tokenized BASIC and the CPU would choke trying to run that directly, instead of with the BASIC interpreter.

    My hello.asm does a byte by byte commentary on these magic numbers before your assembly code:

    Quote

     

    ;
    ; cl65 -o hello2.prg -t cx16 -C cx16-asm.cfg hello2.asm
    ;
    ; Also, you should count on CHROUT modifying X, so you should flank that jsr with phx and plx.
    ; Run with x16emu.exe -prg hello2.prg -run -scale 2

        .org $0801                  ; Assembled code should start at $0801
                                    ; (where BASIC programs start)
                                    ; The real program starts at $0810 = 2064

                                                     ; 10 SYS 2064
        .byte $0C, $08                    ; $080C - pointer to next line of BASIC code
        .byte $0A, $00                    ; 2-byte line number ($000A = 10)
        .byte $9E                             ; SYS BASIC token
        .byte $20                             ; [space]
        .byte $32, $30, $36, $34   ; $32="2",$30="0",$36="6",$34="4"
        .byte $00                             ; End of Line
        .byte $00, $00                     ; This is address $080C containing
                                                      ; 2-byte pointer to next line of BASIC code
                                                      ; ($0000 = end of program)
        .byte $00, $00                     ; Padding so code starts at $0810

        CHROUT = $FFD2

        ldx #0
    again:
        lda hello, x
        cmp #0
        beq done
        stx SaveX
        jsr CHROUT
        ldx SaveX
        inx
        jmp again
    done:
        rts
    SaveX: .byte 0
    hello:
        .byte   "hello world! ", $00

     

    Enjoy!

    • Like 1

  8. 22 hours ago, desertfish said:

    I don't have a  preference for one or the other simply due to the fact that I am not knowledgeable enough about parser generators to know the differences 🙂

    How would Prog8's grammar look like in a LALR 1 definition?   (as compared to the current prog8.g4 spec)   Why would it be preferable?

    I've chosen Antlr because that looked to be a high performance, well supported, and broadly used parser generator for Java (and thus, Kotlin).  I'm open for alternative better solutions though.   The parser is in its own project, so you could make another one next to it. The biggest effort would be the mapping into the Ast nodes that the rest of the compiler uses. And perhaps dealing with parser errors.

    LR produces a much more complex state-machine for the parser but is easier to write grammars because we don't have to worry about left recursion and left factoring. LR is also a faster parser than LL but if you were to write the parser yourself, LL parser is preferable and much easier to write, but who does that nowadays?

    While there are a few LR parsers for Java, I could not find something specifically for Kotlin, and I didn't spend too much time trying to figure out the Java/Kotlin integration. SINCE your grammar is already done I wouldn't change it and ANTLR is a fine product.

    Quote

     

    LL or LR?
    This question has already been answered much better by someone else, so I'm just quoting his news message in full here:

    I hope this doesn't start a war...

    First - - Frank, if you see this, don't shoot me.  (My boss is Frank DeRemer, the creator of LALR parsing...)

    (I borrowed this summary from Fischer&LeBlanc's "Crafting a Compiler")

      Simplicity    - - LL
      Generality    - - LALR
      Actions       - - LL
      Error repair  - - LL
      Table sizes   - - LL
      Parsing speed - - comparable (me: and tool-dependent)

    Simplicity - - LL wins
    ==========
    The workings of an LL parser are much simpler.  And, if you have to
    debug a parser, looking at a recursive-descent parser (a common way to
    program an LL parser) is much simpler than the tables of a LALR parser.

    Generality - - LALR wins
    ==========
    For ease of specification, LALR wins hands down.  The big
    difference here between LL and (LA)LR is that in an LL grammar you must
    left-factor rules and remove left recursion.

    Left factoring is necessary because LL parsing requires selecting an
    alternative based on a fixed number of input tokens.

    Left recursion is problematic because a lookahead token of a rule is
    always in the lookahead token on that same rule.  (Everything in set A
    is in set A...)  This causes the rule to recurse forever and ever and
    ever and ever...

    To see ways to convert LALR grammars to LL grammars, take a look at my
    page on it:
      http://www.jguru.com/thetick/articles/lalrtoll.html

    Many languages already have LALR grammars available, so you'd have to
    translate.  If the language _doesn't_ have a grammar available, then I'd
    say it's not really any harder to write a LL grammar from scratch.  (You
    just have to be in the right "LL" mindset, which usually involves
    watching 8 hours of Dr. Who before writing the grammar...  I actually
    prefer LL if you didn't know...)


    Actions - - LL wins
    =======
    In an LL parser you can place actions anywhere you want without
    introducing a conflict

    Error repair - - LL wins
    ============
    LL parsers have much better context information (they are top-down
    parsers) and therefore can help much more in repairing an error, not to
    mention reporting errors.

    Table sizes - - LL
    ===========
    Assuming you write a table-driven LL parser, its tables are nearly half
    the size.  (To be fair, there are ways to optimize LALR tables to make
    them smaller, so I think this one washes...)

    Parsing speed - comparable (me: and tool-dependent)

    --Scott Stanchfield in article <33C1BDB9.FC6D86D3@scruz.net> on comp.lang.java.softwaretools Mon, 07 Jul 1997.

     

    Here are two BASIC grammars to compare, "jvm" is from ANTLR's repository.

    c64_basic_bnf.txt jvmBasic.g4

    • Thanks 1

  9. Is it just me or am I alone in having this great aversion to LL grammar, and thus an aversion to using ANTLR?

    LALR(1) just makes sense to me and is so elegant especially when using EBNF notation.

    After checking out most lexers/parsers it seems to me that Lark is the sweetest thing since apple pie!

    But I am still convinced to learn Kotlin 😀


  10. 12 minutes ago, JimmyDansbo said:

    I would also like to know if it is possible to run the emu without sound enabled? At the moment I install the alsa-dummy module to get the emulator to run in a VM without sound hardware.

    I got the alsa-dummy module loaded and alsamixer shows it as an option... but I can't seem to get

    Quote

    ./x16 -sound <OPTION>

    option to work... it just outputs a list of sound options but I can't choose "Dummy".


  11. I am temporarily running development in a Linux box using Debian 10 (Buster). The Linux download file for X16 r38 is dynamically linked to libc 2.29 while Buster has 2.28 and no view in sight for a future libc update. I also do not want to venture into the messy multiple libcs franken-debians. Perhaps the developers could statically compile the binary? Note: Ubuntu seems to have 2.29 but not Debian yet.

    I'm going to compile my own BUT perhaps for future Linux users it would help.

    Is there a way to run x16 without sound? I don't need sound right now and it complains that it needs ALSA etc.


  12. How cool would it be to somehow get the great Woz aware of this project? Maybe even perhaps get some insights and ideas...

    ... or even better, get the 8-Bit Guy to invite Woz to his YouTube show!

    • Like 4

  13. On 9/30/2020 at 11:07 AM, desertfish said:

    Perhaps - but don't forget that commanderX16 support only arrived a few weeks ago and this project is much much older 🙂

    Forgot about this detail!

    It might take a while to start digging inside Prog8's source code... I'm getting familiarized with Kotlin and ANTLR while fooling around with IntelliJ IDEA... all new tech to me! Being a hacker at heart, I just *have* to write a small interactive calculator using Kotlin and ANTLR to test my newfound knowledge!

    Edit: I am seriously consierding ditching Python and C# for Kotlin. It'll be just C, Kotlin, and Assembly (6502, 68000, x86, and ARM) for me!

    PROS: JVM, Java libraries, clean code like C# (a tad cleaner than Python),  I prefer { } instead of indentations, statically typed, Android, better job opportunity in the JAVA field?

    CONS: JVM (who wants to be dependent on Oracle?), not well integrated with other technology, i.e. less mature, Kotlin/Native still being developed (iOS!)


  14. 7 hours ago, desertfish said:

    Maybe start with familiarizing yourself with the classes that make up the AST (see the ast folder)

    I think I'll start with the grammar file... just gotta find it.

    7 hours ago, desertfish said:

    Kotlin + IntelliJ IDEA

    I hope it's emacs-friendly (they do have a Kotlin major-mode available). Edit: It is...

    wsl-emacs-kotlin.PNG.e3d2b5245e1269f2eb63dc1341288ddf.PNG

    7 hours ago, desertfish said:

    About the 16 pseudo registers:  Well, they're not (yet) first class citizens in the Prog8 language. However, because Prog8 allows you to define memory-mapped variables they're pretty close to what I wanted anyway.

    I was thinking of using them as "use-once and throw away", i.e. used as a mechanism to transfer paramenters to functions, and once in the function routine, the function copies the value into its local static memory reserved for these paramenters. In this manner, the calling program does not need to know the address of the static memory of the paramenters of any function (but needs to know how many parameters and of which type). Passing objects is also possible if used to pass a pointer to the object. Does Prog8 support pointers? 

    7 hours ago, desertfish said:

    but to support that would require quite hefty changes to the parser and those changes don't really blend well I think with the original language as it should work for the C64

    Supporting both the C64 and X16 was a negative point for me. It adds more complexity than is needed especially since they have different design. If we focused just on X16 (or make a fork) things would progress much faster. Trust me, when the X16 comes out, I will never ever touch a C64 again!


  15. On 8/27/2020 at 4:30 PM, desertfish said:

    One improvement I'm already thinking of, is perhaps making the set of 16-bit pseudo registers part of the language so you don't have to access them anymore as zeropage variables.

    That is a great idea and one of the things that should be used and abused!

    On 8/31/2020 at 5:52 PM, desertfish said:

    It would be cool if people would use Prog8 for larger projects, but other than the few dozen example programs I've not actually written a large piece of software in Prog8 yet 😄    Mostly because I'm still too busy tinkering with the compiler itself and fixing bugs, and now, CommanderX16 support for it.

    I have been thinking about NOT starting yet another 6502 BASIC compiler but instead HELP out with Prog8! Gives me a reason to learn yet another programming language (actually two... Kotlin and Prog8). After Googling Kotlin I read that it drastically reduces boilerplate code which was the big reason why I kept Java away from me with a ten-foot pole! I hope to be able to sift through your code without getting bamboozled...

    • Thanks 1

  16. 7 hours ago, desertfish said:

    Prog8 *is* created by me, I'm working on the compiler while trying to create some interesting programs with it at the same time.

    That explains the lack of information on the Net! I had first assumed that you created this language which led me to decide to write a compiler based on a true and tested BASIC dialect. I wouldn't need to re-invent anything, just code away the implementations. Analyzing Prog8 I can see how it is a blend of many different ideas so implementing it wouldn't present much problems... but still involve some thinking!

    Feel free to add simple Prog8 source along with the generated assembly code in your Prog8 thread... I love analyzing compiled code and see how efficient or how to improve efficiency!

    • Like 1

  17. 50 minutes ago, desertfish said:

    Sounds similar to what I am doing with Prog8 🙂

    Yea, it occurred to me too! Honestly I have never heard of Prog8 and actually I thought it was invented by you! Couldn't find much on Google... anyways I know BASIC quite well and the grammar is already done for C64 BASIC V2. I am also old-school UNIX programmer so I am much more comfortable with Flex/Bison (lex/yacc) and C. I also don't feel like patching up cc65.

    We can definitely exchange ideas!


  18. 20 minutes ago, desertfish said:

    What do you prefer instead?

    Doesn't exist yet... since I don't expect the compiler to be compliant to C-standards, I am thinking about writing my own (yet another) BASIC compiler akin to BASIC Boss but with more improvements. The only difference is that this one will be custom-made for the X16 and its improvements. I'll borrow many ideas from Woz's Integer BASIC, add HTAB/VTAB (or LOCATE) et al. With a BASIC compiler I won't need to bother the X16 devs for C64 BASIC improvements.


  19. 5 minutes ago, Jestin said:

    I use vim, so am obviously deeply offended by the mention of emacs here

    I use vim too... I don't discriminate 😀 I use nano and pico to edit unix config files when I'm too lazy to install vim. I reserve emacs for *real* development 😆

    All I need now is a console-based X16/6502 debugger... I am seriously considering converting my Apple ][ text-only emulator into such debugger... xdb

    • Like 1

  20. 13 hours ago, SerErris said:

    But if you want to use Windows then WSL is just something to enable you to run Linux - which was not the idea in the first place.

    After fiddling around with Atom and VSCode I reverted back to my trusty old emacs (both Windows and Linux). I did not like installing Cygwin nor Mingw so I installed Debian WSL and got my nice bash with all the useful tools. cc65 is a nice debian package and I can run the X16 emulator from my Windows installation just fine. I use Makefile from within emacs and version control with the old diff & patch tools. Slim and quick.

    I also came to an epiphany... I don't actually like cc65 due to its C-stack implementation. It causes inefficient code.


  21. On 9/21/2020 at 1:55 AM, SlithyMatt said:

    It's pretty dead simple, and pretty much how I have shown it in my videos.

    Err... what videos?

    My config.cson didn't need the use of * file-types as per the instruction of the * language-65asm package:

    Quote

    "*":
      core:
        telemetryConsent: "no"
        uriHandlerRegistration: "always"
      "exception-reporting":
        customFileTypes:
          "source.assembly.6502.cc65": [
            "asm"
            "inc"
          ]

    Also you mentioned:

    Quote

    I am running Linux, so the build environment is within the Bash shell and my projects use Bash build scripts, GNU makefiles, or both. I simply call all of these from a terminal window, usually with multiple tabs so that I can switch between different working directories and have separate histories where I do the same few commands over and over again.

    In that case, Atom might as well be Emacs with syntax highligting...  

    emacs-cc65.thumb.PNG.553e97e6425f371142ca50c960385b56.PNG


  22. On 9/19/2020 at 11:20 AM, SerErris said:

    I am looking into that option now but have issues to get it to work.

    I have cc65 running, I have Visual Studio Code and I use "cc65 for 6502/65816 machines" by SharpNinja as an expansion. However I cannot get VS Code to build anything. It never understands that it shall use cc65. Instead it asks me to tell VS Code what compiler to use.

    Is there anything I need to configure in the workspace for it to work?

    Yeah, I am having problems getting SharpNinja extension to work smoothly if at all... it's really old. I am now trying to setup Atom like Matt says below:

    On 9/10/2020 at 2:48 PM, SlithyMatt said:

    I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.

    So I revert to Matt and ask... what's your setup like? Config files, workspace, hotkeys, build process, etc.

×
×
  • Create New...

Important Information

Please review our Terms of Use