Crystal Castles Level Viewer

In a previous post I talked about the Crystal Castles source code. Based on this code I decided to figure out how the level data was stored and write a viewer for it. 

Even though I called this a "level" viewer that term isn't used much in the source code, but there are two other terms that are important to understand, "wave" and "city". Each distinct layout for a level is called a city, and there are 16 different cities in the game. What some games call a "level" is referred to as a wave in Crystal Castles. There are 37 waves in the game. Since there are only 16 cities, most get repeated but there is a mechanism to give them some variety which I will explain later. 

City data is stored in ROMS 136022-102.1h and 136022-101.1f with 1024 bytes allocated for each city. 

The shape of a city is defined by a 22x22 grid of box each of which can have a different height. The first block of data for each city is 484 bytes and determines the height of each box. The height can range from 0 to 127. The first byte is the block in the back corner, it then proceeds along the back row to the right, and then continues left to right, back to front. 

The next block are the 484 attribute bytes which are laid out just like the height data. The bits in each byte are as follows:

     0-1: Region - Used to selectively turn off certain parts of the city in certain waves.
    2:  Accessibility (1 = Accessible/0 = not Accessible)
    3:  Unused
    4:  Gem (1 = Gem present)
    5:  Tunnel (1 = Block is part of a tunnel)
    6-7: Priority - Used for accessible blocks that are behind other blocks. Changes the color of the sprites so they look like they are passing behind the block. I still need to do some research to better understand how this works. 

The next byte is a count of how many elevators, maximum of five, are on the level, which is followed by the elevator's data, 11 bytes for each one:

0:  Mode - 3 = Falling to the bottom/2 = Sitting at the top/1 = Rising to the top/0 = Siting at the bottom
1:  Current Mode Time - Frames left in current mode
2:  State - FF = Stopped/00 = Moving

3-4: Pointer to current mode time in RAM. This points to the current mode time, but the Mode and State bytes are also stored in RAM with it.
5: Top Height
6: Bottom Height
7: X position in pixels
8: Y position in pixels
9: Frames to wait at the top and bottom
10: Priority - Used to indicate that an elevator is behind another piece of the city

The first three bytes are moved to mode pointer address since they dynamically change during the level, which the remaining data stays static. 

The waves are stored in a table in the ROM along with the game code. Each wave has one byte in the table. Bits 0-3 determine which of the 16 cities is used for the wave, and the rest of the bytes control the "regions". As shown above each block has an attribute that can assign the block to one of three regions, or no region. The remaining four bits in the wave table control the regions as follows:

bit 4 = 0 turn off region 1
bit 5 = 0 turn off region 2    (If both regions are set off, only one is randomly chosen to be off)
bits 6 - 7 : 0 = Turn off region 3
                : 1,2,3= Turn on region 3

The regions allow for variations to cities that are used more then once. The region handling code does have a random determination for region three, but the way it is written the random state can never be reached. 

I have used this information to build a Crystal Castles level viewer. The program is written in C# and can be compiled with Visual Studio Community Edition. The source code is available here:

https://github.com/danlb2000/CrystalCastlesLevelViewer

You can step though either by city of by wave, view the accessibility attribute and turn on or off each region. When in wave mode the regions will automatically be set based on the game rules. 

ZZ-Top Legs Video

An 80's rock video might seem to be an unusual topic for this blog, but there is a videogame related mystery in it. I was a huge music video and MTV fan back in the early 1980's and I distinctly remember the 1984 video for the song Legs by rock back ZZ-Top. Part of the video takes place in a small restaurant and I do remember there being arcade games in it, but there is a detail I missed until recently, I was probably focused on things in the video!

The first game we see in the video is a classic Taito Space Invaders cabinet released in 1978. 

In another shot we see a Stern Berzerk machine which was released in 1980. You can also see the Space Invaders machine is next to it. 

The mystery comes up later in the video when you see this shot. The Berzerk machine is gone and something else is in it's place. There are no clear shots of it the video so it was a little hard to make out what game it is. The bezel on the front of the machine is pretty unique, and I remember that Atari did a couple games with this bezel design. 

I eventually figured out that it is an Atari Destroyer from 1977 a pretty rare game. 

So why were there two different games in the video? An article Santa Clarita magazine provides a likely answer. Kymberly Herrin, one of the elminator girls, says this in the article:

“We were paid really well. We all got over $2,000 for the shoot, which is so much for a video dancer.” She said the shoot “went fine” but something went wrong at the film lab. “I heard the film came out black. We had to reshoot a major portion of the video.”

So clearly one game was used during the original shoot and the other during the reshoot.

