Details

You may have heard of Blitz! Basic for the Commodore 64? Well that is a compiler that takes a standard BASIC v2 listing and turns it into p-code, replacing many BASIC rom routines with custom routines to speed things up. If you ever want to know what these tokes are, I have figured them out here for you: Blitz! Basic Tokens. Here's also the disassembly of the interpreter I used for this purpose: Blitz! Basic Interpreter Disassembly Plus Tokens. 

Details

Register $1c0f on VIA2 in the Commodore 1541 diskdrive is pretty much undocumented. This blog will not go on about the inner workings of the 1541 diskdrive, there are many great resouces for that, and I assume you have read them, or will be able to read up on the matter before reading further. ;-) 

 The 16th register ($1c0f) of the VIA2 chip (which is the 6522 chip) in the drive is documented as doing the same as the 2nd register ($1c01): port A input/output register. The difference is that with $1c0f no handhaking will occur. 

By setting input latching to disabled (meaning data level on port A pins will not be buffered until fetched), register $1c0f will simply reflect the data on the pins at all times. This means that reading $1c0f will fetch the state of port A pins. Port A is a parallel system of 1 lines, each representing 1 bit state. So all 8, PA0-PA7, make up one byte. 

VIA2 is connected to the reading circuit of the 1541, and the bits read as the disk spins will arrive at PA0-PA7, actually shifted unto them. Since the ideal speed of the spinning disk is 300 rpm, there is a capped number of cycles per byte read. We know the disk in divided into 4 speed zones, because of slower speeds as you move closer to the center of the disk. To maintain roughly the same speed, the decoder speed of incoming flux changes (that are translated into bit states) is different for each of the 4 zones. Bottom line is that ideally, each bit read from the disk would take 3,25 microseconds, 8 bits then being 26 microseconds. As the 1541 has a true 1 Mhz clock speed, this means in theory every 26 cycles 8 new bits would appear on the 8 lines. 

Details

In 1985 Beyond released Mike Singleton's excellent Lords of Midnight to the unsuspecting Commodore 64 gamer. Although, the game had been released a year before on the Speccy, so I guess those not living under a rock at the time would have read magazines that reported on the conversion to other platforms. The PAL (EU) and NTSC (US) disk versions featured a fast loader, and the game loads almost instantly. Well, compared to standard Commodore 1541 transfer rates. It also features an elaborate copy protection scheme. On the PAL disk, that is. You see, Beyond apparently licensed Mindscape in the US to market the game there. Somehow Mindscape didn't get the memo that copy protection would be a must-have. So they opted out. But I digress. Back to the PAL version. Let's shed light on the copy protection (...attempt, I guess, as I played a pirated version back then). I will mark protection efforts with a 'P' and a number. For the impatient, I provide the summary already in the table below. You can also download my disassembly of everything with my own comments. 

P# Protection Description
1 Obscure the XOR line A machine code instruction (EOR) in the preloader is obscured by shifting and rotating bits in the bytes that make up the instruction
2 XOR encrypt the C64 loader The bytes of the actual loader code have been XORed with the value $66. This value is tucked away in an area of crap bytes loaded in the pre-loader. 
3 Add two sectors with checksum errors Two dummy sectors have been added that have wrong checksums
4 Use a 40 track disk Important code is stored on Track 36, normal copiers can't handle those. 
5 Sectors have custom headers Sectors on Track 36 have custom GCR headers that are looked for by loader code. 
6 1541 loader code is XOR encrypted The two dummy sectors with the wrong checksum both give rise to error code $05, and that value is needed to XOR decrypt the code loaded from Track 36. 
7* Data stored inverted Game data is stored with bits inverted. This could also be just because of fast loader speed requirements. 
8* Game start location needs to come from 1541 The 1541 loader sends over the start offset of the game, it is not stored in the C64 loader somewhere. This could also just be part of a good loader. 

The summary of the protection schemes used by Beyond in 1985. Download or read the source code!

Details

Using HVSC and smart search of specific parts in the music player for 1987 Street Sports Basketball (C64) I was surprised to see that the player went back to 1983's Mountain King. In fact, the player was found in more games. here's a list: 

; Mountain King 				1983    Beyond
; Donkey Kong					1983    Nintendo
; Track and Field				1984    Atarisoft
; WarGames					1984    Coleco Vision
; Sesame Street letter Go Round	                1984    CCW, CBS Software
; Pole Position					1984	Atarisoft
; Math Mileage					1984	Douglas D. Dragin
; Chevytech			                1985	Chrevrolet, unknown programmers. 
; Crystal Castles				1986	Unknown
; World Games 					1986	Epyx
; Street Sports Basketball		        1987	Epyx
; Street Sports Soccer			        1988	Epyx
; Street Sports Football		        1988	Epyx
; Chevytech					1988	Chrevrolet 
; The Sporting News Baseball	                1988	Epyx

I went on and disassembled the player that is in Mountain King, which I consider the first version for now and since Douglas D. Dragin is the one credited as programmer (and also on some other games in the list above) I think it is safe to assume it was Dragin that coded the player. 

In the file you can read up on the player specifics and the source code as well. 

But I will show some details in this post, and provide example programs (PRG) to run. See below. 

  1. Using serial port for pulse wave
  2. OPL2 samples and Grauw's conversion
  • You are here:  
  • Home