Gameboy Camera Force Trippy H

Here is something I have been working on for a few days now and only got a little bit of progress. But progress is progress and this really helps me understand gameboy debugging.

Analyzed the WRAM addresses for any and all changes that occur when you press buttons, select particular cursor locations and of course: when you enter DJ mode (Trippy H).

After hours and hours, I found that WRAM $D5CE is the game mode byte, or at least that's what I call it. This byte is changed directly before switching between dancing mario, menu, view, shoot and trippy H (as well as the other menus and modes).
1:D5CE 00 w
The first instance was when you press a button while mario dances. I restarted the emu and pressed A. The code broke and stopped at $74AC where there was an "LD A, $00"
Has someone done this before?

Dance = 19, menu = 00, shoot = 01, DJ = 1F, view = 02, play - 07, etc.

After learning this, I set an access break when the byte 00 is written to $D5CE

I replaced this with "LD A, $1F" and restarted again.

This time when you press a button at dancing mario, Trippy H starts!

----------------------------------------------------------------------------------------------------------------

Next update I would like to stop the cart from checking if the camera is present. This will allow the ROM to be put onto a normal flash cart. 

2nd future update would be to remove unnecessary routines like "shoot  " and "view" hopefully the ROM itself can be reduced in size. Potentially an MBC1 + SRAM + BATTERY

3rd future update I would like to break the ROM even more and remove saving altogether so that it can be safely put on a 64M cart along with LSDJ or a dedicated ROM only cart.

Do not stay at the Guest Quarters Hotels - Dumping The Miracle Piano Teaching System

I had my Willem programmer pulled out for some Sega Genesis programming stuff and decided to finally dump the eprom inside of the Miracle Piano teaching System Keyboard. If you recall from a previous post of mine, it contained a 27c256 OTP eprom. It also contained many proprietary ICs of which I may never figure out. We may never know what microcontroller they used or what language the machine code is suppose to be written in. z80, 6502, etc.

In any case; with many vintage computers and other devices containing ROM, the authors always find the space to sign and date their work and in rare cases they may even decide to add a little easter egg. Although I cannot locate a date, here is some clear text I found in the ROM image:

"This Eprom contains code created by Mike Collins. Anne Graham and Ray Livingston. Do not stay at the Guest Quarters Hotels. Keep that Coke classic and that Piping hot coffee coming."



I got a real kick out of reading that. For anyone who knows what to do with it, here is the binary file:
http://www.mediafire.com/download/eo3zujca7jvw44f/MPTS_ROM.zip

Making Gameboy Sprites, Tiles and Maps

Just to put it on the table, you have no business creating anything for Gameboy if you have not yet read "Everything You Always Wanted To Know About GAMEBOY: but were afraid to ask."

Read it and then return for my tutorial. I can wait.

***

Now then, lets start talking about sprites, maps and other graphic elements. As you very well know, the Dot matrix gameboy displays four shades of grey (or green). Each shade is represented by two bits: 00, 01, 10 or 11 respectively. It isn't that important to know right now, but while setting up the palette in your gameboy code, it is commonly done as follows:

...
init:
ld a, %11100100 ; Window palette colors, from darkest to lightest
ld [rBGP], a        ; Load Accumulator A (11100100) into rGBP
...

Where "rBGP" Equates to $FF47, an address representative of the specially reserved I/O Register...but why am I just repeating what you have already read, right?

Now, back to the point. You may choose to design all of your characters and objects for your game strictly in binary or hexadecimal data if you wish but I prefer the visual approach. You know, the kind with a GUI. ;)

First download these two programs:
Gameboy Tile Designer: http://www.devrs.com/gb/hmgd/gbtd.html
Gameboy Map Builder: http://www.devrs.com/gb/hmgd/gbmb.html

Both of these tools will help you create and visualize the output of tiles and maps. Tiles are going to be used both for maps and for sprites, you can imagine a sprite or character figure to be a collection of tiles. Pretty simple.

