I think anyone who disputes that epay hasn't taken over hamfests is
delusional. That being said, there are still vendors who show up
at the bigger ones (like Dayton and Timonium) and they make the occasional
bargain worthwhile.
As far as classic computing is concerned, I don't see Vax 11/750s
anymore at hamfests: it's all peecees. That doesn't eliminate the
possibility of a mysterious discovery. If the weather is fine (always
a chancy proposition at Dayton), then what is finer than digging
through boxes of junk for the occasional fine item?
Peripherals seem to be in greater supply than processors and cables
abound. So, take the good with the bad.
well, it's not a 2860 selector channel panel, though the design is contemporary
with what you have
http://www.thegalleryofoldiron.com/2860.HTM
it may be a 2870 multiplexer channel. haven't been able to locate a picture of
its CE panel, though.
>
>Subject: Hand-rolling a CP/M machine
> From: "Ethan Dicks" <ethan.dicks at gmail.com>
> Date: Tue, 24 Apr 2007 11:02:52 -0400
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>With all of this recent 8-bit and CP/M talk, it's prompted me to do a
>little digging on what it would take to put together a CP/'M machine
>on my own. I already have a couple of commercially-produced boxes.
>This is about taking a Z-80, some RAM, some ROM and a storage unit and
>making it run CP/M.
>
>I've been reading the various threads, so I have a general idea of
>what has to happen, but I'm still fuzzy on a few specifics, no doubt
>due to my lack of deep experience with the Z-80.
>
>The point of ROM vs RAM at $0000 has been gone over a few times. Do
>"standard" CP/M machines use a shadow-ROM technique, or what, to
>cold-start? We used to use a trick with the 68000 that would map ROM
>at $000000, _and_ at some higher address, with the first few
>instructions jumping to the higher ROM image, , and either an I/O pin
>that toggled the address mapping for the lower ROM image, or just
>watching for the first pulse from A23, such that the act of jumping up
>to the higher ROM address itself would remove ROM from the bottom of
>the memory map, revealing RAM.
there are two ways to do this. One is ROM at 0000h with a latch and
logic to make it appear at reset (boot) and disappear when some
specific event or port is activated.
The other is to OR in a 1 to A15 so that Rom at F000h block also appears
at 0000h and the logic can take that "ORing" out when not needed. The rom
can then be disabled if desired.
>>How did CP/M systems handle 64K of RAM? Was there one primary way it
>was done, or did every hardware vendor do it differently? I should
>probably just confine my efforts to 48K of RAM and use the upper 16K
>for a boot ROM, but if it's easy to support 64K of RAM, why not?
I'd say for practical running of the many CP/M applications 48K of ram
is reasonable. CP/M can run in as little as 20K but, CP/M with ASM
running leaves about 3k for symbol table and buffers in that case.
I'd limit the minimal system then to maybe 32k (one 61256 32kx8 sram).
There are so many different ways to do it that ones imagination can
be taxed! And most ahve been used.
Myself I prefer 8k, 16k or 32k Eprom at 0000h as then I can use that to
launch CP/M and then disable it. CP/M is 5.5K for itself and the BIOS
can add typically 1.5k to 3.5K. So a 8K can hold all of CP/M and BIOS
image. Boot for such a system is simple, copy the image to the last
8k of ram jump to the BIOS coldboot vector ther code will disable rom
and init low ram (page 0 the first 256 bytes) and your off and running.
This saves the need to have system tracks and preparing them with some
system prior to bring up. With 16k or more you can also have monitor
code and utilities i the ROM.
>To confirm, the minimal I/O system is some flavor of serial interface
>for console I/O (presumably piped to a display smart enough to handle
>ANSI codes), and some form of block-addressable storage with a CP/M
>filesystem, right?
Thats one way and by far the most common. Basically CP/M requires a
console that can be any form of keyboard (BIOS makes it look like ASCII
if needed) and a display (the most minimal I've done was 2 lines of
32char LCD!). However, for display I'd advise staying with 64x16 or
better as many apps like BASIC, MUltiplan, Editors want a full 80x24
screen.
>(I'm ignoring handy I/O like parallel printer ports and 8255-type
GPIO and the like, for the moment).
Definatly optional but useful.
> Is it required that the storage unit be writable?
No. CP/M does not swap or page. However, it's less than useful
without some writeable storage but that can be drive B.
I've built systems wher drive A: is 512k of Eprom (EEprom) as WOROM
(write once for bringup) and runs as romdisk and a second "device"
that is 512k of ram as ramdisk. With CMOS ram it can be battery
backed up and for CP/M 512K is a useful working space.
FYI: the core CP/M programs (ED, PIP, STAT, ASM, DDT and LOAD) fit
in somthing like 40K. So a small romdisk of say 128k (27C010) can
hold a lot.
> Is there a minimum size for the display?
CP/M itself doesn't care those anything less than 32char wide
and 4 lines is hard to work with. Applications like editors rarely
work acceptably (to the user) with less tha 64 character lines
and 16of them. One system epson PX-8 is 480x64 pixels and runs
in character mode as 80x8. I'd consider that usable from experiece
with it.
>That wouldn't matter for hanging a VT100-equivalent off of
>the console port, but if I were to use some flavor of textual LCD, it
>would very much matter. To find another way to ask, would the body of
>extant CP/M apps freak out if you try to run them on a display that's
>under 40 chars wide or under 24 chars tall? Do they expect 64 chars
>wide or 80 chars wide? I don't think the OS itself actually cares how
>wide or tall the display is, but perhaps some of the CUSPs, like DIR,
>might.
See comments already made. I'm currently playing with a small pannel
of 240x64 (32x8). Works but hard for reading lots of long text.
Reminder Epson had the an earlier system with a smaller screen, Tandy
M100 was 40x4, Osborne-1 was 50char by 16 lines (might have been 20)
so it's been done.
>Rather than taking a bare Z80, wiring on a Z8530, an SRAM or two and
>an EPROM, I was contemplating beefing up my 1976 SDS Z-80 Starter Kit
>to the point where it could run CP/M. I've written about it here
>before, when I first got it, to remind those that don't know or don't
>remember what it is, it has a ~2MHz Z80, 1K of 21L02 SRAM, room for
>one more K, one 2716 with "ZBUG", two empty 2716 sockets (one attached
>to an EPROM programming circuit), a keypad and 7-segment LEDs, a
>largish wire-wrap area, and two S-100 slots. Presuming I wire the
>SRAM, a larger-capacity EPROM, and some serial device into the
>wire-wrap area, is there anything I should look for in an S-100 card
>that would be interesting to install? A video card (rather than a
>serial console), perhaps? I think I have one or two S-100 video
>cards, but I was never clear on how one attaches a keyboard to that
>rig - is there an ASCII keyboard port typically provided on an S-100
>video card, or is that a separate peripheral?
How you get there is fairly unlimited. If the SDS is S100 it's likely
easier to find a S100 RAM board (Compupro Ram16, ram17 and many others
are 6116 or 6164 srams for 64k).
For exmple I have a Computime SBC-880 S100 card. Thats a Z80, 1K of ram,
2716 Eprom, 8251 serial, 8253 timer (baud rate and free timers) plus
parallel IO on a S100 card. That with a RAM16, VDM1 (64x16 video),
a DEC LK02 keyboard (ASCII parallel) plus one HomeBrew card that
has a IDE drive (100mb) and a s100 interface for 16bit IDE. That's
4 boards and give me a 64k Z80 system that runs CP/M. A 5th board is
a Computime 4 serial port card for excess IO..
S100, My $0.02 is leave those boards for the S100 bus as the signals needed
were devolved from z80 to look like 8080 and to talk to those boards
and it eats TTL when talking from bare Z80. If you have a z80 for S100
and Memory, serial IO the only thing needed (if the Z80 does not have rom
provisions) is a ROM and storage card. Much easier than trying to
interface a non S100 Z80 board to S100. What makes S100 nasty is the
split data bus, one for read path one for write path , that makes for a
lot of redundant buffers and steering logic.
>Thanks for any and all answers to my noobish CP/M questions,
Many have no idea what the hardware can be under CP/M.
Allison
Hello,
Those terminals are based on the IBM Selectric typewriter.
I have used them +- 1975 and must have the IBMmanual of it but d'not ask me where.
If you should need it I can search for it and copy.
Groetjes,
Old-Hans
tsg53939 at scarlet.be
---
Scarlet ADSL Unlimited - Only 24,95 euro per month.
Max download Speed up to 6 Mbps, download volume of 30 GB. Order now...
>
>Subject: Re: Junkbox CP/M system?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Mon, 23 Apr 2007 17:32:21 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 23 Apr 2007 at 18:47, Jules Richardson wrote:
>
>
>> From a programming point of view, how easy is accessing IDE compared to a
>> typical FDC ('765 or similar)? I did write some assembler to access an IDE
>> drive about 12 years ago, but have long since forgotten details! :-)
>
>CF IDE is easy--it's 8 bit. HD IDE uses a 16-bit data path for
>sector data transfer, so that makes things a bit more involved.
>Otherwise, the register set looks pretty much like a WD1003 PC-AT
>type disk controller.
>
>Cheers,
>Chuck
One thing, you do not have to use D8-15! Sur you give up half the data
in a sector but you also eliminate a lot of hardware. That and even an
old 100MB drive will yeild 50mb which by CP/M standards is the world in
a bottle.
Allison
The question on junkbox z80 systems made me remember that
old 386 and 486 system besides providing a raft of 32kx8 SRAMS
also had a keyboard interface chip..
I have a few salvaged 8742(smae as 8242) from PC hardware
of the AT class 80386-486 level.
Without resorting to eraseing the Eproms (8742) and reprogramming
them I've wondered if..
Can these parts (PC AT keyboard interface) can they be used for
small system as a interface from AT or PS2 keyboard to a 8bit micro.
Right off I suspect yes. However is there any information on how
to "talk" software wise to them as to what kind of results and
commands they take?
Allison
>
>Subject: Re: Junkbox CP/M system?
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Mon, 23 Apr 2007 22:16:08 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 24 Apr 2007 at 5:16, Ensor wrote:
>
>> The original IDE drives used 8-bit transfers (I had one in my first XT),
>> even to this day there is still be a signal on the IDE interface to force
>> the use of 8-bit mode.
>
>It's safe to say that there hasn't been an IDE drive manufactured
>within the last 10 years that supports 8 bit data transfer mode.
>Even many of those that claim to support it don't (probably just
>vestigal "cut and paste" text). I once went through my stack of
>320MB and up 3.5" IDE drives and couldn't find a single one that
>actually supported 8 bit PIO
Same here and I have IDE drives all the way down to 10mb. A few like
the WD TIDBIT80 seem to do it and none of my 2.5" drives from 160mb up
do it. All of my Connor 21/40/60/80mb drives do not, nor do any of the
collection of Seagates from 80mb through 500mb. I also have a potload
of WD drives and I suspect a few smaller ones (20mb) but have
found nothing documented that says they do and haven't tried them
> Mostly, IOCS16- is ignored on most
>drives. There was a considerable amount of debate in X3T10 when ATA-
>2 was being hammered out as to whether IOCS16- should even be
>included in the list of signals (it was removed when X3T10 defined
>ATA-3). It was reinstated in ATA-5 on request from the CF group.
All the vendor docs I've seen seem to make IO16 an output as a notification
that the current transfer is 16bit.
>On CF, IOCS16- is honored--but it's not on any IDE hard drive you're
>going to buy today.
I've heard that was true of any drive over 500mb and have not seen anything
over 80mb that does.
Me I keep saying if you really need the simplicity of 8b transfers and
the low cost that comes from a surplus IDE drive just ignore the high 8bits
and enjoy it. There's no harm from that. So what if half the storage
is unused, likely the drive is large anyway.
Allison
>
>Subject: Junkbox parts...
> From: M H Stein <dm561 at torfree.net>
> Date: Tue, 24 Apr 2007 03:41:05 -0300
> To: "'cctalk at classiccmp.org'" <cctalk at classiccmp.org>
>
>A couple of relevant sites:
>
>http://www.csd.uoc.gr/~hy325/spring-2006/docs/8042.pdf
>
>http://www.beyondlogic.org/keyboard/keybrd.htm
>
>mike
Thanks for the info. After years of using nicely encoded
keyboards the AT/PS2 deal is a mess.
Allison
>
>********************************
>Date: Mon, 23 Apr 2007 15:19:55 -0700
>From: "Chuck Guzis" <cclist at sydex.com>
>Subject: Re: Junkbox parts...
>
>On 23 Apr 2007 at 11:29, Allison wrote:
>
>
>> Can these parts (PC AT keyboard interface) can they be used for
>> small system as a interface from AT or PS2 keyboard to a 8bit micro.
>> Right off I suspect yes. However is there any information on how
>> to "talk" software wise to them as to what kind of results and
>> commands they take?
>
>It's all described in pretty decent detail in the PC AT Techref.
>Look in the "System Board" section. When I first saw it, I wondered
>why the IBM writers had wasted so much paper on it.
>
>Cheers,
>Chuck
This is my annual looking for item.
I am serching for the schematic or manual supplied with
the IMSAI IMP-48. The IMP48 is a single board computer
that used 8035, eprom(1k), ram(1k) and 8279 keyboard display
contrller to drive an 8 digit led display and a keypad.
Allison
>
>Subject: Re: Junkbox parts...
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Mon, 23 Apr 2007 15:19:55 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 23 Apr 2007 at 11:29, Allison wrote:
>
>
>> Can these parts (PC AT keyboard interface) can they be used for
>> small system as a interface from AT or PS2 keyboard to a 8bit micro.
>> Right off I suspect yes. However is there any information on how
>> to "talk" software wise to them as to what kind of results and
>> commands they take?
>
>It's all described in pretty decent detail in the PC AT Techref.
>Look in the "System Board" section. When I first saw it, I wondered
>why the IBM writers had wasted so much paper on it.
I don't have the PC AT Techref, any hope for that on line?
Also are the later versions (the AT version used a 8041A and the
386 and later versions use 8042 [more ram, more rom and faster])
the same as that spec?
Allison
