W65C265SXB vs W65C816SXB?

[porcupine]

My question is why anybody would buy the W65C816SXB for $199 when the W65C265SXB is available for $99, and from what I'm reading the latter has a full 65c816 compatible core and all the address and data lines and interrupts equivalent to an 816 are available anyways?

Am I right that the only significant difference is clockspeed? What am I missing in these datasheets?

For that matter, unless one needs PDIP format, is there any advantage to a pure 816 over the W65C265S? It looks to me like the 65c265 has the advantage of exposing all 24 address lines without having to futz with latches and demultiplexing D0-D7...

Or are there significant limitations I'm not getting about the microcontroller form? It looks like it can still address external memory and the like. The pre-programmed ROM maybe is a limitation?

[Dr Jefyll]

porcupine wrote:

Am I right that the only significant difference is clockspeed? [...] It looks to me like the 65c265 has the advantage of exposing all 24 address lines without having to futz with latches and demultiplexing D0-D7...

I'm with you. Except for the 8 MHz limitation, the '265 puts the '816 to shame! There are a TON of peripherals on chip -- and no need to deal with demultiplexing, as you say. It offers programmable chip selects, too.

Unfortunately the '265 datasheet is a disaster, or at least appears to be. Certainly its organization is far from what you'd wish for or expect. Maybe all the pertinent details are in there -- and configuring on-chip peripherals involves a LOT of detail -- but WDC does not have a good track record with documentation, and I'm not optimistic. I have a feeling you'd end up writing the much of datasheet yourself. Maybe someone with hands-on '265 experience can comment.

ETA: the datasheet also fails to convey the product's potential, IMO. The Key Features list on page 3 fails to mention the Parallel Interface Bus (PIB) -- an interface that can connect the '265 to the data bus of a host processor. The '265 can serve as an intelligent peripheral! It's also possible to connect multiple 265's in a "star" network, creating a high-integration multiprocessor system.

-- Jeff

[porcupine]

Interesting. And I'm glad it's not just my newbie inadequacies and the data sheet is actually incomprehensible to other people. Only my bits of familiarity with the 816 have made it tolerable.

On a side note: I'm currently writing a python class to communicate with the MENSCH Monitor on my SBX over USB serial, since I do not have Windows and don't intend on pirating and installing it just to run their Windows-only dev tools. Right now I have methods for connecting, interacting, pulling register state (into a python object), and doing the memory dump (converts SREC file into python byte array). I am now starting on the facility for writing memory. Once I have that plus the jump commands, should be possible to write a tool to upload and run code on the board from a Mac or Linux machine.

[Dr Jefyll]

And you own a 265 SBX, porcupine?

Maybe the '265 datasheet isn't all that bad. Let us know how you make out -- and don't hesitate to ask for help. To be honest, I have only browsed the datasheet. The things I notice most are the lack of a Table of Contents, and the heavy imbalance between prose (hardly any) and charts & tables (oodles). Maybe the document merely lacks polish -- who knows. The acid test is when a person tries to actually use it, searching for specific information as opposed to just browsing.

I didn't realize WDC offers two sets of boards -- the developer boards (suffix DB) and the Xxcelr8r Boards (suffix SXB). Each set has four members:

