Jump to content
Michael Steil

Proto #2 support in GitHub ROM, Emulator & Documentation

Recommended Posts

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

  • Like 21
  • Thanks 7

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Found only 1 issue so far, which turned out to be a bug in my own code (in the file based assembler -  fixed now):  it was reading $0000 sometimes by mistake, which happened to work before because that  used to contain zero.  But in v39 it is no longer zero.

 

Share this post


Link to post
Share on other sites
10 hours 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?

Or, in other words, for the LOAD and SAVE routines to work with SEQ files in addition to PRG files. If it doesn't start with a load address, it is not a PRG file.

I think it would have to be a feature request for LOAD to load sequential files. It would have to query whether the file IS a PRG or a SEQ file, and it would either have to be an error if you tried to load a sequential file in mode 1, or better it loads to the HighRAM window under the current bank if you load a sequential file in mode 1.

As far as Saving SEQ files, I think that would be better to just do it in the current API (though AFAIU not all of the pieces are fully implemented): create the file as a SEQ file, open it in a channel for writing, and write the bytes one after another to the channel you have opened. LOAD could well find out that a file is a SEQ file, not a PRG file, but SAVE would need to be told, and the game is probably not worth the candle since those will often be things like game data files that are loaded a lot more than they are saved.

Share this post


Link to post
Share on other sites
Posted (edited)
On 3/27/2021 at 2:45 PM, Elektron72 said:

I believe ZeroByte is referring to a mode that would actually load the first two bytes as data.

That's exactly what I mean. Even if the Kernal's LOAD/SAVE are always going to { use+skip | ignore+skip } the 2 "header bytes", doing it yourself isn't that hard. One workaround would be to read the first two bytes individually using OPEN mechanics, and then using load to do the rest with $base+0x02 as the target...

 

p.s.: I would rather LOAD supported not skipping the bytes tho. 😁

Edited by ZeroByte
Added P.S.
  • Like 1

Share this post


Link to post
Share on other sites

Is there an official release of the emulator, or will I need to compile it? The latest release seems to be "Kyoto", from last August. 

 

Share this post


Link to post
Share on other sites
5 minutes ago, TomXP411 said:

Is there an official release of the emulator, or will I need to compile it? The latest release seems to be "Kyoto", from last August. 

The main branch is the current in-development code. It's the "bleeding edge" version, and you must build it yourself. The release version is still R38.

 

Speaking of which - I noticed a pull request in the main branch to fix the YM2151 audio frequency - the fix is wrong and should not be used. It should be set to 3.579545 MHz. The pull request has doubled this value.

  • Like 1

Share this post


Link to post
Share on other sites
5 minutes ago, ZeroByte said:

Speaking of which - I noticed a pull request in the main branch to fix the YM2151 audio frequency - the fix is wrong and should not be used. It should be set to 3.579545 MHz. The pull request has doubled this value.

Can you please put this comment into the pull request on GitHub? Thanks!

  • Thanks 1

Share this post


Link to post
Share on other sites
26 minutes ago, TomXP411 said:

Is there an official release of the emulator, or will I need to compile it? The latest release seems to be "Kyoto", from last August. 

I am planning the r39 release for this weekend.

  • Like 4
  • Thanks 3

Share this post


Link to post
Share on other sites
12 minutes ago, Michael Steil said:

Can you please put this comment into the pull request on GitHub? Thanks!

I did add to the comment thread on the pull request last night when I noticed it. It's pull request #241 and my comment there is under the username ZeroByteOrg

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Michael Steil said:

I am planning the r39 release for this weekend.

Thanks.

 

I was trying to build it myself, but not having much luck. I don't know which build tools I need for Windows, and the Visual Studio project I have doesn't build the current version of the emulator. If anyone else has built this on Windows, it might be nice to add a "How to build on Windows" doc to the repository. 

Edited by TomXP411

Share this post


Link to post
Share on other sites

