News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - hackfleisch

Pages: [1] 2
1
I tried this before, but could not get any reasonable results. There must be a cars brand logo (Ford) inside, which is 400x198 Pixels and 256 indexed colors, this i know for shure. The others may be symbols and characters.

I think there is some kind of compression. Because of the age and the architecture (build 2007 usbg a NXP MAC7116) used i tried to decode it as RLE (used in BMP) or LZW (GIF), but could‘nt get any result, It does not seem to fit.

Also i could not determine any size values in the header, neither length nor width and height. I could not imagine how the processor know at which address to look for a specific image. All i found are two pointers at the end of each block (image, tile?), right before the EOI magic 38 56. Look at the last image block posted. The first dword in front of the magic points to the beginning of the block, which makes ni sense to me. To get the address, use little endian. The prefix 0x30 may be just flags or a relative higher address the processor uses to address the external flashdata.

I’m stuck. Therefore i posted it here, because you guys really know this stuff!
If someone needs the whole flashdump, it can be donwloaded here: s29gl016a90tfir2_ipc_vfl_7m2t-14c026-ae.zip


April 03, 2018, 02:29:20 am - (Auto Merged - Double Posts are not allowed before 7 days.)
One important thing i should mention: The data inside the flash is read as 16 Bit entities (WORDs). This is because of the hardware architecture.
So the datastream:
Code: [Select]
00 00 FF 00 00 01 00 00 00 00 00 00 00
05 AC 0B 00 05 AC 6F 02 00 8C 9A 00 05 57 05 AC 01 60 09 27 01 57 05 AC 01 60 70 05 00 74 74 00 00 05 00 01 57 09 AC 01 60 05 27 01 57 72 AC 00 60 6A 03 00 00 57 05 AC 01 60 09 27 01 57 05 AC 01 60 73 02 00 00 4B 57 05 AC 01 60 09 27
must be read as:
Code: [Select]
00 00
FF 00
00 01
00 00
00 00
00 00
00 05
AC 0B
00 05
AC 6F
02 00
8C 9A
00 05
57 05
AC 01
60 09
27 01
57 05
AC 01
60 70
...
4B 60
08 4B
0B 00
05 4B
71 00
05 4B
00 00
00 00
8B 00
C3 00
8B 00
00 00
08 30
D8 F5
08 30
CC F5
00 00
38 56

It may be interpreted as bytes, but could also skip some bytes... i don't know. Even endianess is unknown.

2
Hello,

it may be placed wrong, but i'm looking for a way to extract the graphics in a Flash-Dump of my cars instrument cluster.

I found some repeatings inside, but still have no clue what image format this may be. All i know is that images are stored have 256 indexed colors, so 8 bit per pixel.

Don't know how to attach files here to post binary dump data, but here is my interpreted example:

Code: [Select]
0x0000 - 0x00F7 (Len 0xF8)
00 00 FF 00 00 01 00 00 00 00 00 00
0x000C: 00 0D
49 01 00 1B 49 01 00 1B 49 01 00 1B 49 01 00 1B 49 01 00 1B 02 00 52 49 00 1A 02 00 49 50 00 29 49 1C 00 1F 0F 00 00 49 00 00 49 49 00 00 49 00 00 49 00 00 0C 49 00 00 49 10 00 49 49 00 00 00 00 49 00 49 49 00 00 00 0D 49 00 00 49 13 00 00 00 49 49 00 49 00 00 00 00 49 49 00 00 00 00 49 49 04 00 05 18 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 00 49 00 49 49 00 49 00 49 00 00 04 18 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 49 49 00 00 49 00 49 00 49 00 00 04 35 00 00 49 49 00 00 00 00 49 00 49 49 00 00 00 00 49 00 49 49 00 49 00 49 00 00 00 49 00 49 49 00 00 49 49 00 00 49 00 00 49 00 00 00 49 49 00 49 00 49 00
49 00 00 00 00 00 1C 00 11 00 1C
00 00 00
00 30 0C 00
00 30 00 00
00 00 38 56