You'll start by opening  Gameboy Tile Designer (or GBTD.exe). I like to keep the default color palette which is "Gameboy Pocket" because it is easier to work in shades of black rather than shades of green. Under View, I also like to switch to "simple" and use nibble markers, though they are not very easy to see. 



Next select the color you would like to draw with by adding it to either your left mouse button or right mouse button by clicking on it with the corresponding button. Start filling in squares to your liking. You make design single 8 x 8 sprites or larger. Anything you wish as long as it is four colors. Once you finish a tile, click on the next blank tile on the far right of GBTD.



You will save the file with whatever content you have at this point and name it something relative to the content. Open Gameboy Map Builder (or GBMB.exe) and click file > Map Properties then use the browse button to locate your new *.GBR file that you made in GBTD. For no, you may ignore width and height because you can add columns and rows at will.



Once you have loaded in your tiles, you may continue to make more tiles! Make and place tiles, side-by-side by having both programs open at once. Each time you save your *.GBR file in GBTD, GBMB will automatically update! How cool is that?

Here are some time-elapsed screenshots of my own work.
















The above Map is simply a 160x144px image that I can manipulate on screen. REMEMBER:
"The main GameBoy screen buffer (background) consists of 256x256 pixels or 32x32 tiles (8x8 pixels each). Only 160x144 pixels can be displayed on the screen." That means that where ever I place the image on the gameboy, there will be large empty scape on the sides. If I wanted to, I could have designed a full 256x256px map and used a scroll option and the d-pad buttons to view it all.


My process of designing such a large map was that I took an image I had re-sized and pixelized in Photoshop. There are a few options when pixelizing and for this one, I chose "pattern."

Below is the full 160x144 image which I have then transposed into GBTD...one tile at a time. It took nearly four hours, but I figured out that I was able to copy and paste a few of the colors. It turened out that the three lightest colors could be copied and pasted from PS to GBTD. I still had to fill in the black (11) pixels though.







With a temporary frame, I was able to see more clearly which pixels I was currently working on. Again, I did this one 8x8 tile at a time.

Once you get better at creating tiles, you can create all sorts of maps and sprites, both for game characters and even art!



When I am able to write better ASM code, I will demonstrate how to export these files and INCLUDE them into your very own ROM images. Thanks for reading!

Update Jul-25-13

Here I am trying to learn gbz80 ASM (or Gameboy Assembly Language) and am just having a terrible horrible day! I have programmed in assemble for classes before and loved it, but nothing wants go correctly this time. First off, the cat is being a psycho-demon and tears through the room every few seconds, next the power went out for one minute last night losing data from the programs I was running, resetting the wireless printer and shutting off the coffee pot so the water had top warm up in the morning and to top it all off, I did my egg over-hard rather than over-easy! BAHHH!

In any case, my biggest problem is that the assembler included with RGBDS, the gameboy assembling environment, refuses to load one of the THOUSAND files that all run in sequence when you initiate the assembling of a ROM. To top it all off, you have to run it through a command prompt which just adds a whole new level of fun to the project.

 I have tried setting programs to admin mode, compat mode, and all other forms of configuration and yet nothing works. Get this, the program was written for Windows 95 so I probably can't use Windows 7 x64...

 

That is the error. RGBFix refuses to load after the batch file calls for it. Putting RGBFix into Admin mode just skips the error message and does nothing. I am supposed to have a *.gb file that runs on gameboy or in an emulator.

 I am not even beyond Hello-World yet because of this nonsense! If anyone knows how to get this assembler working in Windows 7 x64, let me know...

Jazz Disassemblies Ep1: Fun with Flippy Floppy Files

This week we have yet another yard sale treasure to gut and explore. Brought to you by Yamaha, I have found a short lived piece of equipment called the Midi data Filer 3, or MDF3. This particular handheld brick accepts live MIDI input and allows for the user to record it for later use on the new, innovative and wonderfully compact data storage called the 3.5" floppy diskette!

