Re: Standard way of graphics in Linux

On a sunny day (Fri, 22 Sep 2006 11:16:18 +0200) it happened Herbert Kleebauer
<klee@xxxxxxxxx> wrote in <4513A9E2.67AEB772@xxxxxxxxx>:

But hey, that level is too high still?
OK, what is a transistor? Well, now it gets a bit tricky to make one yourself,

Don't think you have to go to the analog level for designing a CPU.

Ok, FPGA, nice, on is a processor generator.....
But that would not be fair, for students that would be cheating.
'analog; if you refer to transistor, it is not really such an analog
element as you may think, the linear range is only small, and
not even linear over the full range.
Delta Ic / Ib is close to linear, but if you look closer the gain changes for
Ic, MOSFETS are also not linear, have a cutoff....

But surely you should be aware that any digital signal in reality
is analog (just take a scope and look at the digital signals, sometimes
it is nearly unbelievable, that the digital components can find
"0" and "1" in this analog mess).

mm, I am in electronics, you need a better scope ? Better decoupling,
but yes, there is undershoot, overshoot, but Von and Voff are somewhere
defined, all you have to do is pass it.

but hey, no probelm, we will use relays.
So, if you are a man, use relais, hardwire the program.

I thought about it many times. The CPU wouldn't be the problem. The
problem is to find a simple way to implement memory.

I have seen analog memory made by using a poly cap on a MOSFET input.
Then a neon bulb via a resistor and switch to +100V or -100V.
So if you connected to +90V, the neon would light (70V or so) become
low impedance, and via the resistor charge the capacitor on the gate.
Discharge happens when you connect to -90V.
Vgs was never bigger then + or - 10V, so safe.
I think Siemens used this to set volume and color in the old TVs,
with 2 push buttons 'up' and 'down'.
I figured out that circuit when I had to repair one.

A bit like FLASH memory....
With some comparators on the output (read an AD) you could store at least
a 4 bit number that way.

Magnetic core memory was very popular too.

I don't say, you should do anything at the lowest possible level.
But you should understand this low levels so you will be able
to use the high levels in a way, that it can be efficiently translated
to the low levels.

If a programmer doesn't know that a div instruction is much more
time consuming than an add instruction, how should he then know to
better choose a HL implementation which requires less divisions
and more addition instead (if there are two ways to implement it).

Or if he don't know about the time penalty for a cache miss and
have to process a large two dimensional array, how should he then
even think about to do it in the right order (row <-> column)?

Or an other example I was concerned myself: a small DOS com
program was executed faster on a 450 MHz PII than on a 3.2 GHz P4.
The problem was the trace cache of the processor which is cleared
when a byte in the same 1k address range is modified. The solution
was simple: insert a gap of 1 kbyte between code and data and the
speed increased by a factor of 10. Ok, you can argue, that in a HLL
the code pages are read only, so writeable data can't be within the
same 1 K range as the executed code, but it is just an example
that problems can arise if you don't understand the low level side.

Yes this is all true, I have done a lot of programming of micros in asm
with the manual and looking at the clocks needed for each instructions.
Especially in the long ago past when you did RS232 in 100% software,
even did a floppy disk MFM driver with nops added to get the timing right.

When doing embedded (PIC) I may still do this.
It would be nice if the students could program at least some PICS,
let them make a RS232 in a PIC that has no hardware serial port :-)
Or baudrate counters..

But as soon as I write for the PC, I use libraries.
libmpeg3 for example, no time to figure out how that works in detail,
a new standard appears every day it seems.
I have a little digital mpeg4 video camera that makes .ASF files.
I looked up ASF spec on the Microsoft site, but hey, mplayer demuxes it
into mp4 DivX... sound too... So good enough for me, made some scripts,
now I can burn DVDs from it automatically.

No problem here with using stuff others wrote.