|
|
Joined: Mar 2001
Posts: 17,215 Likes: 234
Very Senior Member
|
Very Senior Member
Joined: Mar 2001
Posts: 17,215 Likes: 234 |
byuu: since you'd know, what are the easiest SA-1 games to get running in terms of not using much of the add-on hardware? I'd like to get Jikkyou Parodius going, but I don't immediately want to slam my head into a game that uses all the features either 
|
|
|
|
|
Joined: Jun 2008
Posts: 205
Senior Member
|
|
Senior Member
Joined: Jun 2008
Posts: 205 |
It's been a while, so I'll do my best. Kirby's Dreamland 3 and Dragon Ball Z: Hyper Dementia are the easiest. They don't use any features at all, IIRC. Just clone the S-CPU, add in the MMIO regs to start and stop, and you can have them running in 8 hours. Or at least, that's what it took me. For you guys probably 2 hours :P Marvelous makes use of standard SA-1 DMA for the sprites, but it'll "run" even without it. Parodius makes use of IRQs, I believe. And Super Mario RPG is very tough, using IRQs and character conversion mode 2 for level up text. The two golf games use both character conversion DMA modes. Not even ZSNES or Snes9X support those yet. SD Gundam G-NEXT uses CC1 DMA, and also has an expansion slot for BS-X cartridges. Jumpin' Derby uses the NMI override thing that nothing else does, and I think it also uses the variable bit-length feature. There's about a half-dozen features bsnes emulates that no known game even uses; such as the SA-1-side IRQ timers. And worst of all, not a damn SA-1 game, out of all ~26 of them or whatever, even uses a fraction of the true power of the SA-1. Almost all of them could easily be made without the chip at all. I strongly suspect most of the time it was simply used as an anti-piracy device. As always, take a look at my WIP forum. The SA-1 testing phase mentions many bugs I ran into and how to fix them. Not sure if this test program is meaningful... It looks fairly primitive, but may be pointing out some useful bugs. If that is a PD ROM, may I ask where you found it? If it's copyrighted, forget I said anything.
|
|
|
|
|
Joined: Oct 2006
Posts: 1,017 Likes: 21
Very Senior Member
|
|
Very Senior Member
Joined: Oct 2006
Posts: 1,017 Likes: 21 |
It looks fairly primitive, but may be pointing out some useful bugs. If that is a PD ROM, may I ask where you found it? If it's copyrighted, forget I said anything. It sounds like this: http://board.zsnes.com/phpBB2/viewtopic.php?p=121043
|
|
|
|
|
Joined: May 2009
Posts: 2,214 Likes: 382
Very Senior Member
|
|
Very Senior Member
Joined: May 2009
Posts: 2,214 Likes: 382 |
Kirby's Dreamland 3 and Dragon Ball Z: Hyper Dementia are the easiest. They don't use any features at all, IIRC. Just clone the S-CPU, add in the MMIO regs to start and stop, and you can have them running in 8 hours. Or at least, that's what it took me. For you guys probably 2 hours :P So, I take it I basically just need to hook a memory map up to the SA-1 chip that's similar to the SNES, and Kirby's Dreamland 3 will fire up? For the life of me I can't figure out what the heck this "cc1bwram" and "sa1bwram" and "sa1iram" stuff is, will KDL3 work without it?
|
|
|
|
|
Joined: Mar 2001
Posts: 17,215 Likes: 234
Very Senior Member
|
|
Very Senior Member
Joined: Mar 2001
Posts: 17,215 Likes: 234 |
Not that simple. Needs a separate CPU core and probably some extreme cart remapping in MESS, I'll handle it.
|
|
|
|
|
Joined: Jun 2008
Posts: 205
Senior Member
|
|
Senior Member
Joined: Jun 2008
Posts: 205 |
The I-RAM and BW-RAM are visible to both chips. To aid in letting bsnes run out-of-order, and because only the SA-1 can make use of the bitmap-RAM projection mode, I have access interfaces for both chips. There's also some special stuff to handle character-conversion DMAs.
cc1 refers to character-conversion mode 1, while sa1 is usually referring to bog-standard SA-1 opcode memory accesses. I'll have to look at the code sometime to explain it better why I have both.
And not only the CPU, you need to support part of the SA-1 MMIO interface to let the main CPU start the SA-1 at a specified point.
|
|
|
|
|
Joined: May 2009
Posts: 2,214 Likes: 382
Very Senior Member
|
|
Very Senior Member
Joined: May 2009
Posts: 2,214 Likes: 382 |
Not that simple. Needs a separate CPU core and probably some extreme cart remapping in MESS, I'll handle it. Bah, fine. I already duplicated the G65816 core into an SA1 core and was in the process of hooking up the MMIO writes to cpu_set_info. I figured I could have it going by the time you wake up tomorrow, seeing as you're probably going to bed soon. If you're meaning my SGB WIP code, I'll have to ask forum goers. It seems I don't have it on my system anymore  That's exactly what I meant.
|
|
|
|
|
Joined: Jan 2006
Posts: 3,691
Very Senior Member
|
|
Very Senior Member
Joined: Jan 2006
Posts: 3,691 |
...and probably some extreme cart remapping in MESS... FWIW, the following code should cover the cart ROM remapping part. while (read_blocks < 64 && read_blocks < total_blocks)
{
/* Loading and mirroring data */
memcpy(&snes_ram[0x008000 + read_blocks * 0x10000], &ROM[0x000000 + read_blocks * 0x8000], 0x8000);
memcpy(&snes_ram[0x808000 + read_blocks * 0x10000], &ROM[0x000000 + read_blocks * 0x8000], 0x8000);
memcpy(&snes_ram[0xc00000 + read_blocks * 0x10000], &ROM[0x000000 + read_blocks * 0x10000], 0x10000);
read_blocks++;
}
Not sure about the changes needed for the SRAM.
|
|
|
|
|
Joined: May 2009
Posts: 2,214 Likes: 382
Very Senior Member
|
|
Very Senior Member
Joined: May 2009
Posts: 2,214 Likes: 382 |
My research notes are here: http://byuu.org/files/supergameboy.txtThe problem I'm having is explained under the $7800 register section, and I'm also quite stumped on the purpose of $6001. I've gotten far enough to have the entire SGB BIOS running, all Gameboy non-SGB games running perfectly with full video, audio and input; and I've gotten a few SGB-specific commands to execute, but again, that $7800 problem makes almost everything unplayable. The six packets generated are in this format:
Packet #1: $f1, $??, <14 bytes of GB ROM data, starting from $0104>
Packet #2: $??, $??, <14 bytes of GB ROM data, starting from $0112>
Packet #3: $??, $??, <14 bytes of GB ROM data, starting from $0120>
Packet #4: $??, $??, <14 bytes of GB ROM data, starting from $012e>
Packet #5: $??, $??, <14 bytes of GB ROM data, starting from $013c>
Packet #6: $??, $??, <14 bytes of GB ROM data, starting from $014a>
$?? values are not looked at by the SGB BIOS at all. They can be anything, but
are most likely $f1,$00 for each packet.
$f1 corresponds to command $1e with a length of 1, eg ($1e << 3) + 1 I'm not entirely sure that that is accurate, either that the first byte corresponds to a command or that it corresponds to a length. The first byte itself seems to be arbitrary, and does not correspond to any kind of length - this is based off of the behavior I've observed in the real Super Game Boy boot ROM that has recently been dumped by Costis. Here's a C version of almost everything the boot ROM does:
int main(int argc, char* argv[])
{
int index = 0, index2 = 0;
int byte = 0, bit = 0;
int sum = 0;
int length = 6;
UINT16 romAddr = 0, ramAddr = 0;
UINT8 byte0 = 0;
SP = 0xfffe;
SetJOYP(0x30);
for(index = 0x1fff; index >= 0; index--)
{
SetVRAM(index, 0);
}
SetNR52(NR52_ALL_ON);
SetNR11(NR11_DUTY_12_5 | NR11_LENGTH_1);
SetNR13(0xf3);
SetNR51(NR51_SO2_4 | NR51_SO2_3 | NR51_SO2_2 | NR51_SO2_1 | NR51_SO1_2 | NR51_SO1_1);
SetNR50(NR50_SO2VOL_7 | NR50_SO1VOL_7);
SetBGP(0xfc); // 3:11 2:11 1:11 0:00 (monochrome)
for(index = 0; index < 8; index++)
{
SetWRAM(0x58 + index, 0);
}
romAddr = 0x014f;
ramAddr = 0x57;
byte0 = 0xfb;
do
{
for(index2 = 0; index2 < length; index++)
{
sum += GetROM(romAddr);
SetWRAM(ramAddr--, GetROM(romAddr));
romAddr--;
}
SetWRAM(ramAddr--, sum);
SetWRAM(ramAddr--, count);
count -= 2;
length = 14;
} while(count != 0xef);
// Some audio? juju goes on in between the above and 0x0087, but it's unimportant
// 0x0087:
SetJOYP(0x00);
SetJOYP(0x30);
ramAddr = 0x00;
while(ramAddr != 0x60)
{
for(byte = 0; byte < 16; byte++)
{
for(bit = 0; bit < 8; bit++)
{
if(GetWRAM(ramAddr++) & (1 << bit))
{
SetJOYP(0x10);
}
else
{
SetJOYP(0x20);
}
SetJOYP(0x30);
}
}
SetJOYP(0x20);
SetJOYP(0x30);
Delay4Frames();
}
LockoutAndBoot();
}
// 0x00c2
void Delay4Frames(void)
{
int index = 0, index2 = 0;
D = 4;
for(index = 0; index < 4; idex++)
{
while(GetLY() != 0x90);
for(index2 = 0; index2 < 256; index2++);
}
}
// 0x00fc
void LockoutAndBoot(void)
{
SetLockout(1);
CartBoot();
}
// 0x0150
void CartBoot(void)
{
...
}
I can't say for certain exactly what the first byte really is, but it appears that the second byte is a summation of the 14 subsequent bytes in that particular row. For example, the buffer built up by the SGB BIOS for Wario Land II looks like:
F1 70 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F3 60 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F5 59 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F7 7A xx xx xx xx xx xx xx xx xx xx xx xx xx xx
F9 F5 xx xx xx xx xx xx xx xx xx xx xx xx xx xx
FB AC xx xx xx xx xx xx xx xx xx xx xx xx xx xx
Your thoughts?
|
|
|
|
|
Joined: Jun 2008
Posts: 205
Senior Member
|
|
Senior Member
Joined: Jun 2008
Posts: 205 |
Well, I only looked at the SNES-side Super Game Boy BIOS code. It looked for the #$f1, and then it looked at bytes 2-16 of each packet and compared it against a copy it stored inside the BIOS itself. The other values can be anything and it still works.
That you've figured out the exact details from RE'ing the 256-byte GB-side BIOS is quite amazing, thank you. I had to fake the packets being sent on reset to start the SGB program, but it would probably be better to emulate the boot ROM and have it do that for us.
|
|
|
|
Forums9
Topics9,320
Posts121,930
Members5,074
| |
Most Online1,283
Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|
