Jump to content

Stefan

Members
  • Posts

    313
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Stefan

  1. Some further thoughts on this. Unless the X16 KERNAL supports and enforces a standard for switching between programs that are simultaneously stored in RAM, each utility program must find its own solutions to the problem, for instance by creating different versions of the program that is loaded to different parts of low RAM hiding the program code in banked RAM while inactive having a restore routine copying back the program code to low RAM when called upon again It will not be as good as a ROM based solution, but it might work sufficiently.
  2. It was interesting reading @BruceMcF's post about, amongst other, TSRs in MS DOS. It's a really relevant comparison to task switching in another OS not supporting multitasking. TSR required memory handling, though. TSR like functionality on the X16 will be challenging due to the lack of memory handling. One benefit of storing utilities in ROM is that we would not need to think about that.
  3. Hi. I've been involved in discussions on two use cases that are quite similar: Using the text editor I've developed to write source code for Volksforth, and a resident file based assembler It is of coarse possible to load the text editor from SD Card, and start it load the source file from SD Card edit the source file save the source file to SD Card load the assembler or Forth compiler from SD Card assemble or compile load the executable from SD Card run the code for testing repeat However, all these steps will be tiresome to do over and over again. The issue will be present for any setup that uses two or more programs in parallel. One solution is to keep at least one of the programs in ROM, if that's supported by the platform. That's very convenient, much the same way as cartridge based utilities in the old days. There might be other solutions, for instance dividing the RAM between programs. Unless there is a load function that may relocate code, programmers must agree in advance upon the division of RAM resources. For any two programs that can easily be done if the programmers just talk to each other. But the complexity grows with the number of programs that are to be synchronized to each other. But it is what it is. If the platform will not safely support ROM based user programs, we must use what resources are available. As evident from history, great ideas will often come to light to overcome limitations put upon us.
  4. You may have noticed that @Michael Steil published a couple of blog posts during May re: Commodore's assemblers. If not, you find them here: https://www.pagetable.com/?p=1518 Michael has also published the source code of some of the assemblers, including the Commodore resident assembler for C64, on his Github account. The legal status of the source code is, however, not clear to me. Very interesting reading. I used the Commodore resident macro assembler on C64 myself in the 80's, and as I remember it, it worked great.
  5. Yes. Sorry. I meant that we have not yet found a previously existing 6502 assembler without these problems. The question I was answering was why we would need yet another assembler - your file based assembler.
  6. I thought so too. That was the start of this thread, calling out for open source 6502 assemblers that run natively on the 6502 and which with relative ease could be ported to the X16. It turns out to be really hard to find any such open source assembler. This thread is all about native programming on the X16, so the CC65 suite, however great to use, doesn't count. All assemblers discussed so far in this thread have different issues: source code can no longer be found, may be widely spread and used but without clear legal basis and/or are so closely tied to a develop environment that porting to X16 would as hard as writing the whole thing from scratch. That said, if there is an open source natively running 6502 assembler, preferably one that could be made to accept plain text files as source code, I'm listening.
  7. Even though there are a lot of 6502 platforms and even more assemblers, I would say there's a gap in the market: Open source 6502 assemblers are rare. 6502 assemblers are often tied to a development environment making them hard to port other 6502 platforms. An assembler that uses source files as input should be much easier to use on different platforms. Another advantage is that you are not tied to one development environment, but may use any editor of your liking. I once heard an economics professor say: There might be a gap in the market. But is there a market in the gap? Let's find out!
  8. Yes, I would also guess it's too late for that kind of change. The next best thing might be a robust KERNAL function for writing to the ROM banks. We'll just have to wait and see what the team comes up with...
  9. The purpose of the command is not to program the ROM, but to start a program that resides in ROM. The command is needed as you cannot change ROM bank in BASIC. Typing for instance POKE 1,[ANY ROM BANK BUT 4 WHERE BASIC IS STORED] will typically crash the BASIC environment. Without a FAR SYS command, you would need to type in a machine code startup stub in RAM with the MONITOR each time the computer is started. That is not very practical. Or load the startup stub from the SD card, which is also a bit cumbersome.
  10. Are there any vararg functions in the current BASIC implementation? I'm not aware. A vararg SYS command could be a lot of work. I don't know if it's worth it. There is much less need for a FAR SYS command that lets you jump to banked RAM. The RAM bank can easily be switched from BASIC with a POKE 0,[RAM BANK] before using the standard SYS command. My implementation of FSYS does only switch ROM banks.
  11. I made the pull request now. As suggested by @desertfish, I'm calling it FSYS. https://github.com/commanderx16/x16-rom/pull/213
  12. 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?
  13. 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.
  14. 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.
  15. 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?
  16. 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.
  17. Let me know if there are problems and I will try to sort it.
  18. 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
  19. Version 1.0.0

    38 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
  20. 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  
  21. 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.
  22. 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
  23. 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
  24. 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!
×
×
  • Create New...

Important Information

Please review our Terms of Use