shopping list

[allisonlastname]

I'm following the "very basic whole-computer schematic" from the 6502 primer, but other than what's on there, is there anything you lot recommend buying (useful logic ICs, tools, etc)?

I'm planning to build it on a breadboard to save having to design a PCB or learn wire wrap (yes, I know there are issues with breadboards but my dad built a 6502 computer on breadboards and it works fine). One thing I was wondering about is putting LEDs on the buses. Do I need latches or something for that?

[floobydust]

Okay, so what tools, if any, do you currently have?

In general, you should have a multimeter at the very least. Also, a way to program the EPROM or EEPROM. Beyond that, things get more expensive.... a logic analyzer is nice, as is an oscilloscope.

LEDS, how do you plan on hooking them up? You can connect them to the 6522 port lines, but you'll need some resistors so you don't overdrive them.

Other bits to think about... once you get some success with the basic setup, then what? More I/O is typical... perhaps a UART and USB-to-Serial adapter so you can setup a terminal program on a PC and interact directly with the system.

Whatever you do, have fun with it.

[drogon]

allisonlastname wrote:

I'm following the "very basic whole-computer schematic" from the 6502 primer, but other than what's on there, is there anything you lot recommend buying (useful logic ICs, tools, etc)?

I'm planning to build it on a breadboard to save having to design a PCB or learn wire wrap (yes, I know there are issues with breadboards but my dad built a 6502 computer on breadboards and it works fine). One thing I was wondering about is putting LEDs on the buses. Do I need latches or something for that?

Breadboard is fine to get started - as 1000s of Ben Eater fans will tell you. (And me - I started my Ruby project on a breadboard) Personally I'd never suggest wire-wrap in this century - others have different ideas though, but it's quite expensive to get into. Here in the UK (and possibly Europe) stripboard is still very popular if you want to hold off a PCB for a bit longer. See e.g. https://projects.drogon.net/ruby-6502-on-stripboard/

If you want to be able to control an LED then yes, you'll need a latch of some sort. I started with a 74als573 for 8 output bits. A 65C22 VIA is more flexible but also bigger (physically) and needs a bit more care & time to get going (but not much).

Have fun,

-Gordon

[Paganini]

Machine pin sockets for all of your ICs. If you're experimenting / troubleshooting you'll be putting things in and pulling them back out pretty frequently (especially your ROM). All those insertion cycles can be pretty hard on your chips' poor little legs. You might even want to go as far as getting a breadboard-compatible (caution: not all of them are!) ZIF socket for the ROM.

[allisonlastname]

floobydust wrote:

Okay, so what tools, if any, do you currently have?

