The early versions of Microsoft BASIC required 4KB of ROM, and many versions existed in the 8KB and 16KB size. But Microsoft's IBM BASIC (known as "Cassette BASIC") for the original IBM PC (Model 5150) required 32KB. This seems odd to me given competitors like:

  1. 8KB CBM BASIC v2.0 in the Commodore 64, which had all the essential disk file functions (but no graphics).
  2. 16KB CBM BASIC v7.0 in the Commodore 128, which had many enhanced features plus graphics.
  3. 16KB BBC BASIC which perhaps had the broadest features of any comparable BASIC and even out-performed IBM BASIC running on the faster PC.

Why was the IBM BASIC so huge (relatively speaking) at 32 KB?

Note/Update: The total amount of ROM in the original IBM PC is 40KB. The additional 8KB being for the PC BIOS. It came on 5x8KB ROM chips.

  • 6
    What is your source for the values? Commented Jan 4, 2020 at 21:52
  • 2
    The three references were all written for a different processor. I think the processors even uses a completely different way to access memory. This makes the comparison a bit off. Besides, you need a complete comparison of what the different Basics could handle before you say one is very much bigger than another.
    – UncleBod
    Commented Jan 4, 2020 at 22:55
  • 6
    Your examples are all for 8-bit 6502s. The sorta-kinda 16-bit code for the 8088/8086 is less dense.
    – scruss
    Commented Jan 4, 2020 at 23:06
  • 8
    @scruss Citation needed. By all metrics I've seen, x86 has extremely dense code. It is certainly the most dense of all modern architectures, and it compares respectably to the Z80, which is pretty much the all-time winner for code density of microcomputer architectures. Commented Jan 5, 2020 at 10:10
  • 4
    Note that the Beeb has 16k for BASIC and another 16k MOS which includes the cassette operating system etc.
    – Gaius
    Commented Jan 6, 2020 at 10:41

5 Answers 5


The early versions of Microsoft BASIC required 4KB of ROM

The 4k versions lacked a number of major features, including string variables. These were added in the 8k versions. The equivalent 6502 version, which also expanded the floating point from 32 to 40 bits, was about 10k.

But Microsoft's IBM BASIC (known as "Cassette BASIC") for the original IBM PC (Model 5150) required 32KB.

There are two primary reasons for this.

One is that the 16-bit format is naturally larger than the 8-bit format of the earlier machines. This likely accounts for half of the difference right off the bat, and perhaps more if I'm right that it didn't use an analog of zero-page for the parser.

This version also included the screen editor and rudimentary operating system for the cassette. These too would be larger than their 8-bit cousins, and the editor, in particular, would normally be part of the underlying OS ROM, at least that was the case on the Atari and Commodore machines.

  • 2
    So you are contending the 32KB IBM BASIC ROM is functionally equivalent to the C128's 16KB BASIC v7 (a full-featured BASIC) plus the C128's 16KB Kernel ROM (simple OS and screen editor). In that case, code size differences between 8088 and 6502 maybe don't account for much. I feel like code density should be similar, because the 8088 supports single byte operands well enough and because the 8088 has many more sophisticated instructions than the 6502. But I guess 2-byte RISC-like instructions for the Zero Page could be significant.
    – Brian H
    Commented Jan 5, 2020 at 1:00
  • 3
    That last paragraph is particularly relevant when considering a comparison with BBC BASIC on the Model B/Master etc. All or most of the commands for I/O (e.g. graphics, sound and file handling) just make calls to the 16kB OS ROM which does all the work. Commented Jan 5, 2020 at 1:22
  • 1
    Worth pointing out that MBASIC for CP/M is 24K in size.There are some early 86 basic versions online and they have sizes roughly around 29K so there was some code bloat due to processor changes but not huge amounts. I suspect a lot of the difference (compared to 6502) is down to supporting both single and double precision and print using etc.
    – PeterI
    Commented Jan 5, 2020 at 1:26
  • 1
    I guess that on an 8088/6 the main density disadvantage is that you almost always have to use an addressing mode suffix byte, making most instructions two bytes in size even before attaching addresses and immediate data. Though I'd have thought the repetition suffixes would do what they're meant to and save quite a bit on string processing?
    – Tommy
    Commented Jan 6, 2020 at 16:28
  • 3
    @Tommy: There are I think three loops in the 6502 versions of BASIC where the REP functions would be useful, and the total size of those loops is probably less than 50 bytes.
    – supercat
    Commented Jan 6, 2020 at 16:57

