Mixing
Developing an application in the era of cassette tapes (audio-tapes)
Clash Royale CLAN TAG#URR8PPP
up vote
11
down vote
favorite
My colleague and I have just had a conversation and we were wondering how the process of developing an application was done in the era of cassette tapes.
Today we have HDDs, backup HDDs, FTPs, repositories in the cloud, etc. -- so we don't care: we just save, send and share our data, but...
I myself, as a child, had a Timex 2048 (ZX Spectrum clone) in the 90s and I remember that creating an application involved saving my work on the tape, then next day I loaded it into Timex's memory, made changes, saved on the tape again and so on. But I worked alone for my own happiness and the applications I created weren't complex.
But what about cases when there were two or more developers? How did they share their code?
What about complex applications? Graphics (simple, but still) for games?
What about the durability of their work? We all know that cassette tapes were very unreliable: errors during saving and reloading data were common. (Eventually FDDs became available for computers such as Spectrum, Atari and Commodore, but as far as I remember they were quite expensive; and they weren't available from the very first moment, were they?)
software-development cassette-tape magnetic-tape
edited Aug 30 at 13:33
psmears
1353
asked Aug 29 at 14:52
jacek.ciach
1934
 |Â
show 3 more comments
up vote
11
down vote
favorite
My colleague and I have just had a conversation and we were wondering how the process of developing an application was done in the era of cassette tapes.
Today we have HDDs, backup HDDs, FTPs, repositories in the cloud, etc. -- so we don't care: we just save, send and share our data, but...
I myself, as a child, had a Timex 2048 (ZX Spectrum clone) in the 90s and I remember that creating an application involved saving my work on the tape, then next day I loaded it into Timex's memory, made changes, saved on the tape again and so on. But I worked alone for my own happiness and the applications I created weren't complex.
But what about cases when there were two or more developers? How did they share their code?
What about complex applications? Graphics (simple, but still) for games?
What about the durability of their work? We all know that cassette tapes were very unreliable: errors during saving and reloading data were common. (Eventually FDDs became available for computers such as Spectrum, Atari and Commodore, but as far as I remember they were quite expensive; and they weren't available from the very first moment, were they?)
software-development cassette-tape magnetic-tape
edited Aug 30 at 13:33
psmears
1353
asked Aug 29 at 14:52
jacek.ciach
1934
1
Possibly a dupe of retrocomputing.stackexchange.com/questions/3314/…, but maybe not since this focuses on the storage and collaboration aspects.
– Wilson
Aug 29 at 14:56
2
Few professional developers would've used tapes for anything other than distributing their completed programs.
– Ross Ridge
Aug 29 at 15:11
1
Possible duplicate of How were the first ZX Spectrum games written?
– Michael Kjörling
Aug 29 at 20:08
Also closely related, possible duplicate: Retrocomputing Software Development Process/Methodologies
– Michael Kjörling
Aug 29 at 20:09
The 8-bit systems that were this limited weren't useful for professional development. The editing and building was done on more sophisticated systems, with a cross-assembler where necessary. Remote debugging would also come in handy. Sort of a kin to developing for a mobile device on your PC today.
– Brian H
Aug 29 at 21:34
 |Â
show 3 more comments
up vote
11
down vote
favorite
up vote
11
down vote
favorite
My colleague and I have just had a conversation and we were wondering how the process of developing an application was done in the era of cassette tapes.
Today we have HDDs, backup HDDs, FTPs, repositories in the cloud, etc. -- so we don't care: we just save, send and share our data, but...
I myself, as a child, had a Timex 2048 (ZX Spectrum clone) in the 90s and I remember that creating an application involved saving my work on the tape, then next day I loaded it into Timex's memory, made changes, saved on the tape again and so on. But I worked alone for my own happiness and the applications I created weren't complex.
But what about cases when there were two or more developers? How did they share their code?
What about complex applications? Graphics (simple, but still) for games?
What about the durability of their work? We all know that cassette tapes were very unreliable: errors during saving and reloading data were common. (Eventually FDDs became available for computers such as Spectrum, Atari and Commodore, but as far as I remember they were quite expensive; and they weren't available from the very first moment, were they?)
software-development cassette-tape magnetic-tape
edited Aug 30 at 13:33
psmears
1353
asked Aug 29 at 14:52
jacek.ciach
1934
My colleague and I have just had a conversation and we were wondering how the process of developing an application was done in the era of cassette tapes.
Today we have HDDs, backup HDDs, FTPs, repositories in the cloud, etc. -- so we don't care: we just save, send and share our data, but...
I myself, as a child, had a Timex 2048 (ZX Spectrum clone) in the 90s and I remember that creating an application involved saving my work on the tape, then next day I loaded it into Timex's memory, made changes, saved on the tape again and so on. But I worked alone for my own happiness and the applications I created weren't complex.
But what about cases when there were two or more developers? How did they share their code?
What about complex applications? Graphics (simple, but still) for games?
What about the durability of their work? We all know that cassette tapes were very unreliable: errors during saving and reloading data were common. (Eventually FDDs became available for computers such as Spectrum, Atari and Commodore, but as far as I remember they were quite expensive; and they weren't available from the very first moment, were they?)
software-development cassette-tape magnetic-tape
edited Aug 30 at 13:33
psmears
1353
asked Aug 29 at 14:52
jacek.ciach
1934
edited Aug 30 at 13:33
psmears
1353
edited Aug 30 at 13:33
psmears
1353
edited Aug 30 at 13:33
psmears
1353
1353
asked Aug 29 at 14:52
jacek.ciach
1934
asked Aug 29 at 14:52
jacek.ciach
1934
asked Aug 29 at 14:52
jacek.ciach
1934
1934
1
Possibly a dupe of retrocomputing.stackexchange.com/questions/3314/…, but maybe not since this focuses on the storage and collaboration aspects.
– Wilson
Aug 29 at 14:56
2
Few professional developers would've used tapes for anything other than distributing their completed programs.
– Ross Ridge
Aug 29 at 15:11
1
Possible duplicate of How were the first ZX Spectrum games written?
– Michael Kjörling
Aug 29 at 20:08
Also closely related, possible duplicate: Retrocomputing Software Development Process/Methodologies
– Michael Kjörling
Aug 29 at 20:09
The 8-bit systems that were this limited weren't useful for professional development. The editing and building was done on more sophisticated systems, with a cross-assembler where necessary. Remote debugging would also come in handy. Sort of a kin to developing for a mobile device on your PC today.
– Brian H
Aug 29 at 21:34
 |Â
show 3 more comments
1
Possibly a dupe of retrocomputing.stackexchange.com/questions/3314/…, but maybe not since this focuses on the storage and collaboration aspects.
– Wilson
Aug 29 at 14:56
2
Few professional developers would've used tapes for anything other than distributing their completed programs.
– Ross Ridge
Aug 29 at 15:11
1
Possible duplicate of How were the first ZX Spectrum games written?
– Michael Kjörling
Aug 29 at 20:08
Also closely related, possible duplicate: Retrocomputing Software Development Process/Methodologies
– Michael Kjörling
Aug 29 at 20:09
The 8-bit systems that were this limited weren't useful for professional development. The editing and building was done on more sophisticated systems, with a cross-assembler where necessary. Remote debugging would also come in handy. Sort of a kin to developing for a mobile device on your PC today.
– Brian H
Aug 29 at 21:34
1
1
Possibly a dupe of retrocomputing.stackexchange.com/questions/3314/…, but maybe not since this focuses on the storage and collaboration aspects.
– Wilson
Aug 29 at 14:56
Possibly a dupe of retrocomputing.stackexchange.com/questions/3314/…, but maybe not since this focuses on the storage and collaboration aspects.
– Wilson
Aug 29 at 14:56
2
2
Few professional developers would've used tapes for anything other than distributing their completed programs.
– Ross Ridge
Aug 29 at 15:11
Few professional developers would've used tapes for anything other than distributing their completed programs.
– Ross Ridge
Aug 29 at 15:11
1
1
Possible duplicate of How were the first ZX Spectrum games written?
– Michael Kjörling
Aug 29 at 20:08
Possible duplicate of How were the first ZX Spectrum games written?
– Michael Kjörling
Aug 29 at 20:08
Also closely related, possible duplicate: Retrocomputing Software Development Process/Methodologies
– Michael Kjörling
Aug 29 at 20:09
Also closely related, possible duplicate: Retrocomputing Software Development Process/Methodologies
– Michael Kjörling
Aug 29 at 20:09
The 8-bit systems that were this limited weren't useful for professional development. The editing and building was done on more sophisticated systems, with a cross-assembler where necessary. Remote debugging would also come in handy. Sort of a kin to developing for a mobile device on your PC today.
– Brian H
Aug 29 at 21:34
The 8-bit systems that were this limited weren't useful for professional development. The editing and building was done on more sophisticated systems, with a cross-assembler where necessary. Remote debugging would also come in handy. Sort of a kin to developing for a mobile device on your PC today.
– Brian H
Aug 29 at 21:34
 |Â
show 3 more comments
7 Answers
7
active
oldest
votes
up vote
9
down vote
Obviously, you can just switch tapes as you go, but systems that used cassette tapes for storage weren't really viable for collaborative development.
Simply because with a cassette tape, you had "what's in memory" and "what's on tape", and the occasional task of saving and loading from a tape.
So you could have someone walk over with a cassette so they can work on it, but there was no effective way to "merge" work at the basic cassette level.
Since cassettes dominated the micro market, you're basically stuck with BASIC as a primary development tool. And some BASICs allowed you to read in text, possibly from tape, like an "include", but it was rare.
In the end, the cassette tape was barely viable for individual development (being both very slow and absolutely notorious for unreliability, along with a whole host of other problems), much less collaborative work.
So, much of the "professional" development on such systems weren't done on those systems at all, but rather they were developed on mini computers with cross development environments. Those systems obviously were much more sophisticated.
answered Aug 29 at 16:14
Will Hartung
2,494614
6
The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it)
– Frédéric Grosshans
Aug 29 at 16:45
1
@FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer)
– jacek.ciach
Aug 29 at 17:46
2
"*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter.
– scruss
Aug 29 at 21:50
@scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it.
– Will Hartung
Aug 29 at 22:52
1
@WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources.
– J...
Aug 30 at 13:38
 |Â
show 1 more comment
up vote
7
down vote
Probably, no serious software development was done purely on tapes.
Floppies were used extensively, as well as cross-tools, ROM emulators etc.
This nice and free book, telling about the creation of the famous ZX Spectrum game named "R-Type", has also some insights into the typical development process for ZX Spectrum.
answered Aug 29 at 23:43
lvd
1,892314
1
That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ...
– scruss
Aug 30 at 4:38
add a comment |Â
up vote
5
down vote
What about complex applications?
You bought a floppy drive, or before that, used punch tape. The period where cassettes were the only form of storage on micros was basically zero.
Up to about 1976 the ASR33 was widely used as the main I/O system for micros, and it had a punch tape system. You could also buy stand-alone punches and readers, both RS232 and current loop. Recall that the first Microsoft BASIC was published on punch tape, and these were widely traded at the Homebrew meetings.
The cassette was developed after the Altair, notably by Processor Technology's CUPS system, and the later KSS, both from late 1975.
But floppies appeared very quickly; MITS was advertising their 88-DCDD Pertec-based 8" system in March 1976. Digital Systems apparently was shipping a similar system in 1975.
I couldn't afford a floppy for my Atari, so I used cassettes right through the early 1980s, but everyone else I knew had a floppy, no matter what platform.
answered Aug 29 at 16:18
Maury Markowitz
1,785420
2
“The period where cassettes were the only form of storage on micros was basically zero.†That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives).
– Stephen Kitt
Aug 29 at 18:04
I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist.
– scruss
Aug 29 at 21:52
@scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s?
– Maury Markowitz
Aug 30 at 19:14
add a comment |Â
up vote
5
down vote
It depends a lot on the machine, the job and your team size and what time we're talking.
Professional developers usually didn't work on the same minimal setup as their target user. Especially in the begining it was common to develop on a larger, somewhat compatible system (or total different with cross compilers) with 'real' mass storage, and usually better editors and so on. And even when workign on the target machine, it was common to have it souped up with disk drives and alike.
Next most jobs where still in a region a single programmer could (and did) handle on his own, so no need to exchange data or files with others. Even if there was a team, theIr job was usually rather seperated, so they exchanged their parts on a regular base and each integrated what the others did.
Compared to today it was way more a world of single coding heroes than teams.
At a point when realy teams where build and multiple programmers (and designers) worked on the same project, disks, including centralized stores where already available. Much like today.
answered Aug 29 at 17:46
Raffzahn
32.6k471129
add a comment |Â
up vote
2
down vote
If you were really determined, you could develop a program in assembly, on a tape-based micro, where the program was too large for the source to fit in memory.
I did this on a TRS-80 model I with... I think 32KB of RAM. It was a long time ago, but I think that's right.
The idea is to break the program up into modules, with each module having some related functions. Each source file, small enough to fit in memory, contained the assembly source for one module. Each module's object code was absolutely located in memory.
I had to keep track each module's location in memory, and it's size. I was serving the role normally held by a relocating linker. When a module grew so large that it was going to impinge upon the following module, I would move modules around in memory, which would mean individually editing each module's source to change its start address.
In a fixed location in memory that did not move around, I kept a jump table. Each public function in a module wrote a JP instruction to a fixed location in that jump table. So when function FOO needed to be called, instead of calling FOO direction, the calling code would CALL foo's entry in the jump table, which would in turn jump to the function.
Each module initialized its locations in the jump table when it was loaded.
The process of creating the program was:
Assemble each module, writing its object to tape as absolutely located binary.
Now load each module's object, one after the other. As each module loaded, it loaded its code into its proper place in memory, and also initialized its entries in the jump table.
Now run it. If it's bad, debug it. If it's good, write the combined RAM image of the program out to a tape. That new tape is the complete program.
I only wrote one program like this. It was a fairly OK rendition of the Atari two-player "Tank" game.
answered Aug 30 at 17:01
Wayne Conrad
733411
add a comment |Â
up vote
2
down vote
What about complex applications?
Some of the more complex applications were cross-assembled on larger (minicomputer) systems (see Basic, Gates and Allen, and Tiny, also Apple DOS, et.al.).
Some more complex applications (in ASM and Basic) were printed in multi-part magazine or newsletter articles, and typed in by the user by hand. Cassette tape was used for checkpointing, just in case the cat got tangled in and pulled out the power cord after hours of typing.
Some FORTH systems may have allowed saving and loading of "blocks" (which could be used as modules for larger applications) to/from cassette tape.
answered Aug 30 at 15:58
hotpaw2
2,636420
add a comment |Â
up vote
1
down vote
What about complex applications? Graphics (simple, but still) for
games?
You couldn't really have that complex of a program on the small home computers that used audio tapes. For example, your Timex 2048 had 16k of RAM. Most of these programs were written in BASIC, which meant you had to store the entire program in source form, along with the interpreter. That gives you at best only 16,384 characters, which works out to about a 430 line BASIC program. I have C++ source files I'm working right now much longer than that. I don't even consider it "code smell" until a source file gets over 1000 lines.
Most programs didn't use Assember directly, due to porting issues (porting between BASICs was bad enough, TYVM). But for ones that did, a <16K binary still meant the amount of source code that went into creating it really couldn't be too much more than a single person could handle.
answered Aug 30 at 14:50
T.E.D.
1834
add a comment |Â
7 Answers
7
active
oldest
votes
7 Answers
7
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
9
down vote
Obviously, you can just switch tapes as you go, but systems that used cassette tapes for storage weren't really viable for collaborative development.
Simply because with a cassette tape, you had "what's in memory" and "what's on tape", and the occasional task of saving and loading from a tape.
So you could have someone walk over with a cassette so they can work on it, but there was no effective way to "merge" work at the basic cassette level.
Since cassettes dominated the micro market, you're basically stuck with BASIC as a primary development tool. And some BASICs allowed you to read in text, possibly from tape, like an "include", but it was rare.
In the end, the cassette tape was barely viable for individual development (being both very slow and absolutely notorious for unreliability, along with a whole host of other problems), much less collaborative work.
So, much of the "professional" development on such systems weren't done on those systems at all, but rather they were developed on mini computers with cross development environments. Those systems obviously were much more sophisticated.
answered Aug 29 at 16:14
Will Hartung
2,494614
6
The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it)
– Frédéric Grosshans
Aug 29 at 16:45
1
@FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer)
– jacek.ciach
Aug 29 at 17:46
2
"*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter.
– scruss
Aug 29 at 21:50
@scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it.
– Will Hartung
Aug 29 at 22:52
1
@WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources.
– J...
Aug 30 at 13:38
 |Â
