Many thanks for the info. That's a great help. I'll
investigate
the newer drive as it sounds like it could be the
RX33. I have
plenty of DSDD 5.25" disks, so I'll give those a try
first.
Thanks
Ian.
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
I don't follow the mailing list closely, but earlier this month
folks were talking about a tape supposedly labeled "OS/2" for the PDP-11.
My gut feeling is that this is something like how "ASCII" sometimes
becomes "ASC-eleven" or even "ASC2" among those who don't know
what's a roman numeral vs digits vs whatever.
Possibly DOS-11 became D OS-11 became OS/2 :-). But DOS-11 on a TK50
would be unusual in any event! Finding, say, a late version of RT-11
or RSX-11 or RSTS/E or Ultrix-11 on a TK50 seems far more likely.
Almost all PDP-11 OS's have an "11" in the name, usually at the end,
and it's easy to see how this could become a "2" in the mind of someone
who thinks that there is a VAX named Saul or SOL.
Tim.
Al wrote:
> I wrote:
>> I think it's time for me to unsubscribe from this list and
>> get back to reality.
> Talk is cheap.
> Let's see the proof.
Well, I was trying to give him the benefit of the doubt, that of
the zillion layered products that DEC was churning out in the
80's and early 90's that a guy might mistakenly think something
was on the tape that wasn't there because of the
language DEC or somebody else used on the TK50 tape label.
But he tells me I'm insulting his intelligence by suggesting that
there may have been some confusion based on his reading
of the tape label. He's made it perfectly clear he doesn't
want any advice on what was actually on the tape, he's made
up his mind, case closed, there was a VAX named Saul and
OS/2 for the PDP-11 because he's been using the VAX since
the year before it shipped. What else can you or I do, Al?
Tim.
Does anyone have an archive of the files for the GEnie National CP/M RoundTable? I am in the process of putting together a site for the Visual 1050 and there was apparently a section dedicated to the 1050: "Library 37. Visual-1050 CP/M". If possible I would like to include these on my site. I have found several stray entries on the net but have not been able to locate the bulk of the contents (most are named VLIBnn.ARK and described as "Visual 1050 Library Disk #nn"). Any help?
Thanks.
_________________________________________________________________
Climb to the top of the charts!?Play the word scramble challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_jan
I found a web page by a guy who made his own MicroAngelo clone. Its a
pretty neat web page but it hasn't been updated for many years, and he
doesn't seem to respond to emails.
http://www.infinetivity.com/~delscott/ua.htm
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Roy J. Tellason" <rtellason at verizon.net>
> Date: Tue, 05 Feb 2008 01:21:19 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Sunday 03 February 2008 09:19, Chuck Guzis wrote:
>> > However while the IO was better CP/M had a far better file system that
>> > accomodated fragmentation (scatter/gather) where RT-11 (and NS* DOS) had
>> > the linear tag and dump that made enlarging a files or creating variable
>> > length files harder.
>>
>> On the other hand, fragmentation on a floppy can result in very bad
>> performance--and CP/M had no "defragment" utility.
>
>Sure it did. It was whatever you used to format a disk... :-) Seriously,
>I'd copy stuff off elsewhere and then with a clean start re-copy it back
>again, no fragmentation.
Defragger for CP/M is both easy and fun... Use pip to copy the source disk
to the destination disk. Best with two or more drives. the real problem
is it's hard to defrag with limited on disk space without buffering in
ram and thats doable too.
>I thought I had remembered one, but can't seem to find it at the moment.
>
>> I can see the advantages of a system that tends to keep files in a small
>> number of pieces. I've seen the single-piece file structure a lot on
>> industrial equipment controllers.
Makes sense where the file is static in size and whats really being done
a loader. what happens if your doing data bases or data collection
and the assumed file size exceeds the as built file... oops.
>> > Assemble CP/M BDOS at around 100k using ASM and you find any disk under
>> > 400K free space is too small. You still see that today with faster disks
>> > and interfaces.
>>
>> CP/M was singularly ill-equipped to support hard disks of any size beyond a
>> couple of megabytes. We'd started offering SA-8000 14" drives as an option
>> and before too many months, we were getting 40MB drives for what we'd been
>> paying for the single-platter ones. 5.25" HD size increases went even more
>> quickly. We bought 7 and 14MB drives from Rodime and it wasn't long before
>> Rodime was telling us that they were substituting 10MB and 20MB drives. I
>> was asked if I could artificially (via software) limit the new drives to 7MB
>> and 14MB so that marketing could charge for the extra storage. I
>> discouraged the idea very strongly, pointing out that the customers weren't
>> stupid--someone was going to peek inside and read the drive nameplate.
It supported drives to 8mb as a logical unit. ou can have up to 16(less
if you have floppies) logical units (A->P) for a total of 128mb.
All of the CP/M derived works starting with P2DOS and on fixed the math
inside the BDOS allowing for drives to 1Gb.
>Oh yeah. I think if there were one thing I'd like to change about CP/M that
>would probably be it, give me a multi-level directory. Last time I gave
>that some thought I was considering using something like *.LBR files do,
>only in those the utilities commonly used would have you set the number of
>entries you wanted to add at the outset, and you had to go through some
>stuff to add more or compact it., and compressing/decompressing library
>members was a whole separate operation and also had to be done manually. But
>I think it's possible.
Thae allocation scheme used makes it hard to keep track of how many blocks
are used by the content of a subdirectory... you can do it but lots of
recursion needed and that means a rewrite of the whole files system
code and also compatability issues as none of the apps will have any idea
of subdirs.
>I did have a "COMMAND.LBR" that was around 600K in size, had all sorts of
>stuff in it, though mostly I used a fairly small handful of utilities.
>
>> But then DRI was really thinking of the "user number" feature as that-
>> -there was the system (user 0) and your own files under your number,
>> never considering that some users might want to use the feature to
>> organize their data and go cross-number frequently.
>
>Yup, that's exactly what I did.
Many of the ZCPR and later improved CP/M work alikes added named directories
that equated to user numbers.
>Any of you know how some of the CP/M variants dealt with HDs and these other
>issues?
Briefly CP/M doesn't, the BIOS writer does. Since basic CP/M has a
hard limit of 8mb per logical disk drives larger than 8mb are divided
into logical partitions as needed. I have many (6 or more) systems
with hard disks and all have disks greater than 10MB. The system with
a 45mb is partitioned (in bios not using MBR or other dosisms) into
5 logial disks four 8mb and one 5mb. The bios also allows for
assigning what partition is what letter though a user utility. I
also have a system with a 120mb disk set up so any four 8mb partitions
can be "mounted" and "dismounted" as needed. Reason for this is
each disk in the BIOS has buffers associated and they can become
significant in space used. By limiting the number of active drives
I save that space at the cost of only have 32mb on line at any given
time. That was a fair trade for a large TPA in a non banked machine.
that and by most users even 8 megs of disk in one lump is luxury
afer using floppies.
Allison
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Roy J. Tellason" <rtellason at verizon.net>
> Date: Tue, 05 Feb 2008 02:20:29 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Monday 04 February 2008 14:48, Chuck Guzis wrote:
>> I wanted to add a "put that diskette back" alarm to my CP/M
>> implementation when there were files opened for writing
>
>:-)
Fortunately it at least did a check for a changed disk.
>> It was then that I discovered that CP/M made no attempt to track open
>> files and indeed, the behavior of many programs depended on this.
>
>It wasn't really much of an OS, compared to a lot of what else was out there.
I'd argue that CPM is barely an OS annd a should be catagorized as a
filesystem and monitor. there are thing it doesn't manage. For some
without all the IO bells implemented the IO is notably poor.
Allison
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Roy J. Tellason" <rtellason at verizon.net>
> Date: Tue, 05 Feb 2008 02:00:47 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Sunday 03 February 2008 07:34, Allison wrote:
>> >On Thursday 31 January 2008 10:07, Allison wrote:
>> >> Whats more interesting is there was nothing to prevent a termcap file
>> >> and later improved CP/M work alikes did exactly that and many more
>> >> things.
>> >
>> >What sort of stuff would you put into the category of "CP/M work alikes"?
>>
>> NOvados, DOS+, ZRdos, Zsdos and ZCPR addons to CP/M. They all could run
>> CP/M programs but added things missing from basic V2.2. The gotacha was
>> they required z80 as they were stuffing all that into the same space
>> required by V2.2.
>
>Not much of a gotcha, I don't think I'll be doing much with the 8080 these
>days anyhow, and pretty much every single one of the CP/M boxes I have on
>hand here are all equipped with a Z80.
>
>ZCPR I've run across, those others are not familiar to me. Are they out
>there and available? Might be worth a look at them if so.
Try google and expect a lot of results. They have been out there for
years.
Allison
>
>Subject: Re: "CP/M compatible" vs. "MS-DOS Compatible" machines?
> From: "Roy J. Tellason" <rtellason at verizon.net>
> Date: Tue, 05 Feb 2008 01:58:20 -0500
> To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org>
>
>On Sunday 03 February 2008 07:27, Allison wrote:
>(Snip)
>Yup, but that assumes that you want two bytes. CP/M would give a function
>code and then anywhere from zero parameters to several of varying lengths and
>some even were pointers to tables and data areas. You might also want to
>bump the return pointer past the data. :-)
The general methodology works for any length but I showed it for two.
>I think rather than use a scratchpad location to save HL into I just swapped
>it with the top of the stack, which would give you HL pointing to the first
>byte beyond the call, though it's been several years since I worked on this
>and my recollection is a bit more than fuzzy about the whole thing.
You can but if you need HL to do 16bit arithmetic of some such you may
have to save it. I've done code that passed variable length parameters on
the stack but after 3 maybe 5 bytes you have to start storing something
somehwere. Even Z80 has a finite number of registers.
>>
>> Interrupt driven, has some basic terminal sense (vt100 specific)
>> and uses IObyte.
>
>Sounds worth looking at, is it out there anywhere?
Never looked but whole VT180s are findable.
>(Snip)
>> >> Thats a lot of available CPU cycles. the biggest areas of change is that
>> >> modem programs werent pausing for disk IO, they could fill a big (say
>> >> 16k) circular buffer and the cpu can be processing interrupts for IO and
>> >> disk to manage transfers rather than doing a lot of waiting in loops. It
>> >> doesn't take a lot more code but the complexity and debugging is greater
>> >> due to the near concurrent activities.
>> >
>> >One of the real problems I had with early BBSing was the fact that I was
>> > using a CP/M box and that had only a lmiited buffer in the modem program
>> > (probably MDM740 at first, IMP a bit later I think), while the guy at
>> > the other end had a newer and higher-speed modem that had several K of
>> > buffer in it that it would continue to empty after my end had asked it to
>> > hold on a minute...
>>
>> In many cases no buffer. it was more like the other end would stop but by
>> time you told it to your 1 byte maybe 2 buffer overflowed.
>
>I could be mistaken but I think those early comm programs had something like
>128 or 256 bytes of buffer in them. Which was like nothing when the
>higher-speed modem on the other end had several K...
Makes little differnce as the reall pain is when you have to hit the
disk be floppy or hard, most systems the CPU is totoally involved
in doing PIO for the disk transfer(expecially floppy) and the rest
of the world is left to hang. You have to stop the transfer prior
to going to the disk. Many cases that doesnt work well.
When you need speed this is where releaving the CPU of that
using DMA pays.
allison
My son and I watched War Games a few nights back, and I pulled out my
old Jameco JE520 speech synthesizer. We played with it a bit tonight,
and it has a bad EPROM #2, so the upper half of the first word set is
garbled. Questions:
* Anyone have a JE520 that could copy the ROM?
* Or, anyone have other ROMs for the DIGITALKER (soft copies, that is)?
* Anyone have a datasheet on this device? NS54104
Jim