6502.org

Hi, I'm new here. I don't remember exactly how I found 6502.org, but I do know that I'm looking to build a old-type computer, mostly for a sort of typewriter, but also for the experience of working with the hardware. I've also never used assembly before, and this is the best place I've found to learn about any form of it(I didn't look all that hard for stuff on x86 ASM). I did read Mr Wilson's most informative primer, and I have used the address decoder from it.

I'm planning on building this computer on a breadboard at first, and then maybe moving to a PCB later. I don't plan to run it at more than 1 MHz, certainly not initially. I'll probably also add a 65SPI if I can, because this: https://www.adafruit.com/products/2719 can use SPI, and I do want a screen eventually. (It's similar to the one the Dodo uses)
But I want to put a front panel on it, much like the Altair's but a bit simplified. This will allow me to program the EEPROM from the front panel if I do it right(I really am a cheapskate. I don't like the prices of any of the EEPROM programmers that I've seen). Trouble is, I couldn't find anything comprehensible to base it off or compare it against.

I've come up with a circuit that I think should do the job of a front panel, but I'm not sure if it actually will. Could I get some feedback on it, please? I apologise in advance for my handwriting, as it's not the neatest.

I've attached the circuit diagrams for the computer itself and for the front panel. Any comments on either would be appreciated.

I don't want to rain on anyones parade, but do you really want to do this?

Front panels are actually pretty complicated with lots of parts etc that can add up pretty quickly. And in the end, you get a pretty awful experience.

If it's what you want, aesthetically, then for sure, but, personally, a front panel doesn't really offer anything and costs a lot of money, time, and effort.

I don't know myself, but especially with all of the modern stuff, there's likely a cheaper mechanism to program your EEPROM -- like a python script off of a Raspberry Pi kind of thing, or some other USB programmable microcontroller.

With a Raspberry Pi, some wires, a bread board, and some scripting you should be able to program most anything.

No parade-raining! If someone wants to do something, then they do indeed already want to do it.

I recently soldered up a PiDP-8 kit, which has about 90 LEDs and a couple of dozen switches on the front panel. It wasn't too bad at all as a construction experience, although lots of effort had already gone into designing it. It's open source too, so anyone can learn from how it was done.

Also: welcome, DerTrueForce, and I hope you do get the feedback you're seeking here.

We had a topic recently, "Happy New Year and happy hacking in 2016!," which had some interesting material on getting going without an EPROM programmer and things like that. There's something intriguing about the possibility of being independent of those things.

Welcome, DerTrueForce. I started looking at your diagrams yesterday, but have not been able to do them justice yet. I might be able to guess what pages you've been looking at though. Make sure you pull NMI\ up. It disappears. I would want to look into how EEPROM is programmed. I've used EPROM a lot, but not EEPROM, and I know there are tricks to having the computer it's in program it. It takes a few milliseconds to program each byte, and the computer must run from RAM during that time, if it's running at all. Perhaps you've figured that it won't, that you'll just enter things from the front panel.

My first EPROM programmer was a hand-made, manually-controlled board, with DIP switches for the address and data, and a pushbutton to program each byte, and a timer since the EPROM needed a 50ms pulse which of course you can't time manually. It was far too prone to human error, and EPROM must be all erased if you make a mistake. EEPROM won't have that problem. I also found out DIP switches, which I chose for cost, not just compactness, aren't made to switch very many times before they're worn out. Small toggle switches will last a lot longer, but are pretty expensive for the number you'll need, and more work to wire up. But again, if that's what you want to do, there certainly is some intrigue to doing it that PDP-8 way that Ed referenced.

Garth: I think EEPROM is programmed much like an SRAM, except it's about a million times slower. The EEPROM I'm looking at is 10 ms max on the write cycle, and the SRAM is 15 ns min. And for this particular EEPROM, unless you are erasing the entire chip, it's all at 5v.

As regards programming the EEPROM, I don't plan on having the 65c02 do that; certainly not at the moment. The idea is to program the EEPROM via the front panel, shut it down, set the jumper on J1 to the write-protect position, and then restart and run it. I didn't want to go to a commercial programmer, because the prices are scary, and I didn't want to have to buy an Arduino that would probably not get much use.

I was planning to use some DIP-20 LED displays like the Jaycar ZD-1740, similar to what's used here: http://hackaday.com/2014/12/01/a-z80-co ... kenlights/ to help bring down the number of individual components. Also, do I need the buffers between the latches and the buses? I'm finding it a bit difficult to find non-tri-state ones. I imagine I could just tie the CS\ to ground if I can't find 'em. I just don't need the tri-state part.

Also, I should have asked this before, but will this circuit give the correct timings for reading and writing to RAM/ROM? And is there a better way to stop the 6502? The way I've done it here seems a little fragile(But then again, this is my first real design, so...).

