BigBoard 1 Bios
robot...@my-deja.com
I lost all my 8" disks in a move a few
years ago:>(
I want to get my bb1 up and running again but no
disks. Also, if you have the source for it that
would be very usefull also.
Does anybody know if Micro Cornucopia user disks
are archived anywhere?
Sent via Deja.com http://www.deja.com/
Before you buy.
O. Alan Jones
master copy so he could make one for himself. Dick is a super nice and
helpful person. Tell him I said so!
--Alan
www.bright.net/~oajones
<robot...@my-deja.com> wrote in message
news:8qaeu0$jib$1...@nnrp1.deja.com...
Richard Erlacher
'm really not as nice as all that, Alan Jones' words notwithstanding,
but I do happen to have several (about a dozen) of the disks you
mention. I also have (as you already know if you've read the post
from Alan) the boot and source diskettes for the Big Board.
In addition, I've designed a number of "hacks" to the Big Board that
should enable it to operate at nearly any harmonic of the 2.5 MHz
speed at which it presently operates. Unfortunately, it won't run
faster than 10 MHz without abandoning the DRAM array on the board.
The DRAMs have to be replaced with faster ones no matter what you do
to the array, but if you put in 256K 80ns parts, it will support 10
MHz operation. There's also a hack to the FDC to enable you to use a
1795 instead of the 1771, which will let you use DSDD 8"diskettes.
I'll be bringing up a Big Board and step-wise installing the upgrades,
starting with the upgrade to 5 MHz operation. I've decided it's not
worth the investment to upgrade the peripherals, so I've come up with
a new scheme to deal with wait-states for the 2.5 MHz peripherals and
1771. I want to test all these mod's before publishing them, so be
patient!
Nevertheless, if you want the MicroCornucopia Big Board User diskettes
copied, I'll do that on YOUR media. I have plenty , but won't for
long if I send them off.
Contact me via email if you want this stuffl
Dick
Steve
Are there any schematics available on the Net or off for this old
venerable so that one might build another??
Steve
nos...@nouce.bellatlantic.net
>---------------------
>Are there any schematics available on the Net or off for this old
>venerable so that one might build another??
>Steve
If I were to suggest anything the schematics for the AmproLB would be
more reproduceable. Also going from 64kx1 or 16kx1 drams to a
single Sram(commonly available cache parts or a pair of the standard
32kx8 parts would also simplify it). the key thing is to get the FDC,
serial and interrupts like a commonly known board as that defines the
critical interfaces (the BIOS).
The AMPROLB is as 1984
1 z80 @ 4mhz
8 64kx1 Dram (use static for that)
1 Eprom 4kx8 (can be bigger, used a 28 pin site )
1 1770 FDC, program compatable with 1793/2793 series.
1 CTC timer and interrupts
1 SIO two serial ports
1 * NCR5380 for SCSI (can skip this, hard to find now)
TTL glue (most to support the Dram!).
Basic AmproLB without scsi was a 64k ram CP/M system with two
serial ports and a few parallel ports one of which is centronics
(unidirectional) printer.
using currently available old parts a 6 or 8mhz z80/CTC/SIO
is easy and static ram is much simpler leaving only the FDC
and 1793 is easiest to find but requires the most TTL glue
around it. it would be easy to copy at the functional bios
level without copying the schematic.. A PAL would out the IO
at the right addresses. The boot rom and bios for that board
has and was published on the WCcdrom though it was not the
latest/last version it was usable.
Other seemingly common Z80/SIO based designs would include
the Kaypro series, Big board I/II and a small troupe of others.
Allison
Neil Cherry
>On Thu, 21 Sep 2000 00:41:21 -0700, Steve <rst...@armory.com> wrote:
>
>>---------------------
>>Are there any schematics available on the Net or off for this old
>>venerable so that one might build another??
>>Steve
>
>If I were to suggest anything the schematics for the AmproLB would be
>more reproduceable. Also going from 64kx1 or 16kx1 drams to a
>single Sram(commonly available cache parts or a pair of the standard
>32kx8 parts would also simplify it). the key thing is to get the FDC,
>serial and interrupts like a commonly known board as that defines the
>critical interfaces (the BIOS).
>
>The AMPROLB is as 1984
> 1 z80 @ 4mhz
Or maybe an S180 (or other new Zilog Z80 compatible chip)
> 8 64kx1 Dram (use static for that)
Or other single chip static ram (larger is very easy to do :-)
> 1 Eprom 4kx8 (can be bigger, used a 28 pin site )
Easy to do, perhaps flash?
> 1 1770 FDC, program compatable with 1793/2793 series.
This can be a problem.
> 1 CTC timer and interrupts
I'm not sure if the S18x family is or isn't compatible.
> 1 SIO two serial ports
Same here.
> 1 * NCR5380 for SCSI (can skip this, hard to find now)
The newer chips x53C80 family of chips are still available. One also
might consider addign the IDE from the Generic IDE project:
http://www.blkbox.com/~jdbaker/SmallSys/8bitIDE.html
> TTL glue (most to support the Dram!).
>Basic AmproLB without scsi was a 64k ram CP/M system with two
>serial ports and a few parallel ports one of which is centronics
>(unidirectional) printer.
>
>using currently available old parts a 6 or 8mhz z80/CTC/SIO
>is easy and static ram is much simpler leaving only the FDC
>and 1793 is easiest to find but requires the most TTL glue
>around it. it would be easy to copy at the functional bios
>level without copying the schematic.. A PAL would out the IO
>at the right addresses. The boot rom and bios for that board
>has and was published on the WCcdrom though it was not the
>latest/last version it was usable.
>
>Other seemingly common Z80/SIO based designs would include
>the Kaypro series, Big board I/II and a small troupe of others.
Still very nice, Allison!
--
Linux Home Automation Neil Cherry nch...@home.net
http://members.home.net/ncherry (Text only)
http://meltingpot.fortunecity.com/lightsey/52 (Graphics)
http://linuxha.sourceforge.net/ (SourceForge)
Richard Erlacher
a 20 MHz Z80, pull an old 64kx8 SRAM off an old motherboard, get a
2732 or other eprom up to 64kx8, and use whatever FDC is available,
then base a BIOS on that FDC and build your own configuration. It
makes a lot more sense to leave out those Z80 peripherals, which are
the speed-liniting thing in a system, as they don't work properly with
wait-states, having to look at opcode fetches, so it makes,
ultimately, more sense to pattern one's system after a BigBoard-II
with the exception that the PIO's should be replaced with 82C55's and
the SIO with a 2681 or equivalent. A DMAC is not necessary, and the
BB-II-style video, patterened after a PC mono card but accessed via
ports rather than memory map, as a terminal would be, via escape code
to control cursor movement, but without a serial link to slow things
down.
The problem with the AMPRO LB is that most folks don't have a
terminal, nor do they want one.
The additional problem with the Little Board is that the board has
only 8 RAM chips, which presents a considerable limitation as opposed
to the 32-socket array on the BB. I've got a hack worked out to put
an additional 8 MB on that board using parts one often finds in the
closet. The real estate on the BigBoard makes more sense, methinks.
Wait a couple of weeks and I'll probably have it working.
If you could suggest some 8042 code for translating the PC Keyboard
scan codes to ASCII as you once suggested one should do, Allison, it
would make the use of a PC keyboard easier. However, it requires
about 500 bytes of lookup table space, and I've not yet figured out
how I'd do that with an 8742. I imagine the code would fit . . .
Of course the published code for using a 68HC705J1 merely requires one
leave out the parallel to serial conversion on the host side
interface, and one's done.
That would let one build a console for the system for $10 or so using
thrift-store components.
Dick
On Fri, 22 Sep 2000 00:33:52 GMT, nos...@nouce.bellatlantic.net wrote:
Steve
>
> On Thu, 21 Sep 2000 00:41:21 -0700, Steve <rst...@armory.com> wrote:
>
> >---------------------
> >Are there any schematics available on the Net or off for this old
> >venerable so that one might build another??
> >Steve
>
> If I were to suggest anything the schematics for the AmproLB would be
> more reproduceable. Also going from 64kx1 or 16kx1 drams to a
> single Sram(commonly available cache parts or a pair of the standard
> 32kx8 parts would also simplify it). the key thing is to get the FDC,
> serial and interrupts like a commonly known board as that defines the
> critical interfaces (the BIOS).
>
> The AMPROLB is as 1984
> 1 z80 @ 4mhz
> 8 64kx1 Dram (use static for that)
> 1 Eprom 4kx8 (can be bigger, used a 28 pin site )
> 1 1770 FDC, program compatable with 1793/2793 series.
Which WD179x, praytell, might do a pinout altered 40 pin replacement of
the Wd1770 or '72 without rewriting the BIOS???
> 1 CTC timer and interrupts
> 1 SIO two serial ports
------------------
It uses the Z80 DART.
> 1 * NCR5380 for SCSI (can skip this, hard to find now)
> TTL glue (most to support the Dram!).
--------------------
Yes, a lot of it disappears. I think one could make a thru-pin version
which is the same form factor as the back of a 3.5" drive!!
> Basic AmproLB without scsi was a 64k ram CP/M system with two
> serial ports and a few parallel ports one of which is centronics
> (unidirectional) printer.
>
> using currently available old parts a 6 or 8mhz z80/CTC/SIO
> is easy and static ram is much simpler leaving only the FDC
> and 1793 is easiest to find but requires the most TTL glue
> around it. it would be easy to copy at the functional bios
> level without copying the schematic.. A PAL would out the IO
> at the right addresses. The boot rom and bios for that board
> has and was published on the WCcdrom though it was not the
> latest/last version it was usable.
>
> Other seemingly common Z80/SIO based designs would include
> the Kaypro series, Big board I/II and a small troupe of others.
>
> Allison
---------------------
I have two AmproLB Z80s, and they are nice, and I have wished to
reproduce them in SRAM form, with the CP/M on EPROM, but the FDC they
used was the WD1770 and later the WD 1772 for faster access. This chip
and its upgrade are no longer available. I would like to use the much
more flexible, available and venerable FDC 765 which is also the Intel
i8272, so as to enable us to easily write the PC format with a utility
when needed.
I'm not sure I can do the BIOS design, but if I have a chance to
undertake the challenge I will do so, however my time lately is limited.
If someone has already done this I'd love to hear about it, and I am now
working on an SRAM schematic from the AmproLB Z80.
-Steve
--
-Steve Walz rst...@armory.com ftp://ftp.armory.com/pub/user/rstevew
-Electronics Site!! 1000 Files/50 Dirs!! http://www.armory.com/~rstevew
Europe Naples, Italy: ftp://ftp.unina.it/pub/electronics/ftp.armory.com
Steve
>
> The problem with the AMPRO LB is that most folks don't have a
> terminal, nor do they want one.
Well, Dick, heavens they already HAVE a PC, that's just a big terminal!!
Steve
Neil Cherry
>If you could suggest some 8042 code for translating the PC Keyboard
>scan codes to ASCII as you once suggested one should do, Allison, it
>would make the use of a PC keyboard easier. However, it requires
>about 500 bytes of lookup table space, and I've not yet figured out
>how I'd do that with an 8742. I imagine the code would fit . . .
I beleive there are several pic projects which interface the PC
keyboard (the AT type I think) to an ASCII device.
Kenneth Casselman
> The problem with the AMPRO LB is that most folks don't have a
> terminal, nor do they want one.
>
Anyone with a PC already has a terminal :)
Ken
Richard Erlacher
PC is not the right vehicle. After all, it's not unheard-of to run a
simulator that's faster and, in some people's estimation, better, than
the original '70's hardware.
I frequently use a PC with a comm program running a script to test or
bring-up a system for which I have no boot diskette. It's a pain, but
once done, it's quite effective. Nevertheless, it's not "real" enough
for me.
Dick
On Fri, 22 Sep 2000 03:30:16 -0700, Steve <rst...@armory.com> wrote:
>Richard Erlacher wrote:
>>
>> The problem with the AMPRO LB is that most folks don't have a
>> terminal, nor do they want one.
Richard Erlacher
found one that's a simple and straightforward interface using the
classic parallel ASCII with strobe.
It's no problem to hack the host-interface side of most any published
intefacing solution such as this, but the fact that I've heard of none
that actually does that. The PC-interface is a bigger job than most
people realize, and it does, after all, require table lookup of some
~500 bytes of scan code in the context of shift, control, and altmode
keys.
One thing both the PIC and the 8x41/42 have in common is that
table-lookup is relatively cumbersome. While I don't see it as
impossible, I do see it as awkward. The MOTOROLA architecture makes
it MUCH simpler, though, simple or awkward, so long as it's possible,
it's not out of the question.
My preference for the MOT part is that it's a 20-pin part that does
the job. That's easy to prototype and not a BIG chip. However,
that's MY preference. If you know of a complete solution if a small
pacakge (28-pin skinnydip) I'd like to know about it. However, if
it's a "half-assed" solution, which most of the published ones are,
you must keep in mind how ugly and awkward it can be to hack somebody
else's code in an architecture that doesn't happily support table
lookup using over 500 bytes of table space.
Dick
On Fri, 22 Sep 2000 11:56:48 GMT, n...@CC47532-A.ewndsr1.nj.home.com
(Neil Cherry) wrote:
>On Fri, 22 Sep 2000 05:14:45 GMT, Richard Erlacher wrote:
>
>>If you could suggest some 8042 code for translating the PC Keyboard
>>scan codes to ASCII as you once suggested one should do, Allison, it
>>would make the use of a PC keyboard easier. However, it requires
>>about 500 bytes of lookup table space, and I've not yet figured out
>>how I'd do that with an 8742. I imagine the code would fit . . .
>
Richard Erlacher
1770/72. However, it's NOT identical. Moreover, the 1770 is mapped
rather strangely (not very) in order to capitlize on the timing
advantage of mapping the register sets in to two sets, one for read
and one for write. I don't find this awful, myself. One could do the
same with the 179x.
The Ampro Little Board, however, is a mite shy on space for hacks to
increase the memory size, for example, without using a third
dimension.
I say this only because I've explored an 8MB add-on memory for the Big
Board, using 72-pin SIMM memory on a single-sided board that plugs
into the memory array. One wouldn't have room for that on the Little
Board.
I've used the AMPRO original Little Board more than any other single
CP/M-based hardware environment. However, its limitations are
ever-present. The Little-Board I/O decoding is ambigous, and, while
that doesn't mean it doesn't work, it does raise the risk of decoding
conflicts, making expansion risky. This makes the Ampro Little Board
a poorer candidate for expansion/modification than, say, the Ferguson
Big Board.
Dick
On Fri, 22 Sep 2000 03:09:35 -0700, Steve <rst...@armory.com> wrote:
>nos...@nouce.bellatlantic.net wrote:
>>
>> On Thu, 21 Sep 2000 00:41:21 -0700, Steve <rst...@armory.com> wrote:
>>
>> >---------------------
>> >Are there any schematics available on the Net or off for this old
>> >venerable so that one might build another??
>> >Steve
>>
>> If I were to suggest anything the schematics for the AmproLB would be
>> more reproduceable. Also going from 64kx1 or 16kx1 drams to a
>> single Sram(commonly available cache parts or a pair of the standard
>> 32kx8 parts would also simplify it). the key thing is to get the FDC,
>> serial and interrupts like a commonly known board as that defines the
>> critical interfaces (the BIOS).
>>
>> The AMPROLB is as 1984
>> 1 z80 @ 4mhz
>> 8 64kx1 Dram (use static for that)
>> 1 Eprom 4kx8 (can be bigger, used a 28 pin site )
>> 1 1770 FDC, program compatable with 1793/2793 series.
>-----------------
>Which WD179x, praytell, might do a pinout altered 40 pin replacement of
>the Wd1770 or '72 without rewriting the BIOS???
>
>
>> 1 CTC timer and interrupts
>> 1 SIO two serial ports
>------------------
>It uses the Z80 DART.
>
>
>> 1 * NCR5380 for SCSI (can skip this, hard to find now)
>> TTL glue (most to support the Dram!).
>--------------------
>Yes, a lot of it disappears. I think one could make a thru-pin version
>which is the same form factor as the back of a 3.5" drive!!
>
>
>> Basic AmproLB without scsi was a 64k ram CP/M system with two
>> serial ports and a few parallel ports one of which is centronics
>> (unidirectional) printer.
>>
>> using currently available old parts a 6 or 8mhz z80/CTC/SIO
>> is easy and static ram is much simpler leaving only the FDC
>> and 1793 is easiest to find but requires the most TTL glue
>> around it. it would be easy to copy at the functional bios
>> level without copying the schematic.. A PAL would out the IO
>> at the right addresses. The boot rom and bios for that board
>> has and was published on the WCcdrom though it was not the
>> latest/last version it was usable.
>>
>> Other seemingly common Z80/SIO based designs would include
>> the Kaypro series, Big board I/II and a small troupe of others.
>>
>> Allison
Richard Erlacher
software that I bought with my original Little Boards (a) used no
interrupts and (b) pretty much used up all the I/O alternatives
available within its hardware environment.
If one were to use the AMPRO code to drive a copy of its hardware with
the exception of the presence of a 1797 in place of the 1770 that came
with it, no code would need to be changed. However, if you'd like to
perate 8" drives, increase the number of drives you use, etc, you
quickly begin to trip over the limitations in the AMPRO hardware. The
Little Board is what it says it is, namely, a Little Board, and it has
most of the features that a CP/M user of the early '80's wanted.
Expansion is not what it was designed for, however.
Substituting a 179x/279x would mean solving some drive-selection
problems that need additional hardware, solving some clocking problems
that require additional hardware, and, of course, providing the
data/clock recovery/write-prcompensation hardware internal to the 1770
but unavailable in the 179x series, and only partially dealt-with in
the 279x.
If I were rebuilding the Little Board with 1980's technology, I'd have
to add lots of stuff to the Little Board that I have just to make it
easy to expand. If a PAL were used to decode the I/O devices, it
would help, but that, alone, would not be sufficient. It makes little
sense, today, to expand the Little Board series because of its
limitations. That shouldn't stop anyone wishing to do it, however. I
have made the observation that the Little Board is a poor candidate
for such expansion. It's not impossible, though. For years, I used
the Little Board as an in-circuit development tool. My target would
simply sit on the Z80 site on the Little Board, and its I/O usage
would carefully be mapped around the AMPRO's ambiguities. I'm glad I
don't have to do that any longer, though
Dick
On Fri, 22 Sep 2000 03:09:35 -0700, Steve <rst...@armory.com> wrote:
>nos...@nouce.bellatlantic.net wrote:
>>
>> On Thu, 21 Sep 2000 00:41:21 -0700, Steve <rst...@armory.com> wrote:
>>
>> >---------------------
>> >Are there any schematics available on the Net or off for this old
>> >venerable so that one might build another??
>> >Steve
>>
>> If I were to suggest anything the schematics for the AmproLB would be
>> more reproduceable. Also going from 64kx1 or 16kx1 drams to a
>> single Sram(commonly available cache parts or a pair of the standard
>> 32kx8 parts would also simplify it). the key thing is to get the FDC,
>> serial and interrupts like a commonly known board as that defines the
>> critical interfaces (the BIOS).
>>
>> The AMPROLB is as 1984
>> 1 z80 @ 4mhz
>> 8 64kx1 Dram (use static for that)
>> 1 Eprom 4kx8 (can be bigger, used a 28 pin site )
>> 1 1770 FDC, program compatable with 1793/2793 series.
>-----------------
>Which WD179x, praytell, might do a pinout altered 40 pin replacement of
>the Wd1770 or '72 without rewriting the BIOS???
>
>
>> 1 CTC timer and interrupts
>> 1 SIO two serial ports
>------------------
>It uses the Z80 DART.
>
>
>> 1 * NCR5380 for SCSI (can skip this, hard to find now)
>> TTL glue (most to support the Dram!).
>--------------------
>Yes, a lot of it disappears. I think one could make a thru-pin version
>which is the same form factor as the back of a 3.5" drive!!
>
>
>> Basic AmproLB without scsi was a 64k ram CP/M system with two
>> serial ports and a few parallel ports one of which is centronics
>> (unidirectional) printer.
>>
>> using currently available old parts a 6 or 8mhz z80/CTC/SIO
>> is easy and static ram is much simpler leaving only the FDC
>> and 1793 is easiest to find but requires the most TTL glue
>> around it. it would be easy to copy at the functional bios
>> level without copying the schematic.. A PAL would out the IO
>> at the right addresses. The boot rom and bios for that board
>> has and was published on the WCcdrom though it was not the
>> latest/last version it was usable.
>>
>> Other seemingly common Z80/SIO based designs would include
>> the Kaypro series, Big board I/II and a small troupe of others.
>>
>> Allison
nos...@nouce.bellatlantic.net
wrote:
>Not to trivialize this operation, but it would be much simpler to buy
>a 20 MHz Z80, pull an old 64kx8 SRAM off an old motherboard, get a
>2732 or other eprom up to 64kx8, and use whatever FDC is available,
>then base a BIOS on that FDC and build your own configuration. It
>makes a lot more sense to leave out those Z80 peripherals, which are
>the speed-liniting thing in a system, as they don't work properly with
>wait-states, having to look at opcode fetches, so it makes,
Parts that run at 6-8mhz are available still, 4mhz parts are not hard
to find.
I only suggest them as they are easy to wire up. Personally I don't
like the Z80 peripherals and use the tons of 82xx stuff I have that
will run fine at 4mhz (these are all early 80s date code) and with
one wait state they seem ok at 6-8mhz for the -5 parts(also CA 1981).
>ultimately, more sense to pattern one's system after a BigBoard-II
>with the exception that the PIO's should be replaced with 82C55's and
>the SIO with a 2681 or equivalent. A DMAC is not necessary, and the
Out use a 8237 pulled from an old XT card as that can run with a clock
not synched to the CPU.
>The problem with the AMPRO LB is that most folks don't have a
>terminal, nor do they want one.
There is that. The BB or Kaypro designs side stepped that or
using a z80 with memory lashed to a XT class ISA-8 FDC, HDC
and video would be pretty painless too.
Inthe end the AmproLB suggestion was if you want something that is not
rocket science, small and very wirewrappable that design with static
ram is pretty minimal. the original was the same footprint as 5.25"
floppy. Anotehr one that used a terminal was the SB180 (64180/z180)
and that was even simpler!
>The additional problem with the Little Board is that the board has
>only 8 RAM chips, which presents a considerable limitation as opposed
but 41256s fit so nice. I'd not use Dram anyway for 64k and for
larger I'd use the rather cheap and common 1mx9 30pin simms.
>If you could suggest some 8042 code for translating the PC Keyboard
>scan codes to ASCII as you once suggested one should do, Allison, it
>would make the use of a PC keyboard easier. However, it requires
>about 500 bytes of lookup table space, and I've not yet figured out
>how I'd do that with an 8742. I imagine the code would fit . . .
There is room. 8742 is 2kb of rom and the lookup can be mirrord to
256bytes or simply use 512bytes. There is some code on or used to be
on Ciciara's site back when. It's on my project list for the cold
months.
>Of course the published code for using a 68HC705J1 merely requires one
>leave out the parallel to serial conversion on the host side
>interface, and one's done.
There are several articles to go from pc xt or pc at keyboard to
serial or parallel and building a parallel port or using an 8255 is
pretty trivial too. Clearly use what you have.
>That would let one build a console for the system for $10 or so using
>thrift-store components.
maybe less if you scrounge. ;) I find that dead386/486 boards are
great finds for cache ram (32kx8 .3wide or 64kx8 .3 wide) , 1mx9
simms, the 8042/8742 for the keyboard is usable as is if you don't
mind scan code, 8237s can be had off old XT, 286 and some 36 boards.
Only thing needed is serial, 8250s are ok, 8251s, 2651s, 2681s are
around along with the 16450s.
Like you said, you want one no problem.
Allison
nos...@nouce.bellatlantic.net
wrote:
>I frequently use a PC with a comm program running a script to test or
>bring-up a system for which I have no boot diskette. It's a pain, but
>once done, it's quite effective. Nevertheless, it's not "real" enough
>for me.
>
>Dick
I run a serial interfaced disk emulator written for cpm on a PC (an
old 486) that is running MYZ80! Its old code and MYZ80 is a cpm
machine like the one that I wrote the code on seems like a good use
for a spare PC. ;)
The terminal is either my Vt180, Vt125, VT320 or the color VT340.
Nothing works like a real tube(TM).
Allison
nos...@nouce.bellatlantic.net
>-----------------
>Which WD179x, praytell, might do a pinout altered 40 pin replacement of
>the Wd1770 or '72 without rewriting the BIOS???
the basic 1793 is the core FDC, you have to glue some ttl around it
for data sep and disk interface but no biggie.
>--------------------
>Yes, a lot of it disappears. I think one could make a thru-pin version
>which is the same form factor as the back of a 3.5" drive!!
Well the basic Ampro is 5.25 sized (smaller actually) and if you pull
the Dram and replace it with a 64kx8 that deletes 13 of the 37 or so
(no scsi) making the board about half the area.
>> Allison
>---------------------
>I have two AmproLB Z80s, and they are nice, and I have wished to
>reproduce them in SRAM form, with the CP/M on EPROM, but the FDC they
>used was the WD1770 and later the WD 1772 for faster access. This chip
>and its upgrade are no longer available. I would like to use the much
>more flexible, available and venerable FDC 765 which is also the Intel
>i8272, so as to enable us to easily write the PC format with a utility
>when needed.
Well teh best bet and fairly easy to fins is the WD37c65 (xt and early
at contr0llers use it). It's 765 code and does ALL formats if
16/9.6mhz clocks are provided. It runs easily at 8mhz z80 speeds
too. the bios changes though.
The other would be 2793. it's close enough to teh 1770/2 to get by
though it's 40 pins and done have the drive select logic (parallel
port would do).
>I'm not sure I can do the BIOS design, but if I have a chance to
>undertake the challenge I will do so, however my time lately is limited.
>If someone has already done this I'd love to hear about it, and I am now
>working on an SRAM schematic from the AmproLB Z80.
>-Steve
Well I've done 765 based bios and will be doing another for Z280.
The first one is rather old code (1981!). It's not hard to do the 765
as PIO if the z80 is at least 4mhz (DD5.25, but dd8" is tough) and
much easier at 6 ot 8mhz.
CPM bios is not all that hard without hard disk once you get past the
deblocking code. Once you have the deblocking code even hard
disk is not bad. A non interrupt driven basic bios for single density
floppy is 1.5k(8080 code!) with buffers and alloc storage.
For those reading DeBlocking code is an interface layer (my term)
between the BDOS that uses 128byte LOGICAL sectors and most
latter disks that used 256/512/1024 byte physical sectors for better
storage efficencty(and speed). Double desnity disks by default
are always (excluding oddbals) 256 or 512 byte sector size.
Allison
nos...@nouce.bellatlantic.net
wrote:
>I say this only because I've explored an 8MB add-on memory for the Big
>Board, using 72-pin SIMM memory on a single-sided board that plugs
>into the memory array. One wouldn't have room for that on the Little
>Board.
Use 256kx1 parts and you up to 256k with minimal hacks (use the spare
parallel port for the extra bit.
>I've used the AMPRO original Little Board more than any other single
>CP/M-based hardware environment. However, its limitations are
>ever-present. The Little-Board I/O decoding is ambigous, and, while
I'ts small, simple and for CPM is was a good (enough) design. Not to
say one cant do better with a mix of current parts and old only that
copying that would not be that bad.
Allison
nos...@nouce.bellatlantic.net
wrote:
>quickly begin to trip over the limitations in the AMPRO hardware. The
>Little Board is what it says it is, namely, a Little Board, and it has
>most of the features that a CP/M user of the early '80's wanted.
>Expansion is not what it was designed for, however.
Exactly. Mine is in case 13x4x8 with power supply for 115/230v (and
12v DC) operation, two 3.5" floppies(781k ea) and a 45mb SCSI drive.
with a VT320 its as compact as any PC with a minitower. it even has a
handle on the side!
>Substituting a 179x/279x would mean solving some drive-selection
>problems that need additional hardware, solving some clocking problems
>that require additional hardware, and, of course, providing the
>data/clock recovery/write-prcompensation hardware internal to the 1770
>but unavailable in the 179x series, and only partially dealt-with in
>the 279x.
It's still not that bad as the circuits are WD textbook.
>If I were rebuilding the Little Board with 1980's technology, I'd have
>to add lots of stuff to the Little Board that I have just to make it
>easy to expand. If a PAL were used to decode the I/O devices, it
PALs are used! Mine has at least one 10L8. the CPU 1B design
was the AmproLB+ and my model. Fact is it's got everthing I need.
If I want to expand I have S100, Multibus, STD and a ISA-8 bus system
for that.
>have made the observation that the Little Board is a poor candidate
>for such expansion. It's not impossible, though. For years, I used
For expansion beyond a basic CP/M engine I'd agree though TCJ
did have a 4mb ramdisk board design for it.
>the Little Board as an in-circuit development tool. My target would
>simply sit on the Z80 site on the Little Board, and its I/O usage
>would carefully be mapped around the AMPRO's ambiguities. I'm glad I
>don't have to do that any longer, though
I have a better selectionand the LB would never be used that way. the
board used in the DEC VT180 is a good candidate adn I've heavily
hacked a few of them even running one 6mhz (the ram was fast enough
as it was.).
VT180 board is four 8251 serial ports (good to 19200baud),
1793 FDC with DD5.25 decode logic (hackable) and 64k
of 4164 ram and two 2732 Eprom sites. It's down side is NO
parallel printer port, DEC used serial for that. I usually pull one
of the 8251s and sub via cable an 8255 or some ttl for that and
the basic board only knows single sided (there is spare gates to fix
that). It's big too at 10.5x11in). The UP side is it fully decoded
for IO (there is a IOread, IOwrite and IOread/write set of decodes
with unused 74138 decode outputs) address and memory. It's
clean, no wait states for IO or memory (other than the 2732boot roms
that leave the map). Runs solid at 4mhz stock and easily upped to
6mhz.
HOWEVER!!! No single board machine without a bus connector
is easily expande unless the basic design provided for it. Most
however have some strong points (cheap, easy to find, small)
to offset that.
Allison
nos...@nouce.bellatlantic.net
too! The old one (still active) is AllisonP at world std dot com.
the spam was getting too think to use a real address anymore!
So all this is old ground and I still build and mod CP/M hardware
as Winders gives me migraines at work.
Allison
Richard Erlacher
ambiguous and (2) there's really not much room for such additonal
stuff. It would be MUCH less work to build the system from scratch as
I've already suggested. There isn't any parallel I/O left for drive
selection, let alone for fiddling with things like head-load timing,
etc. The code would be pretty straightforward, but Ampro did a couple
of things that I'd be loath to give up. One of these is the insertion
of their phantom drive for allowing copying to/from foreign formats.
The other thing, sadly, is that they used those awful Z-80
peripherals. Those limit system performance to whatever the slowest
peripheral can tolerate.
Dick
Richard Erlacher
shoulder to find their interrupt acknowledge.
Dick
On Fri, 22 Sep 2000 23:36:01 GMT, nos...@nouce.bellatlantic.net wrote:
>On Fri, 22 Sep 2000 05:14:45 GMT, ed...@hotmail.com (Richard Erlacher)
>wrote:
>
>>Not to trivialize this operation, but it would be much simpler to buy
>>a 20 MHz Z80, pull an old 64kx8 SRAM off an old motherboard, get a
>>2732 or other eprom up to 64kx8, and use whatever FDC is available,
>>then base a BIOS on that FDC and build your own configuration. It
>>makes a lot more sense to leave out those Z80 peripherals, which are
>>the speed-liniting thing in a system, as they don't work properly with
>>wait-states, having to look at opcode fetches, so it makes,
>
>Parts that run at 6-8mhz are available still, 4mhz parts are not hard
>to find.
>
>I only suggest them as they are easy to wire up. Personally I don't
>like the Z80 peripherals and use the tons of 82xx stuff I have that
>will run fine at 4mhz (these are all early 80s date code) and with
>one wait state they seem ok at 6-8mhz for the -5 parts(also CA 1981).
>
>>ultimately, more sense to pattern one's system after a BigBoard-II
>>with the exception that the PIO's should be replaced with 82C55's and
>>the SIO with a 2681 or equivalent. A DMAC is not necessary, and the
>
>Out use a 8237 pulled from an old XT card as that can run with a clock
>not synched to the CPU.
>
>>The problem with the AMPRO LB is that most folks don't have a
>>terminal, nor do they want one.
>
>There is that. The BB or Kaypro designs side stepped that or
>using a z80 with memory lashed to a XT class ISA-8 FDC, HDC
> and video would be pretty painless too.
>
>Inthe end the AmproLB suggestion was if you want something that is not
>rocket science, small and very wirewrappable that design with static
>ram is pretty minimal. the original was the same footprint as 5.25"
>floppy. Anotehr one that used a terminal was the SB180 (64180/z180)
>and that was even simpler!
>
>>The additional problem with the Little Board is that the board has
>>only 8 RAM chips, which presents a considerable limitation as opposed
>
>but 41256s fit so nice. I'd not use Dram anyway for 64k and for
>larger I'd use the rather cheap and common 1mx9 30pin simms.
>
>>If you could suggest some 8042 code for translating the PC Keyboard
>>scan codes to ASCII as you once suggested one should do, Allison, it
>>would make the use of a PC keyboard easier. However, it requires
>>about 500 bytes of lookup table space, and I've not yet figured out
>>how I'd do that with an 8742. I imagine the code would fit . . .
>
>There is room. 8742 is 2kb of rom and the lookup can be mirrord to
>256bytes or simply use 512bytes. There is some code on or used to be
>on Ciciara's site back when. It's on my project list for the cold
>months.
>
>>Of course the published code for using a 68HC705J1 merely requires one
>>leave out the parallel to serial conversion on the host side
>>interface, and one's done.
>
>There are several articles to go from pc xt or pc at keyboard to
>serial or parallel and building a parallel port or using an 8255 is
>pretty trivial too. Clearly use what you have.
>
>>That would let one build a console for the system for $10 or so using
>>thrift-store components.
>
Richard Erlacher
problem, the ambiguous decoding. It also doesn't really save much
space, since the board is still used. We're not talking new board
here, Allison, we're considering a hack of the existing. If I were
building a new board, it would not dally at 4 or 6 MHz since there are
20 MHz parts available for $8 per.
Dick
Steve
>
> It's only bad in the sense that (1) the on-board decoding is
> ambiguous and (2) there's really not much room for such additonal
> stuff. It would be MUCH less work to build the system from scratch as
> I've already suggested. There isn't any parallel I/O left for drive
> selection, let alone for fiddling with things like head-load timing,
> etc. The code would be pretty straightforward, but Ampro did a couple
> of things that I'd be loath to give up. One of these is the insertion
> of their phantom drive for allowing copying to/from foreign formats.
>
> The other thing, sadly, is that they used those awful Z-80
> peripherals. Those limit system performance to whatever the slowest
> peripheral can tolerate.
>
> Dick
It is very easy to look for any ambiguous I/O "in"s and "out"s and to
compare them to the Ampro memory map and correct them if needed, I doubt
they need it but it would be good to check, and then to rebuild the
Ampro with only the specific I/O map addresses implemented, so no
address ambiguity is designed-in. It may only take a couple decoders and
some glue logic. The Ampro has a master enable register to simplify this
a bit, and that makes it easy! I have the memory map if anyone needs it.
Steve
Steve
>
> Sadly, pulling the DRAM and MUX's still doesn't solve the most serious
> problem, the ambiguous decoding. It also doesn't really save much
> space, since the board is still used. We're not talking new board
> here, Allison, we're considering a hack of the existing. If I were
> building a new board, it would not dally at 4 or 6 MHz since there are
> 20 MHz parts available for $8 per.
>
> Dick
It's not SO horrible, look, anybody with a binary string find and
replace with Z80 set smarts can do it:
--
AMPRO LITTLE BOARD Z80 I/O and MEMORY MAP
The Ampro Little Board Z80 EPROM is initially imaged in the lowest 4KB's
and this is reflected ambiguously 8 times, up to the 32K boundary. After
boot the lower 32K DRAM is mapped in, for a total of 64KB and the EPROM
is inaccessible thereafter in CP/M without a lot of care, that is! I
managed it and pirated a copy into a soft loader for use of the monitor
EPROM (different than the boot EPROM, a bonus) in software. Ask if you
want a copy by email or in an EPROM and give me your address!
There is an 8-bit control register located at I/O 00Hex. All bits are
cleared at reset. These are:
Bit 7 6 5 4 3 2 1 0
BCR X EEN DDEN SD1 DS4 DS3 DS2 DS1
---------------------------------------------
Where:
X = don't care
EEN EPROM enable 0=enabled in lower 32KB
1= disabled, replaced by DRAM
DDEN = Double-Density enable 0=enabled 1=disabled
SD1 = Side 1, 1=floppy side 1 , of two (0 and 1, 0=bottom)
DS4, DS3, DS2, DS1 Floppy Drive Selects
--------
The CTC chip has four independent counter/timers at 40H, 50H, 60H, and
70H in I/O space. It's master clock is the 4MHz system and the 2MHz
clock is the counting clock. These are CTC channels 0, 1, 2, 3 in that
order above in the successive I/O addresses.
Channel 0 is the baudrate generator for DART channel A, serial port A
Channel 1 is the baudrate generator for DART channel B, serial port B
Channel 2 is unused, and is available for user applications.
Channel 3 can be used as an optional interrupt for the FDC logic.
The Little Board BIOS doesn't support this use, however.
--------
The DART talks to the serial ports A and B through four non-consecutive
I/O
addresses, 80H, 84H, 88H, and 8CH, which are:
Data A Control A Data B and Control B
--------
Floppy Disk Controller I/O Addresses:
C0H Command Register Write
C1H Track Register Write
C2H Sector Register Write
C3H Data Register Write
C4H Status Register Read
C5H Track Register Read
C6H Sector Register Read
C7H Data Register Read
The DS1-4 of the board control register BCR also are used, of course,
as is the Drive Ready line from the drives to the DART DCDB input pin.
--------
Parallel Port
01H I/O address is the data register for the printer data pins.
02H Any write to this I/O address sets the strobe flip-flop.
03H Any write to this I/O address clears the strobe flip-flop.
The BUSY signal, pin 10, is connected to the DART RIB input, and
the DART channel B status register is read for RIB status. You must
first send the DART a channel B "reset external status" command to
correctly read the BUSY signal. RIB is inverted so that BUSY = 0
is RIB HI.
--------
That's it, except to check for ambiguous I/O addressing.
The ambiguities are listed as follows:
---------------------------------------------
Board Control Register 000xxx00
Parallel Port Data Latch 000xxx01
Parallel Strobe Set 000xxx10
Parallel Strobe Clear 000xxx11
CTC 01xxxxxx
DART 10xxxxxx
FDC 11xxxxxx
Unused, available to user 0011xxxx
Unused, reserved 0010xxxx
----------------------------------------------
Well, that's it! Hope you enjoyed it. ;->
-Steve Walz rst...@armory.com
Richard Erlacher
to rebuild the AMPRO?
If that were on the list of things to do, which it really isn't, I'd
start from scratch and omit the DRAMs, omit the Z80 peripherals, put
in a REAL printer port, and run the speed up, say, to 19.6608 MHz,
which is a harmonic of the common baud rates.
What I've been writing about in the past has been taking an existing
1980's series PCB and modifying it so it would do more. There's no
reasonable way to do this on an Ampro Little board, of which I've only
seen and used the FIRST release, which I liked because of the
packaging it allowed me to use, and I see little benefit in building a
new one. Unless one builds his own from scratch, the board is
organized in such a way that there's little room for anything else to
be added, and replacing one thing with another would be a waste of
time in view of the ease of building a new, improved version from
scratch.
The Ampro Software is clearly marked as belonging to them and forbids
its use with anything other than Ampro hardware. That software works
quite well with the hardware for which it was written, and if you want
to change the hardware, it would be little improvement to use software
made for different hardware, in light of the fact you'd be changing
the disk-related portions. There are features that work well with the
original that wouldn't serve so well with a changed hardware map.
Dick
On Sat, 23 Sep 2000 01:16:42 -0700, Steve <rst...@armory.com> wrote:
>Richard Erlacher wrote:
>>
>> It's only bad in the sense that (1) the on-board decoding is
>> ambiguous and (2) there's really not much room for such additonal
>> stuff. It would be MUCH less work to build the system from scratch as
>> I've already suggested. There isn't any parallel I/O left for drive
>> selection, let alone for fiddling with things like head-load timing,
>> etc. The code would be pretty straightforward, but Ampro did a couple
>> of things that I'd be loath to give up. One of these is the insertion
>> of their phantom drive for allowing copying to/from foreign formats.
>>
>> The other thing, sadly, is that they used those awful Z-80
>> peripherals. Those limit system performance to whatever the slowest
>> peripheral can tolerate.
>>
>> Dick
Richard Erlacher
Clearly, you miss the point regarding ambiguous decoding. What that
does is make your hardware appear to be in more than one location.
Unfortunately, it often results in some hardware occupying multiple
I/O locations, thereby limiting where other hardware can live. That
limits one greatly. The problem with that is that there are few
regions of I/O that can be used for anything useful as a result.
There's nothing wrong with that approach, so long as you don't try to
expand the system. THAT's where the trouble comes up. This could
easily be fixed by removing all the SSI logic and replacing it with a
PAL. Then one could more easily expand the I/O. However, there's
also that rather limiting control register . . . and then there's that
really badly lobotomized printer port . . . And they use individual
I/O bits from some of the peripherals to help with the disk I/O, among
other things. All this is FINE in the original Ampro, but for a more
generalized use, it's a mess!
Dick
On Sat, 23 Sep 2000 01:28:48 -0700, Steve <rst...@armory.com> wrote:
>Richard Erlacher wrote:
>>
>> Sadly, pulling the DRAM and MUX's still doesn't solve the most serious
>> problem, the ambiguous decoding. It also doesn't really save much
>> space, since the board is still used. We're not talking new board
>> here, Allison, we're considering a hack of the existing. If I were
>> building a new board, it would not dally at 4 or 6 MHz since there are
>> 20 MHz parts available for $8 per.
>>
>> Dick
Lee Hart
> Are there any schematics available on the Net or off for this old
> venerable so that one might build another??
Allison suggested the Little Board would be easier to build, or perhaps
a new design based on the Ampro Little Board.
In these days of "free" memory, huge disks, and fast CPUs, building the
hardware is the easy part. The software is the problem. Writing a BIOS,
FORMAT, and configuration utilities for a new computer will take a lot
longer than building the computer itself.
That's why I would suggest picking a machine for which VERY complete
software is readily available. Even though it can make the hardware hard
to build, it will save a lot of time debugging and getting it running if
you KNOW the software you have is working.
You can make changes in the hardware design as long as you are SURE they
don't have any effect on software. For example, replacing 64kx1 dynamic
RAMs with two 32kx8 static RAMs.
I happen to like the Heathkit computers, because they have very clear
schematics and published source code listings for their BIOS. However,
I'm sure there are other candidates as well.
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
Harold Bower
>
> Steve asked:
> > Are there any schematics available on the Net or off for this old
> > venerable so that one might build another??
>
> a new design based on the Ampro Little Board.
>
> In these days of "free" memory, huge disks, and fast CPUs, building the
> hardware is the easy part. The software is the problem. Writing a BIOS,
> FORMAT, and configuration utilities for a new computer will take a lot
> longer than building the computer itself.
To see what one person's idea to 'clone' the AmproLB (Z80 version), drag
out the schematics for the YASBEC. Paul Chidley basically did just
that! Instead of DRAM, he had 2 SRAM sockets for 32kx8 thru 512k x 8
chips needing only a different 16L8 PAL for decoding. The floppy
controller was the same (WD 1771 or 1772), same parallel printer port
addressing, etc. While the later YASBECs used a custom BIOS (one of
Paul's friends, I forget his name), the original was so similar to the
Ampro that it didn't make it out.
After working with YASBECs for a while (I now have four), many of the
limitations surface, one of the main being the floppy controller. For
that reason, I have replaced the WD part with a National Semi part and
get 1.76MB on 3.5" HD, and 1.44MB on 5.25" HD drives. The mods was in
(the last?) TCJ issue.
Hal
Richard Erlacher
In answer to the original query, Yes, the schematics are available, in
scanned form, from me, once I get around to scanning them. I could,
of course, get copies made, given aaaaan emailed request.
Your point is well taken. However, it depends largely on what a
person's goals are. As it happens, I'm more interested in taking
these old computers and hot-rodding them as opposed to building them
from scratch. That's just a preference, and I'm not against re-use of
an existing software set by careful emulation of the hardware for
which it was designed.
From the standpoint of modifying existing circuits, the Little Board
is a poor choice, for reasons I've already repeated a couple of times.
From the standpoint of using existing software, Ampro is also poor
choice, (a) because their software is clearly marked as indtended for
use on AMPRO hardware only, and (b) because the owner of the rights to
that software is still conducting business under the same trade name,
AMPRO. Without their permission it would be a clear violation of law
and ethics to utilize their software.
If one makes small changes in the BigBoard hardware, it's hard to tell
whether the hardware is Kaypro, Xerox, or Ferguson Engineering. It's
even difficult to distinguish most of the low-level software for the
BigBoard-1 and the BigBoard-II, though there are some glaring
differences. The code is pretty similar, however.
My statements have been made from the viewpoint that IF you have an
AMPRO Little Board and a Ferguson BigBoard, the Ferguson product
offers many more choices as far as "improvement" or "hot-rodding"
might be concerned. I've mapped out a plan for expanding the
Big-Board-I memory to 1 MB of main memory, and using the same signal
set to refresh an 8 MB array for ramdisk use. I've also worked out a
scheme for running the existing 2.5 MHz peripherals together with a
speed switch that enables the processor to run at 20 MHz when a Z-80
peripheral is not involved. I've also cooked up yet another
double-density upgrade, of which there are many, for the
single-density-only FDC that's on the original. Unfortunately, I'm
still unable to decide the best way to deal with the problems
associated with those $#@#$! Z80 peripherals when mode-2 interrupts
are in use.
I personally see no advantage to using mode-2 interrupts in a system
like this, particularly in view of the penalty in performance, but
that shouldn't influence someone else's choices. Im not even sure
that interrupts are used in the Big Board software, That doesn't
speak well for the level of research I've done in the software, but
I'd certainly want to dispense with the business of interrupts just to
make the speed switch simpler. In any case, it looks, for now, like
I'm going to support the Mode-2 interrupts by making ALL interrupt
service routines operate at 2.5 MHz, that is, run the CPU at 2.5 for
I/O cycles and while interrupts are pending. It's ugly but it's what
was built in once the decision was made to use those Z80-specific
interrupts. Unfortunately, that rules out supporting disk I/O with
interrupts, since the 2.5 MHz Z80 isn't fast enough to do an elegant
job with DD 8" diskettes.
If one were motivated enough to scratch-build a Z80 system, it would
be MUCH easier and smarter to use 82xx Intel peripherals rather than
the Z-80 peripherals. There are plenty of code snippets for the Intel
peripherals.
The mode-2 interrupt was designed because it is faster. It isn't
MUCH faster, but if the CPU has to run at 1/8 the speed to service the
interrupt, the benefit is lost.
What I would have to ask is, "What is the objective of building a
system from scratch? New hardware can't run the CP/M software any
better than any of several pretty good emulators that run on a PC. If
one is unwilling to write one's own software, why not just run the
PC-based emulator. That runs the CP/M code just fine, many times
faster than the original hardware, and even allows the user to program
in high-level languages and run the resulting product of the compiler.
The only reason I can see for going to all that trouble, i.e. writing
new BootRom and BIOS code for new hardware is to improve a specific
function. For example, I'm looking at the question of WHICH of
several processors to use in a diagnostic tool for the S-100 bus,
This is a single-card system with n on-board HDD and FDD, that plugs
into an S-100 bus and attempts to diagnose various problems. The V-50
is in the lead right now, since it can use 8086 code for I/O, yet can
emulate the 8080 at several times real-time. We'll see, though I'd
never do that to build a system that won't be as fast as an emulated
system on the PC.
Please see remarks I've embedded in the quoted post below.
Dick
On Sat, 23 Sep 2000 16:24:26 GMT, Lee Hart <leea...@earthlink.net>
wrote:
>Steve asked:
>> Are there any schematics available on the Net or off
>> for this old venerable so that one might build another??
>
>Allison suggested the Little Board would be easier to build, or perhaps
>a new design based on the Ampro Little Board.
>
>In these days of "free" memory, huge disks, and fast CPUs, building the
>hardware is the easy part. The software is the problem. Writing a BIOS,
>FORMAT, and configuration utilities for a new computer will take a lot
>longer than building the computer itself.
>
Yes, the hardware's the easy part, but building new hardware to run
existing software is totally without warrant.
Where is memory free, other than on the old PC motherboard lying in
the closet? Of what use are the "huge" hard disks, when all the CP/M
software, documentation, source code, etc, will easily fit within <100
MB? How would you endeavor to use such resources without rebuilding
your BIOS? What's the big deal about rewriting a BIOS, anyway? S-100
users had to do that every time they added a new facility to their
computer. CP/M provides you with the tools with which to do that.
Further, what does it help to try to run existing software on
hardware that can't talk to the "huge" disks, and can't use drives
greater than 8 MB in size, and can't use more than 16 drives. If you
want to use software that relies on those things, it's not CP/M.
>
>That's why I would suggest picking a machine for which VERY complete
>software is readily available. Even though it can make the hardware hard
>to build, it will save a lot of time debugging and getting it running if
>you KNOW the software you have is working.
>
That includes almost any CP/M system. I guess what matters is what
you have. Making a system that doesn't work run to your satisfaction
is a valid objective, however. If you're going build it yourself, it
makes little sense to copy something someone else has already done in
hardware. The only ting I would want to do under such circumstances,
is fix the mistakes. That means change the hardware, which requires
subsequent rework of the software.
>
>You can make changes in the hardware design as long as you are SURE they
>don't have any effect on software. For example, replacing 64kx1 dynamic
>RAMs with two 32kx8 static RAMs.
>
That turns out to be the only sort of change you can make, aside,
perhaps from speed. Both are transparent to software.
>
>I happen to like the Heathkit computers, because they have very clear
>schematics and published source code listings for their BIOS. However,
>I'm sure there are other candidates as well.
>
There are many! Open hardware and low-level (driver) software were
the rule rather than the exception in the CP/M days. Only the
packaged powered, ready to use systems got by with their omission.
nos...@nouce.bellatlantic.net
wrote:
>Yes! AND the 82xx peripherals don't have to look over the CPU's
>shoulder to find their interrupt acknowledge.
>
>Dick
I know that but the price you pay is that the interrupt structure is
either simpler (single level single address) as it is done in the
Vt180 (one interrupt for all four 8251s) and the routine has to poll.
The alternative is 74148+logic, 8214+logic or 8259(awful part).
Still the timing independance of any of those compared to Zilog
peripherals is useful.
Since I ahve some 8214s I use that to make a 8level vectored
scheme that uses z80 interrupt mode 2.
Allison
nos...@nouce.bellatlantic.net
wrote:
>etc. The code would be pretty straightforward, but Ampro did a couple
>of things that I'd be loath to give up. One of these is the insertion
>of their phantom drive for allowing copying to/from foreign formats.
that bios feature is easy to keep even if the io system is revised.
the basics of it is to do a BDOS logical to BIOS logical translation
(table lookup mostly) and that table point to physical drivers OR
logical drivers that point to physical drivers. Crafty, yes and
useful as it also allow for remapping drives to make A the fisrt
partition on the hard disk B: a floppy C: hard disk a partition and
E: the phantom floppy (useful with DOSDISK).
>The other thing, sadly, is that they used those awful Z-80
>peripherals. Those limit system performance to whatever the slowest
>peripheral can tolerate.
True but 85c30s (a dual SIO with DMA) does run to 10+ MHz.
Allison
nos...@nouce.bellatlantic.net
wrote:
>If that were on the list of things to do, which it really isn't, I'd
>start from scratch and omit the DRAMs, omit the Z80 peripherals, put
I'd dump the Dram for static. Like I said 2 chips (ram and decode)
replaces 13.
Zilog periphs, I'd keep them as they are pretty simple and run slower.
I can still find 6 and 8mhz parts easily.
>in a REAL printer port,
there is one already but it's 1985 real. What you mean is an
EPP or ECP port and yes that would be much more useful.
> and run the speed up, say, to 19.6608 MHz,
>which is a harmonic of the common baud rates.
no z80s around above 10mhz. To get that speed you are
talking Z80S which has 2 serial ports and more but is z180
(might as well do a SB180 then).
The Z180 difference is small but we are not talking a z80 as in the 40
pin dip that is so common (note most of those are 4mhz parts that
will run to 5 maybe 6).
>What I've been writing about in the past has been taking an existing
>1980's series PCB and modifying it so it would do more. There's no
>reasonable way to do this on an Ampro Little board, of which I've only
>seen and used the FIRST release, which I liked because of the
the first release is actually a rare board as the LB+ is far more
common and yes a better product.
>The Ampro Software is clearly marked as belonging to them and forbids
>its use with anything other than Ampro hardware. That software works
It was, and where is ampro now? Have you asked permission?
>quite well with the hardware for which it was written, and if you want
>to change the hardware, it would be little improvement to use software
>made for different hardware, in light of the fact you'd be changing
>the disk-related portions. There are features that work well with the
>original that wouldn't serve so well with a changed hardware map.
But I've done it and most of the logical portions do NOT care about
hardware beyone a 64k memory map and there being disk hardware
(even if over a serial port).
Allison
nos...@nouce.bellatlantic.net
wrote:
>Sadly, pulling the DRAM and MUX's still doesn't solve the most serious
>problem, the ambiguous decoding. It also doesn't really save much
>space, since the board is still used. We're not talking new board
>here, Allison, we're considering a hack of the existing. If I were
>building a new board, it would not dally at 4 or 6 MHz since there are
>20 MHz parts available for $8 per.
>
>Dick
Context Dick... I'd not change the AMPROLB. I'm talking building
(with a wrirewrap gun or PC fab) from the ground up and in that
context its as good a basic idea as any.
I will add that someone started with the idea of BUILDING something
and not hacking the daylights out of an existing board. IF that
person had an Ampro or BBII or whatever I doubt this line of dilog
would exist.
In that context of BUILDING from scratch and not being a rocket
scientist a design like AmproLB simplified to static ram somethign
similar is very buildable with parts that the average joe seems to be
able to find in bucket loads as junk.
Allison
nos...@nouce.bellatlantic.net
>It's not SO horrible, look, anybody with a binary string find and
>replace with Z80 set smarts can do it:
>--
>
>AMPRO LITTLE BOARD Z80 I/O and MEMORY MAP
>
>The Ampro Little Board Z80 EPROM is initially imaged in the lowest 4KB's
>and this is reflected ambiguously 8 times, up to the 32K boundary. After
this is so you can use a 2732, 2764 or 27128 and the LB+ accepts all
those. even if that were not true like you indicate no harm no foul.
>boot the lower 32K DRAM is mapped in, for a total of 64KB and the EPROM
>is inaccessible thereafter in CP/M without a lot of care, that is! I
Correct and this is not a bad thing. though by hitting bit6 of the IO
control register the rom can be turned on and used (with a 32k part I
put some of the bios code there).
>managed it and pirated a copy into a soft loader for use of the monitor
>EPROM (different than the boot EPROM, a bonus) in software. Ask if you
>want a copy by email or in an EPROM and give me your address!
Check the WC CP/M cdrom (for get where, in oneof the archives) much
of the code was publshed as part of a BYTE article.
>There is an 8-bit control register located at I/O 00Hex. All bits are
>cleared at reset. These are:
>
>Bit 7 6 5 4 3 2 1 0
>BCR X EEN DDEN SD1 DS4 DS3 DS2 DS1
>---------------------------------------------
>Where:
>X = don't care
oops you have 9 bits!
>EEN EPROM enable 0=enabled in lower 32KB
> 1= disabled, replaced by DRAM
>DDEN = Double-Density enable 0=enabled 1=disabled
>SD1 = Side 1, 1=floppy side 1 , of two (0 and 1, 0=bottom)
>DS4, DS3, DS2, DS1 Floppy Drive Selects
Looking at the CPU-2b schemtaics and manuals
Bit7 FDCinit (FDC reset)
bit6 EEN (eprom endable/disable)
bit5 DDEN (double density)
bit4 SD1 (side)
bit3 DS4 (FDC select)
bit2 DS3
bit1 DS2
bit0 DS1
this is correct:
>EEN EPROM enable 0=enabled in lower 32KB
> 1= disabled, replaced by DRAM
>DDEN = Double-Density enable 0=enabled 1=disabled
>SD1 = Side 1, 1=floppy side 1 , of two (0 and 1, 0=bottom)
>DS4, DS3, DS2, DS1 Floppy Drive Selects
>The CTC chip has four independent counter/timers at 40H, 50H, 60H, and
>70H in I/O space. It's master clock is the 4MHz system and the 2MHz
>clock is the counting clock. These are CTC channels 0, 1, 2, 3 in that
>order above in the successive I/O addresses.
Teo of the timers are use for SIO baud clock. The third is used for
FDC interrupt and NCR5380 scsi interrupt.
>Channel 0 is the baudrate generator for DART channel A, serial port A
>Channel 1 is the baudrate generator for DART channel B, serial port B
>Channel 2 is unused, and is available for user applications.
>Channel 3 can be used as an optional interrupt for the FDC logic.
>The Little Board BIOS doesn't support this use, however.
it does if there is SCSI Eprom.
>Floppy Disk Controller I/O Addresses:
>C0H Command Register Write
>C1H Track Register Write
>C2H Sector Register Write
>C3H Data Register Write
>C4H Status Register Read
>C5H Track Register Read
>C6H Sector Register Read
>C7H Data Register Read
>
>The DS1-4 of the board control register BCR also are used, of course,
>as is the Drive Ready line from the drives to the DART DCDB input pin.
This is coincidental as those addresses will map to the 1793 as well.
Other than the control register you have it all right.
My source is the schematic and tech manual that
came with my AmproLB 15 years ago. Yes I
preserve books as they are often more valuable
than the actual hardware.
Allison
nos...@nouce.bellatlantic.net
wrote:
>expand the system. THAT's where the trouble comes up. This could
>easily be fixed by removing all the SSI logic and replacing it with a
>PAL. Then one could more easily expand the I/O. However, there's
Ampro did that in the CPU-2b IC5 a 10L8.
>also that rather limiting control register . . . and then there's that
They retained the control reg. as I mapped it. one message back.
I find that handy as I used a 32k part and put goodies into the part
above the basic 4k they used.
>really badly lobotomized printer port . . . And they use individual
it is not, It was as printer ports of the day were. The BBII, kaypro
and even the IBM XT were not much better. Me, I'd use a bit
from the control reg (dden is a waste for me) and use that to disable
the output reg and parallel inthe 8bit input reg to get a basic
bidirectional port. An ECP design is better and if I were BUILDing
Id do that to have a slew of extra bits.
>I/O bits from some of the peripherals to help with the disk I/O, among
>other things. All this is FINE in the original Ampro, but for a more
>generalized use, it's a mess!
Well they are the side effect of the 1770. It only does part of the
FDC interface (in 1985 that was pretty good!). so you need some bits
for the rest of the control. Thats why I said yu could use a 1793
in the 1770s place if you have something like the 9229 to handle the
FDC cip to disk data sep and clock gen.
Allison
Richard Erlacher
Dick
On Sat, 23 Sep 2000 12:50:21 -0400, Harold Bower
<halb...@cablespeed.com> wrote:
>Lee Hart wrote:
>>
>> Steve asked:
>> > Are there any schematics available on the Net or off for this old
>> > venerable so that one might build another??
>>
>> Allison suggested the Little Board would be easier to build, or perhaps
>> a new design based on the Ampro Little Board.
>>
>> In these days of "free" memory, huge disks, and fast CPUs, building the
>> hardware is the easy part. The software is the problem. Writing a BIOS,
>> FORMAT, and configuration utilities for a new computer will take a lot
>> longer than building the computer itself.
>
>To see what one person's idea to 'clone' the AmproLB (Z80 version), drag
>out the schematics for the YASBEC. Paul Chidley basically did just
>that! Instead of DRAM, he had 2 SRAM sockets for 32kx8 thru 512k x 8
>chips needing only a different 16L8 PAL for decoding. The floppy
Careful now! I hate to see people wandering down this path, which
leads to much confusion.
The 1771 is a very old WD chip capable of only FM recording while the
1770, 1772, and 1773 were among the very last 17xx series parts made
at Western Digital and only barely support use with 8" drives, yet
support both FM and MFM.
Richard Erlacher
(where the most important feature was the "LITTLE" and everything else
was secondary) would you? That was specifically designed for
NON-expandability.
I'd submit that the Big Board was a much better model for the
home-hacker. What's more, it has its own on-board video and uses a
parallel keyboard, so you don't have to purchase/maintain a terminal.
If I were doing what you suggest, I'd use a bunch of Intel
peripherals and a WD controller, and use an IDE interface to a
leftover drive in the desk drawer. Those Z-80 peripherals were fine
so long as they matched, exactly, the CPU speed. ZILOG doesn't make
the peripherals in speeds above 10 MHz, though their CPU is available
at 20 MHz.
Dick
On Sat, 23 Sep 2000 19:03:02 GMT, nos...@nouce.bellatlantic.net wrote:
>On Sat, 23 Sep 2000 05:18:20 GMT, ed...@hotmail.com (Richard Erlacher)
>wrote:
>
>>Sadly, pulling the DRAM and MUX's still doesn't solve the most serious
>>problem, the ambiguous decoding. It also doesn't really save much
>>space, since the board is still used. We're not talking new board
>>here, Allison, we're considering a hack of the existing. If I were
>>building a new board, it would not dally at 4 or 6 MHz since there are
>>20 MHz parts available for $8 per.
>>
>>Dick
>
>
Richard Erlacher
>On Sat, 23 Sep 2000 15:45:23 GMT, ed...@hotmail.com (Richard Erlacher)
>wrote:
>
>>If that were on the list of things to do, which it really isn't, I'd
>>start from scratch and omit the DRAMs, omit the Z80 peripherals, put
>
>I'd dump the Dram for static. Like I said 2 chips (ram and decode)
>replaces 13.
>
The decoding can be provided in a PAL along with the decoding for
everything else, so one chip replaces all the DRAM support logic and
decodes the I/O as well..
>
>Zilog periphs, I'd keep them as they are pretty simple and run slower.
>I can still find 6 and 8mhz parts easily.
>
Arrow sells all the Zilog peripherals at speeds up to 10 MHz, though
I'm not sure about a DMA. That may have quit at 6 or 8. It's not
necessary anyway.
>
>>in a REAL printer port,
>
>there is one already but it's 1985 real. What you mean is an
>EPP or ECP port and yes that would be much more useful.
>
No, not ECP or EPP. Just one that monitors busy and the error flags,
and can send 8 bits + strobe, and can reset the printer as well as
operating its auto-linfeed and select. It would be helpful, too, if
it were provided with some input, for those occasions when you want to
do somethiing useful.
>
>> and run the speed up, say, to 19.6608 MHz,
>>which is a harmonic of the common baud rates.
>
>no z80s around above 10mhz. To get that speed you are
>talking Z80S which has 2 serial ports and more but is z180
>(might as well do a SB180 then).
>
I'd recommend you check the ZILOG web site again. The 40-pin
Z84C00-20's cost about $8 at Arrow. You could check their web site as
well in case the price has changed.
nos...@nouce.bellatlantic.net
wrote:
>In these days of "free" memory, huge disks, and fast CPUs, building the
>hardware is the easy part. The software is the problem. Writing a BIOS,
>FORMAT, and configuration utilities for a new computer will take a lot
>longer than building the computer itself.
maybe. the BIOS is not as mysterious as many seem to think. Config
utilities are handy and likely can be copied or modifies from many
that exist out there. Format... seriously it's the most trivial of
programs and even the existant one can be used if you stay with one of
the WD chips. The formatter for the 765 and clones is also trivial.
in both cases you build a track image of data (different for WD and
765) and play it to the FDC in format mode then go to next track
and update the track number bytes and write again until done. Then go
back and read each track to verify.
If ther was anything I could say to a new cpm user...
Have and use an emulator, handy software design and
test platform.
Get/find a real CP/M box (anything) to see what
real hardware is like.
With that as a starting point building a system to spec is far easier
as you need a development platform anyway.
>I happen to like the Heathkit computers, because they have very clear
>schematics and published source code listings for their BIOS. However,
>I'm sure there are other candidates as well.
Yes there are many. though after 10-20 years finding them or more
importantly the docs can be a minor challenge.
Since I have docs for the DEC Vt180 and about 20 or so others that I
have actual samples of it's easier for me to make the choice.
my systems, all run cpm:
North*Star Horizon S100 (2) (one I built in 1977)
Compupro S100
Califonia Computer Systems CCS2200 S100
My design in a Compupro box S100 (multi Z80)
Netronics Explorer8085
Processor tech SOL-20
AmproLB+ (3.5" floppies and 45mb scsi disk)
Micromint SB180 (64180)
Kaypro 4/84
North*Star Advantage
Epson PX-8
DEC Vt180 (one complete and 15 spare boards)
DEC VT180 board configured as standalone
(boxed rather than in VT100 terminal)
Visual1050 CP/M 3 with hard disk (3)
DEC DECmateIII with CP/M APU card (cmos PDP-8 with Z80)
kluge-I an 8085(6mhz cpu) using 8257 DMA, 8259Interupt,
64k static, 8274 (dual sio like), and 765.
my greatest hack is a trs80 (Arev board) with revised memory map to be
CP/M compatable (ram at 0000). I moved all the IO to the top of
memory, used 64k drams, and modded the roms to phantom to 0000 at
reset, added lower case... and all in the same box. the box off the
bus adds serial io and disk.
Allison
Richard Erlacher
Dick
On Sat, 23 Sep 2000 18:47:49 GMT, nos...@nouce.bellatlantic.net wrote:
>On Sat, 23 Sep 2000 05:13:00 GMT, ed...@hotmail.com (Richard Erlacher)
>wrote:
>
>>etc. The code would be pretty straightforward, but Ampro did a couple
>>of things that I'd be loath to give up. One of these is the insertion
>>of their phantom drive for allowing copying to/from foreign formats.
>
>that bios feature is easy to keep even if the io system is revised.
>the basics of it is to do a BDOS logical to BIOS logical translation
>(table lookup mostly) and that table point to physical drivers OR
>logical drivers that point to physical drivers. Crafty, yes and
>useful as it also allow for remapping drives to make A the fisrt
>partition on the hard disk B: a floppy C: hard disk a partition and
>E: the phantom floppy (useful with DOSDISK).
>
What I've seen work even more to my own taste is making the RAMDISK
drive A. Unfortunately, CP/M requires extensive modification (into
something else) to support enough drives to allow the use of
larger-than-8MB drives, so it gets unwieldy. I'd hate to have to wade
into a new system to see what's what where these features are
concerned. The versons I have of the Ampro disk utilities all seem to
expect 'E' to be the phantom drive. If I want two 5-1/4" drives (48
and 96 TPI, two 3-1/2" drives ( one HD + one of the older 800K types)
and two 8" drives, there's not much space for hard disks.
>
>>The other thing, sadly, is that they used those awful Z-80
>>peripherals. Those limit system performance to whatever the slowest
>>peripheral can tolerate.
>
>True but 85c30s (a dual SIO with DMA) does run to 10+ MHz.
>
Unfortunately it's not so well supported with software. I don't mind
the 8530 series parts because they don't look over the CPU's shoulder
for their interrupt acknowledge, so you can use waits to interface
them if needed. That wasn't around when most CP/M systems were being
designed.
>
>Allison
>
nos...@nouce.bellatlantic.net
<halb...@cablespeed.com> wrote:
Hal makes an important point... TCJ reprints are still
available with YASBEC and friends in there.
VOLUME 1 or II bound has a 4mb ramdisk for AmproLB
as an expansion option and also several issues address
the idea and implmentation of a 8mhz AmproLB.
Allison
Richard Erlacher
software (before 1985) I never found even one that actually used
interrupts. They made all sorts of hardware and software compromises
to support the things, often increasing cost and memory use by quite a
little but quite obviously seldom used them.
I don't find any excuse for CP/M, which is a single-task, single-user
system to mess with interrupts at all. If it weren't for the
overhead, it might be useful to use them for some I/O tasks, but I
doubt it. The OS is normally waiting for input anyway.
Dick
On Sat, 23 Sep 2000 18:41:40 GMT, nos...@nouce.bellatlantic.net wrote:
>On Sat, 23 Sep 2000 05:14:29 GMT, ed...@hotmail.com (Richard Erlacher)
>wrote:
>
>>Yes! AND the 82xx peripherals don't have to look over the CPU's
>>shoulder to find their interrupt acknowledge.
>>
>>Dick
>
nos...@nouce.bellatlantic.net
wrote:
>>I'd dump the Dram for static. Like I said 2 chips (ram and decode)
>>replaces 13.
>>
>The decoding can be provided in a PAL along with the decoding for
>everything else, so one chip replaces all the DRAM support logic and
>decodes the I/O as well..
No reason why not.
>>Zilog periphs, I'd keep them as they are pretty simple and run slower.
>>I can still find 6 and 8mhz parts easily.
>>
>Arrow sells all the Zilog peripherals at speeds up to 10 MHz, though
>I'm not sure about a DMA. That may have quit at 6 or 8. It's not
>necessary anyway.
The DMA is limited or they gave up at 4mhz. An alternate is the
Zbus parts like the 85c30 as that is a dual SIO and dual DMA
that runs at 10mhz and faster.
>No, not ECP or EPP. Just one that monitors busy and the error flags,
>and can send 8 bits + strobe, and can reset the printer as well as
Correct and that was the norm in 1985... EPP would be better.
>>no z80s around above 10mhz. To get that speed you are
>>talking Z80S which has 2 serial ports and more but is z180
>>(might as well do a SB180 then).
>>
>I'd recommend you check the ZILOG web site again. The 40-pin
>Z84C00-20's cost about $8 at Arrow. You could check their web site as
>well in case the price has changed.
>>The Z180 difference is small but we are not talking a z80 as in the 40
>>pin dip that is so common (note most of those are 4mhz parts that
>>will run to 5 maybe 6).
Arrow wish book. I wish they would supply some of the things I've
ordered.
then again have neary 4 tubes of 4/6 mhz z80s and maybe a tube of
84c050s (10mhz cmos z80 40 pin with clock control, wait, ram). Some
things dont demand going fast and those slow parts are easy to use
and quite free of cost.
Allison
Richard Erlacher
Dick
On Sat, 23 Sep 2000 19:43:08 GMT, nos...@nouce.bellatlantic.net wrote:
>On Sat, 23 Sep 2000 15:55:03 GMT, ed...@hotmail.com (Richard Erlacher)
>wrote:
>
>>expand the system. THAT's where the trouble comes up. This could
>>easily be fixed by removing all the SSI logic and replacing it with a
>>PAL. Then one could more easily expand the I/O. However, there's
>
>Ampro did that in the CPU-2b IC5 a 10L8.
>
>>also that rather limiting control register . . . and then there's that
>
>They retained the control reg. as I mapped it. one message back.
>I find that handy as I used a 32k part and put goodies into the part
>above the basic 4k they used.
>
>>really badly lobotomized printer port . . . And they use individual
>
>it is not, It was as printer ports of the day were. The BBII, kaypro
>and even the IBM XT were not much better. Me, I'd use a bit
>from the control reg (dden is a waste for me) and use that to disable
>the output reg and parallel inthe 8bit input reg to get a basic
>bidirectional port. An ECP design is better and if I were BUILDing
>Id do that to have a slew of extra bits.
>
I'd certainly agree that the EPP type port would work OK. Even at 20
MHz the Z80 couldn't operate the ECP at a rate suitable to the tasks
for which it's used in the PC environment. After all, it uses the
PC-resident CPU to replace one of several RISC's in a printer, to hold
down the cost. Of course it brings even an 800 MHz Athlon to its
knees, though that's probably just because of the high frequency of
interrupts.
I'm not sure the EPP would work terribly well, but it would provide an
I/O channel where, now, there is none.
>>I/O bits from some of the peripherals to help with the disk I/O, among
>>other things. All this is FINE in the original Ampro, but for a more
>>generalized use, it's a mess!
>
>Well they are the side effect of the 1770. It only does part of the
>FDC interface (in 1985 that was pretty good!). so you need some bits
>for the rest of the control. Thats why I said yu could use a 1793
>in the 1770s place if you have something like the 9229 to handle the
>FDC cip to disk data sep and clock gen.
>
Yes, the emphasis was to make it small, so they used everything that
ws there as fully as they could and left no resources for expansion.
That's the problem with that particular design as a model for a new
build.
>
>Allison
>
Don Maslin
: In answer to the original query, Yes, the schematics are available, in
: scanned form, from me, once I get around to scanning them. I could,
: of course, get copies made, given aaaaan emailed request.
: Your point is well taken. However, it depends largely on what a
: person's goals are. As it happens, I'm more interested in taking
: these old computers and hot-rodding them as opposed to building them
: from scratch. That's just a preference, and I'm not against re-use of
: an existing software set by careful emulation of the hardware for
: which it was designed.
: From the standpoint of modifying existing circuits, the Little Board
: is a poor choice, for reasons I've already repeated a couple of times.
: From the standpoint of using existing software, Ampro is also poor
: choice, (a) because their software is clearly marked as indtended for
: use on AMPRO hardware only, and (b) because the owner of the rights to
: that software is still conducting business under the same trade name,
: AMPRO. Without their permission it would be a clear violation of law
: and ethics to utilize their software.
I'm not sure that this is exactly true, as AMPRO sold the rights to the
Littleboard to Davidge (Buellton CA) some years back when they got into
the PC-104 stuff. Davidge did not survive too long after, so the rights
ownership is something of a mystery - like many CP/M related things.
- don
: If one makes small changes in the BigBoard hardware, it's hard to tell
: Dick
:
:>
:>
nos...@nouce.bellatlantic.net
wrote:
>What I've seen work even more to my own taste is making the RAMDISK
>drive A. Unfortunately, CP/M requires extensive modification (into
>something else) to support enough drives to allow the use of
>larger-than-8MB drives, so it gets unwieldy. I'd hate to have to wade
Install Zrdos/Zsdos. Runs fine on ampro (bios). If not there is
NOVAdos, P2dos, Suprdbos. I've run them all on my Ampro.
All of them side step the 8mb limit and are at the most minimum level
BDOS replacements in that they are the same size (E00h bytes)
and are interchangeable. Run them with the CCP or Zcpr you have
and you dont have to learn anythingif you dont care to.
>concerned. The versons I have of the Ampro disk utilities all seem to
>expect 'E' to be the phantom drive. If I want two 5-1/4" drives (48
>and 96 TPI, two 3-1/2" drives ( one HD + one of the older 800K types)
>and two 8" drives, there's not much space for hard disks.
E; is a logical drive (not phantom). It can be mapped to any of the
hardware. I happen to use if for different formats or DOSdisk
the dos to cpm file transfer utility (works killer with 720k 3.5"
disks). Since my 45mb scsi is partitioned into four 8mb and
one 3mb and the two floppies the map I use works for me.
A: Hd partition 1 cpm boot(3mb partition)
B: floppy
C: Hd partition 2 C programs (8mb part)
D: floppy2
E: logical mapping (usually dosdisk use)
F: HD partition3 Pascal programs (8mb part)
G:HD partition4 Asmbler programs (8mb part)
H:Hd partition 5 misc and basic programs (8mb part)
>>True but 85c30s (a dual SIO with DMA) does run to 10+ MHz.
>>
>Unfortunately it's not so well supported with software. I don't mind
>the 8530 series parts because they don't look over the CPU's shoulder
>for their interrupt acknowledge, so you can use waits to interface
>them if needed.
Since the serial part is SIO what software do you need? It is a SIO!
The DMA is like the z80 DMA.
I have a tube of them and they are nice. the down side is they are
52pin plcc though JDR sells a socket to wirewrap pin adaptor
that is cheap. Also they are not the simple to use z80 bus interface
liek the sio/ctc would use.
>That wasn't around when most CP/M systems were being
>designed.
Neither were EPP ports, 64k srams or 20mhz z80s.
The sio and CTC used in Ampro, Kaypros and friends are
not that fast (so big deal) but, for the novice to building
computer a z80, CTC and SIO with a Eprom(or flash)
and 64k static ram is a trivial design exercise
and adding a 765based or 1793 based FDC to that
make a complete 4mhz z80 cpm engine that is reasonable.
Allison
nos...@nouce.bellatlantic.net
wrote:
>EEEK! You'd not really use that model, designed for the Little Board,
>(where the most important feature was the "LITTLE" and everything else
>was secondary) would you? That was specifically designed for
>NON-expandability.
As was the BBII!!!
>I'd submit that the Big Board was a much better model for the
>home-hacker. What's more, it has its own on-board video and uses a
>parallel keyboard, so you don't have to purchase/maintain a terminal.
Since all them hackers ahve terminals called PCs thats a minimal
issue.
>If I were doing what you suggest, I'd use a bunch of Intel
>peripherals and a WD controller, and use an IDE interface to a
>leftover drive in the desk drawer. Those Z-80 peripherals were fine
>so long as they matched, exactly, the CPU speed. ZILOG doesn't make
>the peripherals in speeds above 10 MHz, though their CPU is available
>at 20 MHz.
Just like the many i've built already. Save for the WD FDC. Never
developed a liking for it and since I worked for NEC (chips) I have an
abundance of 765 and later clones that I'd use instead.
My S100 multi z80 cpu crate was based on intel peripherals and 765.
I've even done the IDE thing. FYI NEC did the 7201 (intel second
source as 8274) wich is a z80 SIO with one big difference it's
8085/8088 (demuxed) bus and interrupt compatable and interfaces
real nice to a 10mhz z80. So I have a real SIO that is faster to boot
both for baud rate and bus side. As to the DMA thing, 8257 or 8237
as both have a real TC (zilog doesnt) and they can run at 12mhz
plus for the bus interface and still work nicely.
See the P112 design that Dave Brooks did. Really nice simple Z180
running at speeds in the fast lane with 765clone (37c665) and even the
EPP port you like in a 3.5" format.
Allison
nos...@nouce.bellatlantic.net
wrote:
>I'd certainly agree that the EPP type port would work OK. Even at 20
>MHz the Z80 couldn't operate the ECP at a rate suitable to the tasks
>for which it's used in the PC environment. After all, it uses the
>PC-resident CPU to replace one of several RISC's in a printer, to hold
>down the cost. Of course it brings even an 800 MHz Athlon to its
>knees, though that's probably just because of the high frequency of
>interrupts.
Then again if I'm running CP/M programs like Multiplan or dbase-II
to a Epson FX80 or a more recent printer like say a HP4l laser
whats the problem with the original? Like I said for the intended use
it works just fine.
Allison
nos...@nouce.bellatlantic.net
wrote:
>I don't find any excuse for CP/M, which is a single-task, single-user
>system to mess with interrupts at all. If it weren't for the
>overhead, it might be useful to use them for some I/O tasks, but I
>doubt it. The OS is normally waiting for input anyway.
OK, if you say so.
I'll turn them off in the NS* will not work well though, it needs
them. The Ampro, Kaypro, EpsonPX8, visual 1050 and the
real oldie of the bunch (it's pre 1984) VT180 _require_them.
In fact the VT180 use a seperate interrut address (two level think of
that and no zio periphs) for the RTC tick.
I may add that the slew of single board S100 systems (z80 FDC, ram io)
on one s100 card all used interrupts. The 8085 powered AC85 from
Autocontrol (another oldie) used the interrupts as well. FYI that was
a SBC 8085 with DMA, 64k dram (4116s) and intel IO. Ran at 5mhz cpu
speed (not bad for 81).
All the later boxen I have used them too. By 1981 the users were
screaming for and expecting type ahead and doing that without
interrupts was hard. By 1984 if you didn't do that it must be a
prototype or a serious marketing error.
Allison
Steve
>
> Now let me get this straight . . . You think it would be a good idea
> to rebuild the AMPRO?
Redesign it, actually. Nice industrial/robotics controller with such a
huge program base!
> If that were on the list of things to do, which it really isn't, I'd
> start from scratch and omit the DRAMs, omit the Z80 peripherals, put
> in a REAL printer port, and run the speed up, say, to 19.6608 MHz,
> which is a harmonic of the common baud rates.
-----------------------------
Yes, just SRAM and EPROM with CP/M boot in ROM. Add a couple 8255 or a
set of latches and buffers for IDE/SCSI, and the DART goes up to 38.4
kbps and is sufficient. I would also like a library of programs-on-ROM
add-on with SPZ and DDT and NWSP and the common nifty utilities. I
don't need one that fast, but 6MHz would be nice.
> What I've been writing about in the past has been taking an existing
> 1980's series PCB and modifying it so it would do more. There's no
> reasonable way to do this on an Ampro Little board, of which I've only
> seen and used the FIRST release, which I liked because of the
> packaging it allowed me to use, and I see little benefit in building a
> new one. Unless one builds his own from scratch, the board is
> organized in such a way that there's little room for anything else to
> be added, and replacing one thing with another would be a waste of
> time in view of the ease of building a new, improved version from
> scratch.
--------------------------
I'd love to finally design a smaller AmproLB Z80 clone PCB for robotics,
but building it up for development on a big durable 5/32" glas
hole-per-pad0-w-w board I have that is about 12" by 18" on stand off
feet would be what I'd like to do first and with the EPROM library I
mentioned. Lots of room for experimenting. I have used that board for a
few years for a few large wirewrap projects, and the plating just
doesn't come off it! It was made for a big 19" cabinet protoboard for
industrial purposes. But I'd finally like to put something permanent on
it with point to point wiring. Lots of room for a field of EPROMS! The
kind of computer you might like to mount in a picture frame on the wall
under plexi with LEDs!! Blinken Lichte!
> The Ampro Software is clearly marked as belonging to them and forbids
> its use with anything other than Ampro hardware. That software works
> quite well with the hardware for which it was written, and if you want
> to change the hardware, it would be little improvement to use software
> made for different hardware, in light of the fact you'd be changing
> the disk-related portions. There are features that work well with the
> original that wouldn't serve so well with a changed hardware map.
>
> Dick
-----------------
Anybody can use a BIOS like theirs, Dick. A BIOS is just part of a
machine! Whether you use CP/M then or a CP/M clone is sort of
irrelevant. If you need to move a couple things around to defeat some
BIOS copyright complaint, that's easy too!
> On Sat, 23 Sep 2000 01:16:42 -0700, Steve <rst...@armory.com> wrote:
>
> >Richard Erlacher wrote:
> >>
> >> It's only bad in the sense that (1) the on-board decoding is
> >> ambiguous and (2) there's really not much room for such additonal
> >> stuff. It would be MUCH less work to build the system from scratch as
> >> I've already suggested. There isn't any parallel I/O left for drive
> >> selection, let alone for fiddling with things like head-load timing,
> >> etc. The code would be pretty straightforward, but Ampro did a couple
> >> of things that I'd be loath to give up. One of these is the insertion
> >> of their phantom drive for allowing copying to/from foreign formats.
> >>
> >> The other thing, sadly, is that they used those awful Z-80
> >> peripherals. Those limit system performance to whatever the slowest
> >> peripheral can tolerate.
> >>
Steve
>
> Clearly, you miss the point regarding ambiguous decoding. What that
> does is make your hardware appear to be in more than one location.
> Unfortunately, it often results in some hardware occupying multiple
> I/O locations, thereby limiting where other hardware can live. That
> limits one greatly. The problem with that is that there are few
> regions of I/O that can be used for anything useful as a result.
I know the problem, but that goes away when you move a bunch of them
around to lower and less ambiguous port numbers, do-able by hunting up
all the BIOS I/O calls to them and doing a find and replace on them with
a software that will thread all the subroutines and determine the opcode
entries. I've written one in basic, the editing is probably easy. The
memory map is NOT very imposing! I think I counted 24 port numbers used
or less, most of those in contiguous ranges to periphs.
> There's nothing wrong with that approach, so long as you don't try to
> expand the system. THAT's where the trouble comes up. This could
> easily be fixed by removing all the SSI logic and replacing it with a
> PAL.
-----------------
I see PALs/GALs as acceptible for myself and my products (no user
servicable doodah inside), but not for most hobbyists who don't have a
burner for them, and I'd rather move all the I/O to more contiguous
ranges anyway and use as simple a decode as I can get.
> Then one could more easily expand the I/O. However, there's
> also that rather limiting control register . . . and then there's that
> really badly lobotomized printer port . . . And they use individual
> I/O bits from some of the peripherals to help with the disk I/O, among
> other things. All this is FINE in the original Ampro, but for a more
> generalized use, it's a mess!
>
> Dick
---------------
The pport does stink, no input, but a few latches and buffers or 8255's
and that's fixed. Leave the pport for a stupid line printer!!
Steve
Steve
>
> On Sat, 23 Sep 2000 05:18:20 GMT, ed...@hotmail.com (Richard Erlacher)
> wrote:
>
> >Sadly, pulling the DRAM and MUX's still doesn't solve the most serious
> >problem, the ambiguous decoding. It also doesn't really save much
> >space, since the board is still used. We're not talking new board
> >here, Allison, we're considering a hack of the existing. If I were
> >building a new board, it would not dally at 4 or 6 MHz since there are
> >20 MHz parts available for $8 per.
> >
> >Dick
>
> Context Dick... I'd not change the AMPROLB. I'm talking building
> (with a wrirewrap gun or PC fab) from the ground up and in that
> context its as good a basic idea as any.
>
> I will add that someone started with the idea of BUILDING something
> and not hacking the daylights out of an existing board. IF that
> person had an Ampro or BBII or whatever I doubt this line of dilog
> would exist.
>
> In that context of BUILDING from scratch and not being a rocket
> scientist a design like AmproLB simplified to static ram somethign
> similar is very buildable with parts that the average joe seems to be
> able to find in bucket loads as junk.
>
> Allison
Well, does ANYBODY have even qty 10 of the WD1772's??
Or does anybody know a quick conversion to use the 765
that doesn't drive you crazy redoing the BIOS???
I have two of the AmproLB-Z80's and I still want something tinier and
more controller-like but with all the legacy capabilities of CP/M, and
perhaps modify it to use for commercial bots with a different FDC!
-Steve
--
-Steve Walz rst...@armory.com ftp://ftp.armory.com/pub/user/rstevew
-Electronics Site!! 1000 Files/50 Dirs!! http://www.armory.com/~rstevew
Europe Naples, Italy: ftp://ftp.unina.it/pub/electronics/ftp.armory.com
Steve
>
> >Bit 7 6 5 4 3 2 1 0
> >BCR X EEN DDEN SD1 DS4 DS3 DS2 DS1
> >---------------------------------------------
> >Where:
> >X = don't care
>
> oops you have 9 bits!
No, I don't, it's typed out of the AmproLB-Z80 model 1A manual
BCR is just the Bit of Control Register!!!
And the Ampro without the SCSI chip(in 1B model) does NOT use bit 7!!
> Looking at the CPU-2b schemtaics and manuals
>
> Bit7 FDCinit (FDC reset)
> bit6 EEN (eprom endable/disable)
> bit5 DDEN (double density)
> bit4 SD1 (side)
> bit3 DS4 (FDC select)
> bit2 DS3
> bit1 DS2
> bit0 DS1
>
> this is correct:
>
> Other than the control register you have it all right.
-----------------
Look up! ^
|
> My source is the schematic and tech manual that
> came with my AmproLB 15 years ago. Yes I
> preserve books as they are often more valuable
> than the actual hardware.
>
> Allison
---------------
Agreed!
Lee Hart
> I know they're out there, but in 8 years of plowing thorugh CP/M BIOS
> software (before 1985) I never found even one that actually used
> single-user system to mess with interrupts at all.
The Heathkit CP/Ms use interrupts. There is a 2 msec real-time clock
interrupt, whose tick counter gives you elapsed time. It also serves as
the error timer for disk I/O, which avoids many of the system "hangs"
and looooong time delays in case of disk errors. All the serial ports
(including the console) are interrupt-driven. You can keep right on
typing on the keyboard, print, and do disk accesses simultaneously
without and won't miss a character.
I rather miss the responsiveness of the system when using non-Heath CP/M
computers.
Richard Erlacher
>On Sat, 23 Sep 2000 20:11:38 GMT, ed...@hotmail.com (Richard Erlacher)
>wrote:
>
The DMA is almost like that, insn't it. Well, in the cases wherein
I've used serial I/O under CP/M, it's been for (1) the console, and
(2) a modem or (3) a serial printer. The 8530 probably wasn't well
supported in category (2). I'm curious what the DMA would be used for
under CP/M, however.
>
>I have a tube of them and they are nice. the down side is they are
>52pin plcc though JDR sells a socket to wirewrap pin adaptor
>that is cheap. Also they are not the simple to use z80 bus interface
>liek the sio/ctc would use.
>
>>That wasn't around when most CP/M systems were being
>>designed.
>
>Neither were EPP ports, 64k srams or 20mhz z80s.
>
>The sio and CTC used in Ampro, Kaypros and friends are
>not that fast (so big deal) but, for the novice to building
>computer a z80, CTC and SIO with a Eprom(or flash)
>and 64k static ram is a trivial design exercise
>and adding a 765based or 1793 based FDC to that
>make a complete 4mhz z80 cpm engine that is reasonable.
>
I'm still convinced that using the Ampro design would be a frustrating
waste of time. I think there's better chance of success and easy,
smooth, slides-in-like-butter implementation with something more
general, not targeted at keeping the board small, hardware. Aside
from the fact I'd use devices that don't support mode-2 interrupts, it
can't be much different. Look at the example of the SD Systems SBC
100. It has an 8251 and an 8253. Those don't bother the CPU speed at
all. I'm partial to a baud rate generator or a programmble counter,
and not one of the counter/timer LSI's of the '70's, though they're
not bad. With a 19.6608 MHz clock to the Z80, you can use a 74HC4040
and a '151, or the equivalent in a PLD to set the baud rate. That
eleiminates the need for the counter/timer unless you really need to
count or time something.
There's no need to settle for a 4 MHz rate. The 20 MHz CPU is on the
Arrow website at $8 or so. 20 ns SRAMS of 64Kx8 aren't sold much any
more but are probably in the basement on an old PC motherboard. If
you run the CPU slowly, say, 5 MHz you can read an EPROM and copy it
into RAM. Then, when you're done, disable the prom, and switch the
speed to maximum warp.
>
>Allison
Walter Rottenkolber
Richard Erlacher wrote in message <39cd0e9b...@superego.idcomm.com>...
>I know they're out there, but in 8 years of plowing thorugh CP/M BIOS
>software (before 1985) I never found even one that actually used
>to support the things, often increasing cost and memory use by quite a
>little but quite obviously seldom used them.
>
The Kaypro II uses the non-masked interrrupt to time disk sector r/w, but
that's all the interrupts I know about. Other i/o uses polling.
Because the Kaypro bank switches the lower 16KB of RAM to get at the ROM
code and video, you have to use the type 2 int. to put the interrupt code
above 16KB.
Walter Rottenkolber
Richard Erlacher
Please see embedded remarks below.
Dick
On Sat, 23 Sep 2000 21:19:32 -0700, Steve <rst...@armory.com> wrote:
>nos...@nouce.bellatlantic.net wrote:
The 765 simply forced the somewhat friendlier WD controllers off the
market with its lower price. I remember feeling, back when I was
doing FDC/HDC work, that the 765 was more restrictive, not offering as
many format options, etc. Perhaps that's related to the choice, but I
suspect it's just that it was $0.25 cheaper when IBM made the choice
to use it. I don't know that the NEC 765/Intel 8272 is available any
longer either. Unfortunately, I've not seen any 9229's to help reduce
the logic in the 179x application either. I suppose one could do it
with a couple of PALs.
What the 9229 (a 20-pin part) did was read-clock extraction from the
raw data stream, write precompensation, and master clock selection,
based on modulation and drive size. That's quite a bit for a 20-pin
part. It incroporated the functions of the SMC 9216, which was just
the clock-extraction circuit. (maybe it did the master clock muxing
as well, ?)
We'd all benefit from a quick fix as you suggest. That would make
circuits like the WD3765 tempting. WIth their ability to drive the
cable (which the 1770/72/73 do just fine, BTW) these small devices
would make life simpler.
Perhaps you should code a Scenix SX microcontroller to replace the
1770/72/73 function. It's fully capable, both of driving the cable,
and of extracting the data and clock from the bitstream. It operates
at 100 MIPS, is reprogrammable, and costs about $6 in unit quantity.
Architecturally it's a bit richer than a PIC, but otherwise similar,
AND code compatible.
>
>I have two of the AmproLB-Z80's and I still want something tinier and
>more controller-like but with all the legacy capabilities of CP/M, and
>perhaps modify it to use for commercial bots with a different FDC!
>
What kind of currently available FDC would you use? I don't even know
what's out there these days. Since one can buy a PC on a PCB the size
of a playing card, I've not had to worry that issue.
FPGA's and CPLD's are big enough nowadays that you can put your
microcontroller on board along with its complement of memory , both
ROM and RAM. That might offer some help. It's the single-chippers
that have driven the old 8-bit microprocessors off the market.
nos...@nouce.bellatlantic.net
<wal...@sierratel.com> wrote:
>The Kaypro II uses the non-masked interrrupt to time disk sector r/w, but
>that's all the interrupts I know about. Other i/o uses polling.
The 4/84 adds a 1/30th second interrupt with polling loop and some
roms use mode 2 from the devices.
>Because the Kaypro bank switches the lower 16KB of RAM to get at the ROM
>code and video, you have to use the type 2 int. to put the interrupt code
>above 16KB.
Actually you can use mode 0. the presence of rom is not a factor
nor limiting to any great extent. Most CP/M standard mapped systems
dont have permanent rom at 0000 but even if it were interrupts are not
a problem.
Allison
nos...@nouce.bellatlantic.net
wrote:
>>Since the serial part is SIO what software do you need? It is a SIO!
>>The DMA is like the z80 DMA.
>The DMA is almost like that, insn't it. Well, in the cases wherein
It's easier to use and cleaner.
>I've used serial I/O under CP/M, it's been for (1) the console, and
>(2) a modem or (3) a serial printer. The 8530 probably wasn't well
>supported in category (2).
OK, what I'm doing doesnt work then. ;) But it does.
> I'm curious what the DMA would be used for
>under CP/M, however.
My favorite use is block moves in larger than 64k maps for boundary
crossings. Z80 LDIR is nice but if you want to do a mapped system
where you can transfer across active to inactive pages you need
DMA (or play pageing games). Another is DMA supported floppy to
relieve the cpu of the PIO task. It's pretty handy for SIO at rates
in the 100k and faster bracket too as most work at those rates are
packets.
Keep in mind I work to free up cpu cycles to do background tasks.
Things like printer buffers (interrupt driven), disk caching and
runnning fast serial modems and seriving floppies with apparent
concurency requires DMA and interrupts.
>I'm still convinced that using the Ampro design would be a frustrating
>waste of time. I think there's better chance of success and easy,
Thats your limitation. I tried the GIDE mod first time on the Amprolb
and its an approach and it works. All I keep hearing "it can't" and
my answer is "people have", I have and if yoru scratch building
and a terminal is reasonable then why not. For most peole entering
into the CP/M world and many that are not it's sufficient or better
than what they need or want.
>can't be much different. Look at the example of the SD Systems SBC
>100. It has an 8251 and an 8253. Those don't bother the CPU speed at
I have two. One with a Z280 planted on the z80 socket!
>all. I'm partial to a baud rate generator or a programmble counter,
>and not one of the counter/timer LSI's of the '70's, though they're
>not bad. With a 19.6608 MHz clock to the Z80, you can use a 74HC4040
>and a '151, or the equivalent in a PLD to set the baud rate. That
Or 74393s and a 151 like the VT180 did years back. Same thing.
In the case of the AmproLB the CTC is handy in that it does the two
baud rate generators and also by setting the timer to FFFFh and using
the count pin to over flow you get two vectored interrutps (any
mode!). and it's only 28 pins. Each design has different tradeoffs
and I've played with many of them. Each works and each has it's
place.
>There's no need to settle for a 4 MHz rate. The 20 MHz CPU is on the
>Arrow website at $8 or so. 20 ns SRAMS of 64Kx8 aren't sold much any
>more but are probably in the basement on an old PC motherboard. If
I know what they cost. Many apps I do a 20mhz cpu is a total waste
as it would be looping burning cycles for nothing. It's a moot point.
>you run the CPU slowly, say, 5 MHz you can read an EPROM and copy it
>into RAM. Then, when you're done, disable the prom, and switch the
>speed to maximum warp.
Yes I know that... I learned that one back in the '70s... Or I can
buy fast parts. It's a red herring.
Allison
nos...@nouce.bellatlantic.net
>nos...@nouce.bellatlantic.net wrote:
>>
>> >Bit 7 6 5 4 3 2 1 0
>> >BCR X EEN DDEN SD1 DS4 DS3 DS2 DS1
>> >---------------------------------------------
>> >Where:
>> >X = don't care
>>
>> oops you have 9 bits!
>-------------------
>No, I don't, it's typed out of the AmproLB-Z80 model 1A manual
>BCR is just the Bit of Control Register!!!
>And the Ampro without the SCSI chip(in 1B model) does NOT use bit 7!!
I have the 1b book right here and bit 7 is fdcinit (reset the FDC).
Bit 6 is eprom enable.
that "X" you have puzzels me as you list NINE (9) bits across!
I understand the 1a doesn't do SCSI but the effect is very limited
and does not impact the main control register.
Allison
nos...@nouce.bellatlantic.net
>--------------------------
>Well, does ANYBODY have even qty 10 of the WD1772's??
I doubt it, it was short lived.
>Or does anybody know a quick conversion to use the 765
>that doesn't drive you crazy redoing the BIOS???
Not an easy one as programtically they live in different worlds.
>I have two of the AmproLB-Z80's and I still want something tinier and
>more controller-like but with all the legacy capabilities of CP/M, and
>perhaps modify it to use for commercial bots with a different FDC!
delete the Dram, use the 2b deisgn without scsi as the device decodes
are more complete, put the 8255 in place of the scsi chip (different
pinout but similar bus hookup.
There seems to be a great fear of the bios. I'm baffled as it's
actually very well defined interfaces and the code to do it is trivial
if interrupts and DMA are not used. DMA ads some complexity
as its a programable device and interrutps can be difficult until you
see how they are done. See the site <www.psyber.com/~tcj) as
Dave has done much of the work if you look around for a basic z80
board with SIOs and even the serial drivers (source) are there.
Allison
nos...@nouce.bellatlantic.net
wrote:
>>--------------------------
>The 765 simply forced the somewhat friendlier WD controllers off the
>market with its lower price. I remember feeling, back when I was
Friendlier? they are different and beyond that 40 pins still hurt if
I try to cuddle them. ;)
>doing FDC/HDC work, that the 765 was more restrictive, not offering as
For what buggered formats like the TRS80 with the deleted address
mark set? Even the 765 can read that. Most of the time it's
meaningless and if anythingit forced a common standard
(good or bad).
>to use it. I don't know that the NEC 765/Intel 8272 is available any
>longer either. Unfortunately, I've not seen any 9229's to help reduce
They are easy to find yet like 1793s.
>the logic in the 179x application either. I suppose one could do it
>with a couple of PALs.
You can do it in two. I've done it with 7 peices of 74xx TTL.
Of cource you can still fine 37c65s, SMC has the 92Cxxx parts.
Also PCs are a greate source of spares. ;)
>What the 9229 (a 20-pin part) did was read-clock extraction from the
>raw data stream, write precompensation, and master clock selection,
>based on modulation and drive size. That's quite a bit for a 20-pin
>part. It incroporated the functions of the SMC 9216, which was just
>the clock-extraction circuit. (maybe it did the master clock muxing
>as well, ?)
It did it all. I've used them and have a few. I also did a FPGA that
does it. It's not all that hard and a Digital data seperator can be
built with a74288 and a 74176 (clue there).
>We'd all benefit from a quick fix as you suggest. That would make
>circuits like the WD3765 tempting. WIth their ability to drive the
>cable (which the 1770/72/73 do just fine, BTW) these small devices
>would make life simpler.
37c65 and 9265, 37c765 and friends are 765s with all the wrapper
around them. The are so different from the WD 1793/1772/2793
that there is no translation possible.
>Perhaps you should code a Scenix SX microcontroller to replace the
>1770/72/73 function. It's fully capable, both of driving the cable,
knock your self out.
Allison
nos...@nouce.bellatlantic.net
Heres a 765 (also clones) basic driver written back in 1984 for the
first 96tpi drives. I have a CPM bios that uses the proto code for
them and can post it, note the bios is a VERY minimal
in that it assumes 8" CPM standrd format (SSSD) and
NO interrutps.
this also runs on z80 obviously it's coded as 8080 so ASM is used.
To those that may be critical, post better! It's free!
Allison
; DISK I/O FOR 765 USING STALL
; C Allison Parent
; This driver is for a minimal 765 design that assumes
; pseudo DMA by stalling the cpu an 8085 <using the
; READY line> at the begining of a read or write until
; the FDC sends a DRQ <releasing READY>. The chip is
; programmed as if it were running using DMA.
; The drive is assumed to be 5.25" double density
; 96 tpi two sided with 9 512 byte sectors per track.
; 737k formatted space. Step rate is 3ms.
; Other drives or formats are possible.
;
; * all registers (8080 model) used
; * sucess is indicated by 00 returned on ACC
; * failure is indicated by -1 returned ACC
; * Detailed errors/status are stored at ST0->SNbit
;
; -interrputs are not used but can be tested via port
; -TC line on chip is used to terminate transfers, a single
; bit port is used for this.
; -DACK is simulated using a specific port address
; -MOTOR is a single bit for bus motor on/off.
;
INTPT EQU 0FFH ; PORT USED TO MONITOR INTERRUPT
; AND MOTOR ON LINES.
FMSR EQU 0F0H ; ADDRESS OF MAIN STATUS REGISTER
FDATA EQU 0F1H ; FLOPPY DATA REGISTER
FDMA EQU 0F2H ; PSEUDO DMA ADDRESS
MOTOR EQU 0F8H ; MOTOR CONTROL
TERMCN EQU 0FAH ; ADDRESS TO WRITE A TC STROBE
;
;
; the format for the calling data structure is:
;
PUNIT DB 00 ; Byte value 0->3
PHEAD DB 00 ; BYTE head<side> select 0 or 1
PSECTOR DB 00 ; Byte value Sector typical 1->26
PTRACK DB 00 ; Byte value track 0-255
;
; Local buffer for sector read or write <cpm deblock>
;
Buffer DS 512 ; make large enough for sector
;
; DISK COMMAND BLOCK
;
CMD DB 0 ; COMMAND READ OR WRITE,
UNIT DB 0 ; PHYSICAL DRIVE 0->3
TRACK DB 0 ; PHYSICAL TRACK 0->256
HEAD DB 0 ; HEAD SEL 0 or 1
SECTOR DB 1 ; PHYSICAL SECTOR, ALLWAYS 1 TO MAX SECTOR
DENS DB 2 ; DENSITY
EOTSEC DB 09 ; LAST SECTOR OF TRACK
GAP DB 1Bh ; VALUE FOR IRG <GAP3>
SECSIZ DB 080H ; HOW MANY BYTES TO XFER/4
DTL DB 0FFH ; SIZE OF SECTOR
;
SRTHUT DB 7FH ; STEP RATE AND HEAD UNLOAD TIME
;
; STATUS RESULT STORAGE
;
ST0 DB 0 ; STORE STATUS 0
ST1 DB 0 ; ST1
ST2 DB 0 ; ST2
SCYL DB 0 ; TRACK
SHEAD DB 0 ; HEAD 0 OR 1
SREC DB 0 ; SECTOR
SNBIT DB 0 ; DENSITY
;
; call read or write command after setting up data structure
;
; commands are the lower 5 bits and there are three modifiers:
;
; SK BIT 5 skip deleted data marks
; MF BIT 6 FM or MFM 1=MFM
; MT BIT 7 multitrack
;
READ: MVI A,046H ; Bit 6 sets MFM
JMP SAVCMD
;
WRITE: MVI A,045H ; Bit 6 sets MFM
SAVCMD: STA CMD
JMP DSKOP
;
;
; GENERAL DISK DRIVER
;
; setup and load command bytes.
;
DSKOP: LDA PUNIT
ANI 03h ; mask for four drives.
STA UNIT ; store in command block
MOV B,A ; park it in B
LDA HEAD ; get head selection
ANI 01H ; insure single bit
STA HEAD ; HEAD
RAl
RAl
RAl ; MOVE head TO BIT 2 POSITION
ORA B ; OR head to unit byte in command block
STA UNIT ; Store in UNIT
LDA PTRACK ; get cylinder
STA TRACK ; move track to command block
LDA PSECTOR ; load sector
STA SECTOR ; save it on command block
LHLD PBFFER ; Get buffer address
SHLD DMA ; store at DMA address
MVI A,00 ;
STA TERMCN ; Clear the bit used set TC
IN INTPT ; Check for interrupts <Via Port>
ANI 80H ; interrupt is bit 7
CZ SENDINT
CALL SETDRV ; SET DRV TYPE
CALL SPECFY ; set step rate and head load/unload time
CALL SETTRK ; perform seek
JZ DOSO4 ; actually read or write at selected sector
ORI 0FFH ; set -1 if error
RET
;
; setup command for read or write <command phase>
; actually put read or write command to 765
;
DOSO4: MVI B,08H ; number of bytes in a command stream -1
LXI H,CMD ; point to command block
CMDISK: MOV A,M ; get command (byte 0)
CALL PFDATA ; push command byte
INX H ; point to next
DCR B ; decrement byte count
JNZ CMDISK ; loop til b=0
LDA SECSIZ ; XFERLEN
MOV C,A ; C will be the number of transactions
; divided by 4
LXI H,BUFFER ; get buffer address to HL
LDA DTL ; DTL, is the last command byte to 765
CALL PFDATA
LDA CMD ; READ IS 0 Is this a read or write
ANI 1 ; WRITE IS 1
JNZ WRR ; JMP WRITE IF 1
JMP RDD ; ELSE READ
;
; Perform read
; Loop executes 4x, this allows C rather than BC as counter
; saving a few Tstates. Makes up to 1024 byte sectors possible.
; From read to read must not exceed 25us worst case min.
; (76t states for 3mhz 8085)
;
RDD: IN FDMA ; pseudo DMA transfer <execution phase>
; Stall an the IN until DRQ goes true.
MOV M,A ; Move to buffer pointed to by HL
INX H ; bump pointer++
IN FDMA ; x2
MOV M,A
INX H
IN FDMA ; x3
MOV M,A
INX H
IN FDMA ; x4
MOV M,A
INX H
DCR C ; C=C-1
JNZ RDD ; loop if C not= 0
MVI A,01 ; loop end
OUT TERMCN ; set TC <terminates transfer>
JMP RESULT ; Get status bytes <result phase>
;
WRR: MOV A,M ; get byte to go
OUT FDMA ; pseudo DMA <write execution>
INX H ; point to next
MOV A,M ; X2
OUT FDMA
INX H
MOV A,M ; X3
OUT FDMA
INX H
MOV A,M ; X4
OUT FDMA
INX H
DCR C ; C=C-1
JNZ WRR ; Loop if C not= 0
MVI A,01
OUT TERMCN ; set TC to terminate
JMP RESULT
;
RESULT: MVI A,0 ; Clear TC
OUT TERMCN
REST1: IN INTPT ; check for result phase interrupt
ANI 80H
JNZ REST1 ; wait/loop for interrupt
MVI C,7H ; load C with number of status bytes
LXI H,ST0 ; point to stats storage
RS3: CALL GFDATA ; get first byte
MOV M,A ; save it
INX H ; pointer++
DCR C ; C=C-1
JNZ RS3 ; loop til c=0
XRA A ; clear ACC
LDA ST0 ; LOAD STS0
ANI 0F8H ; MASK OFF DRIVE #
MOV B,A ; park it
LDA ST1 ; Load STS1
ORA B ; ACC or B ->ACC if 0 then sucess
RET ; Done return to caller.
;
; Set motor on and waits .5 sec
;
SETDRV:
MVI A,080H ; TURN MOTOR ON AND WAIT .5 SEC
OUT MOTOR
LXI H,0C000H
DELDM: NOP ; APPROX .5 SEC DELAY
NOP
DCR L
JNZ DELDM
DCR H
JNZ DELDM
MONMNI: ; set up gap and specify params
MVI A,01Bh ; GAP3 value for this format
STA GAP
MVI A,0EFh ; high nibble has step rate (4ms)
; low nibble has head unlod time (240ms)
STA SRTHUT ; save that
MVI A,0FFh ;
STA DTL ; set DTL to FF for N greater than 0
MVI A,02 ; N in the commad, size of sector 512
RET
;
; Perform spacify command
;
SPECFY: MVI A,03 ; specify command
CALL PFDATA ; push it
LDA SRTHUT ; step rate and head unload time
CALL PFDATA ; push that
MVI A,04h ; head load time <16ms>, allow the stepper to
; settle as heads load when media is inserted
; BIT 0 is the non-DMA bit. 0=DMA
CALL PFDATA ; push that
RET
;
; SETTRK Seek to a TRACK on UNIT
; Up to four drives can seek at the same time from
; seperate commands. Read or write cannot start until
; ALL seeks are done.
;
SETTRK: IN INTPT ; any interupt pending
ANI 80H
CZ SENDINT ; if yes find out why/clear
LDA TRACK ; get track
ORA A ; set flags
JZ RECAL ; if 0 perform recal instead of seek
MVI A,0FH ; Seek command
CALL PFDATA ; push command
LDA UNIT ; say which unit
CALL PFDATA ; send that
LDA TRACK ; to what track
CALL PFDATA ; send that too
JMP WAINT ; wait for interrupt saying done
RECAL: MVI A,07H ; recal to track 0
CALL PFDATA ; send it
LDA UNIT ; which unit
CALL PFDATA ; send that too
WAINT: IN INTPT ; wait here for interrpt saying done
ANI 80H
JNZ WAINT ; loop til interrupt
CALL SENDINT ; get interrupt status
RET
;
; Interrpts are normal for command completion or errors.
; Sense interrupt clears them and also find out why.
;
SENDINT:
MVI A,08H ; sense interrupt command
CALL PFDATA ; send it
CALL GFDATA ; get results
STA ST0 ; store that
CALL GFDATA ; get another
STA ST1 ; save that
LDA ST0 ; get first one
ANI 0C0H ; mask off all but interrupt code 00 is normal
RET ; anything else is an error
;
; write a command or parameter sequence
; transfers are synchonized byt MSR D7 <RQM> and D6 <DIO>
; RQM DIO
; 0 0 BUSY
; 1 0 WRITE to data register permitted
; 1 1 Byte for READ by host pending
; 0 1 Busy
;
PFDATA: PUSH PSW
PFD1: IN FMSR ; reading or writing is keys to D7 RQM
ANI 80H
JZ PFD1 ; wait for RQM to be true.
IN FMSR
ANI 40H
JNZ ERRORT
POP PSW
OUT FDATA
RET
;
; Read a status byte from FDC
; Same rules for RQM and DIO save for it's read case
;
GFDATA: IN FMSR
ANI 80H
JZ GFDATA
IN FMSR
ANI 040H
JZ ERRORT
IN FDATA
RET
;
ERRORT: JMP ERRORT ; dead end for a out of sync I/O to FDC
; This should never occur unless an application writes to a wrong
; port address <FDATA>. If this occurs the fix to read until
; RQM becomes true. Then check interrupts. This only occured while
; debugging a new interrupt driver.
;
END
Steve
I have the 1A book in front of me, and it is X unused. And I do
NOT have nine bits, 7-0 is 8!! The other things are labels for
that
LINE OF TEXT!!:
|
v
Bit 7 6 5 4 3 2 1 0
BCR X EEN DDEN SD1 DS4 DS3 DS2 DS1
|
BCR means Bit of Control Register
> I understand the 1a doesn't do SCSI but the effect is very limited
> and does not impact the main control register.
>
> Allison
----------------------
Then they changed it for SOME reason, the same CP/M runs on both minus
the HD support.
bill_h
> If one makes small changes in the BigBoard hardware, it's hard to tell
> whether the hardware is Kaypro, Xerox, or Ferguson Engineering. It's
> even difficult to distinguish most of the low-level software for the
> BigBoard-1 and the BigBoard-II, though there are some glaring
> differences. The code is pretty similar, however.
Well, actually, they ALL are Ferguson engineering. Way to go, Jim!
The BigBoards, naturally, are obvious. The Xerox was covered by one
of those really intimidating non-disclosure agreements big companies
usually have you sign when they're trying to cover their tracks.
Kaypro - well, they bought a couple BigBoard I's and simply re-laid
them in a form that could be packed into a metal box. Of course, with
out any input from Ferguson, they evolved independant of his 'original'.
Bill
Tucson, AZ
bill_h
> >EEEK! You'd not really use that model, designed for the Little Board,
> >(where the most important feature was the "LITTLE" and everything else
> >was secondary) would you? That was specifically designed for
> >NON-expandability.
>
> As was the BBII!!!
You have no clue what the BB II is, or can do.
Nor, apparently, have you heard of the STD BUS.
The guy to start with when it comes to ''expanding''
the BB II is Andy Bakkers.
Bill
Tucson, AZ
Amardeep S Chana
<39ce6e9e...@news.bellatlantic.net>...
>
>>doing FDC/HDC work, that the 765 was more restrictive, not offering as
>
>For what buggered formats like the TRS80 with the deleted address
>mark set? Even the 765 can read that. Most of the time it's
>meaningless and if anythingit forced a common standard
>(good or bad).
>
>
That one you describe where normal sectors had deleted data marks was the
Model III TRS-80 format and the 765 cores definitely can read it. More of
an issue was that some of the earlier formats using the 1771 and 179x family
used a very short post index gap. Much shorter than the recommended size.
Since the 765 actually does a reset when it senses an index pulse and there
is a recovery time somewhere on the order of 750uS to 1.5mS depending on the
exact part, the first sector can be very hard for the 765's to read. I've
often times put tape over the index hole or installed a switch to disconnect
the index line to work around that problem when reading some early Cromemco
and TRS-80 disks.
Even more difficult was the TRS-80 Model I TRSDOS format that used the
1771's non standard 0xF8 address mark on the directory track. All Western
Digital 17xx descended controllers could read a sector with that mark but
only the 1771 could write it. A 765 core controller can't read it at all.
The biggest gripe I have with the 765 core is the fact that you cannot do a
track read including the inter sector information. You can sort of do this
by reading a sector with a sector size of 8192 bytes and you get all sorts
of stuff after it, but you still can't get the stuff before sector 1 and the
write splices usually hose up the data stream. The 17xx series will resync
at every data mark so you actually could read the entire track cleanly.
Amardeep
Steve
>
> On Sun, 24 Sep 2000 17:13:08 -0700, Steve <rst...@armory.com> wrote:
>
> >> >No, I don't, it's typed out of the AmproLB-Z80 model 1A manual
> >> >BCR is just the Bit of Control Register!!!
> >> >And the Ampro without the SCSI chip(in 1B model) does NOT use bit 7!!
>
------------------------
YOU, Allison, using proportional fonts??? It wasn't me!! ;->
> >----------------------
> >Then they changed it for SOME reason, the same CP/M runs on both minus
> >the HD support.
>
> It's not used. It's available to reset the FDC and the only reason
> you would do that is if it were out in space hung. CP/M itself would
> not care as it's something resolved at the BIOS level.
>
> Allison
---------------------
Yeah, well, an afterthought. It was laying around.
-Steve
nos...@nouce.bellatlantic.net
>> >No, I don't, it's typed out of the AmproLB-Z80 model 1A manual
>> >BCR is just the Bit of Control Register!!!
>> >And the Ampro without the SCSI chip(in 1B model) does NOT use bit 7!!
Ah, proportional fonts... nothing lines up.
>----------------------
Richard Erlacher
which I have one downstairs, was apparently not as well thought-out as
the first one. The memory design, using 4116's made little sense,
several years after the 64K parts were out, and the board itself was
objectionably large. The inclusion of the STD bus slot didn't buy
much, but it did serve to make the board even larger.
I've yet to explore the SASI interface possibilities, but I'd say the
inclusion of the DMAC was not only wasteful of space and money, but
silly, as well as being an impediment to the further development of
the board as a general purpose application circuit for the Z80. The 6
MHz parts were available by then, though there wasn't a 6 MHz DMA. In
fact, even today, the DMA is the slowest and most limiting device in
the series.
While it's possible to conceive of a task for which DMA might be used,
I've never seen one that couldn't be accomplished without it, nor have
I ever seen one that wouldn't be improved by its omission. Likewise,
the use of interrupts in a CP/M environment seems a waste of effort
and resources, as the serial devices seldom are used when the CPU has
anything better to do than wait for a task to be done.
The BB-II was expandable, via its STD bus slot, though I doubt it was
any more than an afterthough, and it makes the board almost too large
for rackmount use. What do you suppose the designer had in mind as a
packaging arrangement?
Dick
On Sun, 24 Sep 2000 19:38:09 -0700, bill_h <bil...@azstarnet.com>
wrote:
bill_h
>
> I think Allison's got things mixed up, but in reality, the BBII, of
> which I have one downstairs, was apparently not as well thought-out as
> the first one. The memory design, using 4116's made little sense,
> several years after the 64K parts were out, and the board itself was
> objectionably large. The inclusion of the STD bus slot didn't buy
> much, but it did serve to make the board even larger.
What are you talking about?? The II USED the 64k parts. And I don't
have a 'I' but I think they were about the same size, meaning the II
got a couple times the functionality out of the same space - EPROM
programmer/sockets; STB BUS; SASI interface; dual 5/1/4'' 34 pin AND
8'' 50 pin diskette interfaces; etc What could you possibly want
that wasn't built in already? It even used the 6845 video controller
that later turned up as THE standard IBM PC video chip. I really
doubt you have clue#1 about hardware design.
> I've yet to explore the SASI interface possibilities, but I'd say the
> inclusion of the DMAC was not only wasteful of space and money, but
> silly, as well as being an impediment to the further development of
> the board as a general purpose application circuit for the Z80.
(further anti-DMA blather deleted) If you DON'T like DMA, simply don't
code for it! It'll just sit there!
> The BB-II was expandable, via its STD bus slot, though I doubt it was
> any more than an afterthough, and it makes the board almost too large
> for rackmount use. What do you suppose the designer had in mind as a
> packaging arrangement?
Oh, yeah, right ... we ALL rack-mount our computers, Sure. You bet!
It's exactly the form factor of an 8'' drive. Ever seen one of those?
The data transfer rate was TWICE that of ANY generally available 5-1/4''
drive of the time.... in other words, if you wanted SPEED, you used 8''
and got the added benefit of 1.3meg of space per DS disk. Gee, once we
thought that was a LOT!
You better take another look at that ''one downstairs''..... doesn't
sound like a II to me ....
Bill
Tucson, AZ
Lee Hart
Brainstorming is fun, but until the storm is over, nothing actually gets
done.
Do you really need a disk controller on a single-board computer for
robots or general fooling-around use? It certainly complicates the
design, and there are lots of alternatives nowdays. PCMCIA cards, a SCSI
port to a CD-ROM or hard drive, a parallel or serial port to a PC, etc.
If you do need a floppy disk controller, perhaps a modern CPU is fast
enough to "bit bang" the disk interface, especially with some simple
support logic to help. A modern version of the Apple IWM (Integrated
Wozniac Machine) if you will. The Heathkit H17 format could do 5-1/4"
single-density floppies with just a 2 MHz 8080, UART, and a few TTL
parts.
Lee Hart
> While it's possible to conceive of a task for which DMA might be used,
> I've never seen one that couldn't be accomplished without it, nor have
> I ever seen one that wouldn't be improved by its omission.
How about a video display? It requires fast data transfers, with very
tightly defined timing -- exactly what DMA is for. There have been some
very clever, minimal-hardware video displays that used DMA to generate
video instead of the more normal dual-port memory or a special CRT
controller. The RCA 1802+1861, and the Timex/Sinclair ZX-81 come to
mind.
> Likewise, the use of interrupts in a CP/M environment seems a waste of
> effort and resources, as the serial devices seldom are used when the
> CPU has anything better to do than wait for a task to be done.
How about real-time clocks (to maintain accurate timing, despite CPU
speed changes, or other tasks)? Another is a type-ahead buffer, so you
don't miss characters. Or a print spooler, to keep printing while doing
other things.
bill_h
> The biggest gripe I have with the 765 core is the fact that you cannot do a
> track read including the inter sector information. You can sort of do this
> by reading a sector with a sector size of 8192 bytes and you get all sorts
> of stuff after it, but you still can't get the stuff before sector 1 and the
> write splices usually hose up the data stream. The 17xx series will resync
> at every data mark so you actually could read the entire track cleanly.
The real difference betwen the 1793 I'm familiar with and the 765
which IBM used is this: the WD part can READ A TRACK. It doesn't CARE
what's on it - the whole thing is placed into memory at the address
you specified for diskbuf. Preamble, inter-sector stuff, EVERYTHING.
Note that this is NOT the 'usual' way you'd read disks. But you could.
The 765 doesn't HAVE a 'read track' command, at least NOT like THAT!
It can only read DATA out of properly numbered sectors, from a properly
numbered cylinder. All you get is the DATA, but NOT the 'extra' stuff.
Trying to read a track whose cylinder number is WRONG causes an error.
To defeat this numbering business, you had to 'guess' at a number and
try it. Over and Over. Very slow; tedious. Dumb. Low tech. Same for
sector numbers: Load 765; attempt read; error; increment; try again.
There is virtually NO WAY to copyprotect a disk that will be read
with a WD 179x chip. And THAT'S why some people (IBM?) chose the 765.
Bill
Tucson
O. Alan Jones
news:39ce70ce...@news.bellatlantic.net...
> On Sat, 23 Sep 2000 20:08:37 GMT, nos...@nouce.bellatlantic.net wrote:
>
> Heres a 765 (also clones) basic driver written back in 1984 for the
> first 96tpi drives. I have a CPM bios that uses the proto code for
> them and can post it, note the bios is a VERY minimal
> in that it assumes 8" CPM standrd format (SSSD) and
> NO interrutps.
>
> this also runs on z80 obviously it's coded as 8080 so ASM is used.
>
> To those that may be critical, post better! It's free!
>
> Allison
>
Thanks for posting the BIOS Allison.
--Alan
Amardeep S Chana
<8qmeca$ilg$1...@node17.cwnet.frontiernet.net>...
>
>Even more difficult was the TRS-80 Model I TRSDOS format that used the
>1771's non standard 0xF8 address mark on the directory track. All Western
>Digital 17xx descended controllers could read a sector with that mark but
>only the 1771 could write it. A 765 core controller can't read it at all.
>
Oops... I meant 0xFA. The 0xF8 is a standard DAM.
O. Alan Jones
learning just from reading all the individual posts. I am still in the
process of learning about the theory of computer hardware.
I personally enjoy building my own computers. I didn't start playing around
with CP/M until about early 1988. I digressed (supposedly--according to my
friends) from the PC world and I'm glad I did! I learned the electronics
theory of computers on my Bigboard computer I built myself. And I "cut my
teeth" programming it's Z80. Over the next year I accumulated several
machines: an old A.B. Dick computer, Kaypro II, Xerox 820, Model IV...ect. I
also learned how to program on a computer trainer we used in the Navy called
the Nida 250. The trainer came with CP/M operating system and BASIC compiler
only. I made lots of brownie points with my supervisors when I ported over
to the trainer dBASE II, WordStar, and other programs, ect. I used a disk
sector editor called VU-77 or something like that (I forget it's name).
I really enjoyed "hacking" on a CP/M computer. So there you are, I just
wanted to let you fellow CP/Mers know that I enjoy all the discussions here
on comp.os.cpm
Have a wonderful day...
--Alan
Richard Erlacher <ed...@hotmail.com> wrote in message
news:39c94ffe...@superego.idcomm.com...
> I
> 'm really not as nice as all that, Alan Jones' words notwithstanding,
> but I do happen to have several (about a dozen) of the disks you
> mention. I also have (as you already know if you've read the post
> from Alan) the boot and source diskettes for the Big Board.
>
Amardeep S Chana
<39cffa1c....@news.bellatlantic.net>...
>On Sun, 24 Sep 2000 22:44:54 -0400, "Amardeep S Chana"
<amardee...@yahoo.com> wrote:
>>
>>That one you describe where normal sectors had deleted data marks was the
>>Model III TRS-80 format and the 765 cores definitely can read it. More of
>
>the trs80 format was one of many butchered formats.
>
Sorry if it came across as correcting. I was agreeing with your statement
that the format could be read by the 765.
>One of my pet peeves of the early to mid 80s was on an average day
>I may have to handle a list of formats that was imposing and annoying.
I never understood why every programmer writing disk driver code thought he
could design a better soft sectored format than the IBM standard. Maybe it
made them feel like they were adding value...
>
>>The biggest gripe I have with the 765 core is the fact that you cannot do
a
>>track read including the inter sector information. You can sort of do
this
>
>Did you ever try the read diagnostic command? 10mf00010 MF is the
>fm/mfm bit.
>
I believe MF is bit 6, not bit 5. But anyway that opcode only delivers the
contents of the data field of each sector but not the format data. Worse
yet, it delivers it in the order encountered with no regard or reference to
the logical sector number. If any interleave is present you have to know
about it ahead of time and sort out the data later.
>>by reading a sector with a sector size of 8192 bytes and you get all sorts
>>of stuff after it, but you still can't get the stuff before sector 1 and
the
>>write splices usually hose up the data stream. The 17xx series will
resync
>>at every data mark so you actually could read the entire track cleanly.
>
>Personally thats nice if your in the data recovery from messed up
>disks business, On the otherhand writing disks that way is still pure
>lunacy.
>
Format analysis is where I like to use that capability of the WD chips.
>I now the 765, I helped introduce and sell it in the early 80s. I
>also have the Japanese, jinglish and english tech manuals
>from that time.
>
>Allison
Jinglish? Sounds like a horrible disease! :)
Amardeep
nos...@nouce.bellatlantic.net
<amardee...@yahoo.com> wrote:
>nos...@nouce.bellatlantic.net wrote in message
>
>That one you describe where normal sectors had deleted data marks was the
>Model III TRS-80 format and the 765 cores definitely can read it. More of
I didn't say that the 765 couldn't read it, only that like many
the trs80 format was one of many butchered formats.
One of my pet peeves of the early to mid 80s was on an average day
I may have to handle a list of formats that was imposing and annoying.
There was nothing worse for the industry thn same cpu, OS and even
program compatability save for you couldn't read the disk becuase it
was a slightly different format!
>an issue was that some of the earlier formats using the 1771 and 179x family
>used a very short post index gap. Much shorter than the recommended size.
>Since the 765 actually does a reset when it senses an index pulse and there
Actually some truncated the format to delete far more than that.
The reset was on the second index seen, INDEXs seen prior to that set
the mark finder in hunt mode,
>is a recovery time somewhere on the order of 750uS to 1.5mS depending on the
>exact part, the first sector can be very hard for the 765's to read. I've
The solution was to over delay index (make is lag the index by 95% of
rotation) or use the 7265.
>often times put tape over the index hole or installed a switch to disconnect
>the index line to work around that problem when reading some early Cromemco
>and TRS-80 disks.
That worked but if the media was off in some way the controller hung
forever looking for index.
>Even more difficult was the TRS-80 Model I TRSDOS format that used the
>1771's non standard 0xF8 address mark on the directory track. All Western
>Digital 17xx descended controllers could read a sector with that mark but
>only the 1771 could write it. A 765 core controller can't read it at all.
Like I said buggered format.
>The biggest gripe I have with the 765 core is the fact that you cannot do a
>track read including the inter sector information. You can sort of do this
Did you ever try the read diagnostic command? 10mf00010 MF is the
fm/mfm bit.
>by reading a sector with a sector size of 8192 bytes and you get all sorts
>of stuff after it, but you still can't get the stuff before sector 1 and the
>write splices usually hose up the data stream. The 17xx series will resync
>at every data mark so you actually could read the entire track cleanly.
Personally thats nice if your in the data recovery from messed up
disks business, On the otherhand writing disks that way is still pure
lunacy.
I now the 765, I helped introduce and sell it in the early 80s. I
nos...@nouce.bellatlantic.net
wrote:
>Richard Erlacher wrote:
>>
>> I think Allison's got things mixed up, but in reality, the BBII, of
I may have..
>> the first one. The memory design, using 4116's made little sense,
>> several years after the 64K parts were out, and the board itself was
Cost, the 4116 was around $1.20 when the 4164 was at $6 and hard to
get. The 4164 was slow to get cheap as the demand was high and
not everyone had good yeild. Also many of the 4164s required an
8bit refresh and the z80 didn't do that. The only 128 cycle refresh
4164 parts were NEC 4164 and the Fujitsu and Hitachi. I think one of
the American vendors also did 128 cycle but they were scarce.
>(further anti-DMA blather deleted) If you DON'T like DMA, simply don't
> code for it! It'll just sit there!
Actually he has a point. If you hopping up a board and the zilog DMA
is there then you have to go to much pain to run faster than 4mhz as
there never was a faster part.
I'm with you on this in that hopping up a Bigboard (or any SBC!) has
its limits and there is a point where a fresh sheet of paper can some
simplifications can do far better.
>Oh, yeah, right ... we ALL rack-mount our computers, Sure. You bet!
Actually I have an IMS S100 rack, kinda neat...
>It's exactly the form factor of an 8'' drive. Ever seen one of those?
I have a raft of them. Can you say huge? Yep!
>The data transfer rate was TWICE that of ANY generally available 5-1/4''
>drive of the time.... in other words, if you wanted SPEED, you used 8''
>and got the added benefit of 1.3meg of space per DS disk. Gee, once we
>thought that was a LOT!
;) yep! I had to go to 1.44 3.5" to get back to where I was in 1982
with my first SA851.
Allison
nos...@nouce.bellatlantic.net
<oaj...@bright.net> wrote:
>
>Thanks for posting the BIOS Allison.
>--Alan
FYI: it's not a bios only the floppy driver portion.
Soon as I find it I'll post a bios that I used for the F1 proto
(non DMA) controller (765 based with many mods) back
in 1982.
Opinion:
The best S100 designs I've seen to date is the Compupro
and Ithaca Intersystems DMA FDC controllers based on
765. There were others but they are less well known.
The advantage of using DMA was the CPU didn't have
to meed the transfer speed needs of the disk and most
of the DMA controllers will support 8"DD or 3.5" 1.44 (13uS worst
case) easily.
Allison
nos...@nouce.bellatlantic.net
<amardee...@yahoo.com> wrote:
Not to worry I knew exactaly what you intended.
Part of the fun was finding out what abuse was propagated
for each format and keepig track of them.
Allison
>Amardeep S Chana wrote in message
><8qmeca$ilg$1...@node17.cwnet.frontiernet.net>...
>>
>>Even more difficult was the TRS-80 Model I TRSDOS format that used the
>>1771's non standard 0xF8 address mark on the directory track. All Western
>>Digital 17xx descended controllers could read a sector with that mark but
>>only the 1771 could write it. A 765 core controller can't read it at all.
>>
>
>
Richard Erlacher
have 64K parts on it rather than the array of 4116's that the pile of
BB-1's has got. Nevertheless, for BB-II, as well as it may meet the
needs of the early '80's computing hobbyist, limts the hot-rodding
that is what I'm interested in pursuing. The best thing one can do in
order to make it run faster with a minimum of alteration is to remove
the DMAC, since running faster will ensure that you can get the data
transfers done quickly. I've not yet looked to see how long it takes
to arbitrate for the bus, but I doubt it will be efficiently useable
for anything other than the fastest transfers, since I don't believe
it can do cycle-stealing DMA as one might want for slow but steady
synchronous processes.
The DMA (Z84C10-8) is the slowest of the peripheral set, and
hot-rodding the BB-II would have to begin with its removal. Then,
with just a few cuts and jumpers the board could be run at nominally
10 MHz since the rest of the peripherals are available at speeds up to
10 MHz. That makes for an appreciable speed-up, The remaining
problems (problems for speed-ups) can be dealt with by adding
wait-states for the video or by speeding up its RAM.
One useful thing here is that the video circuit is not terribly
different form that in the IBM Mono board, so the code for the mono
board, or at least the timing parameters can be swiped from the PC's
Mono card, and the result will be that you can use the really decent
mono monitors that they sell at nearly all the thrift stores often for
under $5. Another handy feature is that wire-wrap area, if you like
such things, since you can fix unconsistencies between what the board
provides and what you need right there, so you don;t have to
accomodate yet another board as a distribution panel aswas done with
the BB-I.
This is definitely a case of "LESS-IS-MORE" though, as removing the
DMA certainly increases the top speed you can attain, providedyou
ditch the mode-2 interrupts in favor of mode-1. I personally would
prefer to live without them.
On Tue, 26 Sep 2000 01:40:33 GMT, nos...@nouce.bellatlantic.net wrote:
>On Mon, 25 Sep 2000 13:01:29 -0700, bill_h <bil...@azstarnet.com>
>wrote:
>
>>Richard Erlacher wrote:
>>>
>>> I think Allison's got things mixed up, but in reality, the BBII, of
>
>I may have..
>
>>> the first one. The memory design, using 4116's made little sense,
>>> several years after the 64K parts were out, and the board itself was
>
>Cost, the 4116 was around $1.20 when the 4164 was at $6 and hard to
>get. The 4164 was slow to get cheap as the demand was high and
>not everyone had good yeild. Also many of the 4164s required an
>8bit refresh and the z80 didn't do that. The only 128 cycle refresh
>4164 parts were NEC 4164 and the Fujitsu and Hitachi. I think one of
>the American vendors also did 128 cycle but they were scarce.
>
>>(further anti-DMA blather deleted) If you DON'T like DMA, simply don't
>> code for it! It'll just sit there!
>
>Actually he has a point. If you hopping up a board and the zilog DMA
>is there then you have to go to much pain to run faster than 4mhz as
>there never was a faster part.
>
>I'm with you on this in that hopping up a Bigboard (or any SBC!) has
>its limits and there is a point where a fresh sheet of paper can some
>simplifications can do far better.
>
>>Oh, yeah, right ... we ALL rack-mount our computers, Sure. You bet!
>
>Actually I have an IMS S100 rack, kinda neat...
>
Aside frmo the high cost of sheet metal, racks are pretty neat.
However I must meant that it was a problem packaging the BB-II in a
way that would accomodate access to its features, allow the use of the
STD-Bus expansion port, AND still fit in a rack drawer. I suppose it
could be done, but it would not be pretty!
I've got a few rackmount card cages, even a couple of brand-new,
still-in-the box ones from Vector, et. al. that I've never used
because of my love for rack mounting. I hate to pay more for the
packaging than the contents.
Dick
nos...@nouce.bellatlantic.net
<amardee...@yahoo.com> wrote:
>I never understood why every programmer writing disk driver code thought he
>could design a better soft sectored format than the IBM standard. Maybe it
>made them feel like they were adding value...
Maybe, it did make for great pain.
>>Did you ever try the read diagnostic command? 10mf00010 MF is the
>>fm/mfm bit.
>>
>
>I believe MF is bit 6, not bit 5. But anyway that opcode only delivers the
OOps... 0mf000010 typo corrected.
>contents of the data field of each sector but not the format data. Worse
>yet, it delivers it in the order encountered with no regard or reference to
>the logical sector number. If any interleave is present you have to know
>about it ahead of time and sort out the data later.
I get all the data from my tests and the jinglish manuals state same.
>Jinglish? Sounds like a horrible disease! :)
Japanese English first translations without correction. Reads with
difficulty and corrupts writing style well!
Allison
Richard Erlacher
core with additional register space to accomodate features for
conrolling spindle motors, drive selection, head selection, and most
everything else needed on a PC disk interface, but it's capable of
dealing with an 8" drive in either single or double density. All the
clock/data separator logic is on board, as is the write pre compen-
sation logic. The device drives the cable directly with 48 mA
drivers. There are numerous applications which have this device on
board in a 44-pin version. (meaning that's where you can get them) It
allows a single controller to handle every common soft sectored disk
format with only a couple of external oscillators. (16 MHz & 9.6 MHz.
It's completely code compatible with the 765. That appears to me to
be adeequate. That might be an adequate way to replace the 1771 in a
Big Board-1. It will take lotsa wires, and new code but what the hey
...
Dick
On Tue, 26 Sep 2000 01:47:22 GMT, nos...@nouce.bellatlantic.net wrote:
>On Mon, 25 Sep 2000 19:41:29 -0400, "O. Alan Jones"
><oaj...@bright.net> wrote:
>
>>
>>Thanks for posting the BIOS Allison.
>>--Alan
>
>FYI: it's not a bios only the floppy driver portion.
>Soon as I find it I'll post a bios that I used for the F1 proto
>(non DMA) controller (765 based with many mods) back
>in 1982.
>
>Opinion:
>The best S100 designs I've seen to date is the Compupro
>and Ithaca Intersystems DMA FDC controllers based on
>765. There were others but they are less well known.
>The advantage of using DMA was the CPU didn't have
>to meet the transfer speed needs of the disk and most
>of the DMA controllers will support 8"DD or 3.5" 1.44 (13uS worst
>case) easily.
>
I've seen several S-100 boxes with 4 MHz Z80's that got around the
horn on the transfer of DD 8" diskette data with no DMA. The one that
immediately comes to mind is the CCS 2422 FDC. I'm sure there were
many others. I've got a Suntronics controller and one from Computime
lying around somewhere that had no DMAC, yet almost all the 765-based
boards (IMS, Systems Group) that I own have a DMAC of one sort or
another. Why is that, Allison? If the processor can do it whom are
we helping by including a DMAC?
Dick
>
>Allison
>
Amardeep S Chana
<39d017bc....@news.bellatlantic.net>...
>On Mon, 25 Sep 2000 22:44:01 -0400, "Amardeep S Chana"
<amardee...@yahoo.com> wrote:
>>contents of the data field of each sector but not the format data. Worse
>>yet, it delivers it in the order encountered with no regard or reference
to
>>the logical sector number. If any interleave is present you have to know
>>about it ahead of time and sort out the data later.
>
>I get all the data from my tests and the jinglish manuals state same.
>
I've never actually tried that command because the data sheets I've read for
NS 8473, NS 8477, Intel 82078, and SMSC 37C78 all say pretty much the same
thing... it is just a read multiple sector command. Here is a verbatim
excerpt from the NS 8473 sheet:
* * *
READ A TRACK (0mf000010)
This command is similar to the Read Data command except for the following.
The controller starts at the index hole and reads the sectors in their
physical order, not their logical order.
Even though the controller is reading sectors in their physical order, it
will still perform a comparison of the header ID bytes with the Data
programmed in the Command Phase. The exception to this is the sector
number. Internally, this is initialized to a one, and then incremented for
each successive sector read. Whether or not the programmed Address Field
matches that read from the disk, the sectors are still read in their
physical order. If a header ID comparison fails, bit 2 of ST1 (No Data) is
set, but the operation will continue. If there is a CRC error in the
Address Field or the Data Field, the read will also continue.
The command will terminate when it has read the number of sectors programmed
in the EOT parameter.
* * *
This description does not suggest the command does a raw read of the track
but just the data fields from each sector in physical order. I'll try it
when I get the chance but I'm pretty sure of the outcome. I've read
numerous other people's accounts of being unable to do a true raw read with
a 765.
Amardeep
Harold Bower
> >On Mon, 25 Sep 2000 22:44:01 -0400, "Amardeep S Chana"
> <amardee...@yahoo.com> wrote:
> >>contents of the data field of each sector but not the format data. Worse
> >>yet, it delivers it in the order encountered with no regard or reference
> to
> >>the logical sector number. If any interleave is present you have to know
> >>about it ahead of time and sort out the data later.
>
> This description does not suggest the command does a raw read of the track
> but just the data fields from each sector in physical order. I'll try it
> when I get the chance but I'm pretty sure of the outcome. I've read
> numerous other people's accounts of being unable to do a true raw read with
> a 765.
>
> Amardeep
You are correct. The multi-sector read only reads the data sector
contents. The SMC 9266 (another '765-compatible') used in the SB-180
used the multi-sector read command in the boot sector code to load the
CP/M image from the first two tracks. Only the data sector contents
were read in sequential (by sector number) order. This is NOT the raw
track read command in the WD family.
Hal
Richard Erlacher
a track read, all right, but what they return is not exactly what
they've read. Instead of some of the codified uniquie bit patterns
use, for example, as address marks, the WD chips return the dedicated
code (meaningful only in the context of formatting) used to signify
those features.
The WD chips also expect/allow the programmer to determine the length
of gaps/sync fields, so it's possible to write a format that won't
work well. While the data sheets provide guidelines, this can give
rise to subsequent readability/interchangeability problems.
Dick
On Tue, 26 Sep 2000 05:05:55 -0400, Harold Bower
<halb...@cablespeed.com> wrote:
>Amardeep S Chana wrote:
>>
>> nos...@nouce.bellatlantic.net wrote in message
>> <39d017bc....@news.bellatlantic.net>...
>> >On Mon, 25 Sep 2000 22:44:01 -0400, "Amardeep S Chana"
>> <amardee...@yahoo.com> wrote:
>> >>contents of the data field of each sector but not the format data. Worse
>> >>yet, it delivers it in the order encountered with no regard or reference
>> to
>> >>the logical sector number. If any interleave is present you have to know
>> >>about it ahead of time and sort out the data later.
nos...@nouce.bellatlantic.net
<amardee...@yahoo.com> wrote:
>I've never actually tried that command because the data sheets I've read for
>NS 8473, NS 8477, Intel 82078, and SMSC 37C78 all say pretty much the same
>thing... it is just a read multiple sector command. Here is a verbatim
>excerpt from the NS 8473 sheet:
>
They are clones but not the same exact core.
I reference the base 765 chip. I've always wondered if the clones
were different but never went out of my way to test that. I've only
used the 9266 (sb180) and the raw 765(and A) and the 37c65
members as those are what is on hand.
the 40 pin 37c65 FYI can be found on some WD ISA FDC/floppy
controllers.
Allison
Richard Erlacher
3-1/2" diskettes as part of the early (pre-release) version of the
data sheet dated 1989. Do you know anything relating to this?
I'm curious how they did that. The note goes into sufficient detail
to lay out the format but it's less than half a page.
Dick
P.S. If you send me a valid email address, I'll email a scanned image
bitmap (about 230KB) of the thing for your perusal. D
Amardeep S Chana
Western Digital version WD37C65CJM uses 16MHz & 9.6MHz crystals and supports
up to 500Kbps data rate. SMC (later known as SMSC) purchased WD's chip &
adapter businesses and released a version (FDC37C65C-LJP) that uses 32MHz &
9.6MHz crystals and supports up to 1Mbps for the 2.8MB (4MB unformatted)
capacity ED diskettes. It also featured an on-board data seperation circuit
that supports FM operation at certain data rates.
Amardeep
Richard Erlacher wrote in message <39d2e3a...@superego.idcomm.com>...
Robert L. Doerr
> Western Digital version WD37C65CJM uses 16MHz & 9.6MHz crystals and supports
> up to 500Kbps data rate. SMC (later known as SMSC) purchased WD's chip &
> adapter businesses and released a version (FDC37C65C-LJP) that uses 32MHz &
> 9.6MHz crystals and supports up to 1Mbps for the 2.8MB (4MB unformatted)
> capacity ED diskettes. It also featured an on-board data seperation circuit
> that supports FM operation at certain data rates.
>
> Amardeep
Not to get too much off the subject but does anyone have any more details
about the data seperation that is used in the different Western Digital
chips and these newer disk controllers? The reason I am asking is that I
remember when I was using the TRS-80 Model I there was a big deal about
the double density boards having an external data seperator and which
method worked best. I remember reading old BYTE articles that said the
on-chip seperators were not all that effective so an external one could
be made to improve reliabity. Is this something that was mainly an
issue with the early ones like the WD1771? Now I am working on a disk
controller card based on the WD2797 controller. I was wondering if it
would make sense to try an external data seperator or if the internal
one in that chip is fine.
Any insight would be appreciated.
Regards,
Robert
BTW: Does anyone have a spare Western Digital data book on these old
floppy controllers you would be willing to sell??? Also looking for
a TI Opto-electronics data book from the early 80's.
--
------------------------------------------------------------
Robert L. Doerr (MCNE, MCSE, A+)
26308 Cubberness
St. Clair Shores, MI 48081
Tel: (810) 777-1313
e-mail: rdo...@home.com
WEB Site: http://www.robotswanted.com
"Keeping Personal Robots alive!"
Heathkit HEROS (Jr, 1, & 2000), Androbots, & MAXX STEELE.
------------------------------------------------------------
Richard Erlacher
with its analog data/clock recovery hardware, but those were, in
general, designed before WD's acceptance of the more stabile and
reliable all-digital circuits. These digital circuits are dependent
on clock circuits involving oscillators that were considered pretty
fast for the time while the 2797 with its PLL support hardware didn't
have to process clocks at those high (32x) rates. Digital circuits
more easily cope with the change in data rates imposed by different
drive types, hence lend themselves to more general controller designs.
The instances in which I've seen the 2797 used successfully, e.g. the
Western Digital WD1002-05 bridge controller, support only one drive
size.
There's no reason to believe that the 2797 won't work, but there are
some application notes (which I haven't got any longer) that you
should perhaps look at and understand before proceeding if you need to
support both 8" and 5-1/4" drives, or, 3-1/2" drives for that matter.
What these essentially showed was that the different data rates
require different loop filters, which are all that's external to the
2797 's PLL in their illustration. They show two separate and
distinct loop filters, connected with a few analog switches, as a
result of which only one loop filter is engaged at any one time.
It stands to reason that if you're making only one of these devices,
you may be able to make a design more suitable to your "One-Of"using
similar techniques but not having to cope with mass-production issues.
You'll be able to select your components rather than using
high-precision parts. What's more, you can consider simply adding to
one loop filter rather than exchanging two of them. Whether that
helps or not is, of course dependent on how you do it.
I haven't looked at the Model 1's FDC for some time, but IIRC, it was,
by some, considered to be so bad that it shouldn't work at all.
Consequently there were numerous third-party fixes, and, possibly,
even one from RS. The Model 3 wasn't much better, thoug I do remember
that it attempted to integrate parts from at least two different
analog PLL chipsets, with little success. Consequently there were
several third-party products widely held to be the only way to make
that one work properly. It seems to me that RS had used a MOTOROLA
phase-detector, (MC4044) apparently because they felt the WD version
didn't work as well, and they used a TI VCO, (74LS624) rather than the
WD version, yet they included the WD 1691, which had both these
funcitons on it in their circuit. It was hard to understand why they
did this in view of the then quite high price of the devices.
There's no question that if you can find a WD/SMC 9229 it might be
easier to support various drive sizes and data rates than with the
2797. Finding one might be difficult, however. You could also build
a PAL to handle the clock countdown and write precompensation, but it
would still be wise to use a 9216, in that case to handle the clock
selection and clock/data separation. I don't know how plentiful those
are these days however.
Dick
On Thu, 28 Sep 2000 10:31:25 -0400, "Robert L. Doerr"
<rdo...@bizserve.com> wrote:
<snip>
Robert L. Doerr
Thank you for that excellent explanation on the data seperation. I
am most familiar with the boards from the TRS-80 some of which were
made by Radio Shack and Percom. Some were double density with the
data seperation built on-board and some sold stand alone data seperation
boards.
The reason I am working with the WD2797 disk controller is that I am
doing work on several old Heathkit disk controller cards and they use
the WD2979 controller chip. These cards are used in their HERO 2000
robot and allow a 360K 5.25" floppy drive to be used with a custom
version of MS-DOS 2.13. My goal in working with these cards is to:
- Be able to repair these cards (No matter what is bad)
- Make them more reliable (possible data seperation upgrade)
- Make an improved version of the same card that is compatible.
- Allow a 720K 3.5" drive to be used with the card
I didn't have any plans to try and use Hi-density drives like the 1.2mb
or 1.44mb drives.
Someone had e-mailed me scans of most of the wd2797 data sheet which
helped out a lot. I had a couple of flakey cards that I was finally
able to fix. There are two potentiometers and a variable cap that are
used to adjust the clock and the pre-comp signals. I read in the data
sheet and it told how they should be calibrated and it made sense. Now
I can calibrate them all the same. I've been curious if enhancing the
data seperation would help too.
Any other insight on the quirks of the WD2797 would help
Regards,
Robert
Richard Erlacher
for any sort of upgrade or repair unless you're DEAD CERTAIN you'll
have enough of them.
WIth a few (well, quite a few) cuts and jumpers you can probably use
a 37C65 or something of that ilk. Most of the cuts will be to remove
components you no longer need, since everything's "in there."
Dick
On Thu, 28 Sep 2000 15:00:45 -0400, "Robert L. Doerr"
Walter Rottenkolber
>
>This command is similar to the Read Data command except for the following.
>The controller starts at the index hole and reads the sectors in their
>physical order, not their logical order.
>
>Even though the controller is reading sectors in their physical order, it
>will still perform a comparison of the header ID bytes with the Data
>programmed in the Command Phase. The exception to this is the sector
>number. Internally, this is initialized to a one, and then incremented for
>each successive sector read. Whether or not the programmed Address Field
>matches that read from the disk, the sectors are still read in their
>physical order. If a header ID comparison fails, bit 2 of ST1 (No Data) is
>set, but the operation will continue. If there is a CRC error in the
>Address Field or the Data Field, the read will also continue.
>
>The command will terminate when it has read the number of sectors
programmed
>in the EOT parameter.
>
>* * *
>
>but just the data fields from each sector in physical order. I'll try it
>when I get the chance but I'm pretty sure of the outcome. I've read
>numerous other people's accounts of being unable to do a true raw read with
>a 765.
>
>Amardeep
>
(usually)format data from memory (or from a fast routine that generates
format data on the fly) beginning at the index hole and ending there, or
reads the track to memory. It does NOT identify or error check the sectors.
The purpose of this command is to format the track, and then read back the
result to check for errors.
It has been said that you could use the track data to r/w to a disk, but I
don't know of any DOS that bypasses the chip firmware to do routine sector
r/w.
Walter Rottenkolber
Amardeep S Chana
>The track read and write does just that. It either writes a track of
>(usually)format data from memory (or from a fast routine that generates
>format data on the fly) beginning at the index hole and ending there, or
>reads the track to memory. It does NOT identify or error check the sectors.
>The purpose of this command is to format the track, and then read back the
>result to check for errors.
>
>It has been said that you could use the track data to r/w to a disk, but I
>don't know of any DOS that bypasses the chip firmware to do routine sector
>r/w.
>
>Walter Rottenkolber
>
That is true for the Western Digital 17xx and 27xx family of disk
controllers. It is not true for 765 type controllers which use a high level
"track format" command to which you only supply parametrics like sector
size, count, gap size, and data field byte. The 765 "read track" command
only returns sector data and none of the surrounding format information.
Amardeep
Rich Beaudry
"Robert stated...
>
>> >BTW: Does anyone have a spare Western Digital data book on these old
>> >floppy controllers you would be willing to sell??? Also looking for
>> >a TI Opto-electronics data book from the early 80's.
Robert,
Check out www.freetradezone.com. It does require a registration process,
although you can opt out of the "send me junk email" option :-).
It has datasheets available for just about any semiconductor device ever made.
I found full data sheets for most of the WD floppy controllers, as well as some
old DACs from the 70's, and even many transistors and other obsolete parts.
WELL worth the registration (although you could enter false info if you are
suoper paranoid).
It may even have datasheets on those TI Opto parts ...
I have NO stake in this website, but I can tell you it identified over 90% of
the parts in my junk box!
Rich B.