Original Macintosh Architecture Questions
Hey folks -- Two items I'm curious about on the classic (and very original) Apple Macs.. 1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984) 2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster? Thanks!
John, If they used a 60040 rather than a 60000 chip that would be a lot faster Bill On Wed, Jun 23, 2021 at 4:25 PM John Heritage via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
Thanks!
The original Mac's architecture locked out the CPU's access to memory during screen refreshes, so maybe that changed in the Classic (which also used a 68000) As far as sound, according to Wikipedia: Two TTL chips provide an 8-bit P <https://en.wikipedia.org/wiki/Pulse-width_modulation>WM sound driver (74LS161 type). So it could do 8-bit samples. Two analog chips providing sound amplification (MC14016 switch, LF353 op-amp) You would clock the sound using the 6522 VIA bridge chip that is connected to the RTC and a 32.768 oscillator On Wed, Jun 23, 2021 at 4:35 PM Bill Degnan via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
John, If they used a 60040 rather than a 60000 chip that would be a lot faster Bill
On Wed, Jun 23, 2021 at 4:25 PM John Heritage via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
Thanks!
Sorry I should have clarified. All of those models are 68000s at 8 (or in one case 7.8)mhz On Wed, Jun 23, 2021, 4:35 PM Bill Degnan via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
John, If they used a 60040 rather than a 60000 chip that would be a lot faster Bill
On Wed, Jun 23, 2021 at 4:25 PM John Heritage via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
Thanks!
The Mac sound hardware was pretty rudimentary : https://en.wikipedia.org/wiki/Macintosh_128K/512K_technical_details It is basically a DAC mono running at 22.25kHz. I guess it was kind of advanced for the time? I assume all the speech stuff was software synthesis, like the DOS programs like say.exe that did similar tricks. Sound Blaster 1.0 was limited to 11khz on it's DAC so the Macintosh was better. But SBPro had dual 22.5khz for stereo. The Atari ST was similar CPU, no idea why it could achieve faster performance. Early Macs sure are pretty sluggish though. - Ethan On Wed, 23 Jun 2021, John Heritage via vcf-midatlantic wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
Thanks!
On 6/23/21 4:55 PM, Ethan O'Toole via vcf-midatlantic wrote:
The Atari ST was similar CPU, no idea why it could achieve faster performance. Early Macs sure are pretty sluggish though.
It's pretty easy to hamstring a fast processor with poor systems-level design. Look at the SGI Indigo2 R10K systems, for example. An Octane with the same CPU at the same clock speed runs rings around it. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Woah there. There is no such thing as a bad SGI. Every one of them at least ran IRIX, no matter the systems-level design (or lack thereof). Also, the octane was not purple. And many wanted a purple computer. Or at least found out they did. -andy
On Jun 23, 2021, at 5:04 PM, Dave McGuire via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
On 6/23/21 4:55 PM, Ethan O'Toole via vcf-midatlantic wrote:
The Atari ST was similar CPU, no idea why it could achieve faster performance. Early Macs sure are pretty sluggish though.
It's pretty easy to hamstring a fast processor with poor systems-level design. Look at the SGI Indigo2 R10K systems, for example. An Octane with the same CPU at the same clock speed runs rings around it.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
On 6/23/21 5:19 PM, Andrew Diller wrote:
Woah there. There is no such thing as a bad SGI. Every one of them at least ran IRIX, no matter the systems-level design (or lack thereof).
Oh nono, don't get me wrong, I love any and all SGI hardware. I ran an Indigo2 R10K MaxImpact as my primary desktop for many years and adored it. But an Octane with the same CPU at the same clock rate does, in fact, trounce it in terms of available CPU performance.
Also, the octane was not purple. And many wanted a purple computer. Or at least found out they did.
Too true. ;) -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Ok, while on that subject, when I come and visit the LSSM, what can one expect in terms of SGI representation? While most SGI's were desktop/workstation class systems there are some large ones. -andy
On Jun 23, 2021, at 5:22 PM, Dave McGuire via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
On 6/23/21 5:19 PM, Andrew Diller wrote:
Woah there. There is no such thing as a bad SGI. Every one of them at least ran IRIX, no matter the systems-level design (or lack thereof).
Oh nono, don't get me wrong, I love any and all SGI hardware. I ran an Indigo2 R10K MaxImpact as my primary desktop for many years and adored it.
But an Octane with the same CPU at the same clock rate does, in fact, trounce it in terms of available CPU performance.
Also, the octane was not purple. And many wanted a purple computer. Or at least found out they did.
Too true. ;)
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
There is a really nice SGI server rack or three there. LSSM is more about the servers than the workstations. On Thu, Jun 24, 2021 at 11:51 AM Andrew Diller via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Ok, while on that subject, when I come and visit the LSSM, what can one expect in terms of SGI representation? While most SGI's were desktop/workstation class systems there are some large ones.
-andy
On Jun 23, 2021, at 5:22 PM, Dave McGuire via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
On 6/23/21 5:19 PM, Andrew Diller wrote:
Woah there. There is no such thing as a bad SGI. Every one of them at least ran IRIX, no matter the systems-level design (or lack thereof).
Oh nono, don't get me wrong, I love any and all SGI hardware. I ran an Indigo2 R10K MaxImpact as my primary desktop for many years and adored it.
But an Octane with the same CPU at the same clock rate does, in fact, trounce it in terms of available CPU performance.
Also, the octane was not purple. And many wanted a purple computer. Or at least found out they did.
Too true. ;)
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
Though we've branched out quite a bit, minicomputers, mainframes, and supercomputers are the primary focus. It largely drops off before the terms "server" and "workstation" came into common use, so we never (ever) say "servers". Almost none of them were used in roles that we would now attribute to servers. -Dave On 6/24/21 12:05 PM, Bill Degnan via vcf-midatlantic wrote:
There is a really nice SGI server rack or three there. LSSM is more about the servers than the workstations.
On Thu, Jun 24, 2021 at 11:51 AM Andrew Diller via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Ok, while on that subject, when I come and visit the LSSM, what can one expect in terms of SGI representation? While most SGI's were desktop/workstation class systems there are some large ones.
-andy
On Jun 23, 2021, at 5:22 PM, Dave McGuire via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
On 6/23/21 5:19 PM, Andrew Diller wrote:
Woah there. There is no such thing as a bad SGI. Every one of them at least ran IRIX, no matter the systems-level design (or lack thereof).
Oh nono, don't get me wrong, I love any and all SGI hardware. I ran an Indigo2 R10K MaxImpact as my primary desktop for many years and adored it.
But an Octane with the same CPU at the same clock rate does, in fact, trounce it in terms of available CPU performance.
Also, the octane was not purple. And many wanted a purple computer. Or at least found out they did.
Too true. ;)
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
-- Dave McGuire, AK4HZ New Kensington, PA
On 6/24/21 11:51 AM, Andrew Diller wrote:
Ok, while on that subject, when I come and visit the LSSM, what can one expect in terms of SGI representation? While most SGI's were desktop/workstation class systems there are some large ones.
There's almost no SGI hardware on exhibit right now, though we'll be putting together an Onyx2 system as a visualization workstation for the newly-restored Cray J90. In storage, the museum has an Origin 2400 and an Origin 3000, both single rack configs. They had been on exhibit for a few years, but were rotated out. My personal collection includes a whole slew of other SGI machines, including a numbered Crimson Jurassic Classic. Some of those will be moved to the under-construction "workstations and small workgroup servers" exhibit floor. That's been perpetually under construction for years due to an unending lack of help, but we'll eventually get it done. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
OK- while SGI is usually associated with the desktop gfx visualization space they did quite a lot in the cluster and super computing space... The Power Challenge and Origin systems were all designed to be supercomputing clusters. The MIPS R8000 was a fascinating dead-end in chip development: https://en.wikipedia.org/wiki/R8000 <https://en.wikipedia.org/wiki/R8000> I look forward to visiting and seeing what you have out there. -andy
On Jun 24, 2021, at 12:45 PM, Dave McGuire via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
On 6/24/21 11:51 AM, Andrew Diller wrote:
Ok, while on that subject, when I come and visit the LSSM, what can one expect in terms of SGI representation? While most SGI's were desktop/workstation class systems there are some large ones.
There's almost no SGI hardware on exhibit right now, though we'll be putting together an Onyx2 system as a visualization workstation for the newly-restored Cray J90.
In storage, the museum has an Origin 2400 and an Origin 3000, both single rack configs. They had been on exhibit for a few years, but were rotated out.
My personal collection includes a whole slew of other SGI machines, including a numbered Crimson Jurassic Classic. Some of those will be moved to the under-construction "workstations and small workgroup servers" exhibit floor. That's been perpetually under construction for years due to an unending lack of help, but we'll eventually get it done.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
On 6/24/21 1:16 PM, Andrew Diller wrote:
OK- while SGI is usually associated with the desktop gfx visualization space they did quite a lot in the cluster and super computing space...
Yes. I myself tend to think of that first when SGI comes up, as I did a lot of stuff in the HPC world.
The Power Challenge and Origin systems were all designed to be supercomputing clusters.
Yes. The Origin architecture is nothing short of glorious.
The MIPS R8000 was a fascinating dead-end in chip development: https://en.wikipedia.org/wiki/R8000
It's an amazing chip. I do have a deskside Challenge with R8000 CPUs. It's on the list of things to get running in the third exhibit floor, if anyone ever gets to it.
I look forward to visiting and seeing what you have out there.
Well again, most of the SGI stuff is in storage, but we can go see most of it at least. -Dave -- Dave McGuire, AK4HZ New Kensington, PA
I went to an Origin 2000/Onyx2 training back in 1997. I think 97. It was at the building that is now the Computer History Museum. Most of the people I met were with the military and oil and gas. The US government had a lot of SGIs. In fact for a while, we used to look for parts on the gov auctions. On Thu, Jun 24, 2021 at 1:18 PM Andrew Diller via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
OK- while SGI is usually associated with the desktop gfx visualization space they did quite a lot in the cluster and super computing space...
The Power Challenge and Origin systems were all designed to be supercomputing clusters.
The MIPS R8000 was a fascinating dead-end in chip development: https://en.wikipedia.org/wiki/R8000 <https://en.wikipedia.org/wiki/R8000>
I look forward to visiting and seeing what you have out there.
-andy
On 6/24/21 1:27 PM, Christian Liendo via vcf-midatlantic wrote:
I went to an Origin 2000/Onyx2 training back in 1997. I think 97.
It was at the building that is now the Computer History Museum.
Most of the people I met were with the military and oil and gas.
The US government had a lot of SGIs.
In fact for a while, we used to look for parts on the gov auctions.
We beta-tested the 2000 at Digex. I picked up my Origin 2400 at a surplus dealer in Virginia about ten years ago. It had NASA property stickers on it; it had come from Goddard Space Flight Center in Greenbelt, MD. Surprisingly, the disks were intact. I used to live in Greenbelt; that's where Digex was founded. A guy who worked for me, my dear friend Mike Donovan, left Digex when we all dispersed, and went on to work for NASA at GSFC. He was the admin in charge of all SGI systems there. There was an /etc/passwd entry for him on that Origin 2400. I emailed him to discuss it; he told me all about what the machine had been doing, and gave me a lot of history about its service life there. Strange and fun coincidences! -Dave -- Dave McGuire, AK4HZ New Kensington, PA
Early in my career I worked at a supercomputing facility. Almost all of our SGI machines were headless. https://users.757.org/~ethan/pics/office/13/Image01.jpg https://users.757.org/~ethan/pics/office/13/Image10.jpg https://users.757.org/~ethan/pics/office/13/Image13.jpg https://users.757.org/~ethan/pics/office/13/Image15.jpg https://users.757.org/~ethan/pics/office/13/Image20.jpg It's so big... and purple.
OK- while SGI is usually associated with the desktop gfx visualization space they did quite a lot in the cluster and super computing space...
The Power Challenge and Origin systems were all designed to be supercomputing clusters.
The MIPS R8000 was a fascinating dead-end in chip development: https://en.wikipedia.org/wiki/R8000 <https://en.wikipedia.org/wiki/R8000>
I look forward to visiting and seeing what you have out there.
-andy
On Jun 24, 2021, at 12:45 PM, Dave McGuire via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
On 6/24/21 11:51 AM, Andrew Diller wrote:
Ok, while on that subject, when I come and visit the LSSM, what can one expect in terms of SGI representation? While most SGI's were desktop/workstation class systems there are some large ones.
There's almost no SGI hardware on exhibit right now, though we'll be putting together an Onyx2 system as a visualization workstation for the newly-restored Cray J90.
In storage, the museum has an Origin 2400 and an Origin 3000, both single rack configs. They had been on exhibit for a few years, but were rotated out.
My personal collection includes a whole slew of other SGI machines, including a numbered Crimson Jurassic Classic. Some of those will be moved to the under-construction "workstations and small workgroup servers" exhibit floor. That's been perpetually under construction for years due to an unending lack of help, but we'll eventually get it done.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
To me the Octane's color is too blue to be "purple", the SGI Indigo10000 on the other hand is purple on the indigo palette: https://www.vintagecomputer.net/SGI/Indigo2_10000/ https://www.color-hex.com/color-palette/2792 So. On Wed, Jun 23, 2021 at 5:19 PM Andrew Diller via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Woah there. There is no such thing as a bad SGI. Every one of them at least ran IRIX, no matter the systems-level design (or lack thereof).
Also, the octane was not purple. And many wanted a purple computer. Or at least found out they did.
-andy
On Jun 23, 2021, at 5:04 PM, Dave McGuire via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
On 6/23/21 4:55 PM, Ethan O'Toole via vcf-midatlantic wrote:
The Atari ST was similar CPU, no idea why it could achieve faster performance. Early Macs sure are pretty sluggish though.
It's pretty easy to hamstring a fast processor with poor systems-level design. Look at the SGI Indigo2 R10K systems, for example. An Octane with the same CPU at the same clock speed runs rings around it.
-Dave
-- Dave McGuire, AK4HZ New Kensington, PA
A few things: http://mirror.informatimago.com/next/developer.apple.com/documentation/mac/S... <http://mirror.informatimago.com/next/developer.apple.com/documentation/mac/Sound/Sound-2.html> https://en.wikipedia.org/wiki/Macintosh_128K/512K_technical_details#Sound <https://en.wikipedia.org/wiki/Macintosh_128K/512K_technical_details#Sound> Later Macs: http://midibox.org/forums/topic/11239-macintosh-apple-sound-chip/ <http://midibox.org/forums/topic/11239-macintosh-apple-sound-chip/> As for speed, read the Speed & Video Section: https://lowendmac.com/2014/inside-the-original-macintosh/ <https://lowendmac.com/2014/inside-the-original-macintosh/> for a possible explanation. -andy
On Jun 23, 2021, at 4:24 PM, John Heritage via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
Thanks!
Thanks. I did read most of those links actually before I posted. I appreciated the simple explanations on sound here. That last link explained how the CPU shared the memory but I'm curious what changed specifically in the classic and/or allowed the ST to perform a bit faster on same code (while the ST also shares the bus with shifter). Thanks On Wed, Jun 23, 2021, 4:56 PM Andrew Diller <dillera@gmail.com> wrote:
A few things:
http://mirror.informatimago.com/next/developer.apple.com/documentation/mac/S...
https://en.wikipedia.org/wiki/Macintosh_128K/512K_technical_details#Sound
Later Macs: http://midibox.org/forums/topic/11239-macintosh-apple-sound-chip/
As for speed, read the Speed & Video Section: https://lowendmac.com/2014/inside-the-original-macintosh/
for a possible explanation.
-andy
On Jun 23, 2021, at 4:24 PM, John Heritage via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
Thanks!
The Mac Classic is faster than the 128k-Plus, but is equally as fast as an SE. Most of the improvement is in SCSI throughput. I own both a Plus and Classic, and confirm the Classic is a bit snappier. It also has a flatter CRT. -J On Wed, Jun 23, 2021 at 4:25 PM John Heritage via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
Thanks!
-- Jason Perkins 313 355 0085
On Jun 23, 2021, at 4:24 PM, John Heritage via vcf-midatlantic <vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
It used some extra gates on the PALs in the timing and/or memory controllers to do a PWM which was then filtered down by an RC circuit to make a crude (but effective) DAC, similar to how delta-sigma DACs work. A similar circuit did the speed control for the floppy drive, which slowed down as it approached the outer tracks. Both took the PWM width data from unused bytes at the end of the video rows as the video scanning circuit went through horizontal refresh, so there weren't any real wasted cycles.
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
It was actually improvements in the bus timing PALs that made the cycles a little tighter, allowing the CPU to run faster because it wasn't waiting for RAM as long. Jecel Assumpciao has/had some really good stuff on the memory timing generator (including the sound/floppy PWM) here: http://archive.retro.co.za/mirrors/homepage.ntlworld.com/kryten_droid/AppleM... In any case, it was still an 8 MHz 68000, but the improved memory timings did yield a performance improvement. - Dave
Thanks David! That diagram (Apple Mac Logic) explains perfectly why the 1990 Mac Classic and the Atari ST were often 20-25% faster than the original Mac despite all being 8 MHz 68000s. The Original Mac gave 4 cycles of memory for CPU followed by 4 cycles of memory for everything else. The ST gave 2 cycles of memory for CPU followed by 2 cycles of memory for everything else (glue/shifter/mmu). The upgraded Macs basically gave 6 cycles of memory for the CPU then 2 cycles for everything else by doubling memory speed. The 68000 would stall for some (many?) instructions with the 4/4 cycle but is able to more or less run at full speed on the 6/2 (Mac) or 2/2 (ST) cycling. Interesting & Thanks!! Last question on the Mac Audio -- Is it fair to say that if you wanted audio on the Mac, you basically wanted to digitally sample a sound/take a sound sample and then have the CPU shape it so it would output correctly? (i.e. costing some CPU cycles) On Thu, Jun 24, 2021 at 11:21 AM David Riley <fraveydank@gmail.com> wrote:
On Jun 23, 2021, at 4:24 PM, John Heritage via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
Hey folks --
Two items I'm curious about on the classic (and very original) Apple
Macs..
1. Mac (128kb ,512kb, etc) audio -- was there a custom or off the shelf sound chip for the audio on the original Mac? and was it 1 channel / and was it a custom chip by Apple? (how did it achieve speech synthesis in 1984)
It used some extra gates on the PALs in the timing and/or memory controllers to do a PWM which was then filtered down by an RC circuit to make a crude (but effective) DAC, similar to how delta-sigma DACs work. A similar circuit did the speed control for the floppy drive, which slowed down as it approached the outer tracks. Both took the PWM width data from unused bytes at the end of the video rows as the video scanning circuit went through horizontal refresh, so there weren't any real wasted cycles.
2. The Macintosh Classic released in 1990 "was about 25% faster than the original Macs". This is in line with the Atari ST often being quoted as faster than a Mac when emulating a Mac via Magic Sac or similar. What changed in the architecture to make the Mac Classic (or an ST in emulation) faster than the original Mac? Was it faster memory that gave more availability for CPU usage? were only certain instructions sped up or was everything faster?
It was actually improvements in the bus timing PALs that made the cycles a little tighter, allowing the CPU to run faster because it wasn't waiting for RAM as long. Jecel Assumpciao has/had some really good stuff on the memory timing generator (including the sound/floppy PWM) here: http://archive.retro.co.za/mirrors/homepage.ntlworld.com/kryten_droid/AppleM...
In any case, it was still an 8 MHz 68000, but the improved memory timings did yield a performance improvement.
- Dave
On Jun 24, 2021, at 4:05 PM, John Heritage <john.heritage@gmail.com> wrote:
Thanks David!
Absolutely! I love the hardware design of the original Mac; it's amazingly minimal given the constraints of technology at the time, with some really clever use of PALs to shrink logic down; the only really custom chip in there is the IWM, which was necessary because pretty much no one else used Apple's GCR format, though the SWIM controller had an even neater logic implementation that could also handle MFM using the same decoder components, which is why it was PC compatible (same reason USB floppy drives can read HD Mac disks and 720K PC disks but not 800K Mac disks; Mac HD disks were MFM).
That diagram (Apple Mac Logic) explains perfectly why the 1990 Mac Classic and the Atari ST were often 20-25% faster than the original Mac despite all being 8 MHz 68000s.
The Original Mac gave 4 cycles of memory for CPU followed by 4 cycles of memory for everything else.
Yeah, and that's what the 68000 datasheet would lead you to believe you want for the bus, but it's not always the best. It's such a strange bus, and it shows you how the "MHz myth" started early; the 68000 had high clock speeds, but it didn't do much per clock (though having a true 16-bit ALU helped).
The ST gave 2 cycles of memory for CPU followed by 2 cycles of memory for everything else (glue/shifter/mmu).
The upgraded Macs basically gave 6 cycles of memory for the CPU then 2 cycles for everything else by doubling memory speed.
The 68000 would stall for some (many?) instructions with the 4/4 cycle but is able to more or less run at full speed on the 6/2 (Mac) or 2/2 (ST) cycling.
Yup. Aside from the Portable, most of the 68000 Macs weren't really all that different architecturally; the Plus added a SCSI controller and the Classic got some better timings, and the SE had a PDS slot, but other than that and some extra memory space, they're all almost the same machine (though the ROM contents make a difference).
Last question on the Mac Audio --
Is it fair to say that if you wanted audio on the Mac, you basically wanted to digitally sample a sound/take a sound sample and then have the CPU shape it so it would output correctly? (i.e. costing some CPU cycles)
You could say that, but it would probably be more accurate to say that when the Mac came around, not many other machines had real sampled audio out, so the sound quality was pretty good for the time already. But it wasn't perfect, as related in this excellent story from Andy Hertzfeld's recollections of the development of the original Mac: https://www.folklore.org/StoryView.py?project=Macintosh&story=Boot_Beep.txt In any case, any application with high quality audio for the time (here I'm thinking something like Dark Castle, which actually has really great sound effects) probably either just lived with the iffy quality or pre-equalized the audio, but given that Dark Castle sounds pretty similar on a machine with a real sound chip like something from the II series, I doubt it makes that much of a difference. Keep in mind that a PWM through a properly tuned RC filter isn't going to sound a whole lot different from an actual DAC (again, delta-sigma DACs work basically on this principle, just a whole lot faster). That site, by the way, is replete with stories you won't find anywhere else (aside from Andy's book, which is the contents of the site plus a few more stories and lots of pictures). I really loved reading through it. - Dave
On Jun 24, 2021, at 10:31 PM, David Riley <fraveydank@gmail.com> wrote:
On Jun 24, 2021, at 4:05 PM, John Heritage <john.heritage@gmail.com> wrote:
Last question on the Mac Audio --
Is it fair to say that if you wanted audio on the Mac, you basically wanted to digitally sample a sound/take a sound sample and then have the CPU shape it so it would output correctly? (i.e. costing some CPU cycles)
You could say that, but it would probably be more accurate to say that when the Mac came around, not many other machines had real sampled audio out, so the sound quality was pretty good for the time already. But it wasn't perfect, as related in this excellent story from Andy Hertzfeld's recollections of the development of the original Mac: https://www.folklore.org/StoryView.py?project=Macintosh&story=Boot_Beep.txt
In any case, any application with high quality audio for the time (here I'm thinking something like Dark Castle, which actually has really great sound effects) probably either just lived with the iffy quality or pre-equalized the audio, but given that Dark Castle sounds pretty similar on a machine with a real sound chip like something from the II series, I doubt it makes that much of a difference. Keep in mind that a PWM through a properly tuned RC filter isn't going to sound a whole lot different from an actual DAC (again, delta-sigma DACs work basically on this principle, just a whole lot faster).
That site, by the way, is replete with stories you won't find anywhere else (aside from Andy's book, which is the contents of the site plus a few more stories and lots of pictures). I really loved reading through it.
Also, speaking of, this is another great story from the same source about the development of the sound capabilities on the original Mac, including some details about the audio fetch during horizontal blanking: https://www.folklore.org/StoryView.py?project=Macintosh&story=Sound_By_Monda... - Dave
Wow! Good articles and thanks David! Since you mentioned you loved the original hardware design of the Mac, I hope you won't mind a few more questions.. Interesting on the IWM making it to the Mac, I knew that was a really innovative chip on the Apple II, but didn't realize it also was used in early Macs. What was the reason the PC used 9 sectors per track while the Mac and Amiga used 10/11 sectors per track each on the 3.5" floppies? (I assume the ST defaulted to 9 sectors per track to stay compatible with DOS disks..) Was it because the PC technically predated the original Mac and Amiga/ST and the early drives/disks were risky with higher densities? Did Apple trade anything off for 400KB floppies in the Mac? Hardware wise, is it fair to say that the Mac probably cost less to manufacture in ~ 1985 than say the Amiga 1000 or Atari 520ST? The Amiga had several custom chips, and even the ST seemed to have more ICs on board, though monitors were optional for both. (I think in 1984 RAM was still very expensive so I can see why the 128KB Mac would be high, especially as an early adopter premium). I always assumed the Mac premium was due to it's software library and 'brand' (at least in the US) at the time, but curious if there were any hardware reasons for the cost. Last question -- were there 'fast ram' upgrades for the original Macs (say pre-1990) that would allow the 68000 access to local memory for faster execution than RAM on the shared bus? or did all RAM have to be shared? It looks like the ram size limitations on the early Macs were relatively close to what the 68000 could do.. Thanks! On Thu, Jun 24, 2021 at 10:38 PM David Riley <fraveydank@gmail.com> wrote:
On Jun 24, 2021, at 10:31 PM, David Riley <fraveydank@gmail.com> wrote:
On Jun 24, 2021, at 4:05 PM, John Heritage <john.heritage@gmail.com>
wrote:
Last question on the Mac Audio --
Is it fair to say that if you wanted audio on the Mac, you basically wanted to digitally sample a sound/take a sound sample and then have the CPU shape it so it would output correctly? (i.e. costing some CPU cycles)
You could say that, but it would probably be more accurate to say that
when the Mac came around, not many other machines had real sampled audio out, so the sound quality was pretty good for the time already. But it wasn't perfect, as related in this excellent story from Andy Hertzfeld's recollections of the development of the original Mac: https://www.folklore.org/StoryView.py?project=Macintosh&story=Boot_Beep.txt
In any case, any application with high quality audio for the time (here
I'm thinking something like Dark Castle, which actually has really great sound effects) probably either just lived with the iffy quality or pre-equalized the audio, but given that Dark Castle sounds pretty similar on a machine with a real sound chip like something from the II series, I doubt it makes that much of a difference. Keep in mind that a PWM through a properly tuned RC filter isn't going to sound a whole lot different from an actual DAC (again, delta-sigma DACs work basically on this principle, just a whole lot faster).
That site, by the way, is replete with stories you won't find anywhere
else (aside from Andy's book, which is the contents of the site plus a few more stories and lots of pictures). I really loved reading through it.
Also, speaking of, this is another great story from the same source about the development of the sound capabilities on the original Mac, including some details about the audio fetch during horizontal blanking: https://www.folklore.org/StoryView.py?project=Macintosh&story=Sound_By_Monda...
- Dave
On Jun 25, 2021, at 9:01 AM, John Heritage <john.heritage@gmail.com> wrote:
Wow! Good articles and thanks David! Since you mentioned you loved the original hardware design of the Mac, I hope you won't mind a few more questions..
Interesting on the IWM making it to the Mac, I knew that was a really innovative chip on the Apple II, but didn't realize it also was used in early Macs.
The IWM was, essentially, an IC version of the Disk II controller (there are a few differences, but that's pretty close). I think it came to the Mac first, since the Apple //e came after the Apple /// tanked, but I could have my timelines mixed up there.
What was the reason the PC used 9 sectors per track while the Mac and Amiga used 10/11 sectors per track each on the 3.5" floppies? (I assume the ST defaulted to 9 sectors per track to stay compatible with DOS disks..) Was it because the PC technically predated the original Mac and Amiga/ST and the early drives/disks were risky with higher densities? Did Apple trade anything off for 400KB floppies in the Mac?
The short answer is that 400/800K floppies used GCR encoding for their low-level format, while 360/720K (and also 1440K) floppies used MFM. They're just two different encoding methods; I don't think one is necessarily superior to another other than the fact that you can pack a little more space into a track with GCR encoding. MFM was the defacto standard on the IBM side for floppies (it's what the original IBM floppy controllers supported), so when Apple added HD capability with the SWIM chip, they went with MFM to be compatible with PCs (thus also gaining compatibility with DD 360/720K disks). The "ISM" (Integrated Sander Machine, AFAICT, as that part was designed by Wendell Sander) portion of the SWIM was basically a new decoding machine that could handle both MFM and GCR with a lot of the same circuitry and state machines. It's really a brilliant design; you can read the SWIM chip design docs on the Archive somewhere if you're curious. Really neat stuff. Later SWIM chips dropped the IWM portion entirely, if memory serves, because the ISM worked well enough for both modes and didn't require the CPU overhead that the IWM did (mostly owing to the tradeoffs that made the Disk II controller such simple hardware; it's basically a step away from bit-banged).
Hardware wise, is it fair to say that the Mac probably cost less to manufacture in ~ 1985 than say the Amiga 1000 or Atari 520ST? The Amiga had several custom chips, and even the ST seemed to have more ICs on board, though monitors were optional for both. (I think in 1984 RAM was still very expensive so I can see why the 128KB Mac would be high, especially as an early adopter premium). I always assumed the Mac premium was due to it's software library and 'brand' (at least in the US) at the time, but curious if there were any hardware reasons for the cost.
I don't know if I'd say that... what the Amiga and ST cost in custom chips, the Mac probably made up for with rather expensive PALs, though they did at least use the mask-programmed version of them (HALs) once they'd finalized the design, which would have saved a fair amount at those volumes. PALs were off the shelf, which made it much easier to prototype, but in volume, a custom chip can be cheaper. I don't know the relative manufacturing prices, but I'd guess that the Mac cost a bit more to build with the CRT and supporting circuitry. Of course, there's an article about exactly this, too: https://www.folklore.org/StoryView.py?project=Macintosh&story=Price_Fight.tx...
Last question -- were there 'fast ram' upgrades for the original Macs (say pre-1990) that would allow the 68000 access to local memory for faster execution than RAM on the shared bus? or did all RAM have to be shared? It looks like the ram size limitations on the early Macs were relatively close to what the 68000 could do..
The original Mac was a pretty simple machine; everything lived on the 68000 bus, for the most part (the 68000, as you may know, also had some special circuitry for directly addressing 6800-bus-compatible devices, which I think they used for the VIA and the Z8530 serial chip, possibly some others, but it was all still the same bus with some slightly different control signals). I have a 128K with a Max II upgrade (pass-through board for the CPU socket that expanded RAM to 1MB and added Mac Plus-ish ROMs, we always called it a "Mac Minus" when I was growing up), but as far as I know the most you could really do to speed up the RAM on that system would be to shift the timings like the Classic did. The original 68K had a 24-bit address bus, so it could address up to 16MB, but not all of that could be RAM because you have to leave room for I/O devices and the ROM. Unlike Intel CPUs, the 68K didn't have the (IMO) silly notion of a separate I/O space, which really just involves a more complex chip select arrangement to add what amounts to one additional address bit, which can only be addressed with a separate, more limited set of instructions. These days, even on PCs, most PCIe memory is mapped into main memory space, but PCI (and thus PCIe) still has the notion of I/O space because it still has to support legacy PC peripherals like the keyboard controller and serial ports that the architecture expect to be at I/O addresses. Instead, like most other computers, all the I/O lives alongside the memory, and you need to make room for a reasonable amount of ROM, so 4MB wound up being the practical limit that you generally see in the Classic and SE, because then you can switch based on just the two high address bits. The RAM chips in the 128K were 16x 4164 (64k x 1 bit) which were relatively new at the time; the Apple II and II+ (effectively the same board) used the older 4116s, which required additional +12v and -5v supplies and tended to die fairly often, while the 4164 only required 5v and was 4x the RAM in the same footprint (reclaiming the two supply pins left room for an additional address pin, which is used for both row and column addresses). The 512K swapped the 4164s for 41256s, which as you might guess are 256k x 1 bit; those used the other bonus pin for another address line. Later boards are dual-purpose with some stuffing options determining whether they're 128K or 512K (a few extra resistors and I think one more address pin multiplexer that's absent from the 128K board for the additional address bit). Later machines used 30-pin SIMMs, which made it a lot easier to pack more memory in a machine (the Max II board I mentioned is jam-packed full of ZIP memory chips, which were rather unpleasant things). With a standard pinout, you can fit up to 16MB on a 30-pin SIMM, but it wouldn't have done much good for a machine with a 24-bit address bus, so the 68000 machines really only supported up to 1MB SIMMs (installed in pairs, because those are 8-bit SIMMs, which is why you never see a single 4MB SIMM on those machines). It wasn't until the II series and cousins (Quadras, LCs, etc) that you started seeing memory buses that were decoupled from the processor buses; the 68000 CPU bus was simple enough you could lash everything to it with some PALs (still more complex than the 6800/6502-style bus of the Apple II, but only just), but the later buses got much faster and more complex, requiring custom ASICs to interface (not to mention the variety of expansion interfaces, particularly NuBus, which also required complex adaptation). - Dave
The IWM was used first on the Mac. The Lisa 1 and Lisa 2/5 have a MOS 6504 running the floppies, complete with its own ROM. On the later 2/10, this was replaced with the IWM. -J On Fri, Jun 25, 2021 at 10:07 PM David Riley via vcf-midatlantic < vcf-midatlantic@lists.vcfed.org> wrote:
On Jun 25, 2021, at 9:01 AM, John Heritage <john.heritage@gmail.com> wrote:
Wow! Good articles and thanks David! Since you mentioned you loved the
original hardware design of the Mac, I hope you won't mind a few more questions..
Interesting on the IWM making it to the Mac, I knew that was a really
innovative chip on the Apple II, but didn't realize it also was used in early Macs.
The IWM was, essentially, an IC version of the Disk II controller (there are a few differences, but that's pretty close). I think it came to the Mac first, since the Apple //e came after the Apple /// tanked, but I could have my timelines mixed up there.
What was the reason the PC used 9 sectors per track while the Mac and Amiga used 10/11 sectors per track each on the 3.5" floppies? (I assume the ST defaulted to 9 sectors per track to stay compatible with DOS disks..) Was it because the PC technically predated the original Mac and Amiga/ST and the early drives/disks were risky with higher densities? Did Apple trade anything off for 400KB floppies in the Mac?
The short answer is that 400/800K floppies used GCR encoding for their low-level format, while 360/720K (and also 1440K) floppies used MFM. They're just two different encoding methods; I don't think one is necessarily superior to another other than the fact that you can pack a little more space into a track with GCR encoding. MFM was the defacto standard on the IBM side for floppies (it's what the original IBM floppy controllers supported), so when Apple added HD capability with the SWIM chip, they went with MFM to be compatible with PCs (thus also gaining compatibility with DD 360/720K disks).
The "ISM" (Integrated Sander Machine, AFAICT, as that part was designed by Wendell Sander) portion of the SWIM was basically a new decoding machine that could handle both MFM and GCR with a lot of the same circuitry and state machines. It's really a brilliant design; you can read the SWIM chip design docs on the Archive somewhere if you're curious. Really neat stuff. Later SWIM chips dropped the IWM portion entirely, if memory serves, because the ISM worked well enough for both modes and didn't require the CPU overhead that the IWM did (mostly owing to the tradeoffs that made the Disk II controller such simple hardware; it's basically a step away from bit-banged).
Hardware wise, is it fair to say that the Mac probably cost less to manufacture in ~ 1985 than say the Amiga 1000 or Atari 520ST? The Amiga had several custom chips, and even the ST seemed to have more ICs on board, though monitors were optional for both. (I think in 1984 RAM was still very expensive so I can see why the 128KB Mac would be high, especially as an early adopter premium). I always assumed the Mac premium was due to it's software library and 'brand' (at least in the US) at the time, but curious if there were any hardware reasons for the cost.
I don't know if I'd say that... what the Amiga and ST cost in custom chips, the Mac probably made up for with rather expensive PALs, though they did at least use the mask-programmed version of them (HALs) once they'd finalized the design, which would have saved a fair amount at those volumes. PALs were off the shelf, which made it much easier to prototype, but in volume, a custom chip can be cheaper. I don't know the relative manufacturing prices, but I'd guess that the Mac cost a bit more to build with the CRT and supporting circuitry.
Of course, there's an article about exactly this, too: https://www.folklore.org/StoryView.py?project=Macintosh&story=Price_Fight.tx...
Last question -- were there 'fast ram' upgrades for the original Macs (say pre-1990) that would allow the 68000 access to local memory for faster execution than RAM on the shared bus? or did all RAM have to be shared? It looks like the ram size limitations on the early Macs were relatively close to what the 68000 could do..
The original Mac was a pretty simple machine; everything lived on the 68000 bus, for the most part (the 68000, as you may know, also had some special circuitry for directly addressing 6800-bus-compatible devices, which I think they used for the VIA and the Z8530 serial chip, possibly some others, but it was all still the same bus with some slightly different control signals). I have a 128K with a Max II upgrade (pass-through board for the CPU socket that expanded RAM to 1MB and added Mac Plus-ish ROMs, we always called it a "Mac Minus" when I was growing up), but as far as I know the most you could really do to speed up the RAM on that system would be to shift the timings like the Classic did.
The original 68K had a 24-bit address bus, so it could address up to 16MB, but not all of that could be RAM because you have to leave room for I/O devices and the ROM. Unlike Intel CPUs, the 68K didn't have the (IMO) silly notion of a separate I/O space, which really just involves a more complex chip select arrangement to add what amounts to one additional address bit, which can only be addressed with a separate, more limited set of instructions. These days, even on PCs, most PCIe memory is mapped into main memory space, but PCI (and thus PCIe) still has the notion of I/O space because it still has to support legacy PC peripherals like the keyboard controller and serial ports that the architecture expect to be at I/O addresses. Instead, like most other computers, all the I/O lives alongside the memory, and you need to make room for a reasonable amount of ROM, so 4MB wound up being the practical limit that you generally see in the Classic and SE, because then you can switch based on just the two high address bits.
The RAM chips in the 128K were 16x 4164 (64k x 1 bit) which were relatively new at the time; the Apple II and II+ (effectively the same board) used the older 4116s, which required additional +12v and -5v supplies and tended to die fairly often, while the 4164 only required 5v and was 4x the RAM in the same footprint (reclaiming the two supply pins left room for an additional address pin, which is used for both row and column addresses). The 512K swapped the 4164s for 41256s, which as you might guess are 256k x 1 bit; those used the other bonus pin for another address line. Later boards are dual-purpose with some stuffing options determining whether they're 128K or 512K (a few extra resistors and I think one more address pin multiplexer that's absent from the 128K board for the additional address bit).
Later machines used 30-pin SIMMs, which made it a lot easier to pack more memory in a machine (the Max II board I mentioned is jam-packed full of ZIP memory chips, which were rather unpleasant things). With a standard pinout, you can fit up to 16MB on a 30-pin SIMM, but it wouldn't have done much good for a machine with a 24-bit address bus, so the 68000 machines really only supported up to 1MB SIMMs (installed in pairs, because those are 8-bit SIMMs, which is why you never see a single 4MB SIMM on those machines).
It wasn't until the II series and cousins (Quadras, LCs, etc) that you started seeing memory buses that were decoupled from the processor buses; the 68000 CPU bus was simple enough you could lash everything to it with some PALs (still more complex than the 6800/6502-style bus of the Apple II, but only just), but the later buses got much faster and more complex, requiring custom ASICs to interface (not to mention the variety of expansion interfaces, particularly NuBus, which also required complex adaptation).
- Dave
-- Jason Perkins 313 355 0085
In any case, any application with high quality audio for the time (here I'm thinking something like Dark Castle, which actually has really great sound effects) probably either just lived with the iffy quality or pre-equalized the audio, but given that Dark Castle sounds pretty
Don't forget that a few guys started making replacement ROMs for a commercial drum machine called DigiDrums I think. They made a tool for editing their data, which they then expanded to a I think a 4 channel sound card for the Mac. They called their company DigiDesign and it allowed users to record multitrack audio at high quality on the Mac And the rest is history..... (DigiDesign = Protools, one of the big digital audio workstation hardware/software platforms.)
participants (9)
-
Andrew Diller -
Bill Degnan -
Christian Liendo -
Dave McGuire -
David Riley -
Dean Notarnicola -
Ethan O'Toole -
Jason Perkins -
John Heritage