I used to cross build it on a Linux VM. I had to keep a cross built SDL library to do it.

Share this post


Link to post
Share on other sites
59 minutes ago, TomXP411 said:

Thanks.

 

I was trying to build it myself, but not having much luck. I don't know which build tools I need for Windows, and the Visual Studio project I have doesn't build the current version of the emulator. If anyone else has built this on Windows, it might be nice to add a "How to build on Windows" doc to the repository. 

The Makefile is setup to do a cross-build, using MinGW to build a Windows .exe from Linux or iOS. The catch is, it is very specific to Michael's build environment, with hard-coded paths, at least one username, and other assumptions about the build environment, including a custom-built SDL2 implementation.

It should be possible to clean some of this up, but we'd want to coordinate with Michael to make sure we don't break his ability to create release packages. It would be almost ideal if someone were to create a CMake script, but again we'd want to coordinate with Michael.

In the meanwhile, there is no native Windows build configuration, nor a true cross-platform build configuration a la CMake. The best I can offer is that you can use the environment I setup for myself, using Visual Studio Community 2019:

Note that if Michael accepts the PR that reorganizes the emulator code files, that VS2019 sln will need to be updated accordingly. It's not hard, though-- basically, just delete all the entries under "x16-emulator" and then drag all the source files from the emulator back into that folder in VS2019. 😛

Share this post


Link to post
Share on other sites
1 hour ago, TomXP411 said:

Thanks.

 

I was trying to build it myself, but not having much luck. I don't know which build tools I need for Windows, and the Visual Studio project I have doesn't build the current version of the emulator. If anyone else has built this on Windows, it might be nice to add a "How to build on Windows" doc to the repository. 

I currently do it using MSYS2.  A lot of people might not want to bother to download and set that up, however.  I like it because things compiled natively with it work natively in Windows, so you can just build with minimal changes to the code, and don't have to bother to cross-compile.  Maybe this is easy with WSL too, I haven't looked into it too closely.  It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.

Share this post


Link to post
Share on other sites
Posted (edited)
5 minutes ago, Ender said:

I currently do it using MSYS2.  A lot of people might not want to bother to download and set that up, however.  I like it because things compiled natively with it work natively in Windows, so you can just build with minimal changes to the code, and don't have to bother to cross-compile.  Maybe this is easy with WSL too, I haven't looked into it too closely.  It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.

I'll check that out, thanks. 

I can't use WSL because that installs and activates Hyper-V - which kills my ability to use VirtualBox (VBox still runs but switches to software virtualization, and no amd64 software will run.)

I'm installing a Linux distro on VirtualBox right now. The Raspberry Pi operating system didn't work, because I couldn't install the SDL development tools. Debian has other bugs that make it unusable on VirtualBox... so now I'm trying Mint Cinnamon. Not to start an OS flame war... but I'm baffled by why the Linux scene is so uneven... it's hard to get a distro to even work reliably on my machines, let alone use it for production tasks like software development. It would be nice if this could be built by Visual Studio, since that's the de facto standard on Windows systems - but I get why Linux-first and Mac-first developers wouldn't go to the trouble to build a VS solution.

 

 

 

Edited by TomXP411

Share this post


Link to post
Share on other sites
Posted (edited)
6 minutes ago, Ender said:

 Maybe this is easy with WSL too, I haven't looked into it too closely.  It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.

I looked into this for a couple of hours the night the update was posted, it was not as easy as I'd hoped, and I ultimately fell back to using my VS2019 setup. 😛

Edited by StephenHorn

Share this post


Link to post
Share on other sites
2 minutes ago, StephenHorn said:

I looked into this for a couple of hours the night the update was posted, it was not as easy as I'd hoped, and I ultimately fell back to using my VS2019 setup. 😛

I tried the VS2019 project on Github, but it seems to require CLANG, which depends on another library, which I can't seem to get installed and working through NuGet. 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please review our Terms of Use