0x00F8 - 0x12BF (Len 0x11C8)
00 00 FF 00 00 01 00 00 00 00 00 00
0x0104: 00 C2
06 00 9C 98 A8 A6 AA AA AB 05 06 00 AA AA A6 A8 98 9C 00 27 09 00 A8 9D AF AC AD AF AB AC 05 AB 00 AA AB 09 AC AB AF AD AC AC 9B A8 00 22 06 00 AC A2 AE AF AA AB A9 08 0D 00 A9 A8 A9 A8 A9 A8 A9 A8 AD AA AC AC 1E A2 00 00 9C 0D B0 AC AA AB AA A9 A9 A9 A8 A8 A7 A7
...
04 8A 00 90 8D 04 00 90 1E 90 00 00 8D 05 8D 00 8D 90 90 13 03 00 00 8D 23 8D 00 00 8D 15 8D 00 8D 00 8D 00 8D 00 8D 00 00 00 00 90 8D 00 8D 00 8D 00 00 29 0D 00 00 8D 00 8D 00 00 00 8D 90 00 00 00 FE 8D 42 00 00 00 00 00 3B 00 73 00 3B
00 00 00
00 30 04 01
00 30 F8 00
00 00 38 56

0x27AC - 0x28AB (Len 0x100)
00 00 FF 00 00 01 00 00 00 00 00 00
0x27B8: 00 36
33 0D 00 0B 33 01 00 0B 33 01 00 08 33 04 00 0B 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 06 00 00 33 33 00 38 34 00 09 33 01 00 08 07 00 00 33 38 00 33 35 08 34 01 00 08 33 01 00 05 33 00 00 34 02 07 35 01 00 08 33 01 00 05 33 00 00 38 03 38 33 00 06 33 01 00 08 33 01 00 06 02 00 38 33 00 06 33 01 00 08 33 01 00 05 03 00 33 38 06 38 01 00 08 33 01 00 05 33 00 00 34 02 07 35 01 00 08 33 00 00 33 07 00 00 35 38 34 33 00 08 33 01 00 08 06 00 00 33 33 00 38 34 00 09 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 04 00 00 33 33 00 00 0B 33 01 00 08 33 04 00 0B 33 01 00 0B 33 01 00 0B 33 01 00 0B
33 0D 00 35 00 00 00 00 18 00 17 00 18
00 00 00
00 30 B8 27
00 30 AC 27
00 00 38 56

0x28AC - 0x29AB (Len 0x100)
00 00 FF 00 00 01 00 00 00 00 00 00
0x28B8: 00 36
36 0D 00 0B 36 01 00 0B 36 01 00 08 36 04 00 0B 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 06 00 00 36 36 00 32 37 00 09 36 01 00 08 07 00 00 36 32 00 36 39 08 37 01 00 08 36 01 00 05 36 00 00 37 02 07 39 01 00 08 36 01 00 05 36 00 00 32 03 32 36 00 06 36 01 00 08 36 01 00 06 02 00 32 36 00 06 36 01 00 08 36 01 00 05 03 00 36 32 06 32 01 00 08 36 01 00 05 36 00 00 37 02 07 39 01 00 08 36 00 00 36 07 00 00 39 32 37 36 00 08 36 01 00 08 06 00 00 36 36 00 32 37 00 09 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 04 00 00 36 36 00 00 0B 36 01 00 08 36 04 00 0B 36 01 00 0B 36 01 00 0B 36 01 00 0B
36 0D 00 35 00 00 00 00 18 00 17 00 18
00 00 00
00 30 B8 28
00 30 AC 28
00 00 38 56

0x29AC - 0x2AAB (Len 0x100)
0x29AC: 00 00 FF 00 00 01 00 00 00 00 00 00
0x29B8: 00 36
01 0D 00 0B 01 01 00 0B 01 01 00 08 01 04 00 0B 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 06 00 00 01 01 00 42 40 00 09 01 01 00 08 07 00 00 01 42 00 01 41 08 40 01 00 08 01 01 00 05 01 00 00 40 02 07 41 01 00 08 01 01 00 05 01 00 00 42 03 42 01 00 06 01 01 00 08 01 01 00 06 02 00 42 01 00 06 01 01 00 08 01 01 00 05 03 00 01 42 06 42 01 00 08 01 01 00 05 01 00 00 40 02 07 41 01 00 08 01 00 00 01 07 00 00 41 42 40 01 00 08 01 01 00 08 06 00 00 01 01 00 42 40 00 09 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 04 00 00 01 01 00 00 0B 01 01 00 08 01 04 00 0B 01 01 00 0B 01 01 00 0B 01 01 00 0B
01 0D 00 35 00 00 00 00 18 00 17 00 18
00 00 00
00 30 B8 29
00 30 AC 29
00 00 38 56

