JimmyDansbo

Please let me know when you find typos, errors and bugs. It seems I quickly "go blind" when looking at my own text and source.

The library has been updated a bit and I have added it to the Dev Tools section

VTUI Library View File VTUI (Vera Text User Interface) library Can be used to create text user interfaces using VERA instead of relying on the KERNAL functions for writing to screen. The library is less than 1KB which means it can be loaded into Golden RAM at $400. As an alternative, include files are provided for Acme and CA65 assemblers. See https://github.com/JimmyDansbo/VTUIlib for documentation, examples and include files. Submitter JimmyDansbo Submitted 02/16/21 Category Dev Tools  

I have actually startet with a bit of RAM testing.

How did you find out about the $388 and $389 addresses ? Do they actually do anything? I don't see any difference...

I don't know how to solve that, but as @desertfish said, as long as your program stays within the 20x15 range, you should be good to go.

This should solve it, although the addresses $386 and $387 might change with new releases of the KERNAL

Gives you 20x15 You can omit line 10 and still get the same result, but then your cursor disappears. Have a look at the VERA documenation and search for HSCALE or VSCALE

I use the Atom editor, it has syntax highlighting, is multiplatform and has github integration. In order to convert images to binary, I have created https://cx16.dk/piskelc2bin/ and https://cx16.dk/png2bin/ I startet out using http://piskelapp.com/p/create but don't do much graphics. As you might gather, I like my online tools Just wish there would be an online IDE with emulator- and github-integration and maybe even online compiler that was not dependent on locally installed software.

Thank you very much for the video. Nice to hear you talk about your progress as well as the speedbumps. As a bonus I now have an idea on how to actually use your tracker I find it a lot easier to get the basics by watching a video like this than to have to read through documentation that often describes a lot of theory that I don't really understand anyway. When I get a better grasp of how to use this tracker, I will most definitely need real documentation to help me get to the next level. - Keep up the good work

It is great to read about your progress and I am looking forward to be able to really play around with the tracker. When my projects get to a certain size, I usually go back to the beginning and try to read my code with new/fresh eyes. This usually results in more comments in the code as I need to explain to my self what certain pieces of code does. I also try to look at macros and functions and see if I can "lock it down", meaning that I am fairly certain that the code is correct and does not need fixing or tweaking. When I do find those, I usually move it out of the way or "encapsulate" it in "****" lines letting my self know that I don't need to look at this again unless there is a problem. Next time I decide to read from the beginning, is is usually a lot easier because some macros and functions have already been locked away and the rest should have better comments. It seems like a lot of work, but in my experience, it has helped me weed out bugs before they appeared and it usually also helps me see where I have inefficient code.

Thanks for your kind words. I will definitely upload it in the devtools category when I have completed all 3 flavors and documentation.

On my Intel Core i7-8850H at 2.6 GHz the emulator runs at full speed with the occasional drop to 99%

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  

Glad to hear you got the issue solved. Your graphics looks pretty cool

No worries, I will not have any time to look at it before tonight anyway.

Ok, that seems to work just fine

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.

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.

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.

It is very possibly a far jump, I have not looked into the code in BASIC ROM to see what it actually does.

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

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