[Maury Markowitz' answer already nails it, so this is just to add some numbers for comparison]

The Cassette BASIC 1.0/1.1 in the IBM PC ROM is a Microsoft BASIC V5.x (*1). It's usually marketed as MBASIC. It was available as stand alone application or as program under CP/M and other OS. MS offered 3 basic flavours:

  • 8 KiB BASIC
  • Extended BASIC
  • Disk BASIC

8 KiB BASIC was intended for (low cost) home computer with limited ROM space. I'm not really sure if there were any uses at all, but it's mentioned in some early manuals.

So a good comparison may be typical Extended BASIC machines (Although Cassette BASIC is a bit different, see below):

  • *MSX BASIC (2)

  • MSX1 BASIC uses 16 KiB ROM for BASIC but needs a rather upper end BIOS to work, filling another 16 KiB for a total of 32 KiB ROM. For disk usage another 16 KiB Disk-ROM is added, which included a 4 KiB BASIC extension.

  • MSX2 BASIC added another 16 KiB (*3) for BASIC for a total of 64 KiB ROM.

  • TA Alphatronic PC

This Z80 based machine featured 32 KiB ROM, of which 8 house the BIOS/OS, while 24 KiB are used for Microsoft Extended BASIC V5.11. This BASIC did not feature any disk extensions, which had to be loaded from disk - much like with the IBM-PC

In addition it's important to see that IBM's Cassette BASIC is Disk BASIC sans disk support (driver). Unlike Extended BASIC, all mechanics for abstract devices are already included. Access is done thru files, using names like "LPTn" or "CAS1". It does no longer need (or support) specific commands like CLOAD/CSAVE for cassette or LPRINT for printer handling, as Extended BASIC does.

Bottom line: Microsoft Extended BASIC (without Disk support) for Z80 systems already filled ~24 KiB of ROM. So 32 KiB for an even more enhanced Version doesn't seam like a lot (*4)

Background IBM PC BASIC

IBM offered BASIC in 3 flavours:

  • Cassette (ROM) BASIC
  • BASIC.COM, to extended ROM BASIC with functions for handling disk files (*2)
  • BASICACOM, adding disk handling plus advanced Features for graphics and sound.

The later two were not stand alone solutions, but extensions to the ROM code. BASIC.COM only adds disk access and handling for serial ports(*4), while BASICA offers many more functions for graphics and sound.

The separation in BASIC.COM and BASICA.COM was made to maximize available RAM on machines with less than 128 KiB. 32 KiB is the absolute minimum to use DOS 1.x. With BASICA loaded this would leave about 1 KiB of RAM for BASIC. So not really usable. BASIC.COM reduced the footprint by ~6 KiB, enabling the use on a 32 KiB minimum system. Still not much better than what a VIC-20 could do for a fraction. For useful programs in BASIC, and comperable numbers to other computers of the time, 48 KiB was the minimum, leaving 17 KiB under BASICA and 23 KiB under BASIC.COM. And with 64 KiB the PC managed to beat the C64 with a whopping 43 KiB free under BASICA.

In it's structure BASIC 5.0 was still an 8/16 bit program. All data (BASIC code plus all data) was held in a single segment (*5). Thus none of the three BASICs could provide more then 61 KiB to a BASIC user. A PC with 96 KiB RAM (*6) would be all a BASIC user could have dreamed about :))

*1 - I'm not sure about the exact version, but it must be after 5.0, but before 5.28

*2 - After all, MSX is said to mean MicroSoft eXtended BASIC

*3 - I'd say code size between Z80 and 8086 version is rather close. After all, the 8086 was made to support 8080 style programming without bloating the code too much - that's why there are many short encodings for instruction equivalent to 8080 instructions - which in turn the Z80 uses as well. Over all increase is somewhere around 20-30% without optimization.

*4 - Due the already abstract file access mechanics.

*5 - While it can be speculated, that porting was kept simple by keeping the memory layout exactly like with the 8080 version, I think it's much more likely that 61 KiB maximum BASIC space seamed, as so often, more than enough for everything.

*6 - 64 KiB motherboard RAM plus 32 KiB Memory Expansion Option (card) - yes, there was such a thing


Even Cassette Basic offered many features not present in the 6502 dialects, including the ability to use long variable names, support for both single and double-precision floating point, support for both 16-bit and 32-bit integer types, support for hex and octal numbers, and many other features.

  • Good point. I wish there was a reference to a more definitive breakdown comparing it with the better 6502 BASICs, such as 16K CBM BASIC v7, 16K BBC BASIC, or Applesoft.
    – Brian H
    Commented Jan 6, 2020 at 16:50
  • I've found The BASIC Handbook useful for this, but you have to do the feature xreffing yourself. Applesoft's its own special hybrid of early MS + whatever Apple was thinking at the time. BBC BASIC is very different: nominally specced to be compatible with MBASIC of the time, its non-core features diverged quickly from any other BASIC
    – scruss
    Commented Jan 7, 2020 at 17:01

My recollection is that BASIC was machine translated from the 8080 BASIC, and so would have been bigger and slower than something written to take full advantage of the 8086.


BASIC was translated at the ASM level from 8080/Z80 to 8086. It includes a number of macros that do basic tasks which could easily have been done in single instructions if BASIC were written from scratch. One of my favorite sequences that I find littered throughout the code:


This is for saving and restoring the flags from stack.

There are similar manipulations to store and retrieve SI using BX as an intermediate. Since these are common operations, they appear often in the code.

  • 2
    While this may have contributed to code bloat, I doubt this was particularly decisive. Have you tried estimating how much space could be saved by using more compact instructions? Commented Nov 10, 2022 at 15:35
  • Compare as well: <retrocomputing.stackexchange.com/q/24173/15334> Commented Nov 13, 2022 at 18:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .