• Please review our updated Terms and Rules here

BASIC-in-ROM in an IBM 5170. Why?

tezza

Veteran Member
Joined
Oct 1, 2007
Messages
4,731
Location
New Zealand
Hi,

One thing I didn't realise until I owned an IBM AT is that, like the original PC, it has BASIC in ROM.

The question is, why? I could understand it if there was a Cassette port, but the ATs were always disk-based machines. With no I/O cards installed then, you could write programs using the built-in-BASIC but you couldn't save it anywhere?

Anyone know the rational for keeping a BASIC in ROM in the AT and not just having it entirely disk-based? Did clones also have it in ROM?

A related question. Did the BASIC on PC-DOS 3.x patch into ROM BASIC or was it stand-alone. GW-BASIC on the MS-DOS 3.x versions is a completely stand-alone program, yes?

Tez
 
Suppose someone wanted to run BASIC from PC-DOS--it uses the ROM BASIC for its functioning.

Try running PC-DOS 2.x BASICA on a clone without the BASIC ROMs.
 
One thing I didn't realise until I owned an IBM AT is that, like the original PC, it has BASIC in ROM.

The question is, why? I could understand it if there was a Cassette port, but the ATs were always disk-based machines. With no I/O cards installed then, you could write programs using the built-in-BASIC but you couldn't save it anywhere?

Anyone know the rational for keeping a BASIC in ROM in the AT and not just having it entirely disk-based? Did clones also have it in ROM?

A related question. Did the BASIC on PC-DOS 3.x patch into ROM BASIC or was it stand-alone. GW-BASIC on the MS-DOS 3.x versions is a completely stand-alone program, yes?

Many of the PS/2s also kept BASIC in ROM. In fact there was even a PS/2 BIOS call to find BASIC in ROM: http://www.IBMMuseum.com/interrupts/INT15h/INT15h22.html (Peter Wendt wrote a short ROM BASIC program that gave microchannel adapter IDs, I have made a couple routines in BASIC here: http://www.IBMMuseum.com/Routines).

Plain-vanilla clones didn´t have BASIC in ROM...

And on IBM systems, the BASIC was stand-alone...
 
Suppose someone wanted to run BASIC from PC-DOS--it uses the ROM BASIC for its functioning.

Try running PC-DOS 2.x BASICA on a clone without the BASIC ROMs.

You've just answered one of my questions above Chuck. So the BASIC in PC-DOS is not stand-alone then? That one reason for a BASIC-in-ROM then.

But I'm still puzzelled as to why the didn't they just put the complete BASIC in PC-DOS (like GW-BASIC in MS-DOS) rather than relying on a ROM subset

I guess if there is no penalty to BASIC-in-ROM, then why not have it there but unlike the ROM in the IBM PC, it's not really usable as stand-alone.

Tez
 
The reason is because IBM's licensing agreement with Microsoft required them to put cassette BASIC in the ROM of all of their machines. In 1992, DOS 5.0 was introduced where QBASIC replaced BASICA/GWBASIC. When that happened, the licensing agreement expired and IBM was finally able to remove cassette BASIC.

Since they had an exclusive license to include the 8086 version of Microsoft BASIC in the ROMs of their machines, no clone makers could have it.

It is indeed rather pointless as only the 5150 and PCjr have cassette ports. It seems that Microsoft purposely crippled cassette BASIC as well, as it doesn't even support file-handling statements like OPEN (as Commodore BASIC does for example), just LOAD, SAVE, BLOAD, and BSAVE.
 
The reason is because IBM's licensing agreement with Microsoft required them to put cassette BASIC in the ROM of all of their machines. In 1992, DOS 5.0 was introduced where QBASIC replaced BASICA/GWBASIC. When that happened, the licensing agreement expired and IBM was finally able to remove cassette BASIC.

Since they had an exclusive license to include the 8086 version of Microsoft BASIC in the ROMs of their machines, no clone makers could have it.

That explains it. It was a legal requirement.

Thanks Fallo.

Tez
 
Did the BASIC on PC-DOS 3.x patch into ROM BASIC or was it stand-alone. GW-BASIC on the MS-DOS 3.x versions is a completely stand-alone program, yes?
BASIC/BASICA shipped with PC DOS 3.30 require ROM BASIC.
GW-BASIC shipped with MS-DOS 3.30 is stand-alone, and works on clones as well.

BTW: were there any cards with casette interface compatible with that in 5150s (and supported by ROM BASIC)?
 
BASIC/BASICA shipped with PC DOS 3.30 require ROM BASIC.
GW-BASIC shipped with MS-DOS 3.30 is stand-alone, and works on clones as well.

BTW: were there any cards with casette interface compatible with that in 5150s (and supported by ROM BASIC)?

