It's often seen as a stumbling block that EPROM programmers are expensive, and yet an SBC needs somehow to have some software to get started.

One approach is to use a single-stepping circuit and toggle the bootstrap into RAM. This is historically authentic but error-prone and tedious!

If the SBC uses an EEPROM, it could be made to be programmable in-place(*), once you've got a way to get your code into the SBC.

Or, combining the two approaches, it would be possible to toggle the bootstrap into EEPROM, so you only need to get it right once.

But in any case the bootstrap should be short. I found myself wondering how short, and this is what I came up with - 27 bytes of utterly untested machine code!


In hex, that's


Any comments or ideas on bootstrapping?

(*) Edit: I think some EEPROMs are particularly easy to program, but I might be mistaken.

27 bytes would not be too hard to do by hand. My COSMAC ELF used a hex keypad to bootstrap a program into ram. I used to write 25-80 bytes using that method.

For my first sbc, I built an eeprom programmer on a breadboard using 4 74LS373 connected to a PC parallel port. One held the data byte, two held the address, and one held the control bits (cs,rd,wr). The cost was under $15 as I used a scrap printer cable.

I had some trouble with the parallel port strobe line not strobing the latches right. I think I ended up using another handshake line for the strobe. I wrote the PC programmer code in QuickBASIC, using the Zicor 28C256 datasheet.

The process was no too complicated, as I recall. However, I had scrounged some 28C256's from a scrapped telecom key system, and I discovered that they had been write protected using a software lock. It took me a while to discover that and to write the unlock code, but I ended up getting it to work. New devices ship unlocked, so that should not even be a factor.

After my SBC-2 was up and running, I scrapped the PC programmer and created a programmer using a 6522 and two 74LS373's. The info on that is on my website under IO Devices.

An even easier solution is right here as well. I am willing to help anyone with programming an EEPROM. For the cost of return postage, I will program anything I'm able. I'm sure there are others here that would also be willing to assist. Just email or PM me with your device to be sure its one I can program.

Once an EEPROM is in a system, it could be reprogrammed in-system if designed to allow it. I have done that also with my SBC-2 system.

Daryl

The reset vector is at $FFFC, not $FFFE, so your code would have to start at $FFE3.

22 (untested) bytes is what I came up with. 253 bytes are always sent, which are stored on the stack (!) The order the bytes are stored in memory is the reverse of the order they were sent (!!) The RTS uses the last two bytes sent/pushed to jump to the appropriate place in the routine stored on the stack. RTI could be used instead, if you wanted to set up the flags before jumping.

Nice! I had a go with using the stack, but I didn't think of the RTS trick.

(Big oops on the reset vector!)

Cheers
Ed

You can get rid of that TXS instruction, since I believe S defaults to $FF upon CPU start up. At the very least, the WDC chips do.

Couldn't you also get rid of the INX if you used 0 as an EOF byte?

You can't use a 0-terminator, because 0 is a valid 6502 instruction, and it appears quite often in operands. It's better to transfer a fixed length chunk of binary data which, hopefully, contains valid code.

But you could almost certainly avoid 0 in the second-stage boot - which only has to load the next stage.

It's entirely possible to avoid 0. The problem is, to do so, you need extra code. To load zero into the accumulator, you need to do something like:

and so on. You'll end up consuming more space and running into more bugs than that one little INX instruction is worth.

It also means you cannot (conveniently) access absolute addresses with a zero offset byte (e.g., $0100, $0200, $0300, etc). Again, you would have to work around this by loading X with $01, and using $02FF as your base address. More code. More opportunities for bugs.

If you can somehow get your code down below 14 bytes, you could use a 74154 to decode A0-A3 and construct a diode matrix ROM. Maybe with two chips, you can use 32 bytes of diode ROM.

All true, but again, we save a byte in the bootstrap and possibly add a few bytes to the second stage. Any significant program is loaded by the second stage (presumably using a format which supports checksums) and has no such restriction.

Admittedly, saving a byte when we're already down near the 20 byte mark is hardly worth any extra inconvenience, but at this point I think it's a game of assembly golf.

(I think it must have been a typo, but I think Daryl's original response had the appearance of throwing down a challenge to reach 16 bytes.)

Cheers
Ed

Right -- I specified 14 bytes to give enough room for the reset vector.

I had a thought a bit like that: I think the Apollo Guidance Computer had ROMs implemented as hard wired arrays(*) It's a suitable technology for a retro bootstrap.

In my own case, if the bootstrap is small enough, I'd like to synthesise it into the CPLD.

(*) Quick check tells me that it was hard-wired ROM but using ferrite cores. I had an idea that somewhere in the past was a ROM design using wire alone, although I can't see quite how that would be done.

Back when I was toying with the Kestrel-1 design, one ROM concept I had was an optical matrix, where matrix rows were illuminated by LEDs, and columns were detected by photo-diodes.

Turned out to be more expensive than I would have liked though.

Hmm...

It's occurred to me that there's another way of achieving the same effect, and quite easily, too - especially for those of us with (almost any) 8-bit Acorn kit (and some 32-bit kit, too)

What I'm thinking of is the "User Port" - for those not in the know, essentially port "B" of a 6522 VIA, wired up to an IDC header under the front edge of the Beeb; a VIA expansion card was also available for most early ARM-based machines, too.

And, of course, if the SBC's VIA's "B" port is hooked up back-to-back the the "User Port", that still leaves VIA's "A" port, and its timers, available to the SBC...

--Martin

_________________
Martin Penny

.sig in beta - full release to follow.

I was looking at the docs (because I wondered if it was possible to do LSR status) and noticed that it appears that the code selects 7bit word length, if I read it right. It would be a bit dificult to write a second stage bootloader that couldn't even use load or store opcodes



edit: if we dont do neither TXS nor INX, and if LSR status had been possible, and if the 6850 had been in zeropage, then it would have been just 16 bytes total