A bug in OS 9. When the Mac first came out, there was no HD. So the Finder was programmed so that the floppy drive is above priorty than other processes.
They did what? I don't see what on earth odds it makes what medium is in use - I/O is a slow process and should never waste CPU time. And "priority"? What priority? If the drive hardware uses programmed I/O, then the CPU will have to get tied up shunting lots of data around (which will cause all the pauses experienced), but if it uses DMA, then most of the time, the OS can just leave the drive to perform the transfer and wait for an interrupt.

This is not so in Mac OS X, which better supports mulitasking and the FD is passe anyway.
Programmed I/O is still a curse to date - it slows down disc access noticeably. Goodness only knows why any hardware of the last decade actually used it. Mac OS X's pre-emptive multitasking, though, will at least stop programmed I/O from hogging up the CPU.

Other copy operations don't tie up the CPU at all, except burning a CD or DVD, which require lots of CPU power.
They do? Why? How much extra power is needed to send a bunch of data to a CD or DVD drive? There is no extra CPU overhead, but what is an issue is buffer underrun caused by the machine being too tied up to keep supplying data to the drive fast enough to keep up with the rate of burning. This affect can also be seen when trying to burn an ISO stored on a network drive onto a CD - it was a 4x burner, so the network can't be transferring stuff that fast

That's just the sluggish performance of Windows. It does that whenever you do something that requires CPU power.
Does it now? That is most definitely not true. Windows is a peculiar beast, though. I have SETI@home running at all times and, even though it uses 99% of my CPU time, there is no trace of any speed drop on my 1.4 GHz CPU. On the other hand, break some code and cause ColdFusion server to get a thread stuck in an infinite loop, and it is possible to have Explorer take something like 30 seconds just to launch the Services control panel so that I can restart the server. I've also had spates of other occurrences this week where Explorer and IE seem to lock each other up.

