How do you upload programs to your 6502 SBC?

[DRG]

On face value, it strikes me that there are quite a few ways of doing this. A confusing number of options really. What is good practice?
I also appreciate that the will be many different assemblers used by the board members here on 6502.org. That bit, I'm not so much concerned about. For my sins, I use vasm and I'm happy with it for my purposes.

However, the reason I started this thread is because I'm interested in two things...
1) Whether what I do is "acceptable" or whether it is unnecessarily complicated and convoluted and I should be doing X, Y & Z instead.
2) What your process is.

How I do things.
Well, I have two processes I can use: I started with a complicated one and have added a less complicated one recently. (In terms of serial communications, I use minicom on my Ubuntu 24.04 computer). I have a 65C51 running at 38400 baud, 8N1 and a 65C02 running at 3.8684 MHz.

Complicated: I have written (am still writing) a monitor. As part of that, I created an upload function. So, pressing "L" and inputting a 4 digit hex number gets the monitor waiting to read in data to store at the inputted location. In a separate console I run a python program I wrote that uploads a file to the 6502 sbc and also calculates and prints out a very simple checksum. The sbc also generates a checksum and displays this at the end of the upload so they can be compared. However, the data has to be in a specific format so I have to use the Fbin option with vasm. This is a simple binary output format with no address meta data - byte-to-byte mapping (hence why I have to tell the monitor where in memory to load it).

Less Complicated: I have a incorporated a "Wozmon mode" into my monitor which allows me to take input in the same fashion as wozmon. But, this means I have to use the Fwoz option with vasm (so it looks like "0400: 12 34 56 78 9A BC DE...") and I have a different python program that uploads that file. I can get around 1450 bytes per second via this method. I can also do a "Paste File" from minicom but it is much slower.

I read of others implementing Xmodem for transfers and S19 for formats!!! Hence, I'm interested in what goes on in the wild with you folks.

Dave

[GARTHWILSON]

The way I control my workbench computer, and send code to it, is written up at http://wilsonminesco.com/BenchCPU/#ctrl .  It is apparently the same as what Dr Jefyll developed, although he used a parallel link to the host computer instead of serial.  It does not require backgrounding or suspending the editor in DOS nor any TSRs or other special software.  My old boss who had moved on to another company said in 1990 that they had just spent $8000 on a C development system and they did not have nearly the interactiveness and development speed that I had with my very simple system.

[BigEd]

I think I used srecords when I was doing this. Simple line-based format, if it goes wrong you can see what's happened.

[barnacle]

Hmm, choices...

• Minimal board with eeprom: keep blowing the eeprom. They're good for 10k writes or more...
• Similar board with ram but no non-volatile storage: a carefully crafted program eats intel hex and spits it out into a format suitable for TTL serial streaming into an LV5183 chip: viewtopic.php?f=4&t=7757&hilit=lv8153
• Current board (still under design) uses a pi Pico for, among other interesting things, an initial program load of the processor which has access to a compact flash, so just needs to load a basic OS/Monitor. Reprogramming that requires a new .bin to be added to the C build.
• I suppose I could write a serial bootloader, but that doesn't sound too exciting

Neil

[BigDumbDinosaur]

I send S-records to my POC units over a TIA-232 link operating at high speed (115.2 kilobits/sec).  My process sends a record and waits for an ACK, CAN or NAK from the POC unit—there is a timeout feature to prevent deadlock.  An ACK means the record was received without error and processed.  A NAK indicates a checksum error with the most recent record, which results in it being resent.  A repeated error with the same record will cause the transfer to end.  Receipt of CAN aborts the transfer.

On a hardwired serial link, the basic checksum used with S-records is more than adequate for catching errors—transmission errors are not likely if the serial protocol is right.  No point in making it overly complicated.

[Yuri]

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

[AndrewP]

Pull ROM out, program ROM, plug ROM back in again.

I was using a UART based bootloader but it's slow and a bit quirky. Everything is ZIF socketed and I've gotten pretty quick at the program/re-insert cycle so that's working for me for now. I've briefly looked at something like the picoROM but haven't needed it that badly.

