Tag Info

The Apple II reads disk tracks as a continuous stream of bits. To make sense of the data, it's necessary to figure out where individual bytes start. This is done with self-sync bytes. Standard self-sync bytes are FF, followed by two "invisible" zeroes: byte 0 ** byte 1 ** byte 2 ** 11111111 00 11111111 00 11111111 00 The Apple II will read bits ...

These programs usually had a mono-color background with very little text. By setting the color of the screen as "black ink on black paper" or "white ink on white paper", it is possible to relocate the whole software in video RAM and hide it from view. These programs were tiny asm utilities (they used 1 or 2 kilobytes or RAM) which copied themselves to ...

There are multiple techniques used by tape copy programs to be able to copy large blocks of data. By large we mean close to the whole RAM capacity (48 KiB) or even more! Using maximum of the available RAM ZX Spectrum 48K (and ZX Spectrum+) has 48 KiB (49152 B) of RAM from which 6 KiB (monochrome pixels) + 768 B (colour attributes) are being used for video ...

If I recall correctly, there were lots of variations to implement this scheme. Besides embedding characters in the listing that would reboot, or clear the screen every so often, a particular one I remember worked roughly like this: The listing only consisted of a single CALL. The internal structure of the BASIC program was carefully changed so the listing ...

In theory, it is fairly simple duplicating a tape. The problem with analog tape-to-tape copies is that sound quality lowers and spurious noises are also copied and more are generated into each new consecutive copy generation. It did not contribute to improve the situation, that later tape copy protection methods/turbo loaders (SpeedLock, Alcatraz...) were ...

There were multiple ways of protecting the program, including: order of line numbers could be altered to produce: circular listings; missing lines; out-of-order lines; out-of-bounds addressing; the "resume" flag could be set such that any command could cause the program to run again; the start-address for the program could be altered so that another (or ...

The assertion that 4x4 is faster is false, it's easier, yes, but not faster. RWTS18 could read the entire track in one revolution so it is the fastest. I know that 4x4 and 6x2 were also capable of reading in one revolution but not sure about 13 sector... don't think anyone ever tried. :-) So RWTS18 gave the game developer faster speed, more space with the ...

No, you won't need any 'HiFi' like recorders. After all, these were the very same devices you also used to record your own programs and/or data. While copying from recorder to recorder does always carry a loss in quality, this is of no big influence on a first or second degree copy (*1). The most important factor is volume. It's much the same as when ...

"Weak bits" are a means of copy protection that generates areas on a disk that read back as random values, without the floppy disk controller actually detecting an error. When copying such a weak bit to a new disk with a standard FDC controller, it will end up as a distinct 0 or 1 depending on the random state that it was read in and never change as long as ...

SYS is the BASIC instruction to execute a routine written in machine code. There is no more BASIC code to view, the entire game is implemented as a machine code program, and the BASIC only exists as a stub to make it easier to load and run. The best approach to viewing what the code actually does and potentially being able to restore your table (if it is ...

Secure? No, but much more so than protected BASIC programmes on tape, which merely had a single field set in the tape header that triggered the run once then NEW behaviour. It would definitely have slowed down most bedroom crackers, but if you had a sector editor, a printer and a good eye for detail, you could probably work it out quite quickly. As Ken has ...

Less disk swapping, but also faster loading. Much of the performance improvement in Apple II fast DOS implementations (including ProDOS) was due to less latency between reading sectors - and this happens naturally (in a game) when there are more sectors per track and you read them all. By the time you've read a sector and finished processing it, you arrange ...

Assuming a program consisting of a unique big block of 49152 bytes (the whole RAM space). A routine that may be used for a copier to copy this block would sit at the top memory, say at address 64000 along with the stack. Prior to that, the copier asks the user to start loading the big block, just to get the flag byte (which may be different than 255). This ...

Nibblers that are utilizing opencbm on a PC need a faster-than-stock connection to read the GCR encoding in real time. There are a couple of solutions, the most common of which requires a ZoomFloppy. To nibble from a 1541 requires a parallel port. 1571 drives are much faster due to better hardware, allowing ZoonFloppy to nibble over serial.

I'm not familiar with that system, but if users had the ability to protect their own files, then no it was not secure. If you can protect your own files (with known contents) then you have easy access to both the protected and unprotected file. XOR has always been a very common encryption method, so it would have been natural for a curious individual to ...

A lot of Commodore 8-bit computer games used a disk that had random-access files on them. This means they were written directly to disk blocks, not via a program, sequential or relative file, which are the three ways Commodore DOS officially supports files. Random files are protected by having the programmer manually mark the blocks as being used. This ...

No, it wasn't considered really secure. In fact several programs existed at the time, including small "type-ins" available in magazines for removing that exact protection. There are some of them listed in the CPCWiki, which are no longer than 3 lines of BASIC (well, sort of) code. I'm not entirely sure when the first such program appeared on a magazine, but ...

It's now well publicized how people used to record programs for their machines, from their radio, which were transmitted by radio-stations . So maybe you could have played the program on an audio-speaker, and then used the microphone on a cassette-recorder to copy the tape. That may have bypassed the flutter problem . What about the volume level when ...

As Jules said, SYS is the BASIC instruction to execute a routine in machine code. Very much like GOSUB. USR is the equivalent of DEF FN. There are 2 ways in which machine code is loaded It is saved with the code. This is great against piracy but it is a pain to modify. Also any minor mod you make might wipe out the assembler. There is a bunch of data ...

Something to consider is the length of the keys. 13 plus 11 bytes gives 192 bits, while 128 bytes is 1024 bits, so this scheme isn't even one fifth as secure as using 128 unrelated bytes. If someone had access only to the encrypted files, the repeating nature of the keys would give an advantage as it adds a pattern that can be detected. The entropy of the ...

A parallel cable helps to copy special formatted disks with an original drive connected to a C64 or even a PC. The problem is the limited RAM (2 KB) on a 1541 that prevents to store a full track keeping all details of the format. With a parallel cabling it's possible to transfer on the fly of a full track. An example for such a picky format is GEOS with its ...

For PC connectivity you win absolutely nothing. Various devices that allow connecting a 1541 (and others) to PC will still talk IEC to the drive, regardless whether they use USB, serial or parallel to PC. There are two devices that are praised for their data transfer abilities - ZoomFloppy and KryoFlux - the former uses IEC as well but has optional ...

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 ...

The Commodore 64 was somewhat unusual in that off-the-shelf tape recorders didn't work with it, so you were forced to use the Commodore Datasette unit or later clones thereof. Also tapes copied in a normal twin-deck machine wouldn't load using the Datasette. One solution was a hardware device that plugged into the cassette port and to which two Datasettes ...

I had an Amstrad 464, which has an internal tape deck. It was quite common to copy tapes using a twin tape deck. Most portable 'ghetto blasters' in the mid 80s had two decks. Normally only one could record. Some even had a fast copy mode where both would run at double speed. Game copies would usually work for the first couple of generations, but then would ...

Perhaps you're remembering "copyright trap": small and inconsequential errors acting as a fingerprint. A product with the same errors must have been copied; if there's no licence, some kind of infringement. I have heard of software with this kind of thing, but don't know of any spreadsheet software. Also some map copyright cases. Related idea is that of "...

Although I've only seen such things in games rather than in professional software, the same principle could apply to both: if the program is not altered, it will either behave correctly or refuse to run at all, but attempts to alter the program to bypass the protection will cause other parts of the program to occasionally malfunction in possibly-subtle ways. ...