VRC5
Moderator: Moderators
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: VRC5
So, should a NES 2.0 Mapper 547 file contain the 256 KiB CHR-ROM as it appears to the NES PPU, similar to Sanchez' UNIF file, or the 128 KiB content of the CHR-ROM as deduced in this thread? How confident can we be in this deduction? Ideally, somebody would desolder that CHR-ROM IC and read it with an EPROM programmer for verification. But that may not be feasible.
Re: VRC5
The easy questions: Is there really only 128 KiB of data? Definitely. Is PPU A3 ignored by the ROM? Definitely.
Meanwhile, we've encountered some number of other games with scrambled address lines, although in the past it's been for ease of routing. I don't see any particular value in de-shuffling the address lines to accurately represent the exact contents of the ROM: this isn't MAME.
Finally, the padding. I'd suggest this is something best addressed as what involves theleastbest performance and/or least maintenance load to an emulator author. (Perhaps the "right" thing for an emulator is to pre-expand the 128KiB of data to 512KiB during the loader, and just treat the 128s bit of QTRAM as another banking bit)
Meanwhile, we've encountered some number of other games with scrambled address lines, although in the past it's been for ease of routing. I don't see any particular value in de-shuffling the address lines to accurately represent the exact contents of the ROM: this isn't MAME.
Finally, the padding. I'd suggest this is something best addressed as what involves the
Last edited by lidnariq on Tue Sep 10, 2019 9:44 pm, edited 1 time in total.
Re: VRC5
definitely, the CHR rom on the QTA adaptor might be 128K and contain only a 1bpp fonts. but since I dumped them via ppu window I haven't realized it. now I have it emulated like a 256K rom with the least half isn't used at all (since the highest bits are ppu generated).
so my dumps may be threated as "overdumps" somehow now... this is easy to fix roms from 256 to 128k and adjust the emulation but dumps already released as is
so my dumps may be threated as "overdumps" somehow now... this is easy to fix roms from 256 to 128k and adjust the emulation but dumps already released as is
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: VRC5
Generally, I tend to fall down on the MAME side of the argument, namely, that the exact contents of a ROM should be accurately represented, unless there is a compelling reason not to. In the case of Konami Q-Tai, when processing a 128 KiB CHR-ROM to add the second bitplane, a few additional shift operations more or less won't hurt. I would not like defining a 128 KiB CHR-ROM representation as canonical that is 1bpp but does not have the A0/A4 reordering, since such a representation exists neither for the PPU nor in the ROM chip.lidnariq wrote:I don't see any particular value in de-shuffling the address lines to accurately represent the exact contents of the ROM: this isn't MAME.
UNIF-format dumps are released; no NES 2.0 dumps are. It would not be the first mapper where the iNES/NES 2.0 representation differs substantially from the UNIF one (Supervision 16-in-1 is another one that comes to my mind).CaH4e3 wrote:but dumps already released as is
How about this: Canonically define UNIF Mapper "KONAMI-QTAI" as using the 256 KiB CHR-ROM representation, and canonically define NES 2.0 Mapper 547 as using the 128 KiB shuffled CHR-ROM representation. Add that these canonical definitions shall not preclude emulators from accepting either representation when loading from either file format, by querying the CHR-ROM size, similar to the source code part I posted before.
Re: VRC5
Yes, and the six titles on the wiki seems to be missing the 小学校の (shougakkou no - of elementary school) before 算数 (sansuu - arithmetic).
Full title: Space School: 小学校の算数 4年 (上) - Space School: Shougakkou no Sansuu Yon-nensei (jou)
Instead of: × Space School: 算数 4年 (上) - Space School: Sansuu Yon-nensei (jou)
Also the order is most likely wrong. 下 (ge) should be part 1 and 上 (jou) is part 2.
Full title: Space School: 小学校の算数 4年 (上) - Space School: Shougakkou no Sansuu Yon-nensei (jou)
Instead of: × Space School: 算数 4年 (上) - Space School: Sansuu Yon-nensei (jou)
Also the order is most likely wrong. 下 (ge) should be part 1 and 上 (jou) is part 2.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: VRC5
A little reminder that technical rather than pedantic contributions are welcome as well.
I see no "小学校の" in any of the screenshots:Pokun wrote:the six titles on the wiki seems to be missing the 小学校の (shougakkou no - of elementary school) before 算数 (sansuu - arithmetic).
Maybe, maybe not. Until this is known for sure, I'd rather go with default sort order.Pokun wrote:Also the order is most likely wrong. 下 (ge) should be part 1 and 上 (jou) is part 2.
Re: VRC5
Pedantic or not, we can only contribute with what we are good at.
I see, it's missing on the title screen as well. It's on the cover though. In that case I guess either is fine.I see no "小学校の" in any of the screenshots:
What sort order? Elementary comes before advanced, but I guess 上 can be used to mean former as well though.Maybe, maybe not. Until this is known for sure, I'd rather go with default sort order.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: VRC5
Default sort order means what I get if I name the .NES files using the long names, then let Windows Explorer do its thing sorting by name.Pokun wrote:What sort order?
It may well be wrong --- having two files "Gradius.nes" and "Gradius 2.nes" causes Windows Explorer to sort "Gradius 2.nes" before "Gradius.nes", so meh.
Re: VRC5
上 (jou) is part 1 and 下 (ge) is part 2. This is the most common use case.Pokun wrote:下 (ge) should be part 1 and 上 (jou) is part 2.
Like say, a novel comprised of two parts would have the first part usually called '上巻' or '上篇', and the second part '下巻' or '下篇'.
A good example is the game series BURAI. Its two games were named '上巻' and '下巻' in the original PC version. When the series was ported to consoles, '上巻' was just called BURAI (PCE, SFC, MD) and '下巻' was called BURAI II (PCE only).
This is even more prevalent when school levels are involved like in these games' titles, as '上' usually means 1st semester and '下' means 2nd semester.
Re: VRC5
You are right, I was confused.
In my experience 上 and 下 are used for advanced and basic courses respectively in which of course basic would go first. But you would probably need a kanji combination for that context to make sense (like 下級 and 上級).
Cuter/kyuuta is more or less proven to be right. In the video you can see that it says キュータ on the back of the adapter.
In my experience 上 and 下 are used for advanced and basic courses respectively in which of course basic would go first. But you would probably need a kanji combination for that context to make sense (like 下級 and 上級).
I see, kanji sorting is advanced stuff and probably very hard to do in a satisfactory way.NewRisingSun wrote:Default sort order means what I get if I name the .NES files using the long names, then let Windows Explorer do its thing sorting by name.Pokun wrote:What sort order?
It may well be wrong --- having two files "Gradius.nes" and "Gradius 2.nes" causes Windows Explorer to sort "Gradius 2.nes" before "Gradius.nes", so meh.
Cuter/kyuuta is more or less proven to be right. In the video you can see that it says キュータ on the back of the adapter.
Re: VRC5
Finally got VRC5 emulation to work. Maybe this is already known, or I'm misunderstanding the issue, but from glancing at different code implementations, it seems that how the VRC5 determines whether the fetched tile is BG or Sprite is unkown.
I just assumed that it listens to PPU A12 and that games are fixed to sprites in left and bg in right pattern table, and it seems to work:
Does this seem reasonable?
I just assumed that it listens to PPU A12 and that games are fixed to sprites in left and bg in right pattern table, and it seems to work:
Code: Select all
uint8_t* vrc5_ppu_read_chr(uint16_t address) {
if(address & 0x1000) { //BG tile fetch
if(qtVal & 0x40) { //QTa Kanji CHR ROM
if(address & 0x08) {
retVal = (qtVal & 0x80) ? 0xff : 0x00;
return &retVal;
}
else
return &chrRom[((qtVal & 0x3f) << 12) | (address & 0xfff)];
}
else //BG tile from external CHR RAM
return &chrRam[((qtVal & 0x01) << 12) | (address & 0xfff)];
}
else //Sprite tile from external CHR RAM
return &chrSlot[(address >> 10)][address & 0x3ff];
}
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: VRC5
This list claims a single VRC5 game was released in 1990, followed by six more as late as 1994. How strange...