VRC5

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: VRC5

Post 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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: VRC5

Post 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)
Last edited by lidnariq on Tue Sep 10, 2019 9:44 pm, edited 1 time in total.
CaH4e3
Posts: 71
Joined: Thu Oct 13, 2005 10:39 am

Re: VRC5

Post 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 ;)
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: VRC5

Post 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.
ccovell
Posts: 1045
Joined: Sun Mar 19, 2006 9:44 pm
Location: Japan
Contact:

Re: VRC5

Post by ccovell »

A little reminder that "Q-TAI" is an incorrect transcription.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: VRC5

Post 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.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: VRC5

Post 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 10493 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 10493 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 10493 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.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: VRC5

Post 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.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: VRC5

Post 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.
User avatar
Gilbert
Posts: 564
Joined: Sun Dec 12, 2010 10:27 pm
Location: Hong Kong
Contact:

Re: VRC5

Post 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.
Pokun
Posts: 2681
Joined: Tue May 28, 2013 5:49 am
Location: Hokkaido, Japan

Re: VRC5

Post 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.
JonteP
Posts: 10
Joined: Tue Aug 14, 2018 5:32 am

Re: VRC5

Post 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?
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: VRC5

Post by NewRisingSun »

This list claims a single VRC5 game was released in 1990, followed by six more as late as 1994. How strange...
Post Reply