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

[BigDumbDinosaur]

No True Scotsman wrote:

If I'm reading Rockwell's R65C02 datasheet correctly, it appears that an external device can put the CPU into standby mode by stopping the clock with PHI0 high.

That is true of all 65C02s, and the 65C816.  As a bonus, all WDC parts with static cores can be stopped on either clock phase.

Quote:

If that's the case, no WAI or interrupts would be needed, right?

How do you propose to restart the MPU absent an interrupt?

Quote:

I looked in my parts box to see which 65C02s I have...Anyway, these here say W65C02, but the manufacturer logo on them is UMC, not WDC.

They are not genuine WDC product, and given the (mis)marking, might not even be a 65C02.  Caveat emptor, and please see this post for good measure.

[No True Scotsman]

BigDumbDinosaur wrote:

How do you propose to restart the MPU absent an interrupt?

I was counting on it to resume when the clock is restarted. Is that not how it works?

[Dr Jefyll]

No True Scotsman wrote:

I was counting on it to resume when the clock is restarted. Is that not how it works?

Yes, but what is it that provides the cue for the clock to restart? (Is it input from the human, for example?)

Note that you'll need some circuitry to start and stop the clock. And, to do so cleanly (ie, without the risk of producing partial pulses that can crash the CPU), said circuitry will involve more than just an AND gate. All things considered, you may find the WAI approach more easily doable.

-- Jeff

[BigDumbDinosaur]

Dr Jefyll wrote:

No True Scotsman wrote:

I was counting on it to resume when the clock is restarted. Is that not how it works?

Yes, but what is it that provides the cue for the clock to restart? (Is it input from the human, for example?)

Ha, Jeff articulated the question within my question.

Quote:

Note that you'll need some circuitry to start and stop the clock. And, to do so cleanly (ie, without the risk of producing partial pulses that can crash the CPU), said circuitry will involve more than just an AND gate. All things considered, you may find the WAI approach more easily doable.

My topic on use of clock stretching to generate wait-states offers some tested possibilities.  As Jeff notes, you can’t just arbitrarily stop and start the clock—timing considerations make the difference between glitch-free operation and a crash.

[No True Scotsman]

Dr Jefyll wrote:

Yes, but what is it that provides the cue for the clock to restart? (Is it input from the human, for example?)

The ESP32 on which the terminal runs will stop the 65C02 clock when the keyboard is idle, and restart it when the user types something. So in a sense, it will be caused by user input, or lack thereof.

Dr Jefyll wrote:

Note that you'll need some circuitry to start and stop the clock. And, to do so cleanly (ie, without the risk of producing partial pulses that can crash the CPU), said circuitry will involve more than just an AND gate.

In the post where I initially talked about this idea, there's a screenshot of that circuit (Fig. 8) for the Rockwell chip.

[Dr Jefyll]

No True Scotsman wrote:

Dr Jefyll wrote:

Note that you'll need some circuitry to start and stop the clock. [...]

In the post where I initially talked about this idea, there's a screenshot of that circuit (Fig. 8 ) for the Rockwell chip.

OK -- looks good.

Quote:

Dr Jefyll wrote:

Yes, but what is it that provides the cue for the clock to restart?

The ESP32 on which the terminal runs will stop the 65C02 clock when the keyboard is idle, and restart it when the user types something. So in a sense, it will be caused by user input, or lack thereof.

Have you figured out how the ESP32 will know when the keyboard becomes idle? Just curious. It's definitely a solvable problem.

-- Jeff

ps- re the clock-stop circuit: in order to meet the rise- and fall-time specs for the clock input on a modern 65xx chip, the gate driving that input should be an AC type or similar, for example a 74AC00. Just sayin'. Folks have gotten away with flauting that spec. But you might prefer to do things "properly."

[No True Scotsman]

