PDA

View Full Version : PC-DOS "0.90" pre-release unearthed



SomeGuy
May 29th, 2017, 11:09 AM
The OS/2 museum has unearthed a May 1981 pre-release of IBM PC-DOS:

http://www.os2museum.com/wp/pc-dos-1-0-but-not-quite/

And PCjs has posted a webby emulator with an image here:
http://www.pcjs.org/disks/pcx86/dos/ibm/0.90/

PCjs is calling this "0.90" although there is nothing indicating that version in on the disk. It still calls itself IBM Personal Computer DOS 1.00, but is much earlier.

Notably, it does not prompt for a date at boot, it does not support EXE files, contains several development related tools, and includes a version of IBM Basic that does not require basic in ROM.

There is also a text file on the disk that gives even more details about development changes.

It will run on a release IBM PC.

Xacalite
May 29th, 2017, 01:41 PM
Nice find, indeed.
BTW: what was the original hardware DOS was made for?
It's easily found that it was some 8086 microcomputer with S-100 bus made by Seattle Computer Products, but I'd like to see more details...

krebizfan
May 29th, 2017, 03:53 PM
http://www.s100computers.com/Hardware%20Folder/Seattle%20Computer%20Products/8086%20CPU%20Board/8086%20Board.htm shows the main board and provides links to download PDF manuals for it.

romanon
May 29th, 2017, 10:59 PM
Very nice and funny, i tried it on my IBM XT and works fine. Funny is that default date is 00-00-81 instead 01-01-81. Also DIR command not reveal free space on floppy drive. Also not all files contains date next to file name in DIR command.
38867 38868

KC9UDX
May 30th, 2017, 02:52 AM
It appears to have an advantage over later versions. I don't see EDLIN there.

SomeGuy
May 30th, 2017, 05:28 AM
Having a null value representing "no date" is actually completely valid in DOS/FAT. That support continued on until at least Windows 9x, although many utilities fail to recognize that.

The idea is that it is not appropriate to assign a date to a file if a user did not specify a date. Other OSes of the time often did similar. You can see that is actually the behavior of this pre-release by creating a new file without specifying a date (yes, edlin is there).

The final release 1.00 forced users to specify a date. Later versions defaulted to 1-1-80. Unless the user is a time traveler, a default of 1-1-80 is always incorrect and "no date" would have been more logical.

hargle
May 30th, 2017, 06:07 AM
I'm impressed that .exe support was added so late to the design. It seems like that would have been a large undertaking to support with such a small window of time. It clearly shows that development+design cycles have not changed in the entire history of the PC industry! We're still cramming in features at the last minute.

romanon
May 30th, 2017, 06:36 AM
What about included basic programs? There is strange game "spcwar" and some calculating program "kilo". I thing that the game is little bit broken...

krebizfan
May 30th, 2017, 06:53 AM
KILO.BAS contains the Kilobaud magazine benchmarks which are available for many of the competing early small computers.
List the game and find the couple of movement keys in the INKEY$ routine ("K" and "M" and somehow ? "ff"). Still broken as befits early prototype code that got dropped from the final system.

fs5500
May 30th, 2017, 07:40 AM
I've tested it on IBM PC 5150 (Rev.1 BIOS) with 32KB RAM and 64KB RAM.

