From: Jim Brain (
Date: 2007-12-18 06:17:32

David Wood wrote:
> I should acquire the free edition of EAGLE.  I haven't used it for ages.
> More often than not, my ideas come up when the only handy thing is a sheet
> of paper and pencil. :)
EAGLE has its quirks, to be sure, but the price is right, and it seems 
most of the hobbyist crowd use it. 

> It's not.  Ive read parts of the 134 datasheet, and find it can be handy for
> a few things.  In order to get I/O -and- system bus though, you'll need to
> use a high-pin-count package.  Not exactly home-soldering heaven. :(
No, and the fact that you can;t get a DIP version for hobbyist builders 
and do-it-yourselfers might kill it.  I considered it since it has some 
IO built in, and I think I saw you could create some defined chip 
selects from inside the MPU. If one was starved for space, and was going 
SMT anyway, it might be worth it.  Minus the internal ROM, though (yuck)

> Correct.  Ive heard of loaders that use illegal opcodes in the NMOS 6502.
> However, the same breakage an '816 would cause would also be caused by a
> 65C02.
Yes, I like your idea, as a design-in for a 816 versus an 02 is trivial, 
and you cna have so much more.
> Meh.  I need to look more into WDC's microcontrollers.  I've glanced, but
> I'm not impressed as yet.  Theyre -very- microcontroller-like.  Tiny ram,
> big ROM.  If youre going to be buffering things, you'll need (relatively)
> large external rams, so why not just use a discrete system?  I welcome
> commentary and more light on WDC's controllers if someone else is more
> familiar..
Mainly the built-in peripherals.  Adding a USART and triggered chip 
select lines to a descrete design is no biggie, but space might be an 
issue.  I like to keep IC count low.

> This leaves another consideration of course.  How does one get the firmware
> to the drive, initially, and how does one recover from inadvertently
> bricking the project with a bad firmware image?  These are way ahead of the
> design, but should be considered somewhat during the design phase when
> considering boot RAM/ROM.  Flash is always an option.  It works well for the
> Retro Replay.  I lean toward the use of flash for the bootloader that
> contains enough intelligence to write a new firmware image to the disk, a-la
> the CMD HD's DOS.
I considered the following:  A basic mini-DOS built into kernal, that 
understood IEC, understood command channel and buffers, and understood 
how to get the first few blocks of IDE disk.  Use that to bootstrap the 
larger OS, which would then swap out the mimi-DOS when loaded.  If you 
brick the drive, just hold a button down to prevent the auto-load of the 
OS and run the little floppy disk you got with the drive.  Maybe offer a 
serial port to bootstrap it the first time from a PC or Mac as another 

Yes, the idea is getting a bit ahead of oneself.  Still, the more I have 
to consider, the easier designs go.


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.