Asder PC 95 Korean cartridge analysis

I have this this weird cartridge for quite long time (called Asder PC 95):


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


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:


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.


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



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:


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)



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.


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.



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.


What is to be examined:
1)
Register $4C03.7:
This is also unknown use. Game every frame makes such loop:


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:


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

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.

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)


Thanks! Maybe some compressed song voice data?

I think the protocol looks like I2C (or I2S)

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.

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.



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

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.

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

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)


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

Similar yes, but no valid I²C device ID and such.
Are you sure that's a good dump? Because I never got it to run under any mapper, not even as you describe.

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

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.

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

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)