0x2AAC - 0x2F7C (Len 0x4D1)
0x2AAC: 00 00 FF 00 00 01 00 00 00 00 00 00
0x2AB8: 00 04
09 01 1A EE 02 00 16 18 00 07 03 00 1A 09 F0 17 00 03 15 02 04 15 00 00 09 02 F5 17 03 03 01 00 F6 1A 00 03 10 04 09 00 F6 17 00 03 13 03 1A 00 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10
...
1A 10 03 F8 02 00 1A 10 03 F8 02 00 1A 10 03 F8 02 00 18 10 03 F8 02 00 16 10 03 F8 03 00 00 10 F6 15 00 03 10 04 00 00 F6 15 00 03 10 04 00 00 F5 00 01 03 05 10 00 00 10 02 F0 13 00 03 10 02 08 10 F0 00 05 10 00 00 FA 00 C3 00 FA
00 00 00
00 30 B8 2A
00 30 AC 2A
00 00 38 56

0x604D0 - 0x606D7 (Len 0x208)
0x604D0: 00 00 FF 00 00 01 00 00 00 00 00 00
0x604DC: 00 FE 00 FE 00 FE 00 FE 00 5E 02 00 03 03 00 37 03 00 85 03 36 03 00 00 03 04 85 85 05 03 01 00 1A 86 01 85 14 86 00 00 03 09 85 85 03 85 00 00 87 00 85 1E 87 01 00 11 03 01 85 04 04 00 00 03 00 00 85 20 00 10 03 01 85 05 04 00 00 03 86 00 85 20 86 01 00 0E 03 01 85 2B 00 0D 03 01 85 2C 00 0C 03 01 85 2D 00 0C 85 2E 00 0C 85 14 86 01 00 10 86 01 85 08 00 0C 03 01 85 13 00 12 85 08 00 0D 03 01 85 12 00 12 85 08 00 0E 03 01 85 10 87 01 00 12 85 08 00 0F 03 01 85 05 03 01 00 1C 85 08 00 10 03 01 85 04 04 00 00 03 00 00 86 06 00 13 85 08 00 11 08 00 85 03 85 85 00 03 00 00 86 06 00 13 85 08 00 12 07 00 85 03 03 85 00 00 06 00 13 86 08 00 13 85 00 00 03 06 03 85 00 00 06 00 13 86 08 00 14 85 00 00 03 05 00 03 00 00 86 06 00 13 85 08 00 19 86 06 00 13 85 08 00 19 86 06 00 13 85 08 00 19 86 06 00 13 85 08 00 19 86 06 00 13 85 08 00 19 86 06 00 13 85 08 00 19 86 06 00 13 85 08 00 19 86 06 00 13 85 08 00 19 86 06 00 12 86 01 85 08 00 19 86 07 00 05 87 01 85 14 00 19 86 0B 00 01 85 15 00 19 86 0B 00 01 85 15 00 19 86 0B 00 01 85 15 00 19 86 0B 00 01 85 14 86 01 00 1A 86 0A 00 01 85 14 00 1C 86 09 00 01 85 13 87 01 00 26 85 11 86 01 00 28 85 08 86 01 00 31 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 32 85 08 00 19 00 00 00 00 3A 00 50 00 3A 00 00 00
06 30 DC 04
06 30 D0 04
00 00 38 56


3
Programming / Looking for basic and reusable ASM code
« on: March 28, 2016, 03:40:02 pm »
I'd like to learn more on GB programming in Assembler. So looking for tutorials or some simple examples for common tasks, i.e. storing background or spirte data and wirte it to screen, get button events, a simple statemachine for program logic, playing musik or soundeffects and such.
Any hints or good howto's?

4
Programming / Re: [DMG] How to disassemble a ROM?
« on: March 26, 2016, 08:59:59 am »
Distinguish code from data seems a common challenge to do.
Completely disassemble and comment the game is more an learing issue for me. I guess real cheaters/patchers use some more pracmatical solutions.