show 1 more comment
up vote
9
down vote
Obviously, you can just switch tapes as you go, but systems that used cassette tapes for storage weren't really viable for collaborative development.
Simply because with a cassette tape, you had "what's in memory" and "what's on tape", and the occasional task of saving and loading from a tape.
So you could have someone walk over with a cassette so they can work on it, but there was no effective way to "merge" work at the basic cassette level.
Since cassettes dominated the micro market, you're basically stuck with BASIC as a primary development tool. And some BASICs allowed you to read in text, possibly from tape, like an "include", but it was rare.
In the end, the cassette tape was barely viable for individual development (being both very slow and absolutely notorious for unreliability, along with a whole host of other problems), much less collaborative work.
So, much of the "professional" development on such systems weren't done on those systems at all, but rather they were developed on mini computers with cross development environments. Those systems obviously were much more sophisticated.
answered Aug 29 at 16:14
Will Hartung
2,494614
6
The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it)
– Frédéric Grosshans
Aug 29 at 16:45
1
@FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer)
– jacek.ciach
Aug 29 at 17:46
2
"*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter.
– scruss
Aug 29 at 21:50
@scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it.
– Will Hartung
Aug 29 at 22:52
1
@WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources.
– J...
Aug 30 at 13:38
 |Â
show 1 more comment
up vote
9
down vote
up vote
9
down vote
Obviously, you can just switch tapes as you go, but systems that used cassette tapes for storage weren't really viable for collaborative development.
Simply because with a cassette tape, you had "what's in memory" and "what's on tape", and the occasional task of saving and loading from a tape.
So you could have someone walk over with a cassette so they can work on it, but there was no effective way to "merge" work at the basic cassette level.
Since cassettes dominated the micro market, you're basically stuck with BASIC as a primary development tool. And some BASICs allowed you to read in text, possibly from tape, like an "include", but it was rare.
In the end, the cassette tape was barely viable for individual development (being both very slow and absolutely notorious for unreliability, along with a whole host of other problems), much less collaborative work.
So, much of the "professional" development on such systems weren't done on those systems at all, but rather they were developed on mini computers with cross development environments. Those systems obviously were much more sophisticated.
answered Aug 29 at 16:14
Will Hartung
2,494614
Obviously, you can just switch tapes as you go, but systems that used cassette tapes for storage weren't really viable for collaborative development.
Simply because with a cassette tape, you had "what's in memory" and "what's on tape", and the occasional task of saving and loading from a tape.
So you could have someone walk over with a cassette so they can work on it, but there was no effective way to "merge" work at the basic cassette level.
Since cassettes dominated the micro market, you're basically stuck with BASIC as a primary development tool. And some BASICs allowed you to read in text, possibly from tape, like an "include", but it was rare.
In the end, the cassette tape was barely viable for individual development (being both very slow and absolutely notorious for unreliability, along with a whole host of other problems), much less collaborative work.
So, much of the "professional" development on such systems weren't done on those systems at all, but rather they were developed on mini computers with cross development environments. Those systems obviously were much more sophisticated.
answered Aug 29 at 16:14
Will Hartung
2,494614
answered Aug 29 at 16:14
Will Hartung
2,494614
answered Aug 29 at 16:14
Will Hartung
2,494614
answered Aug 29 at 16:14
Will Hartung
2,494614
2,494614
6
The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it)
– Frédéric Grosshans
Aug 29 at 16:45
1
@FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer)
– jacek.ciach
Aug 29 at 17:46
2
"*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter.
– scruss
Aug 29 at 21:50
@scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it.
– Will Hartung
Aug 29 at 22:52
1
@WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources.
– J...
Aug 30 at 13:38
 |Â
