Hello,
does anybody have information/source code/anything about the
Zilog Zeus System? It is a System III Unix derivate running
on a Z8001 16bit CPU. I'm looking for more infos on that.
Thanks,
Matt
bpope at wordstock.com (Bryan Pope) wrote:
> > If you can stand hearing 1070Hz, 1270Hz, 2025Hz, and 2225Hz tones,
> > and you're not making too much noise, howzbout: implement Bell 103
> > with modems with microphones and speakers, and just skip the whole
> > interconnecting wire business (...)
>
> I think the cat(s) would take issue with that and proceed to destroy
> the cause of said tones...
That would probably be an issue even with the ultrasonic setup, ISTR that there were "cat chasers" in the market which issued ultrasound when something entered the detection area of an IR sensor to prevent the fuzzball from going in places where it shouldn't (e.g. near expensive furniture).
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
> > > It shouldn't be too hard to use a C/L phone as the wireless link=20
> > > between two modems.
> >
> > I'd be very interested in such an arrangement, but I have the
> > suspicion that there will be no convenient location in the handset's
> > circuitry to interface a phone line to.
>
> I suspect if you use 'classic' modems (300 baud, 1200/75, etc), then
> it'll e totally trivial if you can also modify the modem. After all,
> there are separate Tx and Rx signals inside the modem unit.
Yes, but what about the levels? Phone line vs. capsule mic/handset speaker?
> > For the DECT system anyway, there are things called "cordless phone
> > sockets"; they aren't really cordless as they need a wall wart, but
> > they are learned to the base station like a new handset is and present
>
> Mains is not a problem , given that many of my classic computers also
> need it ;-)
First of all sorry, I learnt that the correct term is "cordless phone jack".
Okay, the whole connection setup would look like that:
Comp1 === Modem --- CTJ ))) DECT Base ))) CTJ --- Modem === Comp2.
=== is RS232, --- is phone line, ))) is DECT transmission.
I don't know if that fits your needs, as the modems will probably require some handshaking and they must be used to "dial" the connection (like from one line of a PBX to another). The cordless telephone jacks for the Gigaset DECT system are called "Gigaset 1000 TAE" (or, relabeled: "T-Sinus STA") in Germany, but those have the German TAE-style phone jack.
Searching for "DECT cordless telephone jack" should bring up some hits. Beware that some types seem to be trying to be too smart already, I read a manual for a system by TIPTEL where you have to set a switch for fax/modem operation on the telephone jack and the thing emits some sort of negotiation burst ("a short hissing noise") upon pickup when in this mode.
Depending on the type, your modem may even need to generate a flash or ground flash signal to put the CTJ into internal dialling mode (don't seize the line at the base station, but ring up another CTJ/handset). With the Gigaset/T-Sinus part you make the distinction by dialling either 0 for external or 9 for internal before the number.
> > I see it's hard to make do without permanent cabling, but the ports
> > shouldn't be such a problem. You could just run two links into each
> > room where
>
> So I wait for my parents to go out, when they get back they see DB25
> sockets on the walls of most of the rooms :-).
Asking beforehand helps a lot I would think ;) At our house, I use every chance when wiring is touched to bring Cat5, RG58 and 2-4 pairs of undedicated copper to pretty much every room - the coax for 10b2 or CCTV, the copper for RS-232, audio, IR-remote-by-proxy, phone or whatever future needs arise.
> If the 2 machines are next to each other, I might just run a null-modem
> cable between them ;-)
I was well aware of that option :) but two links would, for example, enable you to connect two machines which are in the same room, but need protocol analysis or conversion between them done by a third device in a second room.
Cheers,
Arno
--
Arno Kletzander
Student Assistant // Studentische Hilfskraft
Informatik Sammlung Erlangen
www.iser.uni-erlangen.de
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal f?r Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
I hope the person that invented them is burning in Hell right now.
Right next to the people who think it's OK to pack something with
them, and not BAG the object, so that you end up with shredded
static-charged peanut bits in every inacessable crevice of the object.
> Date: Thu, 08 May 2008 10:18:12 -0600
> From: Richard
> This isn't the first time someone has made a slam on packing peanuts,
> yet I've had plenty of things sent and recieved with peanuts and had
> no problems. I think the key is to not just dump the peanuts into the
> container, but to physically compress them into the box. The flaps of
> the box should require some pressure to fully close around the item.
> If done properly, peanuts will not leave a loose void for things to
> wiggle around inside.
I'll use peanuts to make a "pillow", placing them inside a sealed
bag, but never for protecting big or heavy equipment. For that, I
use the sheet polystyrene insulation foam sold at home-improvement
stores.
Above all, I've found that if enough rigid foam is used to prevent
the item inside from moving, supporting it on all sides, it most
often makes it to its destination without the slightest bit of
damage, even through UPS ground.
All bets are off, however, if the box gets run over by a forklift, or
falls off the conveyor belt while the aircraft is being loaded. I've
seen both.
Obviously, if there's some loose item in the equipment that will flop
around with mechanical shock, it's better to secure it or remove it
for separate packaging. I'm not beyond unsoldering wires in order to
secure something for shipping if necessary. In my experience, floppy
drives, particularly 8" drives, are best shipped with a cardboard
insert in place of a diskette and the door mechanism secured with a
cable tie. A lot of older hard disks had shipping bolts that could be
installed to keep things from moving around with mechanical shock.
For the last mile, it pays to be on good terms with your regular
UPS/FedEx driver.
Cheers,
Chuck
Richard writes:
> This isn't the first time someone has made a slam on packing peanuts,
> yet I've had plenty of things sent and recieved with peanuts and had
> no problems. I think the key is to not just dump the peanuts into the
> container, but to physically compress them into the box. The flaps of
> the box should require some pressure to fully close around the item.
> If done properly, peanuts will not leave a loose void for things to
> wiggle around inside.
I think your comments are perfectly valid for the sorts of things
that ship well with peanuts. There's even different types of peanuts
that work well for different densities of items etc.
But they do not work well for dense, heavy items with protrusions
that have to be protected. Foam-in-place has a real advantage in
keeping the object centered in the middle of the box - compressed
peanuts work sometimes but foam-in-place works all the time. And some
"handcrafting" with custom wooden or cardboard corner protectors,
bubble wrap of appropriate type (some times are best for lightweight
items and others will stand the abuse of heavy items) cleverly applied,
or even newspaper/kraft paper PROPERLY used
can do a remarkable job making sure that it's not the protrusions
or corners that hit the edge of the box.
It's not so much the peanuts I'm opposed to, they are valuable and
sometimes appropriate tools. It's the attitude that throwing a
70 pound, very dense instrument with fragile protrusions into
a cardboard box with peanuts around it is the best or only thing
that can be done.
What's astonishing is that 80% of the time when an instrument
was damaged in transit, it was packaged by the "UPS store"
or equivalent. You'd think that since they're charging for their
services they might actually use UPS-recommended supplies
and techniques, but they don't!
Tim.
>
>Subject: RE: Minimal CP-M SBC design
> From: "Andrew Lynch" <lynchaj at yahoo.com>
> Date: Wed, 07 May 2008 20:35:10 -0400
> To: <cctalk at classiccmp.org>
>
>
>Hi Andrew,
>
>Just sitting here wondering why you're not using one of the enhanced-
>functioning Z80 chips. Even going with the 64180 or Z180 would give
>you 2 UARTS and an MMU, in addtion to 2 DMA channels and a timer.
>Later version of this product line, will of course, give you more
>instructions and functionality.
>
>But the MMU can make the whole process of bootup very easy. Simply
>use the MMU to map the ROM out after the system's been started
>(you've got a 1MB physical address space). Duck soup.
I can make the boot process easier as you can plop the rom in
mappable space. The usual arguement is can you get a Z180
in a package most people are willing to deal with (64pin dip)?
Of course the there is a fast Z180 (33mhz) for those that really
want speed.
>But if you want to stick with the "real" Z80, I've seen two methods
>of getting around the reset to 0000.
>
>The first is to simply force three bytes onto the system bus to
>perform a jump to whatever address you desire after a reset. You'll
>only do this once per reset, so the circuitry's pretty simple.
>
>Another way to is to start out with an EPROM mapped in and then
>disable it using an I/O instruction. You can leave RAM mapped in for
>write cycles, so that only reads will come from the ROM and writes
>will go directly to RAM. That way, you can set up locations starting
>at 0000 from a ROM.
The latter is the shadow rom many have refered to. I usualy do that.
And make the rom BIG so not only can I map it in when I want but also
access part of it (ROMDRIVE).
>In any case, the ROM needn't be very big. I think Don Tarbell used a
>little bipolar 82S123 PROM. Gives you 32 bytes to do what you need,
>which, in Don's case was enough to get the first sector of an 8"
>floppy read.
Maybe but in this day and age a 27C256 makes more sense and you can
put the whole system image there and have room left over for a debug
monitor. There is no requriement to boot the system from "disk"
and making that change can make bring up simpler.
>
>CP/M BIOSes for 2.2 and below are easy--they're poll-mode with
>clearly described inputs and outputs. About the only thing you may
>find confusing is the IOBYTE convention, but that's optional and
>fairly well documented.
IO byte is mostly useful fo when you have moer IO that a console
and printer. It's pretty trivial to implement.
>>I've written a CP/M BIOS without resorting to assembly, doing the
>whole thing in machine code. It's not a big thing and you can start
>with the basic set of disk and console I/O routines. There are two
>boot entry points in the BIOS jump vector--the "cold start" entered
>by a jump to 0000 that (re)loads the entire CP/M BDOS and CCP, and
>the "warm start" that simply reloads the CCP.
And sources are already on the net for many examples.
>Disk I/O is done in 128 byte "sectors", so if your physical sectors
>are longer than that, you'll need to set up blocking and deblocking
>routines.
>
>All of this is covered in the CP/M System Alteration guide in pretty
>fair detail, along with a couple of samples.
Deblocking is not too mysterious. The real missing bit in the
Alteraion guide is how the BDOS telegraphs the need to preread
and when to skip it.
Allison
>
>CP/M 3.0 or MP/M is more involved, taking advantage of bankswitching.
>Interrupt-driven I/O is required for MP/M--and the I/O system is
>more elaborate.
>
>Cheers,
>Chuck
>
>-----REPLY-----
>
>Hi Chuck,
>
>Sorry it took me so long to reply.
>
>There is no good reason as to why my computer is designed the way it is. I
>just sat down one day and decided to build a Z80 computer.
>
>I got a book at the library and did a few Google searches and the next thing
>you know I was soldering some parts into a prototype board on my bench. It
>went through several interations until I ended up with this design.
>
>The Z80 is definitely the classic although Zilog makes some much improved
>integrated components. Using them would have made life much easier I
>suppose but I wasn't aware of them when I started.
>
>I definitely wanted to avoid the hard to build technologies like SMT or hard
>to get parts or unique programmable parts like PALs, GALs, CPLDs, or FPGAs.
>
>Why? Just because. I could have used those components but in my estimation
>they take something away from the "feel" or nostalgia or some other
>intangible quality. I am sure Tony probably knows what I am talking about.
>;-) I am not sure I do...
>
>One goal was to make the design easy and cheap so that others could make the
>project too and keep it affordable. That pretty much eliminated all the
>really modern stuff.
>
>I did consider PLCC packaging for a bit since it uses 0.1" spaced pins but
>decided to stick with plain old DIP chips since they are easier to work with
>and test. Yes, PCB density suffers terribly but there is absolutely nothing
>practical about this project in the least :-) Why start now?
>
>Anyway, I am nearing completion of the PCB build process. Last night I got
>the machine to boot CP/M from the EPROM. Now it can recognise the ROM and
>RAM drives as block devices.
>
>Allison was a huge help in many of the SBC design aspects and I owe her a
>debt of gratitude.
>
>Thanks and have a nice day!
>
>Andrew Lynch
>
I have a DEC server (PC) with a 486 running Interactive Unix and I cant
seem to find a way in to change root Password. Any one have a boot disk
or better yet a full set of disks.
- jerry
Jerry Wright
JLC inc
g-wright at att.net
> Message: 17
> Date: Tue, 6 May 2008 23:03:50 +0100 (BST)
> From: ard at p850ug1.demon.co.uk (Tony Duell)
> Subject: Re: Interconnecting classic computers
> To: cctalk at classiccmp.org
> Message-ID: <m1JtVGL-000J3OC at p850ug1>
> Content-Type: text/plain
>
> >
> > Eric Smith wrote:
> > > Fred wrote:
> > >> If we are going to discuss the WORST systems, surely we can't leave out
> > >> the TRS80 casstte port system that RS came up with for classrooms!
> > >
> > > Well, don't leave us in suspense. In what way was it done badly?
> > > Was it unreliable? Did it fail to meet its design objectives?
> > >
> > >
> >
> > Our school system had one, back in 1981.
> >
> > There was a panel that was a mux/demux to 24-ish diskless model 3s. The
>
> I thought the standard one was for 16 slaves to one host, but there's no
> reason for that limit.
Sixteen student machines to one instructor station is correct.
> I seem to rememebr the same hardware could be used with Model 1s, Model 3s
> and Cocos, but that the host and slaves had to e the same type of machine.
The first version, the Network 1, was limited to the 500 bps data rate of the Model One interface. Model Ones could be combined with Model 3s and Model 4s, provided the users of the newer machines specified the slow cassette data rate. The Network 2 supported the 1500 bps rate of the Model 3 and 4, the Color Computer line (including the MC-10) and the Model 100/200. 3s and 4s could be mixed at will, all versions of the Color Computer line could co-exist (except the MC-10 -- although the MC-10 used the same data format as the other Color Computers, the BASIC ROM tokenized the keywords in its own unique way, so any BASIC code exchanged would be garbage). The 100 and 200 could be intermixed. I recall hearing about somebody using a Model 4 with its Mod 100 exchange utility getting that combination to work, but I never tried it myself.
The Network 1 and 2 were actually rather clever devices for the era. Never gave me a bit of trouble in my classrooms except when some of the students forgot to select the slow speed on their Mod 3s (my first year as an RSCC instructor [starting 2 Nov 1980], the classroom was full of Mod 3s, except of course for the instructor's system).
--
Ward Griffiths wdg3rd at comcast.net
These histrionics were probably unnecessary, since there was no reason to think anybody would be watching us with more than casual interest until I made my first move to follow Buchanon's trail, in London. Still, somebody might check back this far later, and I always feel that if you're going to play a part, you might as well play it all the way, at least in public -- and it's hard to tell what's public and what isn't, these electronic days.
Donald Hamilton, _The Devastators_, 1965
Hi Andrew,
Just sitting here wondering why you're not using one of the enhanced-
functioning Z80 chips. Even going with the 64180 or Z180 would give
you 2 UARTS and an MMU, in addtion to 2 DMA channels and a timer.
Later version of this product line, will of course, give you more
instructions and functionality.
But the MMU can make the whole process of bootup very easy. Simply
use the MMU to map the ROM out after the system's been started
(you've got a 1MB physical address space). Duck soup.
But if you want to stick with the "real" Z80, I've seen two methods
of getting around the reset to 0000.
The first is to simply force three bytes onto the system bus to
perform a jump to whatever address you desire after a reset. You'll
only do this once per reset, so the circuitry's pretty simple.
Another way to is to start out with an EPROM mapped in and then
disable it using an I/O instruction. You can leave RAM mapped in for
write cycles, so that only reads will come from the ROM and writes
will go directly to RAM. That way, you can set up locations starting
at 0000 from a ROM.
In any case, the ROM needn't be very big. I think Don Tarbell used a
little bipolar 82S123 PROM. Gives you 32 bytes to do what you need,
which, in Don's case was enough to get the first sector of an 8"
floppy read.
CP/M BIOSes for 2.2 and below are easy--they're poll-mode with
clearly described inputs and outputs. About the only thing you may
find confusing is the IOBYTE convention, but that's optional and
fairly well documented.
I've written a CP/M BIOS without resorting to assembly, doing the
whole thing in machine code. It's not a big thing and you can start
with the basic set of disk and console I/O routines. There are two
boot entry points in the BIOS jump vector--the "cold start" entered
by a jump to 0000 that (re)loads the entire CP/M BDOS and CCP, and
the "warm start" that simply reloads the CCP.
Disk I/O is done in 128 byte "sectors", so if your physical sectors
are longer than that, you'll need to set up blocking and deblocking
routines.
All of this is covered in the CP/M System Alteration guide in pretty
fair detail, along with a couple of samples.
CP/M 3.0 or MP/M is more involved, taking advantage of bankswitching.
Interrupt-driven I/O is required for MP/M--and the I/O system is
more elaborate.
Cheers,
Chuck
-----REPLY-----
Hi Chuck,
Sorry it took me so long to reply.
There is no good reason as to why my computer is designed the way it is. I
just sat down one day and decided to build a Z80 computer.
I got a book at the library and did a few Google searches and the next thing
you know I was soldering some parts into a prototype board on my bench. It
went through several interations until I ended up with this design.
The Z80 is definitely the classic although Zilog makes some much improved
integrated components. Using them would have made life much easier I
suppose but I wasn't aware of them when I started.
I definitely wanted to avoid the hard to build technologies like SMT or hard
to get parts or unique programmable parts like PALs, GALs, CPLDs, or FPGAs.
Why? Just because. I could have used those components but in my estimation
they take something away from the "feel" or nostalgia or some other
intangible quality. I am sure Tony probably knows what I am talking about.
;-) I am not sure I do...
One goal was to make the design easy and cheap so that others could make the
project too and keep it affordable. That pretty much eliminated all the
really modern stuff.
I did consider PLCC packaging for a bit since it uses 0.1" spaced pins but
decided to stick with plain old DIP chips since they are easier to work with
and test. Yes, PCB density suffers terribly but there is absolutely nothing
practical about this project in the least :-) Why start now?
Anyway, I am nearing completion of the PCB build process. Last night I got
the machine to boot CP/M from the EPROM. Now it can recognise the ROM and
RAM drives as block devices.
Allison was a huge help in many of the SBC design aspects and I owe her a
debt of gratitude.
Thanks and have a nice day!
Andrew Lynch
