It is currently Tue Dec 18, 2018 7:04 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Fri Nov 30, 2018 11:15 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 450
Location: Poland
I have this this weird cartridge for quite long time (called Asder PC 95):
Image Image Image Image

It looks like some add-on cartridge for those keyboard famiclones, mainly designed for learning English language (everything is about guessing words)
Image Image

Brief analysis has shown that the cartridge might have additional audio channels (audio lines are wired to some mysterious chips)So let's reverse engineer it:
Image

There is 1MB PRG-ROM, 8kB CHR-RAM, Mapper blob chip (which seems to be MMC3 with exact pinout (ommiting WRAM and CHR-A13..A17 lines), second mysterious blob, opamp, 7474, and PAL16V8.

PAL is read-protected but I was able to deduct its functionality after analyzing its behaviour.
Code:
  n4C04 <= (!M2) | (!CPU_nROMSEL) | (!CPU_A14) | (!CPU-A2) | (CPU_A8) | (nC00) | (CPU_A13);
  O4 <= D6 when M2 & nROMSEl & A14 & !A13 & !nC00 & !A8 & !A2 & !A1 & A0
  O2 <= this line behaves weird, seems to be some helper line for the above latch
  O3 <= D6 when M2 & nROMSEl & A14 & !A13 & !nC00 & !A8 & !A2 & !A1 & !A0
  O1 <= this line behaves weird, seems to be some helper line for the above latch
  D7 <= INA when M2 & nROMSEl & A14 & !A13 & !nC00 & !A8 & !A2 & A1 & A0 else 'Z'
  PRG_A19 <= O3 when !CPU_A14 & !CPU_A13 else
             O4 when !CPU_A14 & CPU_A13 else
          '1'


So except the ordinary MMC3 registers ($8000-$ffff), there are a few others coming from the PAL:

Code:
Mask: $fd07
$4C00 (w): [.P.. ....] - sets outer 512 kB PRG-bank for $8000
$4C01 (w): [.P.. ....] - sets outer 512 kB PRG-bank for $a000
$4C02 - nothing
$4C03 (r): [I... ....] - I=value of INA pin, .=OPEN BUS
$4c04 (w): [.... ....] - outputs 0 on OUTA
$4c05 (w): [.... ....] - outputs 1 on OUTA
$4c06 (w): [.... ....] - outputs 0 on OUTB
$4c07 (w): [.... ....] - outputs 1 on OUTB


For pedantics:
* $c000 and $e000 always point to the last outer PRG-bank selected
* Those bits does not take into account if MMC3 is configured in swap-PRG mode ($8000.6=1)
* After writing value to $8001, game code writes the same value to $4c00 when $8000=#6. Same wieth $4c01 when $8000=#7. So it can be emulated as oversided (1MB) MMC3.
* Hardware logic does not not distinguish between read and write cycle for above registers, so when writing into a readable reg - bus conflict occurs and when reading from writable reg - actual written data will be unknown (due to open bus behaviour, probably high byte of the opcode)
* CHR-RAM A10..A12 is controlled by MMC3.

INA/INB seems to be inputs (due to pulled-ups to VCC)
OUTA/OUTB seems to be general purpose output pins for generating arbitrary waveforms so I called them that way (they're also pulled to VCC for unknown reason)


Mysterious BLOB chip and unpopulated 8-pin header:
There is a unknown blob chip with the following lines wired into the die:
Code:
 01    02    03    04    05    06    07    08    09    10    11    12    13    14    15    16
100nF  VCC   GND  OUTB   INB   OUTA  GND   INA   |      |   GND   SND+   VCC  SND-   VCC   GND
to GND                                           +-160k-+         
reset?                                        clock generator?     


There are also unpopulated 8 pins which are not only vias, but also seems to create some kind of header-connector for connecting unknown peripheral (note square shape for determining first pin)
Image
Code:
SND- VCC SND+ INA GND OUTA INB OUTB


I found ROM called `ASDER PC-95 (16-in-1) (Arab)` which has quite different menu items and music varies. Also it is only 512 kB. Arab version is controlled using Subor Keyboard.
Image Image

However, the Korean one described in this topic does not respond to joypad nor Subor Keyboard (game does not even poll $4016/$4017). Later I found out that it writes/reads to a bunch of another registers every frame, which seems to be designed for communicating with keyboard.

Code:
          read $4900;
  +------equals #$e6?---------+
  | yes                       |no
 \./                       \./
$491f <- #$00     |     $4904 <- #$00
$491f -> read     |     $4906 -> read
$491f <- #$01     |     $4904 <- #$01
$491f -> read     |     $4906 -> read
...               |     ...
$491f <- #$0a     |     $4904 <- #$0a
$491f -> read     |     $4906 -> read
                  |     $4904 <- #$0b
                  |     $4906 -> read
                  |
$4905 <- #$82     |     $4905 <- #$82
                        ...
depending on values read from $491f/$4906
only FFs -> the code polls joypad
only 00s -> the code doesn't poll joypad


So it looks like $4900 is used for distinguishing between different version of registers used for keyboards communication.
There is 11 (or 12 byte) keyboard buffer. Value written to $491f (or $4904) sets pointer to desider address of the buffer and
reading from $491f (or $4906) returns its value.

Keyboard layout:
I started by guessing which bits are responsible for up/down/left/right and return. Then I looked at the Subor's keyboard layout and found it to be similar. Then I applied it to the game logic and at least the following keys work: letters, numbers, space, return, arrows, backspace, delete.
Code:
      ----------------bits (0=key pressed, 1 = key not pressed)------------------------------
      ----7----  ----6----  ----5----  ----4----  ----3----  ----2----  ----1----   ----0----
-$0-- V          5          E          F2         C          F          G           4
-$1-- X          3          W          F1         END        S          D           2
-$2-- HOME       DELETE     PRIOR      F8         RIGHT      NEXT       BACK        INSERT
-$3-- PERIOD     0          6          F5         COMMA      L          I           9
-$4-- DOWN       BACKSLASH  LBRACKET   F7         LEFT       UP         RETURN      RBRACKET
-$5-- LCONTROL   1          A          ESCAPE     TAB        Z          CAPITAL     Q
-$6-- J          8          U          F4         M          K          Y           7
-$7-- LSHIFT     EQUALS     P          F6         SLASH      APOSTROPHE SEMICOLON   MINUS
-$8-- B          6          R          F3         SPACE      N          H           T
-$9--                                  NUMPAD2    NUMPAD8    NUMPAD4    GRETURN     NUMPAD6
-$10- NUMPAD8    NUMPAD2    NUMPAD1    F12        F11        NUMPAD7    NUMPAD4     LMENU
-$0a- NUMLOCK    DIVIDE     NUMPAD5    F10        NUMPAD9    MULTIPLY   ADD         SUBTRACT
-$0b- NUMPAD0    DECIMAL    NUMPAD3    F9         SPACE      PAUSE      NUMPAD6     GRAVE


What is to be examined:
1)
Register $4C03.7:
This is also unknown use. Game every frame makes such loop:
Code:
3F:E39F: AD 03 4C  LDA $4C03 = #$FF
3F:E3A2: 29 80     AND #$80
3F:E3A4: D0 F9     BNE $E39F


If the returned bit is set, game does not respond on clicking any position in the menu. My guess is that those OUTA/OUTB are used as clock/data for some external input device (yet another version of keyboard?), while $4c03.7 is like ready/busy signal and one of the INA/INB is used as data signal from the device to the cartridge.

2) How to stimulate the glob to generate some audio (by OUTA/OUTB/INA/INB lines). Measuring on scope both sides of the 160k resistor shows no signal, so maybe it is defected? Or it is the kind of chip, used for generating pre-programmed sounds that only generate clock while playing sound?)
This is waveform on those lines after powerup:
Image

3) What external peripheral can be connected to the unknown header and what is the protocol

4) I started data/code logging in FCEUX, clicked every position in the menu and played the game for quite long time but is shows only about 3% of code executed and 7% of data used. Looking at the non-used portions of ROM shows something that looks either as random or compressed. 1024 kB of game and only 10% of code/data is used? Weird that this game is 2 times bigger than the Arabic version but it does not even have a text editor.

---

ROM:
https://drive.google.com/file/d/1iBb5vE ... jQMOR/view


Top
 Profile  
 
PostPosted: Fri Nov 30, 2018 12:39 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
Marking on the LM386 looks authentic. UTC is a real company that makes them and the datasheet agrees with the markings in your photo.

Any idea what the unpopulated wire bonding site is above the CHR RAM? 29 lands is a weird number.


Looking at the ROM, vast swaths of it contain something with higher-than-normal entropy (compressed data?) (8kb-106kb and 590k-1014k). The histogram is more uniformly distributed than 6502 code, text, or picture data, but has clear structure: there's both something going on with period 18 bytes as well as many byte pairs that are disproportionately present.


Top
 Profile  
 
PostPosted: Fri Nov 30, 2018 12:55 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 450
Location: Poland
Quote:
Any idea what the unpopulated wire bonding site is above the CHR RAM? 29 lands is a weird number.

