- Details
- Written by Mr.Mouse
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
- Written by Mr.Mouse
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!
Read more: Beyond C64 disk copy protection (Lords of Midnight), 1985
- Details
- Written by Mr.Mouse
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.
Read more: SIDiscovery #1: Douglas D. Dragin music player (1983)
- Details
- Written by Mr.Mouse
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
Page 1 of 3
