Asder PC 95 Korean cartridge analysis

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

Post Reply
krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Asder PC 95 Korean cartridge analysis

Post by krzysiobal » Fri Nov 30, 2018 11:15 am

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: Select all

  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: Select all

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: Select all

 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: Select all

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: Select all

          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: Select all

      ----------------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: Select all

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

lidnariq
Posts: 8765
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Asder PC 95 Korean cartridge analysis

Post by lidnariq » Fri Nov 30, 2018 12:39 pm

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.

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: Asder PC 95 Korean cartridge analysis

Post by krzysiobal » Fri Nov 30, 2018 12:55 pm

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)
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

lidnariq
Posts: 8765
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Asder PC 95 Korean cartridge analysis

Post by lidnariq » Fri Nov 30, 2018 1:21 pm

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.

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: Asder PC 95 Korean cartridge analysis

Post by krzysiobal » Fri Nov 30, 2018 3:34 pm

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

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

Re: Asder PC 95 Korean cartridge analysis

Post by NewRisingSun » Fri Nov 30, 2018 10:51 pm

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.

MLX
Posts: 105
Joined: Tue Feb 14, 2017 9:50 am

Re: Asder PC 95 Korean cartridge analysis

Post by MLX » Sat Dec 01, 2018 2:13 am

Footage: A, B
Courtesy of someone with the proper hardware.

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: Asder PC 95 Korean cartridge analysis

Post by krzysiobal » Sat Dec 01, 2018 3:54 am

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

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

Re: Asder PC 95 Korean cartridge analysis

Post by NewRisingSun » Sat Dec 01, 2018 4:21 am

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.

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: Asder PC 95 Korean cartridge analysis

Post by krzysiobal » Sun Dec 02, 2018 8:03 pm

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

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

Re: Asder PC 95 Korean cartridge analysis

Post by NewRisingSun » Mon Dec 03, 2018 11:31 am

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).

krzysiobal
Posts: 589
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland

Re: Asder PC 95 Korean cartridge analysis

Post by krzysiobal » Sun Jan 06, 2019 3:54 pm

I don't know what is going on, but I come back to this topic and the audio chip started working. The outputs of SND+/SND- lines looks similar to the SUBOR one (PWM pulses), though the whole chip seems to be rather raccepting data in serial, instead of paralel format.
Here is what is transmitted to make it say word "apple".
INA definitely acts like a BUSY line (0=ready to accept next command, 1=busy)

Image Image
Attachments
Apple Rides The Flower.zip
(100.48 KiB) Downloaded 145 times
sound_apple_saleale_logic_analyzer.zip
(521.82 KiB) Downloaded 138 times

Post Reply