date:20201004

On 10/4/20 8:58 PM, jim stephens via cctalk wrote:

> I had not seen your earlier no tape gap mentions.

The old CDC 6000 SCOPE 1LT driver.  Since SCOPE user programs use
circular buffering, The PP overlay 1LT simply emptied the CM buffer and
wrote it, 12-bit word by 12-bit word to the drive controller, so long as
the CPU program kept the buffer filled.

The problem arose if the program either failed to keep up (e.g.
competing programs demanding the CPU) or if an ECS transfer occurred.
Where I got involved was with a 4-CPU configuration sharing 4MW of ECS,
using the ECS for swap space.  ECS transfers completely swamp the
read/write pyramid, so the PP gets locked out and can't service the
drive.  Recovery was doing a backward-read to the BOT or preceding IRG.
Lather, rinse, repeat.

It was fun to watch and we never solved that one to anyone's
satisfaction.  I don't know if 1LT survived in NOS.

Long NRZI reads/writes are easy, as all that was needed was to keep a
XOR of the frames as they're read or written for the LRC.  PE and GCR
tapes would be a bit thornier, I'd imagine.

--Chuck

Re: 9 track tapes and block sizes

2020-10-04 Thread jim stephens via cctalk





On 10/4/2020 8:47 PM, Chuck Guzis via cctalk wrote:

On 10/4/20 8:12 PM, jim stephens via cctalk wrote:


On 10/4/2020 4:00 PM, Chuck Guzis via cctalk wrote:

On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:



I don't believe that you're missing anything.   When I process these
files, I mask off the lower 24 bits as the block length.  A 16MB tape
block is impossibly large in any case.

--Chuck

Oil logging tapes write 9 tracks with no inter record gaps or file marks
till EOT.  I'm guessing you've not digitized any of those?

A couple of years ago, one of the NASA logging units turned up for not
much money.  Big flight case.  Basically consisted of a Kennedy
incremental drive (i.e. stepper) brought out to several BNC connectors.

My recollection is that the Kennedy 9000-series unit was NRZI and likely
800 bpi.   Unlikely that you could get 16MB on a 10.5" reel with that.
Probably unreadable on standard tape drives with limited formatter
memory.  I've also mentioned CDC 7-track "long tapes".

I've certainly seen the 9-track analog telemetry tapes also, but they're
a much different kettle of fish.

--Chuck

The Microdata 1600 with the NRZI interface could write an entire tape of 
normal "record" data  with a Pertec drive.  We wrote code to write IBM 
records on our system and make our 360 happy.  One of the debug efforts 
had a bug in some experimental code that neglected to do the eot order 
to the controller, and the entire tape was one record.


The system did retries on it till the system crashed, then sucked the 
entire tape into the vacuum columns.  We weren't popular that day.


The system I mentioned earlier was at company my partners worked at 
earlier.


I had not seen your earlier no tape gap mentions.

Thanks
Jim

Re: 9 track tapes and block sizes

On 10/4/20 8:12 PM, jim stephens via cctalk wrote:
> 
> 
> On 10/4/2020 4:00 PM, Chuck Guzis via cctalk wrote:
>> On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:
>>> 
>> I don't believe that you're missing anything.   When I process these
>> files, I mask off the lower 24 bits as the block length.  A 16MB tape
>> block is impossibly large in any case.
>>
>> --Chuck
> Oil logging tapes write 9 tracks with no inter record gaps or file marks
> till EOT.  I'm guessing you've not digitized any of those?

A couple of years ago, one of the NASA logging units turned up for not
much money.  Big flight case.  Basically consisted of a Kennedy
incremental drive (i.e. stepper) brought out to several BNC connectors.

My recollection is that the Kennedy 9000-series unit was NRZI and likely
800 bpi.   Unlikely that you could get 16MB on a 10.5" reel with that.
Probably unreadable on standard tape drives with limited formatter
memory.  I've also mentioned CDC 7-track "long tapes".

I've certainly seen the 9-track analog telemetry tapes also, but they're
a much different kettle of fish.

--Chuck

Re: 9 track tapes and block sizes

2020-10-04 Thread Al Kossow via cctalk





I'm surprised that they have not turned up since they are useful for wells when 
trying to enhance output.


seismic data recovery from tape has been going on for a long time

Re: 9 track tapes and block sizes

2020-10-04 Thread jim stephens via cctalk





On 10/4/2020 4:00 PM, Chuck Guzis via cctalk wrote:

On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:



I don't believe that you're missing anything.   When I process these
files, I mask off the lower 24 bits as the block length.  A 16MB tape
block is impossibly large in any case.

--Chuck
Oil logging tapes write 9 tracks with no inter record gaps or file marks 
till EOT.  I'm guessing you've not digitized any of those?


A friend built a custom machine which could be placed on site at the 
well site.  The tapes would be run to the unit, and then the data stream 
transmitted to a US based location for analysis.  Made necessary in 
Canada as they became very aggressive about transmission of such data.


In the 70's and 80s when this was in use it was very difficult to 
transport half inch tapes across the border w/o being challenged because 
customs was tipped off that the tapes were all potentially banned material.


I'm surprised that they have not turned up since they are useful for 
wells when trying to enhance output.


Thanks
Jim

Modcomp computers and documentation

2020-10-04 Thread devin davison via cctalk

Greetings everyone, it's Been a while since i posted here.

I had picked up some modcomp minicomputers over the past couple years. A
modcomp classic, with a nice front panel with binary swiches, similar to a
pdp 11. There is a modcomp 32 as well, the machine boots from internal
floppy drives.

I was eager to pick up these machines, and save them from being thrown out.
I picked up all of the documentation as well. Everything. A truckload of os
information. I started to scan it all, but about 3/4 of the way through, my
scanner broke.

The 32 machine was not stored in climate controlled conditions before i
picked it up, and is a bit more worn. It is designed to boot off floppys to
load the microcode into the cpu... but the floppys... id be supprised if
anything survived. Stored in bad conditions.

The classic has internal microcode roms and will not have the same
troublesome problem.

I have been unable to devote the time and space to these machines as i had
planned. I have been far too busy working at ibm, i am planning to shut
down my side interests and focus on my dec pdp 11 stuff and ibm mainframe.

I am looking to see if anyone would be interested in buying these. I spent
a great deal getting them moved and keeping them in cool climate controlled
storage, i am looking to see if i can get any offers and break even.

Keep in mind, they are the size of a computer rack and heavy.

I will post back with pictures soon.

Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

2020-10-04 Thread Brent Hilpert via cctalk

On 2020-Oct-04, at 1:55 PM, Chris Hanson wrote:
> On Oct 4, 2020, at 1:53 PM, Brent Hilpert  wrote:
>> 
>>> For the latter two, I need to figure out whether my backplane supports ABCD 
>>> use in the first couple of slots, or if it’s purely an ABAB model. (The 
>>> KDF11-A, RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to 
>>> interpret that as ‘these were configured together in this pattern” rather 
>>> than “these happened to fit in here for storage.”)
>> 
>> I have an ~ 30 page manual for the MDB MLSI-BA11-600 series chassis, if 
>> there is something that might be answered from that.
> 
> Whoa, cool—that’s the chassis I have! Is the manual scanned?

