You are not logged in.

#1 2014-07-17 00:05:53

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

68020 vs 68030

I noticed a thread on 68kmla from uniserver on the Mac IIx and wondering about the performance jump of the 68030 that kind of degenerated into a 68k/ppc/x86 comparison thread.  But there's a lot more going on than just the CPU.

There's 3 primary things about the 68030 that make it faster than the 68020.  I'll go through them and how they apply to Mac systems.
1) larger cache
The cache increase was only 256bytes, IIRC, making it a marginal increase at best.  However, I'm not sure how much the cache size matters on these machines, since the cache will be flushed fairly regularly in normal system use.  The cache will help with tight code running in a loop, like with Photoshop or Excel or other purely computational tasks.  But these machines most likely had to switch between 24bit and 32bit CPU modes fairly regularly, usually for hardware accesses.  A lot of the Mac II and later memory map put hardware into 32bit only regions, while a lot of the older drivers and software remained 24bit.  For instance, anything using resources would switch to 24bit for resource manager accesses, while anything accessing peripherals would switch to 32bit.  Each switch caused a cache flush, emptying the cache.

2) memory burst mode
Normal 68k memory accesses require 4 clock cycles to access memory.  So if the bus is 32bits wide, a 68k machine can load 32bits of memory in 4 clock cycles (similarly for 16bit busses, it takes 4 clock cycles to load 16bits).  If the memory resides in cache, the access is twice as fast, accessing it in 2 cycles.  Burst mode lets the CPU load an entire cache line (4x32bits) in a "burst".  Essentially you load the first 32bit quantity normally, and then the memory controller keeps sending the 3 other 32bit quantities without the CPU needing to request them, each 32bit quantity only costing 2 cycles to load.  Burst mode requires support from the memory controller to actually work, and the first 030 machines were still using 020 memory controllers.  The IIx and SE/30 used the GLU from the Mac II for their memory controller.  It wasn't until the IIfx and IIci that the memory controllers supported burst mode.  So the initial 68030 macs didn't support burst mode, and don't benefit from this feature of the 68030.

3) synchronous bus access
I'm not sure 68k macs supported this access mode.  For sure the initial 68030 machines didn't.

So, the first 68030 machines didn't benefit much performance wise from the 68030 over the 68020.  But, there's still a good reason for the 030 move: cost.  Macs had moved to 32bits, but still supported 24bits.  This required an MMU to be able to switch between the two.  But the 68020 didn't have an MMU.  The Mac II and LC shipped with an HMMU (although the 68851 was available for the Mac II, required by A/UX).  The HMMU was a chip made by apple that was enough of an MMU to allow switching between 24 and 32bit address spaces, but not a full 68851.  It saved cost and power over the 68851, but the boards space and fabbing a custom chip still adds nontrivial cost to the system.  The 68030, while more expensive, included an on die MMU, resulting in an overall cost savings over the 68020 + HMMU, as well as freeing up board space.

It's also hardly surprising that the first rev is a hybrid adoption, incremental progress is typically how progress is made.  It required a redesign of the memory controller (along with software changes) to take full advantage of the 68030, and the memory controller in macs is typically not standalone.  The MDU in the IIci also includes the RBV video.  Same with the VISA memory controller in the LC, incorporating the video controller into the design.

Offline

#2 2014-07-17 01:19:16

Mk.558
Member
Registered: 2014-07-08
Posts: 160

Re: 68020 vs 68030

The difference between an '020 and a '030 is noticeable to me, but not the same as between an '030 and a 603e.

While we're on the subject of speed, what difference exists between the 128K - through the SE (and probably Classic I, perhaps II) concerning the CPU overhead with respect to the screen drawing? I was told that half the CPU is spent on the 128K and 512K for redrawing the display but only 3/4 for the SE.


SE/30 Cap Replacement http://tinyurl.com/mjf24zs
Classic Mac Networking v3.1 http://applefool.com/se30/
"Linux assumes you know exactly what you are doing." -oboedad55, ubuntuforums.org

Offline

#3 2014-07-17 01:48:13

thatguy
Member
From: South Korea
Registered: 2014-07-15
Posts: 5

