Could many/most home-computers of early 80's, have been capable of saving BASIC-Language-Programs to cassette/disk, as machine-code, or possibly even as assembly-code, with a little extra code (or other small modification)?

NOTE - This 'may' only have required a small amount of extra code, to save BASIC-Language-Programs as -

  • As Machine-code - If it was possible to intercept and send the machine-code being sent to the CPU, to a buffer file, maybe line by line, then to a cassette/disk - This 'may' only have required a small amount of extra code.
  • As Assembly-code - If it was possible to intercept and send the assembly-code (generated after the BASIC-Language program was converted to assembly-code) before it was converted to machine-code, to a buffer file, maybe line by line, then to a cassette/disk - This 'may' only have required a small amount of extra code.
    ( I made an incorrect guess about the assembly-code, detailed in the last paragraph of this question, so this would be incorrect, but I will leave it here ).

My Reason For Asking This Question
I'm wondering if maybe home-computer manufacturers didn't include instructions to save BASIC-Language programs as assembly-code or machine-code in order to monopolize (minimize the amount of people who could produce fast software) the software/games market for their machines, since I assume that machine-code or assembly-code software run a lot faster than BASIC-Language software.

My Probable Misunderstandings Which Prompted Me To Post This Question

  • BSAVE BLOAD & BRUN - BSAVE BLOAD & BRUN - Wikipedia - I am still unsure if perhaps BSAVE saves a BASIC-Language-Program from memory, to a cassette/disk, as Machine-Code, and, on that Wikipedia page it says, quote - "a BRUN command that, after loading the file into memory, would immediately attempt to execute it as machine code", which may ( or may not ) suggest that a BSAVE saves BASIC-Language-Programs to a cassette/disk, as a Machine-Code.
  • I incorrectly thought that the definitions stored in the ROM for how to perform BASIC-Language instructions/commands/functions, sat in there as assembly-language-instructions, even though I knew about the Interpreter ( which I thought does all the checking of the program and then executes it directly to the CPU via direct lines/pins to the CPU ) . I have now read more about the Interpreter .
  • 18
    I think most machines didn’t translate BASIC to assembly; they just interpreted it.
    – Tommy
    Commented Mar 29, 2022 at 22:54
  • 18
    The premise is false. BASIC on most micros was not compiled, and therefore there is no 'machine code' (nor 'assembly code') to save. Turning an intepretive system into a compiler system is not a 'small modification;'.
    – dave
    Commented Mar 30, 2022 at 2:36
  • 4
    If it was possible to intercept and send the machine-code being sent to the CPU, -- Why do that? The "machine code being sent to the CPU" is the code of the BASIC interrpreter, which you already have in the ROM.
    – dave
    Commented Mar 30, 2022 at 2:39
  • No, on several levels. It would require that the home computer would in addition to Basic interpreter, also to have a Basic compiler.
    – Justme
    Commented Mar 30, 2022 at 11:12
  • The line between interpretation and compilation is blurry. For Basic on an 8-bit micro, the native arithmetic (8-bit integer) doesn't match the language's arithmetic (floating point), so machine code would be either impossibly complicated or a series of library function calls with few other instructions. ECD Basic compiled to "threaded code", which was essentially just addresses of operators. A tiny "interpreter" picked these up and branched to them in sequence (more efficient than subroutine linkage). The threaded code was effectively the machine language of a virtual machine.
    – John Doty
    Commented Mar 30, 2022 at 16:37

6 Answers 6


If it was possible to intercept and send the machine-code being sent to the CPU, to a cassette/disk.

This sounds like you want to record the instructions a CPU is executing to some media. If yes, than this is way beyond any capability of a home or personal computer, as the data rate is simply beyond what any storage system could do.

  • A 6502 running at 1 MHz, like on a C64 would need to store about 1 MiB/s.
  • That's about 2000 times faster than the fastest cassette interface could deliver (average home computers were even 2-5 times slower).
  • It's as well some 250 faster than a floppy system of that time (not counting seek times)
  • Finally it's still 2 times faster than the maximum transfer speed a ST506 or ST225 hard disk could deliver.

So no, simply not possible to intercept any code send to the CPU

