Jump to content

Stefan

Members
  • Posts

    313
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Stefan

  1. This thread is a bit old, but I've too been thinking about printer support. Being a complete novice on the matter, I would also believe that it's doable to write a driver that outputs PCL (or Postscript). Outputting plain text without a lot of formatting and other options might not even be hard. I don't know if it's true, but I would think that the biggest problem is how to transfer data to the non-vintage printers typically found in our homes today. The small HP LaserJet I have got at home only has an USB port as an example. As far as I can tell, you would need an "active adapter" between the X16 and the printer to solve this. Building this around a microcontroller such as the Arduino is probably very hard. You can find discussions online where people are trying to make Arduino based printer servers. I don't know if any of these attempts has been successful. The next level is something like a Raspberry Pi. You would then probably end up with a complete Linux OS on the Pi. The X16 could send PCL or Postscript data to the Pi (for instance over I2C), and the Pi could send it to the printer. The actual printing could be done by calling the Linux lp command. It might, however, be disturbing for some that this "adapter" is a lot more capable than the X16. We would need to hide the Pi in a nice box not to keep thinking about that Or are there any better ideas?
  2. Version 0.0.6 published now. This version makes BASLOAD + X16 Edit = True. As before, type SYS $9000 to load a BASIC source file. A new feature is that the program remembers the last loaded file, and you may select to reload that file without typing its name. Another new feature is that you by typing SYS $9003 may load and start the text editor X16 Edit. BASLOAD expects the X16 Edit executable to be stored in the root folder of the SD Card. The actual CBM DOS path is "//:X16EDIT*.PRG". If BASLOAD has been used to load a BASIC source file, that file is automatically opened in the editor. The purpose of these changes is to make the edit-save-load-test cycle more convenient. A more thorough description of the BASLOAD usage is found on Github: https://github.com/stefan-b-jakobsson/basload For an illustration of the BASLOAD+X16 Edit workflow, see the attached short video. BASLOAD workflow.mov
  3. @kliepatsch Debugging 6502 assembly can be quite hard. It would be interesting to hear what techniques are used by others. I usually do the following: I try to divide code into functions - the smaller the better - with well defined input and output. Test each function separately to ensure it works. Also test that functions work properly if the input is invalid. I think it's very valuable to comment what each step of the code is supposed to do. It helps you think more clearly about the code. Before using any tools to debug the code, I usually do the debugging in my head by just reading the code and thinking about what could go wrong. In most cases I find bugs with this method. If that is not successful, my next method is to store intermediate results/values in memory that I can look at after testing the function. This is often very helpful. I usually resort to the emulator's debugger as a last resort. Sometimes the debugger works great. But often I have a hard time making it work efficiently. Maybe I'm not using it right.
  4. Yes, it also supports the ON ... GOSUB N1, N2, ... construct.
  5. Published version 0.0.5 just now. This version adds support for BASIC source code in ISO mode lower case. On reading the source file, ISO mode lower case text is converted to upper case. The content of strings is, however, left untouched. This should make it possible to program conveniently in ISO mode as well. Apart from that a few bug fixes. The function that was reading the Kernal version number on startup was still not working properly in all circumstances, which caused some "random" loading failures. Available in the download section, and on Github.
  6. Yes, it's a clever solution.
  7. Your code should work. I made a simple test to enter a two line BASIC program, and then deleting the last line, and then another test to insert a new line in the middle of a program. I could not find a situation where the VARTAB pointer in $03e2 is not moved to the first address after the end of the program.
  8. That is understandable. I did the following to make a coming clean-up easy: The Kernal version is read at program startup. The control addresses for RAM and ROM select used by the detected Kernal version are stored in two zero page words In the rest of the program I read and store bank selections using these zero page words, like "STA (RAM_SEL)" When R39 is official, it's easy to do a project wide search and replace "(RAM_SEL)" with "RAM_SEL". RAM_SEL would then just be a definition pointing to the control address. But just a few minutes ago @Kevin Williams announced that prototype #3 is working more or less. Maybe R39 is not too long away...
  9. The Kernal version is stored in bank 0/$ff80. The problem is how to change to bank 0 before you know what version is running. There are several ways to handle this, I'm sure: Your solution might work. One possible problem is that there is a risk you are overwriting values used by the Kernal. Even if you could determine that $bfff is not used today it might be in the future. Another solution I've read about some time ago is to write a 0 both to $01 and to $9f60. This seems to work, but I'm not really a fan of doing this, as $9f60 is connected to VIA1 in R39 according to the PRG. Using the FETVEC function has the advantage that you are using a public Kernal function that should be stable between versions.
  10. Hi, I was struggling a bit with reading the Kernal version number in an assembly program that is to support both R38 and R39. As is apparent from the PRG, the Kernal version is stored in ROM bank 0/$ff80. The problem I had was that you are not in ROM bank 0 when starting an assembly program from BASIC. Reading $ff80 in the BASIC ROM bank does not give you the version number. And to change ROM bank you need to know what version is used. Almost like "catch 22". I found a solution using the Kernal function FETVEC ($ff74) that is callable from the BASIC ROM bank, getting the version number like this: lda #$80 sta $22 lda #$ff sta $23 ldx #$00 lda #$22 jsr $ff74 And then you have the version number in A.
  11. There are no guarantees, but VARTAB seems to be at $03E2 both in R38 and the upcoming R39. I would expect low RAM usage to be quite stable. "Non-public" KERNAL functions in ROM I expect to move around quite a lot between versions.
  12. Version 0.0.3 now published. It contains: performance improvements, support for ON ... GOTO N1, N2, N3 support for labels after THEN without preceding GOTO/GOSUB code cleanup Please let me know if you use it and find bugs.
  13. 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.
  14. 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
  15. 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.
  16. 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/
  17. Stefan

    BASLOAD

    Version 0.0.7

    70 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 BASLOAD workflow.mov
  18. BASLOAD View File 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 Submitter Stefan Submitted 07/10/21 Category Dev Tools  
  19. 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
  20. 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
  21. 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
  22. 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!
  23. 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.
  24. Is it safe to say that creating a proper task switcher will be quite a feat?
  25. 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
×
×
  • Create New...

Important Information

Please review our Terms of Use