In the future I'm supposed to be going all in on the FAT32 file system on SD Card and - if I ever get there - will probably use an SD Mux like the SDWire.

[barnacle]

AndrewP wrote:

Pull ROM out, program ROM, plug ROM back in again.

I had not realised my 1970's philosophy remained so popular

To be fair, that's why I use Symon for the bulk of development but it has its limitations: for example, while its terminal responds to _some_ ansi codes, I haven't found a way to move the cursor beyond forwards and backwards, or to position it. Which is going to make developing a screen editor, um, interesting.

Neil

p.s. I've said it before: a 6502 variant with a USB boot loader and some useful amount of internal flash would be very handy...

[J64C]

I use an ATmega chip that I program as a boot ROM. It dumps the program in to RAM, resets the 6502, then goes in to tri-state.

Gives the advantage of being able to run the 6502 at 30+ MHz as there is no ROM access speed issues.

[plasmo]

6502 requires fast memory. Because RAM is so much faster than conventional ROM, I prefer to synthesize a small, fast ROM in CPLD to boot from either serial port or CF disk. The limited logic fabric in CPLD can synthesize about 64 bytes of ROM which is sufficient to wait for CF ready while looking for data from serial port. If CF ready is detected first, it will load and run program stored in CF’s master boot record; if serial port is ready before CF disk, it will load and run 256 bytes of binary serial data into a specific page in memory. For subsequent file load with serial port after bootstrapping is completed, I used Intel Hex format which is generated by many assemblers.

This method saved me the trouble of swapping in and out ROM. I programmed CPLD once in-situ, then used serial mode initially to load CF formatting software to enable CF bootstrapping, then used CF bootstrapping method to load most programs into 6502’s memory. If new program are added to CF disk, that can be done serially either with Intel Hex or Xmodem. This is the method for creating a fully loaded CF disk initially, then the CF disk can be duplicated via a disk imaging tool. It may seem complicated, but I used a macro scripting in TeraTerm to automate the process.
Bill

[Dr Jefyll]

J64C wrote:

I use an ATmega chip that I program as a boot ROM. It dumps the program in to RAM, resets the 6502, then goes in to tri-state.

Gives the advantage of being able to run the 6502 at 30+ MHz as there is no ROM access speed issues.

Yeah, it's nice how the no-ROM aspect makes the project simpler and potentially faster.

I developed a no-ROM approach which goes one step further: it also requires no microcontroller (ATmega) and no UART (although there is a simple link to the host computer). Depending on preferences, some folks will find this approach to be most preferable. See Ultra-minimal 3-wire Interface boots up 65xx CPU's

Edit: I see plasmo posted while I was typing. His approach is appealing, especially if the project will require a CPLD anyway.

-- Jeff

[BigDumbDinosaur]

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.

Before I commit something to the firmware, I test-run things by loading into RAM (S-records to the rescue).  Makes debugging a less tedious process, especially if the code being tested is a device driver.

barnacle wrote:

AndrewP wrote:

Pull ROM out, program ROM, plug ROM back in again.

I had not realised my 1970's philosophy remained so popular

The process persisted well into the 1980s.  All of the Commodore eight-bit machines had ROMs, so you can be sure firmware development involved plenty of ROM-yanking. 

[John West]

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.

The job that didn't have a ROM emulator had a big box with a UV light in it. Take an EPROM out of the box, burn it, swap it into the board (ZIF sockets? What a luxury!), and put the old EPROM into the box at the other end, shuffling all the other chips along. By the time it reached the front of the queue again, it'd be erased.

[barnacle]

They did exist, and I recall using them, but I also have an idea that they weren't cheap, at least in the seventies.

I suppose that if the more available memory is dynamic, you need a lot of stuff going on behind the curtains to make it appear as a static rom. By the eighties, there were chips like the 2114 (1kx4) and 6116 (2kx8) which would have made it a lot more simple.

Neil

[BigEd]

Ah yes, I’d forgotten ROMBO. From a previous thread:
viewtopic.php?p=52556#p52556
(Programmed over i2c, in my case using a USB adapter)