And again, my expectiation that an old console game is easy to hack, has pointed out to be wrong... and the simple Z80 CPU is more complicated than expected.

So, what i can do is to follow the code using the debugger, identify the data areas by the registers loaded (HL, BC, DE) and write down the executet code, one by one. What would help in this process is a kind of memory-list, to mark the adresses seen.

March 26, 2016, 09:05:49 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Today or tomorrow I'll release my Z80 tree disassembler/decompiler, which uses a tree view widget to disassemble routines on command.
Sounds interessting! Where can i get this tool?

5
Programming / [DMG] How to disassemble a ROM?
« on: March 25, 2016, 02:58:18 pm »
Hello,

as i'm getting familar with Z80 Opcodes and using BGB disassembler, i'd like to document the subs and loops found in the game-ROM. It would be a great help, if some experienced user may give me some advice on "how to do it right". I'm sure there are some best-practice rules to follow.

My goal is to compile the generated sourcecode to a new binary ROM file and get this executed. My starting point is address 0x0100, of course ;-)

6
This is a self-study project. I choose GB, because i thought it would be easier to understand an old gameconsole than an recent one (like PS-Vita or such). Another point was that i get in touch with Z80 in my early Computer and electronics experiences. So i am a little bit familar with it.

7
When using an Hex-Editor like HxD, each byte is shown with as HEX value and corresponding ASCII char. When searching the data, HxD let you choose how to find the entered searchvalues. Just click "as text" here.

How to find the tilemaps is something that i don't know (for now). It may be everywhere in the code. In this early consoles there are no data-signatures which can help identifying those maps. I try to find the maps of my game by reverse engeneering the whole code.

8
Welcom on board ;-)

As i'm trying to do the same thing for another game, i can tell you that it is not that easy! First i thought there must be text strings inside the game ROMs and it would be enough for overwrite them. But it's much more complicated than that. I'll try to explain:

Text inside the game (this may differ from ROM to ROM) was made of character graphics (=font). Each char ist made by one tile, a 8x8 dotmatrix image. Tiles are placed on screen using tilemaps. They tell where, which tile should be shown. So making a text like "GAME OVER" will require 7 individual tiles for the chararcters "G", "A", "M", "E", "O", "V", "R". The tilemap then tells to place "E" twice, in "GAME" and "OVER". Also the space between both chars may not be a tile, so there is no need for a character here.

As you can see, there is no chance to find text which is coded like that. There may be games using ASCII-Texts for displaying the font-characters on the screen, so you can simply change it. Check this by using an HEX-Editor like https://mh-nexus.de/de/hxd/ (HxD) and look for it.


9
ROM Hacking Discussion / [DMG] How to build a FLASH-Cartridge
« on: March 25, 2016, 11:05:00 am »
Hi,

i'd like to create a cartridge which can get programmed from PC via USB. I've read about http://www.reinerziegler.de/readplus.htm but did not find my preferred solution there. Besides it's a GREAT site with many usefull informations!

What i try to do is, to buy a ROM with greates functionality (should have MBC5, Battery, SRAM), then remove the ROM-Chip and place a 4 meg Flash-memory onto it (biggest possible, i think). Then add some extra hardware to program the flash via USB. Also need a programmer for that.

For the flash-chip i think a AM29F032B should do it. The USB-Connection could be made by an FTDI-Shield, which is low-cost and alread contains an USB-connector. Now comes the tricky part. How to program the flash with the serial-out of the FTDI? I could think of an Atmega (Arduino) which is connected through USB, getting the ROM data and write it to the flash. Also i have no idea which programmer may be used for this.

Maybe someone knows an easier solution?
I want to void an extra programmer, or swapable chip-sockets for the flash. I should be programmed easily via USB.

10
Hello,

after getting so much help from this board in understanding the principles of ROM hacking and architecture of the Nintendo Gameboy (DMG) i would like to give something back. Therefore i start this project.

My goals are:
  • Learn a lot of console arch, game development and such...
  • Disassemble the whole game
  • Translate the gametext to German language
  • Change graphics inside game to some custom pictures
  • Looking for cheats inside the code
  • Generate patches for endless life/fire and such