Re: 68020 vs 68030

Can't help it. It made me think of this. smile

eleven.gif

Offline

#4 2014-07-17 03:23:55

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

i am also curious about that MK.558.
if i had time like i use to, i could do some benchmarks smile

Good explanation bbraun!


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#5 2014-07-17 05:23:19

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: 68020 vs 68030

For the 128k/512k/Plus machines vs SE it isn't so much a matter of CPU as much as bus cycles.
The display is 512x384 and refreshes at ~60Hz.  The "video memory" lives in system RAM, so in order to update the screen, the contents of RAM must be read, which takes bus cycles. 
On the Plus and earlier machines, the PAL (memory controller of sorts) initiates the accesses to the video buffer in RAM.  As the beam scans out a horizontal line on the screen, the PAL will read 1 word (16bits, the size of the bus) every other memory access.  When it reaches the end of the line, it will then do a single read of sound data.  The time it takes for the beam to reset for the next line (horizontal blanking) is several memory access cycles long, so it can read the sound data, and release the bus to the CPU during this time.  Similarly, during the vertical blanking interval, the bus is released to the CPU as well.  Keep in mind that a memory access on 68k machines is 4 clock cycles.  So, half the bus cycles are used by video in the Plus and earlier machines.  Since the Plus is clocked at 7.83MHz, the bus is 16bits wide, and each access takes 4 clock cycles, you'd expect an overall bus throughput of about 3.92MB/s.  If the Plus really had to give up half the bus time to video access, that'd mean the CPU could only pull about 1.96MB/s.  But the horizontal and vertical blanking intervals give enough time so the Plus can realistically pull about 2.56MB/s.  Which isn't quite as bad you'd think.

The SE does the same thing, but reads 2 words (32bits) at a time, so only does it once out of every 4 CPU accesses.  I believe it has further optimizations, since the video accesses are all linear, it can do something similar to the 68030 burst access, and rather than needing to address each of those words individually, it only needs to address the first one, and clock the next word out onto the bus.  I believe the SE reads those two words in 5 clock cycles instead of 8, using this mechanism.  As a result, factoring in the horizontal and vertical blanking intervals, the SE gets about 3.22MB/s memory bandwidth, which is getting pretty close to the theoretical maximum of 3.92MB/s.

The CPU isn't involved with any of this, the PAL in the Plus and the BBU in the SE takes control of the bus and generates the video memory addresses.  So this doesn't necessarily result in the processor being idle while the screen is updating, since 68000 instructions can take a dozen clock cycles to execute.  The CPU can be busy processing the data it just got, while the screen is being updated.

Offline

#6 2014-07-17 07:32:28

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

Soo the Macintosh Portable, with its VRAM and the SE/30 with its VRAM. Do in-fact help the performance of the machines greatly!?
- that does make the Mac Portable quite a bit better then a Suped up Mac SE?

Because the Macintosh Classic, Still has a PAL... that means they REALLY Cheapened that bad boy up!

And even a comparason between a LC-II and the Mac Classic II is not right because at least the LC-II had its own VRAM.

Looks like the LC-I even has vram.

Now the question is, what were they smoking when they made the IIsi?

no vram on the IIci,  but the se/30 has vram.

i know, i need to be careful and pay close attention to the time line...

Last edited by uniserver (2014-07-17 07:47:12)


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#7 2014-07-17 07:35:45

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

that tells me with the IIci and the IIsi they might of been banking on you buying a video card.


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#8 2014-07-17 09:56:54

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

John brought up a good point.

http://jwvideo.free.fr/ImagesMac/MacII/ … e_2200.jpg
MacIIVx_Mere_2200.jpg

its got it all... Vram / Ram / CPU Cache, all on the board!

so this thing kind of reminds me of a LC-II on ROIDS smile

if you look at the PCB...
http://en.wikipedia.org/wiki/Macintosh_IIvx

- so this thing runs at 32mhz.
- 4 MB, expandable to 68 MB (80 ns 30-pin SIMM) - kinda make me think, that capability is like an "admission of guilt" for the 10mb limitation with the LC-II!!!
- its slightly slower then the IIci - is this with or with out the IIci cache card installed?  i dunnno.
- it does have 32k L2 CPU Cache on the main board! Witch in order to achieve this you needed to buy a card with the IIci.
- 32 MHz processor was crippled by a 16 MHz bus - reminds me of the LC-II.  Yuk!

