Jump to content

Stefan

Members
  • Content Count

    210
  • Joined

  • Last visited

  • Days Won

    6

Stefan last won the day on January 12

Stefan had the most liked content!

Community Reputation

129 Excellent

1 Follower

About Stefan

  • Birthday 01/03/1973

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yes, it also supports the ON ... GOSUB N1, N2, ... construct.
  2. 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.
  3. 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.
  4. 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...
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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
  11. 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.
  12. 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/
  13. Version 0.0.5

    11 downloads

    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
  14. Load BASIC programs from text files 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  
×
×
  • Create New...

Important Information

Please review our Terms of Use