> Date: Wed, 18 Apr 2007 11:57:43 +1000
> From: Doug Jackson <doug at stillhq.com>
> Subject: Quick survey on equipment
> To: cctalk at classiccmp.org
> Message-ID: <46257B17.3080905 at stillhq.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Some have questioned the number of people on the list who
> have CP/M systems.
>
> Lets do a quick survey - I'll start first!
>
> Pulsar Little Big Board - z80 CP/M 2.2
> Bondewll 2 - z80 - CP/M 2.2
>
> On the list of non CP/M systems:
>
> 3 x Apple II 5.25" disk systems
> 7 x Apple Mac systems (various)
>
> TRS-80 Model 1, 4, 4P
> 2 x Disk Smith System 80
> 1 Exidy Sourcerer
>
> 1 Energy Control Rockwell 65F11 (forth) system
> 1 Homebrew 65F12 system
>
> Amstrad CPC464
>
> TI99/4A - No disk system though :-(
>
> Bucketloads of HP & TI Calculators
>
> No DEC Equipment - So can't help there (But I do have a SBC6120 PDP8
> emulator.)
>
>
> Doug
>
Without venturing into the storage room:
Kaypro 2, II (2), 4 and 10
Osborne OCC-I, Executive
PMC Micromate (2)
Heathkit H89 (2)
Morrow MD11
Seequa Chameleon
Sony SMC-70
Televideo TS-802, TS-803
HP-87 (with CP/M module)
Re:
From: "Robert Armstrong" <bob at jfcl.com>
Subject: WH-27 Problems (was RE: Heathkit H8's, H9's and H-11's)
....
In extended mode the drive could handle 512K diskettes ... So the bottom
line is that if you want to run standard RT-11 on the H-11, you have to set
the switch to RX-01 mode and you have the equivalent of an RX01 drive. No
double density ...
*************
I don't think that's correct; the controller in the H-27 (WH-27) is a Z-80
with a Western Digital 1771. The 1771 is most definitely single density
only. It's not capable of double density.
Hello Folks,
I'm on a business trip to Long Beach, CA next week and would like to know
whether
someone could recommend me any vintage stores or other places in that area I
should visit in my spare time.
I mostly interested in DEC, CDC and Lispmachines or newer stuff like Suns or
similar as well.
Sadly, there no time for me to visit the CHM.
Best Regards,
Marc Holz
Greetings Geeks & Geekettes;
I'm looking for a small pile of Commodore gear for a project a friend of
mine and I are putting together for this year's Chicago Commodore Expo
(which means a deadline of August or so).
I'm after:
Commodore 64s (any case style)
Commodore 128s (pref. not the beefy DCRs to save on shipping)
Disk drives (any type)
Power bricks for the above (drives & machines)
Associated cabling
Game carts (see below)
All of the above will be treated with respect and neither dismantled
(unless it was already broken, although I'd very much prefer working gear)
nor sold on, and will be part of a unique project which you'll all be
detailed on when the time looms near (Ooooo, hush, hush, exciting isn't
it?).
Except the game carts - which I'm cannabalising for their connectors,
which seem to be darned expensive on their own - so if you have broken
carts, even better!
I'd also like to find a monitor, as my own one is back in New Zealand and
out of reach right now, and for the life of me I can't seem to find either
my DIN->composite cables nor any of the blasted RF boxes that seem to
accumulate in every corner _until_ you're looking for one.
I'm looking for people who are willing to let this go for shipping only
(I'm not exactly made of money, but is anyone?) on the guarantee that
there will be no ignominious end to the equipment and the knowledge that
it will be used for a very cool multi-CPU project.
I'm based in the US (50441), by the way, and I'll probably keep my
shipping costs down by only taking up offers by US based people, but
please let me know.
Thank you all!
JP Hindin
>
>Subject: Re: CP/M survey
> From: "Chuck Guzis" <cclist at sydex.com>
> Date: Thu, 19 Apr 2007 08:48:40 -0700
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On 19 Apr 2007 at 3:20, Sridhar Ayengar wrote:
>
>> How does it differ? Aren't all drivers just fundamentally open, close,
>> read, write and ioctl?
>
>Well, CP/M 2.2 have no "open" and "close" function, just read and
>write--single character for character devices and a single 128 byte
>block for mass storage. The closest thing to ioctl is the "select
>unit", "set track" and "set sector" entry points.
Yes.
>While BDOS
>supports open and close functions, it's entirely up to the user to
>track open files--the BDOS doesn't contain so much as a list of open
>files. Early MS-DOS operated the same way--using FCBs for file I/O
>like CP/M.
While the OS didn't do that it was easy to have your own FCB(s) and
the OS would not limit you.
CP/M was a big step up from OSs like NSdos that only did sequential
allocation and even more limited user interface.
>Directories are, of course, flat, though you could
>qualify entries with a "User area" field that was not considered to
>be part of the filename. Allocation information is kept with each
>directory name entry; when a file got large enough, another directory
>"extent" was allocated. There was a very firm upper limit
>(implementation defined) on the number of files one could have on a
>volume. IIRC, the upper limit on disk storage was about 8 MB per
>volume.
The limit is for CP/M2 were 65535addressable sectors * 128bytes =8mb
it would be higher if the math didn't truncate at 16bits. The improved
BDOSs (P2DOS and friends) fixed the math and it was then:
65535 * allocation block size (up to 32k) =2gb
CPM3 and MPM allowed for 512byte sectors and 32mb max logical drive size.
>One needn't worry about reentrancy, multiple character/block requests
>or interrupts. Everything's done with a jump vector table; since
>CP/M is non-multitasking, management of driver data is simple.
CP/M2 is non multitasking, V3 and MPM which are related (same filesystem
and bdos calls) it can be an issue. However, the non-multitask status
of CP/MV2 didn't prevent things like background printing or interrupt
driven IO though it meant the BIOS implmentor had to do the work.
One nasty with a flat file system and allocation scheme is with an 8mb
drive and directory sized for say 2048 entries a directory search on a
moderately full disk was SLOW. It was a sequential search.
>If you were dealing with disks with sector sizes larger than 128
>bytes, some write-behind, read-ahead logic was unavoidable, but even
>there, the BDOS would help out by signifying if the read was for a
>directory block or the write was for a newly-allocated block. If
>you had sufficient RAM to do full track reads and writes, you could
>often improve the speed of CP/M I/O significantly.
IDE helps as it has on drive buffering/cache and a few floppy and
harddisk controllers were buffered and did deblocking in hardware.
One floppy controler that could do this was the JADE DoubleD.
Other oddities is there was no MBR or on disk partition tables for
large drives. The partition info was kept in the DPH/DPB inside the BIOS.
>Disk volume tracking was done using a simple "checksum" on a
>installation-defined number of directory entries. If a disk was
>changed unexpectedly, the BDOS responded by setting its status to
>Read-Only and displaying an error.
Only required for floppy or the uncommon removable harddisk
(CDC hawk anyone).
>Later versions of CP/M supported multi-block I/O and file date and
>time stamps.
They did significantly advancement CP/M as it allowed existing
program base to live on.
Allison
>
>Subject: Re: CP/M survey
> From: Jim Battle <frustum at pacbell.net>
> Date: Thu, 19 Apr 2007 12:19:48 -0500
> To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
>
>Chuck Guzis wrote:
>> ... And most professional apps for CP/M used the 8080 instruction
>> set initially--only later did a bunch of Z80-specific (e.g. ZCPR)
>> code come out. I never could understand this--in general, little to
>> be gained in speed by using Z80 codes.
>
>I thought the main motivation was footprint, not speed. The relative
>jumps save a byte each time they are used, and djnz saved two.
the Z80 instruction set not only had the relative jump, and DJNZ but also
small fixes like the the asymetric problem of you could load the SP
but in 8080 you had to burn a register to get the SP contents. The
block moves and bit tests are worthwhile too.
Where the Z80 gained speed was 4mhz and faster (best 8080 hit was 3)
and a much more sophisticated interrupt capability. That and those
index registers helped solve those times when 8080 needed more
registers to play with pointers without twisty code.
>One of the most wasteful features in the 8080 instruction set, I
>thought, were the 8 conditional calls and 8 conditional returns. I
>would have much rather they had only unconditional call and
>unconditional return only and used those 16 opcodes for something more
>useful. Sure, they were useful once in a while, but not so often that
>they should use up 6% of the single byte opcode space.
;) 8080 was what it was and compare to the 8008 a huge improvement. What
was more interesting to me at that time was to 6800 and 6502 which were
in many ways simpler yet better by a differt route.
One of the oddities of most cpus is 90% of the code is done with a small
portion of the instrucion set. the remaining 10% of code may use less
than 50% of the unused to that point instructions. There are always
a few that are nearly never used.
One example of a 8080 (and 8085 and z80 usage) is ORA A with in one
assembler I renamed to SEF (set flags). The 8080 family is loaded with
instructions like that.
At the other extreme.. 8085 and z80 "unsupported" instructions that every
chip maker insures are there and behave the same even if not specified.
Allison
>
>Subject: Re: WH-27 Problems (was RE: Heathkit H8's, H9's and H-11's)
> From: "Barry Watzman" <Watzman at neo.rr.com>
> Date: Thu, 19 Apr 2007 12:54:42 -0400
> To: <cctech at classiccmp.org>
>
>Re:
>
>From: "Robert Armstrong" <bob at jfcl.com>
>Subject: WH-27 Problems (was RE: Heathkit H8's, H9's and H-11's)
>
>.....
>
> In extended mode the drive could handle 512K diskettes ... So the bottom
>line is that if you want to run standard RT-11 on the H-11, you have to set
>the switch to RX-01 mode and you have the equivalent of an RX01 drive. No
>double density ...
>
>*************
>
>I don't think that's correct; the controller in the H-27 (WH-27) is a Z-80
>with a Western Digital 1771. The 1771 is most definitely single density
>only. It's not capable of double density.
Barry is correct. I know the beastie well enough and single density was
it's thing. However there was a third party version on the market that
could do DD (but not DEC RX02) and was modeled like the H27.
there wer others in the PDP-11 market that did compatable rx02 DD (two
sided) such as the DSD880 and a few others.
Allison