Last Minute Changes

My menu and window drawing problems turned out to be a bug that was only revealing itself on the virtual Mini vMac Macintosh 128k. I'm not sure what it was, but it disappeared when I spent some time cleaning up the Mac specific code last night. So, the menus and dialogs all work. I need to do some final testing tonight and I will get a download available!

Fighting with MPW

I spent Saturday trying to get lwip to load on a virtual 128K with 64K ROMs. I think I managed it by building a program with no user interface or feedback at all. I can't test it though because Mini vMac doesn't link to a real serial port or tty. Anyway, with a limited user interface on the 128K, I can run PPP and ICMP (eg: ping), but not TCP. I set it up so it will load as much as it can, then provide an error if it cant load the next module/protocol (rather than a hard crash).
I spent the rest of the weekend trying to get a simple interface programmed for the application. Unfortunately, MPW versions 3.0 to 3.5 do not seem to be able to generate menubar or window resources that a Macintosh with 68K ROMs can use. The menus are there, but they just show up as white blocks (see screen shot above). I don't think I can figure out a solution in time, but at least command-q actually quits the application now. Good enough.
Mini vMac has been great for testing just to make sure the program basically works. I will spend the last few days testing on my real Macs and getting a download together with all of the required licensing info for PPP and lwip.

Happy Birthday Macintosh!

30 years old and still no TCP/IP. I think I am getting close, but there is a lot of code to trace through to make sure I segment everything properly and load everything in the right order to keep the memory footprint low, and avoid segmentation of the memory. I have reserved a few hours this weekend to work on this, so hopefully I will make some progress.

Too Big!

Uh, oh. I wanted to make sure my lwIP application would work on a real 128K Macintosh (I discovered mine was upgraded to 512K), and none of my old Macs have just 128K RAM. So, I recompiled Mini vMac to be a 128K Macintosh, rather than the default Macintosh Plus. After it starts PPP, it gives a system error ID=15. This is a segment loader error, which probably means it is out of RAM trying to load the lwIP core.
In better news, I eliminated most of the debug messages so I don't have to hit the enter key so many times to dismiss the debug dialog boxes.

Success and Video Update