I have a multimeter with voltage, current and resistance settings. My dad has a scope that I could probably borrow if I asked nicely. I have access to a wire cutter/stripper, a soldering iron, and a solder sucker as well (I'm using a breadboard to avoid soldering but who knows, something might come up).

As for programming ROMs, I have an arduino and a raspberry pi. Googling for "arduino eeprom programmer" turns up a lot of results, so I think we're fine there.

floobydust wrote:

LEDS, how do you plan on hooking them up? You can connect them to the 6522 port lines, but you'll need some resistors so you don't overdrive them.

drogon wrote:

If you want to be able to control an LED then yes, you'll need a latch of some sort. I started with a 74als573 for 8 output bits. A 65C22 VIA is more flexible but also bigger (physically) and needs a bit more care & time to get going (but not much).

I was more thinking "LEDs on the buses for debugging", because I've heard of that being done before and I think it would be cool. I've done bare metal raspberry pi GPIO before so I can probably figure out how to make a 6522 go.

floobydust wrote:

Other bits to think about... once you get some success with the basic setup, then what? More I/O is typical... perhaps a UART and USB-to-Serial adapter so you can setup a terminal program on a PC and interact directly with the system.

Yeah, I was looking at the MAX3100 for a UART, because I'll probably want SPI set up anyway. I can (and have in the past) use the aforementioned arduino as a USB-serial adaptor. Another thing I could do is add some keypads. I have one or two Adafruit 4*4 keypads lying around that I've never really used.

I'll get some sockets for the ROM, if I can get some ROM. Having had a quick peruse of Mouser, they appear to be completely out of 28c256 AND 28c64 ICs. Is there an alternative that still works with 6502?

[GARTHWILSON]

allisonlastname wrote:

I'm following the "very basic whole-computer schematic" from the 6502 primer, but other than what's on there, is there anything you lot recommend buying (useful logic ICs, tools, etc)?

The most basic logic ICs I can think of suggesting, in descending order, are the 74xx00 quad 2-input NAND, 74xx04 hex inverter, 74xx02 quad 2-input NOR, and 74xx138 and '139 decoders.  For just starting out, the "xx" is probably best filled in with HC.  More on the reasons upon request.

Quote:

I'm planning to build it on a breadboard to save having to design a PCB or learn wire wrap (yes, I know there are issues with breadboards but my dad built a 6502 computer on breadboards and it works fine).

Be careful.  That just means the failure rate is not 100%.  That's not very useful information.  It can be done of course, and has been many times, but we want to maximize your chance of success; so the first bullet point near the top of the 6502 primer page on AC construction has guidelines to help with that, if you really must use a solderless breadboard.

Quote:

One thing I was wondering about is putting LEDs on the buses. Do I need latches or something for that?

Unless you single-cycle it, they will change much too fast to see anything.  If you really want them though, I recommend minimizing the bus loading by holding the LED current down to 1mA or so (which still gives decent brightness with modern LEDs); so (5V-1.7V)/1mA=3.3KΩ.  The 1.7V is the approximate voltage drop across a red LED with this amount of current.  The voltage drop will increase a little as you go from red to yellow to green to blue.

It might be more useful to put the LEDs on the I/O port pins; but then remember that they will present a load on port bits that are set as inputs too, not just outputs.

On the socket recommendation:  The machine-pinned ones with several little fingers inside each hole are normally the most reliable; however I've found from experience that that benefit is lost if you remove and re-insert the IC lots of times for external programming.  33 years ago I did this and the sockets got quite loose and had to be replaced.  My recommendation now, if you can't use a ZIF socket for that, is to use just use sockets with double-wipe contacts, which I think probably most sockets are today, meaning the contacts press against both sides of the IC pin, instead of just one side.

[BigDumbDinosaur]

Using a breadboard to prototype a computer circuit is always a crapshoot. In such an application, a breadboard tends to be like a politician, which means you are likely to be disappointed.

As for your parts list, where is your schematic? As I said to another person who is apparently about to get a comeuppance with his project (for the following reason), you are looking at rivets, but have yet to design the airplane. I highly recommend you develop a schematic based upon a realistic system, using Garth’s primer as a guide, and post it here so we can examine it and perhaps identify anything that might be a showstopper.

Garth’s suggestion that you use 74HC logic is one that I second. 74HC is more forgiving of dodgy construction methods than some other logic families, and will be fine at speeds up to at least 8 MHz. Definitely do not use any of the TTL families, e.g., 74LS, 74F, etc. Also, avoid 74AC for now, as that family has very aggressive outputs that may give a first-time builder (you) considerable grief.

Quote:

One thing I was wondering about is putting LEDs on the buses. Do I need latches or something for that?

Waste of time and LEDs, in my opinion. As Garth notes, you won’t see anything useful as the machine runs, unless you have Superman’s vision.

[BigDumbDinosaur]

GARTHWILSON wrote:

On the socket recommendation:  The machine-pinned ones with several little fingers inside each hole are normally the most reliable; however I've found from experience that that benefit is lost if you remove and re-insert the IC lots of times for external programming.  33 years ago I did this and the sockets got quite loose and had to be replaced.  My recommendation now, if you can't use a ZIF socket for that, is to use just use sockets with double-wipe contacts, which I think probably most sockets are today, meaning the contacts press against both sides of the IC pin, instead of just one side.

What Garth says.

Although sockets are to be avoided for a number of reasons, gold-flashed, machined-pin types are best used in applications in which parts must be removable, but are seldom removed. Double-wipes are more reliable when frequent removal is required. For a ROM, which may see frequent removal for re-programming, I recommend use of a quality ZIF socket for convenience (during the early days of my POC development, I was constantly monkeying with the firmware). See attached for a ZIF socket that I use.

socket_dip28_zif_aries526.pdf

Aries Low-Profile ZIF Socket

(536.37 KiB) Downloaded 191 times

[allisonlastname]

Ok, I have a partial schematic (see attached PDF). I haven't done the clock generation, reset button, or interrupts yet but I'll hopefully get those done soon.

I feel like the address decoding could be done a lot cleaner but I'm not sure how. I'm aiming to have RAM from 0000 to 7fff, IO from 8000 to bfff, and ROM from c000 to ffff.

[drogon]

allisonlastname wrote:

drogon wrote:

If you want to be able to control an LED then yes, you'll need a latch of some sort. I started with a 74als573 for 8 output bits. A 65C22 VIA is more flexible but also bigger (physically) and needs a bit more care & time to get going (but not much).

I was more thinking "LEDs on the buses for debugging", because I've heard of that being done before and I think it would be cool. I've done bare metal raspberry pi GPIO before so I can probably figure out how to make a 6522 go.

Like you, I have a bare-metal OS for the Pi to support my BASIC, but unlike the Pi, you've got to (a) wire it all up here and (b) write most of the code in assembler rather than C/Python/Forth/etc. Nice to read the stuff on your blog though.

However, you can boot a 6502 directly into C with a small hand-written "crt0.s" file using e.g. cc65 (I've done it as a proof of concept), you will need to patch the ROM with the reset vector.

But looks like good progress so-far.

I'd suggest is a slightly different memory map - 32KB RAM then 32KB ROM (with a small hole for IO) then you'll be able to run e.g. BBC Basic natively on it - but it's also easy for me to suggest that as that's what I did in my systems... However the 16KB from $C000 up is more than enough for e.g. EhBASIC and a small 'monitor'.

If you have a PiTubeDirect interface (ie. a big level shifter) then you can hook the VIA up to a Pi and use an 8-bit parallel transfer mode to use the Pi as a terminal - or bit-bang serial through the VIA. Or have a look at how the "slow bus" works on the BBC Micro - it's like an 8-bit interface driven through a VIA.

Cheers,

-Gordon

[allisonlastname]

drogon wrote:

I'd suggest is a slightly different memory map - 32KB RAM then 32KB ROM (with a small hole for IO)

How do you recommend mapping the hole? And would it be worth putting IO in zero page? One of the original 6502 manuals actually mentions doing it like that.

drogon wrote:

If you have a PiTubeDirect interface (ie. a big level shifter) then you can hook the VIA up to a Pi and use an 8-bit parallel transfer mode to use the Pi as a terminal

Arduino runs at 5v, so no need for a level shifter there.

[drogon]

allisonlastname wrote:

drogon wrote:

I'd suggest is a slightly different memory map - 32KB RAM then 32KB ROM (with a small hole for IO)

How do you recommend mapping the hole? And would it be worth putting IO in zero page? One of the original 6502 manuals actually mentions doing it like that.

No idea. I used a GAL in my designs so I didn't have to bother with all that TTL. It was easy in the GAL to map $FExx to a 256 byte page for IO and I have just one device - a 65C22 VIA.

The zero page thing was supposedly to save code (ZP addressing needing 2 bytes not 3) and make accesses go a cycle faster. Personally I think it's bogus today but in 1976 when speeds were low and memory expensive, then it might have been a thing.

drogon wrote:

If you have a PiTubeDirect interface (ie. a big level shifter) then you can hook the VIA up to a Pi and use an 8-bit parallel transfer mode to use the Pi as a terminal

allisonlastname wrote:

Arduino runs at 5v, so no need for a level shifter there.

I only mentioned this as you said you'd done Pi stuff before and wondered if you might be using one. I use an ATmega on my Ruby boards too, but it's somewhat different in that it can "see" a small part of RAM ($FFxx) in a mutually exclusive sort of way and I don't have any ROM - the ATmega copies the bootloader over.

-Gordon

[floobydust]

I also agree with Gordon on a smaller I/O window. For years, I've used a single memory page (256 bytes) for an I/O page. I've always located mine at $FE00. I don't recommend putting I/O in page zero.

I designed a small CPU board back in the 80's that use 3 logic chips:

- 7400
- 7430
- 74138

Using the above, you can have a memory map as:

RAM - $0000 - $7FFF
ROM - $8000 - $FDFF / $FE00 - $FFFF

I/O - $FE00 - $FEFF
- I/O is broken into 8- I/O selects, each at either 16- or 32-bytes wide.

Also, the write line for memory is qualified using phase 2 CPU clock, which is required.

I've attached a section of a schematic for this, albeit the I/O selects are done at 16-bytes wide, so only half of the I/O page is used.

Note that in the setup, the chip select for the 32KB RAM is tied directly to A15 from the CPU, which eliminates decoding it separately. You can also use a jumper for the write line on the 28C256, as these devices can be programmed insitu if needed.

You can also find the entire system with an I/O adapter on my github page.

[Paganini]

To be clear, the IC goes into the socket and never (or rarely) comes back out of it. It is the socket that is inserted / removed from the breadboard. The round legs on machine pin sockets are MUCH more durable for this use than the legs of dual-wipe sockets.

[Dr Jefyll]

allisonlastname wrote:

And would it be worth putting IO in zero page? One of the original 6502 manuals actually mentions doing it like that.

A perennially divisive question on this forum! And, a classic case of Your Mileage May Vary.

It's true as Gordon says that speeds are higher nowadays, and it's also worth mentioning that many typical applications are compute bound rather than IO bound, which means a substantial boost in IO speed will probably yield no appreciable gain. [see addendum]

So, the question becomes this: What sort of work will you be doing, and what priorities are important to you? IO in zero page does undeniably provide a substantial boost in IO speed... even if your speed was already pretty fast to begin with.

There's more on the subject here. My own 65xx machines all have IO in zero page because bit twiddling is an important focus for me. There are pros and cons but my own priorities are such that I have never regretted the decision for an instant.

ETA: bit-bang serial IO is the sort of code that can really benefit. And if you're shooting for a certain specific speed goal (say, blab-blah kilobaud on your RS232) then IO in zero page can make the difference between possible and impossible. Note that this applies even if the associated application is something compute bound like a BASIC interpreter.

-- Jeff