Not to mention the extra hardware needed to capture and record this date - after all, the process is usually done in software. Heck, it's still the same today. Modern CPU again run faster than any regular storage media can record.

Doing such recording is the domain of In Circuit Emulators. And even these usually operate by stopping and/or and slowing down their target. Quite expensive devices. A somewhat capable system for an 8 bit home computer in the early 1980s was in the region of 20,000 to 50,000 USD, depending on capabilities. Systems capable doing real time ICE for modern CPUs go easy past 1.5 million USD per unit.

So, no. Not even close to the capabilities of an 8 bit system at the time, nor within price range of a home system.

If it was possible to intercept and send the assembly-code ( generated after the BASIC was converted to assembly-code ) before it was converted to machine-code, to a cassette/disk.

Not really sure here either. For one this sounds like simply saving the program. No need to 'intercept' anything, just save it to media, the very same way like it's done today.

Except that BASIC does not generate any Assembly code. BASIC is an interpreter language, essentially a virtual CPU, like a Java byte code interpreter.

I'm wondering if maybe home-computer manufacturers didn't include instructions to save BASIC-Language programs as assembly-code or machine-code in order to monopolize the software/games market for their machines, since I assume that assembly-code or machine-code run alot faster than BASIC-Language software.

There are several misconceptions here:

  • Save and load for BASIC programs are integral to the BASIC language. After all, what good is a programming language when programs can not be stored and retrieved?

  • All BASIC machines (*1) at the time used BASIC, as mentioned, Interpreters. There is no machine code produced.

  • Even less any intermediate Assembly source. These machines simply had not enough storage (RAM, floppies) to compile in a two stage process. Compiler for home computers, if available at all, always produced direct machine code.

  • Such compilers were almost always (*2) third party software - which then of course could save their product - who would spend money on a compiler if it can't save the produced code? Or, would want to spend much time waiting for compile before running any program?

  • While machine code is of course faster than BASIC, this is not always needed, not even for games.

  • In fact, several home computers had their BASIC especially improved to handle performance relevant parts like sound and graphics with additional commands, allowing write fast paced games in BASIC (*3).

Last but not least:

What was true for game consoles - that console manufacturers wanted to make a share from games sold (as well) - was never the case about home computers. They are an open architecture by definition.

So, why should computer companies artificial cut down machine features? Their intention was to sell machines, wasn't it? Crippled designed do not really sell well, do they? Even less if other manufacturer machines do provide these features?

*1 - That is home computer class with BASIC in ROM at the time

*2 - Trying to be careful, with the incredible number of different home computers that were designed and sold at the time, there might be some odd one who had a compiler included. Never say never when it's about Punk-Age-Computing :))

*3 - Not just Woz' Integer BASIC which was intended for Games i nthe first place, but as well machines like the TI 99/4. This computer was often looked down at for being ... lets say "not fast", but with extended BASIC, it was possible to create and animate graphics while playing music of typical games of the time without a single line of machine code.

P.S.: Considering various more or less well worded questions over the last days, it seems you're trying to research a certain use case, but miss the needed basic concepts about computers in general and simple (1980s) computers in particular to ask the right way. It might be useful to point out the purpose of our search and how the information gathered is to be used, so we can tailor answers more to the point of your search.

  • 8
    @dntknw That's a fundamental misunderstanding of how BASIC typically worked. BASIC was interpreted. Depending on the machine, it was either stored as plain text in memory or, on many machines, tokenized to save precious RAM. You couldn't save BASIC in as machine code because it simply didn't work that way. As far as software/games market - in the computer market (as opposed to the game console market) software sold by the manufacturer was in order to sell more computers, not the other way around. Apple, Atari, IBM, Radio Shack, Commodore - they all had very strong 3rd-party software vendors. Commented Mar 30, 2022 at 1:37
  • 2
    @dntknw He tried to focus on an assumed implication of your question that there was no way to save/load machine language programs, which is not true. Essentially all BASIC allowed to load and save machine language in addition to or instead of BASIC programs.
    – Raffzahn
    Commented Mar 30, 2022 at 1:49
  • 1
    Regarding footnote 1, the once I used where I had to load the BASIC from tape or other media still used a BASIC interpreter as standard. (Sharp MZ series)
    – UncleBod
    Commented Mar 30, 2022 at 8:56
  • 1
    @StephenKitt CBASIC was pretty standard for (more or less) professional software development under CP/M since ca.1977. It could produce a p-code (for more density) or 8080 machine code. Beside being more advanced than MS' MBASIC, the C stands not for Compiler as many assume, but for Commercial, as it used BCD float to avoid non decimal artefacts - something accountants hate :)) CBASIC was later bought by DR and as well published for the PC.
    – Raffzahn
    Commented Mar 30, 2022 at 12:43
  • 2
    @dntknw BASIC save files are either plain-text representations of the BASIC program, or tokenised representations (many systems allowed both, e.g. 8-bit Ataris) — never machine language. Commented Mar 30, 2022 at 12:47

