5. The PlayMobile prototype

5.1 Prestudy

We started this project by looking for information about the Gameboy system on the Internet, and found a lot of information. Then we started to think about how we should connect our hardware to the Gameboy

 

5.1.1 Serial port vs. cartridge port

There is basically two ways of connecting a Bluetooth module (or any other extra hardware) to a Gameboy, first through the serial port, and second through the cartridge port. The cartridge port solution has the best performance, but requires more hardware so it will be more complicated and also more expensive. Connecting extra hardware through the serial interface is easier and much cheaper, but uses a lot of processor power.

Standard games use the serial interface, so we decided to try to use the serial interface to be able to run standard games.

 

5.1.2 Measurements on existing games

It was not sure that it was possible to run standard games as we did not know what they sent to each other or how the interface worked, so the first task was to make measure communications between two Gameboys.

First we searched on the Internet for information about the link port, and found out that it was built as a shift register as described in chapter 3.2.6. When we saw the shift register structure we soon realized that it would be a big problem that data was transferred in both directions simultaneously without knowing which one of the Gameboys that would be clocking it. To replace this we would need a system with extremely high transfer speed and with no delays. Impossible of course, but there might be other ways to sole this if one knew what data was sent. With a PC and a simple circuit connected to the parallel port, we could listen to the communications so we built a measurement system to listen to the communications using a simple program written in Visual C++.

Figure 5.1: Schematic over the serial communication adapter.

Figure 5.2: The serial communication adapter built on a breadboard.

  

When we saw the data sent between two games we saw that they just sent a copy of the button states, and some synchronization in the beginning of the game. This meant that we might be able to delay the data one transfer and it still would work. With our communication adapter we tried to delay the data one clock cycle, but we did not get it to work. With our communication adapter we also tried to look at the communications between two pokémon games, but they looked very complicated.

5.1.3 Prestudy results

When we did not get the games to work with the delays and the dual direction clocked shift register seemed weird to us, we decided to try the cartridge solution instead. When we could not run standard games on the serial interface we thought that we would be better off with the high performance that the cartridge solution could offer.

 

5.2 The cartridge solution

Our idea with the cartridge solution was to add a circuit that was plugged in between the game cartridge and the Gameboy. The RAM should be (time) shared between the CPU and the Gameboy to minimize transfer time. With this more complicated design we also planned to include a camera. With this, the players could see each other while playing, and also the prototype could be used as a videophone.

5.2.1 System overview

This system should have its own CPU and RAM, with the RAM shared between the Gameboy and the external CPU. The RAM would be into the memory space of the Gameboy cartridge RAM. Commands should be written to RAM by the Gameboy and be read by the external CPU that would read and perform them. Writing data to RAM is an operation that is quite fast. One byte is written in just a few clock cycles, and all data can be written to memory one big chunk, making the communication very fast. Figure 4.1 shows the system we wanted to make.

Figure 5.3: System overview.

The CPLD is listening to the communications between the Gameboy and the Cartridge. When the CPLD is accessing RAM bank 128..256 in the cartridge, then the cartridge is disabled and the RAM memory is accessed instead. There is a status byte in the CPLD that can be read both by the CPU and the Gameboy simultaneous, used for status bits needed, as the CPU canít use the memory when the Gameboy accesses it.

The CPU is an Atmel [14] ATS8115 by Atmel. It has a built in UART, in this case used to communicate with the Bluetooth module

 

5.2.4. The memory

The memory is used to store commands and data. The data is game data transferred between the Gameboys and also image data (from the camera) that can be transferred directly over the Bluetooth link or to be read by the Gameboy. As mentioned in the overview, the memory can be read both from the Gameboy and the CPU, but not simultaneously, the CPU selects the owner of the memory.

5.2.5 The CPLD and memory decoding.

The CPLD handles reading the GB memory bus, controlling the internal memory bus, sharing memory, and sample data from the AD. As it is a reprogrammable chip it is quite easy to add extra functions if needed. See Appendix A.1 for the VHDL source code and constraints file.

 

5.2.5.1 XC9500