As for the problem of Explorer progress dialogs locking out another Explorer window or, worse, most of Explorer such that the background fails to redraw after I minimise windows (that don't appear to actually go anywhere), it seems to be either overkill race condition checks, or just exceeingly poor multi-threading, where it is just reluctant to create a new thread for anything.

I'm not sure, I've just had Explorer be a nuisance this week

Open the extension, open the icl8 resource, and open the icon that appears at start-up. Then hack it up
Sure, but what if that icon is in use for something else (didn't I explain that earlier?). I need to change the actual code that passes in the icon ID to the OS, or something. The extension is Thomas Tempelmann's Joliet one, and during OS start-up, it pops up a CD icon instead of the extension icon. But if I edit it, some of my CDs will start showing extension icons

One of the last versions of OS 9, and only then do the programmers remember to fix up minor bugs like this?
They only added the Finder's Window menu in 9.1, and left Undo until X. They're never in a hurry to fix some things. Oh, and try this: set a folder to list view, and then set it to large icons. It will never open with the top icon visible, even if all the icons fit in the window, it always scrolls down by one row. Unless that got cured in 9.0, I don't use that view any more.

I had loads of fun, thank you
And more yet...

- uilleann

quote:

---

Originally posted by SpikeSpiegel:
soo wait can i post my absolutely inane and pointless questions here too?

---

i'd love to hear them.... just keep 'em a bit on the mature side, eh?

i agree with u...
1: who gives a shit if it has a kernel or not?
2: it doens't make any difference at all whether it is floppy or not, it is the fact that it is just a slow drive, just liek a zip 100
3: if you have a shity computer, burnign a cd would take most of your processor power, but it really doesn't need all that much
4: My one disagreement: dvds can take all of your 2 gigahertz to get them ready, though you may have implied that
5: I ALLREADY SUGGESTED THE RESEDIT SOLUTION AND WE SAID IT WOULDN'T WORK!
6: i hope you are having more fun

In theory. Now, alas, I only know theory, and part of my reason for asking was probably to find out why computers have such a strange tendency to do all file I/O as programmed I/O, where the CPU actually has to transfer all the data between the I/O controller and the RAM, little piece at a time. In such cases, the CPU is in heavy use for all file I/O, and thus it can be difficult to keep up with the CD burner on older machines. Another factor on older machines might be RAM shortage and paging from a machine in use, but any other heavy hard disc access will help prevent the CD burning app getting adequate hard disc access to read in the data being burnt.

it doens't make any difference at all whether it is floppy or not, it is the fact that it is just a slow drive, just liek a zip 100
I blame programmed I/O, personally, unless anyone has a better theory. And a floppy disc transfers more slowly, so that idea has merit. I'm not sure about Zip discs, they're pretty speedy actually. Try comparing the responsiveness in Classic Mac OS with Zip transfers with IDE, SCSI and USB Zip drives. I've tried all three, I think IDE makes the Mac noticeably more responsive, I'm not sure now.

As for my Mac, my Zip drive is SCSI, and that is a different matter - it seems like the SCSI hardware is generating a very low-level interrupt/event, and then taking over the CPU to do the transfer. I say interrupt, because SCSI transfers stop my MP3 player altogether, and that runs off an event (VBL task) that pre-empts all other tasks - I even get to listen to music with a bomb dialog on the screen, let alone when an application has locked up.

dvds can take all of your 2 gigahertz to get them ready, though you may have implied that
Do you mean mastering the image before burning? That process would take CPU time, yes, but 2 GHz? I can't see it taking that much. If you're running Mac OS classic, it is very easy to come to the false assumption that an app is tying up the CPU (because nothing is responding) when it has merely made a blocking I/O call to the OS which has not itself yielded the CPU to another process while it's waiting for data to be transferred.

Mac OS X is different, and like with any other pre-emptively multitasked OS, the amount of CPU time it wants to use is completely irrelevant, because the OS will give every process a fair share of the CPU and there will only be any slowdown when a large number of tasks are all getting hungry for CPU time.

I'm not sure about Windows, though - sometimes, it just goes and locks itself out of the hard disc, or something... it's an odd OS. I mean, how can a ColdFusion server thread trapped in an infinite loop stop Explorer from accessing the hard disc. Explorer has enough CPU power (pre-emptive scheduling), so maybe the server just had disc I/O all tied up (I have no idea what Windows' hard disc scheduling is like), but why does an infinite loop need extremely heavy hard disc access?

Ah well, enough for now :)

And even though disc I/O in Mac OS is primitive, it's no better in Windows - the only difference in Windows is that the only thing that stops respoding is the Explorer window involved, because someone Microsoft are too stupid to thread Windows properly such that I/O operations don't tie up the interface. And given that IE and Explorer are the same app in the end, an Explorer window that's tied up can (and has) locked IE out on me... (or something to that effect)

- uilleann

Edit:
Oh, that reminds me - one thing I loved about Mac OS was that it cached directory entry and/or volume bit map updates during copying, and only wrote them after ever so many files, whereas DOS does it after every file, making copying of large numbers of files to a disc very slow, as there is head movement back and forth between every file. However, the slow verification on Mac OS kinda negated the effect.

With the simplified copy dialogs in 8 upwards, you can no longer see when it is writing to the different parts of the disc, and if it still verifies copies (DOS verify does it exceedingly fast).

2: it doens't make any difference at all whether it is floppy or not, it is the fact that it is just a slow drive, just liek (neat spelling dg4!-MG)a zip 100
Isn't that what I've been telling you all along

3: if you have a shity computer, burnign a cd would take most of your processor power, but it really doesn't need all that much

If you're so smart, you might know that if a computer has a DVD writer, it isn't shity unless you installed it in a P4

4: My one disagreement: dvds can take all of your 2 gigahertz to get them ready, though you may have implied that
So what? I'm using iDVD 1.0, so maybe that's why

5: I ALLREADY SUGGESTED THE RESEDIT SOLUTION AND WE SAID IT WOULDN'T WORK!
If it worked for me, it shound work for you, and if it doesn't your Mac is really screwed up

A Mac (prior to OS X) lacked a commandline interface, which meant that the parts of the kernel we interact with are abstracted through through the GUI. This means that when a problem is encountered the OS would print a pretty error box and the system would restart. This meant that hacking the OS to fix errors isn't as easy as with DOS or *nix systems.

I/O
U, I/O requires some prossor time, always. Even it just flips the bit to tell the DMA to start transfer. There are 2 models of I/O:
1.) Event Driven I/O (Interupts)
2.) Prossess Driven (Polling/programmed I/O)
Macs use Interups, which means that Prossors is told by the user program that I/O is needed, the prossessor tells the DMA to load the data into special registers, when the data is finished the Exception bit in Co-Prossor zero is fliped and the OS (read kernel or Exception handler) takes over control and moves the data from register to the memory slot the requesting program asked it to in.

