How do you upload programs to your 6502 SBC?

[drogon]

I have a few little 6502/ 65816 and 6507 systems.

The 6502 and '816 systems are "romless". They have an AVR MCU which has a non-exclusive shared memory interface to the main 65xx RAM. IT can poke a little bootstrap (<200bytes) then take the 65xx out of reset which then runs and uses a simple communications protocol to get the rest of the OS over to the 65xx side.

The AVR runs the filing system on a local SD and I wrote my own File Transfer Protocol which runs from a "smart" terminal on the host PC side (Linux) and has the ability to exchange files from the host PC to the SD card. The OS on the 65xx just sees the filing system so it doesn't really know that a file has been transferred over.

To update the bootstrap (Not changed for over 6 years now) or update the OS that runs on the 65xx I built it on my Linux PC then re-build the AVR code which picks up the 65xx binary and encodes it as a table in the Flash memory of the AVR. I did look at having it on the SD card which would free up space in the AVR but it's not really needed.

On the 6507... It's a bit more "traditional" in that I have an EEPROM which I remove from the 6507 board and inset into my "EPROM" programmer, send the code to it then move it back to the development board (Which has a ZIF socket). That's the 4KB TinyBasic. For the actual basic programs, I get my terminal program (minicom) to send text files over the serial line but adding in a small delay (80ms) at the end of each line sent as the TinyBasic interpreter needs some time to store the line away in RAM.

I've found (5v/TTL) serial to be 100% reliable at this point - no different from those creating text representations of binary files in Wozmon format and sending them over a serial line... The FTP on the 6502 and 65816 boards currently encodes files into a textual uuencoded format because at the time I couldn't be bothered writing something more to handle file sizes, etc. in an otherwise binary stream and I already has some ancient libraries to handle it.

-Gordon

[Yuri]

BigDumbDinosaur wrote:

Yuri wrote:

I usually reprogram the ROM, though I've gotten very good at just doing a copy and paste into wozmon over the serial port.

I did a lot of that in the early stages of developing my POC V1.0 unit.  With each successive unit, the ROM-juggling became less frequent.  My most recent change to POC V1.3’s ROM was the new-and-improved™ S-record loader.

My goal is to start trying to get a more comprehensive monitor in place that can handle larger records, and have a nicer editor for the monitor, and more features.

Slowly getting there, having fun hacking code for it. ^^

[enso1]

I added an 'L' command to wozmon, which load a binary file with a two-byte prefix:
- one-byte page location
- one-byte page count (and I pad the file to page boundary)

The page arrangement makes the loader very simple.

