[comp.os.minix] Unix for Atari 8-bit

jca@pnet01.cts.com (John C. Archambeau) (05/25/90)

slayden@prandtl.nas.nasa.gov (James B. Slayden) writes:
>	Are there any commercial or developement projects to port any
>kind of unix to an Atari 8-bit machine? That is all I have right now and
>would like to use something like Minix to study with.

Probably after a full fledged K&R C compiler can be ported to the Atari
8-bit.  I can safely say since the Atari 8-bit machine was the first machine I
ever owned that I don't see a port of Minix ever happening.  We have enough
problems with the 64K segmentation of the 80x86 (x < 3) processors without
indroducing the problem of a 64K address space.  And even if you did kludge
the memory with the various memory upgrades out there, you'd still have the
problem of only having a single channel IRQ on the entire machine.  Not a
pretty thing to port any implementation of Unix to.

That's the whole reason I trashed my Atari 8-bit system eons ago and got an
IBM XT clone.  If you want bottom line Unix, you're going to have to get an XT
clone and run Minix on it, that is your only option.

If you want something a bit more powerful, then get an ST and run ST Minix on
it.  Minix does have its function inspite of the fact that PC Minix as it
stands now is a far cry from what I want in a Unix system.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Small memory model only for
 ** ARPANET : crash!pnet01!jca@nosc.mil     | Unix?  Get the (*bleep*) out
 ** INTERNET: jca@pnet01.cts.com            | of here!
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */

V2057A%TEMPLEVM.BITNET@cornellc.cit.cornell.edu (Juan Jose Noyles) (05/26/90)

I'm in no position to say what will or won't happen, but I'd like to remind
you folks that Unix v7, upon which Minix is based, was capable of running quite
well on a 64K machine (PDP 11/34).  Perhaps someone can find out from DEC
(Digital Equipment Corporation) and find out who wrote v7.11m, which I used in
1983 (on a PDP 11/34), and ask try to persuade them to become involved with or
at least look at Minix.

ast@cs.vu.nl (Andy Tanenbaum) (05/28/90)

In article <20321@nigel.udel.EDU> V2057A%TEMPLEVM.BITNET@cornellc.cit.cornell.edu (Juan Jose Noyles) writes:
>I'm in no position to say what will or won't happen, but I'd like to remind
>you folks that Unix v7, upon which Minix is based, was capable of running quite
>well on a 64K machine (PDP 11/34).  Perhaps someone can find out from DEC
>(Digital Equipment Corporation) and find out who wrote v7.11m, which I used in
>1983 (on a PDP 11/34), and ask try to persuade them to become involved with or
>at least look at Minix.

UNIX V7 for the PDP-11 was written by Ken Thompson and Dennis Ritchie of
AT&T Bell Labs.  I'll see both of them in London in July, where all three
of us are invited speakers at the UK UNIX USERS GROUP MEETING.
I'll ask them, but I suspect Dennis will giggle and Ken will frown.
I wouldn't hold my breath on this one.

Andy Tanenbaum (ast@cs.vu.nl)

geoff@utstat.uucp (Geoff Collyer) (05/28/90)

Juan Jose Noyles:
> Unix v7, upon which Minix is based, was capable of running quite well
> on a 64K machine (PDP 11/34).  Perhaps someone can find out from DEC
> ...  and find out who wrote v7.11m, which I used in 1983 (on a PDP
> 11/34), and ask try to persuade them to become involved with or at
> least look at Minix.

Actually, V7 was a bit cramped in the single 64k byte kernel address
space offered by the smaller 11s, at least when used for timesharing.
DEC produced V7M which ran on many more hardware configurations of
PDP-11 than did the original V7.  Fred Canter of DEC did much of the
work, if memory serves.  I don't recall if V7M was derived from 2BSD,
which was a severely hacked V7 from UC Berkeley which added memory
overlays to the V7 kernel, but which didn't always get it right (oops,
panic).  The 2BSD crew wanted to squeeze the features of 4BSD into a
PDP-11, and size and complexity be damned.

I was very glad that I was running an 11/70 and so didn't have to
choose among these V7 variants; our 11/70 ran real V7 until it was
sold in 1987.  Sigh, makes me nostalgic.
-- 
Geoff Collyer		utzoo!utstat!geoff, geoff@utstat.toronto.edu

henry@utzoo.uucp (Henry Spencer) (05/28/90)

In article <1990May27.213330.11881@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes:
>> Unix v7, upon which Minix is based, was capable of running quite well
>> on a 64K machine (PDP 11/34)...
>
>Actually, V7 was a bit cramped in the single 64k byte kernel address
>space offered by the smaller 11s, at least when used for timesharing.

V7 only just barely ran on the small 11s, in fact.  It made a workable
single-user system if you didn't get ambitious, but the kernel table
sizes had to be so small that it wasn't hard to get into trouble.