Prossess Driven I/O uses Polling to coninually ask the keyboard "Are you done yet?" which means that no other prossess can work, the Prossessor is completly monopolized by the I/O access loops. This type of memory map is how the original DOS worked, and how a lot of programs that monitor status in cars/planes/ect. They have no other work to do except see if a deivice is giving imput or not.

The Slowdown
Burrning a CD is just I/O to a device, the prossor isn't bothered by it... What is slowed down is if the bus is still being used by the burning, this isn't a problem after the CDRW or other mass staorage device's write buffer has all the data, but untill that is the case, the prossessor(s) have to use their cashe, which means is there is a cashe miss the miss time will be HUGE because it'll have to wait for the buss to become clear. Moreover, most architectures for dual prossessors, dualg, use a write through which means that if you change something in memory instead of just changing it the cashe it has to write the change out to main memory as well (or the other prossessor wouldn't know of the change) which means that even if the requested item was found in the cashe, if you modified it in anyway it would have to be written back out to main memory and you'd be stuck with another great miss time. Granted that the bus and DMA is fairly fast, but if you are multitasking while burning, you'll notice a slowdown because the write buffers on most CDRWs isn't large enough and requires the bus a number of times.

So, yes, it will take time writting to a crappy drive, but not clockcylces. So sounds like you should have spent the money for the second prossessor on better mass storage devices. :P

The DVD question is also about decoding the DVD, remember that all data is, is 1 and 0 it takes prossessor time to intrepret those 1's and 0's into other 1's and 0's that your monitor reads. Perhpas Dualg4 needs to take Computer Orginization and ASM...

Let me ask a very important question to dualg:
what is: 0101 1000 0101 1111 ?

Another possible slowdown is Pipline Hazards, esspecially true with multipule prossessor machines. The types of hazards are:
1.) Branch instructions (there are 2 that most compliers and arctictures have fixed)
2.) Data update: writes wastes clockcylces if the next line needs to use the data written in the last cylce(The solution is to sneak in another instruction in the wasted clockcycle(most compilers do that as often as it can))
3.) Two instructions trying to access the same resource (the bus) at the same time.

Speeding up
Prossessor resources being the least cause of slowdown, I have to laugh at all this worry about buring clockcylces... I/O is slow, Memory access is slow, the prossessor can handle 5 instructions at a time, but every device uses the BUS (which is fast-ish) and every other device is SLOW (in comparison to the prossessor). You want to speed up any system, what you do is get faster Memory (not more memory mind you) and a single prossessor with a large cashe and then turn off Virtual memory. Also, don't multi task as much and only use programs with good locality of reference (decrease memory acssess and raise cashe hits)

A Mac (prior to OS X) lacked a commandline interface, which meant that the parts of the kernel we interact with are abstracted through through the GUI. This means that when a problem is encountered the OS would print a pretty error box and the system would restart. This meant that hacking the OS to fix errors isn't as easy as with DOS or *nix systems.

-Actually, the reason why it was harder to make the OS fix errors was because the OS rarely ever screwed up. And what's this about *'ing the first letter of Unix?

I/O requires some prossor time, always. Even it just flips the bit to tell the DMA to start transfer. There are 2 models of I/O:
1.) Event Driven I/O (Interupts)
2.) Prossess Driven (Polling/programmed I/O)
Macs use Interups, which means that Prossors is told by the user program that I/O is needed, the prossessor tells the DMA to load the data into special registers, when the data is finished the Exception bit in Co-Prossor zero is fliped and the OS (read kernel or Exception handler) takes over control and moves the data from register to the memory slot the requesting program asked it to in.

