Proto #2 support in GitHub ROM, Emulator & Documentation

ZeroByte · Post by **ZeroByte** » Tue Mar 30, 2021 3:02 pm

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?

AndyMt · Post by **AndyMt** » Wed Mar 31, 2021 1:49 pm

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.

ZeroByte · Post by **ZeroByte** » Wed Mar 31, 2021 1:55 pm

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....

desertfish · Post by **desertfish** » Wed Mar 31, 2021 2:29 pm

@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.

ZeroByte · Post by **ZeroByte** » Thu Apr 01, 2021 5:43 am

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

pzembrod · Post by **pzembrod** » Sun Apr 11, 2021 11:47 am

@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.

ZeroByte · Post by **ZeroByte** » Mon Apr 12, 2021 1:56 pm

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.

pzembrod · Post by **pzembrod** » Mon Apr 12, 2021 4:22 pm

2 hours ago, ZeroByte said:

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

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

ZeroByte · Post by **ZeroByte** » Mon Apr 12, 2021 4:47 pm

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"

Scott Robison · Post by **Scott Robison** » Mon Apr 12, 2021 5:37 pm

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.