Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by Stefan

  1. Great! Github is a great alternative for a project like this. As to the "select kernal ROM" issue. I have not done any thorough investigation, but this is what I think is happening. Basic is in ROM bank 4, and the Kernal is in ROM bank 0. You may see how the X16 ROM is put together in the makefile. You may also do PRINT PEEK($9F60) at the basic prompt, which returns a 4. When you start a program from Basic, you will continue to have ROM bank 4 selected unless you change it. In the Basic ROM bank, there are corresponding jump instructions to Kernal public functions at the same addresses as in ROM bank 0. But is is not the same content, and the actual Kernal functions are not also stored in ROM bank 4. For instance, FFD2 in bank 4 = JMP $FD53. In bank 0 this is JMP ($0326). If you follow the execution path in bank 4 from $FD53 I would say that you will eventually end up at an instruction that makes a bank switch, and then calls the function in ROM bank 0. And when it's done, it will switch back to bank 4. There's quite a lot going on preparing for the bank switch, explaining the delay. The solution seems to be an easy one. An assembly program that uses Kernal functions should switch to ROM bank 0 at start, and restore the ROM bank before program exit.
  2. From the discussion in the File I/O Performance thread I think we know how to optimize the speed of file reading: Disable interrupts Select Kernal ROM before the read loop Maybe getting the status value directly from memory instead of calling READST The assembler you're working on is very promising. I guess the next big step is supporting symbols/labels. These are the thoughts I have had on that subject: The symbol table entries could have a fixed length, making it easier to store and search them The symbol names could be long but not more than maybe 256 characters; to limit the size of the table you could opt store not the whole name, but for instance this information that is used for searching/matching symbols: A suitable number of characters from the start of the symbol name (for instance 6 characters) The total length of the symbol (Forth does this) An 8 bit checksum (for instance just adding the character ASCII values together). The symbol search could start from the end of the table. This makes it possible to redefine symbols, as the assembler will find the symbol that was defined last. This method is used in Forth. Redefined symbols could be used to support scopes, which I find very valuable in ca65. When starting a new scope the assembler needs to store the index of the last item in the symbol table. New symbols defined within the new scope are added to the symbol table at the end. When checking for not allowed duplicate symbols, the search would start from the end of the table and stop at the index where the scope started. And when leaving the scope the pointer to the last symbol would be reset to the index before the scope started, effectively forgetting all symbols created within the scope. These are not in any way my ideas, it is just a combination of Forth and David Salomon's book that I mentioned above in this thread.
  3. A side note. The ROM version of X16 Edit I'm working cannot avoid bank switching when reading files. The code is in ROM bank 7, and for each byte it reads it must go the Kernal ROM bank 0. However, I'm not using the Kernal JSRFAR function, but my own minimal bank switching code stored in low RAM ($0400-7FFF). Opening the same 73 kB file is done in about 5.3 s => 13.8 kB/s. The editor RAM version doesn't have to do the bank switching, and is a bit faster, loading the file in about 4.5 s => 16.2 kB/s. This is the bank switching code. Before calling this routine the address in jsr $ffff needs to be changed to the address you actually want to call. I use a macro to make this "self modification" safe. bridge_kernal: stz ROM_SEL ;Kernal is ROM bank 0 jsr $ffff ;$ffff is just placeholder pha lda #ROM_BNK ;Set ROM select to our bank again sta ROM_SEL pla rts ;14 bytes
  4. Interesting stuff. I have three test programs to verify this, all reading the 73 kB source code file provided by @desertfish in the native assembly thread. The original test program, interrupt disabled The same + changing ROM bank to 0 at start As no 2 + but reading the status directly from memory (status address = $0286, hope I didn't get that mixed up). I clocked these manually (average of three runs per test program): 7.8 s (7.76 s + 7.76 s + 7.75 s) => 9.3 kB/s 4.4 s (4.33 s + 4.30 s + 4.42 s) => 16.6 kB/s (78 % faster) 4.1 s (4.12 s + 4.07 s + 4.12 s) => 17.8 kB/s (91 % faster) The bank switching really seems to be the culprit. The READST function is also hitting the performance, but not nearly as much as the bank switching. test_banking_status.asm test_banking.asm test.asm
  5. The weird thing is that doing SEI + CLI outside the interrupt handler doesn't save much time. It's still a mystery to me.
  6. I have done some more tests, and written a completely new test program. These are my findings. My test program is as fast or slow as your test code, i.e. loading the source file in about 8 seconds. That is if the test program is run as a "normal program", and not within an interrupt. If I setup the IRQ vector in $0314-15 and makes it point to the start of my program, so that it is run as part of the interrupt (the same as X16 Edit) the file read is done in about 4 seconds without changing the code that's responsible for reading the file. Can this be the true behavior of the machine? Or is it some kind of bug in the emulator? test.asm
  7. The editor is essentially a custom IRQ handler. Everything, including the file read function, is run within the interrupt handler. So a file read blocks further interrupts from happening. However, if interrupts are disabled in your code, that doesn't help (much). The timer doesn't work then, but I manually clocked it to be 7,8 s. I don't know which vectors you are thinking about. But I would say the program does nothing special before starting the file load.
  8. Hi, I cannot see anything obvious. It seems that X16 Edit loads the complete file in about half the time. That's 8,208 lines of code. Blocks free in the editor before load=1,983 and after=1,692, diff=291 blocks x 251 bytes => the file is about 73,041 bytes. Seems to match the reported file size if the sdcard image is mounted in the host file system. The secondary address is different in your code compared to the editor, but that doesn't seem to affect load time. Another difference is that the editor appends ",s,r" to the file name for sequential file read. But this doesn't either seem to affect load time. We have to keep looking...
  9. After programming a while for the emulator I'm generally very pleased with how things are working. There are a lot of free ZP addresses, at least when you program in assembly. Typically even a large program really requires only a few ZP words, mostly for indirect addressing. The bank switching works well as is, and it will work even better when moved to ZP. But I have the advantage of not having done bank switching 6502 programs before, so I have no fixed view on how this could or should work. The interface to VERA is logical and easy to work with. I'm especially fond of the auto increment/decrement feature, making it possible to do really fast writes to the memory in VERA. And there's a lot of RAM and ROM, making it possible to do things never imagined on 8 bit computers. I think it really is a dream to program.
  10. Hi, Yes the editor reads the whole file, and then refreshes the screen. EDIT: I think it's sufficient if the assembler has one common read_line function, so that it's easy to expand it in the future to receive code from other sources (e.g. memory). It would also be nice to have one common write_byte function, so that it's easy to let the assembler write program code to different destinations, if need be (file, memory or whatever). These are just my thoughts.
  11. Really impressing work. Maybe you can improve the speed of the file read function. I tried to load a 433 kB file into X16 Edit. That took 26 seconds, i.e. 16 kB/s. Another thing. At the heart of the assembler I/O could be a read_line function. There's nothing wrong letting the assembler using different sources where the line is read from (file, memory). But again. Impressing work in such a short time.
  12. I uploaded v 0.3.3 of the X16 Editor today. New in this version: I have implemented a directory listing view, that you can use to select files for opening or saving. The default option is still to enter the file name manually at the prompt, similar to how GNU Nano works. At the open and save file prompts you may press Ctrl+T. "To files" in GNU Nano jargon. I hope that X16 Edit will be usable for native programming on the computer. The ability to easily open different files should be valuable. I have also made an alternative entry point that loads a specified text file immediately on startup. I have discussed this option with @pzembrod who also came with valuable input on the function. The idea with this function is that it may be useful when integrating X16 Edit with other programs, for instance Volksforth and the C compiler Philip is working on. If this is hard to understand, the functions are described in more depth in the manual and the special notes on using the ROM version that is available on the download page. Or you may watch this video. X16 Edit 0.3.3.mp4
  13. True. Also answered by I=U/R => During a short R is close to 0 Ohm and I is close to infinity Amps (but in reality the amount of amps provided by the PSU). Almost everything I know about electricity is contained within those three letters
  14. Isn't this answered by our beloved formula U=RI => I=U/R? That is, the amount of current drawn by a circuit depends on the voltage and the overall resistance, not how many watts the PSU may supply.
  15. Yes, I remember. It's good we can help each other
  16. I tried again, and it works now with secondary address 0. I was pushing the right params to SETLFS so it must have been something else. Sorry for cluttering the page.
  17. Hi, I've been testing to read the disk directory in assembly using Kernal functions. I have found some example code for the X16 that uses secondary address $60 when reading the directory. However, I can't find that this is mentioned anywhere in the docs. In the 1541 user manual, there is an example program at the end that reads, amongst other, the directory. It uses secondary address 0. Secondary address $60 seems to work, but secondary address 0 returns error "File is not an input file". Why is this so?
  18. That would be a very nice project. A stumbled upon David Salomons book about build an assembler (mentioned above in this thread). It's very hands on. And freely available online: http://www.davidsalomon.name/assem.advertis/asl.pdf I found the discussion on how to layout the symbol table and how to support different scopes especially interesting.
  19. Hi @desertfish The great benefit of using standards (such as ASCII encoded plain text files) is that it makes it possible for programs to work together. And that makes it possible to easily divide programming tasks between different programmers or teams. In the long run, we will be using our combined efforts more effectively, hopefully ending up with better applications.
  20. Hi, Exciting news that you are close to get the C compiler working. Haven't had time to play with VolksForth the last couple of weeks. If you could give me some pointers on how to use 6502asm.fth, that would be nice. Also, if you come up with anything else that would make X16 Edit better for Forth or C programming, please let me know.
  21. Interesting idea. Maybe you actually could compile the CA65 assembler with the CC65 compiler. When I compiled the CC65 suite for my desktop computer, CA65 became 211 kB. Obviously you need to strip out some functionality, as @SlithyMatt mentioned above, to make it fit.
  22. Some initial thoughts after reading manuals for the Merlin assembler: If I understand, it only assembles source code residing in memory, not directly from files, not what I would prefer. I read somewhere that it uses a custom binary format for the source code, not plain text. May or may not be true. And it is very particular when it comes to source code formatting. My guess is that porting the Merlin assembler, requires porting the whole system including the editor (probably not a good option) or splitting out just the assembly function and doing a lot of rework to that.
  23. According to Wikipedia, the heir of the author of that program released all his "Apple software to public domain" in August of 2000. https://en.wikipedia.org/wiki/Merlin_(assembler) However, the Merlin assembler was also bundled to an editor, initially a line editor, which very few of us would stand to use. I don't know how much that complicates porting the program. Anyway, I think it would be a good idea to look at the source code to get a feeling for how hard it would be.
  24. Yes, I've used CA65 quite a lot. It's a great assembler. I realize that it will be hard for a native assembler to match all features of CA65. But it would still be possible to make a very good assembler that is easy to run on many different 6502 systems. In order for the X16 to become something else than a game console with a complicated way of starting your games, native programming is probably important. I suspect that there is no easily portable open source assembler that you could build upon. Hopefully I'm wrong. If my suspicion is true, it's a bit sad considering the wast amount of time and effort poured into developing various assembly programming environments for different 6502 based systems since the processor was born. If you would go about making yet another assembler, it should be made portable. Using raw text files as input is probably be the best option. Bundling assemblers/compilers makes them harder to port. Also, making a good source code editor is a huge task in itself, and takes a lot of time and energy that could be saved for making the best possible assembler/compiler. So if you would go about making that assembler, please let it read source code from text files and output object files controlled by a minimal text based interface.
  • Create New...

Important Information

Please review our Terms of Use