The choice of games is interesting. Both Space Invaders and Destroyer were quite outdated by the time the video was filmed and even Berzerk had been out for a few years. If this was an actual resturant it's possible that they were getting whatever the local operator had on hand instead of the latest and greatest games. It's unlikley that you would replace Berzerk with Destroryer, so even though Berzek was more prominent it is likely that it was the game during the shoot.

I think a more likely explenation is that this isn't a real resturant but instead something created for the video. The real tipoff for me in the grill area which just doesn't look realistic and way to clean.

If this was created for the video then the switch of games makes much more sense. The games aren't important to the story of the video so they probably didn't care what the game were so took whatever they could get cheaply, thus explaining the out of date games. When they did the reshoot the Space Invaders was still avaialble, but the other game probably wasn't so it got switched out. 

Valcom PagePac Door Phone Controller

 

i

I recently ran across this piece of surplus hardware from the late 90's/early 2000's. This is a Valcom model V-5324001 Door Phone Controller. Basically this device would be connected to an intercom box on a secure door and also to a phone system. When someone pushes the intercom button to gain entry it would ring a phone which could then be used to talk to the person at the door. This one has a date of 2002 on the bottom but some of the chips have date codes back into the 90s. The company that made it is Valcom which is still in existence. The company makes a range of communication products mainly focused a safety and security applications, and they still make a more modern version of this same device. 

Under the flip up front cover are the limited external controls. The dip switches are used to setup the basic configuration of the unit, but the majority of the configuration is done from the telephone handset. The left knob controls the volume of the sound coming out of the door speaker and the right knob controls the volume of the sound coming back from the door microphone. Finally there is a LED that indicates the system status. 

On the back are the connections to the system. On the left is an  RJ11 jack used to connect to a phone system and next to it another RJ11 for connecting to a telephone handset. The system can work with just a handset of both a handset and phone system connection. On the right are all the external device connections. This would have had a screw terminal block that plugged into that socket but it was missing from the unit I found. 

On the bottom is a label with all the typical regulatory information. There are also two patents listed which are quite relevant to this device:

US-5289539-A: Echo canceller using impulse response estimating method

US-5315644-A: Telephone interface circuit

In the manual there is a diagram of how the system can be used. When someone wants to enter they press a button on the intercom panel. This will ring that phone and optionally sound an alert through an external speaker which would be useful in a noisy environment. When the phone is answered it is connected to the door intercom so the person on the phone can talk to the person at the door. To permit entry the user would enter a code on the door which would unlatch the door. Alternately the system can be connected to a phone system. In this configuration the system can operate in two different ways. First, when someone pushes the door button a sound will be played through the Aux Alert Device and then the call can be answered from any phone by dialing the number of the PagePac. The other option is to configure the PagePac with a phone number that will be called when someone wants entry. 

Here is a look a the PCB inside the unit. Not surprisingly the unit has a lot of analog circuitry with a small digital section.

On the left side is the power supply. The input to the supply is from an external 12VAC transformer. This 12 VAC goes through the bridge rectifier just below the transformer and then to the regulators at the bottom to produce +5VDC and +10VDC. The 12VAC also goes into the transformer and is stepped up to around 95VAC and then passed through two more bridges to produce two 24VDC outputs. I assume these higher voltages are for the phone circuitry since normal line voltage is 48VDC and ringer voltage can be up to 100 VAC. 

Towards the lower middle is the analog phone circuitry, the small isolation is transformer is a prertty standard component of a phone line interface. The left three relays appear to be for controlling the phone line and the right relay appears to be connected to the door button inputs. Not sure why a relay would be needed for that. There are a couple un-populated components, a second connector, two relays and and support circuitry. The first empty relay spot goes to the un-populated connector and the second appears to go to the audio amplifier. I assume there was another model that had this additional hardware but I haven't been able to find any reference to it. 

In the lower right corner is the audio amplifier probablty to drive the door speaker. This is built around a TDA1515BQ - 24 W BTL or 2 x 12 W stereo car radio power amplifier.

Finally, in the upper right is the digital control logic. The system is built around a Z0861108 microcontroller. This is a Z80 microprocessor with RAM, ROM and IO devices built into a single package. Most of the other chips around the processor are just general logic chips but there are a few interesting ones:

X24C44 - 256 Bit Serial Nonvolitile Static RAM. This is used to store the system configuration done through the phone keypad.

MT88700E - DTMF Decoder. This is a phone touch tone decoder which would be used to decode the keypad presses needed to configure the ssystem,

PCD3312C - DTMF Generator. This is a phone touch tone generator which would be used by the system to dial a phoner number.