Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 01/12/21 in all areas

  1. 2 points
    After programming a while for the emulator I'm generally very pleased with how things are working. There are a lot of free ZP addresses, at least when you program in assembly. Typically even a large program really requires only a few ZP words, mostly for indirect addressing. The bank switching works well as is, and it will work even better when moved to ZP. But I have the advantage of not having done bank switching 6502 programs before, so I have no fixed view on how this could or should work. The interface to VERA is logical and easy to work with. I'm especially fond of the auto increment/decrement feature, making it possible to do really fast writes to the memory in VERA. And there's a lot of RAM and ROM, making it possible to do things never imagined on 8 bit computers. I think it really is a dream to program.
  2. 2 points
    I wrote a Z80 scrolling sprite and tile engine for one a few years ago and while it worked fine the quality of the display took a bit of a thumping.
  3. 2 points
    Worked a bit more on my attempt at a file-based assembler. Basic assembler functionality more or less done, it can more or less assemble a raw disassembly now. No labels, symbols or other things yet I also ran it on a 8200 lines long disassembly dump of the Commander X16 ROM region of $c000-$ffff (16 KB) and it took about 12 seconds to assemble that (into memory). Half of that time is spent just loading the source code from disk... and we're not yet writing the result to a new file so that would probably add about six seconds more... adding labels and symbols functionality will require re-reading the source file at least one extra pass so that adds six seconds once again. A disk-to-disk assembler will be pretty slow compared to an in-memory assembler... For now it's still an example that's part of the Prog8 compiler repository so the source is here https://github.com/irmen/prog8/blob/master/examples/cx16/assembler/assem.p8
  4. 2 points

    Version 1.1.0

    22 downloads

    Usage Because of its simplicity the library can be stored in a 1K space below basic programs, starting at $0400. Save the EFFECTS.PRG program in the directory where your BASIC program is stored, which would typically be in the same directory from where you are running the emulator. Load library with LOAD command: LOAD”EFFECTS.PRG”,8,1,$0400 Since this routine after the first run adds a new interrupt handler it is good practice to only load it once. It is therefore recommended to do a simple check: IF PEEK($400)=0 THEN LOAD”EFFECTS.PRG”,8,1,$0400 And that is it. Now you only need to call the needed sound effect from the BASIC program with a simple SYS command. We have four different effects so four different addresses can be called: SYS $400 PING Is designed for events like picking coins or rewards. SYS $403 SHOOT Effect that can be used for shooting the gun or other weapon. SYS $406 ZAP Electricity zapping or perhaps a laser gun sound. SYS $409 EXPLODE Long explosion for when we successfully blow something up Alternative binary named EFFECTSHI.PRG that loads into memory at $9000 can be downloaded. Of course calls are then $9000 for PING, $9003 for SHOOT, $9006 for ZAP and $9009 for EXPLODE. Full source code and walk through is available at my blog: https://www.8bitcoding.com/p/simplest-sound-effects-library-for.html Demo video:
  5. 2 points
    I subscribed. Just doing my part!
  6. 2 points
    Funny.... following your thread, I landed on the wikipedia page. And reading it, I stumble upon this: Sounds like there's a touch of 9918 in VERA
  7. 1 point
    I just feel that the 65C02 is a distinctly poor choice for a multitasking system. But I'm not expecting to write multitasking code. I think it's amply clever just to put certain tasks like file I/O on the non-interrupt code path, while my interrupt code handles other normal frame-by-frame program execution.
  8. 1 point
    Oh, I'm definitely having some tables and optimized multiply routines, the only open question is how many.
  9. 1 point
    There is a set of vectors that various I/O routines use, between the hardware stack at $01xx and the Golden RAM at $0400-$07FF. As I did not previously know of these vectors, I went hunting and found this... I believe that the Commodore 64 vectors are as follows (and Commander X16 seems to be the same): $0314-$0315 788-789 Execution address of interrupt service routine. Default: $EA31. $0316-$0317 790-791 Execution address of BRK service routine. Default: $FE66. $0318-$0319 792-793 Execution address of non-maskable interrupt service routine. Default: $FE47. $031A-$031B 794-795 Execution address of OPEN, routine opening files. Default: $F34A. $031C-$031D 796-797 Execution address of CLOSE, routine closing files. Default: $F291. $031E-$031F 798-799 Execution address of CHKIN, routine defining file as default input. Default: $F20E. $0320-$0321 800-801 Execution address of CHKOUT, routine defining file as default output. Default: $F250. $0322-$0323 802-803 Execution address of CLRCHN, routine initializating input/output. Default: $F333. $0324-$0325 804-805 Execution address of CHRIN, data input routine, except for keyboard and RS232 input. Default: $F157. $0326-$0327 806-807 Execution address of CHROUT, general purpose data output routine. Default: $F1CA. $0328-$0329 808-809 Execution address of STOP, routine checking the status of Stop key indicator, at memory address $0091. Default: $F6ED. $032A-$032B 810-811 Execution address of GETIN, general purpose data input routine. Default: $F13E. $032C-$032D 812-813 Execution address of CLALL, routine initializing input/output and clearing all file assignment tables. Default: $F32F. $032E-$032F 814-815 Unused. Default: $FE66. $0330-$0331 816-817 Execution address of LOAD, routine loading files. Default: $F4A5. $0332-$0333 818-819 Execution address of SAVE, routine saving files. Default: $F5ED. Information taken from https://sta.c64.org/cbm64mem.html
  10. 1 point
    That was more highlighting my preference since, in a pinch, I could just reflash the ROM. Unless it's some crazy part, I already have a ROM burner I used for other projects. In general though, I agree, the expectation should probably be to only enable said jumper during the installation process of a card or a driver upgrade? These seems like rare events, relative to day to day use anyway, to the point that I think it would be a reasonable approach - if one that needed to be well documented. To eb it's just too tantalizing not to use all that available ROM space for something.
  11. 1 point
    This is why I wanted to see a second slot for user ROMs. David explicitly said, at one point, that he does not want to install an In System Programmer for the KERNAL ROM, so if we want to re-flash the KERNAL, we will have to remove the chip, flash it with a programmer, and re-install it.
  12. 1 point
    The internal ROM is writable, with limitations. However you may have the routines you can put on slots, that doesn’t mean the KERNAL knows that they exist or how to use them, and patching the routines is actually easier and cleaner to do again through the SD card. Easier to implement and easier to fix if you screw up. Sent from my iPhone using Tapatalk
  13. 1 point

    Version 0.0.4

    21 downloads

    *** THIS FILE IS ALSO NOW IN THE DEMO SECTION TO ENABLE THE "TRY IT NOW" FEATURE *** This may be of interest to absolute 6502 assembly beginners like me, although advanced 6502 programmers may cringe at the way I've done things here! This program does very little, but it is a repository of useful assembly routines for things like printing different bytes of memory (useful for debugging) as well as some basic math operations. I will keep adding to this as I progress through my assembly journey (I'm aiming to write my fractal BASIC programs in assembly). Thanks to the following YouTubers for their excellent tutorials on all things 6502: Ben Eater - YouTube Matt Heffernan - YouTube ChibiAkumas - YouTube (and also his excellent website: Assembly Tutorials: Learn 6502 Assembly Programming... With ChibiAkumas!) Function usage: (notation for cc65 assembler) jsr print .byte (list of PETSCII character codes to print, ending in a $0 byte) jsr println .byte (list of PETSCII character codes to print, ending in a $0 byte) jsr print_mem .word (start address of memory dump) Set MEMDUMPLEN to the number of addresses you wish print_mem to display.
  14. 1 point
    Beginner 6502 Assembly Stuff View File This may be of interest to absolute 6502 assembly beginners like me, although advanced 6502 programmers may cringe at the way I've done things here! This program does very little, but it is a repository of useful assembly routines for things like printing different bytes of memory (useful for debugging) as well as some basic math operations. I will keep adding to this as I progress through my assembly journey (I'm aiming to write my fractal BASIC programs in assembly). Thanks to the following YouTubers for their excellent tutorials on all things 6502: Ben Eater - YouTube Matt Heffernan - YouTube ChibiAkumas - YouTube (and also his excellent website: Assembly Tutorials: Learn 6502 Assembly Programming... With ChibiAkumas!) Function usage: (notation for cc65 assembler) jsr print .byte (list of PETSCII character codes to print, ending in a $0 byte) jsr println .byte (list of PETSCII character codes to print, ending in a $0 byte) jsr print_mem .word (start address of memory dump) Set MEMDUMPLEN to the number of addresses you wish print_mem to display. Submitter gavinhaslehurst Submitted 01/12/21 Category Demos  
  15. 1 point
    Really impressing work. Maybe you can improve the speed of the file read function. I tried to load a 433 kB file into X16 Edit. That took 26 seconds, i.e. 16 kB/s. Another thing. At the heart of the assembler I/O could be a read_line function. There's nothing wrong letting the assembler using different sources where the line is read from (file, memory). But again. Impressing work in such a short time.
  16. 1 point
    Yeah, I'm not up to assembling a custom keyboard at this point in time. I don't have the space or the patience. I'd buy one if someone made one, though.
  17. 1 point
    In case someone was wondering, this site has a pinout for the keyboard ribbon cable if someone wants to case / keyboard mod their 400 with custom mechanical keys. https://www.40percent.club/2020/12/orthopi.html
  18. 1 point
    Your YouTube tutorials are great Matt! I've always wanted to learn assembly, and this has been a really fun way to get started. I can't wait to run my creations on the real hardware.
  19. 1 point
    The debugger would preferentially halt at particular addresses because of the timing of keyboard polling in the emulator. This happens once per frame, in response to the VERA module deciding to fire its VSync interrupt. This is a mostly arbitrary choice: it's convenient to do this here, as opposed to slowing down the primary CPU/execution loop when the vast, overwhelming majority of checks for keyboard input are going to come back empty anyways. The kernal's interrupt handler, which is what you're seeing, also kicks off in response to the VERA module's VSync interrupt. Since the keyboard polling happens at a regular interval relative to that kernal interrupt handler, pausing execution through the keyboard at any given time is going to cause the debugger to stop at roughly the same execution addresses each time. $038B would likely be part of the kernal's trampoline logic for bank swaps, $E023 is deep in ROM. Edit: I don't happen to know anything about your project, but if you're compiling with cc65, I would definitely recommend specifying `-Ln symbols.sym` in your linker options. This will produce a file name "symbols.sym", which contains a plaintext listing of all the symbols in your project, along with the hexademical address they occur at. With this, you can find a symbol and then set a debug breakpoint at it, so you can stop the debugger exactly where you suspect something is going wrong. For instance, I have an ASM function named "generate_sin_curve", so in my symbols.sym file, I can find the following line: al 003267 .generate_sin_curve From this line, I know I can run the debugger, load my program, then hit F12 and type in "d 3267" and press enter to send the debugger directly to the start of that function. I can press F9 to set a debug breakpoint, then F5 to resume running the emulator. I can then run my program, and the debugger will pause execution immediately before running the instruction at that address.
  20. 1 point
    No, that's a H.P.Lovecraft joke. I did grow up and go to University in Massachusetts, though. Now I'm near Boulder, Colorado, to be nearer the Old Ones hanging out unemployed during COVID19
  21. 1 point
    Now available on Github, version 1.2 of my assembly language editor. This is the native assembler you are looking for. Write your programs directly on the x16, save them, write programs in banked RAM too. https://github.com/edrobotguy/cx16/blob/master/METAL1_2_38_0664.zip This editor is a little different than most - it's an interpreter, in the same way that BASIC is an interpreter, rather than a compiler. That means there's no source code stored anywhere in RAM. The only source code is in VERA as it is being displayed. Your code is interpreted as you type it and stored in machine language and metadata, which is things like labels and comments and so on. The metadata is stored separately from your program. So when you're executing your code, it's the actual code. There's no stepping or breakpoints. This also means that you can load in already-compiled programs and read them - and add your own labels and comments to make it more understandable. I'm thinking of doing precisely that with David Murray's PETDRAW, converting it for the X16. There is also a non-standard program notation: every command has a unique four-character code. The first three are the same as the standard notation, and the fourth character indicates addressing mode. It might irk veteran 6502 programmers, but it doesn't take long to get the hang of it. I put every single "wouldn't it be nice if" that I could think of into this program. Have fun. Edited to add: Here's the video playlist; only two so far but more to come.
  22. 1 point
    Hi, I was hyped about the fact that much of the ZP is actually empty and not used by the system. I found this allways a huge limitation of C64 that actually most of it is occupied by the System and Basic and you could barely find 10 bytes unused. Now in the progress of the project I can see first signs of getting it filled by the system again (now bytes $00-$21 are in use). Of the 126 bytes, that were available before, are now only 93 left. This is not to bad still, but shows a tendancy. Can you please consider to make it a design goal to have as much as free space in the precious ZP? ZP is becoming in the enhanced instruction set of 65c02 even more precious, so I would love to be able to use it. One way to achieve it would be a way to easily save and reload the parts that users might not need (e.g. Basic). Yes I know you can work in a "don't care" mode and simply assume that the user need to reset after using your program. However that is in no way a modern approach and I like to leave a clean environment. So if you run my program from basic, I like to return to basic and find it intact (no hidden time bombs left, because something overwritten). Also calling the basic initialize routing might not be the best, as it also clears the basic memory (overwrites what was in there in terms of sys calls or whatever). What I am asking for is: Either reserve some of the really precious ZP space for us programmers, or create a basic/kernal routine to restore the space without deleting any other part of the ram. Last point of consideration: Of cause If I write into areas used by basic, those data will be gone after calling basic initialize, but the basic ram should not be overwritten. I can then put temporary data into the memory section in questions and that keeps my program intact to get rerun.
×
×
  • Create New...

Important Information

Please review our Terms of Use