It boots well, but BASIC interpreter (BAS18/BAS18A is Not enough to run on 64KB RAM.
(BAS18/BAS18A works on 128KB RAM or higher.)
(Only BASICA works on 64KB RAM)
So I guess AUTOEXEC.BAT is renamed as AUTOEXEC.BAK.

AUTOEXEC.BAK content is :
date
movbas
bas18a

Also CHKDSK access disk without write protect knob.

RBAS.COM seems to be IBM PC ROM BASIC C1.00.
It doesn't work on IBM PC/PS2 with ROM BASIC.
(It should work on PC without ROM BASIC.)

This is minimum RAM to run IBM PC BASIC (Disk) / BASIC (Advanced) (0.90 beta / 1.00 / 1.10)

*IBM PC DOS 0.90 (Beta)

BASIC (Disk) : 128KB (BAS18.COM)
BASIC (Advanced) : 128KB (BAS18A.COM)
BASIC (Advanced) : 64KB (BASICA.COM)


*IBM PC DOS 1.00

BASIC (Disk) : 32KB (BASIC.COM)
BASIC (Advanced) : 32KB (BASICA.COM)


*IBM PC DOS 1.10

BASIC (Disk) : 32KB (BASIC.COM)
BASIC (Advanced) : 48KB (BASICA.COM)




http://i.imgur.com/RWgK0Jf.png

http://i.imgur.com/bgfWXP7.png

http://i.imgur.com/PA4oekM.png

http://i.imgur.com/88LBxOn.png

http://i.imgur.com/h7YM9bu.png

http://i.imgur.com/rWQMtLK.png

http://i.imgur.com/kWMnwqk.png

http://i.imgur.com/bS9RvZN.png

http://i.imgur.com/30CFE7Y.png

roberttx
May 30th, 2017, 08:31 AM
It appears to have an advantage over later versions. I don't see EDLIN there.

I had successfully blotted EDLIN from my memory, up until now. Thanks...

Chuck(G)
May 30th, 2017, 09:24 AM
I never did understand the logic behind EDLIN. Less capable than the much older CP/M PIP--a WYSIWYG simple text editor would not have been much larger.

krebizfan
May 30th, 2017, 09:46 AM
Wasn't DRI's competitor to EDLIN the similarly less than intuitive ED? ED had more features but one needed very good spatial memory to fully utilize them.

I think EDLIN was just thrown together quickly to verify that character and file handling worked with the intent of being replaced by a decent editor as soon as time permitted. IBM instead offered the Personal Editor for $50. Personal Editor was a bit too large to be the default editor for a minimally equipped IBM PC since it could handle of a maximum of 8 kB of text on a 64kB machine with 2 disk drives.

vwestlife
May 30th, 2017, 09:50 AM
The only good thing about EDLIN was that in batch files you could feed it commands to manipulate text files. The end result was a pseudo-scripting ability in DOS, without any additional software required.

Chuck(G)
May 30th, 2017, 09:55 AM
Wasn't DRI's competitor to EDLIN the similarly less than intuitive ED? ED had more features but one needed very good spatial memory to fully utilize them.

I think EDLIN was just thrown together quickly to verify that character and file handling worked with the intent of being replaced by a decent editor as soon as time permitted. IBM instead offered the Personal Editor for $50. Personal Editor was a bit too large to be the default editor for a minimally equipped IBM PC since it could handle of a maximum of 8 kB of text on a 64kB machine with 2 disk drives.

Let's not forget that PCDOS 1.0 sold for $40. Paying $50 for a real editor seems to me to be a bit silly.

I wound up adapting one that I wrote for the 8085. Still occasionally use it (greatly enhanced) when I'm coding 16-bit x86 code. VEDIT came out pretty early and even had a version that ran on the Displaywriter. Orders of magnitude better than EDLIN.

lowen
May 30th, 2017, 10:30 AM
Heh, it's not a real OS until you can fight over whether to use vi or emacs. ;-)

This is a great find, even without vi and emacs!

SomeGuy
May 30th, 2017, 10:46 AM
A line editor like Edlin could be useful on systems driven by terminals/teletypes. Given that DOS and Edlin originated on SCP's S-100 system the design does make sense. An IBM PC-specific full screen editor would have been nice with early DOS, but obviously IBM didn't feel it was worth the effort.

Edlin is still present in Windows 10 - 32bit. :D

Chuck(G)
May 30th, 2017, 10:50 AM
I can recall doing some things with PIP that I could have only done with sed under Unix (or perhaps a sed-like editor). CP/M had XSUB which enabled one to use a file as console input to a program. (Yes, it was a bit clunky). I was surprised to see that the functionality that had been in CP/M for years was missing from PCODS. And IBM wanted $99 for the (buggy) assembler.

vwestlife
May 30th, 2017, 11:03 AM
Heh, it's not a real OS until you can fight over whether to use vi or emacs. ;-)

...or fight over how to pronounce "vi"! (Is it "V.I." or as in "viable"?)

Trixter
May 30th, 2017, 11:29 AM
or worse -- VIsual editor means it probably should be pronounced "vih". (I pronounce it vee-eye)

Xacalite
May 30th, 2017, 11:38 AM
A line editor like Edlin could be useful on systems driven by terminals/teletypes.
Yes, it's interesting to realize that DOS had pretty good provisioning for terminals, even for the dumbest ones.
Anybody actually used that back in the era?

Chuck(G)
May 30th, 2017, 11:38 AM
This thread does remind me of the decision faced by a small business purchaser of a new computer back in the day.

In 1983-4, it really wasn't clear why anyone would want to purchase a 5150 over the 8-bit (Z80, 8085, NSC800) competition. PCDOS 1.1 and CP/M 2.2 had similar features and limitations (single "flat" directory structure, very similar system APIs, etc.). At the time, there were also CP/M system offerings with a hard disk--something that IBM didn't offer. 160KB floppies certainly weren't anything to write home about--there were several systems using 5.25" floppies at the time that held 800K.

And the selection of business-oriented applications wasn't all that good. No wonder a friend purchased a Morrow MD2 instead of a PC for his business.

I suspect that it was Lotus 1-2-3 that secured the PC in the marketplace. You couldn't get 1-2-3 for 8-bit CP/M. The financial folks were buying Apple IIs solely to run VisiCalc. It's true that Sorcim had SuperCalc, Microsoft had Multiplan, "Dash" Chang offered Microplan, and there were numerous other "small" spreadsheet programs, but VisiCalc ruled the professional market. Mitch Kapor was very smart in making 1-2-3 follow the VisCalc conventions, which the financial community understood. Money for a box to run 1-2-3 or VisiCalc was pocket change to these types.

The drive toward ever larger and more complex spreadsheets was also a huge factor in bigger RAM space (EMS: LIM--the "L" is Lotus) and faster CPUs. It's no accident that IBM demoed both the 5170 and the PS/2 with 1-2-3 as a main attraction.

I think that without 1-2-3, and particularly after the Mac debuted, the IBM PC platform would have been just another personal computer system.

mbbrutman
May 30th, 2017, 05:40 PM
Do we have a timeline problem here? By 1983 you have DOS 2.0 and the PC XT 5160 with a 10MB hard drive. And by 1984 you have the PC AT.

I don't think the original 160KB single sided drives lasted very long either; those were probably gone in 1982 in favor of the 320/360KB double sided drives. That was a very early change made to the series.

I agree though, in 1982 the comparison to 8 bit CP/M machines would not have been flattering to the 5150. Except for the promise of 16 bits and the huge address space in comparison. And of course, the IBM name.

yuhong
May 31st, 2017, 02:47 PM
Do we have a timeline problem here? By 1983 you have DOS 2.0 and the PC XT 5160 with a 10MB hard drive. And by 1984 you have the PC AT.

I don't think the original 160KB single sided drives lasted very long either; those were probably gone in 1982 in favor of the 320/360KB double sided drives. That was a very early change made to the series.

I agree though, in 1982 the comparison to 8 bit CP/M machines would not have been flattering to the 5150. Except for the promise of 16 bits and the huge address space in comparison. And of course, the IBM name.

I should also mention "But there’s also BAS18.COM and BAS18A.COM which expect the BASIC “ROM” at segment 1800h (at 96K, clearly assuming a 128K machine) in RAM rather than at segment F600h in ROM.".

yuhong
May 31st, 2017, 02:49 PM
This thread does remind me of the decision faced by a small business purchaser of a new computer back in the day.

In 1983-4, it really wasn't clear why anyone would want to purchase a 5150 over the 8-bit (Z80, 8085, NSC800) competition. PCDOS 1.1 and CP/M 2.2 had similar features and limitations (single "flat" directory structure, very similar system APIs, etc.). At the time, there were also CP/M system offerings with a hard disk--something that IBM didn't offer. 160KB floppies certainly weren't anything to write home about--there were several systems using 5.25" floppies at the time that held 800K.

And the selection of business-oriented applications wasn't all that good. No wonder a friend purchased a Morrow MD2 instead of a PC for his business.

I suspect that it was Lotus 1-2-3 that secured the PC in the marketplace. You couldn't get 1-2-3 for 8-bit CP/M. The financial folks were buying Apple IIs solely to run VisiCalc. It's true that Sorcim had SuperCalc, Microsoft had Multiplan, "Dash" Chang offered Microplan, and there were numerous other "small" spreadsheet programs, but VisiCalc ruled the professional market. Mitch Kapor was very smart in making 1-2-3 follow the VisCalc conventions, which the financial community understood. Money for a box to run 1-2-3 or VisiCalc was pocket change to these types.

The drive toward ever larger and more complex spreadsheets was also a huge factor in bigger RAM space (EMS: LIM--the "L" is Lotus) and faster CPUs. It's no accident that IBM demoed both the 5170 and the PS/2 with 1-2-3 as a main attraction.

I think that without 1-2-3, and particularly after the Mac debuted, the IBM PC platform would have been just another personal computer system.

And if they didn't release the IBM PC/XT with DOS 2.0 and directories, the 32MB limit might have eventually killed off DOS in favor of CP/M-86.

krebizfan
May 31st, 2017, 03:09 PM
And if they didn't release the IBM PC/XT with DOS 2.0 and directories, the 32MB limit might have eventually killed off DOS in favor of CP/M-86.

Yes, because everyone was racing to partition their systems into 8 MB user areas. CP/M-86 had a number of advantages over DOS; the file system was not one of them.

yuhong
May 31st, 2017, 03:18 PM
Yes, because everyone was racing to partition their systems into 8 MB user areas. CP/M-86 had a number of advantages over DOS; the file system was not one of them.

They were already trying to fix it with CP/M 3:
https://groups.google.com/d/msg/comp.os.cpm/rFagrp7WT9E/ixC8GLtiJcwJ

krebizfan
May 31st, 2017, 04:05 PM
They were already trying to fix it with CP/M 3:
https://groups.google.com/d/msg/comp.os.cpm/rFagrp7WT9E/ixC8GLtiJcwJ

CP/M-86 1.1 actually only permitted a single 8MB partition through HDMAINT. DOSPlus (CP/M 4) upped that to a single 32MB partition. CVV which allowed CP/M-86 to install multiple partitions appeared much later; the versions I have seen date from 2001. Some structures may have been enlarged but many bottlenecks remained so much so that DRI got rid of the CP/M file system.

http://www.seasip.info/Cpm/format41.html

Chuck(G)
May 31st, 2017, 04:07 PM
That only applied to file size. CP/M was still a "flat" directory structure with "extents" (akin to S/360 DOS allocation). When you ran out of directory space (and that was hard to predict, particularly if you used file date/time extensions), that was it. There was no way to add directory space. Further, the only way to "partition" this massive directory into human-manageable portions was to use user area numbers. Unfortunately, most third-party programs didn't know how to take advantage of the facility.

What made DOS 2 important was the use of subdirectories, like Unix and the linked-list allocation map. So the number of directory entries was equal to the number of files. If you ran out of root directory space, you could put things in subdirectories, which essentially are not limited with regard to the number of entries they can contain.

chulofiasco
May 31st, 2017, 04:32 PM
The only good thing about EDLIN was that in batch files you could feed it commands to manipulate text files. The end result was a pseudo-scripting ability in DOS, without any additional software required.

this is very clever...

Xacalite
May 31st, 2017, 04:41 PM
I should also mention "But there’s also BAS18.COM and BAS18A.COM which expect the BASIC “ROM” at segment 1800h (at 96K, clearly assuming a 128K machine) in RAM rather than at segment F600h in ROM.".
Interesting conclusion, indeed.
The first version of 5150 board supported 16-64 KB RAM.
So, for running BASIC in RAM, they needed some expansion card.
Was such a card available from IBM right after the release of 5150?

SomeGuy
May 31st, 2017, 04:48 PM
this is very clever...
I've never used edlin like that, so please correct me if I am wrong, but wasn't scripting it only possible after DOS 2 introduced console piping/redirection? Seemed like more of a side-effect than clever design.

Chuck(G)
May 31st, 2017, 04:51 PM
Yes. IBM offered both 32KB and 64KB option cards.

krebizfan
May 31st, 2017, 05:02 PM
Interesting conclusion, indeed.
The first version of 5150 board supported 16-64 KB RAM.
So, for running BASIC in RAM, they needed some expansion card.
Was such a card available from IBM right after the release of 5150?

For BAS18, the card would have to be ready before the 5150. Some of the first cards designed were 32kB and 64kB memory expansion cards.

vwestlife
May 31st, 2017, 05:11 PM
I've never used edlin like that, so please correct me if I am wrong, but wasn't scripting it only possible after DOS 2 introduced console piping/redirection? Seemed like more of a side-effect than clever design.

Yes. It involved a lot of redirected ECHO commands, such as:

https://groups.google.com/d/msg/alt.msdos.batch/g-BXt7IJ-kg/fVLrHKRm-P4J

yuhong
May 31st, 2017, 05:13 PM
For BAS18, the card would have to be ready before the 5150. Some of the first cards designed were 32kB and 64kB memory expansion cards.

I wonder why they didn't add 64K DRAM support to the 5150 board too.

krebizfan
May 31st, 2017, 05:27 PM
I wonder why they didn't add 64K DRAM support to the 5150 board too.

No, no, I mean the card supported at most 64kB of memory; it was very similar to the Datamaster card except the memory chips were not stacked. The problem with 64kbit RAM chips was a limited supply. Fujitsu didn't start their manufacture of 64kbit chips until Mid 1982. The same problem that applied to the dual sided disk drive: the only way IBM could have gotten enough to fill the production line of the IBM PC would have resulted in a bidding war and an extreme increase in price.

Edit: Found a list of production volume in 1981. The term units is used; I presume that means chips.
1kBit 1 million
4kbit 15 million
16kbit 230 million
64kbit 11 million

SomeGuy
May 31st, 2017, 05:30 PM
What seems odd is that the original 5150 had 16k soldered on to the motherboard, but even the BIOS itself required 32K in order to boot a disk. In theory one could probably stuff DOS 1.x in to 16k but there would not be any room left to actually run anything. I guess they could claim a minimal 16k system was usable with ROM basic and cassette, to keep minimal configuration prices low.

bobba84
May 31st, 2017, 05:35 PM
Has anyone ever seen a 5150 with 16k and no drives?

KC9UDX
May 31st, 2017, 07:07 PM
I had one with no drives. RAM was not that low though. 256 or 384 or 512 or something like that.

But I don't know that it came from the factory that way. I suspect the guy I bought it from was swapping drives and blanking plates between machines and selling them with dual or none.

EDIT: On second thought it may have had only 64k. I recall adding a card to bring the RAM up.

Chuck(G)
May 31st, 2017, 07:23 PM
Has anyone ever seen a 5150 with 16k and no drives?

You could certainly run cassette BASIC programs with that.

Chuck(G)
May 31st, 2017, 07:59 PM
No, no, I mean the card supported at most 64kB of memory; it was very similar to the Datamaster card except the memory chips were not stacked. The problem with 64kbit RAM chips was a limited supply. Fujitsu didn't start their manufacture of 64kbit chips until Mid 1982. The same problem that applied to the dual sided disk drive: the only way IBM could have gotten enough to fill the production line of the IBM PC would have resulted in a bidding war and an extreme increase in price.

I think everyone forgets how hard DRAMs were to come by around 1982-83. The US was in a trade war (http://www.nytimes.com/1983/06/03/business/the-selling-of-the-256k-ram.html?pagewanted=all) with Japan, with the US accusing Japan of dumping. In Silicon Valley, it was easy to buy microprocessors, but if you were in purchasing trying to get DRAM for your assembly line, your little Rolodex was pretty dog-eared. Some vendors, such as Intel, would give you priority if you ordered DRAM with other products. But I know of at least one case of a truck carrying DRAM being hijacked and several break-ins to get at the stock that various companies were holding.

You have to realize that for higher-density DRAM, yields were pretty terrible. So bad, in fact, that I still have a few Intel 2109 DRAMs which are really 2117s with half of the array bad--Intel suffixed the part number with a digit that indicated which half was to be used. (National had the same deal with 256Kb EEPROMs).

So, it should come as no surprise that IBM marketed the 5150 with only 16KB installed.

For what it's worth, my own experience with Japanese DRAM demonstrated that, at the time of the 16K chips, they were far ahead of the US. I remember testing a NEC uPD416 and being stunned that the contents held without refresh for several seconds. I probably still have the DRAM in my hellbox.

By 1985, the situation had pretty much resolved itself and DRAM supplies were sufficient.

By the way, does anyone have any Western Electric-branded DRAM? They were supposed to be pretty good back in the day. Good old Ma Bell.

bobba84
May 31st, 2017, 08:27 PM
a truck carrying DRAM

Probably about 1GB worth HAHAHAHA!

KC9UDX
May 31st, 2017, 08:39 PM
This reminds me of what I always tell people when they say the C64 was inferiour because it only had 64k. It was pretty shocking when it came out that a machine like that could have a whole 64k!

yuhong
May 31st, 2017, 08:45 PM
I think everyone forgets how hard DRAMs were to come by around 1982-83. The US was in a trade war (http://www.nytimes.com/1983/06/03/business/the-selling-of-the-256k-ram.html?pagewanted=all) with Japan, with the US accusing Japan of dumping. In Silicon Valley, it was easy to buy microprocessors, but if you were in purchasing trying to get DRAM for your assembly line, your little Rolodex was pretty dog-eared. Some vendors, such as Intel, would give you priority if you ordered DRAM with other products. But I know of at least one case of a truck carrying DRAM being hijacked and several break-ins to get at the stock that various companies were holding.

You have to realize that for higher-density DRAM, yields were pretty terrible. So bad, in fact, that I still have a few Intel 2109 DRAMs which are really 2117s with half of the array bad--Intel suffixed the part number with a digit that indicated which half was to be used. (National had the same deal with 256Kb EEPROMs).

So, it should come as no surprise that IBM marketed the 5150 with only 16KB installed.

For what it's worth, my own experience with Japanese DRAM demonstrated that, at the time of the 16K chips, they were far ahead of the US. I remember testing a NEC uPD416 and being stunned that the contents held without refresh for several seconds. I probably still have the DRAM in my hellbox.

By 1985, the situation had pretty much resolved itself and DRAM supplies were sufficient.

By the way, does anyone have any Western Electric-branded DRAM? They were supposed to be pretty good back in the day. Good old Ma Bell.

Actually, I think the DRAM market declined in 1985. I think it was around 1979 that there was a DRAM shortage, and in 1980 the shortage was beginning to end. Edit: here is a source: http://archive.computerhistory.org/resources/access/text/2013/04/102723421-05-01-acc.pdf

yuhong
May 31st, 2017, 08:48 PM
Fujitsu didn't start their manufacture of 64kbit chips until Mid 1982.

I believe it was around 1980 not in 1982. Fujitsu technically had 64K DRAM chip samples in 1978, but they were not standard +5V chips (I think it was +7.5V and -2.5V).

krebizfan
May 31st, 2017, 09:13 PM
I am using a 1996 report from Integrated Circuit Engineering Corporation for these figures. It is available in PDF format from the Smithsonian Chip Collection.

1979 had 60% growth in volume as 16kbit chips caught up with 4kbit chips. May have been a shortage but only because demand grew even faster.
1985 had a 21% decline as 4k and 16k chips started to be phased out but 64k couldn't catch up.
1987 had 4% decline following 18% increase in 1988
Then there was a long plateau from 1989 to 1993. 1989: 13% growth; 1990: 1% growth; 1991: 7% decline; 1992: 16% increase; 1993: 1% increase

1976, 1977, 1979, 1980, 1983, 1984: all these years had volumes increase by more than 50%.

Chuck(G)
May 31st, 2017, 10:20 PM
At any rate, I recall a very rough time around 1980 for getting DRAM.

"Dumping" has been a continuing cry in the US for a long time. In the mid-late 1990s, Japanese (e.g. NEC, Fujitsu, Matsushita) and Korean (Hyundai) managed to smooth over things by building DRAM plants in the US. For example, Hyundai/Hynix built a plant here in 1997 to make 16Mb and 64Mb DRAMs amidst threatened trade sanctions. They received a bundle in subsidies, but by the end of 2001, most of the workforce had been furloughed. The 3M square foot building was put on the market in 2008 and only recently has been acquired by Avago. I think Hynix/Hyundai is now making their DRAM in Wuxi.

Often, we make the mistake that market forces are dictated by technical issues only. That's only a small part of the picture most of the time. Heaven knows what the picture will look like in the long run with the current administration.

Unknown_K
May 31st, 2017, 10:49 PM
Lots of semi fabs went bust by 2001. A billion dollar new fab in Orlando FL (Cirent SEMI) went from boom to bust in a few short years around that time. The late 90's was an interesting time.

yuhong
May 31st, 2017, 11:55 PM
At any rate, I recall a very rough time around 1980 for getting DRAM.

"Dumping" has been a continuing cry in the US for a long time. In the mid-late 1990s, Japanese (e.g. NEC, Fujitsu, Matsushita) and Korean (Hyundai) managed to smooth over things by building DRAM plants in the US. For example, Hyundai/Hynix built a plant here in 1997 to make 16Mb and 64Mb DRAMs amidst threatened trade sanctions. They received a bundle in subsidies, but by the end of 2001, most of the workforce had been furloughed. The 3M square foot building was put on the market in 2008 and only recently has been acquired by Avago. I think Hynix/Hyundai is now making their DRAM in Wuxi.

Often, we make the mistake that market forces are dictated by technical issues only. That's only a small part of the picture most of the time. Heaven knows what the picture will look like in the long run with the current administration.

The Hynix subsidies was considered illegal and after failed acquisition talks with Micron, they filed anti-dumping suits in the US and other countries which resulted in high duties being imposed in 2003. These duties applied only to DRAM chips fabbed in Korea, which made the Eugene fab very useful. They closed this fab in 2008 right around the time the duties was being lifted (I think the Wuxi fab was also running by that time).

Chuck(G)
June 1st, 2017, 07:41 AM
It was an interesting situation. In the case of Hynix, you have a world market and if a domestic fab avoids trade sanctions, it's good. DRAMs are a fungible resource; most manufacturers don't care where their supply comes from.

vwestlife
June 1st, 2017, 07:52 AM
Has anyone ever seen a 5150 with 16k and no drives?

I've seen photos of no-floppy IBM PCjrs, but never any photos of a no-floppy 5150 PC.

Even single-floppy PCs seem to be very rare. The few that existed were probably almost all upgraded to dual-floppy at some point in their life.

krebizfan
June 1st, 2017, 08:09 AM
I've seen photos of no-floppy IBM PCjrs, but never any photos of a no-floppy 5150 PC.

Even single-floppy PCs seem to be very rare. The few that existed were probably almost all upgraded to dual-floppy at some point in their life.

I know a few people that purchased floppy-less IBM PCs. That was mostly because the IBM price for floppy drives was about double what some alternate suppliers charged. I don't think anyone used one in that configuration for long.

Chuck(G)
June 1st, 2017, 08:17 AM
Certainly, when I bought my 5150, Computerland didn't have any fully decked-out units in stock. So I got a 16K unit, and bought a single floppy, controller and MDA. I used a third-party monitor, added a second floppy that I had hanging around and populated the rest of the RAM.

Trixter
June 1st, 2017, 08:56 AM
For what it's worth, my own experience with Japanese DRAM demonstrated that, at the time of the 16K chips, they were far ahead of the US. I remember testing a NEC uPD416 and being stunned that the contents held without refresh for several seconds.

When we were making 8088 MPH, we were shocked to discover that as well -- we could flat-out disable refresh for a full second or more and the contents held. In the end, we opted to lower refresh only a little, to align with whatever multiple of cycle counting we were doing at a given time (ie. to prevent audible aliasing artifacts coming out of the PC speaker). Not all of our test systems had RAM that good, and we wanted the program to work on all 5150s and 5160s.

Casey
June 1st, 2017, 01:50 PM
CP/M had ED instead of EDLIN. I remember using that to create source files until I learned Valdocs had a "non-document mode."

Casey
June 1st, 2017, 01:53 PM
Naaah, it still had "IBM" on the front. :)

Xacalite
June 1st, 2017, 04:38 PM
When we were making 8088 MPH, we were shocked to discover that as well -- we could flat-out disable refresh for a full second or more and the contents held.
Yes, and it has some serious implications on security - https://www.csee.umbc.edu/~nicholas/601/601%20tenMinute%20papers/LeeColdboot.pdf

Chuck(G)
June 1st, 2017, 06:48 PM
I remember the paper, but it seems to me that (a) the tester had power applied to the system and then (b) removed power and chilled the DRAM.

That left me scratching my head. If the system was powered, why remove power?

krebizfan
June 1st, 2017, 07:21 PM
I remember the paper, but it seems to me that (a) the tester had power applied to the system and then (b) removed power and chilled the DRAM.

That left me scratching my head. If the system was powered, why remove power?

The theory is to be able to read the contents of the DRAM from a different system bypassing all the security measures. Locate the decryption key in the DRAM and then have at the hard drives. No guessing of passwords required. Ah, but this superhack is defeated by the expedient of turning off a system 5 minutes before leaving the office. I think having a stranger standing nearby with dry ice might just trigger some response.

Chuck(G)
June 1st, 2017, 08:03 PM
Yeah, exactly! :)

Marty
June 2nd, 2017, 06:02 PM
Hi All;

Most likely I missed something, but, I tried the first two links and I couldn't find the Source files these Programs..

THANK YOU Marty

krebizfan
June 2nd, 2017, 06:12 PM
If you go to the PCJS site, click the SAVE button under the emulator (next to the drive combobox) and that will save the disk image in use. It won't have the right name though so make sure that the newest download is 160kB.

mikey99
June 3rd, 2017, 06:50 AM
I created a bootable diskette using mbbrutman's DSKIMAGE utility.
DSKIMAGE PCDOS090.IMG 1:40:1:8

This booted up fine on my XT-286.

Very interesting piece of history here :-)

