Hi folks!

while waiting for the board to arrive and reading some of the documentation and forum posts, I tried to figure out how to wire a SRAM chip to the W65C265SQXB.

There is one question though I couldn't figure out from the data sheet where it says:



Does anybody know if the default power-up sequence enables emulation?

As of my current understanding, keeping the RESB button pressed/depressed during power-up should alternate between these modes, but the information I've read so far does not give a conclusive answer on that.

The schematics in the attachment show the approach I am planning to take to wire a CY62256NLL-70PXC SRAM chip to the W65C265SQXB.

What do you think, could it work that way?

Regards.

The RUN pin and Emulation mode is muddy. It seems to be that in Emulation Mode, the MCU parrots the internal address and data bus out to the pins described.

Out of the box, in default state, the CPU runs entirely self contained. So, for example, when it's accessing internal RAM or talking to the internal ports, nothing is seen "outside" the chip.

In it default state, the 256S has 8 Parallel ports. But, as soon as you start going outside the chip, that is interfacing hardware to the assorted CPU buses rather than the ports, the majority of those start vanishing. P0, P1, P2, and P3 are consumed by the Address and Data bus. P0 and P1 are the lower 16bits of the address bus, P2 is the data bus, and P3 is 17-24 of the address bus. Unlike the '816, the '256S breaks out all 24 bits of the address bus. But at the cost of 4 of the ports.

But during Emulation mode (which is what the RUN pin governs), it seems from the documentation that when it is accessing the internal parts of the MCU, those signals are ALSO brought out to be readable on these ports.

However, it's not going to be trying to READ from those ports (notably the data bus). Of course, when it's talking to external components, it doesn't need to parrot the internal state for monitoring -- the values are there naturally.

Mind, this is just a guess, as I don't have any experience with In Circuit Emulation (ICE).

If you're not using ICE, then you can ignore the RUN pin, and that entire bit about that startup sequence. However, this is also how you enable the external ROM at startup, so it's a bit confusing. Ideally the MCU will start up with the ROM enabled, and the ROM will quickly shut down the Emulation Mode before it even starts accessing the internal memories of the system.

In truth, though the MCU is really designed to start from the internal ROM, look for an external reference (which can be a ROM, but on the 256SXB board is a Flash chip), and if it sees the signature it's looking for, it'll just short circuit to that and let it finish it continue the boot process.

It you just tie the BE/RDY pin high, it'll start up in the default mode with the internal ROM.

Now, all that said. There's your schematic.

Here's the problem with that.

I feel they did a real disservice to folks on the QXB board by dedicating Port 7 to the on board LEDs. It's all handy and nice and blinky, but the problem is that the MCU has a whole bunch of very nice Chip Select logic built it to it, and all of those Chip Select lines are on...Port 7. I think they could have "sacrificed" Port 5 for use with the blinky lights and expose the CS lines to the header. Port 5 is for the "Parallel Interface Bus" which, frankly, I'm not quite clear what that's for or how it would be used. So in MY Pooh Brain, I'd rather "lose" that than the CS logic. Exposing the CS logic would have made the QXB much more expandable.

But as is, out of the box, it's a bit of self contained island.

Now, for the RAM expansion.

In theory, tying P17 (which is A15 from the CPU), will work, since it's a /CE pin, meaning when A15 is low, the chip is enabled. And that's the case for the lower 32K of RAM (the upper 32K is dedicated to ROM).

So, that part of the decoding should work.