Photographed. No scanner.
It's not as good as 600dpi scan, but pretty good.

I'll send access url.

Re: 9 track tapes and block sizes

On 10/4/20 1:50 PM, J. David Bryan via cctalk wrote:
> On Friday, October 2, 2020 at 13:51, Al Kossow via cctech wrote:
> 
>> Those would already be broken with Bob's use of large negative numbers
>> for physical end of tape and 'bad block is here' (you don't get to know
>> how big that bad block was, so that is hell with tapes with
>> variable-length records, grumble..)
> 
> I'm not sure I understand.  SIMH metadata markers are treated in the tape 
> library code as unsigned values, so EOM and erase gap are seen as large 
> unsigned values.  The format limits record lengths to 24 bits (so about 16 
> MB maximum per record), reserving the upper 8 bits to indicate the type of 
> the marker, and the bad record marker is the top byte = 0x80.  The record 
> length of a bad block is encoded in the lower 24 bits and indicates how big 
> the bad block was.
> 
> What am I missing?

I don't believe that you're missing anything.   When I process these
files, I mask off the lower 24 bits as the block length.  A 16MB tape
block is impossibly large in any case.

--Chuck

Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

2020-10-04 Thread Chris Hanson via cctalk

On Oct 4, 2020, at 1:53 PM, Brent Hilpert  wrote:
> 
>> For the latter two, I need to figure out whether my backplane supports ABCD 
>> use in the first couple of slots, or if it’s purely an ABAB model. (The 
>> KDF11-A, RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to 
>> interpret that as ‘these were configured together in this pattern” rather 
>> than “these happened to fit in here for storage.”)
> 
> I have an ~ 30 page manual for the MDB MLSI-BA11-600 series chassis, if there 
> is something that might be answered from that.

Whoa, cool—that’s the chassis I have! Is the manual scanned?

  — Chris

Re: 9 track tapes and block sizes

2020-10-04 Thread J. David Bryan via cctalk

On Friday, October 2, 2020 at 13:51, Al Kossow via cctech wrote:

> Those would already be broken with Bob's use of large negative numbers
> for physical end of tape and 'bad block is here' (you don't get to know
> how big that bad block was, so that is hell with tapes with
> variable-length records, grumble..)

I'm not sure I understand.  SIMH metadata markers are treated in the tape 
library code as unsigned values, so EOM and erase gap are seen as large 
unsigned values.  The format limits record lengths to 24 bits (so about 16 
MB maximum per record), reserving the upper 8 bits to indicate the type of 
the marker, and the bad record marker is the top byte = 0x80.  The record 
length of a bad block is encoded in the lower 24 bits and indicates how big 
the bad block was.

What am I missing?

  -- Dave

Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

2020-10-04 Thread Brent Hilpert via cctalk



On 2020-Oct-04, at 1:14 PM, Chris Hanson via cctalk wrote:

> Thanks to everyone who replied, on- and off-list! There’s an MXV11-B (M7195) 
> on its way to me. :)
> 
> Since people were asking about my setup, here’s what I have:
> 
> - MDB BA11-clone enclosure, PSU, and 8-slot 22-bit backplane
> - DEC KDF11-A (M8186) rev C processor with FPP added
> - DEC DLV11-J (M8043) SLU
> - Motorola M1132 128KW RAM
> 
> And some stuff that’s untested but I’m eager to try:
> 
> - (soon) Emulex UC07 SCSI controller
> - (soon) DEC MXV11-B (M7195) system controller
> - DEC MSV11-LF (M8059) 64KW RAM
> - DEC DEQNA (M7054) Ethernet controller
> - DEC RLV12 (M8061) RL01/02 disk controller
> - MDB MLSI-SCM11 system controller
> 
> For the latter two, I need to figure out whether my backplane supports ABCD 
> use in the first couple of slots, or if it’s purely an ABAB model. (The 
> KDF11-A, RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to 
> interpret that as ‘these were configured together in this pattern” rather 
> than “these happened to fit in here for storage.”)

I have an ~ 30 page manual for the MDB MLSI-BA11-600 series chassis, if there 
is something that might be answered from that.


> I’m actually still looking for docs on the MSLI-SCM11, since it looks 
> extremely configurable and I have no idea how to use it or what it’ll provide…

Manuals, catalogs, brochures posted on Archive.org

2020-10-04 Thread J. Peterson via cctalk

Last year I found a box of material, much of it related to S-100 
computers and the Sol I owned in the 1970s.  I've scanned it in and 
posted it to the Internet Archive:


https://archive.org/details/@j_peterson

Folks researching obscure old devices (Biotech Electronics CGS-808, 
anyone?) may find something useful. I still have a few documents 
waiting to scan, but this is 98% of it.


Cheers,
jp

Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

2020-10-04 Thread Chris Hanson via cctalk

Thanks to everyone who replied, on- and off-list! There’s an MXV11-B (M7195) on 
its way to me. :)

Since people were asking about my setup, here’s what I have:

- MDB BA11-clone enclosure, PSU, and 8-slot 22-bit backplane
- DEC KDF11-A (M8186) rev C processor with FPP added
- DEC DLV11-J (M8043) SLU
- Motorola M1132 128KW RAM

And some stuff that’s untested but I’m eager to try:

- (soon) Emulex UC07 SCSI controller
- (soon) DEC MXV11-B (M7195) system controller
- DEC MSV11-LF (M8059) 64KW RAM
- DEC DEQNA (M7054) Ethernet controller
- DEC RLV12 (M8061) RL01/02 disk controller
- MDB MLSI-SCM11 system controller

For the latter two, I need to figure out whether my backplane supports ABCD use 
in the first couple of slots, or if it’s purely an ABAB model. (The KDF11-A, 
RLV12, and MLSI-SCM11 came in the backplane, but I’m hesitant to interpret that 
as ‘these were configured together in this pattern” rather than “these happened 
to fit in here for storage.”)

I’m actually still looking for docs on the MSLI-SCM11, since it looks extremely 
configurable and I have no idea how to use it or what it’ll provide…

As for what I’m going to do with it, I’m thinking XINU. Comer’s book is one of 
the two books via which I learned C (Tannenbaum’s was the other) so I think 
that’d be a fun system to have up and running, especially since it has IP 
support.

  — Chris