Yes, but prior to MS-DOS 5.0, MS-DOS was not available as a standalone retail product. IBM users got PC-DOS.

I don't know about the second question. Such a card could not be 100% compatible, as the cassette interface used the 8255 on the motherboard that's also used by the keyboard and system control functions. A card with its own BIOS support would be possible, I suppose, but I've never heard of one. The cassette port wasn't much used even in the original 5150.
 
BASIC/BASICA shipped with PC DOS 3.30 require ROM BASIC.
GW-BASIC shipped with MS-DOS 3.30 is stand-alone, and works on clones as well.

BTW: were there any cards with casette interface compatible with that in 5150s (and supported by ROM BASIC)?

No, but they are possible to make, and it's actually fairly easy too. All you need is a copy of the skeaker/casette interface (decoded to another I/O address, if nessecary*) on an expansion card, and a BIOS extension with a proper Int 15h cassette interface handler. You can even make it output 3-channel shounds instead of the 1-channel sound of the original design, since counter 0 and 1 aren't being used (RAM refresh logic and system clock already exist in the system).
 
Last edited:
Yes, but prior to MS-DOS 5.0, MS-DOS was not available as a standalone retail product. IBM users got PC-DOS.

Actually, MS-DOS 3.20 was the first retail version, but when DOS 5.0 was introduced, all the OEM versions except for PC-DOS disappeared.

Some OEM versions of DOS have BASICA.EXE instead of GWBASIC.EXE. BASICA.COM is the IBM version and is much smaller than the standalone versions.

They also had BASIC.COM, which just added disk support without the advanced sound and graphics statements. This was to save memory if you didn't need those features, but by the time that DOS 3.20 came out (1986), it was no longer an issue as PCs were now shipping with a minimum of 256k. BASIC.COM was then just made into a stub that launched BASICA for compatibility with batch files.

The cassette port wasn't much used even in the original 5150.

Microsoft did not even want to put cassette support in BASIC because they knew no one would use it, but were told by one of the IBM people "Just give me 75 cents worth of software to support 75 cents worth of hardware".
 
I think there are some other things to consider here:

IBM is big on backwards compatibility. Even if an AT doesn't have a cassette port, having BASIC in ROM means that the BASIC and BASICA programs on disk can function the same on all of the IBM machines.

BASIC in ROM also provides a minimal diagnostic environment. You can do peeks and pokes and basic tests to see if the machine is operating. Even for just testing the video and keyboard. Without cassette BASIC in ROM, a machine without a functioning drive is a complete doorstop.
 
I think there are some other things to consider here:

IBM is big on backwards compatibility. Even if an AT doesn't have a cassette port, having BASIC in ROM means that the BASIC and BASICA programs on disk can function the same on all of the IBM machines..

But compatibility in PC-DOS versions would be still be maintained if the filenames BASIC.com and BASICA.com were unchanged, whether or not they contained the whole interpreter or were just a stub to the ROM program, yes? They would just take a bit more room on the disk.

BASIC in ROM also provides a minimal diagnostic environment. You can do peeks and pokes and basic tests to see if the machine is operating. Even for just testing the video and keyboard. Without cassette BASIC in ROM, a machine without a functioning drive is a complete doorstop.

This is true. When my disk controller was not functioning on the AT, the fact that is fell into BASIC-in-ROM was actually useful from a diagnostic point of view. It showed me the motherboard was working.

As an aside I'm having fun at the moment with Virtual PC 2007, setting up a PC-DOS 3.1 enviroment with DOS utilities, menu utilities (pkzip, ped, list.com etc.), a RAMDISK and applications and game software cica about 1986-87. This will mirror what I'll put on my AT soon, and I'm essentially doing this to relearn my way around DOS and those old programs I used to use.

Everything works except BASICA and BASIC for obvious reasons :)

Tez
 
Last edited:
As an aside I'm having fun at the moment with Virtual PC 2007, setting up a PC-DOS 3.1 enviroment with DOS utilities, menu utilities (pkzip, ped, list.com etc.), a RAMDISK and applications and game software cica about 1986-87. This will mirror what I'll put on my AT soon, and I'm essentially doing this to relearn my way around DOS and those old programs I used to use.

Everything works except BASICA and BASIC for obvious reasons :)

Tez


Tez
While we are on the topic,

If you try to write a program that issues Int 18h while DS and ES is set to 0000h, and runs it under Windows XP, you'll actually get an error message telling you that ROM-BASIC isn't supported by NTVDM.
 
While we are on the topic,

If you try to write a program that issues Int 18h while DS and ES is set to 0000h, and runs it under Windows XP, you'll actually get an error message telling you that ROM-BASIC isn't supported by NTVDM.

Actually, it doesn't matter what the registers are set to. The NTVDM just traps INT 18H and puts up a Message Box.
 
Actually, it doesn't matter what the registers are set to. The NTVDM just traps INT 18H and puts up a Message Box.

I know, but then it won't work IF Basic was supported. Is there any point in writing programs that don't work?
 
But compatibility in PC-DOS versions would be still be maintained if the filenames BASIC.com and BASICA.com were unchanged, whether or not they contained the whole interpreter or were just a stub to the ROM program, yes? They would just take a bit more room on the disk.

You forgot about the RAM usage. Being able to reuse 32K of ROM saves RAM.

On an AT this is a moot point since they all had at least 512KB of RAM. But on a PC 32K can be a big difference. It was especially important on the PCjr, which only had 112 or 96K of RAM to work with depending on the video mode.


Mike
 
I know, but then it won't work IF Basic was supported. Is there any point in writing programs that don't work?

I humbly submit that any disk-based program (how else are you going to get something that runs under XP?) that uses INT 18H to exit to ROM BASIC isn't a program that "works". ROM BASIC has no way to get back to the operating system, not to mention the issue of leaving buffers unflushed and disk tables un-updated.

Even BASICA doesn't use INT 18H, which is intended to be used by the BIOS boot routines as a "failed boot" exit point. I'm not aware of any technical reference that advocates calling INT 18 from an OS-resident program, are you?

That being said, I do wish the clone makers had elected to have INT 18 exit to some sort of system debug monitor if the boot from disk failed.
 
You forgot about the RAM usage. Being able to reuse 32K of ROM saves RAM.

On an AT this is a moot point since they all had at least 512KB of RAM. But on a PC 32K can be a big difference. It was especially important on the PCjr, which only had 112 or 96K of RAM to work with depending on the video mode.


Mike

Wasn't the first PC's shipped with only 16Kb of RAM, or did they ship every PC with all 64Kb installed in 1981/1982?
 
I humbly submit that any disk-based program (how else are you going to get something that runs under XP?) that uses INT 18H to exit to ROM BASIC isn't a program that "works". ROM BASIC has no way to get back to the operating system, not to mention the issue of leaving buffers unflushed and disk tables un-updated.

Even BASICA doesn't use INT 18H, which is intended to be used by the BIOS boot routines as a "failed boot" exit point. I'm not aware of any technical reference that advocates calling INT 18 from an OS-resident program, are you?

That being said, I do wish the clone makers had elected to have INT 18 exit to some sort of system debug monitor if the boot from disk failed.

It's better to go into BASIC than to get the computer halted. There may even be a way to return to the operating system:

Step 1: The program makes sure it is activated outside the first 64Kb of memory. Else, it allocates some memory, copies itself out of the first 64Kb of memory, trnasfers controll to the new code, then frees the memory at it's first possition.

Step 2: The Program backs up every piece of RAM below 0000:FFFF and stores it in a safe area outside the first 64kb. Of course it allocates space for this first.

Step 3: The program mounts a routine to one of the IRQ lines. This routine will move the memory back to the first 64kb block, and restores the registers.

Step 4: Int 18h is used to call C-BASIC.

Step 5: When the user wants to return, he/she just needs to activate the IRQ line the routine is associated with. This can be done with a normal flip-flop, some noise-filtering, and a manual toggle switch.

This should theoretically work, as long as no other interrupts goes off durning step 1, 2 and 5. It also relays on that C-BASIC doesn't wipe out the interrupt vector table, and that interrupts are enabled durning runtime. Running BASIC programs that pokes above the first 64Kb should also be avoided.
 
Wasn't the first PC's shipped with only 16Kb of RAM, or did they ship every PC with all 64Kb installed in 1981/1982?

The cassette model of the 5150 had 16k, and disk models had a minimum of 32k.

INT 18h, like INT 19h, was only meant to be called by the BIOS during the POST, as it assumes that there's no OS loaded and that the interrupt vector table is unaltered from its power-on default. Starting cassette BASIC by going into DEBUG and executing an INT 18h is a bad idea, since BASIC will set up its operating environment in the first 64k, where DOS is.

There was a difference on early PCs with 64k of memory, but as I said, 256k became the minimum on new machines by 1986, and so BASIC.COM was dropped. The Compaq Portable had 128k from the beginning, in part because of its RAM-resident BASIC.

As for the PCjr, cartridge BASIC only runs in the first 128k (doesn't normally work with memory expanders), so space is limited.

What I find strange is that GWBASIC gives you 60,300 bytes of program space, but BASICA only gives 60,225 bytes even though most of it is in ROM. Where did those 75 bytes go?

Cassette BASIC does make a useful diagnostic tool to check the memory size, or number of serial, parallel, and joystick ports (as expansion cards like the Six-Pak may not have a port enabled even if it's physically present).
 
Back
Top