Every CHR-RAM pin is also routed there so it's probably option for blob-CHRRAM (probably there is something similar under the PRG-ROM for PRG-ROM in blob version)

Quote:
Looking at the ROM, vast swaths of it contain something with higher-than-normal entropy (compressed data?) (8kb-106kb and 590k-1014k). The histogram is more uniformly distributed than 6502 code, text, or picture data, but has clear structure: there's both something going on with period 18 bytes as well as many byte pairs that are disproportionately present.

Thanks! Maybe some compressed song voice data?

I think the protocol looks like I2C (or I2S)
Image


Top
 Profile  
 
PostPosted: Fri Nov 30, 2018 1:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7842
Location: Seattle
70kbit/sec isn't out of range for I²C ... too slow for I²S though.

The sections I identified are clearly neither PCM nor ADPCM.


Top
 Profile  
 
PostPosted: Fri Nov 30, 2018 3:34 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 450
Location: Poland
There is a mini-game where you choose subject, object and verb out of few ones to built english sentence and later the whole sentence is displayd.

Image Image Image Image

After choosing each of them, a chunk of 4 x 16 bits are transmitted, for example:
apple:
0010100000000011 2803
0000000001000011 0043
0010100000000011 2803
0100011111010000 47D0

kicks:
0010100000000011 2803
0000000001000011 0043
0010100000000011 2803
0101101111010000 5BD0

tree:
0010100000000011 2803
0000000001000011 0043
0010100000000011 2803
0001011100110000 1730

And when the whole sequence is displayed (THE APPLE KICKS THE TREE), there are 5 chunks (each 4 x 16 bits)
Second chunk is the same as for APPLE, third is the same as for KICKS and fifth is same as for tree. And First and fourth are also the samo (THE). So those sequences definitely are used to play one of the built-in voices for the words.
And the INA becomes high during the sequence speech and goes low after it is finished so that the CPU knows where to feed next word to play

Normally, there was a 36 ms gap between each of the fifth packets. When I replaced the 160k resistor with 300k resistor, the gap lengthen to 72ms so the R is used to control internal frequency generator.

Unfortunatelly, there are no sound waveforms generated at all and those gaps are suspicious short (play of each word should take at least around 1-2 seconds).
Maybe there should be some oscillator or RC circuit in place of resistor


Top
 Profile  
 
PostPosted: Fri Nov 30, 2018 10:51 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
The voice data is most likely some kind of phoneme data. MLX, who owned the cartridge, had no Subor Keyboard, so he could not play far enough to trigger a voice sample being played to record it. Hearing it may provide a hint as to what kind of phoneme-processing IC is being used. The CPU interface, for what it's worth, does not match any of the TMSxxx chips in MAME. I have looked at the protocol before, and it's definitely not I²C.

Also, I have assigned Mapper 531 for the Korean PC-95 in NintendulatorNRS, which does run it using the Subor keyboard and keypad, and the game clearly does poll $4016, so I am not sure what you are doing to make it not do that.

