abrasive wrote:
nitro2k01 wrote:

The problem with this cart, and "jose"carts as well is that they can't switch out bank 0. For that reason hey can't do multiple ROMs, since each program is dependent on having it's own "bank 0".

CAPTAIN SPECULATION STRIKES AGAIN.

I will neither confirm nor rule out the presence of a bank remapping feature in the final cart, at this point.

If we are to nit(ro)pick, the text is pretty clear.

Features:
(List of three features)
These features are provisional. (And then after that:) This is not a multi-boot or multi-file cartridge.

But y'know, if it turns out it's possible to do it in hardware, sure, why not.

Ah! (De)compression! That's something that I don't think the GB can do comfortably, really. The NGPC apparently has 16-bit CPU. Then there's the (perhaps small) problem of the user turning off the power in the wrong moment while writing to bank 0 and locking yourself out of the the bootloader, so you have to fix it over USB. On the other hand, the compression method might just work. I'll have to do some experiments.

My original idea was to only overwrite bank 0, and store the rest of the ROM banks in higher ROM banks, and patch the ROM switch routine in each ROM to go to those higher banks. Painful to get right, but will work really fast once it's in place and works.

Can't speak for NGPC. Perhaps there are some circumstances that make it easier to do on the NGPC, eg built-in bank switching in the console. On GB it's a pain, though.

herr_prof wrote:

Yea if you compile a multirom it would work, but what about the sram?

PAGING DR NITRO2k1

Was ist das? Eine page aus Herr Professor Peter Lewis Swim?!

Actually, no that wouldn't work.

The problem is this. The GB CPU can only address 64 kilobytes of memory. So to access more than that, you use so called bank switching. There are two ROM memory areas areas available from a regular GB cartridge. One area is a fixed area which points to the bottom 16 kilobytes of the ROM chip. (Bank 0) Then there's a switchable area which can address one variable 16 kB area at a time.

The problem with this cart, and "jose"carts as well is that they can't switch out bank 0. For that reason hey can't do multiple ROMs, since each program is dependent on having it's own "bank 0".

Now there's a way around this. Since this is a flash cartridge, and the Gameboy can write to the flash memory, you could use a software method where a piece of code on the Gameboy writes a new bank 0 for every newly loaded ROM. Then the ROM also needs the rest of its banks, and there are different methods of solving that. But either way it'll be hackish, and there's the risk of temporary failure if he cartridge loses power during this operation. In that case, it would need to be reprogrammed using USB.

Normal LittleFM operation is planned to be supported and poses no problem, however.

I was trying to find out if they were perhaps bigger than they needed to be because of a too high voltage rating.

That's indeed a good placement for a jack. I've done a couple P******* mods where I've glued the jack to the back of the battery compartment with super glue. Has worked for me.

Now tell me, what's the capacitance and voltage rating on those caps?

1,735

(8 replies, posted in Tutorials, Mods & How-To's)

So, uhm, you're tapping the display signals.

See: http://blog.gg8.se/wordpress/2009/11/23 … d-palette/

The lower right point in that 2*3 matrix should give similar results as the lower left one. This should work extra well with Shitwave, as it draws something on the screen which is at least somewhat like the waveform it outputs.

The second pin (actually third, since the outermost one counts as a pin too) is the power supply for the LCD, -19 V or thereabouts. Very dangerous for the electronics.

The 7th pin from the left is one of the lines for reading the state of the buttons. It should be pretty boring. Sure you got that one right?

Don't have many moniez, don't have a NES and don't know 6502 asm, so this thing is not for me. Cool nevertheless, of course!

jarek wrote:

Download code to the RAM on the cartridge or the NES? The cartridge has no RAM, it's a microcontroller->CPLD, with the CPLD passing opcodes to the 2a03 chip to synthesize notes.

Oh! So it doesn't even have a tiny bit of (flash) ROM space? It's all live, so to speak? Well, obviously the NES's RAM. It's just 2k, but I'm sure some people can use it for something interesting, if you can copy some code into RAM and jump to it.

Another thing ou might want to look into is allowing code download to RAM via sysex messages. For best use, it would be a good idea to let the code in RAM hook interrupts as well. (Not sure about how you best do that with 6502...)

1,739

(193 replies, posted in General Discussion)

The hammer has been swung!

1,740

(20 replies, posted in Nintendo Handhelds)

Why didn't anyone move it to the right section section yet?

Rolf speaks many words of truthinessisosity.

Saskrotch wrote:

i would make a thread about it

Wow, that's like soooo meta!

nkogliaz wrote:

nitro2k01,  could ESD be a factor in this equation?

ESD, no. Everything is hidden away, so you can hardly touch any connectors even if you wanted to. Now that you mention it though, CMOS latchup might play a role if
1) the smartboy reader is using a certain kind of cartridge connector and
2) id the cartridge was inserted/removed while the unit was powered on.
(3) the brand of SRAM might play a role too; some brands may be better protected against this)

What you need to look for is the pattern on the bottom side of the board, where there's a row of soldered connections.

This is a picture of a GBC board. The cartridge slot is removed, but that doesn't matter. Notice how pins 1-31 are in a straight zig-zag pattern whereas pin 32 is moved a bit up. Pin 32 is ground, and this makes sure ground always makes contact first and breaks last, should you insert or remove the cartridge when the GBC is powered on. If the stupidboy guys used DMG cart slots, pin 32 will also on the same zig-zag line, and it might be susceptible to CMOS latchup.

This is just a theory though, and I'm not sure if this is a real-world concern.

I looked at the savs. Seems like the power died after all. Either the battery is dying, or it came loose for a short while.