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. 

Details

So I wanted to generate an audio wave using the SERIAL port of the Commodore 64. Since the lines ride at 5 V DC, but can alternate between 0V (signal on) and 5V (signal off), pulses should be possible. I wondered if I could modify the waves further, by changing the rise time. But that was not possible. 

Using ATN line to generate pulse waves

See picture from my oscilloscope above. When the C64 is idle, the ATN line stays at 5V. If we want the attention of devices connected to the serial port, we do this by dropping the line to 0V. In my code I made that the default situation. So "do nothing' in my case means keep the ATN line at 0V. Then, when wanting a pulse-wave, "let go" and the line will rise to 5V DC, but at the cost of a peak, as you can see. The pulse-width is 50%, as you can see, so at 50% of the period, I drop the line back to 0. Again at the cost of a peak, before it goes back to 0V. In this instance above, the peak-to-peak voltage is a total of 8.6. 

The rise time (or drop time) is very fast. I am unable to modify it with software. It is within microseconds. Even if I set it to go to 5V and follow immediately with a call to drop it to 0V, the peak is there. 

I had a plan to feed that back to EXT-IN on the SID, to passively mix with the other three channels, but that is impossible with this Vpp level. The recommendation is for any EXT-IN signal coming in the SID, to ride at 6 DC, but only at 3 Vpp. 

With 8.6 Vpp I am nowhere near that max limit, so let's not do it!

Example of music with SERIAL port ATN pulse wave

Nevertheless, it is possible to just hook up the pulse-wave to an audio set and have that extra channel. As a proof of concept I simply modified my PULSE-FX player and have the player not use gate on/off to generate the pulse wave on a channel, but use the SERIAL port ATN line low/high for the wave. 

Check the MP3 of the result (serial port pulse wave at left channel): 

http://c64.xentax.com/media/ATN-PULSE_XNTX.mp3

 

Details

To play 8 bit samples on an OPL2 there is a simple technique to use the test bit to freeze the voltage output from the chip, which can then be controlled by setting the lower 8 bits of the frequency to an 8-bit sample value. 

The original trick was written by Mitsutaka Okazaki.
 
Some background info from Grauw, who helped me get this trick to OPL2. 
 
Details on TEST register and the undocumented bit 2 function
(if 1, resets (and holds, while active) the PG count for Car/Mod at 0 )
 
You can in fact simply write an 8 bit unsigned sample to a channel when the test bit is set (after a bit more preparation) at a proper sample rate and you will hear the sample play. However, the voltage is taken from the sine table on the chip, and that has a slightly different output than you might expect if you were dealing with a linear type of relationship with your unsigned value (you know, $80 being silence, 0 most negative output and 255 most positive). 
The result is that samples may sound slightly different, a bit more "sharp". Grauw took a look at the outputs and constructed a table that accounts for that internal chip look-up. 
 
Here I compare the two methods. The fast, don't look up, just output the sample method, and the Grauw's table method. (Of course, you can convert your samples using Grauw's table before and then still have a fast no-look-up method, but it takes an extra step. 
 
I take a simple approach, play a sample that goes from 0 to 255 and then back to 0 in steps of 1, and that 4 times. I do it without Grauw's conversion and with that conversion. 
 
 
The picture above illustrates how well Grauw's table is doing the trick. Note that the non-converted left wave is a bit louder, but not in proper phase. Where you would expect a maximum (positive or negative) at end of each half of a period, this is the case only after conversion, you see two quarter sines (inverted). So Grauw neatly matched it to the quarter sine output table on the chip. :) 
 
Will you hear a lot difference in the samples? Probably not, especially if you don't know how it should sound. But to the trained ear, there is a slight difference. Nothing to worry about. But we do want things to be perfect. So great work, Grauw! 
 
 
 
 
  1. SID DIGI Play Routines
  2. YM3812 (OPL2) register write timing on the Commodore 64
  • You are here:  
  • Home