- serial port was limited to 57.6 kbit/s  - wonder why?

- a slower version of the IIvx with a 16MHz processor, man that would have been a real poor value.

- For a while afterwards, people who bought an expensive Mac that quickly became outdated were said to have been "IIvx-ed"
OOOooo that is harsh!! haha.

Last edited by uniserver (2014-07-17 10:02:52)


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#9 2014-07-17 10:09:20

volvo242gt
Member
From: Duvall, WA
Registered: 2014-05-22
Posts: 406
Website

Re: 68020 vs 68030

It also has the ability to install a ROM SIMM slot, which might be of interest.  See if it'll boot off a IIsi ROM...  :-P

-J


modern: Mac Pro 2.8GHz 8-core 6GB/500G/DVD-RW, A1150 MBP 2GHz CD, 2GB/80G/DVD-RW
Pre-Mac: ][+, //e
other: iPhone 6s 128GB Space Gray

Offline

#10 2014-07-17 10:33:14

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

oh man...  haha!  You bet!

I wonder if the 16 bit bus limitations go away with this installed?
http://lowendmac.com/1993/daystar-turbo … r-upgrade/
daystar-040-turbo-iici.jpg

Last edited by uniserver (2014-07-17 10:44:02)


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#11 2014-07-17 15:55:34

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: 68020 vs 68030

Kinda jumping all over the place here, but trying to keep up:
Portable: it's twice the clock of the Plus/SE, and the processor doesn't have to share access to RAM.

Classic: Information on the Classic is a little more difficult to come by, I suspect because "who cares?".  But benchmarks show it has more memory bandwidth than the SE.  PAL is short for "Programmable Array Logic", which really just means they took a bunch of discrete logic chips and put them into a single chip.  The PAL in the Classic isn't the same thing as what's in the Plus.  For the memory access, I mentioned earlier that the CPU isn't always hammering on the bus, a memory access takes 4 cycles, and instruction execution can take a dozen or so (depending on the instruction).  Some systems, such as the atari ST machines I believe, arranged their video access to happen while the CPU wasn't using the bus, which dramatically cuts down on the contention.  I can't find specific information on the Classic to say that's what they did here, but it would explain the better memory performance of the Classic vs. the SE.

IIci/IIsi: these machines use the MDU memory controller, which includes the RBV video controller.  So the cost of onboard video controller of these machines seems to be very low, compared to a separate controller.  The II/IIx/IIfx didn't have onboard video at all and you had to use a nubus card.  So you can kind of think of the RBV as a "free" video controller.
But the MDU on these machines was pretty neat for the time.  The normal formula for memory bandwidth on 68k macs up to that point was clockspeed * bus width / 4 clock cycles per memory access.  So on the IIx, a theoretical maximum memory bandwidth was 15.67 MHz * 32bit bus / 4 = 15.67MB/s.  So the expected throughput of the IIci would be 25 MHz * 32bit bus / 4 = 25MB/s.  But remember the MDU introduced support for burst mode access, which reads the first 32bits at 4 clock cycles, but then fills the rest of the cache line at 2 cycles per 32bits.  This gives the IIci a memory throughput of 36.36MB/s.  That seems like a pretty impressive number considering the previous generation, but it needs to be tempered by the fact that the burst mode is going to cache, so if you're not actually using each of the 4 32bit quantities you're reading, it doesn't actually help you.  And if you flush cache, it's all gone.  And keep in mind what I said about 24/32bit mode switches causing a cache flush.  It's still pretty impressive though.

IIvx/P600: Everyone loves to hate these machines, and for good reason.  The 16bit bus is a killer.  The reason the cache on the IIvx was such a big deal is it helps to not have to go over the 16bit bus as much.  The P600 not only didn't have a cache, the PDS slot didn't have the cache management lines available, so you couldn't add a cache.  The P600 logic board PCB is the same as the IIvx's with the cache unpopulated.  So you might be able to add the cache by just soldering it on.
Anyway, these machines are technical curiosities to me, being an abandoned fork in the Mac product line.  These are the only 68030 machines with a 1MB ROM (The 040's all have 1MB ROMs except the AV macs which have 2MB), and later ROMs will not work on these machines.  I tested the P600 at one point, and ISTR >1MB of ROM is not available on these.  I say it's an abandoned fork because no later ROMs have any knowledge of the IIvx/P600, and won't work on them.
Adding an accelerator doesn't avoid the 16bit bus.  The accelerator still needs to talk to RAM and all the onboard peripherals, and the bus is 16bits.  Accelerators with their own CPU can have their own onboard cache, and the more cache, the less it will have to go over the 16bit bus to access RAM (hopefully anyway).
As for comparisons against the IIci, it's all about the configuration and benchmark.  Any time the IIvx has to go over its 16bit bus, it's going to be slower than the IIci.  But if it can execute entirely of cache, for example on pure calculations, the 32MHz clock is in its favor.

Offline

#12 2014-07-17 16:56:52

jt
Member
From: Bermuda Triangle, NC USA
Registered: 2014-05-21
Posts: 1,407

Re: 68020 vs 68030

uniserver wrote:

I wonder if the 16 bit bus limitations go away with this installed?

Nope, the accelerator is still forced to access System Memory through that unconscionable 16bit bottleneck, such a config would be a waste of a good accelerator.

As for the IIci, it was the HighEndMac of its time, but a branch of the slot starved IIx form factor. The cache helped to make up for the Vampire Video in the IIci, with more memory available, so it wasn't nearly as nasty a hindrance to performance as in the IIsi.

Historically, the IIci was the DTP workstation of choice for a very long production run. A NuBus VidCard and TPD was almost a given, often in grayscale with the Vampire Video reserved for the beautiful 13" RGB(?) sitting on top for color preview duty and off to the side. That made it the free VidCard bbraun mentioned with the TPD sitting directly in front of the designer with the NuBus card driving it handling the vast majority of the screen redraw load in that role.

The mid-range IIsi was intentionally hobbled every which way so as not to be a competitor of the IIci and IIfx for pro level DTP. Vampire Video limited Portrait resolution, the only really useful config available on the RAM starved IIsi, to half the bit depth available on the display as well, IIRC.

Apple tweaked total system performance tradeoffs across the line very carefully for maximization of product lineup profit. What was the timeframe for the IIvx/IIvi rollout scheduling? I wouldn't be surprised at all if the shift coincided neatly with discontinuation of the cash cow production run of the DTP oriented IIci and the imminent rollout of the Quadra generation with malintent or good business sense, depending upon observation across the fence.

Offline

#13 2014-07-17 19:13:33

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

ok so the VX has a 16 bit bus, i still can't figure out why.   

i think its because the Iici used that RBV,

its TO ME the VX has roots that come more from the LC-II then the Iici.

i mean it probably just came down to cost.   but this same kind of HOKEY thinking was used with the PowerMac 5260 P O S!

thanks for all the info!!  Really great bbraun and jt!

So looks like a IIsi rom is not going to work with this beast...

also i use to have hate for the powermac6100 until i realized that CPU would run at 80/90 mhz with out too much problems.
witch overcome what ever the reasons why i decided to hate it in the first place... oh yeah... because it was slow.
and its cool the PM6100 will allow (2) 128 meg simms. 

For some reason the VX still has my interest for the moment...  John had a good question... can i take some parts from the VX and put them on the Iici to make the Iici run at 32 mhz?   i do not have an answer for that one.  i do know how ever from the LC-III experimentation. that the 25mhz cpu will run at 32/33 mhz with no issue. so i wouldn't have to like desolder solder CPU's.  smile

Last edited by uniserver (2014-07-17 19:15:20)


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#14 2014-07-17 19:28:13

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: 68020 vs 68030

The IIvx is 32MHz on a 16bit bus, and the nearly identical IIvi is 16MHz on a 32bit bus.  Folklore has it, the IIvx was supposed to have a 32bit bus at 32MHz, but the schedule was shortened, and couldn't make it work in the time allotted so here we are.

Offline

#15 2014-07-17 19:32:44

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

Yeah i hear ya.   i guess after the fact, it is, what it is smile  haha
they rushed the thing... were not able to make it how intended... and threw that cache band-aid over it hopping it would make it better...
OR?  where they going to do the cache anyways... and then the cache with the 32bit bus would have been FANTASTIC!

but wuda shudda cudda...


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#16 2014-07-17 19:33:53

uniserver
Member
From: Sf, Mi
Registered: 2014-05-15
Posts: 956
Website

Re: 68020 vs 68030

sayings like method to the madness come into play.


#I Re-Cap √Mac √NeTX √Amiga Boards - A/B - PSU# (MacCaps.com)  Modern SCSI HD's - For Old Macs - Pre Cfg'd - 10k RPM! 73gb!! $50 + free shipping  -- Mac 128K Re-Ram kits (16 Chips) $35 + shipping, Floppy Issues?-> Bourns Filter Solution 128k - SE/30, $16 + shipping

Offline

#17 2014-07-17 21:56:33

Mk.558
Member
Registered: 2014-07-08
Posts: 160

Re: 68020 vs 68030

Thanks for the explanation on the PAL control of the video driving process. Basically the short story is that the PAL takes away memory access from the CPU for a short time to push video data from RAM to the the video circuitry? But it's not as big of a hit as it can be made out to be then, as you say.

I've stuck the Rocket 33 in a IIci and to be honest it wasn't that much of a difference as I expected. It's slightly faster, but part of that could be influenced by the Placebo Effect: I know it's got a 040 clocked higher so that means it has to be faster. The main reason I don't think much of the 040s is that there was no System 6 for them. As a point of comparison, I was testing the maximum speed of a RAM disk to HDD copy (and back again), plus a 10/100 NuBUS card from iMac G4 -> IIci's RAM disk. System 6 was nearly double the data rate of System 7.0.1 with the Rocket active. Okay yes by the time the 040s came out System 6 was on its last legs but it still rocks on floppies. (It's why I don't think much of the Quadra 700, as well. I'd rather have an accelerated IIci instead.)


SE/30 Cap Replacement http://tinyurl.com/mjf24zs
Classic Mac Networking v3.1 http://applefool.com/se30/
"Linux assumes you know exactly what you are doing." -oboedad55, ubuntuforums.org

Offline

#18 2014-07-17 22:38:05

bbraun
Member
Registered: 2014-05-29
Posts: 1,064
Website

Re: 68020 vs 68030

Yeah, that's pretty much right for the video accesses of the Plus & SE.

I'm not entirely sure what the technical differences are between the System 6 and System 7 finder copies are.  My suspicion is lots different.  Probably different block sizes, different RAM cache size, and most significantly, System 7 verifies the data it wrote.  There's several 3rd party extensions that speed up the Finder copy in System 7, presumably by messing with all those things.

FWIW, a file copy probably won't show that significant a difference with a CPU accelerator.  In fact, a Rocket could have worse file copy throughput than an unaccelerated system, if it accesses anything off the Rocket its self.  The Rocket being on Nubus is worse than the 16bit data bus limitation of the IIvx.  Nubus has a theoretical maximum of 10MB/s, although due to latencies, in practice it is much slower than that.  But let's assume 10MB/s just for the sake of discussion.  Remember that even the Portable's system bus is 15.67MB/s, and that's actual throughput.  The IIci can burst as high as 36MB/s.

I think the biggest win of the 040 over the 030 is the pipelining and CPU cache.  Like I was saying above, the processor can leave the system bus idle while it executes an instruction, which can take a dozen or so clock cycles.  Among other things, pipelining can allow the next instruction to fetch what it needs from the bus while the current instruction is still processing.  It allows more efficient utilization of resources, instead of letting parts of the system sit idle while the CPU chugs along, lots of stuff can be going on at the same time.  You'll see this more with code execution than IO activities.

Offline

#19 2014-07-17 23:22:41

Mk.558
Member
Registered: 2014-07-08
Posts: 160

Re: 68020 vs 68030

Oh I don't doubt that the '040 is a better processor. But it does make you wonder sometimes.

If I can get the Rocket going under System 6 I'll know for sure.

Here's my notes concerning the file transfers:

- IIci, 7.1 with AS4 installed but off, AsanteFast 10/100 Nubus, Radius Rocket 33MHz with 20Mib ram in accelerator mode, 8mib on mobo, 50mib hard drive to imac g4, 9.2.2. ram disk to ram disk network copy: 
	> download 9mb file from imac g4 to IIci: 0:27.7  ====== 7.0.1 3.1mb file download from imac to ram disk 0:15.3 NO ROCKET
	> upload 9mb file from iici to imac g4: 0:35.9 ======= Also no rocket upload 3.1mb file to imac from ram disk 0:18.6
	
	1.) 332.7KiB/sec, 2.66Mbps  ----- 207.5KiB/sec, 1.66Mbps
	2.) 256.7KiB/sec, 2.05Mbps ----- 170.7Kib/sec, 1.37Mbps
	
-- IIci as before with rocket, but scsi HDD to ram disk: 
	> copy 9mb file from hdd to ram disk: 0:20.9 ---- 7.0.1 No ROCKET copy 3.1mb file from ramdisk to HDD: 0:22.5
	> copy 9mb file from ram disk to hdd: 0:29.9 ----- 7.0.1 NO ROCKET copy 3.1mb file from hdd to ram disk: 0:10.8
	
	1.) 441.0KiB/sec, 3.53Mbps ----- 141.1KiB/sec, 1.13Mbps
	2.) 308.2KiB/sec, 2.47Mbps ----- 293.9KiB/sec, 2.35Mbps
	
