NeX, if this is about what we talked about two days ago...
A0-A8 (A total of 8+1 line) are responsible for the actual logo. If those are correct, and all other lines are grounded, the logo should show, but the game won't boot. If you see a pattern of lines or dots in the logo, whether the logo is scrambled or not, one or more of the data lines are loose. If you don't see a pattern of lines/dots, the data lines are probably ok, at least.

Also, if you e-mail me the ROM, and I can produce a list of scrambled logos that you can compare against to pinpoint which address lines might be loose.

2,034

(44 replies, posted in General Discussion)

Phunny because it's trooo!

2,035

(100 replies, posted in General Discussion)

On his Tumblr...

http://josh-kaplan.com/post/294164486/murraythenut-dick

That's sooo me...

2,036

(100 replies, posted in General Discussion)

*snarky comment coming in*

I think he himself honestly believes in his idea, but I'm doubtful. He doesn't show any proof whatsoever that he has a working prototype. He doesn't even show any proof whatsoever that he knows what he's talking about. Quite the opposite actually.

So, he's going to use mGB... In other words, he's not going to write any Gameboy code. An Arduino eh? So he's going to turn the Arduino into a homemade MIDI keyboard and cut out the ArduinoBoy middleman. At best. It wouldn't surprise me if he's actually going to put two Arduinos in there... one running an unmodified copy of AB and one that sends MIDI. What is he planning to actually do? Cut out the buttons from a DMG and put his keyboard there? His description is not exactly clear.

I also don't see what the hell he needs two grand for, unless maybe he's looking to cover all of his developmental and material costs for the first run and be able to sell his stuff for a pure profit

And the name...? Is DMG-10 supposed to be a play on both DMG-01 and DS-10?

I don't see his idea flying anytime soon. sad

2,037

(36 replies, posted in Nintendo Handhelds)

Ah, looks really, really broken... But out of curiosity, can you make anything appear on the dead part by adjusting the contrast? Even just make the area completely black?

2,038

(36 replies, posted in Nintendo Handhelds)

Let me see the screen with LSDj running. Or anything that has stuff going on on the whole screen.

bleo wrote:

What if I use LSDJ on a DMG for a bassline and drums, mGB on a gameboy light controlled by piggy via midi running on a gp2x for some chords, and chipsounds VST on my netbook and vocoded for the melody?  Then I'd be FORCED to chose one hardware and one software platform.  How would that help anyone?  Tags should remain as is. I suggest if you don't like gameboy tracks, as soon as you realize what is it is, skip it.  That's what I do wink

Exactly. And with my suggestion this would still work... The duiferent platforms etc would just be listed under their respective captions.

2,040

(9 replies, posted in Other Hardware)

I just found this... An Arduino shield for the YM2151 chip! Looks pretty cool.

http://www.ooishoo.org/ym2151shield

2,041

(11 replies, posted in Sega)

I've seen a Sega CD loader, but you apparently can't use it on ROMs. You must compile your own code that's using it. I'll see if I can find the link.
Also, I'm under the impression that Sega CDs are relatively hard/expensive to come by, so maybe this isn't the best solution unless you already own a Sega CD...?

My original idea for this was to let certain tags be platform tags, other software tags, yet other genre tags. They would work exactly like any other tag, but the tags would be shown in groups for easy access, in tho song listing page, on individual song pages etc. What thinks?

trashy: It's under the gbdev.gg8.se domain these days. Gameboydev.org is back in Jose's hands and used only for selling cartridges now. Also, the info on the wiki is not unique, but it might still be helpful.
http://gbdev.gg8.se/wiki/articles/Main_Page
http://gbdev.gg8.se/forums/index.php

And of course, as I said before:
http://gameboy.mongenel.com/  <- and click GBC ASMSchool

Just so we don't exclude any possibilities... What is the speed rating of the flash chip? The speed rating is the last number in the part number, after a dash. It's typically something like -75, -90 or -120 and tells you how many nanoseconds the chip will take to deliver the requested data. Lower is better. -120 should work, -90 should definitely work, but anything above -120 might not. I find it hard to believe that such a big chip would be too slow, but you never know.

Can you tell me something about the scrambled logo?
Does it look the same every time? If no, then something is seriously wrong. ( smile )
Does it have any resemblance of the Ninty logo? If yes you've probably swapped or otherwise screwed up the data lines.
If neither of those, (same dirt every time) you're reading data from somewhere else in the ROM.

If the flash chip is actually programmed correctly, then there's something wrong with the address lines.

Any unused address pins should be grounded, otherwise they might fluctuate and this can cause a complete failure. However, since your cart doesn't use MBC5, I'm assuming it's using MBC3 or maybe MBC1. (But not MBC2, as MBC2 couldn't even handle the 8 MBit LH538...) Both MBC1 and MBC3 have a max size of 16 MBits, so you should be able to get the full size. You should be able to connect at least A19 by connecting it to A19 of the ROM. If there's only 1 unconnected pin left on the MBC, that's where A20 should go. Or you could ground A20 and live with having only 8 MBits for now.