SomeGuy
June 3rd, 2017, 05:19 PM
Just for the heck of it, tried it on a few different machines. It booted on my Columbia Data Product 1600, but gave a "divide overflow" trying to do almost anything. Tried a couple of other generic clones, a turbo XT, 286, and an AMD Athlon KT7a system (on 3.5" low density), and it booted and mostly ran, although the RAM version of basic acted kind of screwpot. Tried it on another somewhat newer system (Athlon X2) and it needed the "55AA" signature in the boot sector. Once that was added it did boot but froze trying to run anything.

It is kind of odd to think that the most important program at the time was probably Basic. But that was 1981!.

Chuck(G)
June 3rd, 2017, 05:53 PM
Another early program for the PC was Wordstar.

vwestlife
June 3rd, 2017, 06:38 PM
Another early program for the PC was Wordstar.

...the DOS version of which was hastily ported from CP/M, so it could only address 64K of RAM and lacked support for subdirectories. After a lot of trials and tribulations, these limitations were finally remedied with the introduction of WordStar 4.0 in 1987 -- which was released for both DOS and CP/M, making it probably one of the last major CP/M applications ever.

krebizfan
June 3rd, 2017, 07:47 PM
WordStar for the IBM PC wasn't available until April 1982. Roughly contemporary to the introduction of double sided 5.25" drives from IBM but buying an IBM PC was an expensive method to increase available memory to WordStar from 56kB to 64kB.

The version of VisiCalc upgraded to support 256k was probably the first program to provide a compelling reason for the IBM PC.

Chuck(G)
June 3rd, 2017, 10:25 PM
It actually was pretty surprising how many CP/M applications were auto-translated, tweaked and patched to get them to run on the 5150. SuperCalc, for example, was one such. I recall Wordstar only because I was mildly surprised that the PCDOS version of 3.3 used exactly the same patch locations that the CP/M version did. That is, if you had the CP/M (8 bit) version of the Wordstar customization instructions, you could pretty easily adapt them to DOS.

yuhong
February 25th, 2018, 10:56 AM
Today os2museum posted http://www.os2museum.com/wp/pascal-out-of-memory/

Krille
February 25th, 2018, 11:44 AM
Today os2museum posted http://www.os2museum.com/wp/pascal-out-of-memory/

That kind of bug is incredibly common. You can load almost any old code in a debugger or disassembler and find signed jcc:s where unsigned jcc:s should have been used. Truth be told, most of the x86 assembler code written in the 80's is complete and utter shit.

Chuck(G)
February 25th, 2018, 11:51 AM
Really? I'm ashamed, then. :)

Krille
February 25th, 2018, 11:56 AM
Well, I did say "most", not "all". ;)

