W65C816SXB and the Single Linux

[cjb]

I decided to grab up one of the W65C816SXB boards before they disappear forever... Unfortunately, I forgot to do my usual technology check and didn't investigate their compatibility with the FOSS/GNU world, and I'm discovering that TIDE interface is not a tried-and-true serial monitor, or at least, doesn't behave like one... Bugga.

Have I missed something (..needs a full-handshaking 8-wire serial instead of 3?). Using Windows is absolutely not an option here.

WDC's Github repository has TerminalPython, but it doesn't work for me, even after hacking on it to ignore 0xff that the post-utf8 world freaks out over.

EDIT: This thread is "how to get these working under Linux"-- don't waste time trying to make it something else if you don't know the answer.

[BitWise]

The 816SXB uses a FTDI FT245RL USB FIFO chip. It looks like a USB serial device to the host PC but appears to the '816 as two FIFO buffers (128 bytes RX, 256 bytes TX). Its not directly connected to the data or address bus but rather is driven the system VIA.

If you usurp the builtin firmware in the SXB you can use the FIFO for communication. I wrote the code for here ...

https://github.com/andrew-jacobs/w65c81 ... 816sxb.asm

.. in the conditional code section for USE_FIFO.

The 816 SXB uses a flash memory which can be self written and contains four 32K banks only one of which is used by the TIDE firmware. You could write a replacement ROM upload it into the flash using my hacker program then short TP2 and/or TP3 to ground select your code bank at reset. Then you can use the hardware any way you want.

[cjb]

BitWise wrote:

You could write a replacement ROM upload it into the flash using my hacker program [...]

You missed that I have no programmatic access to the board.

If it gets to the point of bothering with the Flash, I'd be dumping the firmware and reverse-engineering the protocol that TIDE uses-- which it doesn't seem like anyone has already done.

[BitWise]

What do you have access to? A flash eeprom programmer? An Arduino that could be used as a programmer? A virtual machine environment that could be used to run up a copy of windows?

[cjb]

Some progress on this to report...

I've successfully brute-forced what the protocol was [for z in range(256): for y in range(256): for x in range(256): ser.write(chr(x)+chr(y)+chr(z) ... and watching for responses], and determined the general command syntax:

command : <$55> <$AA> {listen for $CC} <command $00-$09> <payload>|{<response>}

The useful commands are 2 (memory write), 3 (memory read), and 5 (execute). There's also a command 4, which seems to report the board configuration in some undetermined format (...but it was how I discovered the protocol -- <$55>{listen}<$AA>{listen: got $CC}<$04>{listen: about 20 bytes came back}. After that, I deduced the memory read command, and then I got access to the 'SXB firmware!)

Command #2 - memory write - requires a payload of: <address low byte><address high byte><address bank><length low byte><length high byte><data ...>

Command #3 - memory read - requires a payload of: <address low byte><address high byte><address bank><length low byte><length high byte> {contents of memory in the specified range are returned}

Command #5 - execute - not completely understood at the moment, however it refers to register and cpu status in $7E00-$7E1F before doing the fake-RTI trick to call the code.

[cjb]

Success! https://imgur.com/a/Ds1hQDa

An alpha release of the sxb.py Python is attached.

>The extension py is not allowed.

Bite on this, phpBB

[BigEd]

"Hi there!" - and well done! (no attachment??)

[SpaceCoaster]

The sxb.py program works well, thanks.

I found a document which has this to say about the protocol...

Quote:

There are only 6 commands from the PC to the WDCDB board:
sync - (00) resync data port, send Sync byte ($00) to PC
echo - (01) Echo response
read_data_from_PC - (02) Read an Address (3 bytes), data block size (2 bytes),
Data write_data_to_PC - (03) Write
registers - (04) Setup pointer to internal Registers and send this to the host/PC
exec - (05) Execute code
noop - (06) Do nothing
noop - (07) Do nothing – (Future implementation– Send version & date)

In my disassembly of the WDCMON I found a jump table which handles 10 commands, with codes 0 through 9. Codes 6 and 7 definitely do nothing as they jump to an RTS. Codes 8 and 9 do more but it doesn't look like anything useful.

[BitWise]

Useful information.

I've written my own C# command line app that I can call from my batch and makefiles to download S28 files into my 816 SXB.

I think I might write a compatible firmware ROM for my ESP32 based emulator that implements the same protocol, I would make it easier to download and run test images.

[cjb]

SpaceCoaster wrote:

The sxb.py program works well, thanks.

I found a document which has this to say about the protocol... [...]

...that's where it was. >_>

It doesn't mention the structure for the payload used for CMD #4 set-internal-registers. From my own look at the dissembled wdcmon, it is maintained in $7E00-$7E0F and needs to be
initialized before exec.

Code: Select all

    procstate = [LO(areg), HI(areg),         # 0,1
                 LO(xreg), HI(xreg),         # 2,3
                 LO(yreg), HI(yreg),         # 4,5
                 LO(execaddr), HI(execaddr), # 6,7
                 LO(dpage), HI(dpage),       # 8,9
                 LO(stackp), HI(stackp),     # A,B
                 0,                          # C - cpu status register
                 cpumode,       # D - CPU mode (0=65816, 1=6502)
                 BA(execaddr),  # E - program bank register
                 0]             # F - data bank register
    writemem (32256, procstate)

[SpaceCoaster]

cjb wrote:

SpaceCoaster wrote:

The sxb.py program works well, thanks.

I found a document which has this to say about the protocol... [...]

...that's where it was. >_>

And still is, or am I not understanding your banter old chap.
While I have your attention. I think that sxb.py has a bug. The line

Code: Select all

execaddr = getargvals(sys.argv[1])-1 # "RTI trick", hence the -1

should be

Code: Select all

execaddr = getargvals(sys.argv[1]) # "RTI trick"

because RTI doesn't have the same offset in the stacked return address that RTS does. Anyway it works much better for me without the -1

Good call on the exec params. Do you know how the TIDE debugger manages to single step the processor on this board?

[BigEd]

(Just for future reference, that document is
User Manual for the W65cSDS Monitor (WDCMON) V1.04
Edit: now here.
)

[BitWise]

SpaceCoaster wrote:

Do you know how the TIDE debugger manages to single step the processor on this board?

I suspect that the host PC does all the hard work by placing a BRK opcode at the next instruction location and restoring the program afterwards.

[kalj]

I played around with the W65C02SXB over the last couple of weeks and wrote up my conclusions here:
viewtopic.php?f=4&t=6326&p=90392#p90392

[SpaceCoaster]

The 6502 world turns slowly and in that time the document has moved