Alright, this isn't my first 6502 single board computer. I recently put together this one, and everything's just grand.

There are a few things I don't like about the design, and the design of most of the SBCs I see. First, there's the issue of having to remove the ROM chip to reprogram it. I know we're just dealing with 27Cxx and 28Cxx chips here, and a programmer is easy enough to bitbang with a microcontroller, but having to remove the ROM from the circuit just doesn't scream elegance with me. Secondly, the use of MAX232* and - gasp - DE-9 ports - just strikes me as antiquated.

With that being said, here's my pitch: has anyone ever looked into using a modern microcontroller to reprogram the ROM and provide a serial interface? There's this project that can program a 28Cxx ROM with an Arduino and a pair of shift registers, and I've seen a few people looking into using an ATMega32U4 instead of a MAX232 chip.

I'd really like to come up with a minimal 6502 SBC that's just CPU, ROM, RAM, and glue (with the data, address, and CS lines broken out on a header), but with the added features of a USB serial port and ability to reprogram the ROM in circuit. I know this is possible, but it's just one of those things that seems too obvious and should have been done already.

Just throwing this out there to get some feedback, really.

You mean 1 main computer programming the OS of the second computer? i.e. multiplexing the slave computer's address and data buses for the OS?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Yeah, pretty much multiplexing the data and address lines onto a small microcontroller so it's able to program the ROM. You can set the pins at High Z, so I can't see how this wouldn't work.

And with the microcontroller idea, you also have the option of using it as a serial output, at the same price (or lower) as a Max232 chip. Hell, you could probably generate your clock signal with it.

I did this type of system for my first SBC on a C-64 over 20+ years ago and it was very rewarding. Although I had to have my C-64 rebuilt many times due to my errors in wiring... But
I advocate any 6502-SBC have the capability to program a sister 6502 project. No EEPROM until it is un-tethered. It is using a RAM for development. A RAM that is selected by the board it is on, or the master.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

It looks like a ATMega32u4 is in TQFP 44 pin package. This is a package which is less than a half-inch per side - 10mm x 10mm.
There are 11 pins per side with a pin spacing of 0.8mm. A standard DIP package has a pin spacing of 0.1 inch or 2.54mm.
So the pin spacing is three times denser than a DIP package.

Most of the homebuilt 6502 SBC are either hand-soldered or wire-wrapped. A tiny TQFP package with tight pin spacing is not very hand-soldering friendly.
It is also not socketable, so not very wire-wrap friendly either.

Once you figure out how to mount the ATMega32u4, you still need to give it access to the EEPROM or other device.
It looks like the ATMega32u4 has 20 bits of usable I/O on ports B, C, D, and E.
You need 8 bits for data, 1 for R/W, 1 to request the bus, so this leaves about 10 bits left.
So the ATMega32u4 would only be able to program about 1k of EEPROM.

Assuming you manage to connect the ATMega32u4 into your SBC somehow, you still need to program the ATMega32u4.
It looks like it has a JTAG interface, so you need some sort of JTAG interface to load code into the ATMega32u4 and an AVR debugger.

Now that you can load code into the ATMega32u4, you still need USB code to load into the ATMega32u4.
You reference it as a "USB serial port" which sounds like you are underestimating the complexity of USB.
This is basically the same as saying "Ethernet serial port" which handwaves the complexity of the protocol.
USB is a packetized protocol which requires a protocol stack, much like Ethernet requires a TCP/IP stack for most purposes.
From what I can tell, a minimal USB stack requires about 16k of code.
So this needs to be acquired somehow and ported.

After all this, you're actually ready to load code into the 6502.

Toshi

My SBC-4 uses a microcontroller to program RAM on power up from its internal FLASH and then release the 65816 (65c02 would work the same) to run from RAM. No EEPROM at all. An added bonus was that you can add I2C EEPROM modules to the microcontroller and have different applications loaded on different modules. These are self-programmed by the micro controller from system RAM. I used a dual USART to provide communications between the 65816 (65C02) and the microcontroller.

Check it out here:
http://sbc.rictor.org/info4.html