The loader immediately executes the loaded code (most often what I want, and when I am just testing code, I start with 'jmp _wozmon'...


It is simple and compact, and my assembler (kingswood) outputs it directly.

[Michael]

John West wrote:

In the 1990s we had ROM emulators, and they are such a useful and obvious idea I'm sure they must have existed in the 1980s and 1970s too. Replace your ROM with a ribbon cable to a small board containing a RAM, some counters, and a little logic, with the other end plugged into your PC's printer port. In the 1990s we still had printer ports. Copy your binary to the printer device, press the reset button, and away you go.

ROM Emulators really are pretty neat. I use a $2 Arduino Nano clone as a built-in ROM Emulator / Programmer of sorts in a reasonably economical variation of the simple Garth Wilson / Ben Eater 6502+6522 board designs. My design uses 64K RAM which is loaded with a 64K image from ROM at a leisurely 1-MHz clock rate by the ROM Emulator at start-up, after which the clock is automatically set to a pre-selected 1, 2, 4, or 8 MHz. I also use the 32-pin ST39SF010A Flash ROM as an economical alternative to the much more expensive 28C256 EEPROM. My design eliminates the need to purchase an EPROM programmer and can actually be used as a simple inexpensive stand-alone programmer for 32K 28C256 EEPROM's and 128K ST39SF010A Flash ROM's.

I have to say having a full-blown ROM Emulator is a developer's dream. A simple push button press switches between Run mode and Emulator mode where I can download one or more code segments, iterative code changes, or full 64K code images directly into RAM at 115,200 bps via the ROM Emulator serial interface. I can also program the 64K 'A' or 'B' portion of the Flash ROM directly from the image in 64K RAM (takes about 9 seconds).

Have fun, guys. Cheerful regards.

[NeonGuppy]

@Michael

That is a facinating concept. Are you willing/able to share the code running on the nano?

[BigEd]

(Indeed very nice project: it looks like Nano runs at 5V, so no difficulty with voltage levels. It looks like perhaps the Nano's USB connection is used to power the whole system, as well as the means of updating ROM images?)

[Michael]

NeonGuppy wrote:

@Michael

That is a facinating concept. Are you willing/able to share the code running on the nano?

I would need to clean up the Arduino ROM Emulator code before sharing. It's functional but more 'experimental' than 'finished'. I'll dust off the project and try to spend some time on it.

BigEd wrote:

It looks like perhaps the Nano's USB connection is used to power the whole system, as well as the means of updating ROM images?

That's Correct. SBC Power and ROM Emulator serial connection are via USB to a host PC.

Cheerful regards, Mike.

[Martin_H]

When I am programming in Forth I send the source file from the terminal emulator on my Windows host. I need to make sure the character send rate doesn't overrun processing rate of the Forth interpreter. The Forth interpreter compiles and executes.

When I am using assembler I more often than not program an EEPROM and plug it into the board. It's honestly pretty speedy.

When I am using the W65C265S I send the Motorola s-record format file to the onboard monitor ROM. I am honestly not sure if that's faster than programming an EEPROM.

I tried self-hosting using flash memory but never got very far with it. Mostly because the first two methods are a massive crutch.

[gfoot]

These days for development I mostly use small ROM-based bootloaders that load the next stage from a serial link. It's quite fast, much faster than unplugging EEPROMs - though I do like the physicality of doing that.

The host software is something custom I wrote in Python, because I was unhappy with the generic functionality off the shelf terminals provided. It provides interactive I/O but also listens for command codes from the 6502 system which allow it to request loading files. In some cases I make the host software then prompt me with a list of files to choose between; in others I've let the 6502 system say which file it wants as part of the request. The transfer protocol is a bespoke one that's very simple on the 6502 side - it just streams the data into memory a block at a time, sending back a two-byte checksum after each block which is extremely easy for the 6502 to calculate. The priority was really to make the receiving code reliable but very compact. I don't bother with retries on checksum failures - they only happen when something is badly wrong with the system anyway.

On my latest computer I made it optional whether it boots the OS from EEPROM or from serial. Loading from EEPROM is much faster, so I use that if I'm working on application code, but if I'm working on the OS itself then I switch it into loading the OS over the serial link instead. Either way it gets copied into RAM before running it, so it's all the same from that point on. Eventually I also made it able to rewrite its own EEPROM, so when I've finished working on the OS I can update the ROM version without having to remove it from the circuit. This is done by having the host software send the ROM flashing program instead of sending the OS kernel - the 6502 system streams it into RAM and executes it, and the flashing program can then request the host to send the ROM image, and burn it to the EEPROM.

Something I want to look into is having the host system be able to reset the 6502 system, or even be able to power it off and on. I considered using serial breaks or UART control signals to do these things - but haven't implemented anything yet. I recently switched to a new FTDI adapter with optocoupled outputs because I was having issues with ground loops but the new one only provides the RX and TX signals so options are a bit more limited now.

[Yuri]

gfoot wrote:

Something I want to look into is having the host system be able to reset the 6502 system, or even be able to power it off and on. I considered using serial breaks or UART control signals to do these things - but haven't implemented anything yet. I recently switched to a new FTDI adapter with optocoupled outputs because I was having issues with ground loops but the new one only provides the RX and TX signals so options are a bit more limited now.

Perhaps use an Arduino or Raspberry PI to this? Both of which can listen for commands on a different serial port, that your Python program could send commands to.

[gfoot]

Yuri wrote:

Perhaps use an Arduino or Raspberry PI to this? Both of which can listen for commands on a different serial port, that your Python program could send commands to.

Yes, in that case the host program could just run on the Raspberry Pi instead of on a PC, and use GPIO as well as regular serial communication.