The current "master" branches of the x16-rom, x16-emulator and x16-docs repositories now correspond to the "Proto #2" hardware, which is incompatible with the "Proto #1".
banking is now done though zero page addresses 0 and 1 instead of VIA GPIOs
the I/O area at $9F00-$9FFF has changed in layout (except VERA)
the layout of the VIA GPIOs has changed
4 SNES controllers are supported
there is now a real-time-clock – but it is not yet supported by the emulator or ROM
If you have software that does manual banking or accesses I/O devices (other than VERA) manually, you will need to update it in order to be compatible with the next emulator/ROM release (r39) as well as real hardware. The Programmer's Reference Guide should have all the necessary information.
Please file bugs on GitHub if you find any issues. Thanks!
I saw something that sparked some curiosity ... I was wondering how you get an open collector from the VIA, and I saw from Garth Wilson's page when writing data bits, or when toggling the clock, the data direction register on the GPIO being used to write 0 then set it to output, and being set to input to allow them to float high (due to the pull up resister). I can see why the half duplexhardware serial shift register is not used, since it is a driver rather than an open collector.
But the Specifications now say that 16 GPIO on the VIA#2 will be available to the User, while all sixteen Port A and B GPIO are specified for VIA #1. Is that 14 GPIO, or are the handshake lines somehow going to be used for I2C?
This is not a feature request or a complaint about functionality - I would just like to know so that I can plan accordingly in my projects - is there any intention for the functionality of the Kernal LOAD/SAVE routines to have a mode where the first 2 bytes of a file are not skipped when loading into RAM/VERA/HIRAM? I'm not speaking to the emulator's intercepts of these functions but the actual Kernal ones. If this has been asked/answered already, then I apologize, but there are a few threads here going over the various behaviors of kernal LOAD vs Emu LOAD etc. The reason I ask is that a couple of my projects are intended to work with files that aren't necessarily crafted for the X16, so if the Kernal load will always either use the first two bytes of a file as the load address, or skip them when using a user-supplied load address, that means I should definitely be crafting my own load routines such that I keep them handy for reuse.
This is not a feature request or a complaint about functionality - I would just like to know so that I can plan accordingly in my projects - is there any intention for the functionality of the Kernal LOAD/SAVE routines to have a mode where the first 2 bytes of a file are not skipped when loading into RAM/VERA/HIRAM? I'm not speaking to the emulator's intercepts of these functions but the actual Kernal ones. If this has been asked/answered already, then I apologize, but there are a few threads here going over the various behaviors of kernal LOAD vs Emu LOAD etc. The reason I ask is that a couple of my projects are intended to work with files that aren't necessarily crafted for the X16, so if the Kernal load will always either use the first two bytes of a file as the load address, or skip them when using a user-supplied load address, that means I should definitely be crafting my own load routines such that I keep them handy for reuse.
Thanks, and keep up the amazing work, everyone!
If you set SA (secondary address) to 0 with SETLFS, it will use the X/Y registers as the address to load to, instead of the first two bytes of the file. There was a bug where this wasn't working with SD card images, but it should be fixed now with the latest changes.
If you set SA (secondary address) to 0 with SETLFS, it will use the X/Y registers as the address to load to, instead of the first two bytes of the file. There was a bug where this wasn't working with SD card images, but it should be fixed now with the latest changes.
It will still expect those files to have a two-bytr header, even though it's otherwise ignored.
If you set SA (secondary address) to 0 with SETLFS, it will use the X/Y registers as the address to load to, instead of the first two bytes of the file. There was a bug where this wasn't working with SD card images, but it should be fixed now with the latest changes.
I believe ZeroByte is referring to a mode that would actually load the first two bytes as data. As far as I am aware, SA = 0 simply ignores the first two bytes of the file, and begins loading data after them. I also believe this is a necessary feature for the X16's LOAD routine. Maybe SA = 2 could be used to enable this?
I've been having some issues with mine. Seems to be related to VERA, which is odd since I didn't think any of that changes. Some weird stuff like my box drawing rountines not drawing the same way as they did before, and some very odd scrolling behavior. I haven't figured out if it's somehow my code or not so hadn't filed any reports on it yet until I have a better idea/test case. But otherwise the baking updates were super easy fix so the core parts of Command Tracker still seem to work with just that change.
I've been having some issues with mine. Seems to be related to VERA, which is odd since I didn't think any of that changes. Some weird stuff like my box drawing rountines not drawing the same way as they did before, and some very odd scrolling behavior. I haven't figured out if it's somehow my code or not so hadn't filed any reports on it yet until I have a better idea/test case. But otherwise the baking updates were super easy fix so the core parts of Command Tracker still seem to work with just that change.
OK. Haven't tested it much, but there are no obvious artifacts.