I never did the 65c02 design as there was not much interest in the 65816 version. It would be easy to use 64k of RAM in place of the 512k and the CPLD could be replaced with a handful of descrete's (I know the XC95xx series is hard to get now) or a more available CPLD could be used.

It also features add-on IO modules to custom tailor your platform.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

TIA-232 may be "mature" technology (it's been around since the 1960s). However, you'd be amazed at how much TIA-232 hardware is being used in new installations, especially machine controls. Your perspective is being constrained by what you see (more correctly, what you don't see) in modern(?) PC hardware.

USB is a consumer interface designed to attach cameras, scanners and cheap printers to a PC. It was never designed to be a system interface, and in fact, does relatively poorly in such an application.

For all of its seemingly wonderful features, USB has two glaring weaknesses: protocol complexity and lack of distance. The latter is especially important in industrial/shop settings, where it may not be desirable or practical to place a computer close enough to a machine to make USB work. USB's outer limit for distance is around 5 meters, whereas high speed (115.2Kbps) TIA-232 can go as much as 100 meters with the right hardware and cabling—or many kilometers with inexpensive short-haul modems. Even faster is TIA-488, which can run at over a megabit/second in a shop loop or at slightly lower speeds over considerable distances. Even wired Ethernet can't match TIA-488 for distance vs. speed.

One of my clients uses a TIA-232 link through a rented TelCo line to drive a line printer in a warehouse two blocks away from the main plant. A short-haul modem at each end attaches to the TelCo line and the usual TIA-232 hardware hookup is used between modem and printer, and modem and server. Because the TelCo line carries no switched traffic—it's basically a pair of point-to-point wires with a repeater and echo cancellation—the modems are all by themselves and don't have to contend with the inevitable noise pickup that a switched pair would see. The link has worked reliably for 16 years and will run at 57.6Kbps no matter what.

The only other way to make this particular setup would have been to provide Internet service to the warehouse, complete with a static IP address, DSL modem and router, at a cost of about three times per month what the rented TelCo line sets them back.

TIA-232 also has the advantage of being a well-understood and stable standard that is adaptable to many applications, using inexpensive and easy-to-program hardware. The same can't be said about USB. If all else fails and I need a way to get data from machine A to machine B, I can do it with a serial port at each end and a suitable cable that I can fabricate on-site. Try that with USB.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

In the Newbie section there was discussion of just this kind of setup. A 6502 main board with a "magic chip" (likely a micro controller) that provides ready access to typical PCs, such as being able to load a program from a serial connection on boot, etc.

When the development is done, the downloader part can be removed to leave the standalone board.

I've always used a ZIF socket for EPROMs that had to be removed and replaced a lot of times in development (although with my Forth system, I have not had to re-do the ROM in many years, and with that in place, I can develop all my applications in RAM).

_________________
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?

Luckily, this work has already been done: http://www.fourwalledcubicle.com/LUFA.php

Also note that while writing a USB host protocol is quite a bit of work, the USB client code for something like a serial device is much simpler. I just checked my latest project, and the USB client code was less than 2kB (ARM Cortex M0)

You can even replace the complete 6502 with it as some 6502 emulators on microcontrollers show.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Note that the microcontroller still needs the MAX232 (or other line driver/receiver-- I prefer the MC145406) to convert TTL-level serial to RS-232 levels.

_________________
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?

I think the idea is that the microcontroller is attached to USB, and implements a virtual COM port.

I'm pretty sure that this could be done using one of the WDC microcontrollers (65c134 or 65c265, based on either the 65c02 or the 65c816); it looks like it should be possible to build something useful with just the controller chip, RAM, ROM (maybe in a zip socket), an oscillator can or two and some sort of USB/serial interface. There should be minimal need for glue logic, as the chips themselves can generate chip-select signals (assuming that the available chip-selects match your requirements.)

Both these microcontrollers are available from mouser. They come with mask-programmed ROM that I am 99.99999% sure contain a monitor program.

I checked with WDC. Here's the reply.



We should put these documents in the archive.

Toshi