Mickey Mouse logic, address decoding, power management, etc.

[No True Scotsman]

GARTHWILSON wrote:

What's the maximum amount of current you anticipate your circuit taking?

That would be hard to nail down, given that a hobby computer system is prone to grow over time. I have numerous ideas for peripheral devices that will attach to it. Not all at once, but in various combinations.

The intended final product is more easily defined. It will be a battery-powered portable with a dual UART and either a dual DAC or an SAA1099 stereo sound chip. Either audio option will have op amp output buffers, LPFs, and LM386 amplifiers per channel.

Co-located within the portable's case will be a serial terminal composed of an ESP386, one or two MPC23017 port expanders to scan a keyboard matrix and rotary encoders, and an SPI non-touchscreen TFT display with micro SD slot. On startup, the 65C02 system will connect to the onboard terminal through one of the UARTs. The other UART will likely have an FTDI adapter (either pluggable or permanently attached) to connect a desktop terminal. The screen I have on hand at the moment is a 4-inch 320x240 TFT, but I'm really shooting for a 7 to 10 inch screen with a wide aspect ratio in the final product. I want to achieve an 80x25 character display in a font that's large enough for me to read comfortably.

Beyond just building a portable computer, I envision an ecosystem to support it that will include both local and online services. The device won't be "always connected" in the way a smartphone is. Rather, the ESP32's WiFi capabilities will be used to connect to a simple Telnet BBS running on my desktop computer at home. The BBS will initially be a simple remote file storage system, but will evolve over time to provide other services, such as an IMAP/SMTP proxy. It may even become a full multi-user BBS at some point.

The overall aesthetic of the text-mode user interface will be influenced by dialup BBS design, which may help explain the design strategy. Data sent from the 65C02 to the terminal display will be parsed for ANSI escape sequences, which will be translated into commands to the TFT driver, e.g., to set text foreground and background colors, move the cursor, and delete things. Said driver also has codepage 437 support, which makes it perfect for this application. As you'd expect, data from the BBS will be likewise marked up with ANSI sequences.

Long story short, I intend to integrate local programs and online services in a cohesive environment that has an old school BBS look and feel. Nerds gonna nerd. ¯\(ツ)/¯

None of which answers your question about expected maximum current. I'll have to go through the datasheets to get an idea of that, but I don't suspect it will be very much. The Model 100 ran for 20 hours on 4 AA batteries, and it had a lot more chips in it than this one will have. The ESP32 has its own sleep modes and other power management features. An inactivity timer can be used to dim the TFT backlight. I may be able to employ one of the halt/resume methods discussed in this thread, with the ESP32 halting the 65C02 or its clock during user inactivity.

I'm not really that worried about battery life. The expectation is that the system will (almost) instantly boot into a usable state like the Model 100, and that it will automagically preserve user data when powered off - again like the Model 100. In other words, it'll be turned off when not in use for more than a few minutes, and it'll pick up where the user left off when turned on again.

So here's the startup sequence. The ESP32 runs its setup function, e.g., opens a serial port and wakes up the 65C02. It then enters a loop in which it polls the serial port and keyboard. The 65C02 boots, connects to the terminal, and requests that the saved user session (or a main menu, command prompt, BASIC, etc., by default) be read from the SD card and sent over the serial connection.

User data will be preserved through frequent automatic file saves, which includes saving a session variable file that can be used to reconstruct the environment.

I'm going to have to invent an in-band signaling protocol to coordinate the WiFi, SD card drive, and ANSI terminal over a single TTY connection, which should be fun.

Well, that isn't what you asked me, but perhaps this project overview will provide needed context for any further musings or questions I may have.

[GARTHWILSON]

