Thread
MacTerminal 1.1 MacBinary file transfers
Hi All,
I spent some time yesterday connecting my Mac 512k to my Windows pc via serial cable. I created the appropriate cable and all works fine. I'm using MacTerminal 1.1 on the Mac and I can transfer files between each computer using XModem. But I'm having the dreaded problem that each file I transfer to the Mac is only recognized as a document not executable etc. Is there a way to get MacTerminal 1.1 to receive files as MacBinary?
I know other terminal software such as ZTerm has a Mac binary option, but I can't see anything like that for MacTerminal 1.1.
I spent some time yesterday connecting my Mac 512k to my Windows pc via serial cable. I created the appropriate cable and all works fine. I'm using MacTerminal 1.1 on the Mac and I can transfer files between each computer using XModem. But I'm having the dreaded problem that each file I transfer to the Mac is only recognized as a document not executable etc. Is there a way to get MacTerminal 1.1 to receive files as MacBinary?
I know other terminal software such as ZTerm has a Mac binary option, but I can't see anything like that for MacTerminal 1.1.
can you send them as SIT files? then just drag and stop the file on unstuff?
I've tried transferring all sorts of files .sit, .bin, .sea etc. None are recognized, all end up being identified as "document" once transferred. I'm using system 4.1 on the 512k so you can't drag and drop. Unfortunately I don't have Stuffit on disk for the 512k. All I have in terms of storage on the 512k is the internal 400k drive and an external 400k drive. My plan was to boot the machine from the internal floppy with MacTerminal 1.1 on the disk, then I could transfer up to 400k to the external drive. It would work great if I could just transfer the files without the dreaded resource fork becoming screwed.can you send them as SIT files? then just drag and stop the file on unstuff?
One other thing I have tried is to transfer the files from Basilisk II on the pc. I have Basilisk II running system 7 on the pc and I can transfer files from that but the problem is the same once they hit the 512k. What I could also do is set up an Appletalk network between Basilisk II and the 512k, but I still need to get the Appleshare disk over to the 512k. It's a bit of a catch 22.
ResEdit? My knowledge here is more System 7 and up. But there has to be an app like ResEdit that will run on the Mac 512 so you can just correct the file types. Not ideal and there may be a better solution. But its what came to mind for me.
ResEdit will probably work. Problem is, how does he get it to the 512k?
ResEdit was around pre-System 7, so it should work (don't know if it would run with 512k of RAM, though).
c
ResEdit was around pre-System 7, so it should work (don't know if it would run with 512k of RAM, though).
c
newer versions of stuffit doesnt care about the resource fork. This i know from experience. Older versions do though, and they are a pain to work with.
Thanks to all for the input. I really don't think my initial idea for terminal transfers is going to work. Someone put me onto Finder Info 1.1.1, which does resolve the file resource fork issue, but unfortunately it would only work with archives. If I had a hard drive it would be a great solution. But due to the limited space with only two 400k drives, extracting archives is not going to be ideal. I think the serial solution will still work though, I'm going to look at creating a 400k Appleshare disk. I've already created the disk image on MiniVMac and it seems to work. Once I get this onto a physical disk I should be able to access a file server running on Basilisk, through the serial cable. This should then allow me to copy application files directly to the blank 400k external disk. That's the plan anyway.
throw some plus rom's in there and use 800k drive/floppies and 6.0.8 ?
buy a couple floppy EMU's from BMOW
maybe soon when someone decides to implement the HD20 support in the floppy emu, we will be golden!!!!!!!!???!?!?!?!?
uniserver,
Floppy emu looks great, not sure if they are available currently, last I looked on BMOW site, it said a new batch was coming. Also, I could the rom replacement as I have some Mac Plus roms. But ideally I'd like to keep this machine as early a configuration as possible.
Floppy emu looks great, not sure if they are available currently, last I looked on BMOW site, it said a new batch was coming. Also, I could the rom replacement as I have some Mac Plus roms. But ideally I'd like to keep this machine as early a configuration as possible.
You need to run MacTerminal from inside a Mac emulator, along with some other adjustments. Start with http://mac128.com and you will find a couple of tutorials for using MacTerminal within OS X, which should apply to a PC environment as well ...
You need to encode the files as Binhex first, then transfer them using MacTerminal, then decode them on the Mac 512K.
Use Binhex 4.0 on the Mac 512K for de-coding.
I wrote a Mac OS X app to encode file for Binhex. It's called OldHex, and you can buy it here.
https://itunes.apple.com/us/app/oldhex/id415628440?mt=12
Use Binhex 4.0 on the Mac 512K for de-coding.
I wrote a Mac OS X app to encode file for Binhex. It's called OldHex, and you can buy it here.
https://itunes.apple.com/us/app/oldhex/id415628440?mt=12
I've tried running MacTerminal 1.1 on the PC side using Basilisk II, I thought it may address the file type issue but it didn't. I've seen that tutorial, It doesn't address the problem of the file type being "document" when the files are transferred using MacTerminal 1.1.You need to run MacTerminal from inside a Mac emulator, along with some other adjustments. Start with http://mac128.com and you will find a couple of tutorials for using MacTerminal within OS X, which should apply to a PC environment as well ...
I don't think MacTerminal will do MacBinary or BinHex conversion on-the-fly - it will require a decoder on the Mac. MacBinary and BinHex were both methods devised for the transfer of Mac files (which incorporate a resource fork) via other platforms' file transfer methods such as the serial-line protocols (XMODEM, YMODEM, ZMODEM, Kermit, etc), or FTP. None of those protocols are resource-fork-aware, so MacBinary and BinHex encode the contents of the data fork and resource fork into a single data file that other platforms can store and transfer.
The result is that even if the source machine is a Mac, if you're using a non-Mac protocol (in this case, anything other than AFP) to transfer the file, it arrives on the Mac as a generic data-only file. An application on the Mac would be necessary to decode the file into its source again, with its resource fork (the resource fork contains the file type info). Newer applications, web browsers, etc, will often perform conversion automatically after a file transfer. But I don't believe any application in existence at the time of the 512 would do that.
I'm not sure what to suggest here to get BinHex or similar onto a disk accessible on the 512, unless you have another Mac with a 1.44MB drive accessible to you...
The result is that even if the source machine is a Mac, if you're using a non-Mac protocol (in this case, anything other than AFP) to transfer the file, it arrives on the Mac as a generic data-only file. An application on the Mac would be necessary to decode the file into its source again, with its resource fork (the resource fork contains the file type info). Newer applications, web browsers, etc, will often perform conversion automatically after a file transfer. But I don't believe any application in existence at the time of the 512 would do that.
I'm not sure what to suggest here to get BinHex or similar onto a disk accessible on the 512, unless you have another Mac with a 1.44MB drive accessible to you...
Just an update on this, I've had some success. I revived an old Powerbook 520c that I have, which allowed me to create a 400k disk with the required software for the 512k.
I've come up with the following 400k boot disk:
System 2.0 (50k)
Finder 4.1 (47K)
MacTerminal 1.1 (98k)
BixHex 5 (8k)
- Result is around 188k free on the boot disk.
By booting the 512k with this disk, I can transfer files in BixHex format across the serial link using XModem in MacTerminal. If the files are 188k or less you can transfer them directly to the boot disk, then extract them out with resource fork in tact using BinHex to a blank 400k disk in the external drive. If the files are greater than 188k, MacTerminal allows you to eject the boot disk when receiving a file, so you can write the receive file to a blank disk. This gives you the ability to transfer a full 400k of data. Then with a bit of disk swapping you quit MacTerminal and run BinHex which also allows you to eject the program disk and extract from the data disk to a blank disk in the external drive.
So all in all, this is a complete solution for transferring files downloaded off the net directly from any Windows of Mac computer, to a Mac 512k, without using a bridge machine.
I also thought I would post my notes for wiring the serial cable, see below:
Mac db-9 Male => PC RS232 DB-9 Female - Description
7 => 6 - DSR
4 => 4 - DTR
9 => 3 - TXD
1 => 5 - GND
5 => 2 - RXD
To do some testing, I created a 512k version of MiniVMac using the actual rom from my 512k, that helped to test what versions of software would actually work. I found that many terminal programs are just too big or would not run under system 2.0. Zterm looked great but will not run in anything less that system 6.0. Screen shot of disk from vMac:
[attachment=0]MacTermBinhex.gif[/attachment]
I've come up with the following 400k boot disk:
System 2.0 (50k)
Finder 4.1 (47K)
MacTerminal 1.1 (98k)
BixHex 5 (8k)
- Result is around 188k free on the boot disk.
By booting the 512k with this disk, I can transfer files in BixHex format across the serial link using XModem in MacTerminal. If the files are 188k or less you can transfer them directly to the boot disk, then extract them out with resource fork in tact using BinHex to a blank 400k disk in the external drive. If the files are greater than 188k, MacTerminal allows you to eject the boot disk when receiving a file, so you can write the receive file to a blank disk. This gives you the ability to transfer a full 400k of data. Then with a bit of disk swapping you quit MacTerminal and run BinHex which also allows you to eject the program disk and extract from the data disk to a blank disk in the external drive.
So all in all, this is a complete solution for transferring files downloaded off the net directly from any Windows of Mac computer, to a Mac 512k, without using a bridge machine.
I also thought I would post my notes for wiring the serial cable, see below:
Mac db-9 Male => PC RS232 DB-9 Female - Description
7 => 6 - DSR
4 => 4 - DTR
9 => 3 - TXD
1 => 5 - GND
5 => 2 - RXD
To do some testing, I created a 512k version of MiniVMac using the actual rom from my 512k, that helped to test what versions of software would actually work. I found that many terminal programs are just too big or would not run under system 2.0. Zterm looked great but will not run in anything less that system 6.0. Screen shot of disk from vMac:
[attachment=0]MacTermBinhex.gif[/attachment]
Further to this I've found an even better utility than BixHex 5 to transfer files across the serial link: PackIt 1.0. Packit is only 9k and allows you to archive multiple files at the source. Then at the destination it allows you to open the packit archive by simply removing the filter when opening files. Files are then restored to the destination will resource fork in tact. It doesn't provide compression, but otherwise it's a great utility.
I've done a write up of this process on my website:
http://tkc8800.com/page/File-transfer-from-pc-to-Macintosh-128k512k-via-serial-cable
I've done a write up of this process on my website:
http://tkc8800.com/page/File-transfer-from-pc-to-Macintosh-128k512k-via-serial-cable
haha BixHex
I'm pleased you found a solution that ought to work for your setup. Permit me then, to describe a couple of differences in procedure:
1) I like BinHex 4.0. The reason is that it is more compatible. BinHex files should survive any platform implementation or file transfer method. As long as you use TEXT when you send the file in HyperTerminal/minicom/ZTerm/whatever you're fine. MacBinary does have a slight kerfuffle with MIME types when sending across the internet but most email providers should be already smart about that. Also BinHex has many cross-platform decoders and encoders -- even OS X 10.5+ has it in the command line.
2) CompactPro can create self-extracting archives. I compressed KidPix, which is 200KiB, into a .sea of 60KiB. Adding BinHex 4.0 encoding raised it to 78KiB. I have never used or heard of PackIt before but I suppose it works fine.
3) Your DE9 RS422 to DE9 RS232 setup is interesting, using DSR and DTR over CTS and RTS. Your page omits details of bitrate and handshaking but I did notice that not using hardware handshake (CTS & RTS) was a significant speed detractor.
4) I have yet to even mention RS232 over RJ45. This could make a USB to RS232 adapter obsolete but I think I should conduct more research.
I'm pleased you found a solution that ought to work for your setup. Permit me then, to describe a couple of differences in procedure:
1) I like BinHex 4.0. The reason is that it is more compatible. BinHex files should survive any platform implementation or file transfer method. As long as you use TEXT when you send the file in HyperTerminal/minicom/ZTerm/whatever you're fine. MacBinary does have a slight kerfuffle with MIME types when sending across the internet but most email providers should be already smart about that. Also BinHex has many cross-platform decoders and encoders -- even OS X 10.5+ has it in the command line.
2) CompactPro can create self-extracting archives. I compressed KidPix, which is 200KiB, into a .sea of 60KiB. Adding BinHex 4.0 encoding raised it to 78KiB. I have never used or heard of PackIt before but I suppose it works fine.
3) Your DE9 RS422 to DE9 RS232 setup is interesting, using DSR and DTR over CTS and RTS. Your page omits details of bitrate and handshaking but I did notice that not using hardware handshake (CTS & RTS) was a significant speed detractor.
4) I have yet to even mention RS232 over RJ45. This could make a USB to RS232 adapter obsolete but I think I should conduct more research.
Thanks for the feedback, see my responses below:
1) Yeah, version 4 of BinHex would be fine, it's about the same size and I don't imagine any problems with it. My process for transferring files across to the physical 512k is to first test and prepare the files in Mini vMac, that way I can archive and extract the files using the exact same program, so I haven't had any issue with BinHex 5. But with Packit you don't even need it, because Packit will recognize any file type. Also with MacTerminal 1.1, I found that you cannot receive files at text. Seems pretty ridiculous, but it will only receive files when set to XModem transfers.
2) I did try CompactPro but couldn't find a version that would run on System 2.0. And also it needs to be small. Keep in my that my goal is to work with a system that has two 400k floppy drives as the only storage, so size is important. Check out Packit, there are two versions: v1.0 (9k), and v3 (30k). V3 does compression but it's very slow, so I prefer to use v1.
3) Thanks for the suggestion, while the serial link works fine, it is slow. I run it at 9600 baud and even at that speed it should be faster, so I'll experiment with using CTS and RTS.
4) I wanted to keep things simple with this solution, not only for myself but others wanting to do the same thing. So USB to serial is very easy. Would be interested to hear more about ethernet to serial if that's what you mean.
1) Yeah, version 4 of BinHex would be fine, it's about the same size and I don't imagine any problems with it. My process for transferring files across to the physical 512k is to first test and prepare the files in Mini vMac, that way I can archive and extract the files using the exact same program, so I haven't had any issue with BinHex 5. But with Packit you don't even need it, because Packit will recognize any file type. Also with MacTerminal 1.1, I found that you cannot receive files at text. Seems pretty ridiculous, but it will only receive files when set to XModem transfers.
2) I did try CompactPro but couldn't find a version that would run on System 2.0. And also it needs to be small. Keep in my that my goal is to work with a system that has two 400k floppy drives as the only storage, so size is important. Check out Packit, there are two versions: v1.0 (9k), and v3 (30k). V3 does compression but it's very slow, so I prefer to use v1.
3) Thanks for the suggestion, while the serial link works fine, it is slow. I run it at 9600 baud and even at that speed it should be faster, so I'll experiment with using CTS and RTS.
4) I wanted to keep things simple with this solution, not only for myself but others wanting to do the same thing. So USB to serial is very easy. Would be interested to hear more about ethernet to serial if that's what you mean.
I got Mini vMac to start up MacTerminal 1.1.
It appears that the only flow control it supports is either Software (Xon/Xoff) or none. Software flow control vs hardware isn't something I have tested personally back to back. I do know that if you have an option for hardware flow control (CTS RTS), you should used it.
I would be quite pleased to have a go at fiddling with it on a 512K. It seems that it does have an option to send a file as Text but as my Receive option is greyed out (most likely because I have no active connection), you may be correct about binary files only.
I had located MacBinary II 1.0.1 ...around the web. It only works with System 6 and above. This is why I don't care much for MacBinary archives. BinHex 4.0 just...works and is multi-platform. I found a worthy quote that I'll put in the next (and final) release of the Guide (source is the Handbook of Data Compression):
You should try out MacTerminal 2.2. It's the last version that will run on a 128K and should be just dandy on a 512K. I didn't get a chance to play with it before my LCII went KAPOW. :disapprove:
It appears that the only flow control it supports is either Software (Xon/Xoff) or none. Software flow control vs hardware isn't something I have tested personally back to back. I do know that if you have an option for hardware flow control (CTS RTS), you should used it.
I would be quite pleased to have a go at fiddling with it on a 512K. It seems that it does have an option to send a file as Text but as my Receive option is greyed out (most likely because I have no active connection), you may be correct about binary files only.
I had located MacBinary II 1.0.1 ...around the web. It only works with System 6 and above. This is why I don't care much for MacBinary archives. BinHex 4.0 just...works and is multi-platform. I found a worthy quote that I'll put in the next (and final) release of the Guide (source is the Handbook of Data Compression):
Still, if you say PackIt works well, then I will investigate it, and note its type & creator information for reference alongside the other mini-library of type & creator codes.Before delving into the details of the format, the reader should understand why such a format is used. ASCII is a 7-bit code. Each character is coded as a 7-bit number, which allows for 128 charactes in the ASCII table. The ASCII standard recommends adding an eighth bit as parity to every character for increased reliability. However, the standard does not specify odd or even parity, and many computers simply ignore the extra bit or even set it to 0. As a result, when files are transferred in a computer network, some transfer programs may ignore the eighth bit and transfer just seven bits per character. This isn't so bad when a text file is being transferred but when the file is binary, no bits should be ignored. This is why it is safer to tranfer text files, rather than binary files, over computer networks. The idea of BinHex is to translate any file to a text file.
You should try out MacTerminal 2.2. It's the last version that will run on a 128K and should be just dandy on a 512K. I didn't get a chance to play with it before my LCII went KAPOW. :disapprove:
How about the Macintosh Floppy EMU?
This ought to work on a PC as well, no?
http://www.bigmessowires.com/macintosh-floppy-emu/
This ought to work on a PC as well, no?
http://www.bigmessowires.com/macintosh-floppy-emu/
Just an update on this, I changed the serial cable wiring to use CTS and RTS. This is what I'm using now:
db-9 Male (Mac) => DB-9 Female (PC)
7 => 7 - CTS
6 => 8 - RTS
9 => 3 - TXD
1 => 5 - GND
5 => 2 - RXD
Speed is still not great, I'm getting around 630 bytes a second. But it's more than good enough and it's very reliable, transfers work great.
I've created an updated version of the 400k boot disk, including Packit, see details here:
http://tkc8800.com/page/File-transfer-from-pc-to-Macintosh-128k512k-via-serial-cable
db-9 Male (Mac) => DB-9 Female (PC)
7 => 7 - CTS
6 => 8 - RTS
9 => 3 - TXD
1 => 5 - GND
5 => 2 - RXD
Speed is still not great, I'm getting around 630 bytes a second. But it's more than good enough and it's very reliable, transfers work great.
I've created an updated version of the 400k boot disk, including Packit, see details here:
http://tkc8800.com/page/File-transfer-from-pc-to-Macintosh-128k512k-via-serial-cable
I looked at MacTerminal 1.1 in Mini vMac.
It doesn't support Hardware Handshake. Either none or Xon/Xoff which is software handshake. You could probably try that, I'm not exactly sure on how Xon/Xoff works. But HSK requires CTS/RTS lines, it's not supported by the other machine, so...I'd probably have to pick up a DE-9 (it's not DB-9) RS232 tester and see if the CTS/RTS lines blip the LEDs when I use software handshake.
Try software handshake and compare it to none.
I have MacTerminal 2.2 here and it looks exactly the same. However, instead of just offering XModem and Text file transfer (I will investigate the Text anamoly you found and see if it is "fixed" in MacTerminal 2.2 or 2.3.1), it has MacBinary, XModem Text, MacTerminal 1.1, Text and "Straight XModem".
I also have procured MacTerminal 2.3.1, the last version of 2.x, (2.2 is the last to work on a 128K) and it looks identical to 2.2. (All top out at 19200bps.) MacTerminal 3.0 I have yet to play with on a real machine.
I will hopefully have a chance to play with a 512K in the future so I'll look at the wiring and fiddle with the terminal apps. As always, I will take copious notes and put down my findings in the Serial Data Interlinks section of the Guide. I don't have a MacTerminal subsection there but I hope to get that done.
EDIT: BTW what is your xfer speed set to? Hopefully you do have a more capable terminal on the other end that can show errors/missed data packets/etc like ZTerm can. If you have it set to 19200bps and it works A+ then I guess that's going to be the most you're going to get out of it. (I used 38400bps on the LCII test box because 57600 wasn't so hot.)
It doesn't support Hardware Handshake. Either none or Xon/Xoff which is software handshake. You could probably try that, I'm not exactly sure on how Xon/Xoff works. But HSK requires CTS/RTS lines, it's not supported by the other machine, so...I'd probably have to pick up a DE-9 (it's not DB-9) RS232 tester and see if the CTS/RTS lines blip the LEDs when I use software handshake.
Try software handshake and compare it to none.
I have MacTerminal 2.2 here and it looks exactly the same. However, instead of just offering XModem and Text file transfer (I will investigate the Text anamoly you found and see if it is "fixed" in MacTerminal 2.2 or 2.3.1), it has MacBinary, XModem Text, MacTerminal 1.1, Text and "Straight XModem".
I also have procured MacTerminal 2.3.1, the last version of 2.x, (2.2 is the last to work on a 128K) and it looks identical to 2.2. (All top out at 19200bps.) MacTerminal 3.0 I have yet to play with on a real machine.
I will hopefully have a chance to play with a 512K in the future so I'll look at the wiring and fiddle with the terminal apps. As always, I will take copious notes and put down my findings in the Serial Data Interlinks section of the Guide. I don't have a MacTerminal subsection there but I hope to get that done.
EDIT: BTW what is your xfer speed set to? Hopefully you do have a more capable terminal on the other end that can show errors/missed data packets/etc like ZTerm can. If you have it set to 19200bps and it works A+ then I guess that's going to be the most you're going to get out of it. (I used 38400bps on the LCII test box because 57600 wasn't so hot.)
I've now got both MacTerminal 1.1 and 2.2 on disks. With 1.1 I tried selecting Xon/Xoff, but using TeraTerm on the PC, when I set it to use Xon/Xoff it wouldn't allow me to send files via Xmodem.It doesn't support Hardware Handshake. Either none or Xon/Xoff which is software handshake. You could probably try that, I'm not exactly sure on how Xon/Xoff works. But HSK requires CTS/RTS lines, it's not supported by the other machine, so...I'd probably have to pick up a DE-9 (it's not DB-9) RS232 tester and see if the CTS/RTS lines blip the LEDs when I use software handshake.
Yes, this does look good, although you would need to send the files using MacTerminal at the other end. I'm going to try this with Basilisk II. I'll run MacTerminal in Basilisk II on the pc with serial port connected to the physical Mac 512k, it should work.I have MacTerminal 2.2 here and it looks exactly the same. However, instead of just offering XModem and Text file transfer (I will investigate the Text anamoly you found and see if it is "fixed" in MacTerminal 2.2 or 2.3.1), it has MacBinary, XModem Text, MacTerminal 1.1, Text and "Straight XModem".
I set it to 19200 at both ends, with that I got around 630 bytes/sec. When set to 9600 at both ends I get around 600 bytes/sec.EDIT: BTW what is your xfer speed set to?
All in all, I'm happy with this solution, it's an easy way of getting stuff to the Mac without a bridge machine.