Wrong port# for RAM bank switch in documentation? - resolved

Schlowski

Member
Sep 24, 2019
45
22
8
Edit2: Got an answer on github:

In the VIA specification, PA is register 1 and PB is register 0, so this is correct.

But yes, the documentation should also have the addresses.
I think I'm not the only one who fell into that trap!
--------------------------------------------------------------------------------------------------

The Programmers Referance Guide lists the VIA#1 for the bankswitch registers as follows:

VIA#1

PinDescription
PA0-7RAM bank
PB0-2ROM bank
PB3-7[TBD]

This leads to the assumption, that $9F60 is the port for the RAM bank and $9F61 the port for the ROM bank.

In the emulator the RAM bank switch is definately $9F61, the following little program show this:

Code:
10 GOSUB200
100 PRINT"BANK # (-1=QUIT)";:INPUTB
110 IFB<0THENRETURN
120 IFB>255THENEND
130 POKE$9F61,B
140 PRINT"BANK #";B;"=";PEEK($A000):PRINT
150 GOTO100
200 REM MARK RAM BANKS WITH #
210 FORB=0TO255
220 POKE$9F61,B
230 POKE$A000,B
240 NEXT
250 POKE$9F61,0
260 RETURN
Switch to $9F60 and the emulator crashes...

Question is: Documentation error or emulator error?

Edit: Opened an issue at github...
 
Last edited:

jdifelici

New Member
Sep 24, 2019
21
22
3
If you look up in the Programmer's Reference it says:

Banked Memory

The RAM bank (0-255) defaults to 255, and the ROM bank (0-7) defaults to 7 on RESET. The RAM bank can be configured through VIA#1 PA0-7 ($9F61), and the ROM bank through VIA#1 PB0-2 ($9F60). See section "I/O Programming" for more information.

So, $9F60 is ROM and $9F61 is for RAM.
 
  • Like
Reactions: qbradq

Schlowski

Member
Sep 24, 2019
45
22
8
Yep, my fault, I simply overread the addresses in that chapter, switched to I/O programming as advertised and got surprised by the fact that Port A follows Port B in the memory layout :)
 

jdifelici

New Member
Sep 24, 2019
21
22
3
Well I had the addresses wrong as well in my demo program. That is why I couldn't get the GETJOY routine to work. After reading this post, and fixing my code, it now works. So Thanks. :)
 
  • Like
Reactions: Schlowski

qbradq

New Member
Sep 14, 2019
24
13
3
Stubbed my toe on this one too. One of those "can't believe I overlooked that" moments for sure :)
 

GregZone

New Member
Sep 29, 2019
21
13
3
Wow, I had to go and lookup the W65C22 VIA datasheet to remind myself of the register mapping.

Indeed, the Port B data register is at address 0 followed by the Port A data register at address 1. Kinda non-intuitive.
This is then followed by the two data direction registers at address 2 (Port B DDR), and address 3 (Port A DDR).

I was (historically) more familiar with the Motorola 6821 PIA, which (more intuitively) had the Port A registers grouped preceeding the Port B registers.


Screen Shot 2019-10-06 at 5.10.34 PM.png
 
  • Like
Reactions: Schlowski

BruceMcF

Active Member
May 19, 2019
100
30
28
It wonder whether it's because the "access the data port without triggering handshake" mode is at the end at $F. That would be on "the main parallel port" PA which I'm guessing would have the port-wide handshake.

That is, if A3=A2=0 => A1=DDIR/Port select, A0=Port A/B select, that fits with A3=A2=A=A0=1 => No handshake Port access and A0 is still Port A/B Select.

Multiplexing A0 as the port select and as part of the handshake free data port function select implies the main parallel port that has the no-handshake access function is A0=1, PA Port = $1, PA DDIR = $3.

It's flipped relative to the MOS CIA locations, but if the above is the reason that the VIA is allocated that way, there's no gain from flipping them around like that for the CIA, since there isn't a "no handshake port access" function AT $F ... the MOS CIA has counter control registers at $E and $F.
 

Schlowski

Member
Sep 24, 2019
45
22
8
One can always add it via a pull request. :)
One maybe, me: no. To be honest I have really no idea about how that github thing with its pull requests work. I barely managed to open an issue ;-) I'm used to svn as a repository...
 
May 22, 2019
409
211
43
One maybe, me: no. To be honest I have really no idea about how that github thing with its pull requests work. I barely managed to open an issue ;-) I'm used to svn as a repository...
It's actually really simple, but I can't write a tutorial tonight. If you're on Windows, you can use the desktop client and it basically "just works". For Mac or Linux, you have to do some command line stuff.

I'll try to find or write up a simple tutorial on doing PRs.
 
  • Like
Reactions: Schlowski

BruceMcF

Active Member
May 19, 2019
100
30
28
One maybe, me: no. To be honest I have really no idea about how that github thing with its pull requests work. I barely managed to open an issue ;-) I'm used to svn as a repository...
It does seem to be tricker than opening up an issue. Here's a tutorial: https://www.thinkful.com/learn/github-pull-request-tutorial/#Time-to-Submit-Your-First-PR

... I cannot say that I have time to work through the tutorial right now, but I guess I will have to eventually if I put my Forth source code up on GitHub.
 
May 22, 2019
409
211
43
It does seem to be tricker than opening up an issue. Here's a tutorial: https://www.thinkful.com/learn/github-pull-request-tutorial/#Time-to-Submit-Your-First-PR

... I cannot say that I have time to work through the tutorial right now, but I guess I will have to eventually if I put my Forth source code up on GitHub.
also... from what I’ve read, pull requests are not a Git thing. The Git protocol has no specification for this. This is entirely a system written by Github’s devs to automate merges from an external repository.
 
  • Like
Reactions: BruceMcF

qbradq

New Member
Sep 14, 2019
24
13
3
Wow, I had to go and lookup the W65C22 VIA datasheet to remind myself of the register mapping.

Indeed, the Port B data register is at address 0 followed by the Port A data register at address 1. Kinda non-intuitive.
This is then followed by the two data direction registers at address 2 (Port B DDR), and address 3 (Port A DDR).

I was (historically) more familiar with the Motorola 6821 PIA, which (more intuitively) had the Port A registers grouped preceeding the Port B registers.
MOS was forced to stop selling their 6501 and peripheral pin-compatible chips due to this lawsuit. I think that's why the 6522 registers are flipped as well.