-- iici, system 608, multifinder off, asantefast 10/100 nubus, 8mb ram, ram disk to imac g4, 9.2.2's ram disk:
	> download 4.9mb file from imac g4 to IIci's ram disk: 0:07.9s  635.1KiB/sec, 5.08Mbps
	> upload 4.9mb file from iici to imac g4's ram disk: 0:12.5s   401.4KiB/sec, 3.21Mbps
	
-- iici, system 608, multifinder off, ramdisk to scsi hdd:
	> copy 4.9mb file from ram disk to hdd: 0:16.4    306.0KiB/sec, 2.45Mbps
	> copy 4.9mb file from hdd to ramdisk: 0:07.9s    635.1KiB/sec, 5.08Mbps

SE/30 Cap Replacement http://tinyurl.com/mjf24zs
Classic Mac Networking v3.1 http://applefool.com/se30/
"Linux assumes you know exactly what you are doing." -oboedad55, ubuntuforums.org

Offline

#20 2014-07-18 23:08:44

jt
Member
From: Bermuda Triangle, NC USA
Registered: 2014-05-21
Posts: 1,407

Re: 68020 vs 68030

bbraun wrote:

FWIW, a file copy probably won't show that significant a difference with a CPU accelerator.  In fact, a Rocket could have worse file copy throughput than an unaccelerated system, if it accesses anything off the Rocket its self.  The Rocket being on Nubus is worse than the 16bit data bus limitation of the IIvx.  Nubus has a theoretical maximum of 10MB/s, although due to latencies, in practice it is much slower than that.  But let's assume 10MB/s just for the sake of discussion.  Remember that even the Portable's system bus is 15.67MB/s, and that's actual throughput.  The IIci can burst as high as 36MB/s.