krebizfan
February 25th, 2018, 12:03 PM
That kind of bug is incredibly common. You can load almost any old code in a debugger or disassembler and find signed jcc:s where unsigned jcc:s should have been used. Truth be told, most of the x86 assembler code written in the 80's is complete and utter shit.

Though in this case, the code responsible was written in Pascal which only had signed integers in the formal standard. On the other hand, the bug would only be noticed on an original IBM PC which had been upgraded to the full 544 kB and with a test program taking up 12 kB or less.

Krille
February 25th, 2018, 12:15 PM
Though in this case, the code responsible was written in Pascal which only had signed integers in the formal standard.

Oh, I thought the Pascal run-time startup code was written in assembler. My bad.

JohnElliott
February 25th, 2018, 02:59 PM
This is why GEM/1 can't cope with VGA resolution - it uses 16-bit signed arithmetic to calculate the size of a video plane. Fine for EGA (plane is 28000 bytes) but not for VGA (plane is 38400 bytes). I think that particular function is compiled C rather than asm. In GEM/2 it was rewritten to use 32-bit signed arithmetic.

Chuck(G)
February 25th, 2018, 03:15 PM
I suspect that if you take a good-sized sample of x86 assembly (written as such, not generated from an HLL), you'll discover that unsigned integers (16-bit) are used far more than signed.

I suppose a way to tell this is to grep unsigned jumps (e.g. JC/JB/JNB/JNC...) versus signed (JS/JNS/JL/JG/JLE/JGE...) and see which comes out on top.

Krille
March 5th, 2018, 05:31 AM
I suspect that if you take a good-sized sample of x86 assembly (written as such, not generated from an HLL), you'll discover that unsigned integers (16-bit) are used far more than signed.

That's true and it's also the reason why it's so easy to spot the occasional signed jcc because they tend to stick out like a sore thumb.

But this type of bug isn't the only reason for my earlier comment. It's also the fact that whenever I open some old code in IDA (an option ROM BIOS for example) I know beforehand that I will, in less than 30 seconds, find some piece of code where the programmer could have used less space. I shouldn't be able to do that with code written for the early processors, especially not if it's written for the 8088.

Though I don't really blame the programmers from that era. I can imagine a few reasons for the crap they produced;


The x86 was a brand new architecture so the instruction set and its mnemonics was all new. Documentation probably was scarce and/or expensive. And in the dead tree-form. Whereas today I can access all kinds of information electronically, without spending a cent or having to sign NDA:s etc.


I have also enjoyed the luxury of reading decades worth of coding and optimization tips & tricks based on their experiences, whereas they had to start more or less from scratch.


They were commercial programmers, which means they couldn't afford to spend too much time tweaking the code. In other words, they had deadlines.


They used inferior tools like MASM and TASM. Also, something as simple as using a low resolution such as 80x25 text will reduce your overview and make it a lot harder to write good code.

So yeah, hindsight is 20/20 but I stand by my earlier assessment. :)

KC9UDX
March 5th, 2018, 05:38 AM
- We were used to the elegance of the 6502 and found x86 daunting (backwards even).

Though I think I spent more time poring over and refining my x86 code as a result.