Jump to content

Proto #2 support in GitHub ROM, Emulator & Documentation


Recommended Posts

15 minutes ago, TomXP411 said:

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. 

 

Huh. It should be using the built-in Clang toolset. I'd open the Visual Studio Installer and check whether that's been installed under the "Desktop development with C++" section. Looks like it's grouped with optional components, maybe I manually added it in.

I remember moving to clang because I got tired of certain build warnings that msvc would glibly overlook, and then bite me when I submitted a PR. 😛

Edited by StephenHorn
Link to comment
Share on other sites

14 minutes ago, StephenHorn said:

Huh. It should be using the built-in Clang toolset. I'd open the Visual Studio Installer and check whether that's been installed under the "Desktop development with C++" section. Looks like it's grouped with optional components, maybe I manually added it in.

I remember moving to clang because I got tired of certain build warnings that msvc would glibly overlook, and then bite me when I submitted a PR. 😛

I will check. I probably didn't install CLANG since I do mostly c# development. 

** yeah, I had to dig into the Optional Components to explicitly install it. I'm doing that now. 

I also managed to get the Linux version and the ROMs to compile, so I'm just working on a Windows executable. 

 

Edited by TomXP411
  • Like 1
Link to comment
Share on other sites

Windows version is WORKING. I compiled the executable with the help of Steven's GitHub project file for Visual Studio 2019, and I built the ROMs on Linux. 

Here's a Zip with the executable and ROMs in it. This should tide Windows users over until the weekend. 

 

x16emu-2021-03-29.zip

Edited by TomXP411
  • Thanks 1
Link to comment
Share on other sites

Correct, you only need to include rom.bin. There are various symbol files generated by building the rom as well, but even though they've usually been included in the release packages, the emulator doesn't need them and can't load them besides (well, not until or unless the feature gets added).

  • Like 1
Link to comment
Share on other sites

5 hours ago, StephenHorn said:

Correct, you only need to include rom.bin. There are various symbol files generated by building the rom as well, but even though they've usually been included in the release packages, the emulator doesn't need them and can't load them besides (well, not until or unless the feature gets added).

Yeah, while the symbol tables aren't used by the emulator, they are useful. My menu program works by printing the LOAD command to the screen and stuffing CR into the keyboard buffer. So I looked that up in the symbol table... So it's super useful to know where KERNAL and BASIC variables are located. I was actually going to include them, but forgot and didn't want to spin my Linux VM back up.

 

 

 

 

 

Link to comment
Share on other sites

6 hours ago, mobluse said:

I believe it's only necessary with rom.bin, but you also included basic.bin, dos.bin, and geos.bin. When packaging for Linux according to the Makefile it only includes rom.bin.

BTW I succeeded in building it for Raspberry Pi OS Buster on Raspberry Pi 4B and it works with all programs I tested with so far.

x16emu_linux-armhf-2021-03-29.zip 263.59 kB · 2 downloads

Thanks for the tip. I just grabbed all the .bin files in the build directory. I figure they were only a few KB, so it didn't hurt either way. 

 

Link to comment
Share on other sites

I'm in the process of updating Brixx and Invaderz to the new emulator and ROM. I want them to be compatible with R38 and R39 - but how can I detect which version the PRG is running?

I know I can detect if I'm running in the emulator:
    read $9FBE/$9FBF, must read 0x31 and 0x36

This doesn't seem to be the version, just an indicator that the software is running on the emulator. Is there an official way to detect ROM/emulator version? I found different solutions, but none seemed officially supportet. Like reading $FF80 or $FFFA etc.

What's the best approach there?

  • Like 1
Link to comment
Share on other sites

1 hour ago, AndyMt said:

I'm in the process of updating Brixx and Invaderz to the new emulator and ROM. I want them to be compatible with R38 and R39 - but how can I detect which version the PRG is running?

I know I can detect if I'm running in the emulator:
    read $9FBE/$9FBF, must read 0x31 and 0x36

This doesn't seem to be the version, just an indicator that the software is running on the emulator. Is there an official way to detect ROM/emulator version? I found different solutions, but none seemed officially supportet. Like reading $FF80 or $FFFA etc.

What's the best approach there?

"The KERNAL version can be read from location $FF80 in ROM. A value of $FF indicates a custom build. All other values encode the build number. Positive numbers are release versions ($02 = release version 2), two's complement negative numbers are prerelease versions ($FE = $100 - 2 = prerelease version 2)." - https://github.com/commanderx16/x16-docs/blob/master/Commander X16 Programmer's Reference Guide.md

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

Ok, if I see this correctly, right now in the emulator looking at $FF80 shows -38, which means ROM version equals emulator version? Using the one posted further up (upcoming R39?) gets me $FF, so it's a custom ROM, but presumably will be -39 once the emulator and ROM is released?

It occurs to me, that what I actually need is to detect the board revision - so I know which RAM banking address to use and all the other hardware memory mappings.

  • Like 1
Link to comment
Share on other sites

  • Administrators
Just now, AndyMt said:

Ok, if I see this correctly, right now in the emulator looking at $FF80 shows -38, which means ROM version equals emulator version?

Using the one posted further up (upcoming R39?) gets me $FF, so it's a custom ROM, but presumably will be -39 once the emulator and ROM is released?