I don't follow you there. What kind of file copy are you talking about? If it has anything to do with I/O and SCSI it's a moot point I would think. NuBus (rev 1, not even NuBus 90) at its very worst saturated Mac MoBo SCSI implementations right up through the vaunted 840AV at 5MB/sec. For I/O, the Rocket was designed to use a fast SCSI-2 chipset on that same 33MHz clock, Mac MoBos didn't match capability until the PPC x500 and x600 generations.

The Rocket can have as much RAM installed on it as the IIci MoBo and none of it is buffered for that idiotic Vampire Video setup, so it can be fully interleaved and runs on the Rocket's 33MHz System Bus.

Benchmarking: it's all in the optimization/bias for the benchmarked operations.

@MK.558: I'm very surprised you didn't see much overall performance increase when you used the Rocket in your IIci. What software were you running and what were you doing? I can tell you right off that your 20MB RAM complement has interleaving bollixed, you'd be far better off with the full 32MB, likely even with only 8MB on board in interleaved mode for some more memory intensive/bottleneck sensitive operations.

As for the 68040: the lowly 68LC040 in the Quadra 605 edged out the IIfx in floating point operations IIRC.

At least that's how I understand the system tradeoffs involved. hmm

Offline

#21 2014-07-19 00:37:59

Mk.558
Member
Registered: 2014-07-08
Posts: 160