In that case, you might find that you don't even need to power down, if using the W65C02S's SToP or WAIt instruction will bring the dormant power requirement down to a negligible level, assuming all loads are CMOS and take only a teensy leakage current when logic states aren't changing.  That would also mean the computer could wake itself up to handle a job without human intervention when a timer says so or when there's some other interrupt from outside.  (That's outside the subject of your diode-resistor logic; but addressing your post above.)

[barnacle]

Just as an aside, have you chanced across this article: https://www.theregister.com/2026/02/11/ ... 0_machine/ (I know it's z80, but it sounds similar to what you're considering).

Neil

[No True Scotsman]

GARTHWILSON wrote:

... using the W65C02S's SToP or WAIt instruction will bring the dormant power requirement down to a negligible level, assuming all loads are CMOS and take only a teensy leakage current when logic states aren't changing.

That sounds promising. Thanks!

barnacle wrote:

Just as an aside, have you chanced across this article: https://www.theregister.com/2026/02/11/ ... 0_machine/ (I know it's z80, but it sounds similar to what you're considering).

It does look similar to what I want, and they're cheap enough on Ebay to pick one up and experiment with it, even if it proves to not be what I want.

I've seen quite a few devices over the years that have a form factor similar to the Model 100, such as the Alphasmart series and the uConsole. Most have a tiny chiclet keyboard, or a one-to-four line text displays, or they run Linux. Waiting for Linux to boot is right out. It has to be ready to go as soon as I turn it on. I want colorful ANSI art screens for the UI, which rules out a monochrome display. I think I actually have an old Laser Z80 computer around here that I took apart. The keyboard on that one was really the only thing about it that was close to being ideal. I may end up getting one of those surplus TI-99 keyboards that Tandy resold in a bag under the Archer name.

That said, the fact that MS BASIC and Wozmon are freely available now is a major selling point for a DIY 65C02.

[No True Scotsman]

It's evidently a major pain getting that MailStation device to do anything beyond its original purpose. Apparently the memory layout inhibits running CP/M on it. The Ben Eater approach of moving a DIP EEPROM between programmer and computer would be more suitable for my experimentation.

[GARTHWILSON]

No True Scotsman wrote:

Most [...] run Linux. Waiting for Linux to boot is right out. It has to be ready to go as soon as I turn it on.

I doubt you'll be using Linux on your home-made computer; but I have it on my laptop computer (and this desktop computer too) and just put it in "suspend" when I'm done with it, which just takes a second or two, and then it comes back just as fast when I turn it back on.  No long boot-up time.

Quote:

I may end up getting one of those surplus TI-99 keyboards that Tandy resold in a bag under the Archer name.

I got one they sold from the Oric computers, and then I thought I should have grabbed a few more; but here I am decades later and I still haven't used it.

[No True Scotsman]

GARTHWILSON wrote:

I doubt you'll be using Linux on your home-made computer; but I have it on my laptop computer (and this desktop computer too) and just put it in "suspend" when I'm done with it, which just takes a second or two, and then it comes back just as fast when I turn it back on.  No long boot-up time.

I did, in fact, think about putting a Raspberry Pi Zero into a portable 65C02 computer, so that I could have an onboard server running PHP/SQLite apps. I ultimately decided to leave all of that on my desktop PC, where it's already installed, and use the ESP32's WiFi module to connect to it there. I may do something with LoRa if I find myself wanting WiFi where it's not available. The ESP32 also supports ESP-NOW, which allows two ESP32s to communicate P2P without a network.

GARTHWILSON wrote:

I got one they sold from the Oric computers, and then I thought I should have grabbed a few more; but here I am decades later and I still haven't used it.

It's surprisingly hard to find raw row-and-column matrix keyboards anymore. About the only ones I see on Ebay are the aforementioned "Archer" TI-99 keyboards, which go for around $80. Somebody offered me one for $60 the other day, but I'd already bought all the hobby stuff I intend to buy this month.

I have a Fujitsu palmtop or netbook keyboard from the 90s that's fairly ubiquitous on Ebay. What's also fairly ubiquitous is the terse 4-page datasheet that helpfully identifies it as a matrix keyboard, but unhelpfully doesn't provide a pinout. I haven't got around to hacking that one yet, lo these three years later. The "Archer" TI-99 keyboard does furnish a pinout diagram.

My first go at a terminal will actually be with a PS/2 keyboard. New 60% keyboards are pretty cheap on Ebay, and they're about the right size.

[BigDumbDinosaur]

GARTHWILSON wrote:

In that case, you might find that you don't even need to power down, if using the W65C02S's SToP or WAIt instruction will bring the dormant power requirement down to a negligible level...

Note that while WAI may be cleared with an IRQ or NMI, the only thing that will clear STP is a reset.  The internal effect on the MPU is the same with either instruction; the only difference is in how the MPU can be restarted.

Disabling IRQs with SEI immediately before executing WAI will cause the MPU to restart on the instruction that follows WAI, provided the interrupt is an IRQ.  The result will be a single-cycle response to the interrupt—the vector at $FFFE-$FFFF will not be taken.  See here for a little more detail on this programming technique.  The article actually is for the 65C816, but it works the same with the WDC 65C02.

[No True Scotsman]

Fascinating. So I could execute WAI to halt the 65C02, and have the ESP32 assert IRQ to restart it where it left off, right?

[BigDumbDinosaur]

[color=#000000]No True Scotsman wrote:

Fascinating. So I could execute WAI to halt the 65C02, and have the ESP32 assert IRQ to restart it where it left off, right?

That’s correct.

One thing to watch out for is any hardware interrupt will cause a restart, but only a restart following an IRQ will execute the instruction following WAI.  An NMI will also cause a restart, but the MPU will take the NMI vector.

[No True Scotsman]

The ESP32 has a similar thing going on with its sleep modes. Waking up from deep sleep causes it to reboot, while waking from light sleep doesn't.

As the ESP32 will be responsible for waking the 6502 up, so to speak, it'll have to ensure that nothing else will. That should be simple enough because the only other thing that possibly could interrupt the CPU would be the console UART. It wouldn't have any reason to interrupt the CPU if the ESP32 isn't sending data through it. And we probably wouldn't want the CPU sleeping to begin with if the second UART was talking to something else.

The only other peripheral is a DAC, and it's a write-and-forget affair.

[BigEd]

> One thing to watch out for is any hardware interrupt will cause a restart, but only a restart following an IRQ will execute the instruction following WAI. An NMI will also cause a restart, but the MPU will take the NMI vector.

Ah, curious. So what happens when the NMI handler reaches and executes its RTI?

[barnacle]

(This is reminding me of my last paid job, where we had a processor running continuously, but by careful choice of run speeds and sleep levels, it used less current than the leakage current in the batteries...)

Neil

[BigDumbDinosaur]

BigEd wrote:

Ah, curious. So what happens when the NMI handler reaches and executes its RTI?

The MPU will execute the instruction that follows WAI and continue from there.  The final step during the execution of WAI is to increment PC so it is pointing to the next instruction’s opcode.  So when the MPU acknowledges the NMI and saves state, it will push whatever is in PC.  That the address of the next instruction is already in PC while the MPU is WAIting explains how single-cycle response is achieved to an IRQ.

[BigDumbDinosaur]

barnacle wrote:

(This is reminding me of my last paid job, where we had a processor running continuously, but by careful choice of run speeds and sleep levels, it used less current than the leakage current in the batteries...)

...and when it turned out that the processor actually was running down the battery, the boss called you into the office and said, “You’re fired!”  That’s why it was your last paid job.