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

For discussing the 65xx hardware itself or electronics projects.
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Mickey Mouse logic, address decoding, power management,

Post by BigDumbDinosaur »

No True Scotsman wrote:
Companies don't really value creativity. Steve Jobs was a rare bird in that regard.
Jobs was more akin to a used car salesman than the creative genius his fanboys occasionally make him to be.  The real creativity in the Apple of old was in Steve Wozniak.  In a metaphoric sense, Woz was able to look at bricks and two-by-fours and envision a house of technology.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
No True Scotsman
Posts: 127
Joined: 22 Mar 2023

Re: Mickey Mouse logic, address decoding, power management,

Post by No True Scotsman »

BigDumbDinosaur wrote:
No True Scotsman wrote:
Companies don't really value creativity. Steve Jobs was a rare bird in that regard.
Jobs was more akin to a used car salesman than the creative genius his fanboys occasionally make him to be.  The real creativity in the Apple of old was in Steve Wozniak.  In a metaphoric sense, Woz was able to look at bricks and two-by-fours and envision a house of technology.
What I meant was, as a manager, Jobs recognized and valued creativity.
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

Re: Mickey Mouse logic, address decoding, power management,

Post by barnacle »

I am firmly of the camp opposed in general to touch screens. They require visual feedback to locate areas of interest but also a stable vibration free environment environment in which to operate them efficiently - which is presumably why some set of idiots decided to use them as primary control interfaces in cars.

They can have their uses, but they're often used where other input methods might be better - I'm trying to imagine laying out a PCB using a touch screen... But they're cheap. So...

Neil (/rant)
No True Scotsman
Posts: 127
Joined: 22 Mar 2023

Re: Mickey Mouse logic, address decoding, power management,

Post by No True Scotsman »

While I have a reasonably clear picture in my head of the system I want to build, I didn't have a clear picture of a block diagram of that system in my head. When I undertake to draw a block diagram, I start by drawing the parts that all systems have in common - CPU, RAM, ROM, clock, etc. - and run out of room before I get to the parts that are different, which are likely the ones you're most curious about.

This time, I decided to arrange everything around the decoder rather than the CPU. A detailed logic diagram of the decoder was previously posted here.
6502_ESP32_block_diagram.png
The ESP32, which is the big box on the right that I forgot to label, is a 3.3V system, which means level shifters will be needed where signals cross the dotted line in the diagram. I have some of those little cards with four BSS138 MOSFETs for that. The BSS138 is safe for I2C, which is convenient because the audio output section will probably contain a PT2257 I2C volume control in addition to the obligatory DAC output buffers, LPFs, and audio amps. Other GPIO pins on the ESP32 may be used as timer-driven interrupt sources for the 6502, or to stop and restart its clock.

The final design of the keyboard scanner (bottom right) will depend on the keyboard I end up using. A keyboard with 64 or fewer switches would require only one MCP23017 dual port expander.
No True Scotsman
Posts: 127
Joined: 22 Mar 2023

Re: Mickey Mouse logic, address decoding, power management,

Post by No True Scotsman »

No True Scotsman wrote:
Seeing it all together like this illustrates how two NAND gates were eliminated. Now if only I could get rid of that last one.
Michael wrote:
I don't see an easy way to get rid of that one gate.
If we can't get rid of it, perhaps we can make it cheaper?
decoder_2N7000_NAND.png
User avatar
Michael
Posts: 633
Joined: 13 Feb 2013
Location: Michigan, USA

Re: Mickey Mouse logic, address decoding, power management,

Post by Michael »

Could something like this work? Do you need /RD and /WR strobes for other peripheral ICs?
temp5.png
I find 64K fast RAM chips on-sale every once in awhile on AliExpress. They're 'pulls' but they've always been in good condition and test good.
Attachments
surplus sram.png
No True Scotsman
Posts: 127
Joined: 22 Mar 2023

Re: Mickey Mouse logic, address decoding, power management,

Post by No True Scotsman »

Yes, I'd like to keep /RD and /WR. I thought about using the other half of the 139 to break them out, as you've done there, and a 3-to-8 decoder to break out /IO0 - /IO7. It would still be three chips, but all three would be fully utilized.

EDIT: I went ahead and sketched in a 138 decoder for IO. Not only are all three chips fully utilized, the IO address space is used more efficiently. We were giving 64 bytes to each of four peripherals before. Now it's 32 bytes for each of eight peripherals. How many peripheral devices have 64 registers anyway? Devices that are doing too much, probably.
decoder_IOx8.png
I forgot to write in the $80E0 - $80FF for /IO7.
barnacle
Posts: 1831
Joined: 19 Jan 2004
Location: Potsdam, DE
Contact:

Re: Mickey Mouse logic, address decoding, power management,

Post by barnacle »

I've considered the '688 for similar functions, and been dismayed by its rather pedestrian speed; it's a potential issue in HC (and it doesn't appear to be available in anything else) at anything under 5v. YMMV of course.
Screenshot from 2026-02-23 07-10-06.png
Neil
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Mickey Mouse logic, address decoding, power management,

Post by BigDumbDinosaur »

barnacle wrote:
I've considered the '688 for similar functions, and been dismayed by its rather pedestrian speed; it's a potential issue in HC (and it doesn't appear to be available in anything else) at anything under 5v. YMMV of course.
The 688’s function is nice, the speed (lack of it) not so much.  This is a part just begging to be synthesized in a 7.5nS GAL.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
User avatar
GARTHWILSON
Forum Moderator
Posts: 8773
Joined: 30 Aug 2002
Location: Southern California
Contact:

Re: Mickey Mouse logic, address decoding, power management,

Post by GARTHWILSON »

BigDumbDinosaur wrote:
barnacle wrote:
I've considered the '688 for similar functions, and been dismayed by its rather pedestrian speed; it's a potential issue in HC (and it doesn't appear to be available in anything else) at anything under 5v. YMMV of course.
The 688’s function is nice, the speed (lack of it) not so much.  This is a part just begging to be synthesized in a 7.5nS GAL.
The '521 is the same thing, and the CD74FCT521CT maxes out at 4.5ns.
https://www.mouser.com/ProductDetail/Re ... VN6g%3D%3D
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
User avatar
BigDumbDinosaur
Posts: 9425
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: Mickey Mouse logic, address decoding, power management,

Post by BigDumbDinosaur »

GARTHWILSON wrote:
The '521 is the same thing, and the CD74FCT521CT maxes out at 4.5ns.
Same functionality, yes, and single-digit prop time.  However, inputs and outputs are TTL, even when VCC is 5 volts.  I can’t see how that device could be successfully integrated into an all-CMOS system running on 5 volts.
x86?  We ain't got no x86.  We don't NEED no stinking x86!
User avatar
Michael
Posts: 633
Joined: 13 Feb 2013
Location: Michigan, USA

Re: Mickey Mouse logic, address decoding, power management,

Post by Michael »

I'm curious if you have a particular clock speed in mind?
Last edited by Michael on Tue Feb 24, 2026 9:35 am, edited 2 times in total.
Martin_H
Posts: 837
Joined: 08 Jan 2014

Re: Mickey Mouse logic, address decoding, power management,

Post by Martin_H »

I am not sure if I understand this, or if I'm confused by the 688 I/O selection.

I read the 688 data sheet, and it compares two 8-bit words and outputs zero if they're identical. Input P are the high eight address lines which means it will return 0 for an entire page. You're comparing against a "wired" Q address using pulldowns and pullup shunts. This allows selection of the I/O page address. You then use IOB to enable the output from a 139 decoder to select between four devices within that page.

Do I understand it? If so, then I'm confused why a moveable I/O page is useful. Your binaries will contain fixed addresses of I/O devices, so moving the I/O page should entail creating new binaries.
No True Scotsman
Posts: 127
Joined: 22 Mar 2023

Re: Mickey Mouse logic, address decoding, power management,

Post by No True Scotsman »

It's not likely I'll clock my portable higher than 4 MHz. I may connect an 8 MHz clock during development to see what happens, but the fastest full oscillator in a can I have on hand at the moment is 1 MHz.
User avatar
Dr Jefyll
Posts: 3525
Joined: 11 Dec 2009
Location: Ontario, Canada
Contact:

Re: Mickey Mouse logic, address decoding, power management,

Post by Dr Jefyll »

BigDumbDinosaur wrote:
GARTHWILSON wrote:
The '521 is the same thing, and the CD74FCT521CT maxes out at 4.5ns.
Same functionality, yes, and single-digit prop time.  However, inputs and outputs are TTL, even when VCC is 5 volts.  I can’t see how that device could be successfully integrated into an all-CMOS system running on 5 volts.
I too roll my eyes at the CD74FCT521CT's TTL output levels, but -- depending on circumstances -- it may be easy to make accommodation. In the case at hand, we're suggesting that No True Scotsman use a '521 to replace a slower equivalent (the 74HC688). In the proposed circuit, the comparator output drives the inputs of an 'HC139 and an 'HC138. I'd consider simply replacing these with 'HCT139 and 'HCT138.

-- Jeff
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
Post Reply