[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Wanted: assistance to get IIgs emulator(s) to use TCP/IP stackin host



 To: roughana
Hi Andrew,

roughana wrote:
Hi all,

I want to be able to use Marinetti applications from within a IIgs
emulator - preferably wirelessly.

After I adopted cs8900A support into AppleWin, I briefly looked at adding similar support to kegswin. I think I got close (sorry it's been awhile and I am recalling this from memory without going back to look a the code) on basic functionality but stumbled on the configuration screen aspect of the integration. It probably wasn't that difficult but I moved on to something else without finishing it.

I think I had in my mind that even if I did complete it, I was wondering how difficult it would be to get the finished product rolled into an offical kegs release .. seeing as there hasn't been one for some years now... and I did not want to support a splinter version.

The support in Applewin uses winpcap which does not play well with wireless interfaces. Oliver Schmidt suggested a way to fix that similar to the way that he handles tcpip integration for Contiki in the native windows port. I looked at that but did not pursue the work required. (again too many things - too little time)

To make it cross platform as kegs is now, it would also require investigation into versions of pcap for linux and macos.


(and selfishly, preferably on MacOS 8.x - because I have a PB1400 and
love it. But I'd move platforms pretty quickly if any other solution
was useable)

First, what is available?

Each host machine is likely to have a TCP/IP stack that is available
to the emulator to use. All that is missing is glue code to hook
things up.

Apparently this has been done for KEGS once already, but it is not
compiled into the distribution so therefore makes it unlikely that ye
average Joe will get this to work on their own.

Bernie has great serial port wizardry that allows the IIgs to drive a
Mac serial port as its own. The Marinetti PPP link layer works but
this requires a serial cable connection to something (modem / other
computer).

Possible solutions:

o Another implementation for KEGS that can be made part of the
distribution and therefore available to everyone ongoingly.

I wonder if Kent Dickey would be open to this?


o Some kind of serial port driver on the Mac that Bernie could talk to
without modification that routes traffic to/from OpenTransport. Would
probably require a different Marinetti link layer that expected this
setup and knew how to handle it.

o Sweet 16 on OS X is mean to be receiving a generic slot interface so
that any card (e.g. Uthernet) could be emulated. I believe that this
would require someone with Mac OS X programming ability to write a
driver that emulated a card (e.g. Uthernet) and communicated with the
host TCP/IP interface.

My understanding was that Eric was gong to work on this (see a2c.network_telecom news group - April 2007) ... I offered assistance ... have not heard any kind of update on his progress to date.


Does anyone have the skills necessary to be able to assist with any of
these alternatives?

I am willing to help where I can but I don't have the cycles to drive this a main project nor the experience when it comes to native Windows or MacOS programming.


Are there other possible solutions?

I welcome any discussion on this as I've been annoyed for years that
I've been unable to find a solution that works for me out of the box.


I would still like to see this as well ... At one point I fancied a native port of Contiki 1.3 for the IIgs (using ORCA/c) that would make use of things like additional memory, possibly a graphical CTK (like the c64 port) ... but as Oliver has noted else where there has been no activity on Contiki apps for that platform (1.3) so one wonders if the effort justifies the result (native 16 bit Contiki 1.3) when there are so many other possibilities/projects to consider.

Glenn
--- Synchronet 3.14a-Win32 NewsLink 1.85
A2Central.com - Your total source for Apple II computing.