We chose a chip called XC9500-108 [19] from Xilinx. [13] It is a high-performance CPLD providing advanced in-system programming and test capabilities for general-purpose logic integration. It is comprised of six 36V18 Function Blocks, providing 2400 usable gates with propagation delays of 7.5ns.

Figure 5.4: X95108 Architecture.

 

5.2.5.2 Programming hardware

To program the chip we used a very simple in-system programmer that either can be bought from Xilinx or built according this schematic:

Figure 5.5: Schematic over the programming hardware.

 

5.2.5.3 Software tools.

We wrote the code for the CPLD in VHDL, a hardware describing language similar to Pascal. To be able to program the chip with this, we needed a compiler. There are many hardware compilers available. Many are expensive but we chose the Xilinx Web Pack, a suite of development tools available for download from Xilinx web-site. This system is quite easy to use, works quite well, except that it can not handle too many levels of statements, but in a small system like ours it is enough.

 

5.2.5.4 Tasks to be performed

The most important task of the CPLD is to decode the Gameboy bus and control the sharing of the RAM. The RAM is mapped to the external RAM address at page 0x80..0xBF so the Gameboy actually see the PlayMobile as a part of the cartridge. Only one unit can access the RAM at one time, so when the RAM is used by the Gameboy, the CPU uses the internal RAM to buffer incoming data. When the internal RAM of the CPU gets almost full, the CPU tells the Gameboy this by setting a bit in the CPLD that can be read by the Gameboy. By setting a bit in the CPLD the Gameboy can send information to the CPU when the CPU has access of the RAM.

Since we had a big nice programmable CPLD we thought that the external latch, for the CPU to store the most significant byte of the address, could be placed inside the CPLD. This could easily be done since we had all address and data pins already connected to the CPLD, so all that was needed was one extra pin for the ALE signal and a few lines of VHDL code.

The image sampling code that should be placed in the CPLD was never written as we ran out of time. This code should be a simple state machine that reads data from the AD and stores it in the RAM and also generates the appropriate control signals for the camera.

5.2.6 The AVR processor

We chose the AVR AT90S8515 [17]as our CPU, mainly because it has a built in UART, can address external RAM and has both built in RAM and Flash ROM. It is based on RISC architecture with single clock cycle instructions. See Appendix A.2 for the AVR source code.

 

5.2.6.1 Overview

Figure 5.6: Architecture of the AT90S8515.

 

5.2.6.2 Software development

In the cartridge solution the AVR needed to communicate with both the CPLD over the memory bus and the Bluetooth module using the built-in UART. To be able to run these two communications simultaneous, we made the serial communications using interrupts, with two ring buffers as temporary storage. The main method is a state machine that reads commands from the memory that the Gameboy wrote and then performs the commands. Due to hardware problems this was never finished. All software for the AVR was made in a specially adapted version of GCC, so all software could be written in pure C, making the development time much faster than if it would have been written in assembler.

 

5.2.6.3 Programmer

The programmer hardware to program AVR processors is very simple, just some wires connected to the printer port of a PC. See Figure 5.7. We used this with the software BA1FB by Jerry Meng, which is quite simple, but works nicely. The only downside with the software is that wont run in Windows NT, so we had to use Windows 98 when programming the AVR processors.

Figure 5.7: Schematic over the programmer.

 

 

5.2.6.4 The Bluetooth interface.

The built in UART is used to communicate with the BT module at 115.2kBps. This is according to the RCMP protocol described in chapter 4.4.2. In the AVR there is interrupt driven code to send and receive data to a send and receive buffers. These buffers are organized as ring buffers, and are written and read by the main loop.

 

5.2.6.5 Memory sharing