It occurs to me, that what I actually need is to detect the board revision - so I know which RAM banking address to use and all the other hardware memory mappings.

  • Yes, the releases have matching ROM and emulator versions. Be careful to negate the number in case it's negative, and then compare it with e.g. 38 or 39. Future versions may use positive numbers.
  • Non-official builds use $FF as the version, yes.
  • The next ROM and emulator will be -39.
  • In order to detect Proto #1 vs. Proto #2, check for abs(version) >= 39. This will work for all released emulator + ROM versions. I'm aware that this check won't work for non-official builds.
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

3 minutes ago, Michael Steil said:

In order to detect Proto #1 vs. Proto #2, check for abs(version) >= 39. This will work for all released emulator + ROM versions. I'm aware that this check won't work for non-official builds.

Super, thanks! It's anyway just needed for a few weeks until the official release and the web-emulator are updated. So I will just assume a custom ROM is indicating the latest ROM and board revision.

And maybe the releases happen before I have updated my stuff anyway 😉.

Link to comment
Share on other sites

If you just want to know your bank address works, you could do something like this:

Check the value at, say $BFFF, inc(bank register), check bfff - if different, your bank register value is correct. If same, inc BFFF, dec(bank). If different then bank reg. is correct. If same then bank reg is wrong. (Then optionally fix the value at BFFF)

Link to comment
Share on other sites

1 hour ago, ZeroByte said:

If you just want to know your bank address works, you could do something like this:

Yes, I thought about this. I actually know what's supposed to be in some of the banks, so I could just do the check without modifying anything.

Link to comment
Share on other sites

6 minutes ago, AndyMt said:

Yes, I thought about this. I actually know what's supposed to be in some of the banks, so I could just do the check without modifying anything.

Derrr - yeah use the ROMs to check. Why didn’t I think of that?

Link to comment
Share on other sites

On 3/30/2021 at 2:04 PM, AndyMt said:

And maybe the releases happen before I have updated my stuff anyway 😉.

Turns out I have to wait for an updated version of cc65 and it's cx16 libs. I tried hard to compile it myself and then fix the .inc and .h files - but failed. Anyone working on this? I can support by updating all the VERA and VIA addresses etc. in the asminc and include files.

Link to comment
Share on other sites

4 minutes ago, AndyMt said:

Turns out I have to wait for an updated version of cc65 and it's cx16 libs.

This is why I decided to only use release versions of the ROM/EMU because keeping this many bleeding edge things in sync was just more of a headache than I am willing to endure, at least on a regular basis....

Link to comment
Share on other sites

@Michael Steil thanks for the work on the roms and the emulator, looking good.   Actual bug fixes  obviously have priority, but there is one Quality of Life patch on the emulator that currently is quite annoying for me, and probably for other Linux users as well.

As it stands, starting and stopping the emulator results in a nasty display flicker and actually causes other applications to freeze or stop updating (most notably, Firefox in my case, it goes totally blank). That patch adds a tiny SDL hint to no longer bypass the display compositor and totally fixes the issue (at least, on my system).

It's easy enough (for me) to build a custom emulator with this patch applied, but I think it would be great if the official emulator that is due to be released soon comes with it out of the box.

  • Like 1
Link to comment
Share on other sites

On 3/29/2021 at 12:41 PM, Michael Steil said:

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

I have created a new pull request with the correct value in audio.c (pull #342).

Hope this was in time to make the cut for R39

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

@AndyMt I got VolksForth to work uniformly with R38 and R39 yesterday. While looking at my code, I realized that I have the simple and robust opportunity to just operate both bank switching addresses $0000/1 and $9f60/1 in tandem; this seems to work nicely and seems good enough to me for the transition period. See https://github.com/pzembrod/VolksForth/commit/fb100de9edc92dfb8db25ed97e6b7f0a4b3085fa for details.

@Michael Steil One question about this approach: It seems clear to me that writing to $0000/1 has no adverse effects in R38 as there's just 2 unused RAM bytes there. How about $9f60/1 in R39? That would write to as yet unimplemented/uninstalled I/O devices in the expansion slots, right?

Also, follow-up question: It seems that the release of R39 is imminent? If so, then I can hold back releasing the next VolksForth version (and, subsequently the next cc64 version) until R39 is out, and include the cleanup https://github.com/forth-ev/VolksForth/issues/33 of the temporary double switching in my next releases already.

  • Like 3
Link to comment
Share on other sites

On 4/11/2021 at 6:47 AM, pzembrod said:

How about $9f60/1 in R39? That would write to as yet unimplemented/uninstalled I/O devices in the expansion slots, right?

That's what I gather from perusing memory.c in the emu source.

Link to comment
Share on other sites

1 minute ago, pzembrod said:

Ah, that's great, thank you for looking into it, @ZeroByte!

FYI - the current code on the main branch simply returns zero if you read from $9f60/1. (or any un-mapped device in that range, really). One thing I just thought of that would be an issue: A routine wants to read the current value of the bank register so it can put it back where it was when finished - e.g. in an IRQ handler. You can't just read both locations - you have to read one or the other, or else do some logic that says "read $9f61 and if it's zero, read $00"

Link to comment
Share on other sites

48 minutes ago, ZeroByte said:

FYI - the current code on the main branch simply returns zero if you read from $9f60/1. (or any un-mapped device in that range, really). One thing I just thought of that would be an issue: A routine wants to read the current value of the bank register so it can put it back where it was when finished - e.g. in an IRQ handler. You can't just read both locations - you have to read one or the other, or else do some logic that says "read $9f61 and if it's zero, read $00"

Or you use two bytes for the time being. Read $00 & $9F61, store them in temporaries, set them both to the desired bank so that it works on either version, then restore both.

  • Like 1
Link to comment
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.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use