Re: Weird behavior of dd



The Natural Philosopher <a@xxx> writes:

No, but you do.
That's where you start writing code to control them - a BIOS if you like.

OK

The usually a library of IO stuff over all that..I rewrote the stdlib
essentially..so things like gets and puts and printf and fopen existed..

This also goes into the "BIOS"? What do you mean by "over all that"?
Do you mean you used gcc as a cross compiler on a Linux system to your
PIC (or whatever) and used your own version of stdlib as the library
to call when you compiled it?

The "BIOS" got burned to a ROM chip?

A multitasking kernel is not that hard if you have timer interrupts
available. Just make yor library re-entrant, or with multitasking in
mind. I cheated and just made any call to the hardware library make the
calling thread full priority and uninterruptible. Like switching off
scheduling for th eduration.

OK.

I always heard that DOS wasn't re-entrant and sort of knew that meant
DOS routines had to return without calling each other or calling themselves.
I guess the way to avoid that is to have a stack of some kind on which to
store registers every time one calls another routine and from which to pop
them when the call to the 2nd routine is completed?

I'm probably not ready for writing a multitasking system, so I'd probably
cheat the same way for starters.

The last task was to port a FORTH interpreter to it all. And a basic
sort of 'command.com' type shell.

Where did this FORTH interpreter live in the resulting system?
Who talked to the FORTH interpreter if everything was in assembler?
Was this for being able to program your PIC in FORTH?

The hardware emulator isn't strictly necessary, but it makes tracking
bigs a lot faster. I had one obscure one where the machine would lock up
every few hours. Turned out to be a timer interrupt in a critical piece
of code..

Apparently, there is an intel x86 simulator called bochs. I may have
downloaded it once but was unable to figure out how to install it.
I guess I can try again. According to the description at sourceforge,
Linux, Windoes 95 and Windows NT will run on top of the simulator.

Actually the simplest thing to get going these days is a PIC. I'd start
there.

Thanks, I'll look into it. At www.piecmulator.com there are links to various
PIC emulators.

You can always use it as an IO controller for a bigger machine later..

You mean, e.g., I take my ancient PC and have it use the PIC as an IO
controller somehow? Or do you mean that I can take some of the components
of an old PC and have the PIC control them instead of the BIOS and OS
of the old PC?

embedded systems is the whole name of all this stuff..making processors
and ram int a computer that doesn't necessarily have a console or a
disk. Its huge fun.

That sounds very interesting. How expensive is it to do this with one PIC?
What about having a lot of PICs running together as a kind of multiprocessor?
At what point do you have to stop using your wall socket and have to start
designing special purpose power supplies to handle all the PICS?
--
Ignorantly,
Allan Adler <ara@xxxxxxxxxxxxxxxxxxxx>
* Disclaimer: I am a guest and *not* a member of the MIT CSAIL. My actions and
* comments do not reflect in any way on MIT. Also, I am nowhere near Boston.
.