Can anything open MacAddict files that went through Linux into SEFDHD? - Macintosh Garden

This page is a wiki. Please login or create an account to begin editing.

11 posts / 0 new

Login or register to post comments

Last post

2011, March 26 - 1:46am

#1

mmmmna

Offline

Joined: 2009 Dec 23

Can anything open MacAddict files that went through Linux into SEFDHD?

From deep inside the miniVmac Sourceforge site, I found a compiled SEFDHD (or is that a SEHDFD?).

I have a ROM, it boots, etc.

I have lots of BinHexes, several Stuffit Expanders, MacBinaryII+, DeBinHex droptool, and a Stuffit converter; I run Mac OS 7.5.3 Revision 2, and none of the MacAddict files can be converted. Importing into the emulator is a breeze, that is how I got all those utilities into the emulator in the first place.

I mount the MacAddict file as type hfs, I think HFS mode is supposed to allow me to use the CD properly.

Are the MacAddict files particularly miserable to open? Do I need a secret decoder ring? Referring to MacAddict Disc 50, October 2000 (few fat apps, the few are clearly noted). None of the files on the CD end with .SIT, .BIN, .HQX, so maybe I'm only getting one fork?

Note: I'm having trouble with MANY files from MANY locations, including Macintosh Garden files.

Edit: Replaced 'xxx 7' by 'Mac OS 7' - IIGS User

Comments

2011, March 26 - 2:44am

#2

rpangrazio

Offline

Joined: 2009 Aug 27

This may sound a little weird, but do a DD dump of the cd to an image. Then use the image as a disk file in MiniVmac. Then you don't have to worry about any issues with how linux

2011, March 26 - 2:50am

#3

rpangrazio

Offline

Joined: 2009 Aug 27

sorry the last sentence is suppose to read
Then you won't have to worry about any issues with how linux reads/writes an HFS volume.

2011, March 26 - 1:55pm

#4

MCP's picture

MCP

Offline

Joined: 2010 Mar 12

There's not going to be anything of use with a compact mac on a magazine disc from 2000. And their archives probably won't extract on such an old system, either. You would at least need Stuffit Expander 5.5 or later, and for their self-extracting archives you might need an '030 processor or later. If you want to run later software you should try the Basilisk II or SheepShaver emulators.

2011, March 27 - 6:37am

#5

bicostp

Offline

Joined: 2009 Aug 17

If I remember correctly, most of the programs on MacAddict CDs are self-extracting VICE installers. Your desktop PC's OS might not pass the resource fork to Mini vMac (at least not without third party software).

Try using Basilisk II as a middleman to read the CDs and copy their contents to disk images or a floppy. Unfortunately unless you're using a Disc from an issue with a This Old Mac article, there won't be much of anything you can run aside from SimpleText files, BBEdit, and maybe the CD catalog tool.

2013, September 13 - 2:57am

#6

mmmmna

Offline

Joined: 2009 Dec 23

I'll skip the MacAddict stuff until later. I'm only testing those files that are not fat binaries, but my complete issue might not be the CPU level, so that isn't too important. I have since discovered that my problem is in the extraction process, not the execution of the app from the MacAddict discs.

For the rest of the problems, some BinHex files will get into the emulated mac and extract fine, some binhex files get in but do not extract in the emulated Mac Plus (whatever of several error messages). Some Macbinary files get into the emulated mac plus and extract fine, some get in and do not extract properly (corrupt file). I thought BinHex and MacBinary (referring to both original and MacBinary II) were file formats which were intended to convey complete files - all forks were supposed to get transferred that way. Did I miss something?

To be certain, I am even using files from the abandonware section here, and these do not extract correctly for me inside the emulated Mac Plus. Again, these are files which are supposed to be in a format which transfers fine for others. Linux shouldn't be part of the problem if the file is totally binary, am I right?