• 8-bit CPU ('C02)
• 8-bit microcontroller ('134)
• 16-bit CPU ('816)
• 16-bit microcontroller ('265)

making for a total of eight boards, as shown here on westerndesigncenter.com and I guess on wdc65xx.com as well.

-- Jeff

[porcupine]

Right, ok, sorry for the confusion, I have the W65C265SXB, not SBX. What terrible product naming.

I got mine ordered through Mouser.

The data sheet for both the board and the chip are really pretty terrible. They managed to make even the memory map hard to read. Sections for the board are just copy and pasted from that for the chip. And vice versa. It's difficult to tell which you're looking at at any moment. It's also full of very old copy... refers to 1980s computers (PC AT, Mac II, Apple II etc.) when talking about using its parallel bus interface, etc. And this despite the board itself being recent (it has a USB connector...).

As a regular microcontroller, I can't really see how the 265 can compete in this age of much cheaper and more powerful ARM Cortex, or even more odd things like Parallax Propeller, XScale, etc. _Except_ that I challenge you to find another MCU that can address 16MB of SRAM with a regular address/data bus. That's a unique feature. Most MCUs are ridiculously RAM starved, or else can only use their non-expandable internal memory or expand only via SPI memory. So there's some advantages to this chip. It's a kind of neat MPU/MCU hybrid that has to fit some niche.

But they should update or rewrite the manual. And hell, re-release this chip at a higher clock rate. Throw a few extra new registers in with the extra die-space that modern manufacturing could get them, and sell it to both 65xx hobbyists and engineers in the industry.

[porcupine]

A few victories for me and my newbie self with this board, feeling pretty pleased.

1. I have my Python-based monitor interface working nicely. It can upload, download, and run programs, as well as dump registers via the USB interface to the Mensch Monitor on the board.
2. Have a makefile running ca65 and assembling a simple program which uses one of the monitor routines to print a string back over the USB interface.
3. Have an external 512KB SRAM hooked up on a breadboard and successfully have my program uploading into and running out of the 3nd bank of memory, with CA65 producing 816 code which works properly in the upper address ranges.

[Dr Jefyll]

Sweet!

Since you're having so much fun, there's a chore you could help out with. Would you be willing to concoct a little test to determine whether the UARTs in the '265 have same bug as the WDC 65C51? Folks on the forum would like to know. Heck, as a '265 owner you'll probably be interested yourself!

I guess you have other stuff on your plate. Still, if my understanding is correct then the test won't be terribly complex. Although the 'c51 flaw pertains to interrupts, you won't need to create a complete body of code. You don't even have to connect the UART to anything! Even with no remote device connected, the flaw (summarized below) should be evident.

floobydust wrote:

Again, the Xmit bit is stuck on and enabling xmit interrupts will endlessly generate interrupts.

Does that sound like it might be up your alley? You'll find lots more detail just by doing a forum search for author Floobydust and specifying the keyword stuck. And he might respond personally if you had any questions -- he's the one who brought the matter to our attention (we appreciate that, FD!).

-- Jeff

ps: You're welcome! Always happy to contribute items to other people's To Do lists !!

[porcupine]

I'd be willing to try, but I'd need some sample code.

[porcupine]

When I run the following:

Code: Select all

send_cr := $00e066
siostat := $00df70
siodat :=  $00df71

cout:
	pha

coutl:
	jsl send_cr
	lda siostat
	and #$10
	beq coutl
	pla
	sta siodat
	rtl

I get infinite scroll, implying I guess that siostat is remaining stuck?

But I could be missing something on that thread and my 6502 coding is n00b.

[Dr Jefyll]

You're using jsl send_cr to call a routine in the WDC firmware, is that right? What does their doc say about the routine, and about siodat & siostat? Can you post the doc, or a link, please?

[porcupine]

send_cr is at address 00:E066 in the monitor firmware, and just sends a CR on serial device #3, which is attached to the USB-Serial adapter. So a way of me confirming that that's in a loop.

siostat is 00:DF70, "ACSRO UART 0 Control/Status Register". The label I gave it is just because the forum thread I read here used that in its code.
siodat is 00:DF71, "ARTD0 UART 0 Data Register"

From the Mensch Monitor docs:

Quote:

SEND_CR ($00:E066)
DESCRIPTION:
This subroutine will output a CR (Carriage-Return/Enter = $0D) character to the serial console
output port #3. Refer to Appendix C - Mensch Monitor Assembly Listing for specific details
regarding the internal operation of the SEND_CR subroutine.
EXPECTS:
No input arguments.
RETURNS:
The carry-bit will always be clear upon completion.
ERRORS:
No errors reported

So shouldn't be messing with any register contents, or stack, AFAIK.

[Dr Jefyll]

Okay, thanks. Looking more closely at your code I notice two possible issues.

Code: Select all

send_cr := $00e066
siostat := $00df70
siodat :=  $00df71

cout:
   pha

;coutl:                ; I commented out this label -- see below
   jsl send_cr
coutl:                 ; Isn't THIS where you wanna loop to when siostat isn't ready?
   lda siostat  ; <--- does this inst'n need to use Absolute Long address mode?
   and #$10
   beq coutl
   pla
   sta siodat   ; <--- does this inst'n need to use Absolute Long address mode?
   rtl

Looks like maybe a simple error about the loop. Or maybe I've mistaken your intention.

I mention the Absolute Long address mode because I'm unsure. Does the assembler "know" to use that mode automatically? Somehow we need to render siostat into a 24-bit address. If the CPU's DBR register contains 0 (the high 8 bits) then it's OK to use Absolute mode (which supplies the low 16 bits). But if DBR is unknown then we need to use Absolute Long mode (which supplies all 24 bits).

Why did you PLA -- what is it that gets recovered? Later I'll ask more about the firmware. (Can you examine send_cr ? Do you have a disassembler?) But this is enough for now!

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

Okay, thanks. Looking more closely at your code I notice two possible issues.

Code: Select all

send_cr := $00e066
siostat := $00df70
siodat :=  $00df71

cout:
   pha

;coutl:                ; I commented out this label -- see below
   jsl send_cr
coutl:                 ; Isn't THIS where you wanna loop to when siostat isn't ready?
   lda siostat  ; <--- does this inst'n need to use Absolute Long address mode?
   and #$10
   beq coutl
   pla
   sta siodat   ; <--- does this inst'n need to use Absolute Long address mode?
   rtl

Looks like maybe a simple error about the loop. Or maybe I've mistaken your intention.

I concur. Jeff moved the coutl label to the right place.

Quote:

I mention the Absolute Long address mode because I'm unsure. Does the assembler "know" to use that mode automatically? Somehow we need to render siostat into a 24-bit address. If the CPU's DBR register contains 0 (the high 8 bits) then it's OK to use Absolute mode (which supplies the low 16 bits). But if DBR is unknown then we need to use Absolute Long mode (which supplies all 24 bits).

Good catch. Unless the lda siostat instruction is written to force 24 bit addressing, whatever happens to be in DB will be where the '816 will go looking for siostat—and it won't necessarily be $00. The assembler is not aware of what is in DB, as that is a run-time condition. Hence the programmer has to be explicit about it.

[porcupine]

Thanks guys.

I had the send_cr in the loop because if I understand the potential issue with the Xmit bug, it gets 'stuck' because the clear condition never clears off the register and the loop never exits. This was my way of measuring that, outputting the CR so I can 'see' that it's sitting in that condition.

Still learning my addressing modes. It's been a long time (uh, 30 years) since I wrote 6502, and I was 10 then, writing rudimentary machine code on a VIC-20. The last assembler I used recently was ARM, an entirely different beast.

Also the fragment there was just my attempt at re-using the code from the forum thread about this at: viewtopic.php?f=4&t=2543&start=30#p29001

[porcupine]

Here's my complete updated listing, using 'far' addressing for the LDA.
I hope I'm mistaken and my code is simply wrong, but it seems like the ACIA on the 65265 suffers from the same defect as the 6551 chip.

Code: Select all

put_str := $00e04e
dumpregs := $00e00f

send_cr := $00e066
acsr0 := $00df70 		; UART 0 Control/Status register
artd0 :=  $00df71		; UART 0 Data register
	
.p816	
.setcpu "65816"			; The 65c265 is like an 816.
.a8				; For our call we need an 8-bit accumulator
.i16				; And 16-bit X register.
	
.code

	;; 	Say hello.
start:
	jsl	send_cr
	
	lda	#^hstring
	
	ldx	#.loword(hstring)
	jsl	put_str

	jsl	send_cr

	;; 	Output 'B' on UART 0, to test if 'Xmit' bug is present.
	lda	#66		
	jmp	cout

	brk

	;; 	Routine to output a single byte (held in A) to UART0
	;; 	From what I've read this gets stuck in a loop because the 6551
	;; 	keeps the XMit bit 'stuck' on.
	;;      See: http://forum.6502.org/viewtopic.php?f=4&t=2543&start=30#p29001
	
cout:	pha
coutl:	lda f:acsr0
	and #$10
	beq coutl
	pla
	sta f:artd0
	rtl


.rodata
	
hstring:	 .asciiz "hello, world, from .rodata!"

.bss
	
.end