V6, on the other hand, ran fairly well on a 34-class machine with 64KB
of physical memory.  You needed to add a bit more core to get the biggest
programs to run, but you could edit, compile, etc. in 64K.  Multiple users
wouldn't be entirely happy about the performance, but they could get work
done.  I used such a system for a while (briefly at 64KB, extensively at
80KB).
-- 
As a user I'll take speed over|     Henry Spencer at U of Toronto Zoology
features any day. -A.Tanenbaum| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

MAB01057%UFRJ.BITNET@cornellc.cit.cornell.edu (Marcelo Amarante Ferreira Gomes) (05/29/90)

I missed this stuff while our link to the net was down, but, as an
Atari 8-bit user (I still use it as a terminal for my PC), I have some-
thing to say: It's a dream I'd like to see, but I doubt it'll be
practical or even pleasant to use, for it's disk drive is sooooooooooooo
slooooooooooooooow... I think that on any machine wich communicates to
its drive via a serial line, Unix, Minix or *ix will never feel the way
it really is.

But if you face it as a programming challenge, though, it might be well
worth to see if one can write such a piece of code - I'd face it myself
if I weren't so busy working on a compiler (during the free hours) with
Guy Helmer. Anyway, the request is pending on my (rather long) future
projects list. Maybe I can later fix the compiler I'm writting to cross
compile code for the 6502.

I've already given it a little thought: we could simulate a larger stack
using a 2-byte stack pointer on page zero - that wouldn't be so slow,
since page zero access is so fast. Regarding the OS itself, one could
use the display list interrupt as the time-slice end marker.

Well, let's stop here, for old 8-bit Atari fans like me may get nostalgic
and start writting the kernel from a series of articles starting with
this one. If anyone has suggestions (or would like them), you may get in
touch with me and maybe something comes out. Please don't expect me to
get too serious about this. I have a college graduating course to finish
and I think I'm already much busyer than I can handle, but I sure appreciate
a nice chat :-)

Marcelo A. Ferreira Gomes (Wally Gator) <MAB01057@UFRJ.bitnet>

jca@pnet01.cts.com (John C. Archambeau) (05/29/90)

MAB01057%UFRJ.BITNET@cornellc.cit.cornell.edu (Marcelo Amarante Ferreira Gomes) writes:
>I missed this stuff while our link to the net was down, but, as an
>Atari 8-bit user (I still use it as a terminal for my PC), I have some-
>thing to say: It's a dream I'd like to see, but I doubt it'll be
>practical or even pleasant to use, for it's disk drive is sooooooooooooo
>slooooooooooooooow... I think that on any machine wich communicates to
>its drive via a serial line, Unix, Minix or *ix will never feel the way
>it really is.
>
>But if you face it as a programming challenge, though, it might be well
>worth to see if one can write such a piece of code - I'd face it myself
>if I weren't so busy working on a compiler (during the free hours) with
>Guy Helmer. Anyway, the request is pending on my (rather long) future
>projects list. Maybe I can later fix the compiler I'm writting to cross
>compile code for the 6502.
>
>I've already given it a little thought: we could simulate a larger stack
>using a 2-byte stack pointer on page zero - that wouldn't be so slow,
>since page zero access is so fast. Regarding the OS itself, one could
>use the display list interrupt as the time-slice end marker.
>
>Well, let's stop here, for old 8-bit Atari fans like me may get nostalgic
>and start writting the kernel from a series of articles starting with
>this one. If anyone has suggestions (or would like them), you may get in
>touch with me and maybe something comes out. Please don't expect me to
>get too serious about this. I have a college graduating course to finish
>and I think I'm already much busyer than I can handle, but I sure appreciate
>a nice chat :-)

