#117266 - MrD - Fri Feb 02, 2007 11:34 pm
I'm just wondering, why wasn't homebrew development for the Game Boy and Game Boy Color as popular and widespread (for want of a better word) as Game Boy Advance development?
Was it due to a lack of available development equipment or problems with the architecture, or what?
(I'm assuming this is the case, which it may not be. But that's what it looks like to me.)
_________________
Not active on this forum. For Lemmings DS help see its website.
#117267 - tepples - Fri Feb 02, 2007 11:37 pm
| MrD wrote: |
I'm just wondering, why wasn't homebrew development for the Game Boy and Game Boy Color as popular and widespread (for want of a better word) as Game Boy Advance development?
Was it due to a lack of available development equipment or problems with the architecture, or what? |
Both. By the time I got into GBA development (early 2002), GBC flash cards were already unavailable. In addition, the ARM architecture is a lot more conducive to the C language, which was popular among Windows game programmers at the time, than the GBZ80 is.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#117313 - sgeos - Sat Feb 03, 2007 8:04 pm
I looked into it... no tools and Z80 was required. I did learn a little Z80, though.
-Brendan
#117324 - keldon - Sat Feb 03, 2007 9:13 pm
I was just reading the February edition of the [url=http://linuxformat.co.uk]linux format[url] magazine and it recommended "getting a Game Boy emulator and learning Z80 assembly language" if you had an interest in assembly language!
#117335 - HyperHacker - Sat Feb 03, 2007 11:07 pm
I did a bit of GB dev, never really finished anything. Mostly ROM hacks. It's fun, but the lack of hardware made it a pain, and I eventually moved on to the DS. However, I still intend to write a Game Boy emulator/debugger and that will require me to make a flash cart since all the technical documents vary slightly or lack information.
_________________
I'm a PSP hacker now, but I still <3 DS.
#117345 - keldon - Sun Feb 04, 2007 12:41 am
Are you aware of the no$gmb emulator/debugger? There is also full documentation for it on the site!
#117346 - Miked0801 - Sun Feb 04, 2007 12:49 am
I did professional work on the DMG/GBC for its whole cycle. Neat platform. Easy to udnerstand and very straight forward - if you could get around having to do everything in bastardized Z80 :)
#117348 - keldon - Sun Feb 04, 2007 1:34 am
I thought its assembler was pretty easy to work with! There were a few corners but for me it was probably because I was young.
#117488 - Miked0801 - Mon Feb 05, 2007 2:32 am
The Z80 for the GB only contained < 1/2 the opcodes and registers of normal Z80 is all. Game Gear was much better in that respect.
#117489 - HyperHacker - Mon Feb 05, 2007 2:39 am
| keldon wrote: |
| Are you aware of the no$gmb emulator/debugger? There is also full documentation for it on the site! |
Yes, but it's terribly buggy and lacks some features such as read breakpoints, execute breakpoints in RAM (it just crashes), table files, etc. It loves to randomly stop working, claim I don't have a valid license, crash, or whatever. Just so many bugs...
I've also used bgb which emulates nicely but its interface makes me want to stab someone, especially since switching windows at the wrong time will deadlock it.
The only other debugger I know of is VBA but it has very few debugging features (RAM editor, disassembler, OAM viewer, and I think that's it) in GBC mode.
_________________
I'm a PSP hacker now, but I still <3 DS.
#117491 - wintermute - Mon Feb 05, 2007 3:01 am
| HyperHacker wrote: |
| keldon wrote: | | Are you aware of the no$gmb emulator/debugger? There is also full documentation for it on the site! |
Yes, but it's terribly buggy and lacks some features such as read breakpoints, execute breakpoints in RAM (it just crashes), table files, etc. It loves to randomly stop working, claim I don't have a valid license, crash, or whatever. Just so many bugs...
|
I used no$gmb for commercial GBC dev, it was a godsend.
The breakpoint in RAM thing I'll give you but that was very rarely needed. The rest just makes me think "Yarr"
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#117500 - Miked0801 - Mon Feb 05, 2007 4:25 am
Buggy my ass! That program was the best thing ever for gameboy development. It DID (does) have read breakpoints & execute breakpoints. It also had remarkably good timing emulation for HBlanks and serial code. That, with all the exception warnings made it 100x better than anything else (Nintendo dev crap included.) My only complaint was that it used a 256 color window for the display such that some of our "hi color" images only partially showed.
Yes, we gladly paid Martin much more than he asked for a license to this invaluable tool.
Yarr indeed.
#117501 - Miked0801 - Mon Feb 05, 2007 4:33 am
-1 to me. Yes, BPs with code executed in RAM were broken. We kept very little code there though so no big deal to us. Just some self modifying palette loading code and the HBlank jump vector.
#119567 - HyperHacker - Sat Feb 24, 2007 10:40 am
What, how do you activate these read breakpoints? I didn't see any mention of it in the manual. Also the debugger has memory leaks, it seems to skip interrupts while tracing, it randomly decides to stop working until I put it in Win98 compatibility mode (or take it out if it already is) and sometimes that doesn't even fix it, it crashes if I try to reload the ROM or sometimes just for no apparent reason, certain keys on the keyboard are hardcoded to GBC buttons, etc.
And some of you might be surprised just how often non-ASCII character sets and execution from RAM come in handy on such a weak system.
_________________
I'm a PSP hacker now, but I still <3 DS.
#119587 - sgeos - Sat Feb 24, 2007 2:22 pm
| HyperHacker wrote: |
| And some of you might be surprised just how often non-ASCII character sets and execution from RAM come in handy on such a weak system. |
On such a weak system? Using ASCII is insane if you ever intend to localize your program. ASCII should be converted to some sort of precalculated font encoding before it hits the message engine.
-Brendan
#119609 - tepples - Sat Feb 24, 2007 6:27 pm
Even a precalculated font encoding may not fix all if you are trying to localize to a language that uses combinations of diacritics (e.g. Vietnamese), contextual changes to the character shape (e.g. Hindi, Arabic, Thai, or Korean) or ideograms (e.g. Chinese, Japanese). In these cases, the entire font might not fit in VRAM, and you'll have to render only the visible text to a pseudobitmap in VRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119614 - Miked0801 - Sat Feb 24, 2007 7:23 pm
| HyperHacker wrote: |
What, how do you activate these read breakpoints? I didn't see any mention of it in the manual. Also the debugger has memory leaks, it seems to skip interrupts while tracing, it randomly decides to stop working until I put it in Win98 compatibility mode (or take it out if it already is) and sometimes that doesn't even fix it, it crashes if I try to reload the ROM or sometimes just for no apparent reason, certain keys on the keyboard are hardcoded to GBC buttons, etc.
And some of you might be surprised just how often non-ASCII character sets and execution from RAM come in handy on such a weak system. |
Use (memory address)?
Or (n)! for read or write.
Very powerful, very easy to find memory leaks and such. We ran it under 95/98 without too many issues. Yes, over a lot of time it would slow, but most debug sessions last under 5 minutes so no big deal.
And preloaded fonts on a system with such limited hardware would be insane. We wrote a font render system and used a byte lookup to get to each character. Works great for a non-asian release. For Japanese, we used a limited shift-jis and no Kanji just to keep the symbols small enough to be useful.
And exectuion from RAM? We used it for interrupt vectoring, fast palette loading (ld hl,n at 3 cycles per byte), a tiny bit for ROM page flipping, and bits of esoterica here and there. A vast majority of stuff didn't need RAM to work, which is good because the system had so little.
Wow, had to go relook at some old Potter code as some memories had faded :)
#119620 - sgeos - Sat Feb 24, 2007 8:49 pm
| tepples wrote: |
| Even a precalculated font encoding may not fix all if you are trying to localize to a language that uses combinations of diacritics (e.g. Vietnamese), contextual changes to the character shape (e.g. Hindi, Arabic, Thai, or Korean) or ideograms (e.g. Chinese, Japanese). |
All of these languages can be handled by using unique code points for each unique display glyph. You need to figure out what characters you will actually use. The font only needs to contain this subset of the writing system. To make things simple, the font probably wants to be arranged in ascending order. You'll probably want to precomile your text so that the version in your ROM works with the font.
| tepples wrote: |
| In these cases, the entire font might not fit in VRAM, and you'll have to render only the visible text to a pseudobitmap in VRAM. |
You will need to dynamically load glyphs into VRAM.
Assuming ASCII or an ASCII like writing system is bad because the assumptions that come along with ASCII can and do cause problems. The space for the font, text bloat and the rendering system may hurt to a lesser extent.
For what it's worth, most Japanese GB/GBC games only used kana, or they used kana and a small subset of kanji specific to the game.
-Brendan
#119626 - tepples - Sat Feb 24, 2007 9:42 pm
| sgeos wrote: |
| All of these languages can be handled by using unique code points for each unique display glyph. You need to figure out what characters you will actually use. The font only needs to contain this subset of the writing system. |
Unless the player can enter text. In this case, the program has to do all the contextual magic by translating characters that the player enters into glyphs sent to the screen.
| Quote: |
| For what it's worth, most Japanese GB/GBC games only used kana, or they used kana and a small subset of kanji specific to the game. |
What do Chinese games use? Chinese has no cop-out comparable to kana-only Japanese writing.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119645 - HyperHacker - Sun Feb 25, 2007 12:32 am
I guess you guys didn't push the hardware as far as I did. Try hacking Pok?mon G/S! :-p Adding on to a game that already uses just about all available RAM and VRAM and the largest ROM size the MBC3 can handle is interesting if nothing else. (And you can't upgrade to MBC5, or you lose the clock.)
I've never looked at a Chinese game, but I'd assume they use something like 12x12, 16x16 or variable-size Kanji using a VWF-like system. (8x8 Kanji? No thanks!) It's a nice trick, instead of loading the font to VRAM and writing tile numbers to your map for each letter, you blank an area of VRAM and write incrementing tile numbers, then load the characters from ROM into VRAM as needed. E.g. if you wanted to print "Hello" then you'd just write tiles 0 1 2 3 4 and load the letters H, e, l, l and o into those tiles in VRAM. (You could get clever and use 0 1 2 2 3 but then you need to keep track of which letters are loaded.) What makes this system nice is its flexibility. You could, assuming you had sufficient ROM space, implement all of Unicode. You can do variable-width fonts by shifting the bits around as you load them. Apply bold/italic/underline effects at runtime. All manner of fun stuff like that.
You'd be surprised how many games do use preloaded fonts, though, but I don't think I've ever seen an official game use ASCII.
Also, my debugging sessions tend to last hours, but are interrupted every so often by the debugger leaking so much memory it starts to get confused and draw its interface wrong. I suppose ROM hacking is a bit different in this aspect.
Miked0801, from my experience and the manual, that's not what ? and ! do. (foo)! breaks on any write to foo, and (foo)? breaks on any write if the value written is not the current value.
_________________
I'm a PSP hacker now, but I still <3 DS.
#119648 - sgeos - Sun Feb 25, 2007 12:34 am
| tepples wrote: |
| sgeos wrote: | | All of these languages can be handled by using unique code points for each unique display glyph. You need to figure out what characters you will actually use. The font only needs to contain this subset of the writing system. |
Unless the player can enter text. In this case, the program has to do all the contextual magic by translating characters that the player enters into glyphs sent to the screen. |
For something like Arabic, maybe; I don't know enough about the language. Nobody seems to mind that they have to choose between upper and lower case in English. I could see forcing Europeans to select the fancy vowels one by one, although a proper accent system would certainly be friendlier. Some lexical transformations will probably have to be made. "To upper" is a good English example. Exactly what needs to be done will depend on your game and your publisher. You still might be able to precompile.
Korean input would probably be a little different.
| Quote: |
| What do Chinese games use? |
Now? Chinese games use Chinese characters. Mainland China uses simplified Chinese, and Taiwan uses traditional Chinese. Hong Kong used traditional characters but is starting to use more simplified characters. I don't know what they used in the days of the gameboy. English? Really old Japanese NES games certainly used English.
For what it's worth, almost all Japanese games use kanji now. (They are more or less traditional Chinese characters. Slightly simplified.)
| Quote: |
| Chinese has no cop-out comparable to kana-only Japanese writing. |
China has the Bopomofo and Pinyin. Children learn the phonetic system, but they quickly stop using it for communication. I had actually never seen the Bopomofo before today.
EDIT: reply to HyperHacker
| HyperHacker wrote: |
| I've never looked at a Chinese game, but I'd assume they use something like 12x12, 16x16 or variable-size Kanji using a VWF-like system. (8x8 Kanji? No thanks!) |
14x14 is a nice size for a bunch of reasons. 8x8 won't work for anything but the simplest characters. Complex characters won't show up even at 16x16. (Admittedly, that was a goofy example. 44 strokes is a lot; nobody uses that character.)
| Quote: |
| You can do variable-width fonts by shifting the bits around as you load them. |
Ack. Now I know why people use objects for variable width text.
| Quote: |
| Apply bold/italic/underline effects at runtime. All manner of fun stuff like that. |
Bold doesn't mix with complex kanji at 16 points.
| Quote: |
| but I don't think I've ever seen an official game use ASCII. |
Because they learn quickly? ASCII is evil. =)
-Brendan
#119660 - tepples - Sun Feb 25, 2007 3:29 am
| HyperHacker wrote: |
| You'd be surprised how many games do use preloaded fonts, though, but I don't think I've ever seen an official game use ASCII. |
VROM on the NES was 8 KiB, split into equal banks for background tiles and sprite tiles. Each 4 KiB bank could hold 256 different tiles. An uppercase-only ASCII chart would take about 18% to 25% of that depending on which dirty tricks a program used, such as repurposing unused punctuation, repurposing unused letters such as Q and Z for graphics if the game don't have high score initials input, etc. Luckily, 25% of background VROM (64 tiles) was the same size as the 1 KiB sub-banks that several mappers used, and a lot of games would bankswitch between the graphics and the text tiles when the raster hit a certain scanline.
I can tell you that Lode Runner, Mario Is Missing!, Adventures of Lolo 3, Little Nemo The Dream Master, I Can Remember, and several other NES games bearing the Official Nintendo Seal used a block of glyphs in ASCII order. So did (unlicensed commercial) Tetяis, Klax, and Spiritual Warfare, and so did the Earthbound prototype. The fact that 0x20 through 0x5F straddled a sub-bank boundary didn't mean much; a simple add instruction could map characters in 0x20-0x5F to glyphs in 0xC0-0xFF to fit them all in one sub-bank. The Mega Man games for NES used ASCII encoding for strings in the ROM, but the equivalent of cputs() translated ASCII characters to VROM glyph numbers.
What would popular NES games' fonts look like if rearranged into ASCII? Wonder no more; here are numerous 8x8 pixel fonts.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#119837 - Miked0801 - Mon Feb 26, 2007 8:32 pm
| HyperHacker wrote: |
...
Also, my debugging sessions tend to last hours, but are interrupted every so often by the debugger leaking so much memory it starts to get confused and draw its interface wrong. I suppose ROM hacking is a bit different in this aspect.
Miked0801, from my experience and the manual, that's not what ? and ! do. (foo)! breaks on any write to foo, and (foo)? breaks on any write if the value written is not the current value. |
Ok, I went back and tried to pull up the manual for GB and it wouldn't let me - the .hlp format is not supported anymore :P
I am quoting from my more recent knowledge of No$GBA. I guess he added some features from when I last used no$gmb a few years back.
But on your debug sessions: Do you really have to play the game hours at a time without resetting the debugger? That seems more like playing and less like debugging from my experience. Or more likely a difference in what we do as you state.
Finally, yes we pushed the hardware pretty dang far. VBlank being precious, VCount interrupts ended up doing all sorts of fun things for us. High color, BT loads, splits, etc. It was amazing how much No$gmb made possible over the boat anchor crap from Nintendo.
#124056 - Abscissa - Mon Apr 02, 2007 9:28 pm
| sgeos wrote: |
China has the Bopomofo and Pinyin. Children learn the phonetic system, but they quickly stop using it for communication. I had actually never seen the Bopomofo before today.
|
That Zhuyin/Bopomofo looks remarkably similar to Japanese -kana. Kinda makes sense though, since both originated as phonetic offspring of traditional Chinese symbols. I didn't look closely enough to see how much the sounds actually match up though, or if it's merely a visual similarity.
(Sorry for resurrecting a dead thread.)
#124058 - HyperHacker - Mon Apr 02, 2007 9:36 pm
Yeah, ROM hacking is a lot different from plain coding. I might have the debugger open several hours to hack new routines into the game, trace routines and references, look for pieces of code, etc. Pretty much writing the code right in the debugger, then copying it out. (I do use an assembler for the longer routines though.)
| sgeos wrote: |
| Quote: | | Apply bold/italic/underline effects at runtime. All manner of fun stuff like that. |
Bold doesn't mix with complex kanji at 16 points. |
I was thinking English characters, actually. And that one you linked to doesn't even show up despite having Asian fonts installed. <_<
_________________
I'm a PSP hacker now, but I still <3 DS.