Tools:
  • Gameboy-Emulator: http://bgb.bircd.org/ - In my optinion the BEST Gameboy-Emulator for Windows PC (runs even under Win 10)
  • Debugger: BGB also contains a powerfull debugger. It can modify code in-place, on-the-fly. Has memory and VRAM viewer and many more.
  • Compiler toolchain: -STILL LOOKING-
  • Tile-Editor: -STILL LOOKING-
  • Sound-Composer: -STILL LOOKING-

Step 1: Getting familar with the ROM
The cart-info tells it's card type "MBC1", no additional RAM, no battery and ROM-Size is 131.072 bytes.

11
Newcomer's Board / Re: Learn about ROM file formats
« on: March 25, 2016, 10:38:04 am »
You have to put the bootrom in the same folder as the emulator (not the same folder as your game ROMs)

That did it!  :thumbsup:
I've downloaded DMG_ROM.bin here [ from a website ], put it into the BGB program dir and enter the filename in bgb control panel "System" into the "DMG bootrom" box. Also check the "bootroms enabled" option. Works like charm! Now i can use BGB's debugger to see what's going on.

After getting the scroll down Nintendo-logo on screen, i started to modify it. My goal was to change des logo, just to see it on the screen. Of course it would never go past the logo-check subroutine, but this was no matter for me.

I found a great web-based online generator for it [ also on a website ]. The tool is written in JavaScript and gives a ROM-file as result.

After getting a big grin, while watching my own custom logo scrolling into screen, my next goal is to learn about displaying graphics. I've read about tiles, tilemaps, background memory and windowposition. I think i could not be so hard to write some ASM code to display some tiles on the screen.

For now i'm looking for good development tools to code and compile in Assembler.

By the way, i would like to say that i REALLY appreciate the help i'm getting here. Instead of flaming and hating dump newbes like me, you and the other members here, answer professional and clearly. Besides this it makes much fun to hack inside this old consoles!

12
Newcomer's Board / Re: Learn about ROM file formats
« on: March 24, 2016, 05:36:13 pm »
bgb can run the bootrom if you have a copy of it. Check "enable bootrom" in the options.

First, thank you so much for your explainations.
I tried to enable the bootrom, and also assign a bootrom file, but it behaves like bevor. No intro screen with scrolling shown.

I did see the tiles of the logo in VRAM, and also see the logo for a millisecond or so on screen. But not the scrolling logo like on the native hardware DMG.

What do i do wrong?

13
Newcomer's Board / Re: Learn about ROM file formats
« on: March 21, 2016, 07:47:30 am »
I tried many GB emulators but none of them seems to emulate the boot-phase of the DMG. I do not see the scrolling "Nintendo(R)" Logo, nor hear any sound. They just start over with the game.
For my tests and learnings it would be great to know one emu doing that.
Any hints for me?

March 21, 2016, 07:54:00 am - (Auto Merged - Double Posts are not allowed before 7 days.)
At the end of four iterations of the loop, the upper four bits of the original source byte have been doubled and shifted into A, and the lower four bits of the original source byte are now in the upper four bits of C.
So the second call to 0096 is what handles them.
Right, as you can see in my "debug" post:
A at start = 1100 1110
A at end = 1111 0000
C at end = 1110 1011

So the second call to 0096 is what handles them.
So, register C is only used to produce side-effects on the carry, and keeps the lower nibble of the current logobyte between iterations, right?
The persistence of registers is what makes Assembler really hard to debug. It's like super-globals in other languages.


14
Newcomer's Board / Re: Learn about ROM file formats
« on: March 20, 2016, 02:58:02 pm »
Thanks AWJ. I must have read a wrong opcode description. "RLA" rotate A through carry.
But the command "RL C" will also rotate through carry, so the carry is "mixed" with both values.

Lets play this through:
First logo byte is CEh, so sub is called with
A=1100 1110
C=A = 1100 1110
assume carry=0
(register shown after the corresponding RL command. The carry is given after the comma)
1. iteration of loop
C=1001 1100, 1
A=1001 1101, 1
C=1001 1101, 1
A=0011 1011, 0

2. iteration of loop
C=0011 1010, 1
A=0111 0111, 0
C=0011 1010, 1
A=1110 1111, 0