Yes folks, you and your friends will spend hours filing and sharing live sequences for years and years to come...The MDF3:



Just a few other facts before we tear it up: this device offers not only MIDI filing Utilities, but also a formatting, copying and back-up of floppies containing any sort of files. Unfortunately, it cannot be used as an external drive for a computer. (Or so says this ASM noob) As for the internals, it looks like we have an 8-bit z180 uProcessor, 128Kbits RAM, Floppy Drive Controller IC, 4Mbits ROM, graphic LCD module, keypad input and various other components.



According to the z180 datasheet, we can only support up to 1Mbit ROM. So...why would Yamaha choose to purchase an (IMO obscure) 4Mbit Mask ROM to store the ASM program? Are they using a highly complex bank mapping setup or are they simply costing the end user more money on a larger capacity chip? Lets have a look at the ROM's socket after desoldering it from the board:



lolwat!? "1M-EPROM"...I think not. The M534001E is definitely not 1M or an ordinary EPROM. Also, pin 1 is labeled as NC or Not connected in the datasheet but is obviously pulled high on the board. What on earth were they thinking? While probing a few other pins, A18 and A17 which are the high address bits seem to be pulled high as well! So to answer my previous question, yes, Yamaha seems to have wasted the extra space...a lot of extra space.

My biggest concern now is how to dump the data. I own a crappy Willem EPROM Programmer which cause everyone issues and I also only have Windows 7 64-bit which only supports high addressed LPT ports! That is another story for another time though; needless to say, I have it working. The Willem software does not have an M534-something-blah ROM option, so I will have to trick it into thinking it contains another chip. According to the datasheet, the pinout is rather common so I am able to tell my computer that I am dumping the 27C040 EPROM.

After attempting a few dumps and receiving verifying errors, I looked back at the datasheets and remembered a previously noted pin...pin 1. Pin 1 is not supposed to be connected with the Mask ROM, but happens to be the Vpp pin on a 27C040. This pin is going to be used on the 040 but is entirely static with the Mask ROM, so finally I figured out that I should simply bend pin 1 up... Dump and verify are a success (and a couple more times just to be sure) ;)

And Here she is: Yamaha MDF3

With Hex data, sometimes headers and other data being sent to an LCD module for example are clear text. It appears that "Copyright (C) 1997 by YAMAHA V1.20.MDF3" is clearly visible at the beginning of the program. Maybe there are other versions out there, or maybe they recycled the program from the MDF2 considering the fact that the Mask ROM says 1997 and 1998...hmmm...Another thing to notice is that I included two files. One is the full 512Kbyte ROM and the other is a cut down version because Yamaha repeated the same code four times, once in each of the 128Kbyte banks to fill it up.



There is more clear text such as the button names, but you can have a look yourself if you're interested. Lets move on to the other hardware inside. Again, there is an LCD and keypad as well as a floppy drive. Looking at the floppy drive, it clearly states 1999 so I assume the code was recycled yet another year! Did they simply improve the external look of the MDF1 and 2? Anyhow, I believe the keypad will be a wonderful example when I design my own 8 or 16 bit computer. As for the LCD, you can all expect to see an update with it backlit.



Now lets take a look at the whole board itself. What I love most about this computer is that it is mostly surface mounted components in SSOP packages and a few DIP's here and there. Many of these parts could have been much smaller, but that wouldn't have made for such an interesting write-up if none of them could be read! I also can share my appreciation for the board designer(s) because there are no components retro fit on the back of the board, such as filter capacitors as we have seen so often in other devices (like last week)...Also, who doesn't love a battery powered 8-bit computer? ;) So here it is, please click to enlarge and enjoy my side-notes:

Jazz Disassemblies Ep0: Me, Myself and the 8-bit Computer

Episode 0: Me, myself and the 8-bit computer

