Proto #2 support in GitHub ROM, Emulator & Documentation

Announcements by the development team or forum staff.
Post Reply
Michael Steil
Posts: 94
Joined: Mon May 18, 2020 7:25 pm

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by Michael Steil »


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!

IMG_1256.jpg

Snickers11001001
Posts: 140
Joined: Wed Jan 20, 2021 6:43 pm

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by Snickers11001001 »


Great news!     Thanks for all your hard work on this.   What an amazing collaboration.   

 

BruceMcF
Posts: 1336
Joined: Fri Jul 03, 2020 4:27 am

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by BruceMcF »


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?

http://wilsonminesco.com/6502primer/GENRLI2C.ASM

ZeroByte
Posts: 714
Joined: Wed Feb 10, 2021 2:40 pm

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by ZeroByte »


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!

Ender
Posts: 220
Joined: Sat May 09, 2020 9:32 pm

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by Ender »



17 minutes ago, ZeroByte said:




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.

SlithyMatt
Posts: 913
Joined: Tue Apr 28, 2020 2:45 am

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by SlithyMatt »



1 hour ago, Ender said:




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.

Elektron72
Posts: 137
Joined: Tue Jun 30, 2020 3:47 pm

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by Elektron72 »



1 hour ago, Ender said:




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?

Stefan
Posts: 454
Joined: Thu Aug 20, 2020 8:59 am

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by Stefan »


I tried to run my program X16 Edit on the emulator+Kernal at their current state on Github.

It was easy to get it working. In my case, only changing the address in the definition of RAM and ROM bank select.

m00dawg
Posts: 346
Joined: Wed Jul 08, 2020 12:41 am
Contact:

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by m00dawg »


That's great news Stefan!

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.

Author of Dreamtracker (https://www.dreamtracker.org/)
Check Out My Band: https://music.victimcache.com/
Stefan
Posts: 454
Joined: Thu Aug 20, 2020 8:59 am

Proto #2 support in GitHub ROM, Emulator & Documentation

Post by Stefan »



35 minutes ago, m00dawg said:




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.

Post Reply