Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by JimmyDansbo

  1. Thanks for your kind words. I will definitely upload it in the devtools category when I have completed all 3 flavors and documentation.
  2. On my Intel Core i7-8850H at 2.6 GHz the emulator runs at full speed with the occasional drop to 99%
  3. VTUI save/restore demo View File A small demo of the save_rect and rest_rect functions from the VTUI (VERA Text User Interface) library. For more information see https://github.com/jimmydansbo/vtuilib/ It is still very much work in progress, but I thought I would share this little demo with you. Submitter JimmyDansbo Submitted 02/08/21 Category Demos  
  4. Version 0.1


    A small demo of the save_rect and rest_rect functions from the VTUI (VERA Text User Interface) library. For more information see https://github.com/jimmydansbo/vtuilib/ It is still very much work in progress, but I thought I would share this little demo with you.
  5. Glad to hear you got the issue solved. Your graphics looks pretty cool
  6. No worries, I will not have any time to look at it before tonight anyway.
  7. No, you just need to move your program and TEXT file into an SD card image and use that instead of using the host filesystem. However, if the LOAD function returns to your program with a file not found error, it is probably because the file is not found. I don't know about CC65, but I know that ACME sometimes has some strange behavior in converting from ASCII to PETSCII. Try changing to Assuming that "TEXT" is the actual filename your program is trying to load.
  8. I just testet with your program and saw the same behavior that you are describing. I then tested with one of my own programs (that work just fine) and saw exactly the same behavior as in your program. I believe that Matt is correct and what we are seeing is the emulator going off and doing weird stuff because we are not loading from an SD card image. Just to be on the safe side, I tried modifying my VTUI example program to load the binary into banked memory at bank 4 and that also seems to work just fine.
  9. I only press F11. Keep in mind that in my test code I do no setup what so ever, I just jump directly to calling FFD5 without caring what is in any registers. I could just as well just do a SYS $FFD5 from basic, but wrote a 1-line assembler program to be able to add the .byte $DB to start the debugger.
  10. It is very possibly a far jump, I have not looked into the code in BASIC ROM to see what it actually does.
  11. Here is a new video where I step all the way through to the code you want. All I do is press F11 and ensure the debugger shows me the correct code if it jumps to banked ROM address https://streamable.com/fxj3dr
  12. The debugger and the monitor is NOT the same. Debugger is what we have been looking at so far, but you have a monitor in the emulator as well that can be invoked by typing MON in BASIC. The Monitor in X16 is derived from the monitor in final cartridge, but the debugger is not the same. If you change RAM or ROM bank during execution of code, you can not expect things to work correctly. If you follow the call to FFD5 all the way through, you will find that BASIC seems to do some stuff before it changes the ROM bank to 0 and calls FFD5... just keep stepping through the code and you will eventually get to the point you want 00:D949
  13. I am not sure I understand the problem. I have made a short video where I follow the call the FFD5. Let me know what it is I am not seeing. https://streamable.com/knpl04
  14. It seems to be working for me. F11 is indeed the key you want to ensure that you enter subroutines. As you see here, I am ready to JSR into FFD5, but notice that BKO is 04 which means the ROM bank is currently set 4 When I then F11 to follow the JSR, I get this: I have jumped to $FFD5, but as you see, it says 00:FFD5 so it is showing me the contents of ROM bank 0. By typing d4ffd5 I get the debugger to show me the contents of ROM bank 4 and I can follow the instructions. Just be sure that you manually follow the BKO value. btw, you can also get the debugger do show you the content of VERA memory by typing: vBXXXX where B=bank or high part of address (0 or 1) and XXXX is the low 16 bits of the address.
  15. If I understand the documentation correctly (https://www.cc65.org/doc/ca65-11.html#ss11.58), .ifref only returns true if something has referenced the name before it reaches the .ifref In your case I am guessing you are including vera.inc in the beginning of vera.asm hence clearScreen has not been referenced yet when the compiler goes through the vera.inc source.
  16. You are welcome in #commander-x16 on freenode or you can join CX16 Basic and Assembler newbies on FB (https://www.facebook.com/groups/434065570799988) Otherwise this forum is the place to go for help
  17. Take a look at my edited response You need to make the debugger show you the correct bank by inserting the bank number before the address
  18. When you use the debugger in the emulator to follow kernal routines be sure to manually switch the bank number. In this case it seem like you are working on ROM bank 4, but the debugger is displaying the content of ROM bank 0. To switch, type dBXXXX where B = bank number and XXXX is the address you want to view. I think that should make it easier to see what is happening in the debugger. The LOAD function expects the first two bytes to be the address where the file should be loaded. Even if you specify an address when loading, LOAD still expects the first two bytes to be an address, but then just ignores those two bytes.
  19. It is not automatic, neither is the header of a box. I just draw a border and a fill_box, then I use plot_char to replace the border with T-pieces where necessary, use print_str to write the header and and hline to draw a horizontal line across my box. In a more feature-rich library there would be the option to add headers to boxes and to divide a box with horizontal or vertical lines. As it is now, the user has to use the basic functions provided to create those advanced features.
  20. I think I have reached a point where I have the Generic VTUI light-library finished. I have managed to fit the functions I initially wanted into 1KB so it can be loaded into golden RAM. The functions included are: initialize - Initialize the jumptable at the beginning of the library to make it easy to call the rest of the functions screen_set - Set the screen to 40x30 or 80x60 or toggle between the two clear - Clear the screen with a specified color set_stride - Set the VERA stride value set_decr - Set or reset the VERA decrement bit gotoxy - Point VERA memory to specific coordinates on screen plot_char - Put a screencode character and color code on screen at the current VERA address scan_char - Read a screencode character and color code from screen at current VERA address hline - Draw a horizontal line vline - Draw a vertical line print_str - Convert and print a 0-terminated PETSCII string to screen at current VERA address fill_box - Create a filled box pet2scr - Convert a PETSCII code to screencode scr2pet - Convert a screencode to PETSCII border - Draw a non-filled box with a border save_rect - Save an area from screen to memory rest_rect - Restore screen from memory I know that this is very basic, but hopefully it could, at least, help people get an understanding on how these things could work. I still have lots of work to do as I have not done anything on the ACME and CA65 include files. I also need to create another example and possibly a demo of how to use the library. I think I will leave the light version with the above functions, and focus on getting the include files finished as well as create a demo on how to use the library. I do plan on extending the library with scrolling, string input, hex/number to string conversion and more, but for now I will get this light version finished.
  21. I have come a bit further. The generic library is functional although it does not have too many functions yet. I spent all of the evening yesterday trying to write some documentation and hopefully it is understandable. Have a look at https://github.com/JimmyDansbo/vtuilib/blob/main/VTUIlib-generic.md You can also look at the examples and download the binary here: https://github.com/JimmyDansbo/vtuilib/tree/main/VTUIlib-generic The example shows off most of the functions currently implemented and should look like this: Let me know if anything is unclear ( there are probably things that needs to be rewritten or clarified)
  22. Effects library does not have its own repo, but it can be found here: https://github.com/Dooshco/X16/blob/master/Effects.asm I have converted to ACME assembler her: https://github.com/JimmyDansbo/cx16stuff/blob/master/effects.asm
  23. I have already made it relocatable. It does not care what address it is loaded at. All that is needed is to initialize the library by JSR'ing to the base address after load. If you have loaded the library to $0400, you just JSR $0400 or if you have loaded it to $A400, you JSR $A400. Afterwards the functions are callable by BASEADDR+2, BASEADDR+5, BASEADDR+8, BASEADDR+11 and so on.
  • Create New...

Important Information

Please review our Terms of Use