show 1 more comment
6
The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it)
– Frédéric Grosshans
Aug 29 at 16:45
1
@FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer)
– jacek.ciach
Aug 29 at 17:46
2
"*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter.
– scruss
Aug 29 at 21:50
@scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it.
– Will Hartung
Aug 29 at 22:52
1
@WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources.
– J...
Aug 30 at 13:38
6
6
The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it)
– Frédéric Grosshans
Aug 29 at 16:45
The fact that the cassette were standard audio-cassette allowed distribution of programmes over FM radio, which was done in Finland in the 1980’s (Ars Technica paper about it)
– Frédéric Grosshans
Aug 29 at 16:45
1
1
@FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer)
– jacek.ciach
Aug 29 at 17:46
@FrédéricGrosshans So was done in Poland; this broadcast was called "Radiokomputer" (en: radio-computer)
– jacek.ciach
Aug 29 at 17:46
2
2
"*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter.
– scruss
Aug 29 at 21:50
"*you're basically stuck with BASIC as a primary development tool:": not really. Assemblers such as HiSoft Devpac supported tape, and (IIRC) came with instructions to save a working copy at the beginning of a tape, so you could keep track of revisions with the tape counter.
– scruss
Aug 29 at 21:50
@scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it.
– Will Hartung
Aug 29 at 22:52
@scruss Sure. Pretty sure the Atari Assembler/Editor cartridge would save to tape as well. But those are outliers, and woe to the poor soul doing assembly development on cassette. At least the machines could warm reset when your program went south, to where you ideally wouldn't lost your work in progress, but even that could be cold comfort and only take you so far. And even then I don't know if they supported collaborative development of loading additional pieces of code vs just wiping the entire workspace and replacing it.
– Will Hartung
Aug 29 at 22:52
1
1
@WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources.
– J...
Aug 30 at 13:38
@WillHartung I'd probably go so far as to say that assembly was the dominant option for any serious programming. BASIC was fine for quick toy programs, but I think a lot of early stuff (C64/ZX era) on early personal computers was all written in assembly, not the least for its efficiency with very limited memory and CPU resources.
– J...
Aug 30 at 13:38
 |Â
