W65C265SXB

[BitWise]

scotws wrote:

So this is weird.

In theory, like, following the manual and the schematic (http://www.westerndesigncenter.com/wdc/ ... 265SXB.pdf), clearing bit 3 of the Chips Select enable register (CS3B, pin 73) at 00:DF27 should enable the external 32k SRAM chip that is on the 265SXB and turn on the the little LED. In other words, because that RAM is enabled out of the box, that bit should already be clear and the LED on.

However, the monitor gives me a $FB (%1111 1011) at this address (bit 2 are the on-chip registers and whatnot, which is perfectly correct). In fact, when I clear CS3B by changing 00:DF27 to $F3, it seems to disable the 32k RAM. This would be the exact reverse of the documented behavior. No LED then, either.

Or am I missing something?

Setting a bit in PCS7 enables the associated chip select so when PCS7<3> is 1 the external RAM is enabled as it is the in default $FB setting.

Are you taking into account that the chip select lines are 'active low' e.g. a low output selects an address range.

Also if you turn a chip select off then you should ensure that the corresponding data register bit for the pin becomes a high output on the SXB board otherwise a memory chip could think it is always active.

[scotws]

BitWise wrote:

Setting a bit in PCS7 enables the associated chip select so when PCS7<3> is 1 the external RAM is enabled as it is the in default $FB setting.

So after going through the documention again - http://www.westerndesigncenter.com/wdc/ ... 5c265s.pdf on page 37/38 - let me walk through this to see if I understand it:

The chip selection is handled by Port 7, which is output only. Since it is not a bi-directional register, it doesn't have a data direction register (PDD) like the other ports, but (as the schematic on page 50 shows), an "enable register" called the Chip Select Register (PCS7 at 00:DF27). It also has a Data Register like the other ports (PD7 at 00:DF23).

Based on section 2.9.2 on page 37 and section 2.14 on page 38, a 0 bit in PCS7 means that the value in the Data Register will be output on the chip select line. For example, if PCS7<3> is "0", whatever is PD7<3> is what will be on the pin. In other words, in this mode, it's a simple output port for its data register. If there is a "1" in the PCS7, however, we turn that pin into a chip select line. At reset, the documentation claims, PCS7 is all "0" and PD7 is all "1".

However, after boot, I get $FB (%1111 1011) in the PCS7 at 00:DF27, which means that everything except bit 2 is set up as a chip select line. The data register for port 7 at 00:DF23 gives me $04 (%0000 0100). We only care about bit 2, because everything else is in the data register is blocked by the 1s in PCS. That 1 in bit 2 is what we see on the pin, and because we're "active low", it's making sure that we don't select something. And that is to make sure we use the on-chip "stuff" (as the Monitor code listing puts it) such as the on-chip ROM, on-chip interrupt vectors, etc.

Does that sound about right?

[BitWise]

scotws wrote:

The chip selection is handled by Port 7, which is output only. Since it is not a bi-directional register, it doesn't have a data direction register (PDD) like the other ports, but (as the schematic on page 50 shows), an "enable register" called the Chip Select Register (PCS7 at 00:DF27). It also has a Data Register like the other ports (PD7 at 00:DF23).

Based on section 2.9.2 on page 37 and section 2.14 on page 38, a 0 bit in PCS7 means that the value in the Data Register will be output on the chip select line. For example, if PCS7<3> is "0", whatever is PD7<3> is what will be on the pin. In other words, in this mode, it's a simple output port for its data register. If there is a "1" in the PCS7, however, we turn that pin into a chip select line. At reset, the documentation claims, PCS7 is all "0" and PD7 is all "1".

Correct

scotws wrote:

However, after boot, I get $FB (%1111 1011) in the PCS7 at 00:DF27, which means that everything except bit 2 is set up as a chip select line. The data register for port 7 at 00:DF23 gives me $04 (%0000 0100). We only care about bit 2, because everything else is in the data register is blocked by the 1s in PCS. That 1 in bit 2 is what we see on the pin, and because we're "active low", it's making sure that we don't select something. And that is to make sure we use the on-chip "stuff" (as the Monitor code listing puts it) such as the on-chip ROM, on-chip interrupt vectors, etc.

On reset the chip does reset PCS7 to $00 but the code in the Mensch ROM changes it to $FB when it examines the memory to look for a user program to execute.

Look at address $E14B in the '265 monitor listing. This is where the $FB value is set. The preceding code tries other values while it examines memory at $8000 and $0800 for the string "WDC".

[scotws]

Okay, so I've added that part to the Guide (https://github.com/scotws/265SXB-Guide/ ... /memory.md). Hope to get some simple "out of the box" examples next to get people started, somethink like the "blink LED" example from Rod Biresch (https://rodbiresch.wordpress.com/tag/w65c816/).

[BitWise]

I tweaked the SXB-Hacker disassembler to understand SEP/REP and changed the XMODEM transfer so that it does not overwrite the on-chip registers when downloading ROM images on the W65C265. This week's job is to build and release a new W65C816 version.

[scotws]

Added an Erratum page to the Guide for the Manual and the Mensch Monitor code (thanks, Andy!) at https://github.com/scotws/265SXB-Guide/ ... erratum.md . Also, TODO.txt file for suggestions of what else should go in the Guide.

[scotws]

COMPLETE REWRITE of this question, because I was up way too late watching the Superbowl in the wrong time zone and obviously am not thinking clearly: It states on the WDC website (http://wdc65xx.com/134_265_SXB-engineer ... ngstarted/) that you can write to the Flash memory when installed in socket:

Quote:

The FLASH can be written right in the socket or pre-programmed in a FLASH chip programmer.

However, a simple experiment with

Code: Select all

m 00:a000

and a bunch of bytes fails, and there are no routines I can find for this in the Mensch Monitor. Am I right that you can only program the Flash via the WDC Tools, which (cough) only work for Windows, not for Macs and Linux?

(And it wasn't even a great game, right?)

[BitWise]

You have to unlock the flash ROM by writing a series of values to specific locations before you can write a data byte. Also you can only write zeroes so you must erase all or part of the ROM (in 4K blocks) to fill it with $FF values before the write.

See here in my code:
https://github.com/andrew-jacobs/w65c26 ... r.asm#L790

The Mensch monitor expects to be writing to RAM.

Download my SXB-Hacker and give it a try. There is an S28 file here:
https://github.com/andrew-jacobs/w65c26 ... hacker.s28
Run from 00:0300

You will need a separate USB-Serial connector on UART0 or change the UART routines to use UART3.

[scotws]

BitWise wrote:

You will need a separate USB-Serial connector on UART0 or change the UART routines to use UART3.

That's on the next parts list. Thanks for the pointer on Flash - I'm loving the board but hating the documentation, or rather the almost complete lack of it.

[scotws]

Speaking of chip select lines and such, I notice that FA15 and FAMS are present in J3 connector attached to port 4. Shouldn't it be rather easy to attach LEDs (for example) to those pins to show which bank is in use?

[BitWise]

scotws wrote:

Speaking of chip select lines and such, I notice that FA15 and FAMS are present in J3 connector attached to port 4. Shouldn't it be rather easy to attach LEDs (for example) to those pins to show which bank is in use?

Yes. Just a LED and a load resister (220-470R or more depending how bright you like them)

FAMS/FA15 ----|>|-----\/\/\/---- GND

[scotws]

I've added a chapter on connecting serial lines to the UARTs of the 265SXB, especially with USB serial adapters (thanks, Andrew!) with two images to make it easier. The chapter is still missing the important part on how to set the baud rate, but I'll have to do a bit more digging around in source codes to figure out exactly how that works. We should probably add some code snippets for the most common cases (19200 8N1, methinks) to make it as easy as possible to access.

EDIT: Sorry, forgot link: https://github.com/scotws/265SXB-Guide/ ... l_lines.md

[scotws]

Added a new simple program to the Guide on how to blink the LED, and expanded the section about how the Port 7 output lines work to reflect that: It now explains why bit 2 of PCS7 and PD7 are treated differently. No more sleepless nights over that!

[scotws]

There is possibly an error in the Mensch Monitor Manual, or I am doing something wrong: The time-of-day clock doesn't seem to be updated during low-power mode after all. This is what it says in the manual (p. 43) about low-power mode:

Quote:

All interrupts will be disabled, excepting the time-of-day interrupt. When the time-of-day interrupt occurs, the clock will be updated.

However, if I set the clock with "t", then hit "x" to go into low-power mode, wait a few minutes, hit RESET to bring the machine back up, the time will still be there, but it also hasn't been updated. Can somebody else with a 268SXB confirm this behavior?

[scotws]

Added a (very general) page about timers and the clock to the Guide.