In both the video game and chiptune/modding scenes I am known me as Jazz or Jazzmarazz, but few know me by my real name; Jordan Appleton-Joslin. This past December, I finally graduated from Central Michigan University with a Bachelors of Science in Information Tech with a minor in Industrial Tech. Studying computer technology through the eyes of your everyday "end-user" simply didn't cut it. From very early on I was overly fascinated with electronics and what makes them work; while never being satisfied with just using them. I quickly finished Uni's requirements to graduate with IT and picked up a huge number of EE classes to fill in the rest of the gaps.

For as long as I remember the Nintendo and Atari took up the largest part of my childhood; playing games and pumping the audio through my father's stereo with unknowingly sketchy and possibly reckless hand-coiled wiring. While my brother tooled around with his walkman, I carried my gameboy listening to the sound files available through option menus. Naturally I found my way into the chip/mod crowd for future-learning-endeavors and old time's sake.

Each week following today will be accompanied by a dis-assembly of some sort. I plan to accept any and all gizmos and gadgets in the name of science! So please send your 70's, 80's and even early 90's crap so that I may break it down and tell you a little more about what makes it tick and or how it may be used for chip-relevant pursuits!

If you have something which piques your interest but cannot find a use, please contact me; broken or otherwise, so please hit up them yard sales and thrift stores!  :D

Now that you know all about me and myself, lets move on to the main attraction. As today's special guest, I have not chosen a gameboy, C64 or Sinclair something or other...but today you will all learn about the Compumate2 from Laser! Originally purchased at an estate sale after the death of the prior owner, this wonderful device was thought to be the one and only Compumate2 for the Atari 2600; however, it is not. I sat this aside for several years once I found out that it was nothing more than a miserable PDA from the 80's.



Full QWERTY keyboard and 7 functions and I was still rather peeved having just obtained an Atari after many long years. Recently though, I had become very interested in the Zilog z80 and Intel 8085. For several weeks, I worked on building my very own 8-bit computer based on the 8085 and even though it was much more powerful; I still wanted to work with the z80. The z80 as some of you may know is what powers each and everyone of your gameboys. Sure, it has many proprietary modifications to interface with the link port, LCD and button input; but it is still a z80 at heart.

So I tore into the PDA not looking for anything fun, but looking for components to scrap. To my surprise, I found not only a z80 micro Processor, but 256Kbit ROM, 64kbit RAM, 2 x 20 LCD and possibility for external programs to be written all running on 4xAA's! Not a whole lot has been shared about this device and even less is known about the external ROM slot, but know this: I will eventually find out how to run a custom program on it. See below that there is a 34 pin connection at one side of the board. Also note the RAM chip being socketed. Laser must have had plans to expand the RAM at one point, but up to what capacity?



Also notice that the sides have empty ports for expansion. The labels read: Line, Phone, Cassette and Expansion I/O. There seems to be limited room inside to fit many more components, but looking at pictures of the Compumate3 which itself is incredibly rare, I found that the I/O port at least was fitted with a midi/game type connection. Could there have been plans to release games for use with commercial PC controllers of that generation? There is no information on any carts being released to support a sure answer. In any case, the computer is equipped with a speaker for simple 1 bit beeps to signal an error or process completion, so why not write a simple 1-channel tracker once the code is analyzed?


If you looked closely at the external ROM connector, it is nothing more than a 2 x 17 DIP connection....exactly that of a floppy drive cable used in last year's PC! Following the pins back to their origins, I find that the ROM slot is directly interfaced with the Address and data buses, but what else...34 pins and only 24 D/A pins...I guess you'll have to wait for the second installment! xP

Thanks for tuning in!

Cheers,
Jazz

p.s. I am including the hex dump and (hopefully reliable) disassembly of the internal ROM as well as various pinouts that I traced with my multimeter:
Compumate2 ROM (BIN)
Various Pinouts (TXT) (Best to be viewed in word pad rather than your browser.)
Use these only for good! ;)