W65C816SXB behaving strangely on access to memory above FFFF

[SamSkivington]

Hello. I'm new here.

I've recently purchased a W65C816SXB board and have very quickly run into something I wasn't expecting.

When I try to LDA from address $01:0000 or higher the debugger says I've hit a BRK and moves my PC elsewhere, to a block of seemingly random bytes outside the range of my code. The first three lines of my code are this:

Code: Select all

	clc
	xce
	lda	>$10000

If I STA instead of LDA the debugger happily moves to the next instruction.

There is nothing connected to the board apart from USB.

I've read elsewhere here that "The 816SXB resets when you access unimplemented memory areas". I've looked over the schematic on the WDC site and can't see anything obvious in it that might cause that to happen. I've also disassembled the internal ROM and can't see anything in that either, so I'm thinking it has to be a hardware issue. I'm sure I've missed something in either the schematic or CPU datasheet (or both), so I'm wondering:

1. How/why is this happening?
2. Can I prevent it from happening?

Appreciate any light someone could shed on this.

Thanks.

[BitWise]

I mentioned this to WDC and they have looked into it. The problem is that the 8 input NOR gate (U15 CD4078B) they use to detect bank 0 is too slow (~150nS).

When memory accesses change bank the signal updates too slowly for the memory chips to be correctly selected so the CPU is effectively fed a random instruction when it tries to read an instruction from bank 0 following a read or write to another bank. I suspect that it often reads a BRK instead of the real instruction.

If you only ever access bank 0 then the state of the gate never changes and rest of the address decoding works within the timing limits.

[GARTHWILSON]

Welcome, SamSkivington!

That's incredible that they would have used a CD4000-series IC!! Could it be replaced with a 74HC4078? (I don't know if there's a 4078 in any faster family.)

[Chromatix]

I'm pretty sure that would work, if you can actually find one. Note that it's listed as obsolete and out of stock. A more immediate solution might be to use a slower clock, allowing the CD4078B time to catch up.

The original CD4078B part, conversely, is still stocked at Mouser from multiple manufacturers, and so are many different versions of the 74x30 8-input NAND (including 74AHC family). The discrete logic market is more than a little bit strange.

If there is room to fit a bodge daughterboard, you can of course construct an 8-NOR from either four 2-NORs and a 4-AND, or three 3-NORs and a 3-AND, or using an octal comparator, or by programming a 16V8 and merely adapting the pinout.

[rwiker]

Unicorn Electronics appear to have the 74HC4078 in stock: http://www.unicornelectronics.com/IC/74HC.html

[BitWise]

WDCs board uses a tiny TSSOP package -- Its the one in the green ring.

I don't think many people have ever designed an XBUS extension for SXB boards or this problem would have been found years ago. My memory expansion for the 265SXB doesn't have this problem as the chip provides the extra address lines and chip selects directly without any extra glue logic.

[Dr Jefyll]

GARTHWILSON wrote:

That's incredible that they would have used a CD4000-series IC!!

It's pretty astonishing, alright.

On the subject of a faster equivalent, 'HC4078 is the obvious choice -- or an arrangement of multiple gates, as Chromatix suggested.

This is a good time to remind everyone that such an arrangement needn't be slow. Most 1G ("one gate") series gates have a maximum propagation delay of 3 ns or less, meaning you can cascade a set of three 3-input gates into another 3-input gate and build a 9-input OR or NOR that comes in at 6 ns or less.

I posted more info (including a Selection Guide) a few years back here on Anycpu.org.

-- Jeff

[SamSkivington]

Thank you everyone. That answered my question and much, much more.

Certainly seems like a bit of an oversight. No QA on these things? Anyway, maybe a 265SXB required for what I wanted to try.

[Ernst64]

Reading the documentation and looking at the schematics, it seems there is additional setting needed to make the upper banks available. The pins CA2 and CB2 of VIA2 are connected to the flash rom upper memory address lines A15 and A16. In the schematic they are called FAMS and FA15.
Did you try to set these lines?
(I am waiting for my board to be delivered, so I can't try myself and validate my statement.)

-- Ernst

[Chromatix]

Those would just page a different section of the ROM into the same address range.

[BitWise]

Ernst64 wrote:

Reading the documentation and looking at the schematics, it seems there is additional setting needed to make the upper banks available. The pins CA2 and CB2 of VIA2 are connected to the flash rom upper memory address lines A15 and A16. In the schematic they are called FAMS and FA15.
Did you try to set these lines?
(I am waiting for my board to be delivered, so I can't try myself and validate my statement.)

-- Ernst

I do this in my 816 hacker

Code: Select all

   280                        ;===============================================================================
   281                        ; ROM Bank Selection
   282                        ;-------------------------------------------------------------------------------
   283                        
   284                        ; Select the flash ROM bank indicated by the two low order bits of A. The pins
   285                        ; should be set to inputs when a hi bit is needed and a low output for a lo bit.
   286                        
   287                                        public RomSelect
   288                        RomSelect:
   289 00:007F: 08                           php				; Ensure 8-bit A
   290                                        short_a
+  290 00:0080: E2 20                        sep     #M_FLAG
+  290                                        longa   off
   291 00:0082: 6A           		ror	a			; Shift out bit 0
   292 00:0083: 08           		php				; .. and save
   293 00:0084: 6A           		ror	a			; Shift out bit 1
   294 00:0085: A9 00        		lda	#0			; Work out pattern
   295 00:0087: B0 02        		bcs	$+4
   296 00:0089: 09 C0        		ora	#%11000000
   297 00:008B: 28           		plp
   298 00:008C: B0 02        		bcs	$+4
   299 00:008E: 09 0C        		ora	#%00001100
   300 00:0090: 8D EC 7F     		sta	VIA2_PCR		; And set
  Mon Nov 23 2020 23:19                                                                                                    Page 10


   301 00:0093: 28           		plp		
   302 00:0094: 60                           rts                             ; Done
   303                        

[SpaceCoaster]

On the Rev C. W65C816SXB boards the 8 input NOR gate has been replaced with a 3K resistor (R23) pulling up to 5V. The BANK0 signal is then provided on the XBUS pin 38, replacing XC3SB. This allows/requires any external expansion to pull BANK0 down when it wants to disable the onboard RAM/ROM and devices.

I suppose this would be a reasonable mod to the Rev B. board. Remove U15 and cut the track for XBUS pin 38 and wire the BANK0 signal to pin 38. Oh don't forget the 3K pull-up, otherwise nothing will work.

The Rev C. schematic has a December 15 2020 date. Just after this conversation started.

[tmr4]

SpaceCoaster wrote:

The Rev C. schematic has a December 15 2020 date.

Does anyone know if the boards being sold now are all Rev C? None of the sites I looked at specify, including WDC, but all had images of the Rev B board.

[Dr Jefyll]

I don't know the answer. But is it the Rev C board you prefer? If so, and you end up with a Rev B instead, you could follow Spacecoaster's suggested mod procedure to create your own Rev C -- it doesn't sound too difficult.

-- Jeff

[SpaceCoaster]

The XC3SB LED comes on when XC3SB is low. As this signal is stolen for this hack the LED is has no real use.

Extending the "mod".

The connection for the XC3SB LED is on pin 12 of U10 via R14 and is ideally placed, being near XUSB pin 38, to use as a ~BANK0 LED.
This LED is connected to +5V and turns on when pin12 is pulled low.
The LED might also work as the pull-up or maybe the diode part of the LED messes with that.

Tempted to get out the microscope, heat gun and Xacto knife. I guess I really need to put the RAM expansion board together first...