Prossess Driven I/O uses Polling to coninually ask the keyboard "Are you done yet?" which means that no other prossess can work, the Prossessor is completly monopolized by the I/O access loops. This type of memory map is how the original DOS worked, and how a lot of programs that monitor status in cars/planes/ect. They have no other work to do except see if a deivice is giving imput or not.

-Correct

Burrning a CD is just I/O to a device, the prossor isn't bothered by it... What is slowed down is if the bus is still being used by the burning, this isn't a problem after the CDRW or other mass staorage device's write buffer has all the data, but untill that is the case, the prossessor(s) have to use their cashe, which means is there is a cashe miss the miss time will be HUGE because it'll have to wait for the buss to become clear. Moreover, most architectures for dual prossessors, dualg, use a write through which means that if you change something in memory instead of just changing it the cashe it has to write the change out to main memory as well (or the other prossessor wouldn't know of the change) which means that even if the requested item was found in the cashe, if you modified it in anyway it would have to be written back out to main memory and you'd be stuck with another great miss time. Granted that the bus and DMA is fairly fast, but if you are multitasking while burning, you'll notice a slowdown because the write buffers on most CDRWs isn't large enough and requires the bus a number of times.

So, yes, it will take time writting to a crappy drive, but not clockcylces. So sounds like you should have spent the money for the second prossessor on better mass storage devices. :P

-I don't have a crappy drive nor a crappy Mac. CDR's don't need to be encoded for use on comsumer DVD players. And CDR's don't hog the system.

The DVD question is also about decoding the DVD, remember that all data is, is 1 and 0 it takes prossessor time to intrepret those 1's and 0's into other 1's and 0's that your monitor reads. Perhpas Dualg4 needs to take Computer Orginization and ASM...

-Yeah sure, and while your at it, dg4, take math 101. (lol!)

Let me ask a very important question to dualg:
what is: 0101 1000 0101 1111 ?

Another possible slowdown is Pipline Hazards, esspecially true with multipule prossessor machines. The types of hazards are:
1.) Branch instructions (there are 2 that most compliers and arctictures have fixed)
2.) Data update: writes wastes clockcylces if the next line needs to use the data written in the last cylce(The solution is to sneak in another instruction in the wasted clockcycle(most compilers do that as often as it can))
3.) Two instructions trying to access the same resource (the bus) at the same time.

Prossessor resources being the least cause of slowdown, I have to laugh at all this worry about buring clockcylces... I/O is slow, Memory access is slow, the prossessor can handle 5 instructions at a time, but every device uses the BUS (which is fast-ish) and every other device is SLOW (in comparison to the prossessor). You want to speed up any system, what you do is get faster Memory (not more memory mind you) and a single prossessor with a large cashe and then turn off Virtual memory. Also, don't multi task as much and only use programs with good locality of reference (decrease memory acssess and raise cashe hits)