It is the CPU that selects who is the master of the memory. When the Gameboy want to use the memory it sets one bit in the CPLD that is transferred through one pin to the AVR. During the mainloop the AVR reads this pin, and when it gets the request for memory it leaves control to the Gameboy as soon as it has finished the current operation. When the Gameboy reads the status bits in the CPLD, and sees that it can use memory, it starts to use the memory and when finished it tell the CPU that it is finished. During the time when the Gameboy uses the CPU it possible that the CPU will get data in from the UART, which normally would be written to the RAM, that currently is in use. To solve this problem, the internal memory is used as a buffer. With 128 byte of buffer, this buffer last for at least 10ms, but then it overruns. To prevent overrun, there is a warning bit in the CPLD that can be read by the Gameboy that can be set by the CPU to inform about that the internal buffer is 75% full. When the buffer is full, the CPU makes a hostile takeover of the memory, so from the time when the warning is set the Gameboy has 2.5ms to finish its current operation.

 

5.2.7 The Bluetooth module and CODEC

The Bluetooth module we planned to use was the ROK101007 that is controlled by a standard RS232 interface and has a PCM to communicate with a Codec to connect audio input and output. The Codec can be any standard Codec using PCM interface. Audio is used for audio transmissions over Bluetooth and might be interesting if one wants to let the players communicate with each other while playing. We had no time to complete this, but if you want to know more about audio over Bluetooth, then you could read the Bluetooth specification.

5.2.8 The AD converter and camera interface.

More fun than just audio would be if the players could see each other when playing. This could be done if a camera is connected. Of course, this image must be small so it does not disturb the game, maybe 16x16 pixels. Such a small image could probably be sent with a couple of frames per second.

There are a couple of different kinds of cameras that can be used. One could use a standard PAL (or NTSC) camera with composite video out. This is quite easy to sample using an AD converter if one only wants a monochrome signal. If color is needed it requires a little bit more complicated hardware, so if color is wanted it is best to use a camera with integrated DA. For a cheap product, the best solution is a diode array camera such as the one Nintendo is selling for the Gameboy. Diode array cameras are cheap, but produce lower quality pictures, but here quality is not the most interesting solution so it is probably the most realistic solution. The diode array usually has their AD converter externally. Some cameras require different control signals, such as clock signals and shutter time settings etc. These signals are generated by the CPLD together with the CPU, but depends on what camera is used.

One interesting detail about the camera and the cartridge solution is that if the Gameboy is removed and some of the software in the AVR is changed the same system could work as a stand alone camera (if it had some batteries).

 

5.2.9 The design and manufacturing of the PCB

We made a test system with a simple double-sided PCB. It was designed by using a simple free PCB program called Express PCB (see screenshot in Figure 5.8), downloadable from www.expresspcb.com. This program does not have schematics or schematics verification, so there were some small errors in our PCB as it was a little too complicated for us to succeed with the manual connection check. These problems were easily corrected by modifying the PCB with wires.

Figure 5.8: Screenshot from Express PCB showing the cartridge test PCB layout.

 

Ericsson in Lund has a small chemistry lab where it is possible to make simple PCBs by using UV exposure and etching.

The CPLD is in a 100-pin QFP package, which is smaller than we could etch with the equipment available, so we used a converter PCB that made it easier to work with the CPLD.

5.2.10. Problems

We made some tests with the system, and found out that most of it worked fine (after a lot of bug fixes and a couple of small hardware modifications). But there were some problems with the memory sharing. Both the AVR and the Gameboy could read and write memory without problems, but when they should communicate by share the memory there were not 100% of reliance, which we needed to be able to use our solution. After spending a lot of time investigating this problem, we passed the deadline we had set, which was that we should be able to communicate with the Bluetooth module. In the end we found what might be the problem. It could be that we used the circuit in Figure 5.9 for the RAM control signals, but this could be a little bit slow. A better solution would be to use the circuit in Figure 5.10 that is faster and more reliable.

Figure 5.9. Two drivers on the same wire, use two tristate drivers and pullup.

Figure 5.10 MUX selects active line.

  

5.2.11 Results

As mentioned in 5.2.10 we had some problems with memory and as we had crossed the deadline of getting the system to work properly, we decided to stop developing the Cartridge solution and try the serial solution instead. This might seem a little bit extreme, but when we worked with the AVR we saw the SPI interface that looked very much like the one in the Gameboy, so it might be easy to use the SPI interface in the AVR to connect to the Gameboy serial port. The time we put into developing the cartridge solution was not completely wasted. Even though we stopped the development, our results had shown that it was possible to connect hardware quite easy to the cartridge port with the method we used. It would just take some more time to develop, as it was more complicated than we first expected to deal with shared memory. A photo of our test system can be seen in Figure 5.11.