The ESP32 will be programmed in the Arduino IDE. In Arduinoland, there's a millis() function that returns the number of milliseconds since the ESP32 started up. We can store the count in a variable and update it each time a key is pressed, and compare the stored count with the current count on each pass through the keyboard polling loop. If the difference is greater than the idle timeout period, the system enters standby mode. The ESP32 itself is awakened by an interrupt, which the MCP23017 can furnish when a key is pressed (i.e., when a pin voltage changes), so there's no need to interrupt the 65C02.

The polling loop in question is just the main loop() function found in every Arduino sketch. This same loop will also print data from the MCU to the SPI screen, completing the terminal.

As the ESP32 has two cores, WiFi and SD card stuff will be handled in a separate concurrent process.

Note that the millis() counter wraps around about every 47 days, which could cause a glitch in our math. However, the chances our portable will be continuously powered up for that long are slim.

What we're basically doing here is taking a task that the MCU might ordinarily perform and moving it to a co-processor.

[fachat]

If you only measure time for keyboard idle, how do you know if the 6502 is done finishing its job?
(Besides me wondering , without having read the whole thread, what you then need the 6502 for anyway in this system?)
André

[No True Scotsman]

fachat wrote:

If you only measure time for keyboard idle, how do you know if the 6502 is done finishing its job?

As has been said, we can't just stop the clock willy-nilly. The idle timer won't be the only thing monitored. In the absence of a fully fleshed out plan, it was the simplest illustration of how the scheme could work.

fachat wrote:

(Besides me wondering , without having read the whole thread, what you then need the 6502 for anyway in this system?)

One of the main goals is to have WiFi on a 65C02 portable. Since the WiFi microcontroller has a lot of untapped capabilities, I may as well farm out other peripheral work to it. I'm not a "retro" purist. I want all of the benefits of a retro computer with none of the liabilities. I'm going to take the quickest path to the results I want.

The ESP32 can't be the main computer because its Harvard architecture prohibits loading and running software on the fly. Somebody may point out a project on Github where it has been done, but I'm not interested in duplicating every "because we could" stunt on Hackaday. That's not to say I don't admire the imagination and skills of the person who originally pulled it off. But that's their thing, not mine. If you're a fellow Gen Xer, you know that little of what we do is performative.