Remember this formula:
memory speed = hit%*hitspeed + miss%*missspeed[/b]
How fast does it take to acess level one cashe? well, what percentage of the time do I use level one cashe times how fat it takes to get it out of levelone cashe plus the miss pentalty (the percentage of misses and the time it takes to acess level 2 cashe

-I used to do all my work on a Macintosh Portable backlit. (I still have it.) When this Mac was formatting a floppy, the entire CPU was focused on doing the disk work. Running System 7.0.1\, you couldn't do anything while the disk was formatting. (Not to say you can in OS 9!) Even if you moved the cursor, it would be slow and it would skip.

This is why Mac OS X is such a Great Leap Forward, because OS 9 is built upon the old MacOS's. Though it is not so bad, and on a G3 i/o is pretty fast actually. And it hardly ever crashes. MG

------------------------------------
memphisto has a dirty mind. I feel better saying that. LOL

if return true, then where can I get it?

-- Jack's Contemplative Mind

Macs use Interups...
All disc and network I/O should use that. And it still doesn't answer what the machine can possibly be doing with all the CPU time it eats up in the process. Actually, the Finder might be issuing blocking OS I/O calls that the OS does not reschedule for, making the Mac seem like it is tied up when in fact it's just sat there idling but not responding. The real question is why Windows uses programmed I/O so much, and why Explorer doesn't seem to be threaded at all (or just riddled with poor semaphore usage or something).

I know PhAtfiSh was only getting PIO access to his DVD drive until some kindly app installed offered to bump it up to DMA access, and it got a whole lot faster. I tried to do the same to my work PC's hard disc access, and I think it's still stuck at programmed I/O.

Unless there is some third type of I/O that sits somewhere in between the two, that we don't know about.

...the prossessor tells the DMA to load the data into special registers...
As far as I can recall, we were taught that DMA meant that the I/O controller had direct access to the main memory, and that neither the CPU nor the OS has anything to do with the transfer whatsoever. Unless the lecturer was lying to us. Of course, if the OS really does transfer the data from these registers to the memory (which kind of defeats the point, it seems), then that would explain the CPU being tied up. But I thought that DMA let you transfer large amounts of data in one go, more than would fit in some registers...

The DVD question is also about decoding the DVD
I only understood it to be referring to encoding, didn't I? Encoding and decoding are two seperate tasks altogether, assuming you've already mastered the DVD. Encoding is just data transfer from the hard disc to the DVD, whereas decoding is indeed CPU intensive. Hell, my 604e can't even play a WMV - it can only just manage MPG, although MP3s play just fine.

...it takes prossessor time to intrepret those 1's and 0's into other 1's and 0's that your monitor reads.
Um, playing DVDs takes a bit more than just interpret 1s and 0s... MPEG-2 is a very complex format.

Quoting MacGenius:
Actually, the reason why it was harder to make the OS fix errors was because the OS rarely ever screwed up.
Maybe. It's different for everyone - my Mac experience hasn't been too bad at all, but I've had times when stuff just won't work and I have no idea what's going wrong, and where, and why. Actually, that reminds me that something else reminded me of removing Borland C++ debugger virtual device driver entry lines from Windows 3.11 system.ini because they were conflicting with McAfee VShield VXDs and causing Windows to fail to start at all. How I worked out it was those two in conflict, I have no idea whatsoever. It might have been the bootlog that told me. Mac OS can be a total pain to sort out for some people, but on the flip side, is very easy to configure, e.g. installation and de-installation of extensions via drag and drop of single files. But if you have an extension conflict, or random OS lock-ups, who knows what went wrong? Anyone?

And what's this about *'ing the first letter of Unix?
*NIX covers Linux as well as other OSes considered to be UNIX. It makes no real sense as *NIX is not a pattern that matches both Linux and UNIX, but if you just say UNIX, I think people consider Linux to be excluded. Or something like that.

If it worked for me, it shound work for you, and if it doesn't your Mac is really screwed up
(referring to the ResEdit solution)
Let me clarify. Inside the extension are a whole bunch of icons. One icon family is the one that the Finder uses for the extension itself, according to the bundle. All the other icons are given to CDs mounted on the desktop - the extension provides Joliet and ISO 9660 filename access and gives the CD a special icon to indicate the filename system in use.

At start-up, the icon being shown is not the one shown in the Finder, but a different icon. The four filename type icons are "Joliet", "ISO 9660", "ISO/Joliet" and "Rockridge". I have no CDs that use both Joliet and ISO 9660 together, that I know of, so maybe that icon was indeed created purely for display at start-up. Changing it will obviously fix the problem, but Murphy's law says that one day, I'll get a CD mount with an extension icon...

Oh, and here's a question for MacGenius's Q&A: when are you and dualg going to stop bitching at each other, you in particular?

And what's this about *'ing the first letter of Unix?[/b]
*NIX covers Linux as well as other OSes considered to be UNIX. It makes no real sense as *NIX is not a pattern that matches both Linux and UNIX, but if you just say UNIX, I think people consider Linux to be excluded. Or something like that.

Well, It's either *NIX or *NUX.

Oh, and here's a question for MacGenius's Q&A: when are you and dualg going to stop bitching at each other, you in particular?

Hmm...let me see. I've already said this before, but Dualg started it. if you rewind to page 1, you will see that I wasn't in the intention of fighting with anyone. Dualg obviously got mad because I couldn't awnser the question. For crying out loud, dg4, "MacGenius" is just a name. I chose it because I am kinda like that guy in the Joy of Tech with the MacGenius tshirt only I carry around a WallstreetG3 instead of a iBook.

Some people like dualg see the name macGenius and think that I know everything about macintosh that you could imagine. Fact is, I don't. if you or someone has a question I can't awnser, instead of starting a "flame thread" you can help me find a solution. after all, two brains are better than one. I will be very happy to stop this fight if dg will comply. Me in particular? gimme a break.

- MG

quote:

---

Originally posted by MacGenius:
True, and you can get it at www.freebsd.org

---

Ok, maybe I was on the sarcastic side there. Here's a better explanation...

The same reason why a PC (Intelx86) version of Linux won't run on a Mac without Virtual PC, and SuSE Linux PowerPC won't run on a PC, Mac OS X cannot run on a PC. It is true that it is Linux-based which is a cross-platform OS, but it is programmed for PPC, same way x86 Linux is programmed for x86 and you need VPC to run it. In other words, it is incompatible.

Now if you can run PC OS's on a Mac, why can't you do the opposite?

Um, let's go back to 1984.

You see, IBM made their computers for ontheshelf parts availible at any hobbist store. And Windows was written for ontheshelf parts, and this is how the PC cloning came along and why IBM can't do anything about it.

Steve Jobs & Company, on the other hand, wisely chose to program their own ROMs, which they had copyright to unlike the IBM roms which everybody could copy. So nobody can make mac emulators or clones w/o Apple's consent.

By making a PC emulator, Connectix is basically making a PC clone. Even though Windows is copyrighed, Connectix buys rights to it, much like Compaq or Gateway.

However, with Apple it is not so. The only Mac Emulator that I saw yet for a PC was one that emualted a Mac Plus... But what can you do on that? And you need to make a copy of a Mac Plus ROM so that company that Makes is won't get in legal trouble. And you need boot disks too.

In other words, it can't be done. I suggested FreeBSD because Mac OS X is based on that. If you don't like Fbsd, hey, it's never been a better time to get a Mac. You can get a pretty decent eMac for only a grand...and you can always but used models like me. (PowerBook G3, 8/192, 300MHZ, DVD, SuperDisk, ZIP 100, 3 batts, charger, P/S...$650).

MG

quote:

---

Originally posted by Tyler Durden:
I was told by my former roomate I could obtain OS X without the GUI and it would work on my AMD Duron machine... true or false?

if return true, then where can I get it?

-- Jack's Contemplative Mind

---

mg.... i don't mean to be competative here, but you can obtain it, weather it would work is another story.

You can actually get darwin, (the core of mac os x) for an x86.

i have to go out to dinner now, but i'll get you a link this evenign

>hee hee<

quote:

---

Originally posted by MacGenius:
Dualg4, have you taken "microprocessorwerks" class yet? Now that might be your problem! A Wintel machine won't even mount the OS X install CD, let alone use software on it.

---

mmm....
that's not at all what i meant

on the darwin info page, you used to be able to download darwin for x86, without gui, obviously, andn without a lot of other things, but darwin nonetheless, still looking for a page... i burnt it to a cd and tried it once... it only works with the equipt that they tested it on

IBM made their own ROMS too, however all the other components in the world's 2nd succesful personal computer (the Apple ][ being the 1st) were standard off the shelf parts. Compaq (and others) reverse engineered the custom ROM so that they had their own one that didn't incorporate any IBM code but had the same function addresses and did the same thing. They could then clone the IBM PC legaly (if imorrally). At the same time, cloners in Hong Kong just copied the IBM ROMS and mass produced cheap illegally cloned PCs.

Apple used off the shelf parts too in the Apple ][, ][+ and ][e with easily copyable Apple ROMS. Again these were massively cloned outside the US and so future Apple machines (like your ][c MG) used custom components that were harder to copy.

quote:

---

Originally posted by MacGenius:
Dualg4, have you taken "microprocessorwerks" class yet? Now that might be your problem! A Wintel machine won't even mount the OS X install CD, let alone use software on it.

---

i'm no idiot
have you taken your social skills class yet?

------------------
'Excuse me, I have to go blow somethign up..... It's a military thing....'-Col. Jack. O'Neil