Figure 5.11: Our cartridge solution test system.

  

5.3 The Serial port solution

As we ran out of time with the cartridge solution, we started to develop the serial port solution. During the development of the cartridge solution we had come across the SPI interface and thought that it could make things easier.

5.3.1 The Serial solution overview

Instead of connecting our prototype to the cartridge port, we wanted to connect the Bluetooth module to the serial port of the Gameboy. With no UART in the Gameboy, this is a little bit difficult, so to solve this we used a converter circuit based on an AVR AT90S8515. (See Figure 5.12) See Appendix B.1 for full schematic.

Figure 5.12: Block schematic over the Serial solution.

5.3.2 The SPI interface

The SPI interface is two shift registers feeding each other like quite similar to the Gameboy serial interface described in 3.2.6. The main difference is that the clock signal has only one direction.

Figure 5.13: Picture showing how the SPI interface of the AVR is used.

 

With only one direction of the clock signal there is a need for two different implementations of this interface, but for the AVR a special register in the processor selects this.

If the interface is selected as master, one only need to write one byte to the shift register to send it. (The interface will automatically generate the clock signal). When the transfer is done, a bit in the SPI status register will be set and the input data is available when reading the shift register, so the processor can do other tasks meanwhile it is waiting for the transfer to complete.

Figure 5.14: Block schematic over the built in SPI interface of the AVR processor.

When the interface is set to be slave, it acts almost the same way, except for that the clock is not generated internally, it is taken from the clock pin. When the byte has been sent and the new byte is available, a bit is set in the SPI status register.

For both master and slave mode it is possible to make the transfer complete bit in the status register to generate an interrupt, so it will work in the background while another program is running.

 

5.3.3 The protocol

When standard games are communicating, the direction of the clock is usually changed depending on the data transferred. In our system we chose to let the Gameboy always to be master to be able to use the SPI interface. When sending data, the length is first send and then followed by the data. The data is dual directions, so both sides send their length and the longest length set the number of clocks needed. There is no possibility for the AVR to initialize a transfer, so the Gameboy has to ask the AVR if it has any bytes to send. This is done by sending data 100 times per second using an interrupt, even if there is no bytes for the Gameboy to send it still initializes a new transfer just to check if the AVR has bytes to send.

 

5.3.4 Software

The software is using the same interrupt driven UART software routines with ring buffers for storing data. In the main loop the AVR just waits for one byte from the Gameboy and when it gets it, it treats it differently depending on the current state. If it is the first byte in one transfer, the length is received and sent by reading and writing to the ring buffers. In the Gameboy there is a serial driver like the one in the AVR to send and receive data. To make sure the AVR sending buffer is overflowing, an interrupt make sure a new transfer is initialized 100 times per second. See Appendix B.2 for the AVR source code and B.3 for the Gameboy Bluetooth drivers. There are also some various system routines in Appendix E

 

5.3.5 Development tools

This solution is using the same CPU as the cartridge solution, so it was natural to use the same development tools as for the cartridge solution. (See chapter 5.2.6 for a description of the CPU and related tools). The PCB is also made using the same tools and methods like the ones used for the cartridge solution.

 

5.3.6 Performance

When sending data at 115.2kbit/s, there are up to 11520 interrupts per second. Each interrupt requires registers to be stored and a lot of code to be executed, resulting in a lot of work for the processor. In other words, the system will easily get overrun and crash using the serial solution. In our games, we saw that the system became very unstable when sending a lot of data. What we understand from these tests is that the serial solution we made for the Gameboy color would not be possible to use for a commercial product, the cartridge solution would be better. (Read more about the future of PlayMobile in chapter 7)

 

5.3.7 Results.

The serial solution turned out to work, but as we suspected it was too much for the Gameboy CPU to handle. If the Gameboy had a built in UART, these problems would not occur. The hardware we developed for this solution can be seen in Figure 5.15

Figure 5.15: Our serial solution test system.