Jestin

I really feel the issue here isn't technical in the slightest. We all know there are ways to increase the RAM, yet all of them will delay manufacturing and increase the price. The one and only question to be answered is "why is this important enough to delay manufacturing and increase the price?" Without an extremely compelling answer to that question, this whole idea is a non starter. Do you have a compelling answer?

$0001 is used for ROM bank switching, and $0002 is currently reserved for the KERNAL's "virtual registers". Taking over 2 more addresses for RAM switching is more than likely going to eat away at the user allocated zero page addresses, which a lot of people are taking advantage of. It also makes selecting a bank as complicated as selecting VERA addresses. Hardware and cost issues aside (which is already being very dismissive), at this stage in the game that's going to break a lot of people's code. Also...I'm not sure I understand the point. If we are okay with a more complicated selection process for HI RAM, why not just do what @x16tial suggests and have this be an optional hardware component on the expansion bus? I mean, you're already suggesting that address selection works like an expansion unit...why not just make it an expansion unit? And frankly, even then I don't know if this much RAM is needed on what is effectively a "toy" computer whose design goals align more with simplicity than utility. What use case is important enough to delay manufacturing, break people's software, and make it more difficult to teach my 7 year old daughter how to switch RAM banks? I'm just not seeing it.

I think this is the opposite of what I've been doing If you ever want images to start in GIMP and end up on the X16, I have you covered: https://github.com/jestin/gimp-vera-tileset-plugin

I finally made the follow up video I promised about how to utilize these tools to generate the data needed for collisions in a Commander X16 game:

Take to the Skies! (demo) View File This is an in-development game that I have been creating. It's main purpose is to aid in a set of tools I've been developing for creating VERA graphics resources (https://github.com/jestin/gimp-vera-tileset-plugin and https://github.com/jestin/tmx2vera), however the project has recently started to take on a life of its own. This is a very incomplete game (only one partially complete level, and no real goals), but should give a feel for how the graphics and game play will be. When more features are added to the game, I'll update this demo. This requires emulator version 41. Submitter Jestin Submitted 07/22/22 Category Games  

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!