Jestin

https://github.com/jestin/asmM6502.vim I forked this project from repo that had a single commit 17 years ago, and was only just a mirror of a wiki post. I added 65C02 support a couple years ago, and today I decided to dive in and add a few more things. I don't know who else is doing 6502 assembly coding in Vim, but if you are, this should make it look a bit nicer.

@ZeroByte I think you are correct. The problem was that the emulator was loading an older build artifact from my project repo rather than the fresh one that was put on the card image. Thanks for clearing that up and helping me figure that out. This sort of begs the question, what is the correct use of `-prg` and `-sdcard` together? I thought the point of `-sdcard` was to run using a card image as the filesystem. It never occurred to me that the host filesystem played any part once that was specified.

I am having trouble loading an application with `-prg` when also using `-sdcard`. I captured two gifs to help show what I'm seeing. One was captured with `x16emu -sdcard card.img -prg AIRSHIP.PRG -scale 2 -joy1 -debug -gif with_prg.gif`, and the other with `x16emu -sdcard card.img -scale 2 -joy1 -debug -gif without_prg.gif`. This is with the same `card.img` file, so the only difference is whether I am using `-prg` or if I am using `LOAD` once the emulator is running. I should note how the first thing my application does it attempt to load additional resources from files on the SD card, however it should disable both layers before doing so (the "Loading..." text is made from hardware sprites). The case using `-prg` never actual runs, and is somehow loading up the incorrect player sprite as well. I suspect the loading of additional resources is the culprit. That all said, loading manually with `LOAD` still works fine.

I created a pair of tools that I've been using to create and edit tile sets, tile maps, and bitmaps for the Commander X16 (or anything else that uses the VERA). The purpose of these tools is to allow you to use GIMP and Tiled for creating your graphics. The first tool is a GIMP export plugin that can output VERA compatible tile sets and bitmaps. This eliminates the need for post processing like is needed when exporting a raw indexed file that the GIMP does out of the box. It can also go a step further by generating a Tiled tile set file (*.tsx) that can be used to draw tile maps. Best of all, the plugin supports non-interactive mode, meaning it can be called from a command line or makefile, treating your GIMP project file (*xcf) as a source for your resources. https://github.com/jestin/gimp-vera-tileset-plugin The second tool is a command line converter from Tiled's tile map file format (*.tmx) to a VERA compatible tile map file. This is also intended to be called from a makefile, so you can just edit your maps in Tiled and rebuild. I've figured out a simple way to use Tiled's automapping feature in combination with a command line argument in my converter to generate collision maps based on the layers you export. These collision maps wouldn't load into the VERA, but rather the Commander X16's main memory, and you'd have to write the code to make use of them in your game. However, once all that is complete, collisions (as well as map interactions) become a by product of your map design. https://github.com/jestin/tmx2vera I've created a quick demonstration video of these tools, so you can get a feel for what they offer: To keep it short, I didn't go into collision maps, but I'll likely create a follow up video to cover that topic in depth.

Oh yeah, I can really see the difference. One of these is running from the filesystem, the other from an SD card image. Definitely going to have to pre-load some loading screens into banked ram.

Nice work! I've been wondering for a while how badly I've been abusing the ability to load content quickly on the emulator, afraid that the load times would be too disruptive on actual hardware. I still don't know what the actual time difference will be, but this update at least makes it clear that calling LOAD isn't free. I'll have to make sure to turn my layers off as I'm loading the maps and tiles, but I suspected I'd have to do that eventually.

Wow! Looks great! Quick note to those who using the kernal `joystick_get` routine. It looks like both `JOY` BASIC command and the kernal `joystick_get` have changed. Previously the `A` register was used to pass the joystick number, 0 through 3. Now 0 means the new keyboard joystick, and 1 though 4 are for actual joysticks (SNES controllers). Tripped me up until I diff'd the docs. Other than that, my programs all ran perfectly! Excellent work, everyone!

I for one appreciate the open communication and honesty in this update. It's disappointing to hear the about the problems, but I'm very thankful that there are backup plans being worked on. I wish I had the expertise to lend a hand, but I can clearly see that all the easily solvable problems have already been addressed, and all that remains are the parts beyond my own capabilities. This update was literally published while I was in the middle of developing my own X16 game, so I obviously want to see the project become a success. Great work so far!

Wow. This is very noble of you, and I for one am grateful that this community has someone like you in it. It's impressive that you can will projects like the Commander X16 into existence fueled on enthusiasm alone. That said, I was also hoping you would be making a reasonable amount of profit for your efforts. Frankly, you deserve it, but there's another reason as well. Not to get into a macro-economical debate, but one of the benefits of capitalism is that it's supposed to put resources into the hands of those who have proven to best utilize them. You, sir, are one of those people. I feel the retro community would be better off with a wealthier 8-bit Guy who has more resources and more financial motivation to continue taking on inspiring projects.

Thank you, @Perifractic,for this update and clarification. Posts like this give us all insight into just how difficult it is to bring a new product to market, and how much effort and thought the Commander X16 team has already put into the project. I think I speak for everyone in this forum when I say that we appreciate your contributions.

For me, the Commander X16 has always been about education. You can look at it and see how it works. The parts are not abstract concepts implemented inside an FPGA. They are physical chips with datasheets connected by higher level block and circuit diagrams. I want the Commander X16 to be my 6 year old daughter's first computer. I've never given her a tablet or a video game console. I want her to understand what a computer is. I want her to see a computer with all its parts exposed. A kit will give her this. An FPGA will not.

Welcome! You sound similar to myself, in terms of experience. I too, was too young to be involved with C64s and other 8-bit machines, and have always felt like there's several layers of abstraction between the coding I've done and the actual hardware. If you don't mind me asking, where is the "Land of Chocolate". Sounds like a nice vacation idea.

Nice work! I spent the last 30 minutes "just seeing what this looks like". Nothing speaks better of a game than people getting sucked into playing it without intending to.

Does anyone know when all the buttons on the SNES controller are supported? Looking at the documentation and the ROM code, I get conflicting information. First, there's the documentation for the JOY BASIC command. It tells me that only a single byte is returned as a bitmask for the pressed buttons. Since the SNES controller has 12 buttons, it appears that X, A, R, and L are unsupported. However, if I look at the ROM code, I find this documentation on the joystick_get subroutine which is used by the JOY BASIC command: This says that the A, X, L, and R buttons are returned, just in a second byte returned in the X register. A quick test with the emulator shows that you can call joystick_get directly and receive the additional buttons in the X register, so I know for a fact the full controller is supported from assembly. However, with even more investigation, I see that the joystick_from_ps2 kernal subroutine has no support whatsoever for the A, X, L, and R buttons of the SNES controller. It appears that if using a keyboard as a joystick, no buttons map to the additional buttons of the SNES controller. So far, my conclusions are: the full SNES controller is supported from assembly using the joystick_get kernal routine the X, A, L, and R buttons are not supported by BASIC's JOY command the X, A, L, and R buttons are not supported when using a keyboard as a joystick Can anyone here confirm or contradict these conclusions? Sorry for continuing an old thread, but I thought this might be appropriate here for anyone searching the site about joysticks and gamepads.