Jump to content

Stefan

Members
  • Posts

    251
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Stefan

  1. I've now got a test reimplementation of the token search function that uses a table of token metadata (lengths, checksums and pointers to start of token name). This seems to have cut the time in half from version 0.0.2 at least for small programs, now using about 0.007 seconds per line of source code, corresponding to 7 seconds to load a source file of 1,000 lines. Needs a bit of cleanup before publishing. Hopefully I find some time this weekend, but they are promising very nice weather where I live.
  2. I converted a small number guessing game to the source code format accepted by the BASLOAD tokenizer. Original code found at: https://retrogamestart.com/answers/learn-commodore-64-basic-programming-type-text-based-games NUMBERS.BAS
  3. Thanks. I also noticed that bug. I think I have fixed it in version 0.0.2 now available on the download page. The 0.0.1 version did not call READST to test EOF condition if the last char was LF or CR. It seems that you get only one shot at reading the EOF condition. If you miss that and read one more character, you will never get an EOF. Source code available at https://github.com/stefan-b-jakobsson/basload Unless no more critical bugs are found, I will continue looking at performance issues. Without analyzing it a lot, I guess that the program's function to test for presence of a BASIC token is called a lot. The label search already uses a checksum to speed up the search. I think I could calculate the checksum of the tokens as well on program startup, and use these to speed up the token search. Version 0.0.2 takes about 1 second to load a source file of 70 lines. That corresponds to 1,000 lines per 14.3 seconds. I'm sure it could be made to run a lot faster.
  4. I did now publish a first version of my loader. You find it here: https://www.commanderx16.com/forum/index.php?/files/file/192-load-basic-programs-from-text-files/
  5. Stefan

    BASLOAD

    Version 0.0.6

    34 downloads

    BASLOAD lets you write BASIC programs without line numbers in the editor of your choosing. BASLOAD runs natively on the X16. As it's name implies, BASLOAD loads BASIC programs stored on the SD card into RAM. While loading a file, it's tokenized so that it can be run by the X16's built-in BASIC interpreter. Source files are stored as plain text that can be edited in almost any editor on the X16 or on a modern computer. There are, however, special bindings for the text editor X16 Edit making the programming workflow more convenient. Instructions on how to use BASLOAD and source code may be found here: https://github.com/stefan-b-jakobsson/basload
  6. BASLOAD View File BASLOAD is best described as a BASIC tokenizer. It takes BASIC source code stored on disk in plain text format, and loads it into RAM. While loading the file, it's tokenzied so that it can be run by the built-in BASIC interpreter. The purpose of BASLOAD is to enhance the programming experience by letting you edit BASIC source code in the editor of your choosing without using line numbers. Instead of line numbers, named labels are defined as targets for GOTO and GOSUB statements. Instructions on how to use it and source code is found here: https://github.com/stefan-b-jakobsson/basload Submitter Stefan Submitted 07/10/21 Category Dev Tools  
  7. True. I forgot that you had made that program. I must look at your solution again. There are some differences as far as I can tell: Source format is different My program does not support long variable names My program outputs BASIC code directly to RAM
  8. Hello everyone! The last week I've been working on a program that loads a BASIC program from a text file. After some (or a lot of) fiddling I finally got it to work. Some notes on the source file format: There are no line numbers in the source file Instead you define labels on lines you want to jump to with GOTO or GOSUB Labels must be defined at the start of a line, but it's OK to have leading blank spaces A label must start with one of the letters A-Z. The following characters may be A-Z or numbers 0-9 The symbol table stores the first 12 letters of a label Line breaks are marked by a single LF or CR The work flow: You edit the source file on the X16 using X16Edit or any other available editor Store the source file on the SDCARD Load the BASIC loader program, and run it Enter the source file name Type RUN to run the loaded BASIC program Enclosed is a video showing this work flow. I need to do some more work on this before publishing. basload.mov
  9. 8 simultaneous files might very well be enough The open file count doesn't limit the number of source files as such, but the level of includes (a file that includes a file, that in it's turn includes a file, that includes a file and so on). In 6502 assembly I seldom go beyond one level of includes. If you would not like to have that limitation, I think it's doable. The file stack mentioned above could hold the following info: File number if file is open, otherwise a value telling us it's closed (a value that's not a valid file number). File path, so we can reopen the file if need be. Next line number, where to continue assembly when we get back to this file. When including a file: The line number where to continue assembly in the parent file is stored in its stack entry. Check if there is a free file number that can be used by the include file If no file number is free, one of the files on the stack needs to be closed. The file number stored in its stack entry is set to the chosen "closed value". The new include file is opened and the details are stored on the file stack. When reaching the end of an include file: The included file is closed and removed from the file stack. The parent file details are read from the file stack (without removing the entry of coarse) If it's already open, set it as input file If 'ts closed, open it, and read until getting to the line number where to continue assembly
  10. That would be very useful. I guess it could be treated as a stack based problem, i.e. a stack that holds references to files and next line number within each file. On starting the assembler the first file is pushed onto the stack. When including a file, it's pushed onto the stack. When at the end of the include file, it's pulled from the stack, and so forth. The stack might have to be a custom software solution. What I do not know is how to effectively handle multiple files from a file system perspective. Can you keep multiple files open at the same time? If so, how many? If not, when reopening a file, AFAIR there is no seek command. To get back to a specific line number within a reopened file you would need to read the file from start counting the line breaks. I don't know badly that would affect performance. Keep up the good work!
  11. At least some of that info is in the Wiki https://wiki.c256foenix.com/index.php?title=Main_Page There's a memory map and a list of Kernal functions. AFAICT, the Kernal is custom built for the platform. I have never looked closely at the 65C816 processor, and don't really know the differences to the 6502/65C02 apart from that you have 24 bit addressing, wider/new registers, additional OP codes and so forth.
  12. Is it safe to say that creating a proper task switcher will be quite a feat?
  13. Some thoughts on the design of a task switcher: It must be interrupt driven. It cannot use the vector 0314-0315, as these are typically set by user programs. A minimal requirement is that a new vector to be used by the task switcher is added to the KERNAL interrupt main loop. The rest of the task switcher could be RAM based and loaded from SD card. The task switcher API core functions could be register, called by a user program that wants to be added to the task switcher show, called by the switcher to show a registered program hide, called by the switcher to hide a registered program close, called by the switcher to close and remove a registered program Possible input to the task switcher when calling register Program name Memory usage: zero page, golden RAM, low RAM Call address for show function (within the user program) Call address for hide function Call address for close function We need to think about what memory content to store, and where to store it If we are talking about complete executables and their data, the memory usage could easily become quite large. Example: 10 programs asking for backup of the whole low RAM would more or less fill banked RAM (512 kB). Is it necessary to backup executable code, or should code and data be well separated so that the executable could just be reloaded from SD Card. Then the backup would contain only data. Could it be left up to the user program to decide on how to store and restore its data when calling hide and show? To enable several programs to use banked RAM for that storage, we need memory management. It's hard to see a solution not requiring the user program to call a register function. That means the task switcher will only work with user programs designed to work with it. We should avoid adding a lot of features unless we want yet another operating system on our hand
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. 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!
  21. 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...
  22. 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.
  23. 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.
  24. I made the pull request now. As suggested by @desertfish, I'm calling it FSYS. https://github.com/commanderx16/x16-rom/pull/213
×
×
  • Create New...

Important Information

Please review our Terms of Use