Trying to decipher the mysteriously confusing WDC 65c02 SXB

[Aloha6502]

Hi folks,

I have a W65C02SXB Single Board Computer from Western Design Center. You can find the datasheet here:

https://wdc65xx.com/Single-Board-Computers/w65c02sxb/

Anyway, I tried using it the way WDC wants us to (in the starter guide here):

https://wdc65xx.com/gettingstarted/02-s ... g-started/

but the process has been very convoluted and at times confusing and not even working, it seems to randomly depend on your Windows install (I tried on different laptops and PCs and sometimes it works).

ANYWAY...

What I want to do is just reprogram the EPROM and experiment from there.

So what I have done is yanked the PLCC Flash ROM (a SST39SF010A @ PLCC32) via my EPROM programmer (TL866II Plus).

In the Windows software for the TL866II Plus (I know there is a Linux/Mac open source program called minipro) I browsed the hex dump. At the bottom, I found the three vectors, all pointing to page $81

However, scrolling to page $81 on the Windows software, I couldn’t see any code. It was just filled with $FF.

So I assume somehow it banks the memory. It’s a 1MB Flash ROM after all. But I don’t know how it has done this banking (or not).

Actually I searched this forum, and there has been an attempt before to make this SXB work, but it involved a lot of other technologies that I don’t want to work with, including Java, Python, etc.

viewtopic.php?f=4&t=6326&start=0

All I want to do is to experiment with writing 6502 assembly for it. Assemble on Mac/Win/Lin and then flash the EEPROM. Not unlike Arduino/PIC/Pi.

I also actually found another person who attempted to disassemble the EPROM code:

https://gist.github.com/kalj/66b23c4405 ... 50555af283

and the reset/interrupt vectors match what I saw from my own EPROM data read.

.org $fffa
.address $8104 ; NMI
.address $8115 ; RST
.address $8100 ; IRQ

However I have a few questions at this time:

1) What software do I use to disassemble the raw data dump file that I got from the EPROM?

2) Why are the addresses “empty” for, at least, the reset vector pointing to $8115?

3) How do I ensure I can generate an assembled object file that is exactly (length and format) what the TL866II Plus wants, to be written onto the PLCC32 Flash ROM? Either via the Windows software for the TL866II Plus, or the minipro program.

4) I think the best way to make this SXB board work is just to replace the EPROM contents with a usable monitor program that can be accessed via the built-in FTDI USB interface (FT245RL chip) and then it can be connected to any PC via USB and operated via a serial terminal program. Unfortunately WDC has not done this and the way it has to work now is too convoluted.

I searched across the Internet and there have been a few attempts by people to make this SXB product usable, but it seems everyone gave up.

I don’t want to.

Thanks!

[CountChocula]

Hello! I'm very much a beginner, but perhaps I can help a little here, at least on how ROM access is configured. Please do keep in mind that I'm just trying to come up with this by reading the documentation, so caveat emptor

If you look through the schematics, the topmost two address bits of the Flash ROM (A15 and A16) are controlled by the U5 VIA through the FAMS (connected to CB2) and FA15 (connected to CA2) signals; this effectively divides the ROM into 4 banks of 32kiB each that can be swapped in or out by manipulating the VIA's registers.

At reset, the VIA sets all its pins to input, but both CA2 and CB2 are pulled high by R21 and R22 respectively, which means that, by default, the bank at the ROM address $18000-$1FFFF will be active.

Now, the ROM's CE signal is tied to board's A15 signal, which means that it will be active when the addresses $8000-$FFFF are on the bus; thus, if I'm reading this correctly, at startup, the CPU will see the ROM's $18000-$1FFFF addresses as if they were mapped to its $8000-$FFFF address space, which matches what the datasheet says in table 1.4. If you look at the contents of the ROM, I bet you would find the initialization code in the uppermost 32kiB of the data dump.

Hopefully, someone with more experience will chime in and tell you if my reading is correct. As for disassembling, you could use something like DA65, but I suspect that it will be an arduous task, because you will have to find ways to distinguish code from data, and vice versa. I'm not a Windows user, unfortunately, so I can't help you much on the tooling end.

I hope this helps, and good luck!

[rwiker]

https://www.white-flame.com/wfdis/ may be worth a try for disassembling and analyzing the monitor. If the code in the gist referred to above is correct, it could be that WFDis might struggle, as it seems that the code in the gist actually contains 65c86 instructions as well (see line 158 in the gist).

[tmr4]

I don't have this development board but do have the 816 and 256 boards and found Andrew Jacobs' Github helpful. He has a Simple Monitor for the 02 board which may be helpful.

[Aloha6502]

CountChocula wrote:

Hello! I'm very much a beginner, but perhaps I can help a little here, at least on how ROM access is configured. Please do keep in mind that I'm just trying to come up with this by reading the documentation, so caveat emptor

If you look through the schematics, the topmost two address bits of the Flash ROM (A15 and A16) are controlled by the U5 VIA through the FAMS (connected to CB2) and FA15 (connected to CA2) signals; this effectively divides the ROM into 4 banks of 32kiB each that can be swapped in or out by manipulating the VIA's registers.