Re: 68020 vs 68030

I was doing just random things, mostly concerning the Guide. Mostly disk I/O rather than CPU crunching.

I suppose one way of easy benchmarking is BinHex 4.0. The thing is slow to encode even on my iMac G4 800MHz machines. Stuffit does it under a second for a 1.44MB image.

I have yet to push the Rocket hard, that'll come when I do the Rocket writeup, if I can. Principally I'm a little worried about the poor CPU on there -- it gets quite hot even when it's not even active. Apparently they must have a lot of confidence in it, but drew the line with the Stage II. I won't put a heatsink on it because I won't be loading it down that much after the writeup.

The Stage II I consider a waste of time. As olepigeon demonstrated on 68kmla, three Rockets on one system is unstable, two maximum. A Stage II is only worthwhile in a IIx (why?) or a IIfx (better). Even then, consider: 1 NuBUS slot gone for video, another gone for an Ethernet card, another gone for a SCSI card, so now you've got only three left. So you might say Okay put two Rockets in and then some fancy-smanchy card like the 5.25" card. Now that's a machine in itself - but for a IIci, a single Rocket is plenty.

If you're looking for an accelerator alone, the Rocket is a waste of a NuBUS slot on a IIci/IIcx. Better would be to use up that PDS slot, I think.


SE/30 Cap Replacement http://tinyurl.com/mjf24zs
Classic Mac Networking v3.1 http://applefool.com/se30/
"Linux assumes you know exactly what you are doing." -oboedad55, ubuntuforums.org

