One thing has struck me : how much does one of these fuel-cell powered cars weigh? If it's less than or equal to that of a conventional car, could we not do away with the wheels altogether and have the flying car we've all been waiting for for the last 50 years?
You're right, there's nothing "obscure" about having to type in commands, however this prejudice against UNIX and it's clones is deeply ingrained in the mainstream IT community and one of the reasons for the prevalence of Windows. There are two ways in which this biggotry will be overcome. Firstly, "friendly" graphical tools have been developed to hide this apparent complexity and provide a familiar interface to the majority. As more of these people adopt such systems because of these friendly front-ends, some will dip under the hood and try some command line work and find out that it's not that bad after all. So the second and most important thing, education through word of mouth amongst former anti-UNIX people will help to convert the majority of those remaining. There will only be a few hard-core UNIX-haters left in years to come.
Interesting. If I am not mistaken, the ZX81 and Spectrum both did it in software, simply by toggling a bit in an output port (in the way that the spectrum BEEP worked). I suppose you could sample the port, say at 10kHz and count the number of 1's and 0's to detect high and low notes, and that way there'd be a bit of a margin for error. I bet some people lost a lot of hair developing that code.:-)
It's often intrigued me how you would write some code to read back the signal off of the tape. What sort of algorithn would you use? What about the maths involved? I've never really been into electronics myself, but, yes, that relay sounds cool.
Now that's interesting. I remember that the original IBM PC had a tape interface, but I never saw one use it either. Remember that if you didn't have DOS on disk it would boot into ROM BASIC? That was still there on the PS/2 machines back in '87 right through until some of the 486-based ones IIRC. It had the commands MOTOR ON and MOTOR OFF for controlling the tape player, but I think it gave you some sort of error saying it was no longer supported:-)
Ah yes, the joys of the ZX81 tap interface. There was no way to verify what you'd saved, so you had to save it two or three times. It was awful. However, they improved the tape I/O significantly for the Spectrum and it was about as good as you could get on a domestic tape recorder. Do you remember those "turboload" games? How did they work? Did they use more than two tones for the data or what? I remember Tomahawk (Apache simulator by Digital Integration) used to load really fast but sounded really odd.
Using an assembler on the '81 was nigh on impossible, since it would take 10 mins to load, 1 min to put your code in and *crash*. Rinse and repeat. The humble hex loader was the way to go...Then when I grew up I ended up having to regularly speak to a Honeywell 316 in a similar fashion, only it was octal, not hex:-)
No, Altair was before my time. I was born in '74.
I had an interface one and microdrive for the Spectrum. I had the HiSoft integer K&R C compiler for it:-)
The ZX81 had a replacement ROM in it that ran multitasking (!) FORTH - in only 8K or ROM and 16k of RAM.
Dude, I've used CP/M, MSX, ZX81, Spectrum, BBC Micro, Acorn Archimeded, 6502 Single Board Computers, you name it.
I had a ZX81 and then a Spectrum 128. My friend had a couple of MSX machines. We coded basic on the MSX. I coded BASIC, C, FORTH and assembler on the Spectrum and ZX81, then went on to a 286 running DOS 3.31.
I just reckon that your idea would have been better if you'd spec'd an ARM or MIPS processor and a low-end commodity graphics board and sound board. Because of economies of scale, they'd be cheaper and more powerful, and easier to code for with many compilers and libraries already available.
Better idea: use 8 Z-80's in parallel to make a 64/128-bit processor and then another 8 for the graphics hardware. We'll have an AY-3-8192 for 3 channel sound + white noise. We can code the ROM in FORTH and when it boots it'll go into a BASIC interpreter (written in FORTH). It will have line numbers from 1-9999 (who could ever need more than 10000 lines in a program?) and FOR, NEXT, GOTO and GOSUB for looping and subroutines. There should also be a 1500 baud cassette tape interface. If we're cunning we could make it capable of, say, 64 colours, but only 2 per group of 8 pixels (1 byte) i.e. 0=background, 1=foreground. Then, there's all that CP/M, Spectrum, Amstrad and MSX software we could run on it!
Whatever you do, don't buy the Black Album (aka The Emperor's New Clothes) as we don't want Messrs. Hetfield and Ulrich to benefit from this new technology:-)
I think the pre-Middle English explanation is more likely. From my humble knowlege of language, e.g. German has the verb ficken == to fuck and English and German have a lot in common if you go back a long time.
Being brought up the world of DOS, email is only half of the story. Viruses would hook into DOS interrups and look for.EXE and.COM files to infect, i.e. they would patch the binary with their own code. When that file is run, the virus copies itself into RAM and TSR's and the cylce repeats.
This is possible since there is no concept of unprivileged users and memory protection in DOS. Obviously, Windows systems supporting the DOS legacy are vulnerable by design.
Next, they became "stealthy" by patching DOS itself so that when you went to examine the infected file on an infected system, it would show you the unmodified file.
Next came tunneling (can't remember how this worked) and then mutation.
One of the first mutation engines was the Dark Avenger Mutation Engine which would rearrange the virus binary so there were never more that 3 instructions in a row the same. This made simple pattern-matching virus scanners useless.
Of course, when NT came along, you'd have thought they'd have fixed all that, but no, with judicious use of a C compiler and the Windows header files it is/was possible to circumvent protection and effectively have "root" privilege.
The rest, as they say, is history.
Wing in Ground-effect trains may be possible and much cheaper to build than maglev ones. You build a smoothe concrete track with walls and the train flies along inside that a few feet off the deck, held up purely by the aerodynamic ground effect. So the theory goes. Now, if you built one that went from, say, London to Paris, you could call it the Syrup of Figs in honour of all thoes cheeky chirpy cockney geezers.
So, is the data stored in blocks of 25 rows of 80 columns? This will be handy for FORTH systems without file systems, and FORTRAN IV,66 and 77 programmers.
Of course it was! Thanks for reminding us! I have one sitting in a box somewhere at home. O'll have to dig it out and have a go on it some day:-) The K5 was AMD's own design, and they had a design for the K6, but bought NexGen instead and used theirs, which was better. How times have changed. In those days it was Cyrix who posed the main threat to intel. Then they lost the plot when the Pentium II came out (intel's first superscalar RISC x86 implementation)
AMD has effectively done that, if you've read any of the technical documents to see what they've done.
The 64-bit mode has twice as many registers that are completely general-purpose (as opposed to the old CISC design of intel where one was a loop counter etc.)
They've only implemented the simpler intructions in 64-bit effectively making it a 64-bit RISC.
Since the K6, AMD processors have been superscalar RISC internally with a translation layer which breaks down complex x86 instructions into simpler RISC ones. It's still there for running legacy code, and completely transparent, i.e. it operates concurrently and with no performance penalty with the 64-bit instructions.
The x86-32 registers are effectively just the top-right quarter of the x86-64 registers.
Go and read AMD's docs. It's all there (and has been for the last 2 years).
I expect so. Give them until next summer (2003) and there will probably be a Pentium V which will be x86-64, run at 1.5 times the clock frequency of the AMD one and be almost as fast.
Then expect Dell to start making "low-end" servers out of it.
A year later, itanic will be all but dead and buried.
Ah, you do not understand the concept of Very Long Instruction Word. Internally the chip's ALU's may be 32- or 64-bit, but with VLIW several instructions (whose results do not depend on each other) go in and are executed in parallel. That's a simplistic explanation.
Here is stuff about the Transmeta chips and many other innovative and non-conventional designs. Look at IA-64 and Sun MAJC on the same page.
Slashdot Mirror
Don't worry, Roy and Elvis are working on a new one, even as we speak.
One thing has struck me : how much does one of these fuel-cell powered cars weigh? If it's less than or equal to that of a conventional car, could we not do away with the wheels altogether and have the flying car we've all been waiting for for the last 50 years?
Lead trousers? Don't you realise what the bremmstrahlung can do to the gonads? :-)
...and I've got some ununpentium on order for my area51 ufo, and I'm not talking about the guidance computer, either.
You're right, there's nothing "obscure" about having to type in commands, however this prejudice against UNIX and it's clones is deeply ingrained in the mainstream IT community and one of the reasons for the prevalence of Windows. There are two ways in which this biggotry will be overcome. Firstly, "friendly" graphical tools have been developed to hide this apparent complexity and provide a familiar interface to the majority. As more of these people adopt such systems because of these friendly front-ends, some will dip under the hood and try some command line work and find out that it's not that bad after all. So the second and most important thing, education through word of mouth amongst former anti-UNIX people will help to convert the majority of those remaining. There will only be a few hard-core UNIX-haters left in years to come.
Interesting. If I am not mistaken, the ZX81 and Spectrum both did it in software, simply by toggling a bit in an output port (in the way that the spectrum BEEP worked). I suppose you could sample the port, say at 10kHz and count the number of 1's and 0's to detect high and low notes, and that way there'd be a bit of a margin for error. I bet some people lost a lot of hair developing that code. :-)
It's often intrigued me how you would write some code to read back the signal off of the tape. What sort of algorithn would you use? What about the maths involved? I've never really been into electronics myself, but, yes, that relay sounds cool.
Now that's interesting. I remember that the original IBM PC had a tape interface, but I never saw one use it either. Remember that if you didn't have DOS on disk it would boot into ROM BASIC? That was still there on the PS/2 machines back in '87 right through until some of the 486-based ones IIRC. It had the commands MOTOR ON and MOTOR OFF for controlling the tape player, but I think it gave you some sort of error saying it was no longer supported :-)
Ah yes, the joys of the ZX81 tap interface. There was no way to verify what you'd saved, so you had to save it two or three times. It was awful. However, they improved the tape I/O significantly for the Spectrum and it was about as good as you could get on a domestic tape recorder. Do you remember those "turboload" games? How did they work? Did they use more than two tones for the data or what? I remember Tomahawk (Apache simulator by Digital Integration) used to load really fast but sounded really odd. Using an assembler on the '81 was nigh on impossible, since it would take 10 mins to load, 1 min to put your code in and *crash*. Rinse and repeat. The humble hex loader was the way to go...Then when I grew up I ended up having to regularly speak to a Honeywell 316 in a similar fashion, only it was octal, not hex :-)
No, Altair was before my time. I was born in '74. I had an interface one and microdrive for the Spectrum. I had the HiSoft integer K&R C compiler for it :-)
The ZX81 had a replacement ROM in it that ran multitasking (!) FORTH - in only 8K or ROM and 16k of RAM.
Dude, I've used CP/M, MSX, ZX81, Spectrum, BBC Micro, Acorn Archimeded, 6502 Single Board Computers, you name it. I had a ZX81 and then a Spectrum 128. My friend had a couple of MSX machines. We coded basic on the MSX. I coded BASIC, C, FORTH and assembler on the Spectrum and ZX81, then went on to a 286 running DOS 3.31. I just reckon that your idea would have been better if you'd spec'd an ARM or MIPS processor and a low-end commodity graphics board and sound board. Because of economies of scale, they'd be cheaper and more powerful, and easier to code for with many compilers and libraries already available.
Many languages have compilers which target, or interpreters which run on, the JVM. Google is your friend.
Better idea: use 8 Z-80's in parallel to make a 64/128-bit processor and then another 8 for the graphics hardware. We'll have an AY-3-8192 for 3 channel sound + white noise. We can code the ROM in FORTH and when it boots it'll go into a BASIC interpreter (written in FORTH). It will have line numbers from 1-9999 (who could ever need more than 10000 lines in a program?) and FOR, NEXT, GOTO and GOSUB for looping and subroutines. There should also be a 1500 baud cassette tape interface. If we're cunning we could make it capable of, say, 64 colours, but only 2 per group of 8 pixels (1 byte) i.e. 0=background, 1=foreground. Then, there's all that CP/M, Spectrum, Amstrad and MSX software we could run on it!
Whatever you do, don't buy the Black Album (aka The Emperor's New Clothes) as we don't want Messrs. Hetfield and Ulrich to benefit from this new technology :-)
I think the pre-Middle English explanation is more likely. From my humble knowlege of language, e.g. German has the verb ficken == to fuck and English and German have a lot in common if you go back a long time.
Being brought up the world of DOS, email is only half of the story. Viruses would hook into DOS interrups and look for .EXE and .COM files to infect, i.e. they would patch the binary with their own code. When that file is run, the virus copies itself into RAM and TSR's and the cylce repeats.
This is possible since there is no concept of unprivileged users and memory protection in DOS. Obviously, Windows systems supporting the DOS legacy are vulnerable by design.
Next, they became "stealthy" by patching DOS itself so that when you went to examine the infected file on an infected system, it would show you the unmodified file.
Next came tunneling (can't remember how this worked) and then mutation.
One of the first mutation engines was the Dark Avenger Mutation Engine which would rearrange the virus binary so there were never more that 3 instructions in a row the same. This made simple pattern-matching virus scanners useless.
Of course, when NT came along, you'd have thought they'd have fixed all that, but no, with judicious use of a C compiler and the Windows header files it is/was possible to circumvent protection and effectively have "root" privilege.
The rest, as they say, is history.
Wing in Ground-effect trains may be possible and much cheaper to build than maglev ones. You build a smoothe concrete track with walls and the train flies along inside that a few feet off the deck, held up purely by the aerodynamic ground effect. So the theory goes. Now, if you built one that went from, say, London to Paris, you could call it the Syrup of Figs in honour of all thoes cheeky chirpy cockney geezers.
So, is the data stored in blocks of 25 rows of 80 columns? This will be handy for FORTH systems without file systems, and FORTRAN IV,66 and 77 programmers.
Of course it was! Thanks for reminding us! I have one sitting in a box somewhere at home. O'll have to dig it out and have a go on it some day :-) The K5 was AMD's own design, and they had a design for the K6, but bought NexGen instead and used theirs, which was better. How times have changed. In those days it was Cyrix who posed the main threat to intel. Then they lost the plot when the Pentium II came out (intel's first superscalar RISC x86 implementation)
Thank you very much. As you have sussed out, I am just getting to grips with sed :-)
AMD has effectively done that, if you've read any of the technical documents to see what they've done. The 64-bit mode has twice as many registers that are completely general-purpose (as opposed to the old CISC design of intel where one was a loop counter etc.) They've only implemented the simpler intructions in 64-bit effectively making it a 64-bit RISC. Since the K6, AMD processors have been superscalar RISC internally with a translation layer which breaks down complex x86 instructions into simpler RISC ones. It's still there for running legacy code, and completely transparent, i.e. it operates concurrently and with no performance penalty with the 64-bit instructions. The x86-32 registers are effectively just the top-right quarter of the x86-64 registers. Go and read AMD's docs. It's all there (and has been for the last 2 years).
There are twice as many registers and they are twice as wide (obviously -:) comapred to IA-32 www.x86-64.org
I expect so. Give them until next summer (2003) and there will probably be a Pentium V which will be x86-64, run at 1.5 times the clock frequency of the AMD one and be almost as fast. Then expect Dell to start making "low-end" servers out of it. A year later, itanic will be all but dead and buried.
Ah, you do not understand the concept of Very Long Instruction Word. Internally the chip's ALU's may be 32- or 64-bit, but with VLIW several instructions (whose results do not depend on each other) go in and are executed in parallel. That's a simplistic explanation. Here is stuff about the Transmeta chips and many other innovative and non-conventional designs. Look at IA-64 and Sun MAJC on the same page.