3. iteration of loop
C=0111 0100, 0
A=1101 1110, 1
C=0111 0101, 0
A=1011 1100, 1

4. iteration of loop
C=1110 1011, 0
A=0111 1000, 1
C=1110 1011, 0
A=1111 0000, 0

So indeed, the bits of the first nibble are doubled and fill up the whole byte of A. This is written to address in HL and HL+2, which makes up the "color" in 2bpp mode. So the color is always 11 or 00 which means black or white.

The next call goes on line after the first, to address 96h. Here carry, A and C register are untouched from previous loop. But what happens with the lower nibble of the source logo byte CE?

15
Newcomer's Board / Re: Learn about ROM file formats
« on: March 20, 2016, 01:30:55 pm »
Back again  :)
I've learned a lot by studing the bootloader of GB, not just how the logo is displayed...
There are a few things i don't understand.
In the graphics load routine starting at 0095h (please see my notes for questions):
Code: [Select]
LD C,A ; $0095     C is loaded with value of A
LD B,$04 ; $0096
Addr_0098:
PUSH BC ; $0098
RL C ; $0099   Rotates C left by one bit using carry-flag
RLA ; $009b   Same as C but without carry
POP BC ; $009c   Why is C rotated? Is lost now because of the pop...
RL C ; $009d   C is never bin used in code. What's it's purpose?
RLA ; $009f    A rotatet left again
DEC B ; $00a0
JR NZ, Addr_0098 ; $00a1     Will loop this 4 times. Every loop A is rotatet by 2 bits. After 4 iterations it the same as before?!?!
LD (HL+),A ; $00a3
INC HL ; $00a4
LD (HL+),A ; $00a5
INC HL ; $00a6
RET ; $00a7


16
Newcomer's Board / Re: Learn about ROM file formats
« on: March 19, 2016, 03:32:30 pm »
Thanks, AWJ. I also read about the memory map.
At this point i really like to make this console doing some action on my command to test the register functions. But therefore i need to have :
 - an GB-Z80 assembler to write my code
 - some kind of EPROM emulator with a cartridge pcb connector

A goal could be to simply show some graphics on the screen or play some sound. Of course i could write an ROM-file and execute it with an GB-Emulator on the PC. But this is only half fun. Maybe i can sacrifice an old cartridge to solder a circuit on the slot-lanes. Maybe there is a chance to emulate the ROM-Access from the console by using an Arduino or connect it to the PC somehow. Because access-rates are relativly slow, it should not be a problem. But to start, an emulator should be fine...

In case it isn't clear, graphic tiles have to be copied from ROM to VRAM to be displayed. The GB video hardware can't directly access ROM. So graphics aren't necessarily in any standard arrangement in ROM, aren't necessarily aligned to 16 bytes or even in native format (text fonts are often reduced to 1bpp, other graphics might be compressed with various custom codecs)

I understand! So this is also why it is not possible to simply "scan" for graphicsdata in the ROM. So the only place where it is structured and clear is at the moment it gets written to the VRAM. But if one would manipulate the content, he must look for the code which transfers this from ROM to VRAM.

If i understand the docs, the Nintendo logo is first placed from the ROM onto the screen, get scrolled and sound is played and after that, it is compared with the internal copy of the data. If they don't match, the console is halted. So i could place a custom image there and it should be displayed, or?
How about the checksums found in the header? I did not read anything about where they get used.

Hmm, i must admit that i first thought that older consoles are easier to hack and understand, but it seems contrarywise. Because nothing is really fixed and every game developer could do like he want (no Game Engines or IDEs) it's always reverse engineering. But it's fun! ;-)

17
Newcomer's Board / Re: Learn about ROM file formats
« on: March 19, 2016, 12:09:21 pm »
xor a,a results in zero. The code you've pasted clears the memory from 0xC000 to 0xDFFF (which is the GB's 8KB work RAM)
Ups  :-\ Guess i was barking up the wrong tree...
At first "xor a,a" (or sometimes written as just "xor a") looks silly and one would expect "ld a,00h" to do the job. But looking into the Mnemonics tells that "xor" takes 1 machine cycle and "ld" takes 2. Wow, every cycle counts, eh? ;-) Why those Z80 developer did not give a command like "clear a" or such... well...