But of course, but it's best to let them know what they're getting in to.
That PDP thing is really cool. And something like that is great for an art piece. The Z80 hackaday thing is very cool also, again, another kinetic art piece.

But as a practical tool, I just feel it's a false economy. They're very tedious, very time consuming, and very error prone to use. If you choose the wrong switches, then it gets painful as well. All of those things add up to frustration.

Frankly, having keyed in thousands of bytes into one over time, something like what the KIM-1 offers is about the minimum usable interface. It's super forgiving, and easy to use. But it's also all software.

The switches might be easier to use if you use hex thumbwheel switches. They won't be any faster, but they may be less error-prone, more user-friendly, and more compact too. I kind of wanted these back about the time I made that manual EPROM programmer, but I thought they were too expensive at the time. BTW, The reason for the EPROM programmer being manual was that I did not have a computer of any kind yet to control a programmer. As a builder, I was just starting out, and I assembled my code by hand, too.
Since the things on the bus won't be driving the LEDs directly, no, you don't need the buffers.
Looking at the 28C256 data sheet now, I see that writing requires OE\ to be high, unlike any of the RAMs I've used.
Since you say, If all bus loads will be CMOS (no 74LS__!), I might suggest a simpler way, putting something like this on each bus line, R/W\, and BE: (There are two resistors per line so you don't cause severe bus contention if you accidentally pull one or more lines down when one of the ICs is trying to pull them up.) The ROM's OE\ may need similar attention when you take care of the comment above. When the computer is running, all switches should be open (except maybe the ROM's OE\, depending on how you take care of it). To program the EEPROM, flip the switch to pull BE down, set the switches for the desired address and data, and push the button to pull the R/W\ line down momentarily. With BE pulled low, ie, negated, you can even let the processor's clock run, and it won't matter, so you can remove the logic in the clock line too. Now you don't need buffers between the switches and the buses, and the other logic becomes simpler too. If the LED drivers have CMOS inputs, you don't need latches before them either. The LEDs will show the address and data.

To go a step further, you could do like the PDP-8 and eliminate the ROM and pre-load RAM from the switches before letting the processor out of reset. You would load only enough to make the computer able to load a bootstrap loader to get the real stuff from serial EEPROM or other storage. Of course, you would lose everything in RAM every time you turn it off, unless you use non-volatile RAM or make some provision to keep the RAM powered and protected when the power to everything else goes down. There's a simple method at viewtopic.php?f=4&t=573&p=32004#p32004 .
We don't want to pat them on the back and tell them they're doing great if they're about to run off a cliff and they don't know it. I think we've all had occasions where we wish someone had educated us before we wasted a lot of time and effort on something that didn't work the way we envisioned. I had one big such project several months ago. I probably would have still done it if I had known what I do now, but not quite the same way. I expect DerTrueForce will still go ahead with his plan, but a little differently from what he originally envisioned. DerTrueForce, do look at the price of switches though. Ones with decent life for what you want to do will still probably be cheaper than an EPROM programmer, but may pose some sticker shock anyway. OTOH, maybe you have a stash of high-quality surplus ones, so they're free. That's always nice.

Zowee those are expensive! Be sure to get the panel ones that are intended for regular use. The DIP switches, although better than some DIP switches, have an electrical life specified in the data sheet as 2,000 detent operations which is only 125 times around the circle. DIP switches are usually intended to set options on a board and then close up the equipment, not keep turning them hundreds of times per session.
Ok, but know that once you get even short portions of code going, you can do that in software. What you would do there is insert a BRK instruction or a JSR BREAK which does exactly what you're talking about but with simpler hardware. This lets you put the subroutine call exactly where you want it. To get there mechanically, you would have to single-step the program. I've done it when I was debugging a problem that showed up immediately in the reset routine, but if the bug doesn't show up for a few thousand cycles after boot-up, you're pretty much out of luck. Letting it go on the normal clock to start, and then stopping it at the right time to single-cycle it, is hopeless, unless you have hardware that will stop it at a particular address. Even then, it could be in a subroutine that's used thousands of times before the trouble comes up because a different routine called it with different inputs.
Why not use a 74HCTxx 8-bit buffer. Its outputs are strong enough to feed the LEDs, and you won't load the buses. (Do still use series resistors for the LEDs to control the current.) Ah, wait a minute. I just remembered you're not using software to translate raw hex to human-readable segment combinations. What do you plan to do for that? Are the LEDs already made with decoders in them? Or were you going to do that in your drivers?
The switching will have to make sure it's clean and that no pulses are cut shorter than what you need for the chosen speed. For example, if you have slow memory and 1MHz speed, each half cycle is 500ns (give or take), and you wouldn't want it cut off at 130ns just because that's when the switching happened. I'm sure there's a way to do it with flip-flops but it's 3am here and I'm much too tired to figure it out at the moment.

OK. Why is my last post is not what I wrote? What I wrote is now in quotes.
I'm guessing that a tired admin hit the edit button instead of the reply one(given the last paragraph). I'd still like to know why my post was edited, though.
#paranoid

I"ve never seen that before, but your guess is probably right - Garth is on USA time and is probably asleep now.

Yea, I think he fat fingered the wrong button and accidentally used his Admin powers making it reply in place rather than as a post.

Another possible consideration is perhaps a hex panel with a keypad.

The ELF has a passive panel that just sat on the bus, as described here:

http://www.sbrune.com/COSMAC/Personal_M ... or_100.pdf

The circuitry is obviously more complicated.

Darn! You're right! I am so sorry! Yes, I should have gone to bed an hour or two earlier, but I was determined to finish something else first and then I checked the forum when I was done. I don't know what time Mike does the nightly backups, but I can check with him to see if there's any way to recover what you had there. First I'll see what I can find by just clicking "Back" a lot of times. I know I deleted a little bit that I wasn't responding to. I frequently click "Edit" on my own posts, including on years-old ones to fix dead links, add a link to a newer related topic, etc.. For me as moderator, the "Edit" button is there for everyone's posts; but I don't edit others' posts. It's right next to "Quote", and I clicked the wrong one.

By far, my main job as moderator is to protect the forum from spammers, not breathe down anyone's neck or force them into some kind of mold. The Yahoo 6502ag forum was pretty much destroyed by spammers and it never really recovered. I didn't want to see the same thing happen here. You won't find anything charming in what I think ought to be done to these vandals. Again I offer my apologies.

Ok, here's your post that I have from re-opening a closed tab in the history and clicking "Back" a few times.
__________________________
That's a good idea. I had planned to use a bunch of toggle switches, very much like the Altair. But as has been pointed out, that's definitely inferior to the hex switches. There are some available from Mouser in a 6-pin DIL pinout.
Hmm. I didn't notice that. I may have to use a DPDT switch instead of a jumper to write-protect the ROM.
I think I've given the wrong impression here. I want to be able to suspend/pause the 6502 and use the panel as a debugger, to examine memory positions, and maybe poke values into memory. Programming the ROM is mostly a side-effect, but a desirable one to me.
I'd planned to use standard bipolar transistors as the LED drivers. I've seen it done in a few kits I've put together, although I think that was 4000-series logic.
As far as suspending the clock signal goes, how should I go about it? The way I've done it here does not seem to guarantee the signals being switched in the right order(as indicated by the lists in the bottom left).

I don't know if this has been mentioned, but I got a commercial programmer for Christmas at it was around $40-ish. My wife bought it for me and I'm pretty sure she used Amazon.

I can find the make/model if you're interested (PM me).

Anyway, it works very well and it's programmed everything I have except some really old FRAM chips.


**EDIT**

It is the ROM Programmer TL866CS

This *LOOKS* like the one I have but I can't remember if it's the exact same version.

http://www.amazon.com/Vanka-TL866CS-Uni ... er+TL866CS

Oh, good. The mistake is an easy one. No hard feelings. And I should have left out the hashtag, that was dumb.
I was thinking of the 220ADC16, which has a life of 10,000 steps(625 full turns), now that I look at the data sheet. Is that a good lifespan, or should I see if i can find something better?
True, and thinking about it, I probably won't use it much, if at all. If I find I do need it, I'll do it then, but otherwise, it's looking like a big pain in the backside to integrate.
I was going to use the raw binary data, as it appeared on the bus, fed into one of these: http://au.mouser.com/ProductDetail/Broa ... svZe8XM%3d.
But again, thinking about it, it would be better to go for a few 7-segment displays. I even have one that I pulled from an old DVD player ages ago that looks like it multiplexes sensibly. If I pair this with an appropriate decoder IC, I can have a far more compact and easy-to read display.
What I thought I'd do was this:
You hit the 'suspend' button, and a flip-flop stores the fact that you pushed it. Then, it waits for the next phase-2 high(maybe by looking for a rising edge), and then holds that line high, in such a way that the clock itself has no say in the matter(Maybe by running it though a gate). Then it pulls down BE and the CPU is stopped.
Then, when the 'run' button is pressed, the flip-flop flops back, the BE line is pulled up, and when the clock is next high, it lets the clock have the line back.
My problem is the BE line, as it needs to switch last on the suspend, but first on the de-suspend. I'm not sure how to do this. I should probably think about it more, but not today, as it's 9 PM here.

EDIT: Or maybe I'll use the one button to toggle stop/run and use a toggle latch instead of a flip-flop.

EDIT 2: I found a circuit in an old textbook that I can modify to avoid chopping clock pulses(It's the bottom one in the picture). Am I being overly picky about the timing of BE? Because it's looking like a pain to get it the way I'm thinking. I can do it, I'm sure, I just haven't found it yet.