At reset, the VIA sets all its pins to input, but both CA2 and CB2 are pulled high by R21 and R22 respectively, which means that, by default, the bank at the ROM address $18000-$1FFFF will be active.

Now, the ROM's CE signal is tied to board's A15 signal, which means that it will be active when the addresses $8000-$FFFF are on the bus; thus, if I'm reading this correctly, at startup, the CPU will see the ROM's $18000-$1FFFF addresses as if they were mapped to its $8000-$FFFF address space, which matches what the datasheet says in table 1.4. If you look at the contents of the ROM, I bet you would find the initialization code in the uppermost 32kiB of the data dump.

Hopefully, someone with more experience will chime in and tell you if my reading is correct. As for disassembling, you could use something like DA65, but I suspect that it will be an arduous task, because you will have to find ways to distinguish code from data, and vice versa. I'm not a Windows user, unfortunately, so I can't help you much on the tooling end.

I hope this helps, and good luck!

Many thanks for your insight into this! But even after your explanation, I am still not fully clear about the connections. What is FAMS? I see it on the schematic but I tried Googling around and couldn't find out what the acronym means in this context.

(I'm not actually a Windows user either but I do use Windows to experiment with, because most of the software runs on Windows, and I can just format and reinstall it if I need to due to viruses, corruption, etc. I primarily use Mac and Linux Mint. In fact I even disable the network adapter in Windows, via Device Manager.)

[Aloha6502]

rwiker wrote:

https://www.white-flame.com/wfdis/ may be worth a try for disassembling and analyzing the monitor. If the code in the gist referred to above is correct, it could be that WFDis might struggle, as it seems that the code in the gist actually contains 65c86 instructions as well (see line 158 in the gist).

Thanks for the link and you are right. The disassembler had a hard time and I had an even harder time trying to make sense of it LOL

[Aloha6502]

tmr4 wrote:

I don't have this development board but do have the 816 and 256 boards and found Andrew Jacobs' Github helpful. He has a Simple Monitor for the 02 board which may be helpful.

Thank you for this link.

I ended up trying this route, even though I didn't want to install Java on my Mac/Linux machines.

However, I did it on my Windows machine via:

https://www.java.com/en/download/manual.jsp

and followed Andrew Jacobs's instructions.

I managed to get his monitor running, although the fonts are a bit weird on my screen (he is using the Java Swing classes I think for the UI).

Anyway, I was able to do some basic testing via the monitor, and was able to test that the Accumulator could indeed be manipulated. However directly modifying the memory addresses (I just used A9 for LDA immediate) is hardly efficient LOL

But it was a quantum leap already in terms of what I have been able to do with the SXB board thus far.

I looked through the RAM (as opposed to the EPROM memory) using Andrew's monitor and there was a ton of stuff all over the place. I don't know if it is real code, or just random bits from powering up the RAM. Anyway I was able to write over portions of memory and hard code the above LDA test.

[Aloha6502]

Finally found what FAMS means

https://github.com/scotws/265SXB-Guide/ ... r/flash.md

Although discussing the W65C265, Andrew also describes some fascinating methodology to do a kind of in-circuit programming of the Flash ROM, applicable to the 65C02SXB (the same Flash ROM part is discussed).

This opens up a lot of possibilities for on-board non-volatile storage and self-modifying ROM code.

[Aloha6502]

CountChocula wrote:

Now, the ROM's CE signal is tied to board's A15 signal, which means that it will be active when the addresses $8000-$FFFF are on the bus; thus, if I'm reading this correctly, at startup, the CPU will see the ROM's $18000-$1FFFF addresses as if they were mapped to its $8000-$FFFF address space, which matches what the datasheet says in table 1.4. If you look at the contents of the ROM, I bet you would find the initialization code in the uppermost 32kiB of the data dump.

Just to follow up, indeed you are correct.

I used the cool HexFiend app to check out the binary dump on my Mac:

https://hexfiend.com

[CountChocula]

Cool! One thing that I would be curious about is what happens when you swap to another bank and an interrupt occurs… I wonder if there is a bit of code somewhere that forces a bank switch to prevent a crash.

[Aloha6502]

CountChocula wrote:

Cool! One thing that I would be curious about is what happens when you swap to another bank and an interrupt occurs… I wonder if there is a bit of code somewhere that forces a bank switch to prevent a crash.

SUCCESS!!!

Finally found out how to turn on/off the lines!

I will show you the reset and interrupt vectors first.

And memory from $8100 onwards.

[Aloha6502]

Turns out (no pun intended) that to turn on the LEDs, the lines have to be LOW from the perspective of the 65c22.

Here is the board at RESET / Power up.

[Aloha6502]

Here are the LEDs for both lines turned on, after forcing the memory via the Java monitor.

Manual Write command to $7FEC.

[Aloha6502]

Writing using $8 and $C will trigger the LEDs.

$8 is %100X which is a "Handshake output" (I assume lines go LOW to begin handshake sequence).

$C is manual LOW output, %110X

[Aloha6502]

Here are the FA15 and FAMS lines independently controlled.