There's a small bootloader program in an internal ROM on the Game Boy CPU that decodes it
Oh, i see. I found the bootloader here http://gbdev.gg8.se/wiki/articles/Gameboy_Bootstrap_ROM. It would take some time for me to understand it.

Next, i will follow the advice to study the registers.

18
Newcomer's Board / Re: Learn about ROM file formats
« on: March 19, 2016, 09:17:55 am »
Well, my first efforts where to decode the Ninendo logo at 0104h. Docs tell that it is bitmap, so a stream of bits was fast generated. But how to arrange them?

Because it is raw imagedata without any additional informations like size and such, i was not able to do it. So i search the web and found it described here http://stackoverflow.com/questions/21119904/how-to-decode-the-nintendo-logo-from-gameboy

Well, i guess this is one thing one just had to know about, to do the job. An i also guess there are many more things i had to learn about the console ;-)

Thanks a lot for pointing out that code is not Z80 but a similar kind of it. So i had to get the right disassembler to read the code. Any hints here?

Next thing would be to understand what is going on in the code. Because CPU codes don't do anything itself, i guess all depends on side effects of writing to magic memory addresses, registers or io-ports. So it seems a good idea to replace the addresses found in the disassembled code with functional names.

Yes, i will try to understand the whole game and every function. I think later i know where graphics, sound and text are stored and how they get used. Maybe i am able to change the code to do like i want (patch lifes, levels, spirtes or texts). This is my final goal.





March 19, 2016, 09:32:45 am - (Auto Merged - Double Posts are not allowed before 7 days.)
The Nintendo Logo in the header is $30 bytes, which is 3 tiles, which probably forms a 24x8 pixel image.  EDIT:  but even that seems small.... maybe it's stored 1BPP to make a 48x8 image?  I'd have to research it.  =x

It seems to be 1bpp. For some reason i don't know, the bytes of the logo:

Code: [Select]
CE ED 66 66 CC 0D
00 0B 03 73 00 83
00 0C 00 0D 00 08
11 1F 88 89 00 0E
DC CC 6E E6 DD DD
D9 99 BB BB 67 63
6E 0E EC CC DD DC
99 9F BB B9 33 3E

have to be arranged like this:

Code: [Select]
C 6 C 0 0 0 0 0 0 1 8 0
E 6 C 0 3 0 0 0 0 1 8 0
E 6 0 0 7 8 0 0 0 1 8 0
D 6 D B 3 3 C D 8 F 9 E
D 6 D D B 6 6 E D 9 B 3
C E D 9 B 7 E C D 9 B 3
C E D 9 B 6 0 C D 9 B 3
C 6 D 9 B 3 E C C F 9 E

As you can see, there are 6 bytes makeing up one row. And 8 rows for the whole image. In binary the later codeblock will look like this:

Code: [Select]
110001101100000000000000000000000000000110000000
111001101100000000110000000000000000000110000000
111001100000000001111000000000000000000110000000
110101101101101100110011110011011000111110011110
110101101101110110110110011011101101100110110011
110011101101100110110111111011001101100110110011
110011101101100110110110000011001101100110110011
110001101101100110110011111011001100111110011110

To improve the visuality of the image, i had replaced the zeros with blank:

Code: [Select]
11   11 11                             11       
111  11 11        11                   11       
111  11          1111                  11       
11 1 11 11 11 11  11  1111  11 11   11111  1111
11 1 11 11 111 11 11 11  11 111 11 11  11 11  11
11  111 11 11  11 11 111111 11  11 11  11 11  11
11  111 11 11  11 11 11     11  11 11  11 11  11
11   11 11 11  11 11  11111 11  11  11111  1111

But i'm really confused about the bit-arrangement of the bytes. It's mixed up with nibbles (4-Bits) of bytes found.


March 19, 2016, 10:06:06 am - (Auto Merged - Double Posts are not allowed before 7 days.)
So, i downloaded "Gameboy Assembler Pro" from the utilities-section of this site for disassembling the code. Now, we can be shure that the instructions are correct.

Starting at 351h, here are the first lines. Could anybody help me to get their meaning?

Code: [Select]
#org 351

