Re:NetBSD runs on nearly every Mac
on
X On OSX Now Free
·
· Score: 1
Actually, all of the AV PowerMacs were Nubus 601 machines, weren't they? NetBSD currently doesn't run on any Nubus PowerMac. The reason doesn't have anything to do with the AV stuff--I think it's the lack of OpenFirmware that's the problem.
Re:NetBSD runs on nearly every Mac
on
X On OSX Now Free
·
· Score: 1
Most of the custom ASICs on early Macs have been reverse-engineered and ports of NetBSD exist for nearly every Mac (with a few exceptions; AV Macs especially).
Eh? I don't know about the AV PowerMacs (haven't gotten around to buying a PowerMac yet, but those dual G4s are tempting:), but NetBSD works just fine on the 68K AV Macs (660av and 840av); I even wrote a driver for the onboard ethernet chip and its funky DMA controller
Copyright (c) 1996, 1997, 1998, 1999, 2000
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.All rights reserved.
NetBSD 1.5_BETA (GEDD) #602: Sun Oct 22 01:41:46 CDT 2000
khym@dahan.metonymy.com:/usr/src.local/sys/arch/ma c68k/compile/GED D
Apple Macintosh Centris 660AV(68040)
cpu: delay factor 800
total memory = 36864 KB
avail memory = 31040 KB
Authoritative answers can be found from:
kam.com nameserver = NS0-K.DNS.PIPEX.NET
kam.com nameserver = NS1-K.DNS.PIPEX.NET
NS0-K.DNS.PIPEX.NET internet address = 158.43.129.75
NS1-K.DNS.PIPEX.NET internet address = 158.43.193.75
Well, Nyquist's theorem isn't an article of faith if you've seen it and the proof:) While math does have a few axioms that you do have to take on faith, everything else has a proof... no further faith needed:) And only conditions are for the input signal to be bandlimited and the reconstruction filter to be ideal... ignoring phase and time is not part of the requirements. In the theoretical world of math, you can make a filter that has zero phase distortion... only problem is you need to know the signal from -infinity to +infinity, i.e., before the beginning of time to after the universe ends:) All real world filters do introduce some phase shift, which I acknowledged in my post. However, it's possible to design filters that have a pretty much constant group delay--ones that just end up delaying all frequencies of the signal by the same amount.
Signal processing engineers know the importance of phase shifts, know what filters do to the phase, and know how to compensate... I think modems are a pretty good demonstration of that--even old 2400bps modems use something known as Quadrature Amplitude Modulation to encode 4 bits of data in a single "symbol". Both the phase of the signal wrt. the carrier, and its amplitude determine the bits that are being sent across the line. Faster modems do something similar, with fancier signal processing to squeeze more bits in; accurately preserving/determining the phase shift becomes even more important.
CDs definitely aren't perfect reproducers of sound, but what is? Not SACD, not LPs, not DVD-A, not 8 tracks; I wouldn't apply "perfect" to any real world method of sound reproduction... But I'm just trying to combat the misconception that some folks have (including you, I believe:) that the whole theory behind CDs and digital sampling is flawed and introduces serious defects in the sound right off the bat.
Anyways, to get this back on topic, the bottom line for me personally is that CDs are good enough, and I'm not gonna pay a premium for better sound reproduction for frequencies at the edge of my hearing. I can see why Sony wanted this though, and I do think that folks who record/mix/etc... music could use better than CD quality (but don't y'all have that already? I got the impression from other articles here that converting to 16 bit/44.1k for CD was typically the last step in the process, and that intermediate steps were done with more bits and samples).
And just to show you that it even works with a 918Hz sine wave, I've made another picture. Reconstructing the samples gives you a stepped sine wave... yes, it has harmonics in it, but none of them are under 22050Hz. Filtering 'em out once again gives you a nice clean sine wave.
As I said, due to the way Goldwave (and all other sampled sound processing programs) works, I repeated each sample 16 times. 14700/16 = 918.75, and 22050/16 = 1378.125 (I used the wrong cutoff frequency originally, but I fixed it). If it makes you feel better, think of pictures 2 through 4 as 14700Hz waveforms viewed on a digital sampling scope with a sampling frequency of 705600Hz. If I didn't repeat the samples, I obviously wouldn't be getting any harmonics over 22050Hz to filter out.
And yes, the 14700 does have the second harmonic (and all higher ones) obliterated by the 22.05K lowpass. That's why it works. That's exactly my point... really, we're talking about some of the foundations of signal processing here. This has been studied in depth by many people; if it were wrong, I think someone would've noticed by now.
Real world filters do cause phase changes (note that the bottom picture is offset from the original), but my demonstration was to show that even though the sampled waveform looks all funky, when you filter it, you're left with a pure sine wave--the same as what you started with. You said "Or that a 1/3 width pulse wave at 14.7K with a 22K filter is EXACTLY a sine wave? I would suggest that it is not...", but my pictures show that yes, it in fact is exactly a sine wave.
As I mentioned in one of my other posts, in the real world, things don't come out perfectly. I do think that a higher sampling rate can have some benefit (though to tell the truth, it's not a benefit that I'd be willing to spend any extra money on). My dispute is with those who are saying that even in a completely theoretical world, Nyquist's theorem is incorrect.
Can't you _see_ this?? Doesn't your math acknowledge this? These are not only measurable distortions but the problem is still
present even _completely_ in the theoretical realm.
Sure, I can see it... my math acknowledges it, takes it into account, and works perfectly. Sometimes math isn't intuitively obvious, even though it all works out in the end.
Here, look at some pictures I made... they're kinda quick and dirty, but they should get the point across:
For the 14700Hz picture, I plotted a 14700Hz sine wave, then marked the sample points in red. Then, in the next picture down, I plot the square wave signal made by the samples. As you say, it's not symmetrical, even though the original sine wave was. Now, I write the samples out to a file, and load it into Goldwave, a sound editing tool (I picked Goldwave because I'm vaguely familiar with it, and know that it does filtering). The third picture is how the sample looks in Goldwave.
For visual purposes, and because Goldwave only works on digitally sampled files, the file loaded into Goldwave actually has each sample repeated 16 times, so it'd actually be a 918.75Hz tone if played back at a 44100Hz sampling rate. This doesn't invalidate my point though; remember that in the real world, pictures 2, 3, and 4 are analog signals, without any sampling rate. Now, I tell Goldwave to do a low pass filter, with a cutoff frequency of 919Hz. Voilà, I get a nice symmetrical sine wave back.
The 14600Hz picture is the same, and yes, the square wave does look like it's been modulated. But do a lowpass filter on it, and it's all fixed
You're totally wrong hear. In testing, it has been proven that CD audio sounds distinguisably better than an mp3 of the same track.
That's nice, I can tell the difference betweena CD and 128kbit mp3 too, but that's not what the discussion is about. Nobody mentioned anything about mp3.
A 22kHz square wave has many (well, an infinite) number of harmonics above 22kHz. Nyquist's theorem applies to a bandlimited signal. Sure, higher sampling rates are important if you really want to capture a 22kHz square wave (take a look at the sampling rate that digital sampling oscilloscopes use... they're in the gigasample/second range; Tektronix has one that goes up to 20GS/s). Higher sampling rates aren't particularly important for audio signals intended for humans to listen to though.
Nyquist's theorem does not imply, however, that the representation of the maximum [or near maximum] frequencies will be highly accurate as far as the shape of the wave form is concerned. At and around 1/2 sampling freqency, the wave forms become basically nothing but square waves [alternating between a single high, and a single low point].
Umm, ever hear of low pass filtering? Say you sample a 22kHz pure sine wave at 44ksamples/second and end up with alternating max/min sample, i.e., a 22kHz square wave. You're not supposed to just use that as-is; you have to put it through a low pass filter, with a 22kHz cutoff frequency, which will get you your 22kHz pure sine wave back again.
The Nyquist theorem does in fact imply that you can reconstruct your original signal perfectly... of course, Nyquist theorem is just math... in the real world, you can't make an ideal lowpass filter with an immediate rolloff, but that's not Nyquist's problem:)
I've never seen an AMD web server able to sustain a ping under 100ms.
yerfable ~> ping -c5 dahan
PING dahan.metonymy.com (10.1.1.66): 48 data bytes
64 bytes from 10.1.1.66: icmp_seq=0 ttl=255 time=0.007 ms
64 bytes from 10.1.1.66: icmp_seq=1 ttl=255 time=0.008 ms
64 bytes from 10.1.1.66: icmp_seq=2 ttl=255 time=0.008 ms
64 bytes from 10.1.1.66: icmp_seq=3 ttl=255 time=0.008 ms
64 bytes from 10.1.1.66: icmp_seq=4 ttl=255 time=0.008 ms
----dahan.metonymy.com PING Statistics----
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.007/0.008/0.008/0.000 ms
*ahem*...I suppose the reason that this is only for x86 is because it is a X86-64 emulator. It emulates a 64-bit platform on x86 machines. Therefore, solaris, PPC, et. al., can reasonably be left out on this round.
No, it doesn't emulate a 64-bit platform on x86 machines. It emulates an X86-64, a 64-bit x86 platform. There's no reason it couldn't run on some other machine. Nintendo/SNES/Gameboy emulators work just fine on x86 PCs, despite the lack of 6502/65816/Z80s in 'em.
And FYI, here is an public domain IA64 simulator, which you could compile on a SPARC, Alpha, PPC, whatever... it only simulates the CPU though, not a full machine.
Welcome to Linux 2.2.17.
Cherokee login: root
Password:
WHAT "cancel" at the login prompt?
Seeing that the original poster said, "That's all well and good, but what about those of us that don't use Linux? For me, switching to Linux entirely is not an option," I think someone needs to take your crackpipe away.
/me takes your crackpipe away
And your irc client too.
Re:Typos not a minor point
on
Think Unix
·
· Score: 1
There's an errata for the book. It is, as far as I'm aware, entirely complete and up-to-date. It's over here (the address is listed in the book, yes). You can determine how many of these have any impact whatsoever on the content.
How about some errata for the errata?:)
p.31 - I assume that should be "Socrates", not "Soctrates"
p.46 - "user", not "uger"
p.123 - "last", not "lasgt"
p.128 - "digits", not "difits"
uh, why not go to the extra 10 seconds of effort to see if babelfish translates from japanese (they don't) before posting? oh. hard to be a karma whore when you post late. my bad.
uh, who said anything about babelfish? Try Gist-In-Time
It's not too difficult if you have the right (i.e. expensive:) tools... I took a class on surface mount soldering at the local community college (for no particular reason), and to remove surface mount chips, we used a large rectangular iron tip that would heat all the pins at once. Let it heat for a while so all the solder melts, and give it a little twist, and it comes right off.
For those of us with lesser means, if you don't care about saving the original chip, you could probably use some small diagonal cutters to clip all the pins, then desolder the pins individually. If you do want to try to keep the original chip, use desoldering wick on the pins and gently lift them up. (Then you'll have to try to bend 'em all back in line if you want to use the chip elsewhere... if I were doing this, I wouldn't worry about keeping the old chip... that's way too much work:)
As for the resoldering part, that's actually not that hard... take a surface mount soldering class to find out how it's done;)
everyone speaks english?? have u ever been outside of the UK or US?!
I have, actually... been to Canada, and they speak English there too!!
Seriously, I've also been to Thailand and Taiwan, and it wasn't terribly hard to find English speakers there; even the lady at the roadside fried banana stand in Bangkok could tell me how much a sack of bananas cost.
Really, "everyone" does speak English... as in you generally don't have to look too hard to find an English speaker, no matter where you are. Try going to a supermarket in some large US city and asking a cashier "yi1 bang4 fan1 qie2 duo1 shao3 qian2?" and see how far you get:)
Well, I had a friend who actually WANTED to register a.us domain, but they wouldn't let him.. I can't remember the reason they gave. I think you _HAD_ to be a business of some sort or an oraganization...
His proposed domain: www.ph34r.us.
Perhaps he should've read the US domain overview or very first bullet of the registration instructions then.
You certainly don't have to be a business, or any sort of organization... I've got a domain under austin.tx.us, and I'm just some guy with a few computers.
For example most SCSI hard drives support the following features:
Command Queuing and reordering, support restricted and unrestricted reordering
Now I love SCSI drives, and they're noticeably faster than IDE drives for some of the stuff I do, probably due to queuing and reordering. However, I've heard some people say that the OS can do a reasonable job of ordering transactions itself; sure, it doesn't know exactly how a LBA maps to a C/H/S, but in general, sorting by LBA should be pretty close, no? I know BSD has disksort, which attempts to do this... any thoughts as to whether a drive can do a significantly better job of reordering than the OS?
(And tangentially, I think an OS can do a much better job of caching than a drive... I feel that having a track's worth of cache in the drive is good enough. The OS should know what data is worth keeping and what can be thrown away, and if it's worth keeping, getting it across the memory bus is gonna be a lot faster than fetching it across the SCSI or IDE bus:)
Slashdot Mirror
Actually, all of the AV PowerMacs were Nubus 601 machines, weren't they? NetBSD currently doesn't run on any Nubus PowerMac. The reason doesn't have anything to do with the AV stuff--I think it's the lack of OpenFirmware that's the problem.
Eh? I don't know about the AV PowerMacs (haven't gotten around to buying a PowerMac yet, but those dual G4s are tempting :), but NetBSD works just fine on the 68K AV Macs (660av and 840av); I even wrote a driver for the onboard ethernet chip and its funky DMA controller
Copyright (c) 1996, 1997, 1998, 1999, 2000
a c68k/compile/GED D
The NetBSD Foundation, Inc. All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.All rights reserved.
NetBSD 1.5_BETA (GEDD) #602: Sun Oct 22 01:41:46 CDT 2000
khym@dahan.metonymy.com:/usr/src.local/sys/arch/m
Apple Macintosh Centris 660AV(68040)
cpu: delay factor 800
total memory = 36864 KB
avail memory = 31040 KB
Actually, I'm pretty sure he meant like q.com
Well that someone would be Network Solutions, Inc., and bad DNS information is out there because NSI has kept the record in the root servers:
yerfable ~> nslookup
Default Server: sloth.metonymy.com
Address: 10.1.1.67
> server a.root-servers.net
Default Server: a.root-servers.net
Address: 198.41.0.4
> set qtype=any
> kam.com.
Server: a.root-servers.net
Address: 198.41.0.4
Non-authoritative answer:
kam.com nameserver = NS0-K.DNS.PIPEX.NET
kam.com nameserver = NS1-K.DNS.PIPEX.NET
Authoritative answers can be found from:
kam.com nameserver = NS0-K.DNS.PIPEX.NET
kam.com nameserver = NS1-K.DNS.PIPEX.NET
NS0-K.DNS.PIPEX.NET internet address = 158.43.129.75
NS1-K.DNS.PIPEX.NET internet address = 158.43.193.75
I doubt that they just forgot to clear it out...
Signal processing engineers know the importance of phase shifts, know what filters do to the phase, and know how to compensate... I think modems are a pretty good demonstration of that--even old 2400bps modems use something known as Quadrature Amplitude Modulation to encode 4 bits of data in a single "symbol". Both the phase of the signal wrt. the carrier, and its amplitude determine the bits that are being sent across the line. Faster modems do something similar, with fancier signal processing to squeeze more bits in; accurately preserving/determining the phase shift becomes even more important.
CDs definitely aren't perfect reproducers of sound, but what is? Not SACD, not LPs, not DVD-A, not 8 tracks; I wouldn't apply "perfect" to any real world method of sound reproduction... But I'm just trying to combat the misconception that some folks have (including you, I believe :) that the whole theory behind CDs and digital sampling is flawed and introduces serious defects in the sound right off the bat.
Anyways, to get this back on topic, the bottom line for me personally is that CDs are good enough, and I'm not gonna pay a premium for better sound reproduction for frequencies at the edge of my hearing. I can see why Sony wanted this though, and I do think that folks who record/mix/etc... music could use better than CD quality (but don't y'all have that already? I got the impression from other articles here that converting to 16 bit/44.1k for CD was typically the last step in the process, and that intermediate steps were done with more bits and samples).
And just to show you that it even works with a 918Hz sine wave, I've made another picture. Reconstructing the samples gives you a stepped sine wave... yes, it has harmonics in it, but none of them are under 22050Hz. Filtering 'em out once again gives you a nice clean sine wave.
And yes, the 14700 does have the second harmonic (and all higher ones) obliterated by the 22.05K lowpass. That's why it works. That's exactly my point... really, we're talking about some of the foundations of signal processing here. This has been studied in depth by many people; if it were wrong, I think someone would've noticed by now.
Real world filters do cause phase changes (note that the bottom picture is offset from the original), but my demonstration was to show that even though the sampled waveform looks all funky, when you filter it, you're left with a pure sine wave--the same as what you started with. You said "Or that a 1/3 width pulse wave at 14.7K with a 22K filter is EXACTLY a sine wave? I would suggest that it is not...", but my pictures show that yes, it in fact is exactly a sine wave.
As I mentioned in one of my other posts, in the real world, things don't come out perfectly. I do think that a higher sampling rate can have some benefit (though to tell the truth, it's not a benefit that I'd be willing to spend any extra money on). My dispute is with those who are saying that even in a completely theoretical world, Nyquist's theorem is incorrect.
Whoops, I guess I should've done a filter with a cutoff frequency of 1378Hz (22050/16)... no matter, it still works great :) I'll fix my pictures...
Sure, I can see it... my math acknowledges it, takes it into account, and works perfectly. Sometimes math isn't intuitively obvious, even though it all works out in the end.
Here, look at some pictures I made... they're kinda quick and dirty, but they should get the point across:
- 14700Hz
- 14600Hz
For the 14700Hz picture, I plotted a 14700Hz sine wave, then marked the sample points in red. Then, in the next picture down, I plot the square wave signal made by the samples. As you say, it's not symmetrical, even though the original sine wave was. Now, I write the samples out to a file, and load it into Goldwave, a sound editing tool (I picked Goldwave because I'm vaguely familiar with it, and know that it does filtering). The third picture is how the sample looks in Goldwave. For visual purposes, and because Goldwave only works on digitally sampled files, the file loaded into Goldwave actually has each sample repeated 16 times, so it'd actually be a 918.75Hz tone if played back at a 44100Hz sampling rate. This doesn't invalidate my point though; remember that in the real world, pictures 2, 3, and 4 are analog signals, without any sampling rate. Now, I tell Goldwave to do a low pass filter, with a cutoff frequency of 919Hz. Voilà, I get a nice symmetrical sine wave back.The 14600Hz picture is the same, and yes, the square wave does look like it's been modulated. But do a lowpass filter on it, and it's all fixed
Ain't math grand? :)
That's nice, I can tell the difference betweena CD and 128kbit mp3 too, but that's not what the discussion is about. Nobody mentioned anything about mp3.
A 22kHz square wave has many (well, an infinite) number of harmonics above 22kHz. Nyquist's theorem applies to a bandlimited signal. Sure, higher sampling rates are important if you really want to capture a 22kHz square wave (take a look at the sampling rate that digital sampling oscilloscopes use... they're in the gigasample/second range; Tektronix has one that goes up to 20GS/s). Higher sampling rates aren't particularly important for audio signals intended for humans to listen to though.
While I hadn't heard of 1-bit amplifiers, the Sony Discman I bought in 1993 uses 1-bit delta sigma DACs...
Umm, ever hear of low pass filtering? Say you sample a 22kHz pure sine wave at 44ksamples/second and end up with alternating max/min sample, i.e., a 22kHz square wave. You're not supposed to just use that as-is; you have to put it through a low pass filter, with a 22kHz cutoff frequency, which will get you your 22kHz pure sine wave back again.
The Nyquist theorem does in fact imply that you can reconstruct your original signal perfectly... of course, Nyquist theorem is just math... in the real world, you can't make an ideal lowpass filter with an immediate rolloff, but that's not Nyquist's problem :)
I guess you mean no "mainstream" OS, but Unicos/mk (as in the OS for massively parallel Crays) supports that.
I've never seen an AMD web server able to sustain a ping under 100ms.
yerfable ~> ping -c5 dahan
3 86/compile/SPIFF
PING dahan.metonymy.com (10.1.1.66): 48 data bytes
64 bytes from 10.1.1.66: icmp_seq=0 ttl=255 time=0.007 ms
64 bytes from 10.1.1.66: icmp_seq=1 ttl=255 time=0.008 ms
64 bytes from 10.1.1.66: icmp_seq=2 ttl=255 time=0.008 ms
64 bytes from 10.1.1.66: icmp_seq=3 ttl=255 time=0.008 ms
64 bytes from 10.1.1.66: icmp_seq=4 ttl=255 time=0.008 ms
----dahan.metonymy.com PING Statistics----
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.007/0.008/0.008/0.000 ms
dahan ~> dmesg | head -4
NetBSD 1.5_ALPHA2 (SPIFF) #340: Tue Sep 26 19:33:23 CDT 2000
khym@dahan.metonymy.com:/usr/src.local/sys/arch/i
cpu0: AMD K6-2 (586-class)
There ya go, 0.008 milliseconds, i.e., 8 microseconds. Way under 100ms.
No, it doesn't emulate a 64-bit platform on x86 machines. It emulates an X86-64, a 64-bit x86 platform. There's no reason it couldn't run on some other machine. Nintendo/SNES/Gameboy emulators work just fine on x86 PCs, despite the lack of 6502/65816/Z80s in 'em.
And FYI, here is an public domain IA64 simulator, which you could compile on a SPARC, Alpha, PPC, whatever... it only simulates the CPU though, not a full machine.
- There's an errata for the book. It is, as far as I'm aware, entirely complete and up-to-date. It's over here (the address is listed in the book, yes). You can determine how many of these have any impact whatsoever on the content.
How about some errata for the errata?p.31 - I assume that should be "Socrates", not "Soctrates"
p.46 - "user", not "uger"
p.123 - "last", not "lasgt"
p.128 - "digits", not "difits"
BTW, p.154 - æ is æ :)
uh, who said anything about babelfish? Try Gist-In-Time
For those of us with lesser means, if you don't care about saving the original chip, you could probably use some small diagonal cutters to clip all the pins, then desolder the pins individually. If you do want to try to keep the original chip, use desoldering wick on the pins and gently lift them up. (Then you'll have to try to bend 'em all back in line if you want to use the chip elsewhere... if I were doing this, I wouldn't worry about keeping the old chip... that's way too much work :)
As for the resoldering part, that's actually not that hard... take a surface mount soldering class to find out how it's done ;)
Actually, Chinese don't find it particularly difficult to learn: "Is Esperanto "too European"?"
I have, actually... been to Canada, and they speak English there too!!
Seriously, I've also been to Thailand and Taiwan, and it wasn't terribly hard to find English speakers there; even the lady at the roadside fried banana stand in Bangkok could tell me how much a sack of bananas cost.
Really, "everyone" does speak English... as in you generally don't have to look too hard to find an English speaker, no matter where you are. Try going to a supermarket in some large US city and asking a cashier "yi1 bang4 fan1 qie2 duo1 shao3 qian2?" and see how far you get :)
His proposed domain: www.ph34r.us.
Perhaps he should've read the US domain overview or very first bullet of the registration instructions then. You certainly don't have to be a business, or any sort of organization... I've got a domain under austin.tx.us, and I'm just some guy with a few computers.
Command Queuing and reordering, support restricted and unrestricted reordering
Now I love SCSI drives, and they're noticeably faster than IDE drives for some of the stuff I do, probably due to queuing and reordering. However, I've heard some people say that the OS can do a reasonable job of ordering transactions itself; sure, it doesn't know exactly how a LBA maps to a C/H/S, but in general, sorting by LBA should be pretty close, no? I know BSD has disksort, which attempts to do this... any thoughts as to whether a drive can do a significantly better job of reordering than the OS?
(And tangentially, I think an OS can do a much better job of caching than a drive... I feel that having a track's worth of cache in the drive is good enough. The OS should know what data is worth keeping and what can be thrown away, and if it's worth keeping, getting it across the memory bus is gonna be a lot faster than fetching it across the SCSI or IDE bus :)
Oh yeah, how could I forget x.org, makers of a popular windowing system for *nix? :)