One serious problem I forsee (and I don't even know if you can get around it)
is how the Atari SIO bus handles devices.  If you have a serial port open, you
have to have the channel to your disk drive closed.  This is how all terminal
and BBS programs handle disk I/O.  So during a sync, every thirty or so
seconds the user would experience this slow down because of:

Close RS232 so we can yank the bus for disk I/O
Do sync
Reopen RS232 port

And this would go on every time a disk I/O would be done.  This is assuming
that you're going to make your Atari 8-bit Minix as Unix like as possible.

Whether ICD's MIO board behaves this way or not, I don't know.  I do know that
if you have a storage device daisy chained on the SIO port, you have to do
this because of the small number of control lines.  And one of them being one
IRQ which is enough to discourage me from attempting Minix on an Atari 8-bit. 
At least with an IBM clone, you have some IRQ's to play with.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Small memory model only for
 ** ARPANET : crash!pnet01!jca@nosc.mil     | Unix?  Get the (*bleep*) out
 ** INTERNET: jca@pnet01.cts.com            | of here!
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */

gdtltr@freezer.it.udel.edu (Gary Duzan) (06/04/90)

In article <2870@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes:
=>
=>One serious problem I forsee (and I don't even know if you can get around it)
=>is how the Atari SIO bus handles devices.  If you have a serial port open, you
=>have to have the channel to your disk drive closed.  This is how all terminal
=>and BBS programs handle disk I/O.  So during a sync, every thirty or so
=>seconds the user would experience this slow down because of:
=>
=>Close RS232 so we can yank the bus for disk I/O
=>Do sync
=>Reopen RS232 port
=>
=>And this would go on every time a disk I/O would be done.  This is assuming
=>that you're going to make your Atari 8-bit Minix as Unix like as possible.
=>
=>Whether ICD's MIO board behaves this way or not, I don't know.  I do know that
=>if you have a storage device daisy chained on the SIO port, you have to do
=>this because of the small number of control lines.  And one of them being one
=>IRQ which is enough to discourage me from attempting Minix on an Atari 8-bit. 
=>At least with an IBM clone, you have some IRQ's to play with.
=> 
=>     // JCA
=>
   The ICD MIO eliminates this problem. At times I have set up my modem for
folks to call in and directly access SpartaDOS with no special software. Since
the MIO uses the parallel bus, there is no need to block the SIO bus. It also
allows Hard Disk access.
   I have given significant thought to running a Unix-like OS on a 6502, and
while I imagine it could be done, I haven't quite that much stamina. However,
in my spare time I am trying to port GCC to the 65816 in an attempt to get
Minix to run on it. There is a 65816 upgrade (Turbo-816) for the Atari 8-bits,
and I think that is a more reasonable project. More than likely I will never
finish it, but I can dream, can't I? :-)

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration
                                 Atari Enthusiast Extreme



--
                          gdtltr@freezer.it.udel.edu
      _o_                 --------------------------                 _o_
    [|o o|]     "My field is blood and guts programming." -- Me    [|o o|]
     |_O_|      "Don't listen to me; I never do." -- Doctor Who     |_O_|

jca@pnet01.cts.com (John C. Archambeau) (06/04/90)

gdtltr@freezer.it.udel.edu (Gary Duzan) writes:
>In article <2870@crash.cts.com> jca@pnet01.cts.com (John C. Archambeau) writes:
>=>One serious problem I forsee (and I don't even know if you can get around it)
>=>is how the Atari SIO bus handles devices.  If you have a serial port open, you
>=>have to have the channel to your disk drive closed.  This is how all terminal
>=>and BBS programs handle disk I/O.  So during a sync, every thirty or so
>=>seconds the user would experience this slow down because of:
>=>
>=>Close RS232 so we can yank the bus for disk I/O
>=>Do sync
>=>Reopen RS232 port
>=>
>=>And this would go on every time a disk I/O would be done.  This is assuming
>=>that you're going to make your Atari 8-bit Minix as Unix like as possible.
>=>
>=>Whether ICD's MIO board behaves this way or not, I don't know.  I do know that
>=>if you have a storage device daisy chained on the SIO port, you have to do
>=>this because of the small number of control lines.  And one of them being one
>=>IRQ which is enough to discourage me from attempting Minix on an Atari 8-bit. 
>=>At least with an IBM clone, you have some IRQ's to play with.
>=> 
>=>     // JCA
>=>
>   The ICD MIO eliminates this problem. At times I have set up my modem for
>folks to call in and directly access SpartaDOS with no special software. Since
>the MIO uses the parallel bus, there is no need to block the SIO bus. It also
>allows Hard Disk access.
>   I have given significant thought to running a Unix-like OS on a 6502, and
>while I imagine it could be done, I haven't quite that much stamina. However,
>in my spare time I am trying to port GCC to the 65816 in an attempt to get
>Minix to run on it. There is a 65816 upgrade (Turbo-816) for the Atari 8-bits,
>and I think that is a more reasonable project. More than likely I will never
>finish it, but I can dream, can't I? :-)

Oh yes, I've gone back and forth with you in e-mail a couple of times that the
65816 implementation would be much more doable.  If MIO boards didn't cost as
much as a 386SX motherboard, I may just go in with you on it for the heck of
it.

Unfortunately, for the cost of bringing my Atari XE system back up to snuff to
handle Minix development, I'd probably end up spending about as much as I
would for a second 386(SX) system.
 
     // JCA

 /*
 **--------------------------------------------------------------------------*
 ** Flames  : /dev/null                     | Small memory model only for
 ** ARPANET : crash!pnet01!jca@nosc.mil     | Unix?  Get the (*bleep*) out
 ** INTERNET: jca@pnet01.cts.com            | of here!
 ** UUCP    : {nosc ucsd hplabs!hd-sdd}!crash!pnet01!jca
 **--------------------------------------------------------------------------*
 */

rbthomas@frogpond.rutgers.edu (Rick Thomas) (06/13/90)

Speaking of 65816's, many memory expander boards for the Apple IIe have
a socket for an '816.  It can be used as a co-processor to the 6502 on
the motherboard.  This leads (more or less as the night leads to the
day...) to a kernel architecture in which the low level device drivers
run on the '02 and everything else runs on the '816.

The Apple IIe's abysmal treatment of interrupts, and the software
driven floppy disk interface (all the bit-bashing is done in software
so Woz could keep the chip count down.) have kept me from even dreaming
of Minix on my Apple IIe, but maybe it is possible after all if the
devices can be polled by the 6502... thus neatly finessing the
interrupts problem.

Enjoy!