I think you have a fundamental misunderstanding of how a (BASIC-) interpreter works. An interpreter does not generate machine code that is then "sent to the CPU", it is machine code that is executed by the CPU which in turn executes the BASIC program. With an interpreter, there is no intermediary machine code to "intercept" and save.

Nor does it make any sense to record the execution of the intepreter and save that to tape, for that would (a) not be any faster than running the basic program, and would (b) not be able to capture any deviations based on, say, user input or the general state of the system.

Generating machine code is what compilers do, and what sets them apart from interpreters. Compilers generally require more resources (memory and disk space, in particular) than interpreters, and generally do not allow for direct debugging (stop the program, see where it's at, inspect variables, etc.) without a separate runtime debugger (which, in turn, requires additional resources). That is why most 8-bit-machines shipped with interpreters rather than compilers. However, compilers for BASIC and many other languages were readily available for most 8-bit platforms, except the smallest ones.

There was, in other words, no conspiracy ot stop people from writing "fast software".


It sounds like you are asking about what is commonly referred to as a "Machine Language Monitor", or "ML Monitor". This is a small utility program that is very commonly used on (all) early computers, including 8-bit home computers. It's frequently considered as the most primitive of all the "sane" ways to interact with a computer.

Fundamentally, there's no need to do any "intercept and send the machine-code...". This because all the code that will be executed is first loaded into memory (RAM/ROM). The ML Monitor allows you to interrupt whatever code is running, then examine it as it exists in memory, along with all the memory-resident data it is using. You can easily view any area of memory as hex data or as assembly code, and you can generally save any range of that code/data memory to an external storage device, such as disk or tape.

Some of the earliest 8-bit home computers, such as the Apple ][, had an ML Monitor utility built into their ROM. For anyone doing assembly language programming, this was a vital debugging aid. All the other computers you can think of also had ML Monitors available. You could even find them printed in magazines, to be typed in by novice users.

  • I have now clarified my question, to specify 'BASIC-Language programs' - "Could many/most home-computers of early 80's, have been capable of saving BASIC-Language programs to cassette/disk, as machine-code, or possibly even as assembly-code - Your answer does not mention 'BASIC-Language programs', so I assume thats why it contradicts Raffzahn answer.
    – dntknw
    Commented Mar 30, 2022 at 1:34
  • 6
    @dntknw It dos not contradict any of it. It's a different focus provoked by asking for something hard to gasp as it implies something that never had been: homecomputer manufacturer trying to hinder people programming their products - the very use case they are made for.
    – Raffzahn
    Commented Mar 30, 2022 at 1:47
  • In thread 24149 I described how a monitor/disassembler and assembler could be set up. They, or the system, usually had a means to save "just a block of bytes".
    – user24174
    Commented Mar 30, 2022 at 11:15

I have vague recollection of some machines being able to load binaries from tape, but can't be specific. If any machine had that capability, and it was undocumented ("hidden by the manufacturer"), the "hackers" would have figured it out by tracing through whatever mechanics were used to facilitate the load, and would have replicated it for their games. Maybe the Atari could do that?

Yes, here it is: What did the cassette bootloader in 8 Bit Ataris do?

At the same time, I'm pretty sure there were BASIC programs hacked so that when loaded, if you did a LIST you'd only see a few lines of BASIC, while the rest of the machine language was loaded behind it. This wasn't a built in procedure, the authors just exploited the load and save routines. This was a crude copy protection mechanism to keep folks from seeing the code of the game.


I'm wondering if maybe home-computer manufacturers didn't include instructions to save BASIC-Language programs as assembly-code or machine-code in order to monopolize (minimize the amount of people who could produce fast software) the software/games market for their machines, since I assume that assembly-code or machine-code software run a lot faster than BASIC-Language software.

No, they did it because machine code is a hard language to program in and assembler is not much better.

BASIC stands for Beginners' All-purpose Symbolic Instruction Code. As the name suggests, it was designed to be easy for beginners to use. It is also machine independent (unlike machine code which varies greatly between different CPUs and is tightly bound to the specific hardware of the machine) and has strong error checking to ensure that bad code can't crash the computer.

Most home computers had a BASIC interpreter which acted as the operating system, using 'immediate' mode to execute commands directly rather than having to write and compile/assemble and then run a program. The BASIC interpreter was held in ROM, and the BASIC program stored in RAM as tokens which took up much less space than plain text. ROM was cheaper than RAM so this made home computers more affordable, and BASIC programs were smaller than the equivalent assembler source so they took less time to save and load from cassette tape (the nonvolatile storage medium used on most home computers to again make them more affordable).

The downsides of these advantages of interpreted BASIC are much slower execution of each line of code (though not necessarily the program, depending on what functions are being called) and less flexibility. Most home computer BASICs added the commands POKE and CALL or USR() to allow creating and executing machine code from within BASIC programs, and some also had binary save and load commands for producing stand-alone machine code programs. BBC BASIC also allowed embedding lines of assembly language in the BASIC program.

A lot of commercial programs (including some games) were written in BASIC. Most home computers provided some means of creating machine code that could be called from BASIC, allowing the production of 'hybrid' programs that used the advantages of both. Some BASICs had a means of protecting the code from being viewed and modified to prevent plagiarism, encouraging commercial use. BASIC code could also be compiled to increase execution speed for games or other programs that needed it.

Far from minimizing the number of people who could create fast machine code games, BASIC provided an easy to learn and bulletproof development environment that put computing power in the hands of people who otherwise could not afford it. Many famous commercial developers learned to program on home computers, which they might not have done if only far more expensive and harder to learn 'professional' development platforms were available.

The few exceptions to this include gaming consoles that didn't come with BASIC, forcing users to buy prepackaged commercial games that were produced by or licensed to the console manufacturer.

Some computers had an instruction to save a part of memory to external-media, as a binary-file, but I was told that would not run any faster than the original BASIC-Language program.

This is not correct. In fact being able to save and load binary code made it easier to create machine code which would run faster. Computers that didn't have this feature had to poke the data into memory from the BASIC program, which was much slower and used more memory. In some cases like the Sinclair ZX81, ways were found to embed the machine code inside a REM statement or character array which would be saved with the program, which was more difficult than a straight binary save/load.

Are binary saves/files of BASIC-Language programs, stored in memory as machine language, or is a binary save/file, a binary format save of the BASIC-Language program?

Interpreted BASIC programs are stored as plain text, or more commonly tokenized text which is more compact and faster to interpret. There is no machine code in a BASIC-language program, either in memory or saved in a file. The machine code is part of the interpreter (which in most home computers is stored in ROM).

Binary files can contain anything, including machine code, graphics data etc. Depending on the dialect of BASIC, it may have commands to load and run a binary file directly as machine code, or it may have to be loaded and then the machine code entered at a specific address using a CALL statement or USR() function.


A machine-specific compiler program can be loaded into a computer with a built-in BASIC interpreter. When run it will compile the basic program in memory into a machine language program that can be saved on disk or tape. Some of these compiler programs worked better than others. The main reason for interpreters is ease of editing the programs. Some had an always on built-in debugger that would not let you complete a line of code with a syntax error. Because of the slow speed of the old machines it was much faster to write programs with an interpreter since a compiler took a considerable amount of time to work. The trade off was a much slower execution of the program. Since most home computers were aimed at beginning programmers that would be making a lot of mistakes at first, the trade off was an acceptable one. Also there were peek and poke commands that could be used to generate machine code subroutines that would considerably speed up sections of the program. The headache was that you had to learn machine code to use them. I hope this answers your question.

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