Actually, it looks like he's trying to implement a simple combinational logic circuit that implements his A[5:0]/D[7:0] truth table. That's why there's all this talk about the QM algorithm and other logic minimization techniques.


Making one's own bootloader could be a great learning exerpience. That said, doing it in the way he's suggested thus far probably will not be terribly practical or useful. And, for that matter, getting something like this to work using pedestrian 74HC logic on an already overclocked microcontroller is going to be a real challenge, and not a particularly intellectual one.

Combinational logic design is not just about getting the correct logic, it requires the correct timing as well; logic minimization will frequently affect timing, and it won't take that many 74HCxx propagation delays to push him past the program fetch timing requirements for his already overclocked microcontroller. Even if he wanted to keep it to two level logic and do a straight implementation using the SoP form straight from his truth table, that 74HC series 64-input OR-gate is going to be a bit elusive.

Although a "ROM" of the type you've suggested is nearly as ridiculous, the access time on something like this is likely to be a whole lot better, and stands a reasonable chance at working. Moreover, it's much more representative of how a bootloader would actually be implemented inside a chip.

I really don't know why Mike is being so obstinate after so many have told him that his design is obtuse. While I certainly don't have the decades of experience that the likes of you and Erik and Kai have, perhaps the most important thing I've learned about this business, is that whenever I set out to solve an embedded design problem, I ask myself, "how have others solved similar problems?" Then, I start looking. I peruse datasheets, descriptions of others' projects, and even the dialog of those far wiser than me here on 8052.com. Most of the time, asking a question of others isn't even necessary; there is plenty of knowledge to be synthesized just from that which has already been said. Only then, armed with that knowledge, do I begin my own design.


Yes, indeed! And, while flash and EEPROMs might be subject to corruption under some aggressive operating conditions, I never recall seeing any post-programming corruption in a 27C64 or similar (E)PROM device with its window properly covered. Even my more than decade-old SPARC machines which used 27C512 parts for their OpenBoot PROM still boot without difficulty!

If he really wants to build his own ISP system as a learning experience, I think that's great. However, using a device like you've suggested would open up the possibility of making a much more useful, richly-featured bootloader. And, for that matter, the implementation of a high-quality bootloader would probably be a whole lot more rewarding than trying to figure out how to "hardwire" 64 bytes of code. He could have the opportunity to learn, for example:

• how to autobaud a serial port
• that hardware-based serial communications, when configured properly, have no "synchronization problems".
• how to parse an Intel HEX file.
• design of glue logic, for entering into/exiting his bootloader mode, and, when in bootloader mode, making sure his system is in a reasonable state for programming (e.g., programmable EEPROM von Neumann-connected).

From a strictly pedagogical standpoint, using a ROM to implement a bootloader that if functionally compatible with the DS89C4x0 bootloader would be a great exercise; its interface is very clean and simple.


Perhaps from some AA cells in his pocket.

--Sasha Jevtic