On 9/18/2008 01:04 PM, cctech-request at classiccmp.org wrote:
>Date: Wed, 17 Sep 2008 11:21:02 -0400
>From: Paul Koning <Paul_Koning at Dell.com>
>Subject: Re: OS/2 Warp, was Re: PCjr Telnet Server Test - Done!
>To: cctalk at classiccmp.org
>Message-ID: <18641.8286.275784.301355 at gargle.gargle.HOWL>
>Content-Type: text/plain; charset=us-ascii
>
> >>>>> "Ethan" == Ethan Dicks <ethan.dicks at usap.gov> writes:
>
> Ethan> Back when NIC weren't $10 each, I remember the easiest to work
> Ethan> with (in terms of compatibility) were the NE2000 and clones
> Ethan> (NE1000 for 8-bit machines), the WD (later SMC) 8013, and the
> Ethan> 3C501, later displaced by the 3C509. ...
>
>Something to keep in mind is that the 3C501 is an extremely bad
>design. It is completely incapable of dealing with back to back
>packets -- even just two of them. And of course that's a perfectly
>normal situation in any plausible network.
>
>I remember working on DECnet when these toys came around, and the
>request came in to have a "go slow" feature in DECnet to support this
>single buffered design. The answer, of course, was "NFW". (Slowing
>down at the source wouldn't have helped because the network could
>easily cause clumping anyway...)
>
> paul
The problem with the 3C501 (and the InterLAN and Ungermann-Bass, and
other I've forgotten about) Ethernet cards of this era where that
they only had one packet of memory on them.
Once a packet was received, you had to wait until software retrieved
the packet and re-enabled the card, before you could get the
next. Likewise if you wanted to transmit - you had to disable
reception, copy the transmit packet into the card, and then send
it. In PCs of that era that was a substantial chunk of time
relative to the potential arrival rate of 10Mbs Ethernet.
I have a presentation I have given at DECUS, where I analyzed (on
paper) what the likely best possible rates for an XT or PC-AT would
be. I should scan that in. (highly unlikely I have a machine
readably copy! wonder what I prepped that in?)
NetWare and NetBEUI driven networks hardly noticed this problem for
two reasons: 1) they were Request/Response protocols. They normally
did not expect additional packets until they responded, and 2) they
were talking to other PCs. Which simply couldn't generate traffic fast enough.
With respect to DECnet, the problem came up quickly when we started
having PCs make requests from PDP-11 or VAX file servers, using
either FAL or the PathWorks server. When pushing data the mini
computer could quickly over run the slow PC with a dumb Ethernet
card. The rest of the world noticed when TCP/IP implementations got
good enough to encounter similar problems with FTP pulls, and PC file
servers finally got enough aggregate clients.
The workaround in DECnet-DOS was a careful tuning of the buffer pool,
and the transport (NSP) credit flow control window algorithms. The
delayed-ack mechanism was optionally tweaked to send an ACK
immediately upon receiving a packet ahead of the expected next. This
typically indicated a lost packet, and usually generated an immediate
retransmit.
The VAXmate and PCs using the DEPCA card would run rings around these
other cards. Because they used the AMD LANCE Ethernet chip with
multiple packet buffers in a mapped memory buffer. The DECnet-DOS
kernel optimized this by using it directly for it's buffer pool and
removing the need for another memory to memory packet copy.
With all due respect Paul, I've never asked another DECnet
implementation to "slow down", certainly not DECnet-RSTS. But don't
get me started on the VMS implementation of async DDCMP.
Dave (Mr. DECnet-DOS)
comcast digital voice still permits you to make dialup modem calls
>from what i understand, im guessing some VOIP providers may work as
well, since CDV is VOIP, so it may work.
http://www.comcast.com/customers/faq/FaqDetails.ashx?ID=2789
On Sun, Sep 21, 2008 at 2:15 AM, Zane H. Healy <healyzh at aracnet.com> wrote:
> At 11:45 PM -0700 9/20/08, David Griffith wrote:
>>
>> Now as soon as I can figure out how to do POTS modem dialing through a
>> cell phone, I'll call.
>
> How much longer will old fashioned modems continue to work with the evolving
> phone systems that we have? When it was looking like I'd be forced to move
> to Verizon FIOS a couple weeks ago, I made inquiries and learned that if you
> have FIOS you can not use a modem.
>
> Zane
>
>
> --
> | Zane H. Healy | UNIX Systems Administrator |
> | healyzh at aracnet.com (primary) | OpenVMS Enthusiast |
> | MONK::HEALYZH (DECnet) | Classic Computer Collector |
> +----------------------------------+----------------------------+
> | Empire of the Petal Throne and Traveller Role Playing, |
> | PDP-10 Emulation and Zane's Computer Museum. |
> | http://www.aracnet.com/~healyzh/ |
>
There is the ocasional homebuilt, TTL CPU thread on here. I wanted to make known this guy, John Plutorak, who reproduced the guidance computer in his basement:
http://klabs.org/history/build_agc/
Awsome project, take a look. I intend to build one too...
Randy Dawson
_________________________________________________________________
Get more out of the Web. Learn 10 hidden secrets of Windows Live.
http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!5…
On 9/21/08 5:24 PM, "Alexis" <thrashbarg at kaput.homeunix.org
<http://www.classiccmp.org/mailman/listinfo/cctalk> > wrote:
> On Sun, 21 Sep 2008 09:37:51 pm Andrew Lynch wrote:
>> I have a working prototype on my bench and can read and write sectors and
>> format tracks.
>
> I never worked out how to format tracks on the 8272. It's one of the
things
> that puts me off using them. Could you describe how it's done?
>
> The other thing that puts me off is the data clock separator. How are you
> doing this?
Look at the code for the CompuPro Disk 1 interface. I don't have to code for
my CBIOS handy but I recall that you have to establish a 6-byte command
buffer (with the right parameters), establish the interleave (if formatting
with one) and then loop through all of the tracks sequentially, sending the
format command for each track. I used a hardware interleave so that my CBIOS
didn't have to do it.
The command buffer for my CP/M system looks like this. The fields come right
>from the 8272 manual.
FMTDAT .DB F_FMT ; format command
.DB 00H ;HDS,DS1,DS0
.DB NFIELD ;N (0, 1, 2, 3) 0=128-byte sectors
.DB FSC ;Sector count (26,15,8) =1ah
.DB 01BH ;SPECIAL FORMAT GPL.
.DB 0E5H ;D (FILLER BYTE)
Rich
--
Rich Cini
Collector of Classic Computers
Build Master and lead engineer, Altair32 Emulator
http://www.altair32.comhttp://www.classiccmp.org/cini
------REPLY------
Hi Alexis, Rich,
Thanks Rich! Yes, Rich has the right command sequence but you also need to
send the C, H, R, N to the i8272 for each sector during the execution phase.
It is not very intuitive but I got it working last night on my test bench
and confirmed it is working with Dave Dunfield's IMD program (Thanks Dave!)
and the Catweasel with CW2DMK (Thanks Tim!). For some odd reason it also
requires a leading $00 to format correctly which I don't understand either.
Basically, it is like writing a sector but you feed it sector metadata as it
goes around the track formatting sectors. Note, during execution phase it
is not like feeding the MSR/data registers like during the command/result
phase. The whole NEC765/i8272 process is kind of screwy IMO and I am
struggling to get my brain around it. I have sample code if you'd like to
see it but it is an awful mess right now.
As for the data separator, I am using an FDC9229 although you could use a
FDC9239 I think. The chips are still available but not exactly common. You
have to look but you can find them. I have some pointers if you'd like.
Actually, Alexis, you'd be the perfect guy for building your own Z80 home
brew FDC as you already have done most of this on your other projects. You
did an awesome job on your home brew 8080 a while back and your other
projects have been great too. Your experience would be a lot of help to the
project in putting out a design that not only works but is reliable and
flexible.
I'd like to support as many hobbyists as possible so I am trying to preserve
the hardware "hooks" to support 8" drives, etc. Due to the complexity of
this project it could really use another set of eyes to check the design.
There are many subtle issues with FDCs that require real hardware
experience.
One final note, the i8272 data sheet for the FORMAT TRACK command is rather
misleading or at least incomplete IMO. I prefer the SMC FDC765 datasheet
found on the BitSavers.org site (Thanks Al!). It also has data sheets for
hard to find units like the FDC9216, FDC9229, FDC9239, etc. Warning: 45MB
FILE!
http://bitsavers.org/pdf/standardMicrosystems/_dataBooks/1985_StandardMicros
ystems.pdf
Thanks and have a nice day!
Andrew Lynch
Does anyone have a source for 19 pin d-sub connectors? The Apple II used these for disk drives.
I haven't been able to find anyplace online that carries these. Any ideas? Similarly, what about 23 pin d-sub connectors (Commodore Amiga disk drive and video connectors)?
-Ian
>
> Does anyone have a source for 19 pin d-sub connectors? The Apple II
> used these for disk drives.
//e not ][, in Europe anyway. With a ][ or ][+ the drive has a 20
way connector which pushes straight onto the interface card and you
trap it between the case and the lid as a strain relief. The //e had a
short linking cable inside the case but if you had an old drive you
could still do it the old way I think.
Roger Holmes.
I'm looking for any information (like tape cartridge type, capacity, bus
interface) on a Magnetic Peripherals BY5A5-F tape drive (part no.
77024231).
Thanks!
Pat
--
Purdue University Research Computing --- http://www.rcac.purdue.edu/
The Computer Refuge --- http://computer-refuge.org
Hi,
If anyone is interested in building a FDC for their Z80 home brew computer
please contact me off list.
I am building a FDC for my Z80 home brew computer and would like to see how
it works for other builders.
The design is general enough to adapt to most Z80 systems. It has IDE and
i8272 (NEC 765) sections.
I have a working prototype on my bench and can read and write sectors and
format tracks.
It includes a simple disk monitor program for testing the FDC which could be
easily adapted to other systems.
I would like to improve and refine this design and increase test coverage
with other builders.
Thanks and have a nice day!
Andrew Lynch