Re: [N8VEM: 14649] 68008 SBC

["..I'd rather be coding ASM!" <uri...@deviate.fi>]

Hi Doug and Yoda,

Doug:
Indeed, I really do love the wiggle and test approach. It's something I 
can indeed get my head around and definitely don't want to get away from 
it.

I quite enjoyed the PS/2-30 story. Indeed a few strong lessons there, but 
in this instance if we were considering designs which required FPGA's due 
to complexity or speed requirements then we'd probably need to design in a 
reverse manner where we specify how the hardware is to behave according to 
the software interfacing with it and bug-fix the FPGA prom routines around 
what it "ought be doing". In this instance, compared to the PS/2-30 
experience, it was a shipped product and you ran (unfortunately) 
smack-bang into a hardware implementation you could not change the 
behaviour of.

Yoda:
I don't know terribly much about FPGA's yet, as I'm only just starting to 
look at them, but could we not simply jack the PROM and re-flash that, and 
the FPGA is in a as close to generic state as possible?

The reason I'm asking is that I've been faffing about with an old MIPS 
R2000 I dug out of my spares and have managed to bumble my way through 
some prom code to bring it up at 3Mhz and bang the states of two LED's 
off three some 795 shif regs. Looking at how I've breadboarded the decode 
logic I'm starting to get an idea of the headaches you lot have when
designing these things and the idea of FPGA's came up. Baby steps I guess.

Also I know a couple of people that work with FPGA's in the embedded world 
and freqently say it should be looked into if I'm headed towards higher 
speed devices down the track.

Al.

--
 --
 Al Boyanich
 adb -w -P "world> " -k /dev/meta/galaxy/ksyms /dev/god/brain