Oh and if you haven't seen these:
http://www.ziegler.desaign.de/32mbit.htm
and

i don't have any actual practical experience, but perhaps I can help you anyway. You know where I am.

2,046

(18 replies, posted in Nintendo Handhelds)

Tip: Samples sound much better on DMG than on GBC or GBA.

belial wrote:
nitro2k01 wrote:

An integer table, even 16-bit integer, is better than that float table

I bet i misunderstand you and maybe this should be discussed somewhere else, but why using an integer table? An integer table of sine values would contain exactly 3 entries {-1, 0 1}.

Oh, you need to scale it, of course. If you want an object to swing 40 pixels from side to side in a sinusoidal curve, you could pre-calculate y=int(20*sin(x)). Actually you could probably get away with calculating 10*sin(x) and multiplying the table values by 2.

Which brings me to another point... Integer multiplication and even division by 2 and multiples of 2 is cheap. It can be easily written as a shift operation. y=4*x is equivalent to y=x<<2 for example.

Another trick, which I don't think the C compiler has support for, is fixed-point arithmetic. You could for example define that in an 8-bit number, the lower two bits are the decimal part and the upper six bits are the integer part. So, for example, you could represent a number like 5.75 without rounding:

Bin: 0001 01.11

This would of course be stored in an 8-bit register as hex: $17 (Bin: 00010111)
The logic is that bits below decimal point get the values 1/2, 1/4, 1/8 etc.

Adding two of these numbers works all the same like any other number of that bit size. If you multiply two numbers fixed-point numbers however, you must realign the number. Consider that you multiply 2*3 in the notation above:

"2.00" = Bin: 0000 10.00 = Hex: $08
"3.00" = Bin: 0000 11.00 = Hex: $0C

$08 * $0C = $60
Bin: 0110 0000 = Hex: $60

Here you need to divide by 4, or as it can also be done, shift right twice, to get the correct answer:

Bin: 0001 10.00 = "6.00"

However, when you multiply fixed-point * actual integer, you don't need the realignment step.

I think any tutorial to programming an 8-bit CPU should talk about binary numbers and 8-bit math tricks. Not as a thing that you need to go through by necessity, but as something that is actually useful. But maybe that scares people off?

Oh, and you're right that there's seems to be a lack of GB tutorial. There's one though...
http://gameboy.mongenel.com/ <- and click GBC ASMSchool
It's geared towards ASM however. Which I personally think is the way to go in the long run.

Maybe I should get my ass off the couch and actually write a tutorial myself. I've been wanting to do this for a while, but lazy and stupid in the same as being an elitist dickhead is almost a guarantee that you'll never manage to write something you're satisfied with.

Now I'm going to sound like a massive dick, but I don't like this paper at all.

It's actually mostly factually correct as far as I could tell when skimming it through, but it feels very rushed. There are a few couple of small things that are wrong, like calling the MBC BSC, but that less important. But what I'm more worried about is that I'm wondering if the complete noob is actually going to learn anything substantial from the paper. It's written in such a way that I'm getting the feeling it was made to meet a school deadline, not out of a genuine will to teach. A lot of things could be probably be described in more understandable ways.

I'm bothered by the theory sections about transistor/logic and NTSC. They don't really fit in. The transistor/logic section could probably be scrapped. If you know about these things, you do. If you don't, that short text isn't going to make much of a difference for you. The NTSC section could probably be replaced with an actual diagram of how the screen is drawn, and when you can and can't write to it.

Then there's the coding guidelines. The first 3 points are sound advice, but last one isn't really. The <=, < etc operators typically have no or a very small overhead compared to == and !=. we only have a limited time window to perform our calculations (vertical synchronisation phase) <- That's not really correct. Just because you can't write freely to the display during most of the time doesn't mean you can't do math. And why make a float table of sine values? An integer table, even 16-bit integer, is better than that float table. And even so, theres no explanation on how you're actually supposed to use the lookup table.

The whole idea that the Gameboy is well documented but it is difficult to collect all the distributed informations on the internet. is largely untrue. There are a couple of good collected sources. Most importantly PANDocs which is a collection of a lot of small documents (some of them quoted in the paper) that was assembled about 10 years ago. It's both more informative and accurate than the quoted sources. (No undocumented GB cart pins etc...) Then there's devrs.com/gb which has many dead links nowadays but is still a good starting place. A little more research would've revealed those.

The paper doesn't at all mention that there are in fact commercial flashcarts for sale to this date. See here for example.

So uhm yeah... I'm sorry for the complete smackdown, but I honestly think a lot of things in the paper could have been better. Forward this post to Belial (or maybe not.)