This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

VRC5

VRC5
by on (#242120)
Neat. The missing VRC (5) chip has been found.

https://www.youtube.com/watch?v=1rnf13b3dG4

(English subtitles are there)
Re: VRC5
by on (#242123)
Screengrab from the linked video:
Attachment:
File comment: https://youtu.be/1rnf13b3dG4?t=1202
KONAMI 052955 VRCV. 8904 Z01.jpg
KONAMI 052955 VRCV. 8904 Z01.jpg [ 65.07 KiB | Viewed 3545 times ]


CaH4e3's writeup: http://cah4e3.shedevr.org.ru/dumping_2019.php#190827
Re: VRC5
by on (#242161)
Since some people don't want to watch YouTube videos, or perhaps it will be missing some day... this is what I gathered from the video.

The VRC5 chip is on the Q Ta adapter for the Space School (it says Space College on the box) series of educational games made by Konami. It is especially rare since they were never sold to the general public.

At the end, it says that VRC5 emulation has been added to FCEUX.

(edit. as of this post, there is no wiki entry for VRC5 nor VRCV)
Re: VRC5
by on (#242163)
It will be interesting to see what it does since it felt odd that there was no VRC5 with the VCRC6 used in Madara/Castleviana but it will be mostly for educational purpose since it's so rare that it cannot be used anyway ^-^;;; But maybe infiniteneslive could make a compatible one if the mapper is that good :lol:
Re: VRC5
by on (#242164)
Cool!
Re: VRC5
by on (#242175)
This is great! :D

From what I gathered from the the video it's an adapter called the Q太 (the core meaning of 太 is something like "greatest", "grand", "very", "thick" or "fat") where 太 is read as "ta" ("tai" is also possible, but it looks like there are furigana above it which explains the reading).

Initially only the six Space School titles was known: 小学校の算数4年生 下 (Shougakkou no Sansuu yo-nensei ge, "Elementary School Arithmetic grade 4 - lower"), 小学校の算数4年生 上 (Elementary School Arithmetic grade 4 - upper), 小学校の算数5年生 下 (Elementary School Arithmetic grade 5 - lower), 小学校の算数5年生 上 (Elementary School Arithmetic grade 5 - upper), 小学校の算数6年生 下 (Elementary School Arithmetic grade 6 - lower), 小学校の算数6年生 上 (Elementary School Arithmetic grade 6 - upper). They where sold to schools and not in retail stores which is why they are so rare. In the video they seem to mix up "part 1" with "part 2", at least in the subtitles (下 "lower" should be basic and 上 "upper" should be advanced).

A seventh game was later discovered known as 危険物のやさしい物理と科学 (Kikenbutsu no Yasashii Butsuri to Kagaku, translated by Kotaku as: "The Gentle Physics and Science of Hazardous Materials"). It's also not a retail game but was made for the oil company Idemitsu Kosan, which used it to teach their employees. It's seems to be the only known game in the Space College series and possibly only a very few copies (or possibly only one) exists.

CaH4e3 managed to reverse engineer the Q太 adapter and dumped the ROMs. The VRC5 chip was discovered to be in the adapter, but not much technical info was mentioned in the video. I guess he added support for it in his own version of FCE Ultra? So far, dumped games seems to include the lower and upper version of Space School games for grade 6 previously dumped, upper version of grade 5 that the guy in the video got and the ultra rare Space College game which was also previously dumped.

It seems you need to enter your student number to be able to start the game for the first time. For upper grade 5 that they showed in the video, they got it to work with "012000000".
Re: VRC5
by on (#242179)
rainwarrior wrote:
Cool!

can I have a full version of nes lizard as reward, please? ;)
Re: VRC5
by on (#242182)
CaH4e3 wrote:
can I have a full version of nes lizard as reward, please? ;)


Only when you update this wiki page http://wiki.nesdev.com/w/index.php/VRC5 :) (joking)
Re: VRC5
by on (#242184)
I have started a wiki page based on my working emulation derived from how I understand the relevant FCEUX source code parts.

I have spent some time trying to understand the idea behind the character code to CHR-ROM offset translation. Doing so is not necessary for emulation, of course.
Re: VRC5
by on (#242187)
That is pretty neat. It was cool that CaH4e3 appears in the video, demonstrating his method for RE'ing the mapper. It reminded me a little bit of hanging out with kevtris and watching him RE mappers, in the early days of CopyNES (all that was missing was some QBASIC action). It's a rare day when get to see a new mapper. And from Konami, at that!
Re: VRC5
by on (#242214)
Pokun wrote:
(the core meaning of 太 is something like "greatest", "grand", "very", "thick" or "fat") where 太 is read as "ta" ("tai" is also possible, but it looks like there are furigana above it which explains the reading).

No, it's more like sound association with the words "compuTER" and "kid" or "boy". Think of the name "Taro" 太郎 which is the genericized boy's name in Japanese, like John or Dick (of "Dick and Jane") are in English.

There's also the Tomy computer ぴゅう太 "pyuu-ta" which came out several years earlier. It was released in the West, not coincidentally, as the "Tutor".

So I think barring any actual instruction manuals from the Q-Ta, "Kids' Tutoring Computer" is the feeling the name is going for.
Re: VRC5
by on (#242216)
ccovell wrote:
Pokun wrote:
(the core meaning of 太 is something like "greatest", "grand", "very", "thick" or "fat") where 太 is read as "ta" ("tai" is also possible, but it looks like there are furigana above it which explains the reading).

No, it's more like sound association with the words "compuTER" and "kid" or "boy". Think of the name "Taro" 太郎 which is the genericized boy's name in Japanese, like John or Dick (of "Dick and Jane") are in English.

There's also the Tomy computer ぴゅう太 "pyuu-ta" which came out several years earlier. It was released in the West, not coincidentally, as the "Tutor".

So I think barring any actual instruction manuals from the Q-Ta, "Kids' Tutoring Computer" is the feeling the name is going for.


I discern from this that we should be pronouncing this as the "Konami 'kew-ta"
Re: VRC5
by on (#242224)
It always bugged my OCD tendencies to have VRC1-4 + VRC6-7 support, so of course I had to add this for the heck of it.

Thanks for the Wiki article, NewRisingSun! I'll try to help out a bit in return: here's an implementation of the VRC5 in C++ code:

https://github.com/byuu/higan/blob/mast ... i-vrc5.cpp

It should be nicer than the FCEUX version to read, as FCEU hides a *ton* of details about how the mappers actually work behind FCEU-only abstractions. But maybe my .bit() stuff will confuse people, so YMMV.

Things from the Wiki:

1. "Character Translation Output ($DC00/$DD00, read). Mask: probably $FF00 (ROM data filled with $FF from $D400-DFFF)"

Bank $c000-dfff can be remapped, so it *can* be something other than $FF. I didn't bother to check if the games ever set it to something where $d400-dfff aren't $FF. But, whatever.

It'd probably be nice if we can ask CaH4e3 to please verify the address masks for this mapper.

2. "Character Translation Operation"

I may well have made a mistake, but try as I might, I couldn't get your formula to work and had to use the FCEUX version.

Code:
tile =glyph *4;
ciramByte =(tile &0xFF) | (reg[0xDB00] &3);
qtramByte =(tile >>8) |

// Indicate CHR-ROM
qtramByte |=0x40;

// Indicate alternate attribute
if (reg[0xDB00] &0x04) qtramByte |=0x80;


The third line is cut off. Presuming you want to turn the | into a ; here, which is what I tried. Didn't work.

3. "CHR Banking Operation" -- "The Konami VRC5 ASIC intercepts this process: Whenever the NES PPU fetches a background nametable byte from CIRAM, the VRC5 fetches an additional byte from QTRAM that indicates whether the next CHR pattern data that will be fetched should come from CHR-ROM or CHR-RAM and from which 4 KiB bank."

I always wonder *how* these ASICs do this. I'm aware there's a clear pattern to fetches for each scanline: $2xxx, $23xx, $(0000-1fff), $(0000-1fff) -- repeat 32 times; sprite stuff for a bit; two more tile fetches; some end-of-line stuff.

But let's say a game enables force blanking for a time, how would these ASICs react?

I wasn't in the mood for trying to guess how the VRC5 did this (it was quite a lot of pain with my MMC5 emulation, and is likely wrong there too), so I just made it steal the PPU cycle position to intercept these fetches for now.

Still, it'd be lovely to know for sure, if it could be determined without decapping and destroying priceless carts.

4. "1: Force CHR pattern data to $FF if CHR A3=1, only if CHR-ROM is used (C=1)"

The reason for this is to control the background color behind kanji. On the title and space screens, this isn't done so you get black backgrounds. In the game menus it does this so you get the blue background behind the kanji. Such a weird way of doing things, but ... yeah that's what it's for.
Re: VRC5
by on (#242225)
Thank-you for your comment.
byuu wrote:
Bank $c000-dfff can be remapped, so it *can* be something other than $FF.
Correct. I tried to express that the game is careful in its ROM layout and bankswitch register content choice not to put anything important there, which suggests that programmers were aware that the register does not respond only at the $DC00/$DD00 address, but likely across the entire 256-byte range.
byuu wrote:
The third line is cut off. Presuming you want to turn the | into a ; here, which is what I tried. Didn't work.
I have attached my NintendulatorNRS source code snippet, based on which I wrote the wiki page. Since it works nicely here, either I have made a mistake in transcribing it to the wiki, our you have made some mistake applying the wiki description. I replaced the stray pipe character with a semicolon on the wiki.

I have not considered what happens when the PPU goes blank for an extended period of time, but I did add a heuristic to differentiate BG versus OBJ fetches based on the last nametable address (lastNTAddr).

When deciding on the NES 2.0 ROM layout, I chose to follow the precedent set by Bandai Karaoke Studio, Nantettatte Baseball and Family Noraebang. That does not constitute a substantive defense, of course. It is more an appeal to consistency with precedent. Admittedly, the precedents are different in those unexpanded cartridges being usable alone, while the Q-Tai adapter cannot be used alone.
Re: VRC5
by on (#242230)
Great Hierophant wrote:
ccovell wrote:
Pokun wrote:
(the core meaning of 太 is something like "greatest", "grand", "very", "thick" or "fat") where 太 is read as "ta" ("tai" is also possible, but it looks like there are furigana above it which explains the reading).

No, it's more like sound association with the words "compuTER" and "kid" or "boy". Think of the name "Taro" 太郎 which is the genericized boy's name in Japanese, like John or Dick (of "Dick and Jane") are in English.

There's also the Tomy computer ぴゅう太 "pyuu-ta" which came out several years earlier. It was released in the West, not coincidentally, as the "Tutor".

So I think barring any actual instruction manuals from the Q-Ta, "Kids' Tutoring Computer" is the feeling the name is going for.


I discern from this that we should be pronouncing this as the "Konami 'kew-ta"
Yeah or even "cuter" if you will. Possibly related to both "cute" and "computer" as suggested by Covell.
I don't think it contradicts anything I said, but I've also seen 太 often used as ateji (using kanji for its sound and disregarding its meaning) for a [ta] sound. I bet the furigana on the package (which I can't read due to all photos having too little detail) says "kyuuta".

The documentation seems to have stuck with "Q-TAI" for now though.
Re: VRC5
by on (#242233)
I second the "cuter" theory. Maybe even "cute". The cartridges that go in the adapter are smaller than normal, hence "cute" sized.

At the time, computer geeks were sending messages in leetspeak, and QT is an abbreviation for cute.

Although, on second thought, if it was "cute" then why not just use English (Roman) letters for both.

"cuter" cute computer sounds more likely.
Re: VRC5
by on (#242234)
And nearly two decades ago, I released a tech demo titled "Who's Cuter". Uh-oh...
Re: VRC5
by on (#242241)
Can the owner provide photos of both sides of the adapter? I'm curious to know what exactly VRC5 could do, not what is used by this particular game(s).
Re: VRC5
by on (#242245)
dougeff wrote:
Although, on second thought, if it was "cute" then why not just use English (Roman) letters for both.

"cuter" cute computer sounds more likely.
Yes, "cute" becomes "kyuuto" in Japanese and would require another kanji that can be read as "to" (太 can only be read as "ta" or "tai"). Kyuuta/cuter it is.
Re: VRC5
by on (#242257)
I'm very curious what exactle the
Quote:
advanced features similar to MMC5 hardware for displaying an extended graphics

are and how they function.

Quote:
And nearly two decades ago, I released a tech demo titled "Who's Cuter". Uh-oh...

My God, we're really getting old...
Re: VRC5
by on (#242269)
The advanced MMC5-like feature is the VRC5's ability to automatically switch the 4 KiB CHR bank for each tile separately, by having additional "shadow" nametable RAM for that purpose. In a way, the VRC5 is more advanced than the MMC5, because that additional shadow nametable RAM is, at 2 KiB, large enough to contain bank bytes for two nametables, while the MMC5's 1 KiB EXRAM limits you to a single nametable when using that particular feature.
Re: VRC5
by on (#242283)
What does that mean in practice? It sounds like it would give you a bigger virtual pattern table (which is great for kanji) but I'm confused why it would need shadow nametables for that.
Anyway great job documenting this on the wiki! :)


krzysiobal wrote:
Can the owner provide photos of both sides of the adapter? I'm curious to know what exactly VRC5 could do, not what is used by this particular game(s).
Yeah I'd also like to see more detailed photos of both sides. It would be great if the adapter and all the held carts could be documented on bootgod's.
From the looks of screenshots, it almost looks like pin 45 and 46 are connecting to something, hinting of an unused expansion audio feature, but I can't really tell very well from those screenshots.

Could there be more features of the VRC5 not used by any game and what is documented on the wiki? The video showed some of the reverse engineering, but it wasn't really clear if they were confident that everything in the black box is found out.


BTW, I guess the kanji ROM is a good reason why Konami had to make an adapter. Konami was to make a bunch of edutainment games for schools, and for that kanji may be preferable. Since they were to make several games for the project, it makes sense to put some load off in an adapter to make the cartridges cheaper. That way the school only need to buy one adapter per Famicom they use at the same time, while having many more cartridges assigned for each student and with their individual progression data recorded. I just wonder how the student number works. Is it hardcoded for each individual cartridge or is there a way to set the number somehow? From the looks of it when they played it in an emulator with a clear save file, there was a hardcoded student number for the ROM.
Re: VRC5
by on (#242284)
NewRisingSun wrote:
The advanced MMC5-like feature is the VRC5's ability to automatically switch the 4 KiB CHR bank for each tile separately, by having additional "shadow" nametable RAM for that purpose. In a way, the VRC5 is more advanced than the MMC5, because that additional shadow nametable RAM is, at 2 KiB, large enough to contain bank bytes for two nametables, while the MMC5's 1 KiB EXRAM limits you to a single nametable when using that particular feature.

Wow, so the mapper has been entierely documented on the wiki already ? Neat !

So basically this feature is full 16-bit nametables (instead of the usual 8-bit), but without the single-tile colour of MMC5, and limitations of RAM where only 1k of aditional RAM is available. Sounds like a good idea, extendable graphics but without being so complex to use.
Re: VRC5
by on (#242297)
Sanchez sent me photos of both sides of the cartridge and adapter, so I was able to do my best and try to find-out the pinouts. I can't guarantee in 100% that all hidden connections were revealed correctly, but the VRC5 pin order seems to be quite logical (pins are in functional groups and in order)

Adapter:
Image Image Image Image Image

Cartridge:
Image Image Image Image Image

Code:
My notes/doubts:
* Both cartride and adapter contains a lot of jumpers, whose role is to
  switch between DIL32 / DIL28 ROMs
   Cartridge PCB (351384)
   --------------------------------------------------------------------
    IC2    JPC JPF JPB JPE JPD JPA
    DIL32  OPN CLS OPN CLS OPN CLS <- default (EF009-5A installed)
    DIL28  CLS OPN CLS OPN CLS OPN
    --------------------------------------------------------------------
    IC1                            <- always DIL32 (EF009-5B installed)
    --------------------------------------------------------------------
    IC3    JPJ JPM JPI JPL JPK JPH
    DIL32  OPN CLS OPN CLS OPN CLS <- default (non populated)
    DIL28  CLS OPN CLS OPN CLS OPN
   --------------------------------------------------------------------
   
   Adapter PCB (351383A)
   --------------------------------------------------------------------
   IC2    JPF JPG JPA JPC JPD JPE JPB JPH
   DIL28  OPN OPN OPN CLS CLS OPN CLS OPN <- default (EF901 installed)
   DIL32  CLS OPN CLS OPN CLS OPN OPN CLS
   --------------------------------------------------------------------
   IC3    JPN JPM JPL JPK
   DIL28  OPN CLS OPN CLS                 <- default (EF901-KN installed)
   DIL32  OPN CLS CLS OPN

* INT PRG ROM / INT PRG RAM refers to the internal chips
  (those inside adapter)

* EXT PRG ROM / EXT PRG RAM refers to the external chips
  (those inside cartridge that is plugged into adapter)

* Theoretically the maximum supported ROM sizes are:
   INT PRG ROM: 1 * 256 kiB
   EXT PRG ROM: 3 * 256 kiB
   INT CHR ROM: 128 kiB
   INT PRG RAM: 8 kiB
   EXT PRG RAM: 32 kiB ???
   
* Unknown pins:
    VRC5.68 = QTA.18 (might be PRG RAM A13)
   VRC5.80 = QTA.39 (might be PRG RAM A14)

* CHR-ROM chip (EF901-KN) has shuffled address lines and PPU A3 is not
  connected dirrectly but through VRC5 (is that something used to automatic
  japanese character switching?)

* What is Konami 052701 - regular 8k SRAM? Why they didnt use the same chip
  as for CHR-RAM or PRG-RAM? I analyzed other Konami Famicom PCBS and they
  never used RAM with Konami markings.
   
* There is one track on the adapter PCB that I don't have idea where goes to
 (and it seems to be surplus)

Image

Code:
                   Konami-QTA
                 Left=Label side
                    +-----+
             GND -- |01 21| -- VCC
          CPU A6 -> |02 22| <- CPU A8
         CPU A11 -> |03 23| <- CPU A9
          CPU A4 -> |04 24| <- CPU A5
          CPU A3 -> |05 25| <- CPU A10
          CPU A2 -> |06 26| <> CPU D7
         CPU A12 -> |07 27| <- CPU A7
          CPU D6 <> |08 28| <- CPU R/W
          CPU D5 <> |09 29| <- CPU A1
          CPU D4 <> |10 30| <- CPU A0
             GND -- |11 31| -- GND
          CPU D3 <> |12 32| <> CPU D0
          CPU D2 <> |13 33| <> CPU D1
         PRG A13 -> |14 34| <- PRG A14
         PRG A15 -> |15 35| <- PRG A16
EXT PRG ROM0 /CE -> |16 36| <- PRG A17
EXT PRG ROM1 /CE -> |17 37| <- EXT PRG ROM2 /CE
                  ? |18 38| <- PRG RAM A12
EXT PRG RAM /CE  -- |19 39| ?   
             VCC -- |20 40| -- VCC
                    +-----+

                                  _____
                       CPU A8 -> /01 80\ ? (goes to QTA 39, maybe PRG RAM A14?)
                         VCC -- /02   79\ <> CPU D0
                     CPU A9 -> /03 (o) 78\ <> CPU D1
                   CPU A10 -> /04       77\ <> CPU D2
                  CPU A11 -> /05         76\ <> CPU D3
                 CPU A12 -> /06           75\ <> CPU D4
                CPU A13 -> /07             74\ <> CPU D5
               CPU A14 -> /08               73\ -- VCC
              CPU R/W -> /09                 72\ <> CPU D6
           CPU /RMSL -> /10                   71\ <> CPU D7
                 M2 -> /11                     70\ <- PPU /WE
               GND -- /12                       69\ <- PPU /RD
             /IRQ <- /13                         68\ ? (goes to QTA 18, maybe PRG RAM A13?)
         CIR A10 <- /14                           67\ -> PRG RAM A12
    CHR RAM A12 <- /15                             66\ -> EXT PRG ROM0 /CE
        PPU A3 -> /16                               65\ -> EXT PRG ROM1 /CE
       PPU D0 <> /17                                64/ -> EXT PRG ROM2 /CE
      PPU D1 <> /18                                63/ -- GND
     PPU D2 <> /19         VRC 5                  62/ -> INT PRG ROM /CE
    PPU D3 <> /20                                61/ -> PRG A17
   PPU D4 <> /21                                60/ -> PRG A16
  PPU D5 <> /22                                59/ -> PRG A15
    GND -- /23                                58/ -> PRG A14
PPU D6 <> /24                                57/ -> PRG A13
PPU D7 <> \25                               56/ -> QTRAM /WE
 PPU A7 -> \26                             55/ -> INT PRG RAM /CE
  PPU A8 -> \27                           54/ -> EXT PRG RAM /CE
   PPU A9 -> \28                         53/ -> CHR ROM A16
   PPU A10 -> \29                       52/ -- GND
    PPU A11 -> \30                     51/ -> CHR ROM A15
     PPU A12 -> \31                   50/ -> CHR ROM A14
      PPU A13 -> \32                 49/ -> CHR ROM A13
           VCC -- \33               48/ -> CHR ROM A12
      CIRAM /CE <- \34             47/ -> CHR ROM A3
       QTRAM +CE <- \35           46/ <> QTRAM D7
      CHR ROM /CS <- \36         45/ <> QTRAM D6
       CHR RAM /CS <- \37       44/ <> QTRAM D5
           QTRAM D0 <> \38     43/ <> QTRAM D4
            QTRAM D1 <> \39   42/ -- GND
             QTRAM D2 <> \40 41/ <> QTRAM D3
                          \   /
                           \ /
Re: VRC5
by on (#242301)
krzysiobal wrote:
* CHR-ROM chip (EF901-KN) has shuffled address lines and PPU A3 is not connected dirrectly but through VRC5 (is that something used to automatic japanese character switching?)
The encoding in the UNIF files from Санчез has the four tiles of each code point as
TL TR LL LR
in order, repeated. By rewiring them such that A4 is the ROM's physical lsbit, and omitting the connection to PPU A3, that means the encoding in the physical ROM is instead [row 0 left, row 0 right, row 1 left, row 1 right [...] row 14 right, row 15 left, row 15 right]

(edit: I suppose the obvious failure mode to this re-interpretation is the presence of half-width characters in the ROM)

Additionally, if you look at the UNIF file, the CHR data entirely fits in one plane. So maybe the function of the bit in QTRAM is not "0: CHR pattern data unmodified / 1: Force CHR pattern data to $FF if CHR A3=1, only if CHR-ROM is used (C=1)" but instead is actually "Value of data bus when CHR A3=1 if read from CHR ROM, i.e. 0: code point is colors 1 and 0; 1: code point is colors 2 and 3"

Out of curiosity, why did you decide that the connection from VRC5 pin 47 / to IC3A pin 25 was "CHR-ROM-A3" ?
Re: VRC5
by on (#242308)
There have not been publicly posted any NES-2.0-format versions of the Q-Tai ROMs, and I am considering a change to the NES 2.0 Mapper 547 definition to reflect the actual CHR-ROM content and connection. So the CHR-ROM is only 128 KiB and not 256 KiB.
Re: VRC5
by on (#242312)
If sanchez used his copy device to read-back those cartridge, instead of desoldering those mask ROMs and dumping using external programmer then the physical order of bits in ROM cannot be revealed I think.

Quote:
Out of curiosity, why did you decide that the connection from VRC5 pin 47 / to IC3A pin 25 was "CHR-ROM-A3" ?

PPU A0..A2, A4..A11 goes directly to the ROM chip, but PPU A3 definitely does not go to the ROM:
Image

There is also for sure connection between: IC3.25 and VRC5.47 and this is the only missing address line in ROM so I called this CHR A3.
Image

Image

--

I have one suspiction that the surplus trace which I thought of before might go to the CHR-RAM A12 (efectively sharing it with either CHR-ROM-A13 or CHR-ROM-A13) and VRC.12 might be additional PRG-RAM/WE line used for additional write protection (ROM need to be analyzed if there is any additional bit set only during writes to PRG-RAM)

--

And VRC.9 and VRC.10 might be swapped.
Re: VRC5
by on (#242319)
I would say that PPU A3 should be missing from the CHR-ROM connection and should not even be considered connected indirectly through the VRC5.

Sanchez' copy-device-originated CHR-ROM has 256K, compared to your 128K, and has bytes 8-15 of every tile always at 0; the hardware was found to be able to turn them into FF. Any deduced connection must account for this size difference and where such a "blow-up" occurs.

If PPU A3=0 (and the QTRAM byte selects CHR-ROM), then the CHR-ROM data specified by the 14-bit tile index (8-bit CIRAM tile number plus 6-bit bank number) is used; if PPU A3=1 (and the QTRAM byte selects CHR-ROM), then CHR-ROM is disabled, and VRC5 returns all 0s (QTRAM D7=0) or all 1s (QTRAM D7=1), thus translating 1bpp to 2bpp, with QTRAM D7 deciding whether colors 0,1 or colors 2,3 are used, as has been pointed out previously.

So if 1bpp is blown up to 2bpp by the VRC5, then at least one PPU address line must be completely left out, and PPU A3 is the best candidate. What you call VRC5 CHR-ROM A3 and then A12-A16 is just VRC5 CHR-ROM A11-A16, which will be connected to the CHR-ROMˋs A11-A16 inputs, addressing 128K of CHR-ROM:
Code:
PPU A0 (Tile row D0) -> CHR-ROM A1
PPU A1 (Tile row D1) -> CHR-ROM A2
PPU A2 (Tile row D2) -> CHR-ROM A3
PPU A3 (bit plane) -> CHR-ROM /CE (if PPU A3=1, output all 0s or 1s instead of CHR-ROM data)
PPU A4 (Tile number D0) -> CHR-ROM A0
PPU A5 (Tile number D1) -> CHR-ROM A4
PPU A6 (Tile number D2) -> CHR-ROM A5
PPU A7 (Tile number D3) -> CHR-ROM A6
PPU A8 (Tile number D4) -> CHR-ROM A7
PPU A9 (Tile number D5) -> CHR-ROM A8
PPU A10 (Tile number D6) -> CHR-ROM A9
PPU A11 (Tile number D7) -> CHR-ROM A10
VRC5 CHR-ROM A11, pin 47 (bank number D0) -> CHR-ROM A11
VRC5 CHR-ROM A12, pin 48 (bank number D1) -> CHR-ROM A12
VRC5 CHR-ROM A13, pin 49 (bank number D2) -> CHR-ROM A13
VRC5 CHR-ROM A14, pin 50 (bank number D3) -> CHR-ROM A14
VRC5 CHR-ROM A15, pin 51 (bank number D4) -> CHR-ROM A15
VRC5 CHR-ROM A16, pin 53 (bank number D5) -> CHR-ROM A16
The CHR-ROM A0/A4 reordering, together with the 1bpp->2bpp blow-up, is basically a means of using a standard 16 bits per row 1bpp Kanji ROM to appear as a 2bpp 8-bits per row with left and right halves as sequential tiles. I have to check again, but I do not remember from the last time I loaded up the ROM in a tile editor that there were any half-width glyphs in there.

Edit: I can see 8x8 hiragana and katakana sets in there, though no 8x16 glyphs.
Re: VRC5
by on (#242326)
Half-width (8x16) alphanumerics and some punctuation are present starting at CHR0 offset 49152 bytes. Quarter-size (8x8) kana and alphanumerics are present starting at CHR0 offset 61440.

The first time I'd looked through I thought I saw half-width kana, but on closer inspection I don't see any now.
Re: VRC5
by on (#242329)
For what it's worth, here is first a C program to reconstruct the 128 KiB CHR-ROM data, as I understand it, from the 256 KiB CHR-ROM data found in the UNIF files:
Code:
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>

uint8_t dataIn [256*1024];
uint8_t dataOut[128*1024];
int main (int argc, char **argv) {
   FILE *handleInput =fopen("QTAI1.CHR", "rb");
   fread(dataIn, 1, 256*1024, handleInput);
   fclose(handleInput);

   for (uint32_t i =0; i <256*1024; i++) {
      if (i &0x08) continue;
      uint32_t outAddr =((i &0x00007) <<1) |
                        ((i &0x00010) >>4) |
                        ((i &0x3FFE0) >>1);
      dataOut[outAddr] =dataIn[i];
   }
   
   FILE *handleOutput =fopen("QTAI2.CHR", "wb");
   fwrite(dataOut, 1, 128*1024, handleOutput);
   fclose(handleOutput);
}
And attached an updated version of my mapper 547 emulation that can take both CHR-ROM images, which are distinguished by the CHR-ROM size.
Re: VRC5
by on (#242376)
Since bitmap fonts are not copyrightable under US law, I figured I'd convert the entire CHR ROM to an image for casual inspection:
Re: VRC5
by on (#242391)
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
by on (#242401)
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
by on (#242408)
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
by on (#242449)
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
by on (#242461)
A little reminder that "Q-TAI" is an incorrect transcription.