Page 3 of 3

Re: VRC5

Posted: Tue Sep 10, 2019 12:40 am
by NewRisingSun
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

Posted: Tue Sep 10, 2019 11:18 am
by lidnariq
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 the leastbest 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)

Re: VRC5

Posted: Tue Sep 10, 2019 2:50 pm
by CaH4e3
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 ;)

Re: VRC5

Posted: Thu Sep 12, 2019 11:26 am
by NewRisingSun
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.
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.
CaH4e3 wrote:but dumps already released as is
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).

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

Posted: Fri Sep 13, 2019 12:39 am
by ccovell
A little reminder that "Q-TAI" is an incorrect transcription.

Re: VRC5

Posted: Wed Oct 23, 2019 2:56 am
by Pokun
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.

Re: VRC5

Posted: Wed Oct 23, 2019 8:39 am
by NewRisingSun
A little reminder that technical rather than pedantic contributions are welcome as well.
Pokun wrote:the six titles on the wiki seems to be missing the 小学校の (shougakkou no - of elementary school) before 算数 (sansuu - arithmetic).
I see no "小学校の" in any of the screenshots:
NHK_Gakuen_-_Space_School_-_Sansu_5_Nen_(Jou)_(CAI_Gakusyuu_System,_QTai_Hardware)_(J)[U][!]-0.png
NHK_Gakuen_-_Space_School_-_Sansu_5_Nen_(Jou)_(CAI_Gakusyuu_System,_QTai_Hardware)_(J)[U][!]-0.png (3.71 KiB) Viewed 7585 times
NHK_Gakuen_-_Space_School_-_Sansu_6_Nen_(Ge)_(CAI_Gakusyuu_System,_QTai_Hardware)_(J)[U][!]-0.png
NHK_Gakuen_-_Space_School_-_Sansu_6_Nen_(Ge)_(CAI_Gakusyuu_System,_QTai_Hardware)_(J)[U][!]-0.png (7.29 KiB) Viewed 7585 times
NHK_Gakuen_-_Space_School_-_Sansu_6_Nen_(Jou)_(CAI_Gakusyuu_System,_QTai_Hardware)_(J)[U][!]-0.png
NHK_Gakuen_-_Space_School_-_Sansu_6_Nen_(Jou)_(CAI_Gakusyuu_System,_QTai_Hardware)_(J)[U][!]-0.png (3.86 KiB) Viewed 7585 times
Pokun wrote:Also the order is most likely wrong. 下 (ge) should be part 1 and 上 (jou) is part 2.
Maybe, maybe not. Until this is known for sure, I'd rather go with default sort order.

Re: VRC5

Posted: Wed Oct 23, 2019 3:18 pm
by Pokun
Pedantic or not, we can only contribute with what we are good at.
I see no "小学校の" in any of the screenshots:
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.
Maybe, maybe not. Until this is known for sure, I'd rather go with default sort order.
What sort order? Elementary comes before advanced, but I guess 上 can be used to mean former as well though.

Re: VRC5

Posted: Wed Oct 23, 2019 3:25 pm
by NewRisingSun
Pokun wrote:What sort order?
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.

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

Posted: Wed Oct 23, 2019 6:08 pm
by Gilbert
Pokun wrote:下 (ge) should be part 1 and 上 (jou) is part 2.
上 (jou) is part 1 and 下 (ge) is part 2. This is the most common use case.
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

Posted: Thu Oct 24, 2019 1:39 am
by Pokun
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 上級).

NewRisingSun wrote:
Pokun wrote:What sort order?
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.

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.
I see, kanji sorting is advanced stuff and probably very hard to do in a satisfactory way.


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

Posted: Thu Nov 07, 2019 8:42 am
by JonteP
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:

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];
}
Does this seem reasonable?

Re: VRC5

Posted: Wed Jan 01, 2020 6:10 pm
by NewRisingSun
This list claims a single VRC5 game was released in 1990, followed by six more as late as 1994. How strange...