-----Original Message-----
From: cctalk-bounces at classiccmp.org
[mailto:cctalk-bounces at classiccmp.org] On Behalf Of Jeff Jonas
Sent: Wednesday, May 07, 2008 4:23 PM
To: cctech
Subject: Re: Minimal CP-M SBC design
I'm slow to enter the discussion because I'm still
busy sorting my z80 parts and single board systems
instead of enjoying them :-(
I'm of 2 minds regarding the Z80:
The "classic" vs. the "embedded" mind-set.
The embedded solution:
I have a Zilog 50 MHz eZ80 development board with more built-in features
that I may ever use: ethernet, InfraRed,
a LOT of flash and static RAM.
My frustration is the lack of support and community activity
despite some high profile contests using the board.
A clever fellow made an expansion board that adds
2 compact flash slots so it runs CP/M really fast!
That appeals to me since it allows it to run stand-alone
even for editing, storing and compiling applications.
And there's still the programming/debugging pod
for using a host system to debug the system
should it require external assistance.
Back to the original query:
the Zilog ez80 board may be appealing because
- it's fast (50MHz) and has a lot built in:
MMU, RAM, flash ROM, serial and ethernet ports.
- allows much more powerful tools on the host system
for source control, compilers, debugging via the pod.
- others are using it too
The classic side:
My first "at home" computer was a Servo-8 single board computer
(6 MHz Z80B, 64k ram, 2 serial ports, parallel port, SASI port).
I chose that over the 4 MHz Z80A Ampro Littleboard.
It cost about $500 (with CP/M and schematics)
so I was really hesitant to interface it to my own things
until I had some experience with cheaper Z80 systems
(particularly since all the parts were soldered in!)
Long long ago I breadboarded a 4 MHz z80a with 10K static RAM
(intending to use battery backup).
I originally intended to use a front panel of
LEDs and toggle switches (inspired by the Altair).
I gave that up while wiring up all the switches,
and instead used a Timex Sinclair 1000 as the front panel
(hey, a keyboard and display!) to the dual-port static RAM.
(the Timex is a complete Z80 system with just 4 chips:
z80 CPU, ROM, RAM and Programmable Logic Array for the rest).
I still want to use discrete Z80 chips because
- I have a logic analyzer to watch it run
(I've disassembled some embedded z80 terminals using it)
- I like the way the Z80 family chips interface so directly,
even for vectored interrupt mode.
- I still want to explore "clever" tricks for memory management such as
. using the "M" line to differentiate instruction from data reads
. implementing true "cycle stealing"
(access to memory not currently active by the CPU).
I salvaged many z80 based devices (terminals, modems, terminal servers)
and pondered reverse engineering them to reprogram for my own uses.
Perhaps I'm too impatient but it seemed easier to just
start from scratch, or buy a single board system and work from there.
I suspect I'll finally get brave enough to just interface
the additional Z80 chips to the Servo-8 Z80B SBC
since I like that more than the ez80 (so far).
Jeffrey Jonas
e-mail: jeffj at panix.com
-----REPLY-----
Jeff,
I am building a Z80 SBC as mentioned previously. If you want to add the
Z80 peripherals to a Z80 based SBC, have you considered just building an
ECB peripheral card?
My Z80 SBC design is based on the ECB bus and supports its optional use.
Maybe the best approach is to build of my SBCs and the ECB backplane and
you design the peripheral card to go along with it.
The Z80 SBC now only supports IO accesses on the ECB. I may extend the
design in the next version to allow full memory accesses across the ECB
for the next SBC design but so far I don't see much use in it since the
SBC already includes 1MB EPROM and 512K SRAM. The ECB pin out is the
same but the control logic of the SBC would have to change.
In addition, the Z80 SBC supports a IEI/IEO lines on the ECB including a
2200 ohm pull up resistor. The Z80 SBC supports the Z80 open drain /INT
line directly to the ECB coupled with a 2N2222 TO-18 transistor to drive
it. So far the only device attached to the Z80 /INT line is the 16550
UART. None of the current software uses the /INT line yet since I
implemented everything in polling mode only.
Maybe this is an opportunity to collaborate? A Z80 PIO/DART board
probably wouldn't be too difficult to implement on ECB. Check my
website if you are interested. I am using KiCad for EDA which is free
software.
Please let me know if interested. Thanks!
Andrew Lynch
Here's a representative lot:
<http://cgi.govliquidation.com/auction/view?id=1686038&convertTo=USD>
They have descriptions like "General Dynamics signal processor adapter
assembly" and they all look like circuit boards with a regular grid
and an arrangements of pins placed into the grids. The grids are
divided into areas and sometimes color coded. Does anyone have any
familiarity with them? There are a ton of these on govliq right now.
It seems to be some kind of test harness.
--
"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/>
> I picked up what I believe is a console from an Autonetics model D-37 Minuteman I missile guidance computer.
D-37 is a DTL computer for the Minuteman II.
There is some info and a picture on Wikipedia now
about it.
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
> Here's a representative lot:
> <http://cgi.govliquidation.com/auction/view?id=1686038&convertTo=USD>
>
> They have descriptions like "General Dynamics signal
> processor adapter
> assembly" and they all look like circuit boards with a
> regular grid
> and an arrangements of pins placed into the grids. The
> grids are
> divided into areas and sometimes color coded. Does anyone
> have any
> familiarity with them? There are a ton of these on govliq
> right now.
>
> It seems to be some kind of test harness.
The NSN hyperlink links to a page that identifies it as "AN/ALR-69 PECULIAR." The 4920 NSN prefix indicates that it's aircraft maintenance equipment. The AN/ALR-69 Radar Warning Receiver is used in a number of US military aircraft. If that's gold plating in the second photo from the left, these might have some significant recovered metal value.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
On Mon, 5 May 2008 20:55:51 +0100 (BST), Tony Duell wrote:
> [...]
> Quite often I need to transfer data between 2 machines. Maybe to
> download a file from this PC, which I've in turn downloaded from a web
> site, to run on one of the classics. Maybe to print out some listing
> from
> a classic. Whatever.
> [...]
>
> So, I think the problem reduces to 'how to interconnect RS232
> ports'. let
> me add some constraints :
>
Requirements as I understand them:
1
> Must work over a distance longer than the RS232 spec allows (i.e. the
> answer is probably not 'A long RS232 cable' :-)).
(see <http://www.lammertbies.nl/comm/info/RS-232_specs.html> for an
interesting discussion on cable lengths v.s. data rate - your data
rates spec'ed below indicate that this is not a problem...
2.
> Prefereably no cables at all. One solution I've come up with is to
> use a
> couple of line drivers and a long cable between them. A long cable
> that
> my parents, or the cat, will get tangled up in :-(
i.e. no cables hence 1 does not apply
3.
> No line-of-sight between the machines
This excludes optical means.
4.
> Must work at 300 and 1200 baud. 110 and 9600 baud would be a bonus
5.
> I only need one pair of machines linked at a time. I don't need a
> network. [...]
Point-to-point - collision avoidance not required.
6.
> Must not make use of any flow control lines on the RS232 port, since
> some
> of my machines don't support them.
7.
> Using classic, or at least repairable, hardwre is a bonus :-)
8.
> I said 'RS232'. I mean asynchronous serial, of course :-). [...]
9.
> I've been looking at some of the license-exempt radio modules, but
> they
> either are half-duplex or amke use of the flow control lines
> (typically
> they buffer <n> bytes internally, then de-assert a flow control line
> while they pack up that data and send it to the other end).
Does this mean that you require full-dupex?
-------
If 8 is required, you probably have to go with a dual channel, radio
link of some sort. Zigbee is definitely overkill based on 5. A simple
set of transceivers should do the trick. TI and others have parts and
reference designs. However, my experience has been disappointing in
enclosed and partitioned areas with these devices - at least at legal
power levels...
Item 7 makes me think X10. This is a classic data-over-power-line
method that has been around for good number of years. It is generally
used to control lights, sprinklers, intrusion alarms, etc. and uses a
simple protocol. However, it appears to be half-duplex. The info is
out there on the web.
You might want to look at ST's ST7540 and ST7538 which are current
power-line modems and should do what you want. A small micro to buffer
things will probably take care of 6.
Jules Richardson noted:
> Hmm, I've got a deep mistrust of any 'data over the mains'
> technology, but
> might that be an option here? I assume *most* of your systems are
> physically
> plugged into the mains anyway, so it'd meet the ideal requirement
> for no extra
> cabling. Data rates presumably not lightning fast, of course...
I don't think security is of concern here unless you are extremely
paranoid or are transferring prohibited material (e.g. perhaps with
your collection, ASCII kiddy porn to the impact printer :=P).
CRC
ard at p850ug1.demon.co.uk (Tony Duell) wrote:
> > Has anybody ever tried interfacing a modem to a cordless phone handset?
>
> Are cordless phones truely full-duplex, or are they more like
> loudspeaking phones whee a local voice input disables the speaker
> output?
> That is not a problem for voice, of course, but it is for full-duplex
> modems.
Every one I ever had in my hands was full-duplex, and we started with the analogue generation before we went to DECT. Cordless phones are fun anyway, I recently built a remote power controller for use with an analogue Siemens Megaset base station. (The base station in the ground floor, next to my father's desk, is powered all the time, "picking up" the handset energises a relay that switches on mains for our DSL modem and ethernet hub. Handset is next to my desktop PeeCee in the first floor and powered only when my desktop computer is on. The controller of course also has a local switch wired in parallel, for when my father wants to go online.)
> > It shouldn't be too hard to use a C/L phone as the wireless link
> > 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.
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 themselves to a phone/fax/modem/whatever like a phone line. Would love to get my hands on one of those one time.
> > I believe Tony also has a NetCommander which would let him select which
>
> Actually I have 3 of them. One is the 16 port model (with 16 RS232
> ports), the others are the fixed-configuration 6 RS232/4 Centronics
> models.
>
> But they do not solce the cabling problem. Nor do they have enough ports
> for all my classics...
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 you have machines (to a wall socket), then use temporary cables to connect just the machines on which you are working at the moment (either two in one room, or one in one room, one in another - therefore two links).
Cheers,
Arno
--
Arno Kletzander
Student Assistant // Studentische Hilfskraft
Informatik Sammlung Erlangen
www.iser.uni-erlangen.de
Psssst! Schon vom neuen GMX MultiMessenger geh?rt?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
Subject: Interconnecting classic computers
> Quite often I need to transfer data between 2 machines ...
> My machines vary in size from the pocket computers
> up to machines that it's not practical to move.
> They're scattered throughout a house.
> They are, alas, not in a machine room.
> Most of the machines (and all the ones I want to consider for this)
> have an RS232 port, either built-in or as an option (which I have).
> Most of the machines run kermit.
> Or I can simply print to the RS232 port on one machine
> and capture the incoming characters on the other
That's great: that solves the protocol issue and it's all RS232.
> So, I think the problem reduces to 'how to interconnect RS232 ports'.
> let me add some constraints :
> Must work over a distance longer than the RS232 spec allows
> (i.e. the answer is probably not 'A long RS232 cable' :-)).
> Prefereably no cables at all.
There are D-I-Y kits for that, and pre-made dongles
for wireless RS232 using bluetooth or Zigbee.
[I got the Circuit Cellar / Freescale Zigbee contest kit
but it failed to flash to the wireless modem program
that I needed for a project]
A "terminal server" puts RS232 ports on ethernet,
but I'm unsure if any have builtin WiFi (802.11)
or are easy to use via WiFi routers/repeaters.
[some are cheap on ebay: I have some but have not
gotten to try them. I used some at a previous assignment].
I saw wireless USB in a catalogue,
so perhaps a wireless USB to a USB-RS232 adapter might work?
I'm suspicious of the USB-RS232 adapters since many are not
8 bit compatible (I learned that the hard way
when one won't download to my PIC-18 development system).
[and most of the USB stuff I've handled lately works under Linux]
> One solution I've come up with is to use a couple of line drivers
> and a long cable between them. A long cable that my parents,
> or the cat, will get tangled up in :-(
You're just reinvented the "short haul modem":
a dongle that converts RS232 to stronger signals
to travel longer wires, such as RS485 (differential signalling).
BlackBox sells them for $$$:
http://www.blackbox.com/Catalog/Category.aspx?cid=381,1452,1465
That's why I snagged some fiber optic RS232 adapters:
boxes about the size of a pack of cigarettes that converts
RS232 to fiber optic (up to 1 km).
-- Jeffrey Jonas
Wireless ideas...
Serial-to-Bluetooth modules exist, but they're about $50 the each for
the bare module, which may be too pricey for a large configuration.
Duplex-ness shouldn't be too much of an issue, given a sufficiently
generous buffer.
Diamond MMC had an interesting card back in the 90's that provided
home networking by imposing an RF carrier on the telephone copper
pair. I've still got a couple of these cards and they work pretty
well. The box claims 10Mb/sec, but reality is more like 1Mb. Still
faster than a modem, however.
IR was pretty popular for a short time--you could even go around
corners if you aimed the transceivers right. It sounds as if Tony
just wants to go point-to-point, so there would be only a single
transmitter on at any one time.
Others have mentioned carrier-current setups, but unless they're
pretty sophisticated, low-bandwidth and error-prone. I've got a copy
of an article from an issue of the HP Journal back from the 80's,
where a spread-spectrum carrier current system is described in
detail.
I wonder if one could simply buy a carton or two of old 900MHz
cordless phones and jerry-rig something up? Come to think of it,
I've never even tried interfacing a regular modem to a cordless phone
handset. I wonder if it works...
Cheers,
Chuck
I'm slow to enter the discussion because I'm still
busy sorting my z80 parts and single board systems
instead of enjoying them :-(
I'm of 2 minds regarding the Z80:
The "classic" vs. the "embedded" mind-set.
The embedded solution:
I have a Zilog 50 MHz eZ80 development board with more built-in features
that I may ever use: ethernet, InfraRed,
a LOT of flash and static RAM.
My frustration is the lack of support and community activity
despite some high profile contests using the board.
A clever fellow made an expansion board that adds
2 compact flash slots so it runs CP/M really fast!
That appeals to me since it allows it to run stand-alone
even for editing, storing and compiling applications.
And there's still the programming/debugging pod
for using a host system to debug the system
should it require external assistance.
Back to the original query:
the Zilog ez80 board may be appealing because
- it's fast (50MHz) and has a lot built in:
MMU, RAM, flash ROM, serial and ethernet ports.
- allows much more powerful tools on the host system
for source control, compilers, debugging via the pod.
- others are using it too
The classic side:
My first "at home" computer was a Servo-8 single board computer
(6 MHz Z80B, 64k ram, 2 serial ports, parallel port, SASI port).
I chose that over the 4 MHz Z80A Ampro Littleboard.
It cost about $500 (with CP/M and schematics)
so I was really hesitant to interface it to my own things
until I had some experience with cheaper Z80 systems
(particularly since all the parts were soldered in!)
Long long ago I breadboarded a 4 MHz z80a with 10K static RAM
(intending to use battery backup).
I originally intended to use a front panel of
LEDs and toggle switches (inspired by the Altair).
I gave that up while wiring up all the switches,
and instead used a Timex Sinclair 1000 as the front panel
(hey, a keyboard and display!) to the dual-port static RAM.
(the Timex is a complete Z80 system with just 4 chips:
z80 CPU, ROM, RAM and Programmable Logic Array for the rest).
I still want to use discrete Z80 chips because
- I have a logic analyzer to watch it run
(I've disassembled some embedded z80 terminals using it)
- I like the way the Z80 family chips interface so directly,
even for vectored interrupt mode.
- I still want to explore "clever" tricks for memory management such as
. using the "M" line to differentiate instruction from data reads
. implementing true "cycle stealing"
(access to memory not currently active by the CPU).
I salvaged many z80 based devices (terminals, modems, terminal servers)
and pondered reverse engineering them to reprogram for my own uses.
Perhaps I'm too impatient but it seemed easier to just
start from scratch, or buy a single board system and work from there.
I suspect I'll finally get brave enough to just interface
the additional Z80 chips to the Servo-8 Z80B SBC
since I like that more than the ez80 (so far).
Jeffrey Jonas
e-mail: jeffj at panix.com
>If I plug this hypothetical "just works" serial-to-Ethernet box onto
>a serial port on an old computer, and plug the ethernet into the
>switch along with my desktop computer, laptop, and wireless router,
>what exactly should the box do? And what should I, as the user, do?
RCPMs used a version of XMODEM which worked over the same port as the
console. You would tpye xmodem s/r (send or recieve) and a file name.
XMODEM would then use the console port to upload and download the file.
You would need a xmodem version for the pc which would support a common
protocol.
On Tue, 06 May 2008 07:53:52 -0500 Jules Richardson wrote:
>> Jules Richardson noted:
>>
>>> Hmm, I've got a deep mistrust of any 'data over the mains'
>>> technology, but
>>> might that be an option here? I assume *most* of your systems are
>>> physically
>>> plugged into the mains anyway, so it'd meet the ideal requirement
>>> for no extra
>>> cabling. Data rates presumably not lightning fast, of course...
>>
>> I don't think security is of concern here unless you are extremely
>> paranoid or are transferring prohibited material [...].
>
> Ahh, no - on that note I meant 'mistrust' as in reliability. Running
> data over
> power lines always seems like the sort of thing that'd work in the
> lab, but be
> a little unreliable out in the real world with all sorts of 'noisy'
> devices
> plugged into the system.
> [...]
Actually the X10 home automation system is quite reliable as its
longevity attests. Currently, broadband over power is being deployed
in a number of test cities in the US (much to the chagrin of Hams - it
tends to raise the noise floor in ham bands excessively) and the usual
suspects are peddling home networking over the mains (e.g. <http://www.dlink.com/products/?sec=1&pid=561d
>).
To get around the noise issue, these systems use burst transmission at
the zero voltage crossing point when line noise is statistically the
least.
As I mentioned previously, a number of folks make transceivers for
this purpose. Echelon <www.echelon.com> has made their entire business
based on this technology used mainly in commercial applications. <http://www.powerlinenetworking.co.uk/component/option,com_frontpage/Itemid,…
> is a UK firm pushing the technology locally.
IC transceivers are available from ST, Maxim, and SiConnect. The
addition of a small micro to do the RS232, support logic, and power
supply should make a useable system meeting Tony's requirements.
CRC
Has anybody ever tried interfacing a modem to a cordless phone handset?
It shouldn't be too hard to use a C/L phone as the wireless link between two
modems.
I believe Tony also has a NetCommander which would let him select which
remote system to connect to and, with a few SS relays, even remotely turn
the selected system power on and off.
m