Does a crazy man not think he is crazy?


Mike, we've all tried to point out the fundamental flaws in your approach. Unfortunately, you have half an idea, and half of that is wrong. It not that any of us couldn't get an eeprom to be loaded with code via the parallel port, so there's no proof needed as to if it could be done. Given your box of parts, I'm sure most of us could solve your basic criteria of being able to load code from the PC into your eeprom. Most likely we would:

1/ Use the serial port as it is easier, less wires and Windows supports it. It also allows us to use Hyperterminal or your terminal program of choice to download the code with - this means we don't need to write a special application on the PC

2/ We would most likely have bootloader code.

The net result is that our design would converge quickly.

Regardless of how you store your boot code, to get any sort of functionality on 16 bytes is most likely pushing it. We could have a competition to see who could do the most in the least bytes - but to what end. In 1970 it would have been reasonable as you had to key in the bootloader by using switches on many computers - so less bytes would have been a bonus. We have no such constraint these days.

Doing the interface via the parallel port has fundamental problems - as you're finding. Having the cpu wake up with the bootload code and poll the parallel port for bytes will most likely require more than 16 bytes of code. At best you might be able to write code to load,say 128bytes via the parallel port into ram then execute it - you might be able to squeeze that into 16 bytes. By the same token, one could do the same with the serial port - and probably easier.

Something like:
org 0
mov r2,#128 ;128 bytes- change to suit taste
mov dptr,#8000h ;point to ram - hardware maps it into code space also
loop:
jb P1.0,loop ;wait for strobe low
mov a,P3 ;read byte
movx @dptr,a ;store into ram
inc dptr ;->++
loop1:
jnb P1.0,loop1 ;wait for strobe high
djnz r2,loop ;loop for 128 bytes
ljmp 8000h ;run bootstrap

It's no use pissing about with interrupts. Once the 128bytes of code is loaded via the parallel port into the ram, it runs that code. With 128bytes of code, you can implement fancier code to load the eeprom. All this would happen in less than a second I would guess. So your challenge is to make this code smaller and fit into 16 bytes without losing the functionality. I know a couple of tricks I could pull.

Using a two stage boot process is not a new idea- in the old days one would load the initial boot via the front panel switches that would read the next bootstrap from floppy or paper tape. It might work for you......