Offline

#22 2014-07-19 04:25:57

jt
Member
From: Bermuda Triangle, NC USA
Registered: 2014-05-21
Posts: 1,407

Re: 68020 vs 68030

If you have a Rocket 33, it's supposed to have a very nice heat sink on top of the CPU already.

IIcx hasn't got a cache slot and it's only 16MHz, so a Rocket would be well worth the slot. The IIci is fairly quick with its 25MHz bus for RAM access by an Accelerator in the Cache Slot.

Ethernet wasn't really a necessity over the lifetime of the IIci, unless you were on a saturated PhoneNet setup. By the time it was really necessary, Apple had already started putting it on the MoBo of high end systems along with the VRAM the IIci really ought to have had from the beginning. No matter what, you still needed to have a NuBus VidCard, Apple never did put enough VRAM in a NuBus Architecture Mac to do more than about 16" resolution at 24bit, if that.

You'd think they wold have learned by the time the X100 PPC generation was hosed by the piddling 2MB they put on what was supposedly a HIGH Performance Video frame buffer card. Three was the bare minimum for any 2-D VidCard/TPD combo for DTP Pros back in the day  .  .  .

.  .  .  with 4(MB) you get eggroll! (1600x1200@24bit) smile


I was in love with the Rocket because most of the things I needed to do were CPU and FPU intensive back in the day. The Polyline Vectorizer tool for artwork ate FPU cycles like mad. The Rocket helped a lot for screen redraws when I was tweaking Bezier control points to hand digitize Postscript Artwork in Fontographer. Later on I had Illustrator and Freehand when I needed truly scalable files. Adobe's Streamline wasn't all that useful in its first couple of revs and by the time they rolled it into AI altogether it still wasn't good enough to autotrace logos for scaling to the sizes I often needed.

The Rocket's more like a RIP in a NuBus slot, so for my work it was a fabulous accelerator. wink

Offline

Board footer

About ThinkClassic

ThinkClassic specialises in the maintenance, repair, restoration and modification of Vintage Apple and Macintosh computers. Ask questions and find answers about classic Apple desktops, laptops, accessories and peripherals.