Re: DRIVPARM and DRIVER.SYS (Was: IBM PC-DOS 2.10 explorations

On 10/4/20 12:16 PM, Fred Cisin via cctalk wrote:
>>> On SOME systems, you could substitute
>>> DRIVPARM = /D:1 /F:2 for similar effect.
> 
> On Sun, 4 Oct 2020, Chuck Guzis via cctalk wrote:
>> IIRC, in xDOS 3.2 and 3.3 DRIVPARM produced an error if specified as
>> usual, but when DRIVPARM was suffixed by a string of three contorl-A
>> (hex 01h) characters, it worked fine.
>> Good ol' DOS arcana.
> 
> THANK YOU!  That provides some clues about the issue of BIOS, not DOS,
> incompatability.


Beg to differ, Fred.   CONFIG.SYS is processed by DOS, not the BIOS.  In
this case it seems to be a lexical quirk to keep folks from using the
feature.

--Chuck

Re: DRIVPARM and DRIVER.SYS (Was: IBM PC-DOS 2.10 explorations


On SOME systems, you could substitute
DRIVPARM = /D:1 /F:2 for similar effect.


On Sun, 4 Oct 2020, Chuck Guzis via cctalk wrote:

IIRC, in xDOS 3.2 and 3.3 DRIVPARM produced an error if specified as
usual, but when DRIVPARM was suffixed by a string of three contorl-A
(hex 01h) characters, it worked fine.
Good ol' DOS arcana.


THANK YOU!  That provides some clues about the issue of BIOS, not DOS,
incompatability.

RE: DOS Versions (Was: IBM PC-DOS 2.10 explorations


> MS-DOS 5.00 first version sold RETAIL


On Sun, 4 Oct 2020, Ali wrote:
Fred,I have to respectfully disagree here. 3.20 was sold in retail. It 
was packaged in the dark blue packaging which was the norm for MS at 
that time (after the green packaging of earlier products).?? I have a 
copy sitting up on my shelf (in fact I have both 3.20 and 3.21). 4.00 
seems to be in the grey oem package but not necessarily branded (i.e. a 
generic rey box included with new system purchase) . I have not seen 
anything MS retail before 3.20.-Ali


When IBM announced 3.20, I stood in line outside the IBM retail store in 
Oakland for the doors to open.  Support of 3.5" was important to me.



We need to differentiate between Retail Sales BY MICROSOFT, V manufacture 
and WHOLESALE sales by Microsoft to OEMs for them to retail.  With a WIDE 
variety of different packagings, ranging from personalized to the OEM 
(Compaq, Zenith, Morrow, etc.), very generic, and even packaging that 
would not be out of place for a Microsoft retail sale.


I was unaware of DOS Retail sales done directly by Microsoft prior to 
5.00.


Although MANY OEMs would sell to anybody with money, most vendors at 
shows, and even stores, were acquiring their inventory from OEMs.


They wouldn't really be called "GRAY MARKET" unless Microsoft's 
terms with the OEM had precluded that.


But, if you have reason to believe that your copies came directly from 
Microsoft, not through an OEM, OR came through a retail store that had 
no affiliation with an OEM, then I need to revise my perception of when 
Microsoft started to retail DOS.  Has anybody ever seen a retail price 
list or RETAIL SALES (V product) ad?  (write/call to purchase)
YES, I can be TOTALLY WRONG.   I felt the elephant's tail and smelled the 
region, but did not have the big picture.



I had even previously speculated that the 1991 date of 5.00 might reflect 
10 year non-competition terms in the original IBM/Microsoft contract(s).



Microsoft certainly did have capability of retail, at least for SOME 
products.  Did they RETAIL the Softcard, or only Wholesale?


In 1979?, Lifeboat (that Microsoft had redirected me to) had 
repeatedly failed to fulfill an urgent need for multiple copies of the new 
Microsoft Fortran for TRS80,  On the way back from the eclipse in Montana, 
I made a stop, and a friend (Bob Wallace) who worked for Microsoft handed 
me the very first couple of copies in the Seattle airport.
The handoff WITHIN state of Washington should have prevented sales tax 
exemption for interstate commerce.  It could still be exempt due to being 
FOR RESALE (although THAT should have required me to fill out forms with 
the WA state taxman), so they might have written it up as being interstate 
(legal if they called me a courier, rather than the customer?)


--
Grumpy Ol' Fred ci...@xenosoft.com

Re: DRIVPARM and DRIVER.SYS (Was: IBM PC-DOS 2.10 explorations

On 10/4/20 10:54 AM, Fred Cisin via cctalk wrote:

> On SOME systems, you could substitute
> DRIVPARM = /D:1 /F:2 for similar effect.
> Same switches as DRIVER.SYS.
> EXCEPT, DRIVPARM would alter the parameters for existing drive letter,
> NOT create a new drive letter.  See also, LASTDRIVE
> (With 4 floppies, CD-ROM(s), HDD(s), parallel port drive(s),
> Floptical(s) on SCSI, RAMDISK(s), etc., didn't want to waste drive letters)

IIRC, in xDOS 3.2 and 3.3 DRIVPARM produced an error if specified as
usual, but when DRIVPARM was suffixed by a string of three contorl-A
(hex 01h) characters, it worked fine.

Good ol' DOS arcana.

--Chuck

Re: Identifying mystery TI ICs (Motorola MDP-1000 investigation continues...)

2020-10-04 Thread Josh Dersch via cctalk

On Sun, Oct 4, 2020 at 10:26 AM Brent Hilpert via cctalk <
cctalk@classiccmp.org> wrote:

> On 2020-Oct-04, at 1:22 AM, Josh Dersch via cctalk wrote:
>
> > More mysteries while poking at the MDP-1000.  Spent some time this
> evening
> > working out the rest of the signals on the power harness (I suspect
> inputs
> > for an LTC circuit and a "power good" signal, as well as something
> > connected to a relay on the backplane, probably related to power
> control).
> >
> > There are a lot of unidentifiable ICs on the main CPU logic board and on
> > the backplane, mixed in with bog-standard 7400-series TTL.  Curious if
> > anyone has any ideas, as my searches and perusal of datasheets/databooks
> on
> > Bitsavers have turned up nothing.  These are all TI-manufactured ICs,
> 1969
> > manufacturing dates, with "SN48xx" and "SN63xx" part numbers (a few omit
> > the "SN" prefix.)  I'm wondering if these are just standard 7400 ICs with
> > special codes; for example there are several SN4816's near the edge
> > connector for the I/O bus, where a 7416 might (?) make sense, and from
> some
> > basic probing and following traces I think the pinouts make sense.
> > (Everything's conformal coated so it's a real bear to beep things out...)
> >
> > Any ideas?
>
> I have run across TI ICs from that era with odd/unknown series numbering,
> in particular the SN3900 and SN4500 DTL ICs.
> Notably:
> - by pinout they match up with standard DTL series ICs,
> - I have only found these in equipment from one manufacturer:
> calculators built by Canon.
>
> I received a solitary page of datasheet for some of them (by way of a
> Canon service center many years ago), but I have never seen them mentioned
> in TI databooks from the era, even in those sections where they list e.g.
> "other products from TI" and proceed to list little known series and part
> numbers.
>
> So an obvious guess is these were house numbering systems of standard
> parts done for the purchaser/equipment manufacturer but with TI's format
> scheme rather than a format specified by the manufacturer. Another guess
> would be standard parts tested and selected for purchaser-specified
> parameters, although that seems a little excessive for these cases.
>

Yeah, either of those options seems a likely possibility.  It definitely
seems like they were building this thing for bulletproof operation, so
maybe it really is the latter.


>
> The 54/7400 series originated with TI in 65, I'm not aware of them
> producing any other TTL series, other than perhaps second-sourcing some
> other manufacturer's.
> I guess that's another possibility - another manuf's TTL series, labeled
> differently.
>
> Odd that this Motorola CPU is filled with ICs manufactured by TI.
>

Yeah, the irony of this was not lost on me.  Other than the aforementioned
linear ICs in the core modules, every IC in this has a TI logo on it.


>
> It's conceivable, although it seems less probable, that they're DTL rather
> than TTL.
>
> On the whole, best guess would seem to be 7400-series inside.
>

Yeah, I'm guessing (hoping) 7400 as well, especially since there are actual
74xx-labeled ICs in here casually mixed with the 48xx and 63xx.

A thought occurred, that if I get desperate I could remove a few of the ICs
and attempt identification using the IC tester I have.  Not going to do
that unless I can't figure it out any other way.  The good news is there
aren't too many varieties.  I haven't done a full inventory but there's not
more than a dozen or so different types in here.


>
> --
>
> On another issue, did you trace the +/-15V lines to the core
> address/inhibit drivers?
> Could some of the remaining wires from the PS be other core supplies - 15V
> was a little low compared to most core systems I've seen.
>
>
I did manage to trace the +/-15V lines to the drivers on the core memory.
I don't believe any of the extra signals are other voltages -- three of
them go to the CPU board, one goes to the aforementioned mystery relay, one
goes to a tiny bit of logic on the mainboard (I suspect some manner of
LTC), and the last goes to a trace that just dead-ends and goes nowhere at
all.  The very little documentation I have on the CPU itself suggests that
the supply provided only +5 and +/-15.  There are two sets of power rails
for each; the first goes to the CPU, front panel, and two memory slots, the
second set goes to the other two memory slots.  I suspect that upgrading
past 8K of memory required a power supply upgrade.

- Josh

Re: IBM PC-DOS 2.10 explorations




Sent from my iPhone

> On Oct 4, 2020, at 1:07 PM, Fred Cisin via cctalk  
> wrote:
> 
>> On Sun, 4 Oct 2020, Will Senn wrote:
>> I am using a Thinkpad T430 w/DOS 6.22. If I can figure out how to get 3.31 
>> on there, I'll give it a shot. I bought a Floppy-USB connector for my old 
>> 1.44 floppy drive and it works fine with DOS 6.22, but I'm not sure where to 
>> locate 3.31 media that I could burn onto a 1.44 floppy and boot. I have 
>> sealed IBM DOS 3.3 media, but I don't think my T430 is really compatible :). 
>> So, I'm not keen on opening the seal...
> 
> I'm curious.
> 6.22 did not have native USB support - that didn't come about until WIN98SE.
> Are you running CONFIG.SYS drivers for it?
> 
> 

I think it’s the laptop BIOS faking the USB as a standard floppy to DOS.


> If you can find an original copy of COMPAQ MS-DOS 3.31, that was originally 
> available on 1.2M and 1.4M
> Zenith MS-DOS 3.31 is another popular choice.
> 
> Try to find it, rather than opening the PC-DOS 3.30.  3.30 (and all earlier) 
> did not support HDD >32M, although there were ways to cheat that limitation, 
> such as the network redirector (with MSCDEX) coul make a local drive LOOK 
> like it was a network drive elsewhere.
> 

Great to know, thanks!
> --
> Grumpy Ol' Fred ci...@xenosoft.com

Re: IBM PC-DOS 2.10 explorations


On Sun, 4 Oct 2020, Will Senn wrote:
I am using a Thinkpad T430 w/DOS 6.22. If I can figure out how to get 3.31 on 
there, I'll give it a shot. I bought a Floppy-USB connector for my old 1.44 
floppy drive and it works fine with DOS 6.22, but I'm not sure where to 
locate 3.31 media that I could burn onto a 1.44 floppy and boot. I have 
sealed IBM DOS 3.3 media, but I don't think my T430 is really compatible :). 
So, I'm not keen on opening the seal...


I'm curious.
6.22 did not have native USB support - that didn't come about until 
WIN98SE.

Are you running CONFIG.SYS drivers for it?


If you can find an original copy of COMPAQ MS-DOS 3.31, that was 
originally available on 1.2M and 1.4M

Zenith MS-DOS 3.31 is another popular choice.

Try to find it, rather than opening the PC-DOS 3.30.  3.30 (and all 
earlier) did not support HDD >32M, although there were ways to cheat that 
limitation, such as the network redirector (with MSCDEX) coul make a local 
drive LOOK like it was a network drive elsewhere.


--
Grumpy Ol' Fred ci...@xenosoft.com

DRIVPARM and DRIVER.SYS (Was: IBM PC-DOS 2.10 explorations


When 5150, 5160, and 5170 first came out, 3.5" drives did not yet exist.
OEMs that were early adopters of them used MS-DOS 2.11.  The disk format 
was not always the same as what IBM used starting with DOS 3.20.
For example, GAVILAN MS-DOS 2.11 supported 720K 3.5", but with a different 
format until version 2.11K (by which time the company had collapsed)


When IBM introduced their 720K 3.5" drives, along with PC-DOS 3.20, they 
also started selling add-on 3.5" drives!   First an external with DC37 
connector, and then later externals for PS/2.  Those could be connected to 
the external floppy port of 5150 and 5160.


BUT, DOS didn't know from 720K, and would do a 360K image on the drive.
Until TOLD otherwise.

DRIVER.SYS was an installable device driver, starting with DOS 3.20, for 
using unexpected drive types (such as not included in the AT CMOS), since 
5150, 5160, 5170 all had hardware that could handle 720K 3.5".
And 5170 hardware could handle 1.4M before that was included in early 
BIOS CMOS.


DEVICE = DRIVER.SYS /D:1 /F:2 told DOS to create a new additional 
drive letter for 720K in the physical second FLOPPY drive.


/D: specified drive (0 - 255, although stock controller only did 0 - 3)

/F: specified drive type
0 - 160 K/180 K or 320 K/360 K
1 - 1.2 megabyte
2 - 720 K (3.5" disk or 80 cylinder low density 5.25 (NOT used in USA))
3 - SD 8"(not supported on all)
4 - DD 8"(not supported on all) 
5 - Hard disk

6 - Tape
7 - 1.44 MB (3.5" disk)
8 - Read/write optical disk
9 - 2.88 MB (3.5" disk)


drive type could also be specified by /T:, /S:, /H: for cylinders, sectors 
per track, and sides; BUT it would NOT let you create as needed; it only 
used that data to look for a match in the existing list.  For example, if 
you told the 5170 that the 8" drive was a 1.2M (not all recognized type 3 
and 4), could you tell it 77 tracks V 80?  (Similar situation in FORMAT)
And some later systems permitted /F:720, etc., since "who can remember 
drive type NUMBER?"




On SOME systems, you could substitute
DRIVPARM = /D:1 /F:2 for similar effect.
Same switches as DRIVER.SYS.
EXCEPT, DRIVPARM would alter the parameters for existing drive letter, NOT 
create a new drive letter.  See also, LASTDRIVE
(With 4 floppies, CD-ROM(s), HDD(s), parallel port drive(s), Floptical(s) 
on SCSI, RAMDISK(s), etc., didn't want to waste drive letters)



DRIVPARM was not documented in PC-DOS

I still don't understand:
On a 5170, with IBM BIOS ROMs using MS-DOS, DRIVPARM would produce an 
"UNRECOGNIZED CONFIG.SYS COMMAND" message.
On a 5170, with IBM BIOS ROMs using PC-DOS, DRIVPARM would produce an 
"UNRECOGNIZED CONFIG.SYS COMMAND" message.
On a 5170, with NON-IBM BIOS ROMs using MS-DOS, DRIVPARM would work 
correctly.
On a 5170, with NON-IBM BIOS ROMs using PC-DOS, DRIVPARM (UNDOCUMENTED) 
would work correctly.
Notice that with the NON-IBM BIOS, it would work with MS-DOS OR PC-DOS. 
"Lack of existence in PC-DOS" was NOT an issue.
With the IBM BIOS ROMs, it would not work, disunirregardless of MS-DOS V 
PC-DOS.
Therefore, it seems that it was present in BOTH versions of DOS (albeit 
undocumented in PC-DOS), but had a strange incompatability with the IBM 
BIOS ROMs.  And, especially strange that the error message seemed to 
clearly be an OS problem.



All of the software changes for 720K 3.5" would also work for 5.25" low 
density 80 track per side 720K drives.  (What had the comical "QUAD 
DENSITY" name in many CP/M systems)  Drives such as Tandon TM100-4, TEAC 
55F, Shugart/Panasonic/Matsushita 465.



--
Grumpy Ol' Fred ci...@xenosoft.com

IBM 3279 analogue board / schematics?

2020-10-04 Thread Mattis Lind via cctalk

I am helping a friend with his IBM 3279 terminal. I got the PSU working
after reverse engineering it. Concluded that the SMPS control chip was a
standard TDA 2640 in IBM disguise.

But of course the thing didn't work with the PSU fixed. A fuse which was in
series with the vertical deflection coil on the analogue board went toast
together with a 200 ohm resistor in the vertical deflection circuit.

https://i.imgur.com/O4YEsdL.jpg

At first I thought this had to do with some kind of fault in the vertical
deflection coil itself. It measured only 1.2 ohms. But checking the IBM MAP
manual revealed that both deflection yokes are supposed to be less than 2
ohms.

So there has to be something else. I powered up the analogue board with the
5V and 8.5V that is normally supplied by the PSU (left the 103V unconnected
since it used for the HV mostly) just to see what happened. The power
consumption was reasonable, 0.3 amps on the 5V and 0.16A on the 8.5V.

I then probed around among all those annoying IBM marked chips and square
aluminium boxes. I found one chip that had 250 kHz on a pin. The chip
appeared to be a divider since there were also 125 kHz, 62 Khz 31 kHz and
15 kHz. It seems to be originating from a square aluminium box. And then I
found a signal which was around 20 Hz on another chip.

As far as I understand the 15 kHz would fit well with the 64us sweep in the
manual.
But what is the purpose of the 20Hz signal? Vertical deflection?

http://bitsavers.trailing-edge.com/pdf/ibm/3279/SY33-0069-3_3279_Color_Display_Terminal_Maintenance_Information_Part_1_Nov81.pdf

According to the above manual the frame sync is 10 ms for model 2 and 13.8
ms for model 3 (this is a model 3).

And moreover if 20Hz is the frequency used for generating the vertical it
could explain why the fuse blew since the current in the deflection yoke
should normally increase linearly with time. Three times longer deflection
period would yield a three time higher current, thus very likely to exceed
the 1.5A rating of the fuse.

So I am looking for either another analogue board for an IBM 3279 or a
schematic for the thing or maybe both would be great. IBM stuff is
annoyingly hard to repair...

Has anyone seen schematics for the IBM 3279? Does anyone have a spare
analogue board?

/Mattis

RE: DOS Versions (Was: IBM PC-DOS 2.10 explorations

2020-10-04 Thread Ali via cctalk



>MS-DOS 5.00first version sold RETAILFred,I have to respectfully disagree 
>here. 3.20 was sold in retail. It was packaged in the dark blue packaging 
>which was the norm for MS at that time (after the green packaging of earlier 
>products).  I have a copy sitting up on my shelf (in fact I have both 3.20 and 
>3.21). 4.00 seems to be in the grey oem package but not necessarily branded 
>(i.e. a generic rey box included with new system purchase) . I have not seen 
>anything MS retail before 3.20.-Ali

Re: Identifying mystery TI ICs (Motorola MDP-1000 investigation continues...)

2020-10-04 Thread Brent Hilpert via cctalk

On 2020-Oct-04, at 1:22 AM, Josh Dersch via cctalk wrote:

> More mysteries while poking at the MDP-1000.  Spent some time this evening
> working out the rest of the signals on the power harness (I suspect inputs
> for an LTC circuit and a "power good" signal, as well as something
> connected to a relay on the backplane, probably related to power control).
> 
> There are a lot of unidentifiable ICs on the main CPU logic board and on
> the backplane, mixed in with bog-standard 7400-series TTL.  Curious if
> anyone has any ideas, as my searches and perusal of datasheets/databooks on
> Bitsavers have turned up nothing.  These are all TI-manufactured ICs, 1969
> manufacturing dates, with "SN48xx" and "SN63xx" part numbers (a few omit
> the "SN" prefix.)  I'm wondering if these are just standard 7400 ICs with
> special codes; for example there are several SN4816's near the edge
> connector for the I/O bus, where a 7416 might (?) make sense, and from some
> basic probing and following traces I think the pinouts make sense.
> (Everything's conformal coated so it's a real bear to beep things out...)
> 
> Any ideas?

I have run across TI ICs from that era with odd/unknown series numbering, in 
particular the SN3900 and SN4500 DTL ICs.
Notably:
- by pinout they match up with standard DTL series ICs,
- I have only found these in equipment from one manufacturer: 
calculators built by Canon.

I received a solitary page of datasheet for some of them (by way of a Canon 
service center many years ago), but I have never seen them mentioned in TI 
databooks from the era, even in those sections where they list e.g. "other 
products from TI" and proceed to list little known series and part numbers.

So an obvious guess is these were house numbering systems of standard parts 
done for the purchaser/equipment manufacturer but with TI's format scheme 
rather than a format specified by the manufacturer. Another guess would be 
standard parts tested and selected for purchaser-specified parameters, although 
that seems a little excessive for these cases.

The 54/7400 series originated with TI in 65, I'm not aware of them producing 
any other TTL series, other than perhaps second-sourcing some other 
manufacturer's.
I guess that's another possibility - another manuf's TTL series, labeled 
differently.

Odd that this Motorola CPU is filled with ICs manufactured by TI.

It's conceivable, although it seems less probable, that they're DTL rather than 
TTL.

On the whole, best guess would seem to be 7400-series inside.

--

On another issue, did you trace the +/-15V lines to the core address/inhibit 
drivers?
Could some of the remaining wires from the PS be other core supplies - 15V was 
a little low compared to most core systems I've seen.

DOS Versions (Was: IBM PC-DOS 2.10 explorations


On Sun, 4 Oct 2020, Richard Cini wrote:
I would only emphasize that 3.5? support didn?t exist before DOS 3 (I 
forget if it was 3 or 3.1; it was when the PS/2 came out). So you have 
to watch the image sizes.


PS/2 came out with PC-DOS 3.30   But also an IBM push for OS/2


DOS versions according to media support (ignoring other IMPORTANT changes, 
such as file handles, hierarchical DIRectories, etc.)


DOS 1.00160k40 tracks single sided 8 sectors per track.

PC-DOS 1.10
MS-DOS 1.25 320K40 tracks per side double sided 8 sectors per track.

DOS 2.00360K9 sectors per track

MS-DOS 2.11	customized by SOME OEMs	720K	3.5"; not all are 
same format as PC-DOS!


DOS 3.001.2M

DOS 3.10CD-ROM  "network redirector"

DOS 3.20720K

DOS 3.301.4M

MS-DOS 3.31 HDD >32M   customized by OEMs
PC-DOS 4.00

MS-DOS 5.00 first version sold RETAIL

MS-DOS 6.00
PC-DOS 6.10 cartload of bundled third party add-ons

MS-DOS 6.20	patched for reliability, including changing SMARTDRV to 
stop trashing disks (blamed on compression)

MS-DOS 6.21 compression not provided (copyright lawsuit)
MS-DOS 6.22 non-infringing compression

Win98SE USB


Note that 2.11 and 3.31, due to OEM customization will OFTEN have a 
different FORMAT program (different drives), and different MODE.COM (some 
had different video modes available).  Sometimes some other bundled 
programs had differences.



Note that DOS version is a numeral, a period, then a two digit decimal 
number.   It is ALWAYS 2.10, NOT 2.1; 3.10, NOT 3.1, etc.

What we call 2.1 is ACTUALLY version TWO point TEN!
what we call 3.2 is ACTUALLY version THREE point TWENTY!
what we call 3.31 is ACTUALLY version THREE point THIRTY-ONE!
what we call 4.01 is actually version FOUR point ONE.

MOV AH, 30h
INT 21h

returns the major version in AL.
Print that.
Then print a period.
Minor version is in AH.
print that as a 2 digit decimal number.

2.10 has AX: 0A02
3.10 has AX: 0A03
3.20 has AX: 1403
3.30 has AX: 1E03
3.31 has AX: 1F03


Note: SETVER (since 5.00) lets a version of DOS lie about its age. 
There's an important reason.
When PC-DOS 1.10 came out, with double sided drives, people sometimes ran 
CHKDSK from DOS 1.00 (sometimes even having 1.00 CHKDSK on a 1.10 boot 
disk), which proceeded to "FIX" the disk into an unusable form.


To prevent that and similar disasters, in addition to modifying CHKDSK to 
not make changes without confirmation, henceforth, EVERY program 
distributed with DOS had a MOV AH,30h/INT21h/CMP AX...  so that programs 
could only run with "correct version of DOS.  When they stopped including 
EXE2BIN.EXE and even LINK.EXE with DOS, it became necessary to either step 
on the version checking code (with DEBUG.COM) or use SETVER.



I'll do a separate post about DRIVER.SYS and DRIVPARM.

--
Grumpy Ol' Fred ci...@xenosoft.com

Re: IBM PC-DOS 2.10 explorations

2020-10-04 Thread Bill Degnan via cctalk

https://vintagecomputer.net/browse_thread.cfm?id=60

If you can find a way to format a MS DOS compatible diskette in the format
you need, here is how to get DOS 1 or DOS 3.3 onto that disk and make it
bootable.

Bill

Re: IBM PC-DOS 2.10 explorations


Richard,

I'll look for the Compaq 3.31 3.5" image. Thanks!

Will

On 10/4/20 10:02 AM, Richard Cini wrote:
You can find bootable disk images on-line that self extract to a 
floppy. For DOS 3.31 I use a Compaq version that went with my 
DeskPro/386.


I would only emphasize that 3.5” support didn’t exist before DOS 3 (I 
forget if it was 3 or 3.1; it was when the PS/2 came out). So you have 
to watch the image sizes.


http://www.classiccmp.org/cini
Long Island S100 User’s Group

Get Outlook  for iOS


*From:* cctalk  on behalf of Will Senn 
via cctalk 

*Sent:* Sunday, October 4, 2020 10:52:49 AM
*To:* Fred Cisin ; General Discussion: On-Topic 
and Off-Topic Posts 

*Subject:* Re: IBM PC-DOS 2.10 explorations
On 10/3/20 4:07 PM, Fred Cisin via cctalk wrote:
> On Sat, 3 Oct 2020, Will Senn via cctalk wrote:
>> 2. Most of the Assembly examples use DOS interrupt 21 for output. Is
>> this typical of assembly programs of the time, or did folks use other
>> methods?
>
> For simple stuff, Int21H works and is portable to anything running
> MS-DOS.
>
> Int10H is less portable.  Not as commonly used.
>
> If you need SPEED, which all commercial software perceived a need for,
> then you need to determine WHERE video memory is (segment B000H for
> MDA, segment B800H for CGA, with TEXT modes of EGA/VGA also using
> those), and put bytes/words directly into video memory.  REP MOVSW was
> generally the quickest way to put up a screenful of stuff (avoid
> segment over-ride because REP MOVSW lost that if an interrupt occured
> in mid transfer)
>
Great detail. I'll be playing around in the video memory. Int 21H is
fine for printf style output, but I've never really played around with
pages of data and this sounds like fun.

>
> Keyboard input could be done with Int21H, Int16h, or accessing memory
> in the BIOS segment.
>
>> 3. I was able to find a lot of 5150/5160 and other manuals, but I
>> couldn't find an IBM Macro Assembler 2.0 manual (there are plenty of
>> IBM Macro Assembler/2 manuals, but those are for OS/2, not DOS). Does
>> anyone know where I can find one online?
>
> MASM manual??!?
> MASM 5.0 was the first version to have documentation that a sane
> person could say was adequate.
> The MASM 5.00 manualS were pretty usable for the earlier MASM.
Hmm. I'll give it a shot.

>
> I used Lafore as textbook for my assembly language class
>
>
>> 4. In y'all's view, what are the significant differences between IBM
>> PC-DOS 2.10 and it's brother MS-DOS 2.x?
>
> 2.00 to 2.10 was minor changes.  Perhaps the most significant was that
> the PCJr used the QumeTrak 142 (early half-height) drives, which were
> TOO SLOW for 2.00, so PC-DOS 2.10 slowed down the DOS track to track
> access time.
>
> 2.11 was MS-DOS ONLY, not PC-DOS.  It was one of the favorite ones for
> OEMs to patch for different video or different drives (such as 720K 
3.5")

> PC-DOS didn't get 3.5" drives until PC-DOS 3.20.
> PC-DOS 3.30 added 1.4M If you want CD-ROM, 3.10 added the "network
> redirector".
>
> MS-DOS (NOT PC-DOS) 3.31, another favorite for patching, was the first
> to support hard drives larger than 32M
>
> PC-DOS 4.00 was unpopular, partially becaause IBM didn't pre-warn
> Norton to revise their fUtilities.
>
> MS-DOS 5.00 was the first to be sold RETAIL (not gray-market from an
> OEM), and added such things as SETVER (so LINK and EXe2BIN didn't need
> patching for DOS versions).
>
> MS-DOS 6.00 added a whole cartful of bundled aftermarket add-ons,
> including compression, SMARTDRV disk cacheing, etc.
> PC-DOS 6.10 had a cartful of different aftermarket brands of the same
> add-ons.
>
> MS-DOS 6.20 was the first version of MS-DOS for which imporving
> reliability was primary goal!  (instead of adding smell-o-vision,
> dancing kangaroos and yodelling jellyfish)
> It backed off the settings for SMARTDRV so that disks didn't get
> trashed (incorrectly blamed on compression)
> 6.21 was same, without compression due to copyright lawsuit(s).
> 6.22 was same with non-infringing compression
>

Great detail, thanks.

>> 5. I'm thinking of moving on to 3.3 at some point, in your view, what
>> are the advantages?
> Consider 3.31, instead of 3.30, to get larger drive support.
>
I am using a Thinkpad T430 w/DOS 6.22. If I can figure out how to get
3.31 on there, I'll give it a shot. I bought a Floppy-USB connector for
my old 1.44 floppy drive and it works fine with DOS 6.22, but I'm not
sure where to locate 3.31 media that I could burn onto a 1.44 floppy and
boot. I have sealed IBM DOS 3.3 media, but I don't think my T430 is
really compatible :). So, I'm not keen on opening the seal...

> Bob Wallace (MICROS~1 10th? employee) wrote the IBM PASCAL.  He
> advised me to NOT use the run-time library.
>
Well, there's a thought. I have Turbo Pascal 3 and it works fine. I just
like the feeling of running the old stuff.


> --
> Grumpy Ol' Fred

Re: Anyone want to part with a DEC MXV11-B (M7195) and/or M8012 (BDV11)?

2020-10-04 Thread Noel Chiappa via cctalk

> From: Chris Zach

> Might have an older MXV11 as well, could the 18 bit one do this

Ooh, good catch; yes, the MXV11-A also has an LTC. I too have an 'extra' one.
The OP should probably check to see if his P/S generates the bus clock signal;
most of the options we've discussed for him would need it.

 Noel

Re: IBM PC-DOS 2.10 explorations

2020-10-04 Thread Richard Cini via cctalk

You can find bootable disk images on-line that self extract to a floppy. For 
DOS 3.31 I use a Compaq version that went with my DeskPro/386.

I would only emphasize that 3.5” support didn’t exist before DOS 3 (I forget if 
it was 3 or 3.1; it was when the PS/2 came out). So you have to watch the image 
sizes.

http://www.classiccmp.org/cini
Long Island S100 User’s Group

Get Outlook for iOS


From: cctalk  on behalf of Will Senn via cctalk 

Sent: Sunday, October 4, 2020 10:52:49 AM
To: Fred Cisin ; General Discussion: On-Topic and Off-Topic 
Posts 
Subject: Re: IBM PC-DOS 2.10 explorations

On 10/3/20 4:07 PM, Fred Cisin via cctalk wrote:
> On Sat, 3 Oct 2020, Will Senn via cctalk wrote:
>> 2. Most of the Assembly examples use DOS interrupt 21 for output. Is
>> this typical of assembly programs of the time, or did folks use other
>> methods?
>
> For simple stuff, Int21H works and is portable to anything running
> MS-DOS.
>
> Int10H is less portable.  Not as commonly used.
>
> If you need SPEED, which all commercial software perceived a need for,
> then you need to determine WHERE video memory is (segment B000H for
> MDA, segment B800H for CGA, with TEXT modes of EGA/VGA also using
> those), and put bytes/words directly into video memory.  REP MOVSW was
> generally the quickest way to put up a screenful of stuff (avoid
> segment over-ride because REP MOVSW lost that if an interrupt occured
> in mid transfer)
>
Great detail. I'll be playing around in the video memory. Int 21H is
fine for printf style output, but I've never really played around with
pages of data and this sounds like fun.

>
> Keyboard input could be done with Int21H, Int16h, or accessing memory
> in the BIOS segment.
>
>> 3. I was able to find a lot of 5150/5160 and other manuals, but I
>> couldn't find an IBM Macro Assembler 2.0 manual (there are plenty of
>> IBM Macro Assembler/2 manuals, but those are for OS/2, not DOS). Does
>> anyone know where I can find one online?
>
> MASM manual??!?
> MASM 5.0 was the first version to have documentation that a sane
> person could say was adequate.
> The MASM 5.00 manualS were pretty usable for the earlier MASM.
Hmm. I'll give it a shot.

>
> I used Lafore as textbook for my assembly language class
>
>
>> 4. In y'all's view, what are the significant differences between IBM
>> PC-DOS 2.10 and it's brother MS-DOS 2.x?
>
> 2.00 to 2.10 was minor changes.  Perhaps the most significant was that
> the PCJr used the QumeTrak 142 (early half-height) drives, which were
> TOO SLOW for 2.00, so PC-DOS 2.10 slowed down the DOS track to track
> access time.
>
> 2.11 was MS-DOS ONLY, not PC-DOS.  It was one of the favorite ones for
> OEMs to patch for different video or different drives (such as 720K 3.5")
> PC-DOS didn't get 3.5" drives until PC-DOS 3.20.
> PC-DOS 3.30 added 1.4M If you want CD-ROM, 3.10 added the "network
> redirector".
>
> MS-DOS (NOT PC-DOS) 3.31, another favorite for patching, was the first
> to support hard drives larger than 32M
>
> PC-DOS 4.00 was unpopular, partially becaause IBM didn't pre-warn
> Norton to revise their fUtilities.
>
> MS-DOS 5.00 was the first to be sold RETAIL (not gray-market from an
> OEM), and added such things as SETVER (so LINK and EXe2BIN didn't need
> patching for DOS versions).
>
> MS-DOS 6.00 added a whole cartful of bundled aftermarket add-ons,
> including compression, SMARTDRV disk cacheing, etc.
> PC-DOS 6.10 had a cartful of different aftermarket brands of the same
> add-ons.
>
> MS-DOS 6.20 was the first version of MS-DOS for which imporving
> reliability was primary goal!  (instead of adding smell-o-vision,
> dancing kangaroos and yodelling jellyfish)
> It backed off the settings for SMARTDRV so that disks didn't get
> trashed (incorrectly blamed on compression)
> 6.21 was same, without compression due to copyright lawsuit(s).
> 6.22 was same with non-infringing compression
>

Great detail, thanks.

>> 5. I'm thinking of moving on to 3.3 at some point, in your view, what
>> are the advantages?
> Consider 3.31, instead of 3.30, to get larger drive support.
>
I am using a Thinkpad T430 w/DOS 6.22. If I can figure out how to get
3.31 on there, I'll give it a shot. I bought a Floppy-USB connector for
my old 1.44 floppy drive and it works fine with DOS 6.22, but I'm not
sure where to locate 3.31 media that I could burn onto a 1.44 floppy and
boot. I have sealed IBM DOS 3.3 media, but I don't think my T430 is
really compatible :). So, I'm not keen on opening the seal...

> Bob Wallace (MICROS~1 10th? employee) wrote the IBM PASCAL.  He
> advised me to NOT use the run-time library.
>
Well, there's a thought. I have Turbo Pascal 3 and it works fine. I just
like the feeling of running the old stuff.


> --
> Grumpy Ol' Fred ci...@xenosoft.com

Thanks Fred!


--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

Re: IBM PC-DOS 2.10 explorations


On 10/3/20 4:07 PM, Fred Cisin via cctalk wrote:

On Sat, 3 Oct 2020, Will Senn via cctalk wrote:
2. Most of the Assembly examples use DOS interrupt 21 for output. Is 
this typical of assembly programs of the time, or did folks use other 
methods?


For simple stuff, Int21H works and is portable to anything running 
MS-DOS.


Int10H is less portable.  Not as commonly used.

If you need SPEED, which all commercial software perceived a need for, 
then you need to determine WHERE video memory is (segment B000H for 
MDA, segment B800H for CGA, with TEXT modes of EGA/VGA also using 
those), and put bytes/words directly into video memory.  REP MOVSW was 
generally the quickest way to put up a screenful of stuff (avoid 
segment over-ride because REP MOVSW lost that if an interrupt occured 
in mid transfer)


Great detail. I'll be playing around in the video memory. Int 21H is 
fine for printf style output, but I've never really played around with 
pages of data and this sounds like fun.




Keyboard input could be done with Int21H, Int16h, or accessing memory 
in the BIOS segment.


3. I was able to find a lot of 5150/5160 and other manuals, but I 
couldn't find an IBM Macro Assembler 2.0 manual (there are plenty of 
IBM Macro Assembler/2 manuals, but those are for OS/2, not DOS). Does 
anyone know where I can find one online?


MASM manual??!?
MASM 5.0 was the first version to have documentation that a sane 
person could say was adequate.

The MASM 5.00 manualS were pretty usable for the earlier MASM.

Hmm. I'll give it a shot.



I used Lafore as textbook for my assembly language class


4. In y'all's view, what are the significant differences between IBM 
PC-DOS 2.10 and it's brother MS-DOS 2.x?


2.00 to 2.10 was minor changes.  Perhaps the most significant was that 
the PCJr used the QumeTrak 142 (early half-height) drives, which were 
TOO SLOW for 2.00, so PC-DOS 2.10 slowed down the DOS track to track 
access time.


2.11 was MS-DOS ONLY, not PC-DOS.  It was one of the favorite ones for 
OEMs to patch for different video or different drives (such as 720K 3.5")

PC-DOS didn't get 3.5" drives until PC-DOS 3.20.
PC-DOS 3.30 added 1.4M If you want CD-ROM, 3.10 added the "network 
redirector".


MS-DOS (NOT PC-DOS) 3.31, another favorite for patching, was the first 
to support hard drives larger than 32M


PC-DOS 4.00 was unpopular, partially becaause IBM didn't pre-warn 
Norton to revise their fUtilities.


MS-DOS 5.00 was the first to be sold RETAIL (not gray-market from an 
OEM), and added such things as SETVER (so LINK and EXe2BIN didn't need 
patching for DOS versions).


MS-DOS 6.00 added a whole cartful of bundled aftermarket add-ons, 
including compression, SMARTDRV disk cacheing, etc.
PC-DOS 6.10 had a cartful of different aftermarket brands of the same 
add-ons.


MS-DOS 6.20 was the first version of MS-DOS for which imporving 
reliability was primary goal!  (instead of adding smell-o-vision, 
dancing kangaroos and yodelling jellyfish)
It backed off the settings for SMARTDRV so that disks didn't get 
trashed (incorrectly blamed on compression)

6.21 was same, without compression due to copyright lawsuit(s).
6.22 was same with non-infringing compression



Great detail, thanks.

5. I'm thinking of moving on to 3.3 at some point, in your view, what 
are the advantages?

Consider 3.31, instead of 3.30, to get larger drive support.

I am using a Thinkpad T430 w/DOS 6.22. If I can figure out how to get 
3.31 on there, I'll give it a shot. I bought a Floppy-USB connector for 
my old 1.44 floppy drive and it works fine with DOS 6.22, but I'm not 
sure where to locate 3.31 media that I could burn onto a 1.44 floppy and 
boot. I have sealed IBM DOS 3.3 media, but I don't think my T430 is 
really compatible :). So, I'm not keen on opening the seal...


Bob Wallace (MICROS~1 10th? employee) wrote the IBM PASCAL.  He 
advised me to NOT use the run-time library.


Well, there's a thought. I have Turbo Pascal 3 and it works fine. I just 
like the feeling of running the old stuff.




--
Grumpy Ol' Fred ci...@xenosoft.com


Thanks Fred!


--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

Re: IBM PC-DOS 2.10 explorations


I didn't think of looking at source. I'll dig around thanks for the tip.

Will

On 10/3/20 12:14 PM, Richard Cini via cctalk wrote:

Regarding #4, if you look at the releases source code for DOS 2.0 you will see 
compilation switches for PCD and MSD. I would need to look again but some were 
control code things, plus sign-on messages. I know IBM shipped different tools 
than MS too.


http://www.classiccmp.org/cini
Long Island S100 User’s Group

Get Outlook for iOS


From: cctalk  on behalf of Chuck Guzis via cctalk 

Sent: Saturday, October 3, 2020 12:44:26 PM
To: Will Senn via cctalk 
Subject: Re: IBM PC-DOS 2.10 explorations

On 10/3/20 8:38 AM, Will Senn via cctalk wrote:


Some questions I have related to the exploration:

1. I'm curious if there are other folks out there doing similar stuff?
2. Most of the Assembly examples use DOS interrupt 21 for output. Is
this typical of assembly programs of the time, or did folks use other
methods?
3. I was able to find a lot of 5150/5160 and other manuals, but I
couldn't find an IBM Macro Assembler 2.0 manual (there are plenty of IBM
Macro Assembler/2 manuals, but those are for OS/2, not DOS). Does anyone
know where I can find one online?
4. In y'all's view, what are the significant differences between IBM
PC-DOS 2.10 and it's brother MS-DOS 2.x?
5. I'm thinking of moving on to 3.3 at some point, in your view, what
are the advantages?
6. I'm happy to post here, but if y'all know of a more appropriate
venue, please suggest it?

1 and 6:The folks at vcfed.org are far more involved into things PC; I
would recommend that venue.

2.  Interrupt 21 is the most hardware-independent way to perform console
output.  It is neither the fastest nor most flexible.   Most MSDOS
programs needing fast or full-screen control revert to writing into
display memory directly, which is a bit more involved, but worth the
effort.  There are also INT 10h calls, but again, for text output, they
can be very slow.

3.  Can't address that one--I have 1.0 and 4.0 and later in my library;
I'm not sure if I have the "gap" ones.  MASM 1.0 was a huge mess; the
product really didn't start to mature until 4.0.

4.  MS-DOS 2.x had numerous variations, such as that employed for the
NEC PC98 series of machines, as well as numerous other non-IBM PC
platforms.  As far as I know, PC-DOS was configured only to be
compatible with IBM's own product line.

5. 3.3 was very popular in the day; one thing that it provided was a way
to avoid some of the storage limitations of earlier versions.  It also
introduced quite a number of API additions (see Ralf Brown's interrupt
list for details).

--Chuck









--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462  7D45 3EAA 5B6D A982 BAAF

Re: IBM PC-DOS 2.10 explorations