The Arabic PC-95 ROM image on the other hand is a badly-done mapper 241 hack that crashes at various points.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 2:13 am 
Offline

Joined: Tue Feb 14, 2017 9:50 am
Posts: 97
Footage: A, B
Courtesy of someone with the proper hardware.


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 3:54 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 450
Location: Poland
Quote:
Also, I have assigned Mapper 531 for the Korean PC-95 in NintendulatorNRS, which does run it using the Subor keyboard and keypad, and the game clearly does poll $4016, so I am not sure what you are doing to make it not do that.

It depends on what your emulator returns for reads from $4900/$491f/$4906. FCEUX returns simulates open bus by returning high byte of address which causes the ROM not to poll $4016.

I have bought keyboard-famiclone console (GLK-2004) for testing this cartridge and it does not responds to keyboard. Then I placed it in specially prepared game-genie cartridge which overrides reads from 4906 by returning $ff and navigation bye joypad was possible.

Maybe it is not exactly I2C but it looks very similar (start = falling edge on DATA when CLK = 1, stop = rising edge on DATA when CLK = 1, data changes when CLK = 0 and valid when CLK = 1)

If you look at the first photos that I got from MLX, there is a solder-short circuit between 74139's pins 7 & 8. I don't believe this was accidental cause the holes in vias are so small, you cannot put so much amount of solder through them. And doing this intentionally also is weird cause it shorts output to GND (all my further tests were done after removing that excessive solder)
Image

BTW. There is yet another version of the cartridge (polish) which is probably arabic translation. The mapper is yet different (writes to $8000/$8001/$8002/$8003 sets 8kB PRG bank at $8000/$a000/$c000/$e000) but it uses the same keyboard protocol as the korean version. They assigned them mapper 168 but that is invalid.
https://media.classicgames.me/nes/17644 ... poland.nes


Top
 Profile  
 
PostPosted: Sat Dec 01, 2018 4:21 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
krzysiobal wrote:
Maybe it is not exactly I2C but it looks very similar
Similar yes, but no valid I²C device ID and such.
krzysiobal wrote:
There is yet another version of the cartridge (polish) which is probably arabic translation. The mapper is yet different (writes to $8000/$8001/$8002/$8003 sets 8kB PRG bank at $8000/$a000/$c000/$e000) but it uses the same keyboard protocol as the korean version.
Are you sure that's a good dump? Because I never got it to run under any mapper, not even as you describe.


Top
 Profile  
 
PostPosted: Sun Dec 02, 2018 8:03 pm 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 450
Location: Poland
Look's like value written to $8003 needs to be OR-ed with 1 (initial values: $8000=0, $8001=0, $8002=0, $8003=1)
When $4904=#$b:
* when $4906 returns 0 - black screen appears immediatelly after a second of showing menu
* when $4906 returns 1 - menu hangs
* when $4906 returns 2 and above - looks ok (game is controllable via the same keymap as I shown above)

Game writes to a bunch of different registers:
* $a000, $a001, ..., $a007 (0, 1, ..7) but only at startup - so they probably set 1kB CHR-RAM banks
* $c000, $e001, $4910, $4911, $4912

for F-BASIC/ G-BASIC probably RAM at $6000-$7fff needs to be present

Image


Top
 Profile  
 
PostPosted: Mon Dec 03, 2018 11:31 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 709
Indeed, OR'ing $8003 with $01 runs the Polish PC-95 ROM image. Kind of a pointless mapper design...

Also, I have to eat crow: only now that I have looked at my mapper 531 emulation source do I realize that I have actually remapped the $490x protocol to Subor keyboard reads/writes so I would not have to actually implement that custom keyboard. I had totally forgotten about that. Sorry for the confusion. :oops:

That remapping code works for the Polish PC-95 ROM image as well. I will assign NES 2.0 Mapper 365 for the Polish version of the mapper (below 512 because it was released outside of East Asia, and 360-364 being used for multicarts that I am going to document on the wiki shortly).


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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