It is currently Mon Sep 16, 2019 1:06 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: VRC5
PostPosted: Sun Sep 01, 2019 10:49 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2559
Location: DIGDUG
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.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Sun Sep 01, 2019 11:59 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21591
Location: NE Indiana, USA (NTSC)
And nearly two decades ago, I released a tech demo titled "Who's Cuter". Uh-oh...

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Mon Sep 02, 2019 4:53 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 540
Location: Poland
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).


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Mon Sep 02, 2019 2:14 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Mon Sep 02, 2019 11:14 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7741
Location: Chexbres, VD, Switzerland
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...


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Tue Sep 03, 2019 10:54 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Wed Sep 04, 2019 2:59 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Wed Sep 04, 2019 3:18 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7741
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Thu Sep 05, 2019 12:19 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 540
Location: Poland
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
                          \   /
                           \ /


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Thu Sep 05, 2019 4:58 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8557
Location: Seattle
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" ?


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Thu Sep 05, 2019 10:32 pm 
Offline

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


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Fri Sep 06, 2019 12:41 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 540
Location: Poland
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.


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Fri Sep 06, 2019 4:39 am 
Offline

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


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Fri Sep 06, 2019 9:29 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8557
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: VRC5
PostPosted: Fri Sep 06, 2019 9:51 am 
Offline

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


Attachments:
mapper547.cpp [5.08 KiB]
Downloaded 1 time
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group