In any event, I recently picked up a flat panel iMac, running 9 and 10.3.9, so I think I can get this ironed out via that path... I can obtain and extract the files on that platform, and then repackage them in various archive or conversion formats and test the transfer until I figure out why the so called good files are not getting across in Linux.

Thanks for reading!

2013, September 13 - 11:31am

(Reply to #6) #7

MikeTomTom's picture

MikeTomTom

Online

Joined: 2009 Dec 7

MacBinary files. Not all formats (1, II, II+ & III) are compatible with all MacBinary compatible programs. IIRC, bin files created with MacBinary II+ are not compatible with Stuffit Expander, for example. This may have some bearing on why some .bin files you are extracting, work, while others don't. - I guess that you should have all possible MacBinary compatible programs at hand and if MacBinary I & II fail, try with MacBinary II+ or MacBinary III, etc. But even then...

On Mini vMac I have fairly good success unpacking MacBinary I & II files using MacBinary version 1.0.1 by Gregory J. Smith, a MacBinary II application from 1989. Also good is "Stuffit Lite" version 3.6, but MacBinary v1.0.1 has extra features especially for dealing with files DL'd from a *nix platform.

An excerpt from the MacBinary 1.0.1 doc describing its menu-item, "True MacBinary":

True MacBinary is used with the case of catenating the three pieces of a MacBinary file on unix into one text file prior to downloading. With some versions of xbin and macget, the resulting forks on unix are not padded out to the 128 byte blocks that the MacBinary standard specifies. Catenating the three pieces (.info, .data and .rsrc) together will not produce a correctly
formatted MacBinary file. Turning off the True MacBinary setting will handle this case. Otherwise, you should leave the True MacBinary setting on. MacBinary will only create true MacBinary II files, regardless of the True MacBinary setting.

BinHex files. Usually this is a very safe way of transferring Mac files across the universe. Where it can go wrong is if they DL incorrectly. There is a known issue with some web browsers that have a Mozilla based engine; i.e. Firefox, SeaMonkey, etc. where if you click a ".hqx" link to DL, it only DL's part of the file rendering your DL fubar. Its safer to right-click the link to a get a Save As dialog.

Stuffit ".sit" is a very safe format for transferring files via *nix but this format has had so many changes and unfortunately most available ".sit" files here are created using Stuffit 5.5 or newer making them not so suitable for Mini vMac. If you find ".sit" files that were created by version 4 or earlier of Stuffit, these present little problem for Mini vMac (or any actual 68000 hardware).

However, as with MacBinary, if the archive author doesn't include a "ReadMe" of something similar alerting you to whatever version of Stuffit was used to compress the file, you have to take "pot-luck" at extracting a .sit file successfully. Stuffit 5.5 handles most OK in either direction version format-wise with some caveats - Sda to say, getting Stuffit 5.5 to run on Mini vMac (or any 68000 mac) is not an option.

2014, February 9 - 9:12pm

(Reply to #8) #8

mmmmna

Offline

Joined: 2009 Dec 23

MacBinary files. Not all formats (1, II, II+ & III) are compatible with all MacBinary compatible programs. IIRC, bin files created with MacBinary II+ are not compatible with Stuffit Expander, for example. This may have some bearing on why some .bin files you are extracting, work, while others don't. - I guess that you should have all possible MacBinary compatible programs at hand and if MacBinary I & II fail, try with MacBinary II+ or MacBinary III, etc. But even then...

I was about 85% of the way to reaching this exact conclusion.
Along with your statements of the BinHex and SIT formats, I think you have covered all that I have struggled with. About the only added information that I'd want revealed would be that the source files which worked for other folks were definitely part of my issues. I really wanted to start with the same files (archive and extractor) that worked for others, yet most folks went through the steps a long time ago, using a very different path, so I was a bit unique, and caused some of my problems.

I'm now setting up to get stuff out of Mac Plusses, via Appletalk, into an SE/30. From the SE/30, I'll use 1.44 Floppies to take out of the SE/30, and I will place the files into a Flat Panel iMac (I have several USB Floppy drives). I think I could also burn CDRs on the SE/30 via an external SCSI burner, but that seems quite likely to add more issues.

I do see that a major issue was the diversity of the file formats that I started with. After testing any transferred files in the emulated Mac Plus running on the iMac, I will simply convert them to the lowest common archive format for all the systems, likely MacBinary I or BinHex.

From there, I'll burn the files on the iMac to a CDR, then make an image of that CDR using Linux DD, then reverse the DD output back into a second image on Linux, burn the second image on the Linux box and test that second CDR on the iMac.

That should prove to me how to best archive the data for my personal use.

Thanks for reading.

2014, February 12 - 2:54am

(Reply to #10) #9

MikeTomTom's picture

MikeTomTom

Online

Joined: 2009 Dec 7

WRT to archiving classic Macintosh data on HFS CD media, here's what I do. Someone or yourself might care to experiment with this method too.

When running a System Software from SSW 7.0.1 to Mac OS 9.2.2, to create HFS formatted CD .ISO archives by using Disk Copy 6.1.2 or newer:

Create a new folder in the Finder at some location in your hard drive, name it as for your intended CD archive, for example; MacArchive01
Drag the new folder onto an icon or alias of Disk Copy to launch it, if DC is already running drag the folder into DC's window. Or choose "Create Image from Folder" from its "Image" menu (or type "Command + J") then navigate to where the folder is located.
This invokes DC's "Save disk image as:" dialog. Note where it is going to save the image to. The name of the image to create will be highlighted, e.g; "MacArchive01.img".

Change the ".img" suffix to ".iso" so it should now read "MacArchive01.iso".
Click the "Format" pop-up menu and choose "Read/Write" from the list.
Click onto the "Size:" pop-up menu:

(i). Mac OS 8.1 - 9.2.2 only: Choose a file size 10 MB or smaller from the list - For these OS's, it is a 2 step process to create a large HFS image file (Ignore steps (i) to (iii) if you are running Mac OS 8.0 or earlier). When you choose a size 10 MB or less, Disk Copy will create an HFS image. If you choose a size greater than 10 MB, DC will create an HFS+ image. We want an HFS format here only.
(ii). Check Zero data & Mount Image. Click [Save] then, when the image is created & mounts, drag it to the Trash to unmount it. Next choose "Convert Image" from DC's menus (or "Command + K") and navigate to the image file you've just created and choose its filename [OK]. This takes you back to the "Save disk image as:" dialog.
(iii). Re-check that "Format" is Read/Write.

In the "Size" pop-up menu, choose the "663,000 K (CD-ROM 12cm, full)" file size. Check "Mount Image" & "Zero Blocks" and click [Save]. If you've followed the steps (points (i) to (iii)) and are saving to the same location you'll be informed that a file with the same name already exists there. Its safe to overwrite this file.

On the desktop you should now have a Read/Write mounted disk image "MacArchive01". Getting Info on the mounted image it should inform you that it is a CD sized HFS disk. You can now copy files into the mounted image at your leisure, until its full if need be.
You can test the images ".ISO" validity, by unmounting the disk, and getting the "Virtual CD/DVD Utility" to mount it instead of Disk Copy. The Virtual CD/DVD Utility will mount .ISO's as read-only so no harm will come to the file and if it does mount the disk image OK then it is 100% OK to move this .ISO to any platform and burn it to CD or store it for safe keeping.

I find the above useful on classic Mac OS's as I can store ".ISO's" on spare hard drives etc and access them when needed, either by burning them to CD or simply mounting them using the Virtual utility.

2013, September 13 - 4:48am

#10

themacmeister's picture

themacmeister

Offline

Joined: 2009 Oct 26

Flat-panel G4 iMacs are the BOMB!

I have one, and it is going great. A very nice semi-retro gaming machine.

2013, November 28 - 3:24pm

#11

FoxOnTheRun

Offline

Joined: 2013 Sep 12

https://archive.org/details/macaddict_coverdiscs