7 Nov
2007
7 Nov
'07
10:21 a.m.
Message: 4
Date: Mon, 05 Nov 2007 12:31:28 -0700
From: woodelf <bfranchuk at jetnet.ab.ca>
Subject: Re: modern serial terminal
PS. I like windows/95 over the latest versions of linux ... Too much bloat.
There was never a version of Linux, or UNIX in general, less bloated
than Windows 95. Windows 95 will very comfortably get you TCP/IP,
protected memory, preemptive multitasking[1], and a graphical desktop on
a 486 SX with 8M of RAM. Linux 2.0 with XF86 3.x was a carnival of
swapping on that configuration. Solaris x86 wouldn't even boot.
If Windows 3.1 was the last nail in the coffin for UNIX on the desktop,
Windows 95 was the last shovel of dirt and the weepy obit.
It's almost fun to load up Redhat 4 on a typical PC of the day and watch
it take twenty minutes to boot.
[1] Yes, Windows 95 had memory protection and preemptive multitasking.
All native win32 and native kernel code ran that way. The catch was that
16 bit drivers and applications were exempted from these restrictions.
Worse still, Windows 95 shipped with some 16 bit drivers for generic
devices, giving you a broken configuration out of the box on a lot of
hardware.
7 Nov
7 Nov
11:02 a.m.
On Wed, 7 Nov 2007, ajones wrote:
Date: Wed, 07 Nov 2007 10:21:02 -0500
From: ajones <aijones2 at bsu.edu>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: cctalk at classiccmp.org
Subject: Re: modern serial terminal
Umm... nonsense...
Ultrix32 on a Vaxstation (say 1/8 the horsepower of the 486sx) was
comfortable in 8M, including _complete_ TCPIP, X, real shell(s), and
reliability... all this about 8 years before W95...
Peter Wallace
Message: 4
Date: Mon, 05 Nov 2007 12:31:28 -0700
From: woodelf <bfranchuk at jetnet.ab.ca>
Subject: Re: modern serial terminal
PS. I like windows/95 over the latest versions of linux ... Too much bloat.
There was never a version of Linux, or UNIX in general, less bloated than
Windows 95. Windows 95 will very comfortably get you TCP/IP, protected
memory, preemptive multitasking[1], and a graphical desktop on a 486 SX with
8M of RAM. Linux 2.0 with XF86 3.x was a carnival of swapping on that
configuration. Solaris x86 wouldn't even boot.
12:42 p.m.
On 7 Nov 2007 at 10:21, ajones wrote:
There was never a version of Linux, or UNIX in
general, less bloated
than Windows 95. Windows 95 will very comfortably get you TCP/IP,
protected memory, preemptive multitasking[1], and a graphical desktop on
a 486 SX with 8M of RAM. Linux 2.0 with XF86 3.x was a carnival of
swapping on that configuration. Solaris x86 wouldn't even boot.
For me, my standard "x86 Work Platform" is MSDOS/Win98 booted to DOS
with DOSLFN added. One gets FAT32 partitions, long filename support
and direct access to hardware ports that will run on a slow 386
(Anyone know why MSDOS 7.1 doesn't work on a 286?). Type "WIN" and
you've got a GUI that will run most Windoze apps, USB, DPMI32 server
and networking--and you still keep access to the hardware ports and
your real-mode DOS drivers. It's not the most secure setup in the
world, but it does most of what I need--even on very slow hardware.
And it loads pretty fast, compared to *nix or even the MS NT variants
like XP or 2K.
95 is a little too flakey for me and ME has got a number of annoying
things that make work more difficult.
Cheers,
Chuck
12:48 p.m.
On 7 Nov 2007 at 10:21, ajones wrote:
> There was never a version of Linux, or UNIX in general, less bloated
> than Windows 95. Windows 95 will very comfortably get you TCP/IP,
> protected memory, preemptive multitasking[1], and a graphical desktop on
> a 486 SX with 8M of RAM. Linux 2.0 with XF86 3.x was a carnival of
> swapping on that configuration. Solaris x86 wouldn't even boot.
You have to be very careful saying things like "never". I've had
TCP/IP, protected memory and preemptive multitasking on UNIX on machines
quite a bit smaller than 8MB. Including an X GUI.
I've had those features on machines way smaller than 8MB on non-UNIX
machines.
Peace... Sridhar
12:58 p.m.
In article <4731FA69.6010405 at gmail.com>,
Sridhar Ayengar <ploopster at gmail.com> writes:
> On 7 Nov 2007 at 10:21, ajones wrote:
>> There was never a version of Linux, or UNIX in general, less bloated
>> than Windows 95.
Umm... IIRC, Xenix was a unix implementation that didn't even require
virtual memory, ran on x86 architectures (386?) and required very
little memory; certainly much less than Win96 since Xenix was
available in 1986.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
1:30 p.m.
On 7 Nov 2007 at 10:58, Richard wrote:
Umm... IIRC, Xenix was a unix implementation that
didn't even require
virtual memory, ran on x86 architectures (386?) and required very
little memory; certainly much less than Win96 since Xenix was
available in 1986.
Early Xenix ran on a 286. I don't think it ever ran on anything
less. I have an early Microsoft MSDOS 2.0 OEM announcement that
talks about eventually unifying Xenix and MSDOS. I guess that goes
in the same category as Microsoft OS/2 2.0...
Cheers,
Chuck
2:47 p.m.
On Wed, 7 Nov 2007, Chuck Guzis wrote:
I learned Microsoft Xenix on a Tandy 6000HD in 1985, which had a 68000
CPU. It also ran on the TRS-80 16B.
Mike Loewen mloewen at cpumagic.scol.pa.us
Old Technology http://sturgeon.css.psu.edu/~mloewen/Oldtech/
Umm... IIRC,
Xenix was a unix implementation that didn't even require
virtual memory, ran on x86 architectures (386?) and required very
little memory; certainly much less than Win96 since Xenix was
available in 1986.
Early Xenix ran on a 286. I don't think it ever ran on anything
less. I have an early Microsoft MSDOS 2.0 OEM announcement that
talks about eventually unifying Xenix and MSDOS. I guess that goes
in the same category as Microsoft OS/2 2.0...
3:43 p.m.
On 7 Nov 2007 at 14:47, Mike Loewen wrote:
I learned Microsoft Xenix on a Tandy 6000HD in
1985, which had a 68000
CPU. It also ran on the TRS-80 16B.
At one point, I had the Z80 I/O routines listing for the 16B Xenix,
courtesy of Microsoft. I didn't hang onto it. We were doing a Xenix
port to a 186/286 board where the 186 did all of the I/O. I was
given the TRS-80 listing as an implementation guide.
But a 68K is a whole lot more CPU than an 8086. One might even argue
that it's more CPU than a 286.
Cheers,
Chuck
4:24 p.m.
On Wed, Nov 07, 2007 at 12:43:45PM -0800, Chuck Guzis wrote:
But a 68K is a whole lot more CPU than an 8086. One
might even argue
that it's more CPU than a 286.
I would, but then I've programmed the 68000 and the 286 in assembler,
professionally.
To hammer this back to the portable serial terminal thread, a 68K-based
terminal would be *great*, but unless you wanted to get into graphical
emulation (Tektronix, GraphOn, VT240...), overkill for the original
scope. I'm personally very fond of the 68000, and have tubes and
tubes of the 64-pin DIP variety on the shelf and lots of hardware
trace and debugging tools, but compared to an 8051 or a Z-80 or
6502 design, not cost effective.
It would be a fun little box, though... and difficult to avoid
serious feature creep into a 16/32-bit Micro.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 7-Nov-2007 at 21:20 Z
South Pole Station
PSC 468 Box 400 Temp -54.8 F (-48.2 C) Windchill -79.1 F (-61.7 C)
APO AP 96598 Wind 6.1 kts Grid 325 Barometer 685.7 mb (10414 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
7:28 p.m.
New subject: MC68000 "size" (was Re: modern serial terminal)
On Wed, Nov 07, 2007 at 03:42:16PM -0800, Eric J Korpela wrote:
On Nov 7, 2007 1:26 PM, woodelf <bfranchuk at
jetnet.ab.ca> wrote:
As will you and I... the MC68020 is unarguably a 32-bit processor, but the
MC68000 is much more a 32-bit processor than a 16-bit processor.
The external data bus _is_ 16 bits for the MC68000, but the internal
register model is 32 bits. The address bus is 24 bits, not 32, but
a 16-bit processor like the 80286 or the PDP-11 has 16-bit address
registers, and can't access more than 64K without register segments or
an MMU or something similar. The MC68000 needs no additional decoding
hardware or tricky software to address its full 16M address space (which
is the same size address bus as the VAX-11/750, which to all accounts
_is_ a 32-bit processor).
There's a reason I described the 68000 as a 16/32 processor earlier
today... internally it *is* 32 bits. The bus interface is just reduced
to save on the pin count, etc.
Look at the size of the ALU and the accumulator(s)/data registers, then
come back to me.
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 8-Nov-2007 at 00:20 Z
South Pole Station
PSC 468 Box 400 Temp -52.2 F (-46.8 C) Windchill -71.5 F (-57.5 C)
APO AP 96598 Wind 4.2 kts Grid 332 Barometer 686.1 mb (10399 ft)
Ethan.Dicks at usap.gov http://penguincentral.com/penguincentral.html
The 68K is 32 bit cpu
We'll have to agree to disagree on that. MC68020 is the first 32 bit
CPU in the 68K line. 
7:42 p.m.
We'll have
to agree to disagree on that. MC68020 is the first 32
bit CPU in the 68K line.
How does one define 32 bit cpu? I know nothing about the
68020 but I
am guessing a 32 bit bus, and some sort of virtual memory. 
8:57 p.m.
New subject: 68k and 32-bit-dom was Re: modern serial terminal
Virtual memory is not, to my mind, either necessary or
sufficient for a
machine to be a 32-bitter. Indeed, IIRC the 68020 does not have any
kind of MMU; when present, that's separate (common, but separate and
not necessary). I think the '040 was the first 68k-series CPU to have
an on-chip MMU (and if I'm wrong I'm sure someone will correct me!).
Actually, the '030 was the first one.
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- LET'S GO FORWARD ... INTO THE PAST! ----------------------------------------
9:38 p.m.
der Mouse wrote:
That makes it a 32-bit architecture to me,
regardless of what kind of bus it has - even if it were bit-serial,
those attributes would make it a 32-bit machine to me.
Can I sell you a Manchester Baby Clone ... Full 32 bits.
Now in solid state. CRT memory optional. :)
Virtual memory is not, to my mind, either necessary or
sufficient for a
machine to be a 32-bitter. Indeed, IIRC the 68020 does not have any
kind of MMU; when present, that's separate (common, but separate and
not necessary). I think the '040 was the first 68k-series CPU to have
an on-chip MMU (and if I'm wrong I'm sure someone will correct me!).
8 Nov
8 Nov
10:07 p.m.
On Nov 7, 2007 4:37 PM, woodelf <bfranchuk at jetnet.ab.ca> wrote:
Eric J Korpela wrote:
If it's got one or more 32 bit wide ALU and 32 bit registers and a 32
bit internal data bus it's a 32 bit processor.
If a processor has 16 bit registers, 16 bit math and address
calculation, and a 16 bit address bus, but it's ALU is only 8 bit and
its internal data bus is 8 bits, it's an 8 bit processor. Right?
We'll have to agree to disagree on that.
MC68020 is the first 32 bit
CPU in the 68K line.
How does one define 32 bit cpu? I know nothing about the
68020
but I am guessing a 32 bit bus, and some sort of virtual memory.
10:15 p.m.
So what's your thoughts on the 8088? 16-bit
registers, 8-bit data path
(but with 16-bit addressing). Is it a 16-bit CPU or an 8-bit CPU?
ALU and internal data path are 16 bits. It's essentially an 8086
multiplexed down to an 8 bit external data bus. That makes it a 16
bit processor in my book, albeit a crippled one. For the same reason
a MC68008 is a 16 bit processor in the same way that the MC68000 is.
The Z80, on the other hand, has an 8 bit ALU and 8 bit internal data
path, but has 16 bit registers and 16 bit address math and a 16 bit
address bus. That makes it a 8 bit processor.
For MC6809, I don't know enough of the internals to make a judgement.
I'd guess that it's got an 8 bit ALU and 8 bit internal data paths,
but I'm not sure.
Eric
10:24 p.m.
On Thu, 8 Nov 2007, Eric J Korpela wrote:
Hmm... So, why was the Sega Genesis billed as a 16-bit machine? It uses a
68k.
--
David Griffith
dgriffi at cs.csubak.edu
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
So what's
your thoughts on the 8088? 16-bit registers, 8-bit data path
(but with 16-bit addressing). Is it a 16-bit CPU or an 8-bit CPU?
ALU and internal data path are 16 bits. It's essentially an 8086
multiplexed down to an 8 bit external data bus. That makes it a 16
bit processor in my book, albeit a crippled one. For the same reason
a MC68008 is a 16 bit processor in the same way that the MC68000 is.
10:32 p.m.
David Griffith wrote:
On Thu, 8 Nov 2007, Eric J Korpela wrote:
Hmm... So, why was the Sega Genesis billed as a 16-bit machine? It uses a
68k.
If memory serves, because it has a 16-bit graphics pipeline.
Peace... Sridhar
So
what's your thoughts on the 8088? 16-bit registers, 8-bit data path
(but with 16-bit addressing). Is it a 16-bit CPU or an 8-bit CPU?
ALU and
internal data path are 16 bits. It's essentially an 8086
multiplexed down to an 8 bit external data bus. That makes it a 16
bit processor in my book, albeit a crippled one. For the same reason
a MC68008 is a 16 bit processor in the same way that the MC68000 is. 
9 Nov
9 Nov
9:40 p.m.
Long time since I played on my Megadrive, and long since forgotten the system's stats,
though I'm sure I could dig it up looking through my old official (UK) Sega magazines
:)
Wasn't there different manufacturers of 68000's? I know the original was created
by Motorola, but I can't say for sure whether the one Sega used was by them.
Just incase anyone wondered (or perhaps not!), the SNES was actually an 8-bit machine with
a "crazy chip" (think I got that quote right, been a long time since I read
"Game Over" by David Scheff). I'd love to know how mode 7 worked (for 3D-ish
racing games like Mario Kart and F-Zero), as it couldn't do 3D polygon graphics until
the SFX (Super Effects) chip was created (presumably just some sort of maths
co-processor?)
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
Sridhar Ayengar <ploopster at gmail.com> wrote: David Griffith wrote:
*>> snip <<*
Hmm... So, why was the Sega Genesis billed as a 16-bit machine? It uses a
68k.
If memory serves, because it has a 16-bit graphics pipeline.
Peace... Sridhar
10 Nov
10 Nov
1:21 p.m.
Andrew Burton wrote:
Just incase anyone wondered (or perhaps not!), the
SNES was actually an 8-bit machine with a "crazy chip" (think I got that quote
right, been a long time since I read "Game Over" by David Scheff). I'd love
to know how mode 7 worked (for 3D-ish racing games like Mario Kart and F-Zero), as it
couldn't do 3D polygon graphics until the SFX (Super Effects) chip was created
(presumably just some sort of maths co-processor?)
Wikipedia has an extensive set of documentation on what the SNES was,
it's capabilities, and what the SuperFX chip was.
9 Nov
9 Nov
12:46 a.m.
Eric J Korpela wrote:
For MC6809, I don't know enough of the internals
to make a judgement.
I'd guess that it's got an 8 bit ALU and 8 bit internal data paths,
but I'm not sure.
That is true for the 6809, but the 6309 (6809 clone)I think has 16 bit internal
data paths.
Eric
8:38 a.m.
Just for curiosity's sahe.
Is the discussion of a dedicated, non-PC, programmable serial
terminal dead in the water?
Doc
1:47 p.m.
Doc Shipley wrote:
Just for curiosity's sahe.
Is the discussion of a dedicated, non-PC, programmable serial terminal
dead in the water?
I remember the inventers of the PAL chip, had a serial terminal
in their book of examples of what to do with PAL's.I think it was
only 300 buad how ever, for screen scrolling was in done with
the video scanning logic.
Doc
Ben.
7 Nov
7 Nov
7:45 p.m.
Hi,
We'll have to agree to disagree on that. MC68020
is the
first 32 bit CPU in the 68K line.
Nope, the 68000 was very much a 32-bit processor; just that it had a 16-bit
external data bus (just as the 8088 had an 8-bit external data bus).
Motorola themselves describe it as a 16/32-bit processor ("ST" ;-)).
TTFN - Pete.
8:43 p.m.
Eric J Korpela wrote:
On Nov 7, 2007 1:26 PM, woodelf <bfranchuk at
jetnet.ab.ca> wrote:
So what's your thoughts on the 8088? 16-bit registers, 8-bit data path
(but with 16-bit addressing). Is it a 16-bit CPU or an 8-bit CPU?
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
The 68K is 32 bit cpu
We'll have to agree to disagree on that. MC68020 is the first 32 bit
CPU in the 68K line.
8 Nov
8 Nov
12:05 a.m.
woodelf wrote:
Jim Leonard wrote:
I think defining a CPU solely by it's memory interface is missing the
forest for the trees. The main purpose of a CPU is to calculate, not
move memory. It's a CPU, not an MMU. CPUs should be categorized by
their capabilities.
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
So what's your thoughts on the 8088? 16-bit
registers, 8-bit data
path (but with 16-bit addressing). Is it a 16-bit CPU or an 8-bit CPU?
8 bit CPU
with 16 bit instructions. :( 
3:44 p.m.
Eric J Korpela wrote:
And how about the Philips P850? The front panel has 16 lights and
switches. The registers appear to be 16 bits wide. The I/O bus is 16 bits
wide. But the ALU is 8 bits wide, as is the memory bus. The machine does
2 ALU operations in hardware for each apparent 16 bit operation.
For an even odder example, consider the HP9810 calculator. It can be
considered to be :
1 bit (ALU width for binary operations)
3 bits (Phyiscial width of user program RAM)
4 bits (ALU width for BCD operations)
6 bits (Logical width of user program RAM)
8 bits (physiical width of user data RAM)
16 bits (physical size of registers, ROM width, logical width of data RAM)
-tony
On Nov 7, 2007 1:26 PM, woodelf <bfranchuk at
jetnet.ab.ca> wrote:
So what's your thoughts on the 8088? 16-bit registers, 8-bit data path
(but with 16-bit addressing). Is it a 16-bit CPU or an 8-bit CPU? The 68K is 32 bit cpu
We'll have to agree to disagree on that. MC68020 is the first 32 bit
CPU in the 68K line.
10:20 p.m.
On Nov 8, 2007 12:44 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
1 bit (ALU width for binary operations)
3 bits (Phyiscial width of user program RAM)
4 bits (ALU width for BCD operations)
6 bits (Logical width of user program RAM)
8 bits (physiical width of user data RAM)
16 bits (physical size of registers, ROM width, logical width of data RAM)
Does it have a separate ALU for binary and BCD operations, or does it
just ignore the upper 3 bits of the BCD ALU in each stage of a binary
operation? If so, I'd probably call it a 4 bitter.
9 Nov
9 Nov
8:16 p.m.
On Nov 8, 2007 12:44 PM, Tony Duell <ard at p850ug1.demon.co.uk> wrote:
The ALU is a pair of programmed 256 nybble ROMs. One of them handles
binary operations and the low bit of BCD operations, the other handles
the high 3 bits of BCD operations (that's a simplification, if you want
to see the scheamtics, grab 'my' scheamtics for the HP9810 from
hpmuseum.net and look at the data path board). There are a couple of
D-types hung off said ROMs for the binary and BCD carry flags.
Actually, since the programmer-accessible registers are almost all 16
bits long (A and B accumulaotrs, P program counter, etc) and since the
only thing that bothers about the fact that it's a bit-serial machine is
the microcode, it's normally classed as a 16 bit (albeit bit serial) machine.
-tony
1 bit (ALU width for binary operations)
3 bits (Phyiscial width of user program RAM)
4 bits (ALU width for BCD operations)
6 bits (Logical width of user program RAM)
8 bits (physiical width of user data RAM)
16 bits (physical size of registers, ROM width, logical width of data RAM)
Does it have a separate ALU for binary and BCD operations, or does it
just ignore the upper 3 bits of the BCD ALU in each stage of a binary
operation? If so, I'd probably call it a 4 bitter.
8 Nov
8 Nov
1:43 p.m.
On Wednesday 07 November 2007 18:42, Eric J Korpela wrote:
On Nov 7, 2007 1:26 PM, woodelf <bfranchuk at
jetnet.ab.ca> wrote:
I don't tend to look at things that way, figuring them _all_ to be 32-bit
parts, but if you must, then the earlier peecee stuff was still 8-bit as
well...
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin
The 68K is 32 bit cpu
We'll have to agree to disagree on that. MC68020 is the first 32 bit
CPU in the 68K line. 
5:37 p.m.
On Thu, 8 Nov 2007, Roy J. Tellason wrote:
And the Z80 is a four bit processor...
Christian
We'll have
to agree to disagree on that. MC68020 is the first 32 bit
CPU in the 68K line.
I don't tend to look at things that way, figuring them
_all_ to be 32-bit
parts, but if you must, then the earlier peecee stuff was still 8-bit as
well... 
7 Nov
7 Nov
8:25 p.m.
> But a 68K is a whole lot more CPU than an 8086.
One might even argue
> that it's more CPU than a 286.
On Wed, 7 Nov 2007, woodelf wrote:
Make that a 386 and you got a fact.The 68K is 32 bit
cpu,none of this
16 bit wantabe's.
How do we DEFINE "a 32 bit CPU"?
Would we consider a 386SX to be a "32 bit CPU"?
9:09 p.m.
Hi,
Exactly.
The choice and wording of the definition will determine whether the 8088
is 8 bit or 16 bit; 8086 meets stricter definitions of 16 bit,
and whether the 68000 and 3086SX are 16 bit or 32 bit; 3086DX and 68020
meet stricter definitions of 32 bit.
--
Grumpy Ol' Fred cisin at xenosoft.com
How do we DEFINE "a 32 bit CPU"?
Would we consider a 386SX to be a "32 bit CPU"?
I don't see any
reason why we shouldn't.
You might as well ask whether the IBM PC is a 16-bit computer or an 8-bit
system? ;-)
3:58 p.m.
In article <473193BE.19835.582AE5C at cclist.sydex.com>,
"Chuck Guzis" <cclist at sydex.com> writes:
Early Xenix ran on a 286. I don't think it ever
ran on anything
less. I have an early Microsoft MSDOS 2.0 OEM announcement that
talks about eventually unifying Xenix and MSDOS. I guess that goes
in the same category as Microsoft OS/2 2.0...
IIRC, Microsoft bought Xenix from its original vendor, so Xenix
predates the MS release.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7:46 p.m.
Richard wrote:
In article <473193BE.19835.582AE5C at
cclist.sydex.com>,
"Chuck Guzis" <cclist at sydex.com> writes:
Yeah, I think I remember that too.
Acorn were working on a port of Xenix for the NS32016 which might have been
interesting, but unfortunately it all got canned before it was finished. :-(
(I don't think anyone else managed a port to that particular CPU - there never
were many machines which used it)
cheers
Jules
Early Xenix ran on a 286. I don't think it
ever ran on anything
less. I have an early Microsoft MSDOS 2.0 OEM announcement that
talks about eventually unifying Xenix and MSDOS. I guess that goes
in the same category as Microsoft OS/2 2.0...
IIRC, Microsoft bought Xenix from its original vendor, so Xenix
predates the MS release.
8 Nov
8 Nov
2:08 p.m.
Acorn were working on a port of Xenix for the NS32016
which might have been
interesting, but unfortunately it all got canned before it was finished. :-(
(I don't think anyone else managed a port to that particular CPU - there never
were many machines which used it)
The Whitechapel MG1 must have orun some unix-like OS (although I doubt it
was Zenix), and that machine is certianly 32016-based
-tony
4:57 p.m.
>>>>
The Whitechapel MG1 must have orun some unix-like OS (although I doubt it
was Zenix), and that machine is certianly 32016-based
<<<<<
It wasn't just "Unix-like", it was Unix.
Actually there were (at least) two versions - I think the 1st one was fairly
closely based on "raw" AT&T, the second was more BSD-like.
I don't know whether I should admit to this (NDA from long ago), but I have
the complete AT&T Unix source for the 32016 from the days when City
University had a loads of MG-1s ... well zipped it fits on 3 floppies.
(could you even get the kernel source for a modern *nix in that space?)
Andy
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.15.24/1117 - Release Date: 07/11/2007
22:52
7 Nov
7 Nov
6:40 p.m.
On Nov 7, 2007 10:30 AM, Chuck Guzis <cclist at sydex.com> wrote:
On 7 Nov 2007 at 10:58, Richard wrote:
I have, in my posession, a disk set for 8086 Xenix. I have not
attempted to boot it as the accompanying scribbled note indicate that
it won't work on a machine with a VGA installed, and I haven't
bothered to try uninstalling the VGA from one of my pre-286 machines.
I doubt that it comes with the development kit, so it's pretty useless
except to show that it works.
Eric
Umm... IIRC, Xenix was a unix implementation that
didn't even require
virtual memory, ran on x86 architectures (386?) and required very
little memory; certainly much less than Win96 since Xenix was
available in 1986.
Early Xenix ran on a 286. I don't think it ever ran on anything
less.
9:50 p.m.
On Wed, 7 Nov 2007, Eric J Korpela wrote:
I have, in my posession, a disk set for 8086 Xenix. I
have not
attempted to boot it as the accompanying scribbled note indicate that
it won't work on a machine with a VGA installed, and I haven't
bothered to try uninstalling the VGA from one of my pre-286 machines.
I doubt that it comes with the development kit, so it's pretty useless
except to show that it works.
I HAD development kit for it - half a dozen additional slipcase binders.
College administrators seem to get joy out of discarding irreplaceable
stuff.
5:47 p.m.
On 2007-11-07 18:58, Richard wrote:
Sridhar Ayengar <ploopster at gmail.com>
writes:
We had it running on a Wyse 286 back in them days. Can't have had more than
one, maybe two megabytes of RAM.
,xtG
.tsooJ
--
John was addicted to placebos until I sent him to a homeless
shelter for a week and told him it was a rehab clinic.
--
Joost van de Griek
<http://www.jvdg.net/>
> On 7 Nov 2007 at 10:21, ajones wrote:
>> There was never a version of Linux, or UNIX in general, less bloated
>> than Windows 95.
Umm... IIRC, Xenix was a unix implementation that didn't even require
virtual memory, ran on x86 architectures (386?) and required very
little memory; certainly much less than Win96 since Xenix was
available in 1986.
6:01 p.m.
On 7 Nov 2007 at 23:47, Joost van de Griek wrote:
We had it running on a Wyse 286 back in them days.
Can't have had more than
one, maybe two megabytes of RAM.
I still have Xenix for the Wyse 286, complete with the development
toolset. Very silly installation that would fail unless "WYSE" was
found in the BIOS. Simple enough to patch around.
Looks and runs like *nix. Nothing remarkable about it.
Cheers,
Chuck
3:43 p.m.
On 07/11/2007 17:48, Sridhar Ayengar wrote:
Me too. I have a PDP-11 here running UNIX with pre-emptive
multitasking, protected memory, TCP/IP, et al. It was common on VAXen
too. I also have a 486 laptop running slackware with a 2.4 kernel in
8M. It can run X, but I tend not to, as the display resolution is "not
high" and anyway I prefer text mode for the things I use it for (switch
setup, SNMP, tcpdump and wireless monitoring, mostly). It works well,
and certainly doesn't exhibit "a carnival of swapping".
--
Pete Peter Turnbull
Network Manager
University of York
On 7 Nov 2007
at 10:21, ajones wrote:
> There was never a version of Linux, or UNIX in general, less bloated
> than Windows 95. Windows 95 will very comfortably get you TCP/IP,
> protected memory, preemptive multitasking[1], and a graphical desktop
> on a 486 SX with 8M of RAM. Linux 2.0 with XF86 3.x was a carnival
> of swapping on that configuration. Solaris x86 wouldn't even boot.
You have to be very careful saying things like "never". I've had
TCP/IP, protected memory and preemptive multitasking on UNIX on machines
quite a bit smaller than 8MB. Including an X GUI. 
7:22 p.m.
On Wed, 2007-11-07 at 20:43 +0000, Pete Turnbull wrote:
too. I also have a 486 laptop running slackware with
a 2.4 kernel in
8M. It can run X, but I tend not to, as the display resolution is "not
high" and anyway I prefer text mode for the things I use it for (switch
setup, SNMP, tcpdump and wireless monitoring, mostly). It works well,
and certainly doesn't exhibit "a carnival of swapping".
I have a Toshiba Libretto 70CT (which probably is marginally on-topic -
it's got to be close to 10 years old, and even if it is a PC it's an
interesting one). I run NetBSD on it, and it deals with X quite happily
in a whole whopping 32M of RAM.
Gordon
1 p.m.
In article <4731887A.23335.556A69B at cclist.sydex.com>,
"Chuck Guzis" <cclist at sydex.com> writes:
It's not the most secure setup in the
world, [...]
That's an understatement. Its not secured *at all*.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
12:53 p.m.
There was never a version of Linux, or UNIX in
general, less bloated
than Windows 95.
What have you been smoking? V7 ran on a flippin' PDP-11!
Windows 95 will very comfortably get you TCP/IP,
protected memory,
preemptive multitasking[1], and a graphical desktop on a 486 SX with
8M of RAM.
I'd hesitate to apply "comfortably" to anything Windows. That aside,
older Unix variants would do the same on other hardware with similar or
lower amounts of RAM. Ultrix. Real BSD - the kind you got from
UCBerkeley. Depending on how liberal your definition of "UNIX" is, QNX
may even count.
If Windows 3.1 was the last nail in the coffin for
UNIX on the
desktop, Windows 95 was the last shovel of dirt and the weepy obit.
It's an awfully lively zombie, then. I run nothing but Unix variants.
So do a few of my work colleagues. A bunch more dual-boot Windows and
something Unixy, or run one on a virtual machine under the other.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
2:48 p.m.
If Windows 3.1 was the last nail in the coffin for
UNIX on the desktop,
Windows 95 was the last shovel of dirt and the weepy obit.
*cough*OS X*cough*
--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com
-- Nasty habits/Here to stay! -- Oingo Boingo ---------------------------------
7:48 p.m.
On Wed, 7 Nov 2007, ajones wrote:
There was never a version of Linux, or UNIX in
general, less bloated
than Windows 95.
Xenix ran on an 8088 XT with 640K. The IBM XT hard disk controller could
be jumpered (undocumented) to handle other sizes of drives other than the
412 (10MB). One of those sizes was 26MB, which was just right for a 10MB
DOS partition and a 16MB Xenix partition (that was how I found out about
the XT hard disk controller's undocumented jumper solder pads)
[1] Yes, Windows 95 had memory protection and
preemptive multitasking.
Are there multiple definitions of "preemptive"?
Or, is "preemptive" a quantitative, rather than qualitative attribute?
I would not consider Win95, nor early Mac, to be "preemptive". Even NT4,
which is purportedly preemptive has a few two many situations where/when
it can not be preempted. For example, when opening a telnet session, it
often can NOT be preempted until it gets to the point of success or failure.
8 Nov
8 Nov
7:11 a.m.
On Wed, Nov 07, 2007 at 04:48:04PM -0800, Fred Cisin wrote:
On Wed, 7 Nov 2007, ajones wrote:
Old MacOS (before MacOS X) was cooperative multitasking. As was 16 bit
Windows. Not sure about Windows95, but I guess at best it was probably a
nasty mixed bag.
There was never a version of Linux, or UNIX in
general, less bloated
than Windows 95.
Xenix ran on an 8088 XT with 640K. The IBM XT hard disk controller could
be jumpered (undocumented) to handle other sizes of drives other than the
412 (10MB). One of those sizes was 26MB, which was just right for a 10MB
DOS partition and a 16MB Xenix partition (that was how I found out about
the XT hard disk controller's undocumented jumper solder pads)
[1] Yes, Windows 95 had memory protection and
preemptive multitasking.
Are there multiple definitions of "preemptive"?
Or, is "preemptive" a quantitative, rather than qualitative attribute?
I would not consider Win95, nor early Mac, to be "preemptive". Even NT4,
which is purportedly preemptive has a few two many situations where/when
it can not be preempted. For example, when opening a telnet session, it
often can NOT be preempted until it gets to the point of success or failure.
The last time I had to touch NT4 is almost a year ago, but I do not
remember the system grinding to a stop when opening a telnet connection.
'Can not be preempted' means 'no other process gets to run' - and I have
a very hard time believing that to be the case for establishing a TCP
connection. My personal impression of NT (in part formed by having to
program IPC related stuff against the Win32 API) was that deep down, NT
is a pretty decent OS, it just got bogged down by stupid ideas tacked on
later and buried under a mountain of crap piled on by Microsofts less
talented hacks. I'm talking about the kernel, not the userland, mind
you - because the user environment is a total desaster in my personal
opinion (which admittedly is shaded heavily by being a unix zealot who
basically considers X to be a pretty nice environment to run plenty of
xterms in).
The basic kernel level design looks pretty good and caused quite a sense
of dejavu for me[0] - no surprise when one considers who did the original
design. And I distinctly remember the scheduler to be preemptive.
(Yes, there were plenty of silly ideas later - like moving the GUI code
into kernel mode for speeds sake ... *sigh*).
Regards,
Alex.
[0] Heaving read up on VMS internals only months before.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
8:28 a.m.
Not sure about Windows95, but I guess at best it was
probably a
nasty mixed bag.
Windows 95 was capable of preemptive multitasking in theory. In practice,
the USER/GDI subsystem was still 16-bit and access to it was serialized and
shared between both 16-bit and 32-bit tasks, meaning a single 16-bit task
would effectively degrade the system to cooperative multitasking as the
16-bit task could not be forced to yield control in these critical sections.
The WoW Win16 system used in NT and modern Windows finally solved this
problem.
Even NT4,
which is purportedly preemptive has a few two many situations where/when
it can not be preempted. For example, when opening a telnet session, it
often can NOT be preempted until it gets to the point of success or failure.
The last time I had to touch NT4 is almost a year ago, but I do not
remember the system grinding to a stop when opening a telnet connection.
6100
days inactive
6103
days old
54 comments
26 participants
participants (26)
-
aijones2＠bsu.edu -
aliensrcooluk＠yahoo.co.uk -
als＠thangorodrim.de -
andyh＠andyh-rayleigh.freeserve.co.uk -
ard＠p850ug1.demon.co.uk -
bfranchuk＠jetnet.ab.ca -
cc＠corti-net.de -
cclist＠sydex.com -
cisin＠xenosoft.com -
classiccmp＠memory-alpha.org.uk -
dgriffi＠cs.csubak.edu -
doc＠mdrconsult.com -
ethan.dicks＠usap.gov -
gordonjcp＠gjcp.net -
julesrichardsonuk＠yahoo.co.uk -
jvdg＠sparcpark.net -
korpela＠ssl.berkeley.edu -
legalize＠xmission.com -
mloewen＠cpumagic.scol.pa.us -
mouse＠Rodents.Montreal.QC.CA -
pcw＠mesanet.com -
pete＠dunnington.plus.com -
ploopster＠gmail.com -
rtellason＠verizon.net -
spectre＠floodgap.com -
trixter＠oldskool.org