Support for Lamp on older platforms
Joshua Juran
finally got around to trying some older platforms.
First was 7.6.1 on an LC. Lamp mostly worked as expected, with a few
caveats:
* Access to /sys/mac/crsr/location caused a crash due to unchecked use
of the Cursor Device Manager. This has now been fixed to check for
the _CursorDeviceDispatch trap and use low memory globals if it's
absent.
* Open Transport doesn't run on a 68020. Fortunately, the statically-
linked Open Transport library code gracefully returns -3201,
kOTNotFoundErr. Less fortunately, the OSErr-to-errno conversion
doesn't detect this case and socket() sets errno to EINVAL.
Supporting IP networking on 68020 would require targeting MacTCP.
Actually, since System 7.6 doesn't support MacTCP itself (even though
it's backward-compatible with MacTCP-calling programs), it seems
networking in 7.6 on a 68020 is completely unsupported.
Running System 7.1 had the further complication that my apps were not
checking the availability of _ThreadDispatch. My app framework now
calls YieldToAnyThread() only when the Thread Manager is available
(fixing e.g. the MacBinary decoder app), though Lamp still needs to
check for itself and refuse to run if it's missing. After installing
Thread Manager 2.0.1, Lamp worked as expected (taking into account
that things like AppleScript aren't available).
So, the next step in making Lamp useful on a 68020 might be MacTCP
support.
Josh
P.S. The MacBinary III+ Decoder app on my site has not been updated
yet -- it requires the Thread Manager to run.
tortoise
On Sep 23, 5:30 pm, Joshua Juran <jju...@gmail.com> wrote:
> Lamp has been known to work in System 7.6.1 on 68040 machines. I
> finally got around to trying some older platforms.
is a unix environment for 68k mac running inside System7,
Pretty ancient but does support ports of gcc and a bunch of unix
utilities. Not portable to powermacs though I think.
Brian
Cameron Kaiser
> > finally got around to trying some older platforms.
>
> Do you know about PATMOS ? Here is a link with binary and source.
There wasn't a link in your message that I could find.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- Life is like a simile. -----------------------------------------------------
Joshua Juran
Here are my notes on PATMOS:
PATMOS
http://freegroups.net/macos_files/Programming.shtml
http://freegroups.net/macos_files/macos_files/Programming/patmos-11-c.hqx
+ protected memory
+ grow-on-demand stack
+ true fork()
+ MacBSD binary-compatible
- 68K only, won't run in Mac OS 68K emulator
- probably doesn't work in Basilisk II
To be maximally useful, Lamp needs to be able to run (a) in emulation,
and (b) natively in PowerPC.
That said, several things might be possible:
* Reuse PATMOS' strategy of programming the MMU when supported[1]
* Load alternate executable formats / runtimes[2]
* Run code for other operating systems[3]
Other things that are more likely:
* Emulate fork()[4]
* Use preemptive threads on 68K (should work in emulation)
* Use (preemptive) MPTasks on PPC (should work in emulation[5] and on
OS X)
Josh
[1] 'When supported' meaning 'only on actual 68K hardware'. I think.
[2] I really like CFM's ability to specify private globals for
multiple connections to the same code fragment. This means that
multiple shells or perl instances (for example) load only one copy of
the corresponding binary (except on OS X, where it's broken). I can't
get MWLink68K to generate a code resource that allows for this, but I
might be able to load a CFM-68K binary and run it (without even
requiring the CFM-68K Runtime Enabler) Anyway, loading ELF or a.out
shouldn't be a problem, but it's far from the only hurdle.
[3] It may be possible to implement the system environment expected of
a Linux or MacBSD user program, depending on what assumptions it
makes. This won't work in the PPC emulators, because modern operating
systems use processor exceptions ('trapping') to make system calls,
and SheepShaver and Rosetta don't implement these exceptions.
[4] Since (a) the parent and child must both be allowed to run without
waiting for the other to terminate, (b) memory accesses in one must
not be detectable by the other, and (c) each process' memory must
occupy the same memory ranges as the caller, then unless the MMU is
programmed for this purpose, it's necessary to copy a process' memory
structures to a saved area and swap in the ones for the next process
to run. This needn't occur on every context switch -- only when the
parent or child is switched in, and the last to run was the other, and
only until one of them execs or terminates. This is still grossly
inefficient, but it beats not having fork() at all, and it will work
everywhere.
[5] MacCVS Pro had an issue running in SheepShaver: User input was
impossible while network I/O was occurring. I wonder if this is an
artifact of MCP's use of MPTasks or SheepShaver's implementation, and
if this would affect other users.
tortoise
On Sep 25, 10:32 pm, Cameron Kaiser <spec...@floodgap.com> wrote:
> > > Lamp has been known to work in System 7.6.1 on 68040 machines. I
> > > finally got around to trying some older platforms.
>
> > Do you know about PATMOS ? Here is a link with binary and source.
>
> There wasn't a link in your message that I could find.
ftp://sunsite.cnlab-switch.ch/software/platform/macos/src/HTML/All.html
Problem -- I just tried to go there to get more stuff built with
PATMOS (such as gcc..)
and it gave me "connection refused"
I did find another download for PATMOS itself googling (link on my
other laptop not here)
but only that and not the other stuff :((
Brian
>
> --
> ------------------------------------ personal:http://www.cameronkaiser.com/--
> Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com