Page 2 of 2

Re: Bootloader terminology

Posted: Sat Aug 28, 2021 11:37 pm
by plasmo
kernelthread wrote:
There's also this scheme:

https://www.ecstaticlyrics.com/electron ... rogrammer/

Here there's no ROM of any description, not even 32 bytes crammed into a PLD. Instead, the Z80 directly executes opcodes sent by a host via an FT240 USB interface chip.
While it is a rambling description of an interesting design, I do get the neat approach of using FT240 flow control to pause Z80 execution. This solved the problem of booting from a FIFO port by feeding Z80 every instruction to be executed, including periodically a jump to 0x0 so not to exceed the 16K program space allocated to the FIFO port. Compact flash data port is also a FIFO port but limited to 256 words in depth, so when booting off a CF disk, a different technique is required that builds an executable bootstrap code which, in turn, loads the real application. In Z280RC the sequence of bootstrap is: state machine initializes the CF disk to read master boot sector --> Z280 executes the 256-word FIFO data stream from CF to build a bootstrap code in memory-->jumps into the bootstrap and read additional CF sectors to get the application program-->jump into the application program.

I was also interested in the challenge of building a retro EPROM programmer in through-hole technology without having programming tools of any kind, no CPLD programmer, no EPROM programmer. So the immediate question is how to boot the retro EPROM programmer and load the data to be programmed without having a EPROM in the first place? My solution was using Z280 because it has a native serial-bootstrap capability. ZZ80MB has two modes; a EPROM programmer mode where it boots from a 256-byte bootstrap coming in via Z280's native serial port and then the bootstrap program loads the programming algorithm and data to program the popular SST39F040 flash memory. The other mode of ZZ80MB is normal SBC mode which boots off EPROM and communicate with console.

I'm interested to hear other ways of building ROM-less EPROM programmer using retro hardware. It is a chicken-and-egg problem.
Bill

Re: Bootloader terminology

Posted: Sun Aug 29, 2021 12:13 am
by cjs
plasmo wrote:
I'm interested to hear other ways of building ROM-less EPROM programmer using retro hardware. It is a chicken-and-egg problem.
Not really, if you're a patient person. Everybody already has an EPROM programmer: it's known as a breadboard and some wires. :-) (Less patient people may find that a pushbutton and possibly even some switches helpful.)

Re: Bootloader terminology

Posted: Sun Aug 29, 2021 3:36 am
by GARTHWILSON
cjs wrote:
plasmo wrote:
I'm interested to hear other ways of building ROM-less EPROM programmer using retro hardware. It is a chicken-and-egg problem.
Not really, if you're a patient person. Everybody already has an EPROM programmer: it's known as a breadboard and some wires. :-) (Less patient people may find that a pushbutton and possibly even some switches helpful.)
That was my start. It was slow; but the biggest problem was that it was so error-prone. If you have EEPROM though (which I don't think existed when I started), you can fix an error without erasing the whole thing and starting over. Then I found out my DIP switches were not rated for nearly enough cycles to be very useful for a programmer; but soon, fortunately, a friend who had made a programmer controlled by his HP-71 hand-held computer helped me out.

Re: Bootloader terminology

Posted: Sun Aug 29, 2021 6:50 am
by John West
plasmo wrote:
I'm interested to hear other ways of building ROM-less EPROM programmer using retro hardware. It is a chicken-and-egg problem.
This was my solution. It's designed for the AT28C256. I could have bought a programmer, but for that project I wanted to do things the hard way.

The first draft didn't have the "increment address button". That turned out to be the much too hard way. This version isn't too bad to use. Set up the address, press "load", set up the data, "write", then "inc" and set up the next byte. The data LEDs show the current contents of the ROM, so it serves as a verifier as well.