6502.org

I'm sure this is a joke, but a serious answer is possible anyway. I would like to offer more modules for facilitating hobby-computer building, although they would probably mostly be very small ones. Bigger ones would not really be plug-in modules so much as external equipment interfaced by 65SIB (6502.org serial interface bus which is compatible with SPI but more flexible).

One of the biggest plug-in modules would be a power supply board that takes anywhere from a weak 9V battery or 6 nearly dead AA's, up to 40V or so (for automotive power that can be up to about 15V plus spikes, and 28V private-aircraft power plus spikes), and puts out 5V and ±10V. There are lots of integrated switching regulators on the market, but I have not found any that do this job in one module. I have a very densely breadboarded one here that's 2.3"x1.85" including a DC-10 power jack and power switch, and it'll do an amp at 5V and a couple hundred mA at ±9V and is filtered and electrically very quiet; but it would be way too labor-intensive to assemble by hand, and the low anticipated sales volume wold not be enough to justify the set-up costs for automated SMT assembly. I don't know if there's a solution for that one.

Smaller modules might include hot-pluggable tiny I2C-6 modules for serial EEPROM [Edit, 7/28/22: I now have an I2C-6 EEPROM module is on the front page of my site, and there's a link to the data sheet there], RTC w/ alarm interrupt, temperature sensors, keypad scanning, etc..

I've thought about multi-I/O modules, but they probably won't happen, for a few reasons. Even a dual or triple VIA would be kind of nice, but there's not much advantage if you have to bring all those connections back down to the mother board. So then it would be for if you want I/O pin headers on the module, but that produces other challenges. My original vision and design for my workbench computer (over 20 years ago) was that most jobs would have the I/O going mostly through the board-edge connector; but as I gained experience with it over the course of many dozens of jobs, I began to see that I was mostly wanting and using individual connectors for the various things, and it was not practical to wire up a socket for the board edge for every project, and especially when I wanted to combine multiple projects. Slowly I added connectors on the computer for:

• RS-232
• remote keypad and LCD
• 65SIB
• a synchronous-serial port to use with the shift register of one of the 65c22 VIAs (used primarily for raster graphics on an analog oscilloscope and to access megabytes of external memory, including testing my memory modules, and for an LCD tester)
• 3.5mm jacks for D/A output and A/D input
• 5-pin sockets for anti-alias filters for the D/A and A/D converters
• 5-pin socket for a 432MHz wireless link
• 3.5mm jack for an amplifier output for a speaker
• I²C port (an earlier incarnation of I2C-6)
• 1-Wire port
• PC keyboard connector
• SS-22 port
• an additional pin header on the front panel for controlling remote equipment, especially a frequency/event counter
• a row of commonly needed oscilloscope probe points
• 3.5mm jack for cassette tape modem (which, although originally an easy way to store data, has become pointless in today's world of fast, dense, cheap serial flash memories)

That makes for a lot of smaller connectors, and in some cases there's additional circuitry to go with them besides just the VIAs or ACIAs. I don't have a separate connector for the MIDI, so it did go through the board-edge connector only. Practically the only thing I use the board-edge connector for anymore is my home-made production-grade PIC programmer.

I or someone ought to test Daryl's 65802 module design and then make it available to the public. I had also thought of something that would be like a 6502 or '816 microcontroller in a 40-pin DIP but possibly also with a tiny LCD onboard to facilitate development. The next-up DIP size was 48 pins in the same .6" width as a 40, and then next is 64 pins which the 68K used in a .9"-wide DIP. It looks like 68-pin DIP sockets are mostly unavailable now though, so you'd either have to use a pair of single-row socket strips, or it might appropriately use a dual-row pin strip header of .025" square posts like my memory module does. How would that be? A 65-pin 65-family microcontroller with a small onboard display.

Thanks. I haven't listed the parts or pinouts here, yet. Maybe its overkill, to document this project so meticuklously? I dunno. It helps me think! (At least, I think it does?)



Me too. Sorry (and thanks for sticking with it; for trying!)
This terminology confused me. I get phi 2. I get VDA and VPA (sort of; mystery pins that I am presently becoming aware of). What is || ? Is that logical-ese? I can't remember my symbolic logic, at the moment? Hpow about the "&&"?

So, here is my EEPROM pinout, synopsis/description, and part number.
I think CE/Low, from decoder circuit, and WE/High (I think I tied this to RWB pin from 65816? I forget?), will read from ROM. OE/ tied low might not be a problem? but I will check and recheck the timing diagram. You are probably correct (I have been having trouble getting my head into "the space" of timing diagrams; I am a musician, so I have no good excuse. Just have to try harder to concentrate on it. Maybe practice makes perfect?)

I think I will socket the Atmel EEPROM, and thus, I can remove it to write to it. So, with CE/Low, and WE/Low (again, from RWB from 65816?) OE/ would have to be high to initiate a write cycle; I won't do this (pull OE/ high) while its in the socket, so writing to it by accident won't be a problem.

I think inadvertant writes wouldn't be a problem; but inadvertant reads, i.e. bus contention might? I dunno. As I said, I will check and recheck the timing until I understand it.


As for the Cypress RAM, I will attach a synopsis, pin diagram, and part number, too. Maybe I am missing something (probably, I am missing something) but the truth table seems to indicate that OE/ is usually "X", which I interprate to be "Don't Care"? The only time it matterts if OE/ is high, is if I want a "bus disable state"? Perhaps I want this, sometimes?

Again, I can check the timing diagrams again, and obsess over them. I definitely will. But, If I do so for a month or two and don't get anywhere, I'll have ot just try it and hope I'm not "too stupid to compute", with hardware.

Hard to say what's a joke, with me. I am definitely new at this, and my 9 Kodak/Nat.Sem. (9628) image sensor project was "a lark" and a stretch to begin with.

My "example schematic" for the KAC-9628 shows a PLA (FLEX10K Altera, something-or-other) but I want to cut that out of the equation. Somehow, the pin/sigs. D0 through D11--digital (parallel, I assume?) video output from the sensors--goes through the Altera and gets switched out to 4 RAM chips (Memm Buffer, the schematic calls it). I don't know, but assume, that the PLA does some alteration of the signal and then switches/decodes the video signal and writes it to the RAM chips. This is my "level one/level zero" analysis of the circuit. I haven't done much else, for fear of what that might entail (as it is 9 sensors X 4 RAM chips, is a serious decoding/mem-buffer circuit! I can hardly handle one microprocessor decoding!).

So, in short, the 9 image sensor might be easiest ported to I2C (thanks again for the link, as I was certain I saw your I2C-6 connector somewhere on this page, but I got lost in cyber-space and couldn't find it again). Probably 9 I2C-6s! But, having never designed a REAL, working, complex digital system, I don't know if I prefer serial or parallel. I think parallel suits my mentality and where available I will use it (at least until it "bites" me! Then I'll know better!).

I've misunderstood the decoding "schema", for I/O especially. Each VIA only occupies 16 (four "address select" lines/pins; sixteen permutations), byte-long locations of memory, as I understand it now. Is that right?

Perhaps I'll suspend judgement until I read and re-read the 65C22N sheet again. I don't feel competent to judge, just now. (by looking at the pin diagram, eight data bits/pins of the VIA hook to the 65816 Data pins, and the 8 pins of Peripheral B and Peripheral A buses of the WDC65C22N(?) hook to two as-yet-unnamed peripheral devices (in my case, parallel video bus of two separate KAC-9628 image sensors, I think?). I assume eight bits/sigs. of the data are placed on these peripheral address buses/lines by the peripheral device (i.e. KAC-9628) and the WDC6522 plops (latches?) the data that was provided into one of sixteen registers that the 65816 can than address, if instructed, to read (according to the one permutation out of sixteen that the 65816 address--4 select pins--has selected)).

This is pronably a confused description, and probably wrong on several points. No good excuse for not "doing my homework", except that I look at the timing diagrams, expecting it to look like "music" or "symphonies", but it ends up being "less fun" than that.

Sometimes, if I sit with a bag of cookies, the mindless munching can facilitate my learning. Probably not good for my overall health, though!

Thanks again. I will work out how best to do this project, eventually. That's all for this Friday night! As for 10 VIAs, your primer section on address decoding ( and maybe on memory maps, too!) suggested it. It seemed a natural question, and not too much like a joke.

The real joke is the KAC-9628 9QTY focal plane array. Don't worry too much about that one; the punchline won't hurt. That particular joke is on me!

Perhaps it is not as "mad" as I think it is? While it might seem overkill (certainly sensors are available with more MP; 9QTY X VGA is hardly 3MP!) or folly, these image sensors are almost microprocessors, in and of themselves. They have internal registers and can be programmed. But the madness stops there; they can operate in both slave and master mode. I am guessing if they are slavish, they can feed the data, parallel video, to the 6522s and then the 65816 could access it. Just a vague hope, until I really know my hardware!

I am reminded of the Atari Nolan Bushnell talk I saw on youtube. i have to go now, computer-sharing at public library, but he had trouble making the first early microcomputers access 5 or 4 video screens. I wonder if it will be similar, here? Cheers.

So, I have about two more minutes on this computer. I gave a really quick perusal of the back and forth between BDD, Jeffyl and Garth, and I must say, I follow, in dim fashion. You are talking in words and lingo I know, about things unknown to me. I will tackle the conversation another time, after I know my own data sheets, as it seems the information you are imparting is really important. faster = better, in my mind; and always will.

A better strategy, for me, for now, is (1) "I'll know my song well, before I start singin' "~Bob Dylan (2) and slowly functioning computers are better than fastly-abberrant computers.. I must (1) study and (2) aim low/slow. Maybe pick up the speed later?

Probably buying a oscillator socket and the Maxim reset button (I think BDD? or BigEd? mentioned). I got a bit of cash for parts and other experiments, at the moment so, I'm feeling a bit less "constrained" than usual; its a very good thing. Maybe my computer will actually happen, someday soon! Cheers, and thanks again.

P.S. (to the above comments) I might radically rethink my decoder circuit (previously was a 74HC138 and a 74HC11, i.e. 3 input AND gate). I'll probably just go with one of the one's suggested by Garth's primer. I especially like the one that gives maximum RAM and ROM and "just enough" I/O (the third circuit on his list, I think?). I must study it more, and see which parts are needed; but, also, I must keep in mind that I am going for the 65816--not 65C02--and Jeffyl and/or BDDs advice might be better--i.e. more pertinent and germane--in this regard. I saw some other decoding schemes on the site here, but must get the internet-time to search for the schematics again. Tomorrow, or another day, I will get to a "more permanent" terminal.

|| represents logical OR and && represents logical AND. These are borrowed from ANSI C.
Just so you understand what these chip control symbols mean, /CE is "chip enable," and may also be written as /CS, meaning "chip select." /OE means "output enable" and /WE means "write enable." As with /CE, other notations may be used, but mean the same thing.

Using the Cypress CY7C1049D static RAM as an example, the control inputs are designated /CE, /OE and /WE. You would assert /CE when the address placed on the address bus by the MPU is one that is somewhere in RAM. This should occur as soon as the address bus becomes valid, which is sometime during the Ø2 low part of the cycle.

When Ø2 goes high, glue logic would "translate" the MPU's RWB output to assert /OE if a read cycle (RWB is high) or /WE if a write cycle (RWB is low). Note that neither /OE or /WE should be asserted until Ø2 is high. This is especially important during a write cycle, as the address bus can change during Ø2 low, which could result in a wild write if /WE is asserted at that time.

Also, during Ø2 low, the 65C816 places the bank address on the data bus. If /OE on the SRAM is asserted at that time both the '816 and the SRAM will attempt to drive the data bus, causing contention and a possibly-bogus bank address.

If you carefully inspect the timing details of the Cypress SRAM, you will see that the time required for it to generate output varies with the order in which you assert /CE and /OE. As the 65C02 and 65C816 both place a valid address on the address bus during Ø2 low, and maintain that address until after the next fall of the clock, best performance is achieved by asserting chip selects as soon as the address is present (and the '816 indicates when a valid address is present with the VDA and VPA outputs). With /CE asserted the SRAM will respond most rapidly when /OE or /WE is asserted. If you tie /OE low and control the SRAM with /CE alone, the time required for output to appear after selection will increase.

The CY7C1049D data sheet doesn't specifically state what happens if /OE and /WE are simultaneously asserted (but see figure 7 on page 9 for some confusion in that regard). In some other SRAMs, such as the 128KB unit I used in POC V1, the data sheet indicates that simultaneously asserting /OE and /WE will result in undefined behavior. Hence POC asserts /OE only when the SRAM is accessed during a read cycle and, of course, only when Ø2 is high. As I needed separate read and write control signals for use with the SCSI host adapter and the DUART (the latter which requires exclusivity with the read and write control inputs), no extra circuitry was involved in controlling the SRAM in this fashion. Also, with no reads allowed during Ø2 low, I eliminated any possibility of data bus contention with the '816.
I quote from page six of the ON Semiconductor 28C256 EEPROM data sheet:

• A write cycle is executed when both CE and WE are low, and OE is high.

Similarly, from the Atmel 28HC64 EEPROM data sheet, subsection 4.2:

• A low pulse on the WE or CE input with CE or WE low (respectively) and OE high initiates a write cycle.

In both cases, it is required that /OE be high while writing.

The data sheet is at http://www.cypress.com/file/42806/download .  The truth table is on page 11, and the OE\ column has X's for "don't care" where WE\ is low or CE\ is high.
The 28's are EEPROM though, not RAM.
..and the slash means it's negative logic (meaning the true state is low, not high), since we don't have a way to put the overbar on it here on the forum.  OrCAD (which I grew to hate at my last place of work) put it at the end, probably because as I was taught in school nearly 35 years ago, we say "chip enable not," with the "not" at the end, although I think some people say "not chip enable."  WDC would undoubtedly call it CEB for "chip enable bar" although for years I thought the "B" stood for "bit," which made me wonder why they did it.  It's like you had to say you drive a Ford car so someone wouldn't make the mistake of thinking you drove a Ford toaster.

Yes, but take another look at the heading for figure 7 on page 9. It seems to be implying that /OE should be deasserted when /WE is asserted.
When I was first introduced to digital electronics (1960s), the "low-true" notation was /XY for signal XY. I didn't encounter the overbar until much later—early 1970s, I think. I never saw the trailing notation XX\ anywhere in print.

That's because the processor could potentially be putting data on the bus before WE\ goes down in that diagram, so you wouldn't want the outputs enabled.  After WE\ goes down, you could also bring OE\ down if you wanted to, but you'd have to go out of your way to do it, which wouldn't make sense at that point.
Leave it to OrCAD.  What can you expect from a company that after 30 years or so still doesn't know how to draw the schematic symbol for a resistor correctly.  (They have more points on one side than the other, and 90-degree angles instead of 30 or so.)  For my website, it took a while to find out how to do the overbar in html for all the <signal>-not notations.  I suppose that in the 60's and 70's, on typewriters, you could go to the line above and apply underlining in the right place, even if there was nothing to underline up there.  Or maybe turn the platen down from there a quarter of a line or something like that (one click), if necessary to get it closer.

The Royal mechanical typewriter (Look, ma! No electricity needed!) on which I learned to type had a ratcheting mechanism for the platen that would allow you to rotate it a half-line, for the purpose over over- or underlining. When you did a normal carriage return, the mechanism advanced the platen two half-lines, producing the standard 1/6 inch line feed. Turning the platen knob always moved the platen the half-line distance.

In some ways, the old mechanical typewriters were more flexible than their electric counterparts. New technology isn't necessarily better technology...

So, I am a little bit more "well-read" than I have felt this past month. Not much, but definitely "on firmer ground" than before.

6522's are making more sense to me, as are the KAC-9628 (image sensors). One nagging thing,. for both, is the "programmable" aspects; both have internal registers and I am ata loss to explain how any of them are accessed or used.

I think, in both cases, the "default mode" will happen on startup of the devices, and I won't have to worry about "individually addressable bits" (for the 6522) or "video or snaphsot mode" and/or "frame window feature" (for the KAC9628). Hopefully, programming--for these devices--is a thing I can ignore.

That's the good news. The bad news is, I gave very little thought to the amount of data that each image sensor actually collects. 9 sensors X two eyes X 300 kp/frame X 30 frames/sec * 60 sec/min * 60 min?hr X 16 waking hours = a boatload of bits (I left my facts and figures at home; you can do the math). So, shelving the 9 sensor project until I have the skills to contemploate "long-term storage", which, incidentally, will be a I/O (6522 chip) consideration, too!
Thanks; still reading through this doc to get the "lay of the land".

That's it, for a quick comment today; still reading responses from the other day and want to "know" before I "speak/write".

(Oh yeah; I did notice that "PA" and "PB" meant "port"; I was calling them "Peripheral address", in my comments above. Silly My mistake! The lingo! The lingo!).

Increasingly thinking about a multilayer board; either a "hacked", pathetic, slapdash-type, as I've previously proposed on this site, or maybe something that even approaches a professional "look and feel"; like the sort of thing suggested on the think and tinker website. https://www.thinktink.com/stack/volumes ... rmattg.htm

Got my oscillator in the mail today. 2 X the desired frequency, as per the "7476" circuit suggested by some on this site. Thus, two clock cycles, precisely out of phase to one another. I still haven't drawn up my oscillator or reset circuit (but will, immediately, tonight, as this is the "easy part" of what still needs to be done!); sidetracked by my insufficient understanding of address decoding, I/O, and whether or not to bring Phi2 into my RAM decode. Still unraveling that mess.

Also sidetracked by my 9 image sensor plan, and a hundred other things (If I am lucky I will have a homemade lens for this monstrosity! The lens will be a monstrosity, for the 9-sensor plan, but if I can manage a "tighter" focal surface array, I can end up with a more compact lens design, too!). This part of the plan--sensors and lenses--MUST wait.

(Thanks, Garth, for the info. I figured parallel was faster, but more "hardware cumbersome", i.e. more planning, more traces, etc. For video, I will probably need the speed, and since parallel digital video output is offered alongside I2C, then I will choose the former. Especially since you mentioned that I2C might be considered "slow"--at least, when compared to SPI ?!).

One thing I can't ignore, is my possible "need" for 3.3 V devices. I think Garth--and the '816 data sheet--mentioned that the 6522 and 65816 would accept logic levels about 2V, and I must check the RAM and EEPROM sheet to see if those chips will ALWAYS talk to the '816 and '22. BUT, being slightly "cash rich" for the moment, I shopped around and found the 1 EEPROM and the 1 RAM--on the entire planet--that is both DIP lead and 3.3V power supply/logic levels.

I have always tended to assume that power supply = logic level; or rather, 5V family spoke 5V "pin-language" and 3.3V spoke to 3.3V and etc. But, looking at REAL chips--the chips for sale--I see that many solutions for low power and scaling of transistors have been developed, and that real care and and attention is the only way to sort out which parts will "talk to each other". I am thinking of just buying the damn chips, just in case I change my mind later, and move to 3.3V (i.e. because the camera chips might want/need it).

As Garth, and the '816 doc pointed out, moving to different 3.3V operation reduces speed/operating-frequency. I hope to avoid this.

How difficult is interface to Blu-Ray? Anybody know? How about Holographic Disc (I know, they barely exist! But maybe a RAID array of these would be prudent? Or, maybe just a few Terabyte external drives would suffice. I assunme the TB drive and the BR-DVD are just a USB interface, and "off the shelf" available!). I guess USB is the next knowledge I need to investigate (for the image sensors).

Made some notes/schematics at home. A little more detail than what I said here, today; I will post at a later time.

Whoa; just noticed this morning, Garth's primer ( http://wilsonminesco.com/6502primer/ClkGen.html ) mentions "Read-not-write" pin for the 6502 and its difference from RD/ and WR/ pins. I'll double check the '816 schematic; "RWB" if I remember correctly.

Also, I just noticed that a "single board '816" ( http://sbc.bcstechnology.net/ ) has been tried and successfully implemented, and thus "meticulous" documentation of my attempt is unnecessary. I am curious how he did it so neat and clean, and compact, as my design is anything but.

I will continue on, in BDD's footsteps, and try to push past the "known" into the unknown.

(I note that he recommends 74ACxx logic in some places, where there is some debate on this forum. I am foolishly and naively stumbling through the timing diagrams, as I presently write, and so I can offer no comment on slew times and such of the 74HCxx or 74ACxx family).

I will have to check the other parts of the 6502.org website. I have neglected them and ignored alot of the completed projects. That is the fun part. To see the completed projects and see why people did the things they did and made the decisions they made.

I think I have probably graduated from Garth's page; not because I understand everything in his primer (I do not!), but because I have stumbled across the "65C02-vs.-65816" thing, five or ten times already; I am a '816 guy (if only because I naively bought the part 5 years ago, and it presently collects dust--metaphorically--in my closet), and should seek out the successful '816 projects. The data bank addressing (on the data pins ! Arghhhh!) alone is enough to give me a headache.

I hadn't really planned on writing today; just stopped at local library, real quick, on my walk to the post office and thought I'd pop in and get some quick advice, i.e. borrow that "flip-flop + 2X-freq. oscillator can" schematic of BDD's ( download/file.php?id=895&mode=view and viewtopic.php?f=4&t=2660&p=28431&hilit= ... mer#p28431 ). Gonna go home, now, and see if I can't clean up my PCB schematic and force it to make sense! ( I really hope I ordered a 74ABT74 and not "HC", as BDD says the slew time will wreak havoc. Good thing I will make another order, or two, before "the season"--holidays--is finished!).

And one final, short, word for today. I was checking the specs on the data sheets and--I think Garth alluded to this earlier--the 6522 and the 65816 MIGHT (I must triple check) accept the H and L levels from the digital video output (D0 through D11) pins of the KAC-9628 image sensor. So, I guess I can get a different voltage supply (different board even? A "Camera Headboard", I think they call it!) for the sensors (i.e. 3.3V) and use 5V for everything else.

Will save some cash (and time and energy and thought) if I don't have to look for RAM and ROM to run on 3.3V. The cash isn't all that much; maybe buy them just in case I have to change my mind later?

Still "sunk" when it comes to my need for massive amounts of video data. (I forgot to mention; the image sensors are "programmable" for 8, 10, or 12 bit depth, i.e. in the Analog to digital conversion of pixel values. Also, I neglected any CFA (color filter array) interpolations.... I don't remember/know if that interpolation is done by the Altera/FLEX-PLA or if that is done "on-chip".).

I have read the basics on handshaking and non-handshaking reads and writes. I hope the 6522 is not limited to 8 bits at a time, handshaking, painstakingly until the data load is handled/directed/stored. One hopes there would be a way for the image sensor to say "here it comes" and the microprocessor to say "OK, send it all", and then "poof", my biologist-brain needn't worry about how to get the 1s and 0s from the image sensor into the RAM and/or permanent/mass storage.

One would hope for that, but one cannot count on that. I am printing out the timing diagrams, right now, so that I have them all, side-by-side, to lookk at and mark, and to see if the KAC-9628 can even hook its D0-D11 digital video output directly to the 6522 PA and PB port/lines. Maybe they don't "talk the same language"?

Is there some way to hook the KAC-9628 digital video output directly to some RAM, and thus eliminate the need for the microprocessor and I/O chip to handle the info? That would be too easy, wouldn't it? Wishful thinking! (Hmmm, since the image sensor is kind of like a "special purpose microprocessor", perhaps there is a RD/ or WR/ pin or RWB pin or something that can "grab" the RAM--and write to it--when it wants it, and the KAC9628 can be interrupted when the '816 wants that particular RAM chip, for reading or writing? Maybe... must read, and know, my devices!).

Such a scheme--mentioned directly above--would be a nightmare for my newbie brain to implement. Multi-processor system, is probably what you would call it! I think I will leave that--the above multi-design--as a "hypothetical" and, for now, moving forward, I should consider that the 65816 should be "master" processor, the 6522 the "messenger" and all the image sensors "slave" processors. This seems the most appropriate and easiest and "sleekest" and "do-able": design, for a newbie.