ECE 476 Final Project - Wonderswan Development Cartridge

• Arbi Zadorian (asz6)
• Zhengyun Zhang (zz25)

Introduction

• Short Summary
  This project allows a Wonderswan developer to upload 64 kB of code/data and execute it on real Wonderswan handheld gaming hardware.
• Long Summary
  
  • We started by opening up one of our Wonderswan cartridges and identifying the various chips and circuitry found inside. We found the main ROM chip, and guessed that it would follow standard JEDEC pinouts for programmable ROM chips of this nature. Having a nonstandard pinout would've increased production costs. We then mapped the pins on the cartridge edge connector to the pins on the ROM chip, so we had a rough idea of what type of chip it was and how the address and data lines were connected.
  • After verifying possibility of success, we proceeded to build a memory programmer. Since the Wonderswan uses a 16bit wide word data bus, we purchased two SRAM chips, each 8bit wide. We then chained these together to provide a total of 32768 16bit words over a 15bit address space. Since the Wonderswan and our MCU operated on different voltages and we didn't have enough pins on the MCU to directly address all 31 lines and still be able to communicate over a serial line, we built a demultiplexer circuit out of 74AHC logic family chips. This allowed us to buffer out the various lines over time, and also allowed us to drive a 3.3V output level chip with 5V signals.
  • After the hardware was built, we programmed on the MCU a XModemCRC compatible transfer program so that we can both upload and download from our "cartridge."
  • In order to interface with the Wonderswan, we etched our own board using a laser toner transfer method, and trimmed it so that it fit into the cartridge slot on the Wonderswan. After everything was attached, we realized that the Wonderswan had a hardware handshake to check for valid cartridges. A valid cartridge has a custom chip, which we could not reproduce. Thus, we tricked the Wonderswan into accepting our cartridge by booting into its preferences mode (which needs a cartridge to load up but doesn't run off the cartridge), and then inserting our cartridge and letting the mode continue to normal play.

High Level Design

• Origination of Idea
  
  • The Wonderswan was a handheld console that gained a decent amount of popularity, but eventually died because the GameBoy Advance came out with a plethora more games, backed by video game superpower Nintendo. The Wonderswan used a popular architecture, the x86, for its processor and thus there were many tools available to compile compatible code. Eventually, Qute corporation released a development kit it called the WOnderwitch, which allowed users to create their own Wonderswan games. The problem with using something like this was that program size was severely limited to around 64kB, and one had to use the built in software interrupt driven functions for interacting with the hardware. This limited the versatility of this device. Furthermore, the Wonderwitch went out of production along with the Wonderswan, and current fetching price is around $150-$200, which is approximately 2-3 times the cost of a new Wonderswan.
  • In order to further development in this area, we decided that it would be a neat idea to reverse engineer how a Wonderswan cartridge would work, and build our very own cartridge with which to upload and test programs with. The API for the Wonderswan has been mostly reverse engineered, but there are still quirks that are unknown. Hopefully, by creating a programmable cartridge and by publishing the specs for the cartridge format online, we can encourage further development on this dying console.
• Logical Structure
  
  • The program on the MCU essentially controls the programming of the 2 SRAM chips in our circuit. Its output is sent through 4 octal buffers so that we can get a 3.3V signal going to the SRAM. It also has control signals which allow it to separate the buffers and itself from the SRAM when it's not using it. This allows the Wonderswan to interoperate with the circuit even with the MCU running.
  • The hardware is essentially in three pieces. One piece is the set of buffers which act as a demultiplexer for the limited number of pins the MCU has. It also doubles as a level converter to output 3.3V instead of 5V. The second piece is the set of SRAM chips. These do the actual storage of program information for the Wonderswan. The last piece is the cartridge PCB, which is essentially a connector to allow the SRAM to connect to the Wonderswan hardware.
• Hardware/Software Tradeoffs
  
  • The MCU wasn't fast enough to fetch instructions for the Wonderswan in real time, because the Wonderswan can fetch at a maximum rate of two bytes per 3.072 MHz clock tick. Furthermore, the MCU did not have enough storage to even hold one bank (64kB) of Wonderswan programming. Thus, we decided to delegate this functionality to a set of SRAM chips, which are faster (120 ns speed, which is like 2 cycles on the MCU).
  • Instead of having control signals feeding straight into the buffers and SRAM, we decided to use hardware inverters. The inverters are tied to a default state if the MCU is not on, so that we do not keep certain inputs floating. Furthermore, these default states represent a "safe" state for the buffers, so in these states the buffers have their output turned off and the SRAM is in read mode. Lastly, an input of 0 to these inverters generate the safe state, so the MCU can boot up and accidentally send a 0 to all the control signals and still remain a safe state.
• Relevant Standards
  
  • XModem CRC
    We implemented a scaled down version of XModem CRC to the point that we could transfer data back and forth between the computer running HyperTerm and the MCU.
  • JEDEC Standard No. 21-C
    The MASKROM on one of the Wonderswan cartridges looked like it would follow the JEDEC word-wide EPROM standard for pinouts. We've verified at least the lower 15 bits of address, the data bits and the output enable lines to be correct.
• Intellectual Property Considerations
  
  • As for intellectual property, it may seem at first that we are violating the DMCA. First, we are not sure that obscurity of hardware specifications is an actual protection and we do not know of any actual protection schemes in use. The valid cartridge detection scheme does not seem to be a protection mechanism and only seems to be a validation mechanism to insure that connections to the cartridge are correct. Furthermore, we are not creating a device to bypass this, since the functionality is already in the Wonderswan to bypass it. We only discovered this functionality and thus did not create it.
  • A recent exemption has also been added to the DMCA by the Library of Congress on October 28, 2003. It states that there's an exemption for

    "(3) Computer programs and video games distributed in formats that have become obsolete and which require the original media or hardware as a condition of access. A format shall be considered obsolete if the machine or system necessary to render perceptible a work stored in that format is no longer manufactured or is no longer reasonably available in the commercial marketplace."

    The Wonderswan is certainly obsolete since Bandai no longer manufactures it.
  • Another question into intellectual property may be the fact that users are using the device to play games that they do not own. First, it is impossible for the user to obtain a game image using our project since we only interface with the Wonderswan, and not with the cartridges. Second, the users are breaking the law if they download illegal ROM images from the Internet for games they do not own. Lastly, our cartridge only holds 64kB, which is not enough to run any commercial games but will run demos released into the public domain. Therefore, this would only help in more Wonderswan units being purchased from excess stock that has been unsold. Furthermore, our project requires a valid cartridge to be in possession of the user.

Program/Hardware Design

• Program Details
  
  • The main program consists of three parts. There is an XModem library file we wrote, a memory interface library file we wrote and then the main programmer file. The entire program was written in C.
  • The XModem library implements two functions: xmodem_send() and xmodem_receive(). Each function takes a pointer to a function. The xmodem_send() function will call its argument whenever it needs 128 more bytes of data to send. The xmodem_receive() function calls its argument when it has correctly received a packet to process the 128 bytes it just received.
  • The memory interface functions consist mainly of memwrite() and memread(). There are also two help functions: writeaddr and writedata() to help with setting the buffer values. Delay timings had to be inserted into the code to allow the buffers and memories to properly record a value. Timing is complicated by the fact that we have pulldown resistors on all CMOS inputs and may have stray capacitances somewhere.
  • The main program boots up a menu over the serial connection, and allows the user to either set or clear the memory with a certain pattern, upload a file, verify a file, download a file, read a word or write a word. Verify, download and upload all use the XModem protocol, but with different arguments.
    • Verify uses xmodem_receivewill simply read the SRAM and compare it with the value it received, causing a retry in XModem if it fails.
    • Upload will receive 128 byte packets, and read the SRAM. It will only write to the SRAM if the read data differs from the data to be written. It then checks to make sure the data was written correctly.
    • There is a fast upload function which will just overwrite all the memory addresses without checking.
    • Download will read the SRAM in 128 byte chunks and deliver them to the xmodem_send function to send to the user.
    • The code can also clear the SRAM by looping through all the addresses and writing a default value (such as 0xff). Furthermore, it can fill the SRAM with a pattern (typically ~addr).
    • The code will use gets() to read arguments for the read and write word functionality and then will proceed to call memread() and memwrite() as necessary. The word write function will pause after setting the buffer values so that it can be measured. After a key press, it will continue and write the word.
  • A tricky part of the code involves timing issues with pulldown and pullup resistors and the overall speed of the external chips. Sometimes data will write to the wrong place, because the address buffers load up the wrong value. We think it may just be an idiosyncrasy with our buffers. We accounted for this problem by having our upload program only write when necessary, to reduce the number of erroneous writes. While not a failsafe solution, this ensures that we have a good chance to uploading any image by simply continuing to upload a few times.
• Hardware Details
  
  • The Mega32 MCU is used as the core of the hardware design. The MCU drives four octal buffers (SN74AHC574N). These buffers take input up to 5.5V, but can be run off a variable Vcc. We used 3.3V in this case so that it can interface with the rest of the chips and the actual Wonderswan.
  • The octal buffers' inputs are tied together, and we use control signals from the MCU to separately clock in each buffer. This allows us to drive a 32 bit wide bus with only an 8 bit wide data bus (PORTC) and some control signals. Two buffers send out a 16 bit address, and two buffers send out a 16 bit data word. Control signals are sent form PORTD of the MCU. There are four control signals ADDREN,DATACLK,ADDRCLK,WE corresponding to D.2,D.3,D.4,D.5 respectively. All control signals are connected to a 74AHC00 chip, which acts as a quad inverter. Non-inverted DATACLK and ADDRCLK are sent to the low byte buffers of data and address buffers respectively. The inverted versions are sent to their respective high byte buffers. This way, by clocking the signal to 1 and then to 0, we can write first to the low byte and then to the high byte. The inverted WE signal is sent to the SRAM chips and also to the output enable pins of the data buffers, while the inverted ADDREN signal is sent to the output enable pins of the address buffers.
  • The outputs of the octal buffers are connected to two 8bit SRAM chips. These chips run off 3.3V and hold 32 kB of data each. Their address pins are tied together, so that they'll provide 32768 words of 16bit each. This was done because the Wonderswan used a 16bit wide data bus.
  • The buffers are tristate buffers, so the MCU can totally disconnect itself from the SRAM chips. This allows the SRAM chips to be connected to a Wonderswan without removing them.
  • The memory chip's data pins are also fed back into the MCU (PORTA and PORTB) so that the MCU can download and verify data uploaded to the SRAM chips.
  • The memory chip's data and address pins are also connected to the PCB card edge board for insertion into the Wonderswan. Consult the pin out specification for more information.
  • All CMOS inputs that cannot be guaranteed a value because certain circuits have been shut off are pulled down to ground using 51k resistors for the buffers and 10k resistor packs for the SRAM addresses.
• Use of Other Code
  
  • We used the fast bit-based CRC generation algorithm found commonly on the web. We essentially looked at the C code and rewrote our own from scratch so that we could have an XModem CRC implementation.
• Failed Attempts
  
  • We tried implementing plain XModem Checksum for the file transfer, but it was very slow to start when downloading data from the MCU, because Hyperterm has to time out three times for XModem CRC before initiating XModem Checksum.
  • We tried to run the software at 38400 baud, but the MCU's UART couldn't handle it
  • We've gotten numerous seemingly random but deterministic errors with code and timing. Currently the code works now, but we are not totally sure why. It might have something to do with the amount of wiring, the capacitance involved and the speed of the circuit.

Results

• Speed of Execution
  We managed to run the serial protocol at 19200 baud. Thus, we are able to reach on average an upload/download speed of around 1400 cps. All interaction through the serial communications channel seems reasonably fast.
• Accuracy
  We ran into accuracy problems because there are stray resistances on our PCB board due to the fact that it was not etched fully and we had to knife away between the connections. Some of the copper dust probably settled in between the traces. Other than these problems, we were able to get pretty good results.
• Safety in Design
  In order to make sure that the CMOS chips did not burn up due to floating inputs, we attached pull up or pull down resistors to all inputs that can possibly float due to power failure, disconnections, etc. We also added a backwards shunting LED across the inputs of the 3.3V voltage regulator to shunt some of the reverse current away if the device was plugged in backwards. Furthermore, a lit LED would warn the user that the device got the wrong power polarity.
• Interference
  There might be some radiated EM radiation at 16MHz or less, but it wouldn't be constant. There is a chance for EM radiation because we had many long wires. We do not think this would present a massive interference risk, however.
• Usability
  Since this was designed for the Wonderswan programmer in mind, we would expect a certain level of technical expertise. As long as they follow the instructions and remember to verify their uploads, the device should be relatively easy to use. All one would need would be our device, the STK-500 with Mega32, a Wonderswan and a real cartridge. The data transfer is via a really standard and abundant protocol, so it would be easy to secure software to do that.

Conclusions

• Conformance to Expectations
  We had hoped to design an all purpose 32MBit cartridge, but due to monetary constraints and time constraints, we could only purchase enough chips and reverse engineer enough pin out information to create a 512kBit cartridge. Buffer timings and PCB board problems made the design not as reliable as it could be. Thus, if we had to redesign this, we would use a Mega162L for more pins so that we wouldn't have to use the buffers. Furthermore, the Mega162L can run at 3.3V, and thus not need the buffers to drop the voltage. Therefore, we can use just the Mega162L and 2 SRAM chips for the core of the design. Furthermore, if we had a larger budget, we would've design a dual layered PCB and had it fab'ed by a PCB service. This way, it would produce more reliable boards and reduce the amount of wiring.
• Conformance to Standards
  Our code has some incompatibilities with the XModem CRC protocol, because it will always send some sort of unexpected byte. However, after this, the protocol recovers and there are no problems with it. The other standard we were trying to confirm to was the pin outs for the Wonderswan cartridge. Since we were able to boot a ROM, we believe that we have achieved this goal.
• Conformance to Intellectual Property Considerations
  
  • We did not use anyone's code, though we did use an algorithm for CRC16 that was prevalent over the net. We believe that this is public domain, and thus there should be no IP problems.
  • We reverse engineered the pinouts for the Bandai Wonderswan cartridge. We believe that this is okay since we are not stealing this information. Anybody with a voltimeter and a screwdriver should be able to do this. As for patents and trademark issues, we are not stealing any of Bandai's names and putting that in our code. As for patents, we are not implementing something that handles the cartridge handshake, and thus are not violating any patents.
  • We did not receive any sample parts, and thus did not sign any NDA's concerning samples.
  • We don't think there's a point to patenting this, since it didn't require too much innovation, and having a patent would in our opinion restrict the flow of knowledge from this project.
• Conformance to Ethics
  
  • With regards to rule 1: 1. to accept responsibility in making engineering decisions consistent with the safety, health and welfare of the public, and to disclose promptly factors that might endanger the public or the environment; , we made sure to have all inputs properly pulled up or down depending on safe default values. We also made sure that our circuit would warn the user if the power was plugged in backwards.
  • With regards to rule 3: 3. to be honest and realistic in stating claims or estimates based on available data; we disclosed the fact that our circuit is not the silver bullet that does everything. We made sure to disclose possible problems with it, such as data inconsistency.
  • With regards to rule 5: 5. to improve the understanding of technology, its appropriate application, and potential consequences; we feel that by disclosing information about how the Wonderswan works, we are making it easier for other developers to understand how it works and to develop applications for it. We did look at how our design can possibly damage Bandai's sales, and we did not feel that our design would hurt the company, but rather help sell some of the excess Wonderswan in stock.
  • With regards to rule 6: 6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations; We improved our skills in PCB etching and also improved our skills in hardware reverse engineering. We felt that we were qualified enough to undertake this project, since one of our members is very knowledgeable about Wonderswan software.
  • With regards to rule 7: 7. to seek, accept, and offer honest criticism of technical work, to acknowledge and correct errors, and to credit properly the contributions of others; We collaborated fairly well as a team and helped each other when there were problems. We made sure to point out any errors to each other and strive together to find a solution.

Current Progress

• Found some sort of weird error with our PCB board. We would have to cut the DATA0 connection while programming with the SRAM and reconnect it when using the Wonderswan.
• Fixed up a programming error in which rewrites of a packet will end up writing ahead, instead of at the same location
• Managed to get Wondersnake, a public domain game, to boot. Furthermore, added a 10byte code hack to Girl Demo so that it would scroll. Additionally, also got the '#wonderwitch Channel Promo' program to boot on the Wonderswan.
• There is also something wrong with the PCB board in that grounding 2 pins that serve as inputs to the Wonderswan would cause the Wonderswan to leak an exhorbitant amount of current, causing shutoff in 30 seconds or less due to low battery voltage.

• Managed to get 'Girl Demo' to boot in the Wonderswan hardware. This demo program basically displays an image of a girl. At first, the ROM image was kind of flaky and the connectors were probably dirty and the ROM didn't boot up correctly. However, after a few tries, we were able to get it to boot rather consistently.
• Figured out a clever trick in which we hot swap Wonderswan cartridges to bypass its hardware handshake.
• Circuit has timing issues because of all the stray capacitances and pull down resistors. Therefore some ROM images will refuse to upload correctly.
• Finished connecting all the circuitry together.

• Begun verification of Wonderswan cartridge pinouts by monitoring 32 lines at a specific time point in the code. Correctly gotten something at address 0x8718 with data 0x50cb by verifying with emulation code trace
• Memory programmer hardware done.
• Memory programmer software debugged and should be bug free. There was a problem with the XModem CRC receive implementation.
• Added functionality to memory programmer, including custom word writes, filling the memory with a specific pattern and image verification
• PCB design for card edge finalized. In progress of etching.

• A good portion of the reverse engineering of the Wonderswan pinouts has been done. Address and data lines have been identified.
• The hardware design of the memory programmer has been pretty much solidified<./LI>
• One board from the memory programmer (the buffers) has been completed.
• The memory board for the memory programmer is half complete and will need testing.
• The code needed to run the whole thing has been written. No verification on overall correctness, though parts of it that could be tested have been correct.
• The etching of an interface board for the Wonderswan is still in progress. Currently, we are investigating the use of AutoCAD for PCB design.
• More reverse engineering needs to be done to insure that the Wonderswan will take our debug cartridge.

Appendices

• Code Listing
  • Memory Interface - memint.c
  • XModem Functions - xmodem.c
  • Programmer Functions - memprog.c
• Schematics
  • Overal Block Diagram
  • Buffer Schematic
  • Power Supply Schematic
  • Pinout Specification for Wonderswan Cartridge
• Cost Details
  • STK-500: included
  • Atmel Mega32: $8.00
  • Two Solder Boards: $2.50*2=$5.00
  • Two SRAM Chips: $4.99*2=$9.98
  • Four SN74AHC574N Octal Buffers: $0.34*4=$1.36
  • SN74AHC00N NAND: $0.32
  • Various Passive Components (resistors, wires): included
  • LM1117DT-3.3 3.3V Low Dropout Voltage Regulator: $0.74
  • Blank PCB Board: $4
  • Etchant Used (1/2 bottle): $2
  • White Board: $5
  • TOTAL: $36.40
• Work Distribution
  • Arbi Zadorian
    • PCB Interface Board Design
    • PCB Interface Board Etching
    • Circuit construction (soldering, wire cutting)
    • Brainstorming ideas to help fix bugs in design, such as ways to work around erroneous memory writes
    • Purchasing PCB board and providing various tools such as a Torx screwdriver, knife, etchant and steel wool.
    • Assistance in reverse engineering Wonderswan cartridge.
  • Zhengyun Zhang
    • Hardware logic design, using suggestions from Dr. Land
    • Software design (XModem CRC protocol, memory interface)
    • Circuit construction (soldering, wire cutting)
    • Purchasing integrated circuits and sockets
    • Reverse engineering Wonderswan cartridge signals
• References
  • Datasheets
    • SRAM Chip (NEC 43256)
    • Octal Buffer (SN74AHC574)
    • Quad NAND Gates (SN74AHC00)
    • 3.3V Regulator (LM1117DT-3.3)
  • Vendor Sites
    • Jameco Electronics
    • DigiKey
    • Atmel

---

Wonderswan is a registered trademark of Bandai