However, you will need to set the bit in disable P7 (the port) and then enable CS3B by hand to turn the RAM on. You'll also have to enable P0, P1, and P2 to act at the Address and Data buses. If you don't turn on CS3B, the chip won't publish the signals out to the chip. Normally, you would tie the CS03 pin to the /CE pin, so the CPU could turn it on for you. But in this case, you're using the address line directly. (This is good, that means you don't have to de-solder an LED to add the 32K of RAM.)

But it does mean that whenever you start up the board, you'll need to hop in to the monitor, and change couple of values to light up the RAM.

Were you hoping to use the ICE mode to do this? That MIGHT work, but I can't say. I really have no idea. I just speculate that you probably just don't want to do that, as it's not clear to me that it would even use those pins except when talking to the internal components.

I agree with wartung about the use of the chip select pins to drive the LEDs. It would have been better to route at least one (/CS7) to an easy accessible pin.

I have only had success using /CS7 to drive external RAM. My 1MB SRAM card routes all the CS lines to the PLD but only CS7 works at the moment. I think its just a problem with the configuration register for the chip selects but haven't had time to stick a logic analyser on it and watch the signals.

In your schematic you can remove the inverter feed /OE and just connect it to GND. The SRAM chip will normally only output when its chip select is active and /WE is high.

You'll have to solder a wire to the correct side of one of the LEDs to get the CS signal or you could try using a high bit from the address bus.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

Hi whartung and thank you very much for the detailed feedback.

That clarified a lot for me.

I agree that hardwiring port 7 to the LEDs causes some trouble. The only advantage I can think of is having them as chip select indicators when not used for blinky output stuff. I suppose setting port 7 to #$00 and then setting bit CS3B of the chip select register should light up LED3 right?

I am not sure about port 3 though ... enabling bit CS3B gives me an address space below the $8000 boundary ... so port 3 address bits won't be necessary and I would hope to be able to use them as normal outputs.

EDIT: I realized that none of the port 3 pins is broken out anyway ... so that makes the concern above pointless.

Is it necessary to explicitely set the data direction bits for port 0 and 1 for output?

Or will the CS3B and BCR0 imply this configuration. Same question for the data port, which could either be input or output depending if writing or reading from SRAM.

Having to do this setup manually each time the board powers up won't be a problem while getting started.

During this period it will be likely accessing the monitor rather frequently. One thought to get around this would be an external ROM with custom entry point and startup routine or just an auxiliary PIC microcontroller poking the commands into the monitor via UART3 ... even not being the most elegant solution I presume

Regards.

Hi BitWise!

Thanks for contributing your thoughts.

As of the /OE pin I am not sure if it could be tied to GND. Following some conversations on the Cypress forum people stated the existing of a specific timing procedure where /OE has to go HIGH before /WE goes LOW. Probably I'll test the RAM access first with my Arduino UNO board once the chip arrives.

Concerning the /CE (chip enable) which is active LOW in the case of this cypress chip it should be OK using the LOW A15 pin when accessing SRAM below $8000 ... as long as the theory proves right.

You wrote that you wired an 1MB SRAM to your board. This sparked an idea which I hadn't thought of before, since I thought address range starting at $8000 and above would be reserved for ROM.

But now I think it could be either right? Then what if we connect say a 64KB NVSRAM covering the whole range $0000-$FFFF. Then I could store "WDC" at $8000 following some startup code and it should automatically be recognized during the startup sequence ... right?

Regards.

For the RAM I would wire the /CE pin to ground and the /OE to A15 unless power consumption was a huge concern. The SRAM only draws about 25mA.

The propagation delay from asserting /CE to valid I/O is more than twice as long as it is from asserting /OE - this is always a good thing. As well you will avoid one more source of glitches by not powering the chip on and off all the time.


According to the datasheet (and that of every other SRAM I have used) the state of /OE is immaterial when /WE is asserted low. Also, according to the way you have it in your schematic /WE would actually go low before /OE went high.

_________________
Bill

So, looked at this some more.

First, turns out that the default monitor on reset essentially lights up all of the CS lines (save CS2B). So, that saves you from having to do anything.

The monitor, first, lights up CS5B, which is the CS for the entirety of the first 4MB of memory, and it does it's check for WDC and 00:8000.

Then, if that fails, it will light up CS4B, which is the CS for the upper 32K of memory, and check 00:8000 again.

If that fails, it turns on CS3B, for the lower 32K, and looks at 00:0800.

If all of those fail, it will, eventually, turn on all of the CS line but CS2B.

Now, CS3B and CS5B overlap. Both cover the same lower 32K of memory.

But, the MCU has an internal hierarchy of memory control, and only lights up the CS line if it actually is necessary, and not overridden by something else.

For example, the internal RAM is prioritized over the CS3B memory. I assume that the CS3B memory is prioritized over the CS5B memory. So, if you try to access 00:0800 with both CS3B and CS5B enabled, only CS3B will actually light up.

It would seem to me, that out of the box, with the monitor, were you to wire up that 32K RAM chip, using P17 as for /CE, it should Just Work, and you should see the CS3B LED light up any time you try to access that memory. And that's good, because it makes wiring that up really simple giving you a useful 32K RAM device with a monitor. When I first looked at the board, I thought adding the 32K would be a lot more difficult.

What's not clear to me, and maybe someone can play with it and see, is what happens if you just have the BCR0 enabled, what do you see on the external Address and Data bus lines? Specifically, if you DO NOT have the appropriate CS bits enabled, will you see anything at all? Or just signals when not referring to internal system. So, if, out of the box, you shut down all of the CS bits, enable BCR0 (turning the buses on), and try to reference, say, 00:0800, does that light up the address bus? Or is it dark?

According to the DS (WDC W65C265S-2125.PDF) section 2.10 and 2.11 you will see action on the address and data buses if BCR0 == 1 AND (!) you are not accessing internal RAM (SSCR2 == 0) or internal ROM (BCR7 == 0). If BCR3 is set you will see addresses and data of internal accesses as well ("In Circuit Emulation" enabled).

Port 7 can be used as a source for /CS signals but you may omit using P7. Then of course there could be the risk of bus contention if you have BCR3 set and accessing some internal resource. The buses will reflect that access (ICE enabled) but your external memory or what else may respond to the address as well - ZAP

Using P7 as the source for /CSx such a conflict should not occur.

This is how I decipher the DS - I did not test that.

EDIT(1): If I understand the schematic /RESET has drawn correctly, A15 is used as /CS for the external RAM. That would map the RAM to the lower 32K of every bank. That should work if BCR3 is cleared. Otherwise access to the internal RAM may cause trouble.
When I turn on my 265SXB a read of 00:DF40..00:DF4F reports: 01 | FB | B0 | 1A | 18 | 36 | 02 | 00 | 00 | C0 | 00 | 00 | 00 | 00 | 00 | 00
This means BCR3 is reset.

Yea, it's pretty clear things would get messy if you enable ICE.

It makes sense that the CS lines are optional. They're a convenience for the designer.

It's clear, I think, that if the internal stuff is enabled, those accesses won't be exposed to the external buses save in ICE mode. I think if you're aggressive enough with the configuration flags, you can pretty well turn this thing into a '816 that comes with the 24b address bus decoded "for free", at the expense of some fiddly reset start up logic (The BE pin get flagged after the RESET pin).

It's good to see that it's pretty easy to expand that little board to 32K.

Using a 128K RAM (/CS and /OE grounded) would give 56K (-1/2K if internal RAM is enabled), but that RAM could be accessed at banks other than zero.
This would as well true for the region 00:E000..00:FFFF. You could prepare an own monitor and own vector addresses by writing to 01:Exxx..01:FFFF and then turn off the internal ROM

That's actually pretty clever. I guess you could just write to bank 01:, to the RAM "behind" the ROM, then disable the ROM.

The trick there would be to put the WDC signature at xx:0800, and then reset the chip. The monitor should then pick it up and call your start up routine.

I haven't looked at the monitor to see how well suited it is to "partial startup".

That is, isolating the "fire up the Serial Ports and interrupts" from the rest of the monitor so your start up routine could leverage that stuff. Because once you take over, you're responsible pretty much for everything.

@ GaBuZoMeu

Sorry, but I can't follow your thoughts about wiring up a 128K chip ... how the upper 64K would be addressable via the broken out pins A0 to A15?

If you look at the schematics at page 7 in the data sheet (https://www.mouser.com/datasheet/2/436/W65C265QBX_Datasheet_20170408-1100556.pdf) it shows that leads A16 to A23 are left disconnected.

Regards.

I think the premise is not that you can get to the extra 64K, but simply that a 128K chip gives you all of the lower 64K (minus 8K) easily.

Basically, by replacing the 32K chip with a 128K you get 64K just as easily as you can get 32K.

I honestly don't know if there's a 64K RAM chip out there or not, or I guess you could just use that instead.

The point about it being addressable via the other banks is that since you don't decode for banks, the RAM is available on "all" banks, save those that the CPU blocks you out of.

That's why the RAM is available in, say, bank 1, but not bank 0 (as the ROM decodes to bank zero, but not the other ones). Since the ROM is internal, and the internal signals aren't exposed, there's no conflict between the ROM and RAM in bank 0, the ROM wins.

So, you can move memory to 01:XXXX, accessing the entirety of the 64K, including copying over what's normally ROM. Then, you can tell the CPU to ignore the ROM and "suddenly" your RAM is there to map in to what was once ROM, letting you experiment with what it would be like to have a completely custom ROM for the device.

And you get all that simply by wiring up a 128K chip in the same way you wire up a 32K. You just "always" enable the chip, and tie up the 16 bits of the address bus.

@ /RESET
whartung already explains how it works. And yes, 128K x 8Bit is common, 64K x 8bit don't exist AFAIK.

Good Luck!

@ whartung & GaBuZoMeu

Ok, we are fooling the address logic of the chip ... when trying to access 00:E000 the chip thinks is its internal ROM area and thus it doesn't drive the external address or data bus and handles everything internally. But when we access 01:E000 the chip thinks we access the RAM above 64K and drives the external address and data bus letting us read/write the area which otherwise would be hidden to us.

Since we only use 16 address lines, any address above 00:FFFF will roll over to the lower 64K, what means it doesn't matter if we would use 01:Exxx, 04:Exxx or 08:Exxx any bank except 00 will have the same effect, right?

Regards.