First, many thanks for the great question. This may well be my favourite retrocomputing video of them all, so I contemplated having a look at the executable for a while myself. So, this is what I did:
To download the audio, I went to the same YouTube video and used 4K Video Downloader (mainly because it clearly shows which audio is the original one, so that ...
You need to use OpenMSX, and get the system ROMs for the machine in question. Then run OpenMSX, set the machine to the FS-A1WSX. There's a little menu button at the top left of the OpenMSX window. In there, set your tape to the WAV file. Then:
10 M$ = "E4E8O3G16G32R32G2G4R4O4C8D8E8F8G2G8F8E8F4E8D8E4D8C4"
20 PLAY M$+M$
The listing above is the content of ...
As you guessed,
loads a BASIC loader.
LOAD "" CODE
loads a machine code program saved on the tape straight into memory, at the addresses given when using
SAVE name CODE start, length
Doing it this way means you can squeeze the most code into the memory, not wasting any on the loader or a loading screen.
I'd bet on some kind of prehistoric "copy protection", or the oddity of the software house production process.
The most usual way was to have a short BASIC loader (e.g. 10 CLEAR 24899: LOAD "" CODE: RANDOMIZE USR 24900) saved with LINE 10 for autostart after load. The second file was a code itself. BASIC made the necessary operations: prepare the memory ...
Use of error-correcting codes was not common in home computers until at least 33.6Kbps modems and/or gigabyte-sized hard disks were available. One of the earliest consumer applications of ECC (in the form of two-dimensional Reed-Solomon codes) was the Compact Disc.
Until then, error-detecting codes such as parity and CRC were reasonably common, including ...
Due to the nature of typical errors, simpler ECCs, like Hamming, would be of no use, and more complex ECCs would be prohibitively expensive.
For example, a burst of noise will corrupt several bits in a row, and if we're unlucky, and depending on the encoding mechanism, the synchronization may be lost, thus rendering all bits up to the end of a block or the ...
It doesn't make any difference. The border colour changes between red and cyan whenever the tape loading routine detects a change in level between low and high, and this happens many times over the period that a video frame is being sent to the display (from top to bottom), producing the stripes.
Static stripes would just mean that the level changes are ...
The good news is the next few steps are easy.
Most (all?) of the MSX emulators include a "virtual tape" that can open a WAV file. openMSX does for sure. It's right in the instructions for the emulator.
I don't know enough about MSX to know if it stored programs as text or in tokenized format, but in either case, once it is loaded you can use the "virtual ...
Only very rarely because the tape hardware is completely distinct between the two machines, it’s very lightly documented and somewhat peculiar on the Electron, is fairly fixed in its functionality, the built-in routines are pretty good (including rewind and retry), and using the standard routines gives you a trivial pathway to adapting your title to ROM or ...
I'd say a rather large number of early systems did - maybe even a majority.
A quick list from memory:
(On purpose not exhaustive, only meant to show that there were many - and for a reason)
Processor Technology SOL-PC/10/20
Any S100 machine with a Processor Technology CUTS board
TA Alphatronic ...
Check this Spectrum tape interface:
A 'pulse' here is either a mark or a space, so 2 pulses makes a
complete square wave cycle.
Pilot tone: before each block is a sequence of 8063 (header) or 3223
(data) pulses, each of length 2168 T-states.
Sync pulses: the pilot tone is followed by two sync pulses of 667 and
735 T-states resp....
Those variable amplitudes looks like electronics problem like failing caps somewhere along the way (recording/playback) or unshielded too long cables or partial remagnetization or even HW bug (some recorders like ELTA have a bug in writing head circuitry that corrupted tapes a bit each time it was played ...)
the correct output should be a rectangular ...
It was a vague anti tampering thing although there was no sane excuse not to have had a tiny piece of regular Basic before it.
In most tapes using this "code loading" the actual code is usually only a few hundred bytes. It is actually just the system variables area and the Basic itself so it auto runs similar to Basic . The main erm advantages of a code ...
You're in luck — I believe that tape reading and writing is already CPU speed independent.
For reading, the 1-bit tape input is provided as the CA1 input to the keyboard VIA. The OS sets it up to generate an interrupt on its rising edge. At each interrupt it interrogates the VIA's timer to determine how long the most recent wave was.
So as long as you don'...
As to how such a device might work, look at the standard Commodore tape encoding, common to the PET, Vic-20, C64 and more. The timings actually vary very slightly between those computers when writing, but I'm going to use the archetypal timings given by The Complete Commodore Inner Space Anthology, page 97.
A program file on tape consists of:
a leader — a ...
A "perfect" result would be obtained if the stripes move at the same pace you can observe when SAVEing a program, that is, a signal with a period of exactly 2168*2 T-states, which means 807.2 Hz. (T-state information taken from https://faqwiki.zxnet.co.uk/wiki/Spectrum_tape_interface )
As the screen you see is the sampled version of what the TV is ...
The Oric Atmos (not the Oric 1) had some kind of error detection (that was broken in the first version of the Atmos ROM) which printed "errors found" (without any further details) when loading encountered an issue. It wasn't based on a checksum, but rather on detecting a proper read of each byte of the tape (if it was using parity, it's at the hardware level)...
I guess some emulators have a direct MIC input for a quick check, but I prefer a little bit longer way.
First of all, I connect the tape with the PC (in fact, I have a "USB Walkman") and make a digital copy using Audacity, at the best quality I can (48 kHz sampling frequency, 16 or 24 bits). Save it as lossless WAV (NO MP3!)
With this record, I can do all ...
I remember copying games on my ZX Spectrum 48k (one of clones). First, most games were already cracked (like "Cracked by Bill Gilbert"), so there usually were no copy protection.
The copies were actually made with the help of tape copying programs. They would load blocks into memory and then, after the cassete changed, replay everything back.
I remember ...
You most likely wrote your early experimental programs in the BASIC language, using Timex’s ROM-resident BASIC interpreter and line editor. Cassette-tape storage would have been accessed using the SAVE and LOAD commands in the interpreter’s immediate mode.
Commercial software, however, would nearly always get written in machine language — to gain the best ...
I've made a couple of discoveries after a night's sleep.
The CoCo still reads the leader length from a RAM address, but its address is two bytes higher in memory than in the Dragon 32:
0199 ** THESE BYTES ARE MOVED DOWN FROM ROM
0200 *** INIT DESCRIPTION
0201 * VALUE
0202 008F CMPMID RMB 1 18 *PV 1200/2400 HERTZ PARTITION
0203 0090 CMP0 RMB 1 24 *PV UPPER ...
Since the coco cassette interface used 1200 baud psk audio encoding in it, the tape format of the coco was 4X faster loading files from the tape and the tape files were 1/4th the size of similar files on atari and commodore systems, which used 300 baud afsk encoding.
it became common to stack multiple files on a single tape. many magazines sold software ...
The C64 didn't use the typical FSK format, but could emit and interpret flux reversals with flexible timing. Changing the baud rate was simply a matter of using different timing values with one of the CIAs. The hardware involved was exceedingly simple, and relied much more on software assistance than in many other micros.
With this flexibility, "...
The panoply of software titles needing LOAD "" CODE to be loaded, is centred around the early ZX Spectrum years, 1982-1984.
While LOAD "" also exists in the ZX81, the technique seems to be a remnant of a wide practice of writing games in assembly together with system variables, for that machine.
That allied with the platform being ...
In the absence of any technical manual:
SviWav2Cas comes with source to decode sampled SVI3x8 tapes.
openMSX can emulate the SVI machines and creates WAV files from SAVE/BSAVE that SviWav2Cas seems to understand.
Maybe save known data from openMSX in SVI mode (say a 1024 zero bytes, or 1024 &hFF bytes) and analyze the WAV files it produces?
(the CAS ...
I'm not sure if this is the right place to to mention this, but I
confirm the outputs mentioned in the question (and reverse-engineer
ones I'm not sure of) with this breakout DIN connector that I made:
This allows me to bring the signals on to a breadboard where I can
'scope them out, cross-connect them to a more standard video cable
into a monitor, and so ...
A Soviet computer Vector-06c did have a CP/M port called Micro-DOS that could work with a RAM disk only.
Cold boot was either from a cassette tape or from ROM (cannot remember, though, if the operating system was a part of the on-board ROM, or one still had to plug an external ROM cartridge - either way, the bootloader could boot from both)
The RAM disk ...
I learned there is a Danish company " B Cool Controls " that apparently are people from ex "Lanng Stelman" MEMAC, they probably have knowledge and experience of complete MEMAC, so they may help with any issues reg files and conversion