Label351:
 ld sp,E000  ; load 16-Bit register SP (Stackpointer) with e000h. SP is used for callback-addresses or pushed values
 ld hl,C000   ; load 16-Bit register HL (H and L) with value c000h
 ld bc,2000  ; load 16-Bit register BC (B and C) with value 2000h

Label35A:
 xor a,a      ; xor value a with itself. Maybe some kind of decryption? xor itself twice will result in originate byte
 ldi (hl),a    ; store value of "a" at memory location pointed by HL (initially c000h) and then increment HL (because of ldi command)
 dec bc      ; decrement BC value. It seems to contain the length of the block to handle
 ld a,b       ; load accumulator "a" with value of "b" (MSB of 16 Bit register BC)
 or a,c       ; binary or it with value of "c". So "a" is only zero if B and C have the value zero
 jr nz,Label35A   ; this seems to be a loop until register a (accu) is zero.

; ok, i'm pretty shure this will decode data inplace at memory location c000h for 2000h bytes.

ld hl,FF8A  ; this seems to be a magic address...
 ld c,75
 xor a,a

Label367:
 ldi (hl),a
 dec c
 jr nz,Label367  ; another decoder?


19
Newcomer's Board / Re: Learn about ROM file formats
« on: March 18, 2016, 04:31:58 pm »
Disch, i understand the concepts of bitmap images. Whats missing was how they are arranged (the planar configuration). Even this is similar to Tiff without headers...

Ok, i research this myself. Just another step in understanding the console. My goal is indeed to understand how everything works.

How can a software find images in the ROM? Are there lookuptables at some well known location?
I also wonder which programming language was used to build the games. I don't think they where coded in ASM. Maybe C or C++ ? Or did rhey use Game Enginges in that era of computer games?

Well, how can i go further in understanding the code found at position 0x351 ?
Are ypu able to interpret what is going on there?
The list of calls seems like a being a main loop.

20
Newcomer's Board / Re: Learn about ROM file formats
« on: March 18, 2016, 03:23:11 pm »
WOW, THANKS A LOT, YOU BOTH !  :beer:

This give a good start. Now i have learn about the hardware and the layout of the ROM data. I also could "decompile" some ROM-Infos from the information found in the links:
The ROM is "Star-Trek Generations - Beyond the Nexus". The file-suffix is ".gb".
 - Its game title at 0x134 is "GENERATIONS"
 - It has 128k in size and ist of cartridge type 0x01 (ROM+MBC1)
 - Byte 0x149 tells 0x00, so the cartridge has no extra RAM on it (ROM-Only cartridge)
 - Byte 0x143 is 0x00, so it is a black+white only game (plain old native GB). No color.
 - The entry-point at 0x100 tells: F3 C3 51 03 (in hex) I decoded them by the Z80 Opcode list found here http://imrannazar.com/Gameboy-Z80-Opcode-Map this Assembler code:
F3 = DI (Disable interrupts)
C3 = JP (2 bytes with addess follow, LSB first, so it will be "JP 0x0351"
So, code goes on at this address.
Next it put the ROM file into an Disassembler i found on the web here https://www.onlinedisassembler.com/odaweb/.

Well, but how to go on now? My Assembler skills are a bit rusty ;-)

The code at 0x0351 look like this:
ld sp,0xe000
ld hl,0xc000
ld bc,0x2000
xor a
ld (0x780b),hl
or c
jr nz,0x035a
ld hl,0xff8a
ld c,0x75
xor a
ld (0x200d),hl
call m,0x79cd
inc b
ret p
adc a,h
and 0x0f
cp 0x0f
jp z,0x036b
call 0x0738
call 0x0470
call 0x0392
call 0x03ed
call 0x1dc5
call 0x05cf
call 0x0835
call 0x0150
jp 0x071e
(i'm not shure if it is allowed to post or attach the whole disas file here...)

I also found this GB Startscreen image in the header. It is called "bitmap" in doc, but it this really a simple bitmap graphic?
And how to arrange the bits to get the logo? The Screen resolution is 160x144 Pixels, but this would give about 3k of data for one screen. The are much more less bytes in the logo.

As you see, i begin to learn and it makes a LOT of fun!!!

Pages: [1] 2