1st stage loader for IMSAI - need ascii to binary conversion

[Tony Duell]

> > 'Easier maintainabilty and tweakaility'. Surely you jest here!
> 
>    Not at all.  Read on and I will explain my position.
> 
> > It is a
> > lot easier to find a fault in a circuit when you can actually put the
> > 'scope probe on a particular signal. Darn it, with a single-chip
> > microcontroller, you can't normally trace the firmware.
> 
>    In the context of a small microcontroller like the ones we're  
> talking about, these things just don't have that much code space.   
> Almost none of them allow self-modifying code.  Nearly all of them  
> have small, simple instruction sets.  If the programmer NEEDS to  
> actually trace the firmware to find a bug, I'd question that  
> programmer's competency.  Seriously.

OK, so I;m an incompetent programmer. I'm happy to agree to that. Because 
I certainly deug firmware (where possible) by hanging a logic analyser 
off the address lines and seeing where the code is going. If you can do 
it without, great!.

Let me give you an alaogy. _I_ once tracked down a logic fault in a P850 
by noticing some odd behviour of the front panel bulbs, in particular 
that half were brighter than the other half. Knowing that it's really an 
8 bit machine interlally made me suspect that one half of the data wasn't 
being latched properly. That lead me to a missing latch strobe signal, 
and so on.

On the other hand, most of the time I use a 'socpe and/or logic analyser. 
I like to debug by figuring out what the unit is doing and comparing it 
with what it should be doing. And I like to debug firmware the same way. 

> > I'd
> > much rather change a 2-lead passive compoennt than reprogram a chip  
> > (and
> > it'll be quicker...)
> 
>    Well, personal preferences aside, it might be quicker and it might  
> not.  I can type "make burn" at a shell prompt in the terminal window  
> to the right of this email message and squirt an entire new code  

I could do much the asme thing (admittedly on a different virtual console 
trather than window, but...) And a good few minutes later, I'd have the 
object code (remember I _don't have_ a fast PC).

> image into the Philips ARM7 chip I'm working with in less time than  
> it takes my (fast Metcal) soldering iron to heat up...and that code  
> image has BIG stuff in it like an IP stack.

On the other hand, my sodlering iron is hot right now :-)
> > bodging together off-the-shelf units, which is another thing I  
> > dislike...
> 
>    ...and I dislike it as well, and I'd never do it.  Not everyone  
> who uses a microcontroller is boding together off-the-shelf units or  

Of course not...

For the record I have used, and do use, signle chip microcontrollers. In 
front of me is a little interface I built. On one side is a Centronics 
printer connector that links to a PC parallel port. Coming out the front 
is a cable ending ia a tiny 2-pin plug. That conencts to a modified HP41 
barcode wand module (!). You hook it up. run a program on the PC whcih 
takes an HP41 program and effectively simulates running the wand over the 
barcode version of that prrogram. Result : Download from PC to HP41 
without HPIL. 

Now, that interface contains a few TTL chips to handle the Centronics 
handshake and a microcontroller. It's sufficiently old that it's a 
PIC16C84. TO do it all in TTL would have been very complicated, difficult 
to debug, and so on. I feel that a microcontroller is the _right_ 
solution here. 

Ditto for the HP48 RS232 port to I2C interface (just a PIC and a MAX232). 

However, I still feel it's not the right solution to use a microcntoller 
_and tone decoders_ to decode cassette audio. Doing the whole thing in a 
microcontorller might be, but I probably woudln't do it that way. But to 
combine the output of the tone decoders? No, I think it's overcomplicated.

-tony