Remember how the C-64 became unusable during tape loads and what-not? Well, that won't fly here. If there's a way to relieve the MPU of tasks that (if we're honest) it was never all that great at, I'll take it. Why have the MPU waste time drawing a 320x240 video display or deciphering key codes when there's another processor there, and much of the code for it is already written?

Stuffing a Raspberry Pi into a custom case won't work for me either. First of all, that's the least imaginative thing one could do with a Pi. You're supposed to invent new smart gadgets with it, not use it as a Temu desktop PC. Although I imagine an appliance with a full Linux system inside is doing too much to be up to any good. Secondly, a portable Linux computer would bring the same problems that devices with "always-on" Internet always bring.

I don't mind telling you I utterly despise smartphones. In my experience, a smartphone is a remote control that other people use to control the person carrying it. Moreover, constantly worrying about charging it before it sucks the battery dry before your eyes is a dance this monkey won't do. And finally...

Who thought smearing your greasy fingerprints all over the screen was a good idea for a user interface? That you, Steve Jobs?

Smartphones don't solve any problem I had before, and they cause new problems I didn't have before. I'm not required to carry one anymore, so I don't.

There's no guarantee every idea I discuss here will be implemented at the end of the day. Sometimes I just like to ask "what if?"

[fachat]

I'm on the Same page with you - on retro feeling and on offloading work. I do have special controllers on my Commodore PET rebuild for USB, I2C. I only do IEC bit banginging because it's the compatible way... (as an extension to be able to use IEC floppies instead of IEEE488 floppy drives. And it does have the fast mode using a shift register. Bit banging is about the most wasted time of a CPU...)

Speaking of WIFi... I am also looking into an ESP solution. But for me it would not only be simple connections but some kind of remote file system solution as well. I am thinking of tapping into the Fujinet ecosystem. Did you think about that, what are your thoughts?

André

[No True Scotsman]

I'm not familiar with Fujinet, but I previously talked about using the WiFi to access remote file storage and PHP/SQLite daemons running on my PC, and possibly a full multi-user BBS later on.

A consideration when using the Internet on an 8-bit computer is that you'll need to filter a lot of content through a proxy that converts it to plaintext or a very simple rich text format that a 6502 can use. You're not going to be able to surf the Web with full CSS and JavaScript support. Even an HTML5 parser is more complicated than you'd think, thanks to HTML5 not being XML-compliant. It would be easier for me to write my own server programs than to try to make the 6502 or the ESP32 do things they weren't meant to do.

The old school BBSes eventually migrated to Telnet, so that's a good place to start. What some people call "Telnet" is really a barebones TCP socket connection that you write your own protocol for. For instance, a homebrew file server would listen on a socket for requests such as "GET /path/to/file" and read the file back in base-64-encoded chunks or whatever. The ESP32 would decode and store the file on the SD card. The loader in 6502 ROM could then request it from the SD card.

I'm not sure if this forum accepts Zip attachments, but I'll try to post some code to illustrate this when time permits.

[GARTHWILSON]

The topic has migrated far from mickeymouse logic, but it's your topic, and you can do that.  You can however edit the head post and change the title, and/or add a note there telling what other subjects get discussed in later pages.

No True Scotsman wrote:

because its Harvard architecture prohibits loading and running software on the fly.

I'm not sure what you're thinking here, but I would say some of us are doing that on it, I in Forth.

I'm with you on the matter of smartphones, although my reasons maybe be partly different.  #1 is that they are the prime surveillance device.  #2 is that all this wireless communication is slowly causing a lot of health damage.  (There are about five more, including, like you say, that I don't like the grime and moiré on touch screens, and I don't want to be bothered with always charging things.)

[No True Scotsman]

I'm actually questioning the need for an onboard language interpreter lately. BASIC was appropriate for the push for computer literacy in the 80s, but it's achieved its goal where I'm concerned. (That said, I think it would be fun to have QuickBASIC on an 8-bit portable.) Programs can be written and assembled on the desktop, and downloaded via WiFi. Perhaps just a monitor for troubleshooting will suffice.

Further ideas about developing on the desktop and transferring binaries to the 6502 system can be found in Jan Roesner's Sixty502 project. It's intended specifically to work with the hardware found in Ben Eater's kit, so a lot of stuff would have to be stripped away or refactored for my purposes.

Regarding the scope creep of this thread, it was bound to happen when I go to yappin'. I've updated the OP with a TOC of sorts.

[BigDumbDinosaur]

No True Scotsman wrote:

Who thought smearing your greasy fingerprints all over the screen was a good idea for a user interface? That you, Steve Jobs?

Development of touch screens was a significant step in dumbing down a user interface to the cognizance level of a monkey, thus making possible the use of almost any electronic device by virtually anyone without regards to intelligence.  Touch screens had existed well before Steve Jobs told Playboy magazine in a 1983 interview that anyone over the age of 30 was washed-up and had no creativity left in them (J.S. Bach would have differed with him on that—the Cantor of Leipzig was 64 when he completed his epic masterpiece, Mass in B minor).  So blaming Jobs for touch screens would be awarding undeserved credit, in my opinion. 

I routinely have trouble with touch screens...guess they don’t like my large, blunt fingers.    My phone is a flip unit—I have no need for all the fluff found in a modern smart phone.  As long as I can make and receive voice calls, I’m good.

[No True Scotsman]

Sure, there were touch screens before, but they didn't catch on in significant numbers until the iPhone.

I tried a KaiOS flip phone. Unfortunately, the device was saddled with a grossly underpowered flip phone CPU. The best feature of old school flip phones - the T9 system - was conspicuously absent.

I was well past age 30 when my supervisor wrote in my performance review that I was "too creative." Companies don't really value creativity. Steve Jobs was a rare bird in that regard.