I let mine go for 20 minutes, and the time was still updated. However in some cases I've had consistent crashes after a leaving a program running for awhile, unless I do an SEI first.

Thanks for that. I'm wondering if long term it wouldn't make more sense these days to add a hardware RTC and replace that code in the monitor, cutting down on the number of interrupts and freeing the timer.

So I've been experimenting with the GET_CHR routine of the Mensch Monitor for Liara Forth, and the thing is so ancient it is giving me second thoughts about using the monitor. ESC returns $1B, as you would expect from the ASCII, but so do the "arrow up" key, "arrow down", DEL, INS and Page Up (I stopped trying those after a while). Unicode this ain't.

To use GET_CHR as the base of a CLI, I'm going to have to go back to the Control-combinations (CTRL-c, CTRL-h, etc) like in Bash. I've started a list of those in Guide (https://github.com/scotws/265SXB-Guide/ ... monitor.md) to make it easier for people to use - these are keyboard shortcut, GET_CHR return, ASCII value, what it does: I'll add to it, but the short of it is that we'll probably want to create a new version of GET_CHR at some point.

Terminals like the VT100 etc. (and software emulations of them) return multiple characters starting with an ESC when you press the function and arrow keys. Could this be what you are seeing?

_________________
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

The VT100 terminal conforms to ANSI standard X3.64 (now ISO/IEC 6429), which defines control sequences that drive the display (such as positioning the cursor) and sequences emitted by the keyboard when a non-QWERTY key is struck, X3.64 is also substantially followed by most other members of the VT family, as well as MS-DOS, UNIX and Linux consoles.

In the case of the keyboard, as Andrew noted, striking a non-QWERTY key typically emits <ESC> followed by other ASCII characters. In order to correctly interpret the non-QWERTY keystroke there needs a way to detect the following keys after <ESC> is received. Usually, this is accomplished by briefly entering a timed loop and watching for another character. If no other character arrives before the loop terminates then you assume the user actually pressed the escape key. If one or more additional characters appear while the loop is being executed then the user pressed a control or function key, the terminal emitted something in response to an earlier command or line noise got you (the latter which shouldn't happen in a proper TIA-232 setup).

For example, suppose the user presses the cursor-right key. The terminal will emit $1B $5C $43 at a rate that is typically between 60 and 100 characters per second. Upon seeing the <ESC> ($1B) you would start the timed loop, which should time out in about 500 milliseconds. That interval is enough for any characters associated with the <ESC> to arrive—it is extremely unlikely the user could type fast enough to confuse your code. Anything received during the loop would be processed as a non-QWERTY keystroke, such as the aforementioned $1B $5C $43 sequence.

So you can see an "interpreter" has to sit between the program that is responding to typed input and the Mensch monitor's GET_CHR subroutine. This would be analogous to operating terminal line discipline in UNIX or Linux in canonical mode, as opposed to raw mode.

You need to track down the documentation for the VT100 so you know what to expect when the user types a non-QWERTY key. Also, read up on line discipline in UNIX or Linux to fully understand the concept.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Ah, that makes sense, thank you. I'll amend the Guide with a link to this discussion - though I think I'll be skipping anything that involves "timed loops" for the first iteration ...

I'm just going to plant my "...of my lawn" sign here and say that ANSI X3.64 conforms with the VT-100 .

If you ever use something like 'vi' on a unix box, or most any character UI that can accept a lone escape key, you may notice a slight pause when you hit the ESC, because the computer is waiting for the rest of the sequence. Since most Unix programs use the Curses (or NCurses) library, that's where you see this pause behavior.

In the end, save for 'vi', in most cases, a lone ESC is really the exception rather than a rule.

Not quite. X3.64 accounts for so-called private mode control sequences, which Digital Equipment (DEC) did not publish in their documentation prior to X3.64 (e.g., DECCKM was only known to developers who had signed non-disclosure agreements with DEC). Also, the original VT100 lacked a partial screen clearing mode (the CSI Ps J sequence, where Ps is 0 or 1) that was defined in X3.64. Subsequent to the ratification of X3.64, DEC released updated firmware for the VT100 to implement the mandatory X3.64 sequences. Hence VT100 conforming to X3.64 would be correct.


It would depend on the software. A primary use of the escape key in lots of software is to abort an operation. This persists to this day in quite a bit of Windows software, and in Windows itself. In my mechanical CAD program, which runs on Windows, the escape key is used to terminate various in-process tasks, a convention that dates back to the earliest MS-DOS version of Autocad.

This is also true for many of UNIX/Linux applications that run on character terminals (lots of this sort of software continues to be used all over the world). Such applications typically run the line discipline in raw mode and do their own internal interpretation of incoming keystrokes to figure out if the user struck a non-QWERTY key. Usually, the alarm() kernel call is used to time out a character get loop that is started after <ESC> has been detected. If the alarm goes off before another character is received, it is assumed that the user struck the escape key or Ctrl-[ (which generates $1B on many terminals). On the other hand, if one or more characters arrive before the alarm goes off they are buffered, rather than passing onward. When the alarm finally occurs, the buffered characters are analyzed to figure out the corresponding non-QWERTY keystroke. I've written plenty of this sort of stuff over the years and am quite familiar with how it works.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Looking some more at this chip, I figured I'd point out some details that are buried in the documentation.

First, notably is the parallel I/O ports. It has a lot of them, but there are caveats. Out of the box, it's a chip with 576 bytes of RAM and 8 I/O ports (among other things). Adding a 24K custom ROM should work out of the box, giving you a CPU with 24K of custom code plus the in built 8K monitor, and the inbuilt RAM. If you want more than that, you need to start trading out I/O ports.

P0, P1, and P3 do double duty as the Address Bus, with P3 being the high byte. Similarly, P2 is the Data Bus. So, if you're interfacing to external memory, you will certainly be losing some of the I/O ports. Perhaps a bit of a disappointment is that you can't use P0 and P1 for the Address Bus and P3 for a port if you only have < 64K of RAM.

So, anyway, interfacing to external RAM will eat 4 of the I/O ports.

P4 and P5 are multiplexed with the Parallel Interface Bus, which seem particularly undocumented. I simply don't know what that is. So, for most applications, these should be available for anything.

P6 is multiplexed with the 4 UARTs. Each UART has a Tx and Rx pin as part of Port 6. Also on P6 are TIN and TOUT. TIN "can be used for counting input negative pulses", TOUT can generated a square wave off of Timer 4. Not clear to me how one goes about counting the negative pulses, but apparently it can be doe. Note for the UARTs, you only have Tx and Rx available, there's no hardware handshaking at all.

P7 is multiplexed to the internal Chip Select logic. If you are using external memory, you will likely be using some of these CS pins.

It should be noted that with P6 and P7, you can individually assign roles to the pins. For example, if you want just one UART on P6, you can use the other 6 pins for I/O.

It seems you can readily take over the entire chip and turn it in to a "normal" '816 without any of the built in I/O. If you wanted a 16MB '816, you would get 2 I/O ports and 4 UARTs (along with timers and such) "for free".

It would be interesting to document the full startup sequence of this chip, including when and how it detects external ROM support. It's all in the monitor listing, but would still be nice to have a higher level diagram of it.

Adding a 32K RAM chip, or a up to 4MB of RAM to it looks particularly straight forward. Where added memory overlaps with internal areas, the chip select logic does the right thing based on how things are configured. There's a chip select for a 32K bank of RAM and overlaps with the lower 4MB bank of another chip select. If both are configured, then the 4MB won't be enabled if the CPU is using the 32K bank.

The documentation is pretty dense, so it takes some sussing out. I thought it would be useful to get a better idea of what the chip could do more at a glance.

Feel free to add this to the github wiki if you like.

Thank you for that, I can't say when I'll get to it - life is being very annoying in this regard at the moment, haven't coded in weeks - but will make a mental note for the wiki.

In addition to what whartung already figured out:

+ there are two sets of interrupt vector tables, one for emulation mode, and one for native mode. Beside RESET (only emu-mode), BRK, COP, NMI, ABORT, and IRQ vectors (like the 65C816) there are 8 separate interrupt vectors provided for each (4) UART (one Rx, one TX), all 8 timers have a separate IRQ vector, one for this ominous parallel interface bus (PIB), and 6 more for some edge detections on various pins. These vectors could be beneficial when writing irq-driven IO-handlers. The vectors are fixed priority encoded.

+ each UART Tx empty interrupt can programmable occur if just the data register is empty or data and shift registers are empty. The latter is useful when driving an RS-485 bus. You can disable the driver after the last character is transmitted w/o using an additional timer or something else.

+ the on-chip RAM is divided into two parts: 512 bytes from 00:0000 up to 00:01FF. This range can be disabled (register SSCRx @ $00:DF41, bit 2). The remaining 64 bytes are within the I/O-space ranging from 00:DF80..00:DFBF. These bytes seemed to be always ever available and on-chip only.

+ using CS5B to address a 4MB RAM (00:0000..3F:FFFF) can be overridden by CS3B to select a different 32KB RAM @ 00:0000..00:7FFF, but the lowest two pages are mapped to internal RAM unless its disabled! So there could be 3 different memories accessible from 00:0000..00:01FF and 2 different from 00:0200..00:7FFF. This may be useful as a separate "supervisor" storage, that could be swept in and out.

+ similar multiple memory is possible using CS4B and ROM enable (BCRx @ 00:DF40, bit 7). These 24KB + 8KB can be covered by CS5B as well.

+ there is one additional caveat using CS5B: during restart the ROM code (00:E109..) checks for a PCMCIA card with the "WDC" signature @ 00:8000 by using CS5B first! After that it checks for the signature again (same address) using CS4B. If there is RAM selected by CS5B it is highly unlikely that a signature would be found - but according to Murphy this will happen surely

+ there are two more memory regions preselected: CS0B (00:DF00..00:DF1F) (just enough for two VIAs) and CS1B (00:DFC0..00DFFF), 64 byte.

+ CS2B seems to have no real usage other than to indicate access to internal resources. It should be save using it as output only (all P7 is output only).

+ the SSCRx register (00:DF41) is used to define the accessing speed of various memory regions as well as to turn on/off a separate FCLK (Fast CLK) and the internal memory (s.a.). It is a bit unclear how the various possible settings are coexisting. But I assume setting bit 1 would cause all actions to slow down to CLK (which is usually a 32KHz clock), otherwise you can select individually the memory access speed for CS4B (00:8000..00:FFFF), CS5B (00:000..3F:FFFF), CS6B (40:0000..BF:FFFF), and CS7B (C0:0000..FF:FFFF) to run at FCLK or FCLK/4. The remaining memory can be clocked by FCLK or FCLK/4 depending on bit 3 of SSCRx. This might be helpful or necessary with additional I/O selected by e.g. CS0B or CS1B.

+ there are 8 timers each having 16 bit counters and 16 bit latches. The clock sources are dedicated (either FCLK or CLK) except for T4 (FCLK or Port 6 bit 0). Each have a separate IRQ vector. Each but T0 can be turned OFF and ON. T0 serves as a watchdog, once enabled you need to pet it otherwise it barks

+ there is astonishing much hardware spent for two tone generators TG0 and TG1. Each have a separate timer, can be en-/disabled, have individual pins (not usable otherwise), and they provide a 4 bit (16 level) analog output signal. The intended use was for generating DTMF tones (requiring low harmonics).

+ NMI can be disabled

- it is explicitly not recommended to enabled ABORT and NMI - they share the same pin. But both can be disabled.

- there are only two timers (T3, T4) as clock source for 4 UARTs. And if you wishes to use T4 for counting or frequency generating there is only T3 left for all UARTs.

- the capabilities of timer T4 collides with UART0: P6.0 is RxD0 or T(4)IN (pulse counting), P6.1 is TxD0 or T(4)OUT (pulse generating)

- the capabilities of T7 (edge latching/ PWM measurement) collides with UART1: P6.2 is RxD1 or PWM (input)

- all edge sensitive inputs have individual interrupts, but all of them are mapped to otherwise used ports. Only P5.6 (pos. edge) and P5.7 (neg. edge) can be used (assuming the PIB is not used).

- the PIB (peripheral interface bus) is most likely an 8 bit data (port 5), 3 bit address (P4.5 (PIRS0), P4.6 (PIRS1), P4.7 (PIRS2)), and 3 bit control (P4.4 (PICSB or PIRDB), P4.3 (PIWEB or PIWRB), P4.2 (PIIB) interface to an other computer. The documentation is difficult to understand. The other computer is called "Host", the W65 is called "Processor" during the description of the various bits in the enable and flag register. Most likely the "idea" is as follows:
-- the W65 appears as an 8 byte wide peripheral within the I/O-space of an other computer (the "host").
-- the host can read/write all registers by using the select lines (PIRS0..2) and PICSB/PIRDB/PIWEB/PIWRB. (How the latter are used correctly I still haven't figure out).
-- usually the host would place its data in the upper four registers (that corresponds to PIR4..7 (00:DF7C..7F)), writing to PIR7 could cause an IRQ to the W65.
-- usually the W65 would write into PIR2 and PIR3. The latter write could automatically trigger PIIB to interrupt the host.
-- the automatic handshake could be turned on/off through various settings in PIBER
I'm not sure what timing specifications are applicable to this "bus". But I assume it was designed to run on an 80x86 as I/O port. So with 8 MHz for the W65 an access to these registers from outside within 200 or 250 ns should work.
-- the interface is somehow "passive" - this means you cannot connect two PIBs together to exchange data between two W65. You would need to map W65(A) PIB into the memory of W65(B) and vice versa - pretty ugly but somehow interesting

Funny, looking in to this a bit deeper.

I was looking at the board schematic. And if you look at the schematic for the FT232 USB->UART chip, you'll notice that the FT232's TXD and RXD are wired to P66_RXD3 and P67_TXD3 pins on the MCU, which makes sense. However, right below that we have RTS# and CTS# wired to P57_DSRB3 and P56_DTRB3.

RTS/CTS are hardware handshaking.

The UARTs on the MCU itself do not support hardware handshaking.

The DSR and DTR bits are managed by the software in the built in Monitor. So, in this sense, the chip DOES support hardware handshaking, at least for one of the ports. Looking at the monitor, it seems to have dedicated Port 5 to hardware handshaking for the 4 UARTs on Port 6. (Actually, it looks like there might only be code for 2 or 3 of them.)

The monitor also supports XON/XOFF apparently.

The monitor was based on the Mensch computer monitor, there's lingering traces of other stuff, like a Sega game controller (little more than some equates and reset logic to a port).

So, this suggests that P4 is the only truly un-allocated port on the board out of the box (assuming you use the inbuilt monitor).

I had a bit of an "aha" moment here when I was digging through the monitor source.

I always basically assumed that the W65C265S MCU was simply an "'816 and some other stuff", but that's not the case. Specifically with regards to the interrupts.

The 816 interrupt vector table for Emulation Mode lie between 00FFF0 and 00FFFF, whereas for native mode, they lie 00FFE0 and 00FFEF. 8 bank zero addresses, some reserved.

The '265S, however, does not share these. The extra hardware on the 265 have dedicated hardware vectors (for example, all 4 UARTs have individual, dedicated send and receive vectors). The vector table for emulation mode on the '265S lie between 00FFC0 and 00FFFF, while native lie between 00FF80 and 00FFBF.

That means, at this trivial level, that a '816 program may not run "unchanged" on a '265S system.

For some reason, I simply assumed that the extra interrupts and what not were managed by the monitor, but the chip itself is managing all of this for you in hardware.



As mentioned in another thread, this is not the case. 2 bits of P4 are used to control the Flash socket on the board. (This is a board feature, not necessarily related to the actual MCU).

Speaking of this, I was a little confused looking at the schematic for the flash. The data sheet says the Flash is mapped to the upper half of the bank 0 64K, and I didn't understand how that worked, since A0-A14 are the only address lines wired to the chip.

Simply, the built in chip select logic handles all that. The 2 bits off of P4 allow you to bank in any of the 32K ranges from the 128K flash, thus making 4, 32K pages available. And there doesn't seem to be any reason to not be able to program the flash on board.

Scott and I put together some documentation for the 265SXB. The page on flash programming is here:

https://github.com/scotws/265SXB-Guide/blob/master/flash.md

_________________
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