show 1 more comment
up vote
7
down vote
Probably, no serious software development was done purely on tapes.
Floppies were used extensively, as well as cross-tools, ROM emulators etc.
This nice and free book, telling about the creation of the famous ZX Spectrum game named "R-Type", has also some insights into the typical development process for ZX Spectrum.
answered Aug 29 at 23:43
lvd
1,892314
1
That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ...
– scruss
Aug 30 at 4:38
add a comment |Â
up vote
7
down vote
Probably, no serious software development was done purely on tapes.
Floppies were used extensively, as well as cross-tools, ROM emulators etc.
This nice and free book, telling about the creation of the famous ZX Spectrum game named "R-Type", has also some insights into the typical development process for ZX Spectrum.
answered Aug 29 at 23:43
lvd
1,892314
1
That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ...
– scruss
Aug 30 at 4:38
add a comment |Â
up vote
7
down vote
up vote
7
down vote
Probably, no serious software development was done purely on tapes.
Floppies were used extensively, as well as cross-tools, ROM emulators etc.
This nice and free book, telling about the creation of the famous ZX Spectrum game named "R-Type", has also some insights into the typical development process for ZX Spectrum.
answered Aug 29 at 23:43
lvd
1,892314
Probably, no serious software development was done purely on tapes.
Floppies were used extensively, as well as cross-tools, ROM emulators etc.
This nice and free book, telling about the creation of the famous ZX Spectrum game named "R-Type", has also some insights into the typical development process for ZX Spectrum.
answered Aug 29 at 23:43
lvd
1,892314
answered Aug 29 at 23:43
lvd
1,892314
answered Aug 29 at 23:43
lvd
1,892314
answered Aug 29 at 23:43
lvd
1,892314
1,892314
1
That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ...
– scruss
Aug 30 at 4:38
add a comment |Â
1
That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ...
– scruss
Aug 30 at 4:38
1
1
That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ...
– scruss
Aug 30 at 4:38
That's an interesting read, @lvd - so Bob Pape started on Microdrive, moved up to a floppy system, then onto PDS. By utter coincidence, I knew some of the Atari ST developers mentioned. They were at Strathclyde University while I was, and the mechanical engineering 1st year comp lab had Atari STs. I helped play-test a few levels when I should've been doing lab work ...
– scruss
Aug 30 at 4:38
add a comment |Â
up vote
5
down vote
What about complex applications?
You bought a floppy drive, or before that, used punch tape. The period where cassettes were the only form of storage on micros was basically zero.
Up to about 1976 the ASR33 was widely used as the main I/O system for micros, and it had a punch tape system. You could also buy stand-alone punches and readers, both RS232 and current loop. Recall that the first Microsoft BASIC was published on punch tape, and these were widely traded at the Homebrew meetings.
The cassette was developed after the Altair, notably by Processor Technology's CUPS system, and the later KSS, both from late 1975.
But floppies appeared very quickly; MITS was advertising their 88-DCDD Pertec-based 8" system in March 1976. Digital Systems apparently was shipping a similar system in 1975.
I couldn't afford a floppy for my Atari, so I used cassettes right through the early 1980s, but everyone else I knew had a floppy, no matter what platform.
answered Aug 29 at 16:18
Maury Markowitz
1,785420
2
“The period where cassettes were the only form of storage on micros was basically zero.†That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives).
– Stephen Kitt
Aug 29 at 18:04
I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist.
– scruss
Aug 29 at 21:52
@scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s?
– Maury Markowitz
Aug 30 at 19:14
add a comment |Â
up vote
5
down vote
What about complex applications?
You bought a floppy drive, or before that, used punch tape. The period where cassettes were the only form of storage on micros was basically zero.
Up to about 1976 the ASR33 was widely used as the main I/O system for micros, and it had a punch tape system. You could also buy stand-alone punches and readers, both RS232 and current loop. Recall that the first Microsoft BASIC was published on punch tape, and these were widely traded at the Homebrew meetings.
The cassette was developed after the Altair, notably by Processor Technology's CUPS system, and the later KSS, both from late 1975.
But floppies appeared very quickly; MITS was advertising their 88-DCDD Pertec-based 8" system in March 1976. Digital Systems apparently was shipping a similar system in 1975.
I couldn't afford a floppy for my Atari, so I used cassettes right through the early 1980s, but everyone else I knew had a floppy, no matter what platform.
answered Aug 29 at 16:18
Maury Markowitz
1,785420
2
“The period where cassettes were the only form of storage on micros was basically zero.†That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives).
– Stephen Kitt
Aug 29 at 18:04
I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist.
– scruss
Aug 29 at 21:52
@scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s?
– Maury Markowitz
Aug 30 at 19:14
add a comment |Â
up vote
5
down vote
up vote
5
down vote
What about complex applications?
You bought a floppy drive, or before that, used punch tape. The period where cassettes were the only form of storage on micros was basically zero.
Up to about 1976 the ASR33 was widely used as the main I/O system for micros, and it had a punch tape system. You could also buy stand-alone punches and readers, both RS232 and current loop. Recall that the first Microsoft BASIC was published on punch tape, and these were widely traded at the Homebrew meetings.
The cassette was developed after the Altair, notably by Processor Technology's CUPS system, and the later KSS, both from late 1975.
But floppies appeared very quickly; MITS was advertising their 88-DCDD Pertec-based 8" system in March 1976. Digital Systems apparently was shipping a similar system in 1975.
I couldn't afford a floppy for my Atari, so I used cassettes right through the early 1980s, but everyone else I knew had a floppy, no matter what platform.
answered Aug 29 at 16:18
Maury Markowitz
1,785420
What about complex applications?
You bought a floppy drive, or before that, used punch tape. The period where cassettes were the only form of storage on micros was basically zero.
Up to about 1976 the ASR33 was widely used as the main I/O system for micros, and it had a punch tape system. You could also buy stand-alone punches and readers, both RS232 and current loop. Recall that the first Microsoft BASIC was published on punch tape, and these were widely traded at the Homebrew meetings.
The cassette was developed after the Altair, notably by Processor Technology's CUPS system, and the later KSS, both from late 1975.
But floppies appeared very quickly; MITS was advertising their 88-DCDD Pertec-based 8" system in March 1976. Digital Systems apparently was shipping a similar system in 1975.
I couldn't afford a floppy for my Atari, so I used cassettes right through the early 1980s, but everyone else I knew had a floppy, no matter what platform.
answered Aug 29 at 16:18
Maury Markowitz
1,785420
answered Aug 29 at 16:18
Maury Markowitz
1,785420
answered Aug 29 at 16:18
Maury Markowitz
1,785420
answered Aug 29 at 16:18
Maury Markowitz
1,785420
1,785420
2
“The period where cassettes were the only form of storage on micros was basically zero.†That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives).
– Stephen Kitt
Aug 29 at 18:04
I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist.
– scruss
Aug 29 at 21:52
@scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s?
– Maury Markowitz
Aug 30 at 19:14
add a comment |Â
2
“The period where cassettes were the only form of storage on micros was basically zero.†That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives).
– Stephen Kitt
Aug 29 at 18:04
I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist.
– scruss
Aug 29 at 21:52
@scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s?
– Maury Markowitz
Aug 30 at 19:14
2
2
“The period where cassettes were the only form of storage on micros was basically zero.†That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives).
– Stephen Kitt
Aug 29 at 18:04
“The period where cassettes were the only form of storage on micros was basically zero.†That’s true in general, but some micros didn‘t benefit from it. For example, the ZX Spectrum and its clones didn’t have a floppy drive for several years... The Apple II also didn’t have a floppy drive for a little while, and other micros similarly started out with no drives (or vapourware drives).
– Stephen Kitt
Aug 29 at 18:04
I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist.
– scruss
Aug 29 at 21:52
I don't think that's the universal experience. In some countries, floppy drives and media were hit with very high import duties. In the UK, this was purely protectionist.
– scruss
Aug 29 at 21:52
@scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s?
– Maury Markowitz
Aug 30 at 19:14
@scruss - indeed, I understand that tapes were widely used in eastern europe and south america well into the 1990s?
– Maury Markowitz
Aug 30 at 19:14
add a comment |Â
up vote
5
down vote
It depends a lot on the machine, the job and your team size and what time we're talking.
Professional developers usually didn't work on the same minimal setup as their target user. Especially in the begining it was common to develop on a larger, somewhat compatible system (or total different with cross compilers) with 'real' mass storage, and usually better editors and so on. And even when workign on the target machine, it was common to have it souped up with disk drives and alike.
Next most jobs where still in a region a single programmer could (and did) handle on his own, so no need to exchange data or files with others. Even if there was a team, theIr job was usually rather seperated, so they exchanged their parts on a regular base and each integrated what the others did.
Compared to today it was way more a world of single coding heroes than teams.
At a point when realy teams where build and multiple programmers (and designers) worked on the same project, disks, including centralized stores where already available. Much like today.
answered Aug 29 at 17:46
Raffzahn
32.6k471129
add a comment |Â
up vote
5
down vote
It depends a lot on the machine, the job and your team size and what time we're talking.
Professional developers usually didn't work on the same minimal setup as their target user. Especially in the begining it was common to develop on a larger, somewhat compatible system (or total different with cross compilers) with 'real' mass storage, and usually better editors and so on. And even when workign on the target machine, it was common to have it souped up with disk drives and alike.
Next most jobs where still in a region a single programmer could (and did) handle on his own, so no need to exchange data or files with others. Even if there was a team, theIr job was usually rather seperated, so they exchanged their parts on a regular base and each integrated what the others did.
Compared to today it was way more a world of single coding heroes than teams.
At a point when realy teams where build and multiple programmers (and designers) worked on the same project, disks, including centralized stores where already available. Much like today.
answered Aug 29 at 17:46
Raffzahn
32.6k471129
add a comment |Â
up vote
5
down vote
up vote
5
down vote
It depends a lot on the machine, the job and your team size and what time we're talking.
Professional developers usually didn't work on the same minimal setup as their target user. Especially in the begining it was common to develop on a larger, somewhat compatible system (or total different with cross compilers) with 'real' mass storage, and usually better editors and so on. And even when workign on the target machine, it was common to have it souped up with disk drives and alike.
Next most jobs where still in a region a single programmer could (and did) handle on his own, so no need to exchange data or files with others. Even if there was a team, theIr job was usually rather seperated, so they exchanged their parts on a regular base and each integrated what the others did.
Compared to today it was way more a world of single coding heroes than teams.
At a point when realy teams where build and multiple programmers (and designers) worked on the same project, disks, including centralized stores where already available. Much like today.
answered Aug 29 at 17:46
Raffzahn
32.6k471129
It depends a lot on the machine, the job and your team size and what time we're talking.
Professional developers usually didn't work on the same minimal setup as their target user. Especially in the begining it was common to develop on a larger, somewhat compatible system (or total different with cross compilers) with 'real' mass storage, and usually better editors and so on. And even when workign on the target machine, it was common to have it souped up with disk drives and alike.
Next most jobs where still in a region a single programmer could (and did) handle on his own, so no need to exchange data or files with others. Even if there was a team, theIr job was usually rather seperated, so they exchanged their parts on a regular base and each integrated what the others did.
Compared to today it was way more a world of single coding heroes than teams.
At a point when realy teams where build and multiple programmers (and designers) worked on the same project, disks, including centralized stores where already available. Much like today.
answered Aug 29 at 17:46
Raffzahn
32.6k471129
answered Aug 29 at 17:46
Raffzahn
32.6k471129
answered Aug 29 at 17:46
Raffzahn
32.6k471129
answered Aug 29 at 17:46
Raffzahn
32.6k471129
32.6k471129
add a comment |Â
add a comment |Â
up vote
2
down vote
If you were really determined, you could develop a program in assembly, on a tape-based micro, where the program was too large for the source to fit in memory.
I did this on a TRS-80 model I with... I think 32KB of RAM. It was a long time ago, but I think that's right.
The idea is to break the program up into modules, with each module having some related functions. Each source file, small enough to fit in memory, contained the assembly source for one module. Each module's object code was absolutely located in memory.
I had to keep track each module's location in memory, and it's size. I was serving the role normally held by a relocating linker. When a module grew so large that it was going to impinge upon the following module, I would move modules around in memory, which would mean individually editing each module's source to change its start address.
In a fixed location in memory that did not move around, I kept a jump table. Each public function in a module wrote a JP instruction to a fixed location in that jump table. So when function FOO needed to be called, instead of calling FOO direction, the calling code would CALL foo's entry in the jump table, which would in turn jump to the function.
Each module initialized its locations in the jump table when it was loaded.
The process of creating the program was:
Assemble each module, writing its object to tape as absolutely located binary.
Now load each module's object, one after the other. As each module loaded, it loaded its code into its proper place in memory, and also initialized its entries in the jump table.
Now run it. If it's bad, debug it. If it's good, write the combined RAM image of the program out to a tape. That new tape is the complete program.
I only wrote one program like this. It was a fairly OK rendition of the Atari two-player "Tank" game.
answered Aug 30 at 17:01
Wayne Conrad
733411
add a comment |Â
up vote
2
down vote
If you were really determined, you could develop a program in assembly, on a tape-based micro, where the program was too large for the source to fit in memory.
I did this on a TRS-80 model I with... I think 32KB of RAM. It was a long time ago, but I think that's right.
The idea is to break the program up into modules, with each module having some related functions. Each source file, small enough to fit in memory, contained the assembly source for one module. Each module's object code was absolutely located in memory.
I had to keep track each module's location in memory, and it's size. I was serving the role normally held by a relocating linker. When a module grew so large that it was going to impinge upon the following module, I would move modules around in memory, which would mean individually editing each module's source to change its start address.
In a fixed location in memory that did not move around, I kept a jump table. Each public function in a module wrote a JP instruction to a fixed location in that jump table. So when function FOO needed to be called, instead of calling FOO direction, the calling code would CALL foo's entry in the jump table, which would in turn jump to the function.
Each module initialized its locations in the jump table when it was loaded.
The process of creating the program was:
Assemble each module, writing its object to tape as absolutely located binary.
Now load each module's object, one after the other. As each module loaded, it loaded its code into its proper place in memory, and also initialized its entries in the jump table.
Now run it. If it's bad, debug it. If it's good, write the combined RAM image of the program out to a tape. That new tape is the complete program.
I only wrote one program like this. It was a fairly OK rendition of the Atari two-player "Tank" game.
answered Aug 30 at 17:01
Wayne Conrad
733411
add a comment |Â
up vote
2
down vote
up vote
2
down vote
If you were really determined, you could develop a program in assembly, on a tape-based micro, where the program was too large for the source to fit in memory.
I did this on a TRS-80 model I with... I think 32KB of RAM. It was a long time ago, but I think that's right.
The idea is to break the program up into modules, with each module having some related functions. Each source file, small enough to fit in memory, contained the assembly source for one module. Each module's object code was absolutely located in memory.
I had to keep track each module's location in memory, and it's size. I was serving the role normally held by a relocating linker. When a module grew so large that it was going to impinge upon the following module, I would move modules around in memory, which would mean individually editing each module's source to change its start address.
In a fixed location in memory that did not move around, I kept a jump table. Each public function in a module wrote a JP instruction to a fixed location in that jump table. So when function FOO needed to be called, instead of calling FOO direction, the calling code would CALL foo's entry in the jump table, which would in turn jump to the function.
Each module initialized its locations in the jump table when it was loaded.
The process of creating the program was:
Assemble each module, writing its object to tape as absolutely located binary.
Now load each module's object, one after the other. As each module loaded, it loaded its code into its proper place in memory, and also initialized its entries in the jump table.
Now run it. If it's bad, debug it. If it's good, write the combined RAM image of the program out to a tape. That new tape is the complete program.
I only wrote one program like this. It was a fairly OK rendition of the Atari two-player "Tank" game.
answered Aug 30 at 17:01
Wayne Conrad
733411
If you were really determined, you could develop a program in assembly, on a tape-based micro, where the program was too large for the source to fit in memory.
I did this on a TRS-80 model I with... I think 32KB of RAM. It was a long time ago, but I think that's right.
The idea is to break the program up into modules, with each module having some related functions. Each source file, small enough to fit in memory, contained the assembly source for one module. Each module's object code was absolutely located in memory.
I had to keep track each module's location in memory, and it's size. I was serving the role normally held by a relocating linker. When a module grew so large that it was going to impinge upon the following module, I would move modules around in memory, which would mean individually editing each module's source to change its start address.
In a fixed location in memory that did not move around, I kept a jump table. Each public function in a module wrote a JP instruction to a fixed location in that jump table. So when function FOO needed to be called, instead of calling FOO direction, the calling code would CALL foo's entry in the jump table, which would in turn jump to the function.
Each module initialized its locations in the jump table when it was loaded.
The process of creating the program was:
Assemble each module, writing its object to tape as absolutely located binary.
Now load each module's object, one after the other. As each module loaded, it loaded its code into its proper place in memory, and also initialized its entries in the jump table.
Now run it. If it's bad, debug it. If it's good, write the combined RAM image of the program out to a tape. That new tape is the complete program.
I only wrote one program like this. It was a fairly OK rendition of the Atari two-player "Tank" game.
answered Aug 30 at 17:01
Wayne Conrad
733411
answered Aug 30 at 17:01
Wayne Conrad
733411
answered Aug 30 at 17:01
Wayne Conrad
733411
answered Aug 30 at 17:01
Wayne Conrad
733411
733411
add a comment |Â
add a comment |Â
up vote
2
down vote
What about complex applications?
Some of the more complex applications were cross-assembled on larger (minicomputer) systems (see Basic, Gates and Allen, and Tiny, also Apple DOS, et.al.).
Some more complex applications (in ASM and Basic) were printed in multi-part magazine or newsletter articles, and typed in by the user by hand. Cassette tape was used for checkpointing, just in case the cat got tangled in and pulled out the power cord after hours of typing.
Some FORTH systems may have allowed saving and loading of "blocks" (which could be used as modules for larger applications) to/from cassette tape.
answered Aug 30 at 15:58
hotpaw2
2,636420
add a comment |Â
up vote
2
down vote
What about complex applications?
Some of the more complex applications were cross-assembled on larger (minicomputer) systems (see Basic, Gates and Allen, and Tiny, also Apple DOS, et.al.).
Some more complex applications (in ASM and Basic) were printed in multi-part magazine or newsletter articles, and typed in by the user by hand. Cassette tape was used for checkpointing, just in case the cat got tangled in and pulled out the power cord after hours of typing.
Some FORTH systems may have allowed saving and loading of "blocks" (which could be used as modules for larger applications) to/from cassette tape.
answered Aug 30 at 15:58
hotpaw2
2,636420
add a comment |Â
up vote
2
down vote
up vote
2
down vote
What about complex applications?
Some of the more complex applications were cross-assembled on larger (minicomputer) systems (see Basic, Gates and Allen, and Tiny, also Apple DOS, et.al.).
Some more complex applications (in ASM and Basic) were printed in multi-part magazine or newsletter articles, and typed in by the user by hand. Cassette tape was used for checkpointing, just in case the cat got tangled in and pulled out the power cord after hours of typing.
Some FORTH systems may have allowed saving and loading of "blocks" (which could be used as modules for larger applications) to/from cassette tape.
answered Aug 30 at 15:58
hotpaw2
2,636420
What about complex applications?
Some of the more complex applications were cross-assembled on larger (minicomputer) systems (see Basic, Gates and Allen, and Tiny, also Apple DOS, et.al.).
Some more complex applications (in ASM and Basic) were printed in multi-part magazine or newsletter articles, and typed in by the user by hand. Cassette tape was used for checkpointing, just in case the cat got tangled in and pulled out the power cord after hours of typing.
Some FORTH systems may have allowed saving and loading of "blocks" (which could be used as modules for larger applications) to/from cassette tape.
answered Aug 30 at 15:58
hotpaw2
2,636420
edited Aug 31 at 6:33
answered Aug 30 at 15:58
hotpaw2
2,636420
answered Aug 30 at 15:58
hotpaw2
2,636420
answered Aug 30 at 15:58
hotpaw2
2,636420
2,636420
add a comment |Â
add a comment |Â
up vote
1
down vote
What about complex applications? Graphics (simple, but still) for
games?
You couldn't really have that complex of a program on the small home computers that used audio tapes. For example, your Timex 2048 had 16k of RAM. Most of these programs were written in BASIC, which meant you had to store the entire program in source form, along with the interpreter. That gives you at best only 16,384 characters, which works out to about a 430 line BASIC program. I have C++ source files I'm working right now much longer than that. I don't even consider it "code smell" until a source file gets over 1000 lines.
Most programs didn't use Assember directly, due to porting issues (porting between BASICs was bad enough, TYVM). But for ones that did, a <16K binary still meant the amount of source code that went into creating it really couldn't be too much more than a single person could handle.
answered Aug 30 at 14:50
T.E.D.
1834
add a comment |Â
up vote
1
down vote
What about complex applications? Graphics (simple, but still) for
games?
You couldn't really have that complex of a program on the small home computers that used audio tapes. For example, your Timex 2048 had 16k of RAM. Most of these programs were written in BASIC, which meant you had to store the entire program in source form, along with the interpreter. That gives you at best only 16,384 characters, which works out to about a 430 line BASIC program. I have C++ source files I'm working right now much longer than that. I don't even consider it "code smell" until a source file gets over 1000 lines.
Most programs didn't use Assember directly, due to porting issues (porting between BASICs was bad enough, TYVM). But for ones that did, a <16K binary still meant the amount of source code that went into creating it really couldn't be too much more than a single person could handle.
answered Aug 30 at 14:50
T.E.D.
1834
add a comment |Â
up vote
1
down vote
up vote
1
down vote
What about complex applications? Graphics (simple, but still) for
games?
You couldn't really have that complex of a program on the small home computers that used audio tapes. For example, your Timex 2048 had 16k of RAM. Most of these programs were written in BASIC, which meant you had to store the entire program in source form, along with the interpreter. That gives you at best only 16,384 characters, which works out to about a 430 line BASIC program. I have C++ source files I'm working right now much longer than that. I don't even consider it "code smell" until a source file gets over 1000 lines.
Most programs didn't use Assember directly, due to porting issues (porting between BASICs was bad enough, TYVM). But for ones that did, a <16K binary still meant the amount of source code that went into creating it really couldn't be too much more than a single person could handle.
answered Aug 30 at 14:50
T.E.D.
1834
What about complex applications? Graphics (simple, but still) for
games?
You couldn't really have that complex of a program on the small home computers that used audio tapes. For example, your Timex 2048 had 16k of RAM. Most of these programs were written in BASIC, which meant you had to store the entire program in source form, along with the interpreter. That gives you at best only 16,384 characters, which works out to about a 430 line BASIC program. I have C++ source files I'm working right now much longer than that. I don't even consider it "code smell" until a source file gets over 1000 lines.
Most programs didn't use Assember directly, due to porting issues (porting between BASICs was bad enough, TYVM). But for ones that did, a <16K binary still meant the amount of source code that went into creating it really couldn't be too much more than a single person could handle.
answered Aug 30 at 14:50
T.E.D.
1834
answered Aug 30 at 14:50
T.E.D.
1834
answered Aug 30 at 14:50
T.E.D.
1834
answered Aug 30 at 14:50
T.E.D.
1834
1834
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f7413%2fdeveloping-an-application-in-the-era-of-cassette-tapes-audio-tapes%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
Possibly a dupe of retrocomputing.stackexchange.com/questions/3314/…, but maybe not since this focuses on the storage and collaboration aspects.
– Wilson
Aug 29 at 14:56
2
Few professional developers would've used tapes for anything other than distributing their completed programs.
– Ross Ridge
Aug 29 at 15:11
1
Possible duplicate of How were the first ZX Spectrum games written?
– Michael Kjörling
Aug 29 at 20:08
Also closely related, possible duplicate: Retrocomputing Software Development Process/Methodologies
– Michael Kjörling
Aug 29 at 20:09
The 8-bit systems that were this limited weren't useful for professional development. The editing and building was done on more sophisticated systems, with a cross-assembler where necessary. Remote debugging would also come in handy. Sort of a kin to developing for a mobile device on your PC today.
– Brian H
Aug 29 at 21:34