Jump to content

Stefan

Members
  • Posts

    251
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Stefan

  1. Considering what Lorin said above in this thread I will probably remove my PR for a START command. I now have a much simpler implementation for a FARSYS command. Example: FARSYS $C000,7 will jump to address $C000 in ROM bank 7. It seems to work, but I will look at the code a bit more before pushing that. Even if flashing the ROM will be somewhat complicated/risky, it's reasonable to believe quite a few will try that anyway. The FARSYS command would be useful for those. Do you think the name of the command should be shortened to FAR?
  2. If it's going to be complicated and/or risky to add programs to the ROM, that of coarse reduces the interest in a START or FARSYS command. I haven't thought a lot about what programs you would typically want to store in ROM. I guess it's mostly utility programs that you use in parallel to other programs loaded from the SD card.
  3. Great news, @Lorin Millsap! If it's becoming practical for end users to add custom programs to the ROM, it would also be very practical if there was a BASIC command to start such programs. Otherwise the user would need to enter a startup stub in the Monitor or load a startup program from the SD card, which sort of takes away the meaning of ROM based programs. A couple of weeks ago, I made a draft PR that implements a START command: https://github.com/commanderx16/x16-rom/pull/208 It's based on the discussion on a standard ROM format here: https://www.commanderx16.com/forum/index.php?/topic/956-signature-for-rom-based-programs/ The command makes it possible to enter for instance: START "MYAPP" The command searches through the ROM banks, and if found, starts the program. Even though the PR code works as advertised, it's a bit rough. Therefore the draft state.
  4. The FAQ says this about the ROM: "TBD: May be able to be flashed from the X16". I think this would be very usable, as not everyone has got an EEPROM programmer. And some may not be comfortable pulling out the ROM IC. Has anyone seen more on this subject? I have never built anything that writes to an EEPROM. As far as I understand, you would typically need to control three ROM lines (apart from address and data): Chip Enable Output Enable Write Enable Is it reasonable to believe that these lines would be connected to one of the VIAs, if it's decided to include this feature?
  5. I found a bug in the backup/restore function affecting the backup of the start of golden RAM. Fixed in release 0.3.6 just published. Still an R38 release.
  6. Let me know if there are problems and I will try to sort it.
  7. Yes, it's supposed to restore the zero page it uses as well. It's done by copying the following memory ranges to banked RAM: Zero page: $22-$34 Golden RAM: $0400-$07FF
  8. Version 1.0.0

    30 downloads

    This is a template for ROM based assembly programs that you are free to use or continue upon. It's made for the CA65 assembler. Usage: Create your program code as normal. Of coarse, you need to place all variables in RAM and avoid any self modifying code. Include the file kernal.inc. This will: Create jump vectors for all "public" KERNAL function, and Set the IRQ vector in $fffe-ffff, so that the KERNAL interrupt handler is called. The file example.s is a small hello world test. The project is built with build.sh. The file example.cfg contains the memory segment settings needed by the assembler/linker. The source code is also available on Github: https://github.com/stefan-b-jakobsson/x16-romtemplate
  9. ROM template View File This is a template for ROM based assembly programs that you are free to use or continue upon. It's made for the CA65 assembler. Usage: Create your program code as normal. Of coarse, you need to place all variables in RAM and avoid any self modifying code. Include the file kernal.inc. This will: Create jump vectors for all "public" KERNAL function, and Set the IRQ vector in $fffe-ffff, so that the KERNAL interrupt handler is called. The file example.s is a small hello world test. The project is built with build.sh. The file example.cfg contains the memory segment settings needed by the assembler/linker. The source code is also available on Github: https://github.com/stefan-b-jakobsson/x16-romtemplate Submitter Stefan Submitted 04/26/21 Category Dev Tools  
  10. I understand. That I cannot help you with. The only viable option for you might be to let the assembler stay in RAM and use the ROM based editor. You could make a function in the assembler to start the editor to make that a bit easier. At least until there is a better solution for starting user-added ROM based programs in the Kernal. If your assembler is using parts of banked RAM or the golden RAM, that should not be a problem. On startup you may set what parts of banked RAM the editor may use. And on startup the editor takes a snapshot of golden RAM and restores it on exit. This functionality has not been thoroughly tested. But hopefully it's working.
  11. I did some more work on the ROM image template, and created a Github repo. I also found a simplified way of creating links to the standard Kernal functions. Enough said. You may read the code https://github.com/stefan-b-jakobsson/x16-romtemplate
  12. Not much to remember about Tilburg, I'm afraid It's not very easy, but I wouldn't say it's very hard either to make a program romable. Some pointers: The ROM image must fill a whole ROM bank. That is 16,384 bytes. No more, no less. In order for the computer not to crash, $fffe-ffff in your ROM bank must point to an interrupt handler in RAM. The KERNAL handler is located at $038b, called "banked_irq" in the KERNAL source code. You can let $fffe-ffff point to this. You need a way to call KERNAL functions in ROM bank 0 You cannot call a KERNAL function directly from another ROM bank. There has to be bridge code in RAM. This is so because if your ROM code tried to directly switch ROM bank and call code in another ROM bank, as soon as the ROM bank is switched code execution continues at the same address but in the new ROM bank. And your ROM code looses control. One solution is to include the KERNAL source "inc/jsrfar.inc". It uses a small code stub stored in RAM called jsrfar3, located at $02c4 Then your ROM code should be able to call functions in other ROM banks with jsrfar in the normal way Finally, if you need or want to call KERNAL functions at their normal addresses, like $ffd2 for outputting a character, you need to implement this yourself in the ROM bank First you would have a "list" of jumps situated at the desired place near the end of the ROM bank, like $ffd2 This would jump to a function in your ROM code that does the jsrfar. I don't know if I'm very good at explaining this. I think it's easier than what it sounds. If you're interested I could make a small example implementation. EDIT: Attached is a minimal working ROM, only supporting call to $FFD2 banks.inc and jsrfar.inc are copied from the KERNAL project test.s is the ROM image source code test.cfg is memory configuration for CA65 assembler build.sh is a build script banks.inc build.sh jsrfar.inc test.cfg test.s You need to append the ROM image to the default ROM image you got with the emulator (file name rom.bin). On Linux/MacOS you could type: cat rom.bin test.bin > customrom.bin When starting the emulator you need to specify the custom rom with the -rom switch. To start the ROM code you need to enter startup code in RAM, for instance in the monitor like this: lda $01 pha lda #$07 sta $01 jsr $c000 pla sta $01 rts
  13. One option is to store the assembler and the editor in ROM. Or at least one of them. X16 Edit already supports this. I've made a PR in the KERNAL project so we would have a BASIC command to start ROM based programs. I call this command START, and you would type for instance START "ASSEM". That would make it easy to start and switch between programs stored in ROM. But I don't yet know if there is any interest. And I don't know how easy it will be for the end user to add custom programs to the ROM. Without a START command in BASIC you could have a routine in your assembler that starts up the ROM based editor. That's what's done in Volksforth. I read somewhere that you live in the Netherlands. Many years ago I studied there for one semester, in the city of Tilburg. It was a lot of fun. Have a nice weekend!
  14. Hi @desertfish I tested the latest version of your assembler today. A lot of progress since I last tried it!
  15. Yes, it's not necessarily easy to get this right. I think a magic comment would work fine for your BASIC preprocessor. That is, if you decide to support different options. I'm sure there are valid historical reasons for the double byte CRLF on Windows, but it's hard to see the benefit of that encoding today. It only makes parsing the file more complicated in my opinion.
  16. I think this is an interesting solution to the shortcomings of the built-in BASIC. I haven't had time to try it out yet, but I will. As to the source code file format of any programming language that is developed for the X16 - be it BASIC, FORTH or assembly - it would be great if we used a common standard so that the source code may be edited in any present or future editor available on the platform. The plain text PETSCII or ASCII file is the reasonable solution in my mind. Plain text file formats are, however, not exactly the same on different computer platforms. This is most evident when thinking about line break encoding. We have at least the LF (ASCII 10) used in todays Linux/MacOS, the CR (ASCII 13) used by legacy MacOS, and of coarse the CRLF (ASCII 13+10) used by Windows. Commodore 8 bit computers did not recognize ASCII control character 10. Even though there were a lot of custom solutions, the closest we have to a standard for line break encoding on Commodore machines is a single CR. That is also used by the VolksForth compiler that is available to us.
  17. This issue is now fixed and pushed to the Github repository, branch "prepare-for-R39". This development branch of X16 Edit works with the current master branch of the emulator and Kernal, what will become R39.
  18. I see what you mean. GNU Nano empties the cut-buffer if you uncut and then cut/copy. But as you say, it's possible to do repeated uncuts. I will look at this issue in the upcoming release for R39. Thank you for bringing this to my attention.
  19. Nice work! The thing I struggled the most with was proper interrupt handling. In a hello world that exits very quickly, chances are that you never have an interrupt during the ROM code execution. After all, there are 155,555 cycles per VBLANK at 8 Mhz. If your program runs for a longer period of time, you would, however, not want the interrupt vector in $fffe-ffff point to outer space, but to some code that handles interrupts. The solution is quite easy. Let $fffe-ffff in your ROM bank point to the KERNAL RAM code banked_irq. That is located at address $038b.
  20. Hi. 0400-07FF "golden RAM" is OK to use. I think it will not play nicely with BASIC if your program is larger than that, and passes the 0800 boundary. I would say most programs are made with a small BASIC stub so you can start it with RUN. If you do it like this, the assembly code is stored in RAM right after the end of the BASIC stub, normally at 080D. How you build an assembly program with a BASIC stub depends on your assembly environment. If using the CC65 tool chain it is done automatically by the linker if you compile with a command like this: cl65 -o MYPROGRAM.PRG -u __EXEHDR__ -t cx16 -C cx16-asm.cfg MYSOURCE.S If you haven't used CC65, there's a bit of a learning curve. But it is worth it in the long run.
  21. I think I finally got it. FETVEC should not contain the MSB of the address you want to look up, but a zero page address that in its turn points to the address you want to read. A working example reading bank 6/address $c000: ;Setup ZP pointer stz $22 lda #$c0 sta $23 ;Call FETCH lda #$22 ;ZP pointer ldx #$06 ;ROM bank ldy #$00 ;Index for the indirect load jsr $ff74 ;Fetch call address ;Store return value sta $6000 rts
  22. I've been trying to use the KERNAL FETCH function for some time. But I can't get it to work. This is my test code: lda #$c0 ldy #$00 ldx #$06 jsr $ff74 sta $6000 rts Reading the KERNAL source code, it seems that the calling address is $ff74, not $ff77 as stated in the PRG. Following the path of execution from ROM bank 0/$ff74, it seems that the value in .A is stored in the FETVEC, and that you need not store it yourself before calling the function as stated in the PRG. When running this, I expect the function to fetch the value in bank 6 (.X) at address $c000 (MSB in .A) + .Y and store it in RAM address $6000. But it doesn't. Neither does it work when I try following exactly what's said in the PRG.
  23. Hi @LRFLEW I think the technique described by @Lorin Millsap would not work for VERA D0 & D1, because it is write only communication to the connected I/O.
  24. I've now made a pull request to include support in the emulator for Delete, Insert, End, PgUp and PgDn keys. I've also updated X16 Edit to support those keys. This code works only if run in the current master branch of the emulator and Kernal, i.e. what will become R39.
  25. Some notes on my progress supporting END, PagUp and PagDn. From the emulator source code, it's apparent that those keys are discarded. See file keyboard.c, function ps2_scancode_from_SDL_Scancode. I made the following minimal change to that function, and recompiled the emulator: case SDL_SCANCODE_END: return 0x69 | EXTENDED_FLAG; That emulates PS/2 scan code E069 when the END key is pressed. The good news is that I could successfully detect the END key in X16 Edit. Most probably, this will work on the real hardware out of the box.
×
×
  • Create New...

Important Information

Please review our Terms of Use