>
>Subject: Re: Emailing: CP-M Z80 home brew computer circuit board.htm
> From: "bfranchuk at jetnet.ab.ca" <bfranchuk at jetnet.ab.ca>
> Date: Tue, 17 Jun 2008 10:09:33 -0600
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Allison wrote:
>>
>> Have you ever used 8"SSSD to do anything that required space? There
>> isn't
>> enough space to run a disassembled version of the BDOS through ASM
>> unless you have at least two drives and don't mind doing cleanup.
>>
>I never could run the CP/M system I was using for more than 30 minutes
>with out
>the floppy stepper sticking. That was fun working with it.
BTDT.. :(
>Still how do you transfer stuff from a floppy ( or file online ) to a
>CP/M system with no external I/O devices?
Explain no external IO?
A serial line works fine, or a parallel bidirectional port. Since every
cp/m system has a console no rule saus it can transfer files on that line
either.
>> Yes you can roll your own data sep it only needs three ttl packages.
>> With all the other hardware needed for the 765 case you end up with at
>> least 10 chips
>> though If you willing to miss a few features it's been done in 7 plus
>> the FDC
>> and that doesn't include the bus side of the FDC interface.
>>
>That I would like to see.
Goo look at David Dunfield's CUBIX system. CPU is 6809 but the FDC is
765 with minimal interface parts count. I'd say it was a good example
of keep ing the chip count to a minimum.
>>
>> Kicad for linux there are other like cadstd for winders.
>> Of course the last 2901 design I'd done in the early 80s was
>> with paper and pen! It's doable that way.
>I still am using paper & pen. Mind you I have to buy JAPANESE pens
>since the quality of the USA stuff is all cheap Chinese imports.
>Now that I have a serious cad program - DIPTRACE on order
>I think I will put the design in hardware.
I still use paper and pen too. I do everything engineering
notebook style. That is black ink, no erasures and numbered
pages.
>> FYI using 250nS eproms will make it terminally slow unless
>> you do two things, use a wide microword 64bits or more and
>> pipeline the address and decode so you can work right to the
>> eprom Tacc minimum limit.
>I got that covered if I read the 2901 data sheets correctly.
>I will be using a 6809 style memory cycle optimized for
>D-RAM access and clock the 2901 in 4th phase of
>the memory cycle. This is retro computing project for the feel
>of the late 1970's not using a 8 bit CPU. I am aming for
>a 800ns memory cycle and the slow access of micro-code
>is not a problem. The only thing pipelined is the next memory
>cycle - Read/Write/Refesh and the default is refresh while
>doing the the 1st cycle of op-code decoding. The front
>panel does RUN/STOP, Single Instruction,Address Load,
>Deposit,Read.
Using Dram is one way to make life hard. you can use larger
static devices and save pain but retain the same cycle style.
Last 2901 design was 16bit, horizontal microcode (56bits),
one microword to a cycle. I was able to get the pipeline
for Eprom address latch to overlap so that the 2732s used
would run at 320ns with good timing. The macro cpu executed
instructions in that time cycle in a four tick cycle. It
was fairly fast for a single address machine. However, I
didn't do the microaddress or micro program counter in the
2901 I did that with TTL. No front pannel either the
system booted a rom minimal debugger. When I got it
working I junked it and started thinking about a 32bit machine.
Allison
>
>Subject: Re: CP-M Z80 home brew computer circuit board
> From: "Eric Smith" <eric at brouhaha.com>
> Date: Mon, 16 Jun 2008 13:58:30 -0700 (PDT)
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>Chuck wrote:
>> the 1770/72/73 have just about everything in a neat little 28-pin package.
>[...]
>> DMA not required.
>
>Whether DMA is required or not has nothing to do with which member of
>the 177x/179x/279x/MB88xx family you use. It's determined by whether
>you can write tight enough transfer loops to avoid write underruns and
>read overruns.
>
>On a 6502 a typical read transfer loop takes a minimum of 22 cycles,
>so a 1 MHz 6502 can keep up with 5.25 inch single and double density and
>8 inch single density with programmed I/O. 8 inch double-density
>requires a faster processor, DMA, or special tricks.
>
>With a Z80 a typical read transfer loop takes a minimum of 52 clocks,
>which on a 2 MHz Z80 meets the requirements for all but 8" double density,
>which requires a faster processor, DMA, or special tricks.
>
>On either processor, unrolling the loop does not shave off enough cycles
>to get to the 8" double density transfer rate.
>
>Note that the read loop has to be capable of reading bytes at about
>20% faster than the nominal rate or overruns become likely.
>
> nominal nominal required read loop
> format xfer rate byte time byte time
> ---------- ---------- --------- -------------------
> 5.25" FM 125 Kbps 64 us 52 us
> 5.25" MFM 250 Kbps 32 us 26 us
> 8" FM 250 Kpbs 32 us 26 us
> 8" MFM 500 Kbps 16 us 13 us
>
>> The 765-based all-in-ones such as the National 8473 and the WD37C65A
>> are about as hard to obtain and are a little more difficult to
>> interface to a Z80 (just about require DMA and interrupts to work
>> right).
>
>The 765-based controllers work fine with or without DMA. Again, the
>issue is the data rate.
>
>Eric
You hit the nail on the head. Interfacing 765 or 179x or any of the
other flavors is about the same from the bus side be it 8080/8085/z80
or 6502. As long as you can poll within the minimum read/write loop
time it's fairly easy. If not in the 8080/8085/z80 world you can use
processor ready line to do a stall-wait on DRQ to keep the loop in
sync and save some 22 T-states. I forget if 6502 has a ready wait
line.
>From a simple SBC perspective even the 1770 series requires some glue
and will inflate the parts count a fair amount. The more common
1793 or 765 will require enough parts to double or triple the parts
count. All of the 37C65 (and 37C665) parts work ok (witness the P112)
but go scarce as the PC industry drives their existance and disappearance.
Easy yes, simple, only if your not doing the work. However add a floppy
and who's supporting all them when someone wants to interface some oddball
pertec or CDC or Amdek 3" that "doesnt work with the SBC floppy"?
I've built my fill of floppy based, IDE based, CF based, ROMdisk based
systems and the latter two are far easier to construct and get going
and if your trying to run CP/M and mess with programming and applications
the smaller lower power SBC can be its own form of fun as you can
put it in a small box with a wall wart and use the laptop as a terminal
anywhere. Having a few PX-8s, Darth Vaders lubch boxes and S100 systems
with all the disks and what not is fine but when you want to move them
it's not so fun using hand truck. Where my tiny Z80 with 32MB CF
in a 5x4x1.5" box is rather fun to bring and show CP/M and what it
can still do, on batteries!
Allison
Hi All,
Never got around to assembling my Spare Time Gizmos SBC6120.
Just put it on ebay if anyones interested.
Item #300234398483
Rob
Rob Borsuk
email: rborsuk at colourfull.com
Colourfull Creations
Web: http://www.colourfull.com
>
>Subject: Re: CP-M Z80 home brew computer circuit board
> From: "Roy J. Tellason" <rtellason at verizon.net>
> Date: Sun, 15 Jun 2008 17:22:48 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Sunday 15 June 2008 16:43, Chuck Guzis wrote:
>> From: "Andrew Lynch"
>>
>> > Implementing floppy IO can take on many variations and picking the FDC
>> > is just the first of many challenges [FDC1793? NEC765? SMC9266?
>> > WD2797?]. What about the data separator? Few chips remain and viable
>> > sources are scarce. Even integrated FDCs with built in data separators
>> > are not readily available.
>>
>> The WD1770/1772/1773 is still my favorite "almost no external
>> circuitry" chip, but they're getting harder to find, in spite of
>> being used on Atari and Commodore boxes. You don't need to buffer
>> the floppy interface and the things have integrated data separators--
>> and come in a 28-pin package.
>
>I thought it was the 179x parts that had the data separator on-chip, no?
No. 1770 did as did 2793...
Allison
>
>--
>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
This should be a Pertec formatted 800/1600bpi drive.
I have a slightly earlier version. I'm pretty sure I
have a manual for it, will dig around..
Curiously, I wasn't able to get it to work correctly with
a Pertec to SCSI converter out of a Qualstar transport.
CP-M Z80 home brew computer circuit board
bfranchuk at jetnet.ab.ca bfranchuk at jetnet.ab.ca
<mailto:cctalk%40classiccmp.org?Subject=CP-M%20Z80%20home%20brew%20computer%
20circuit%20board&In-Reply-To=5E5B27B6AB204FE39BB21B75D4C8713B%40andrewdeskt
op>
Sun Jun 15 12:06:33 CDT 2008
* Previous message: CP-M Z80 home brew computer circuit board
* Next message: big bucks for a Tek computer on eBay
* Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
________________________________
Andrew Lynch wrote:
> -----REPLY-----
>
> Hi! Thanks Jim for the comments. Please let me address the issues raised
> by Ben:
>
> If you look closely at the SBC design, you'll notice it has a feature even
> better than a floppy controller -- it has a fully buffered IO bus! It
> contains all the Z80 signals brought out to the DIN 41612 connector. The
> peripheral bus adheres to the published ECB standard.
>
> If you want floppy IO, the solution is simple -- just design one and
attach
> it to the bus! I have already done this with my Disk IO board (IDE and
> NEC765 FDC) which plugs into my home brew ECB backplane along with the
SBC.
> Assuming there is enough interest in these home brew SBCs, I hope to make
a
> PCB version of the Disk IO board.
>
Well when you get a PCB of the Disk I/O board , I'll take the set of PCB's.
Will a 8272 (intel) Disk controler replace the NEC765? for the floppy
controler
for the track formatting for CP/M? Unicorn Electronics is my favorite
shopping for
electronic parts and I can find a 8272 there.
-----REPLY-----
Hi Ben,
Of course, the NEC 765 and Intel 8272 are virtually the same part and are as
common as dirt.
I believe Intel licensed the NEC 765A and just renamed it the i8272 or
something like that.
However, getting the FDC chip is the trivially easy part. Getting a data
separator is a much more difficult problem.
Have you tried finding an FDC9229 recently? How about a SMC FDC9216 or UMC
8326? Even the FDC1793 requires a DS chip.
I challenge you to even *FIND* a FDC9229 *datasheet* these days.
DS chips are nearly unobtainium or at least very difficult to get. I have a
few and but not many. They are hard to find.
For a DS you can probably substitute a ROM based state machine or even hack
it out using SSI TTL chips.
However, then you'll have a much larger PCB that'll cost a small fortune to
manufacture and few can afford.
If you try to use an integrated FDC with DS built in, you'll run into even
more problems.
Chips like the WD2797 and SMC9266 have built in data separators but are even
more scarce and expensive than the data separator chips.
In short, if just adding Floppy IO to a SBC were an easy task, you see more
home brew SBCs available with them.
I am trying to build an SBC that any hobbyist can afford, build reliably,
and have a reasonable chance of success.
That means compromises had to be made and some stuff had to go.
Anyone can design a great computer on paper. Making a real, tangible part
is a lot more difficult.
Using cool sounding but almost impossible to find parts seems easy but it
makes the SBC practically worthless.
If you can make a low cost Z80 SBC that includes floppy IO, I would love to
see it. I'd even buy one or two.
I look forward to seeing your design.
Thanks and have a nice day!
Andrew Lynch
I'm looking at buying an IDT (Innovative Data Technology) tape drive, model TD-1054/INTL. I don't have any information on it other than that. It's a manual thread drive, and appears to be 800/1600bpi. But, what I can't tell from the seller's pictures is the interface. He thinks it's Pertec, but doesn't know. I don't have a formatter board, all my machines are set up to communicate with formatted Pertec drives. It _appears_ to have two 50 pin connectors on the board, but it looks like a couple of the fingers aren't populated. I don't remember ever seeing a Pertec drive like that. (but I could be wrong...)
I've emailed the seller asking for a better picture, but I was hoping that someone here might have some knowledge about this drive.
Thanks!
-Ian
Hi, All,
With all the CP/M questions flying around (and some by me), I ran across
an interesting archive at one of the CP/M respositories - Infocom games
*plus* setup files for random CP/M environments. The source provided
starts like this:
;Copyright 1982 Infocom, Inc. All rights reserved.
;Configuration Program for INTERLOGIC(tm) CP/M Files
;Configured for basic no-frills terminal
;This program should be edited to specify terminal and
;printer parameters for your CP/M system. Edit this
;file, then assemble, load, and run the program.
;Complete documentation of the setup procedure will
;be found in your INTERLOGIC Reference Card.
;Terminal and printer specific parameters start at
;the label CPMCPL, about 20 lines below. Nothing
;prior to that label should be altered.
... and what follows are a set of data storage spots to fill in with
who-knows-what to customize interpreter behavior for your environment.
Does anyone have a copy of the aforementioned "INTERLOGIC Reference Card"
for CP/M versions of the games?
I'm running things under the altair/altairz80 emulators that are part
of SIMH. I have CP/M, etc., working fine - I just need the text from
the Infocom reference card that would have come in the game box.
Thanks,
-ethan
--
Ethan Dicks, A-333-S Current South Pole Weather at 17-Jun-2008 at 10:00 Z
South Pole Station
PSC 468 Box 400 Temp -64.8 F (-53.8 C) Windchill -92.1 F (-69.0 C)
APO AP 96598 Wind 6.5 kts Grid 351 Barometer 673.2 mb (10886 ft)
Ethan.Dicks at usap.govhttp://penguincentral.com/penguincentral.html
> From: "Eric Smith" <eric at brouhaha.com>
> Whether DMA is required or not has nothing to do with which member of
> the 177x/179x/279x/MB88xx family you use. It's determined by whether
> you can write tight enough transfer loops to avoid write underruns and
> read overruns.
More or less what I was trying to say (however clumsily).
> On either processor, unrolling the loop does not shave off enough cycles
> to get to the 8" double density transfer rate.
For more conversation on transfer loop speeds, see my comments on
Herb Johnson's Retrotechnology site. By getting clever with code,
you can turn in some pretty fast transfer loops even on a lowly 2 MHz
8080.
For example, if we assume that the controller will assert wait states
if an input is attempted on the data port until a byte becomes
available and interrupts on operation complete, a 2MHz 8080 transfer
loop could handle an 8" MFM transfer like this:
LXI H,floppy$byte
floppy$byte: clocks 2mhz
IN fdcport ;FDC port 10 5 uS
PUSH PSW ;store 2 bytes 11 5.5 uS
PCHL ;loop 5 2.5 uS
Total: 26 13 uS
Now, of course, you've got to unravel what you've got on the stack to
get your data back, but you've gotten it--at 2MHz and on an 8080 yet.
Caveat: I haven't tried this, except on paper. If you were to unroll
the loop to a series of IN/PUSH pairs, the byte time should drop to
10.5 usec, more than fast enough for an 8" MFM transfer.
But that discussion's from the days when silicon was expensive. An
inexpensive async FIFO would get rid of the problem entirely and
allow for transfer at one's convenience.
The point that I was trying to make was that the 1770/2/3 make for
very easy interfacing with a minimum of parts--and are very easy to
program. They feature a small package and were designed for
5.25"/3.5" drives. Were I prototyping a small PCB with a Z80 and
floppy support, they'd be my first choice.
Cheers,
Chuck