Got it! Hitting the enter key rather than clicking the mouse on the dialog boxes makes the connection. That's either a timing or mouse port serial interrupt issue. Oddly, the return key doesn't do anything. I have TCP/IP networking on my original (modified) Macintosh! I think the memory use is low enough, it should work on a real 128K Macintosh. Is it pronounced "El whip" or "l.w. I.P."? I like the Mexican flair of El Whip! (Actually, it's pronounced "lightweight IP" - boring…)

Old System Success, and Old Hardware Fail

My lwip application seems to run fine on System 2.0 and Finder 1.1g on the Macintosh SE. That's great because that is probably about the maximum system version that the Mac 128K can run. Unfortunately, the Mac 128K gives the above error when opening the serial port.

Pre-System 7 software from MPW 3.5

lwip PPP IP address in System 6.0.8

I spent way too long the last couple of nights trying to get MPW to build an application that could be run on pre-System 7 (even System 6.0.8). I tried using MPW 3.1 (System 6 only) and MPW 3.5 (System 7.1 - Mac OS 9) in different ways to get it to work. Here were all of my attempts and results:

Detour - RetroChallenge 2014SC ?

I saw this Apple II prototyping card on ebay tonight and HAD to buy two. These haven't been available for a while. I resorted to buying an IBM XT prototype card in the past which is bigger but has the same trace spacing on the slot connector. I have never gotten around to actually making an Apple II card though. This looks perfect for some future project.

MakeFile Overhaul

Tonight, I investigated how to fix the issue of the Main code segment being too large for a normal build/link without using --model far which may be causing compatibility problems. There is a #pragma segment segname directive that I thought could work to break up the segments. However, every function needs a directive before it to put it in a segment! That would require way too many code edits. After some research, I found out that MPW's compiler will also take a -seg segname option to assign the object code to the specified segment name. This is the way to specify a segment for an entire source file.
After reading a bit of Building and Managing Programs in MPW, I realized my Makefile is not using any of the complex features available in MPW. So, I incorporated some path constants and Directory Based Dependency Rules, and eliminated a lot of the hard-coded paths and dependencies in my make file.
I figured out that the key to using Directory Based Dependency Rules and code segments in the Makefile is to add a modified extension to the list of object files you want to put in a separate code segment. Then, add a new default build rule for that extension. Code segments are way easy now! I can now remove the --model far option which seems like it might be incompatible with older Macintosh System versions. The main segment with the PPP interface comes in about 31K and the rest of lwip is just 28K, each fitting nicely in a code segment.
Here is an example section of an MPW Makefile (new extension in yellow and segment name option in blue): ObjFiles-68K = "{SrcDir}ip_frag.c.o" ∂ "{NetISrc}etharp.c.n.o" ### Default Rules ### {NetISrc} ƒ {NetISrc} {PPPISrc} {SrcDir} ƒ {CoreSrc} {IPV4Src} {APISrc} .c.o ƒ .c {•MondoBuild•} {C} {depDir}{default}.c -o {targDir}{default}.c.o {COptions} .c.n.o ƒ .c {•MondoBuild•} {C} {depDir}{default}.c -o {targDir}{default}.c.n.o {COptions} -seg NetIf

TELNET Echo, Echo, Echo, Echo!

Motorola 68000 uses 32 bit addressing. Don't forget it!

Fixed the not enough space for new header size error.
For some reason, I thought the 68K processor was 16-bit, so I told lwip a pointer uses 16 bits in the cc.h header file. (It has a 16 bit data bus, 24-bit external address bus, but is 32 bits internally.) Now, you would think I would have figured this out after using 32-bit addressing to get past the previous link error. Or, maybe I would have looked at the lwip cc.h for the coldfire processor, which is a 68K at heart. Or, maybe I would have read the Apple SC/SCpp Reference more thoroughly the first time around. Anyway, MPW for 68K uses 32 bit pointers.
Quick fix to the code:
typedef u32_t mem_ptr_t;
And... no assertion errors at run-time! It still isn't completing the PPP negotiation, but it is trying so hard: PowerMac-G4 pppd[777] <notice>: pppd 2.4.2 (Apple version 233-0-8) started by epooch, uid 0 PowerMac-G4 pppd[777] <notice>: Connect: ppp0 <--> /dev/cu.usbserial PowerMac-G4 pppd[777] <error>: Received bad configure-ack: 02 06 00 00 00 00 05 06 bf 68 ca 18 07 02 08 02 PowerMac-G4 pppd[777] <warning>: IPCP: timeout sending Config-Requests; PowerMac-G4 pppd[777] <warning>: acscp: timeout sending Config-Requests; PowerMac-G4 pppd[777] <notice>: Connection terminated.

Killing Bugs

MacPaint on Macintosh System 2.0

ZTerm on System 7.1

Click "Read more" for details...

Link Error with PPP

I realize that posts about porting code must horribly boring to read. However, the boring details will hopefully help someone who attempts some similar feat of folly. As a result, I will try to post a picture or two of a Macintosh or Mac GUI element that summarizes my progress. The details of which can be read by clicking the "Read more >>" link at the bottom of the post. First installment:

Before:
16-bit addressing can only reach 32K of code.

After:
32-bit addressing can access many more K of code!

Sibling Rivalry

Macintosh SE harassing sad Macintosh 128k for lack of internet connectivity…

Importing and Porting

The ppp-new branch of lwip is available for download here: lwip-ppp-new.tar.gz . Of course, I couldn't find the zip download at first, so I had to download git, compile and install it, then check-out the ppp-new branch of lwip. Oh well, now I have git installed.

In 2006, according to my old makefile, I tried to port lwip to the Mac OS, but I had no luck. I did a lot of hand editing of source code files to convert them to Mac paths and line-feeds. So this time, I took a few hours to write a short MPW Script to fix the line-feeds and paths of all of the source files at once.

I just realized the MPW compiler has an option -includes unix which solves the path issue. Oh well, at least I don't have to worry about the line-feeds.

So the lwip code is Macified, I just need to set up the architecture specific options and write a program to use it. I have a feeling I will have a lot more "Oh well"s in my future.