NEC PC-98 (and compatible) emulation

[joncampbell123]

Such machines are said to be similar to IBM PC, though with different video hardware and proprietary bus, but with DOS just the same. Would be a nice feature to add to the DOSBox-X codebase.

[joncampbell123]

Info:

http://people.freebsd.org/~kato/pc98-arch.html
http://euc.jp/articles/pc9800.en.html
https://en.wikipedia.org/wiki/NEC_PC-9801

Video chipset:
https://en.wikipedia.org/wiki/NEC_%C2%B5PD7220

---

(Aybe)

some more info:

General

Intro to NEC PC-9800 World

NEC PC-9800 Quick Guide

Documents

Index of /docs/content/computing/NEC <- BIOS docs, Japanese X)

To translate with Chrome:

https://archive.org/stream/PC9800TechnicalDataBookBIOS1992/PC-9800TechnicalDataBook_BIOS_1992_djvu.txt

http://hackipedia.org/browse/Computer/Platform/PC%2c%20NEC%20PC%2d98

Emulators

PC-98 emulators

Neko Project II

Neko Project 21/WでWindowsを動かす

[sikthehedgehog]

I have my doubts that the PC-98 is really that close enough. I mean, there are nearly perfect ports of Rusty and Totsugeki Mix, and I know Windows was ported to the PC-98 too (using dedicated drivers), but besides the CPU I have my doubts of it having enough in common to make it trivial. Just warning.

That said, having an easy to use PC-98 emulator on Linux would be nice :P (no need to rely on Wine anymore)

[joncampbell123]

True, however I am making some architectural changes that would better allow alternate PC-98 emulation to coexist with the DOS emulation we have now.

[sairoutine]

I really need this feature :)

[joncampbell123]

Would be cool, yes. The changes are going to take a lot of time to work in by myself.

Basically 99% of DOSBox-X assumes PC/AT hardware. Conditional code needs to be added so that if machine=pc98 is given it emulates PC-9821 hardware. Lesser changes need to be made for the DOS kernel, since DOS is the only thing common between PC-98 and IBM PC.

Pick something small to work on and submit patches for me to integrate. I do have a life to live. I will help too, since I just got a PC-98 laptop to test against.

I have been gathering PC-98 software and whatever bits of information I have. Most of it is in Japanese so I'll need help with translating it. I can provide that as well to help.

[sikthehedgehog]

Isn't the DOS actually quite diferent? I mean, if I recall correctly it has extensions in order to draw Shift-JIS text for the sake of kanji support (for the record, there's a DOS extender for the same purpose for IBM PCs). Of course one could probably just use a disk image in the meanwhile.

The only thing in common is pretty much the CPU, albeit the bitmap support meant that Windows could be ported to it (that's a whole story on its own).

[joncampbell123]

From what I understand, it's MS-DOS with modifications for the PC-98 BIOS, a proprietary PC-98 partition table, and support for SHIFT-JIS, with all text in Japanese. If that weren't true, I would not have been able to run PKUNZIP on an old PC-98 last night to transfer files over floppy. Everything else is proprietary to PC-98.

In the long run PC-98 emulation will have to affect the BIOS interrupt vectors, PIC mapping, I/O ports, etc. but in the meantime it might help to add minor things like DOS/V emulation, a SHIFT-JIS font and rendering, and modifications to the DOS kernel to emulate more PC-98-ish things if machine=pc98. I know DOS/V is Microsoft MS-DOS for IBM PC, the point is that would be one way to add, test, and develop SHIFT-JIS console rendering at the start.

I don't expect DOSBox-X to run something like Touhou Project for a long while, but you do have to take steps to get there.

I could do my part if I were to add support for the D88 disk image format that the PC-98 world seems to like to use. The D88 format's representation of the physical tracks and sectors would also help emulate MS-DOS games that use intentional bad sectors or funny sectors as a form of copy protection.

One thing I will want to do on my end to keep the code working is add test cases and self-testing code to make sure things work properly despite these modifications, in order not to break anything as we proceed. That's what I'll be doing with DOSBox-X in the coming months. Patches are welcome, though they will be applied to branches off of master to keep master stable, then eventually merged into master.

I will be able to help with emulation as I have just recently acquired an old NEC PC-98 Lt2 486DX laptop which I will be able to poke at now from the DOSLIB project. Contrary to what I've heard about 3.5" 3-mode it takes the IBM 1.44MB format just fine.

[joncampbell123]

I have been able to collect some documentation so far on PC-98:

http://www.hackipedia.org/browse/Computer/Platform/PC,%20NEC%20PC-98

I will add to this collection as I find more.

All of it is in Japanese, but that's all I can find.

[sikthehedgehog]

I can speak (sorta) Japanese but I don't have much time (and translation takes a lot of time, I'm not particularly fluent to be fair) so I can't help much :/

Thankfully tech docs tend to be reasonably easy to guess if you have a vague idea of what to look for (unlike most text). I'd suggest to just machine translate it and then maybe ask for help if a particular part doesn't seem clear.

[joncampbell123]

Machine translation is.... okayish... so far, though it doesn't help with some of the PDFs that were scanned from manuals (no text to copy-paste).

[joncampbell123]

It's not feasible to rewrite the DOSBox-X bootup process to emulate machine=pc98. So to develop it gradually, machine=pc98 boots up into IBM PC/AT vgaonly mode, and the Z:\ drive contains a GOTOPC98.COM that replaces interrupt vectors and signals emulation to relocate I/O ports to emulate NEC PC-9821. Interrupts and I/O ports can be implemented gradually this way, until full emulation is complete and machine=pc98 can eventually boot up entirely in PC-98 mode.

[sikthehedgehog]

Machine translation is.... okayish... so far, though it doesn't help with some of the PDFs that were scanned from manuals (no text to copy-paste).

Ack. Some PDF readers do OCR on the fly to select text, but yeah OK that sounds like an issue :/

[john-at-charpa]

At the risk of stating the blindingly obvious - have you considered peering at the nekoproject II source for clues? It's a completely different project than DOSBox, but the source is fairly well organised. If anything it might help with hardware details that may not be documented well, even in Japanese.

http://amethyst.yui.ne.jp/svn/pc98/np2/tags/VER_0_86/

[joncampbell123]

I definitely have! It's one of my major references to PC-98 hardware and documentation, even if many parts aren't all that well commented.

[joncampbell123]

Also, recently I've managed to acquire actual PC-9821 hardware to test against to confirm whether or not the documentation is correct. It is thanks to Neko Project II and some PC-9821 laptops that I have been able to test and develop DOSLIB on PC-98 as far as I have right now!

[john-at-charpa]

Fantastic job. I've been smiling into my coffee all morning at the Pentium Pro CHANGELOG entry too. Emulate ALL the things!

[joncampbell123]

The latest commit adds 8255 emulation, and hacks the timer and interrupt emulation to move to different I/O ports when you run GOTOPC98.COM to switch into PC-98 mode. It's very minimal at this stage but it works so far.

I've tried to make comments comprehensive enough to explain what I'm doing and why.

As a side effect of that development, there is now a RE-DOS.COM command that exits and restarts the DOS kernel (without rebooting the whole system).

[joncampbell123]

Self notes for further development:

• The keyboard itself seems to handle the CAPS, KANA and NUM key states (including toggling the LEDs).
• The NUM key does not return any scan codes
• CAPS and KANA will only send a code on keypress. When sent, the make/break state depends on whether pressing the key has enabled or disabled the mode.
• Pressing and releasing a key produces make/break scancodes as you'd expect.
• However, holding a key produces a repeating sequence of make/break codes (instead of IBM PC/AT keyboards that re-send the make code while held down). When the key is finally released, a break code is sent.
• The serial codes (thankfully) do not have multi-byte "escapes" for newer keys that AT keyboard do.

[joncampbell123]

I just added code to emulate the text VRAM of the GDC.

I added code to use ANEX86.BMP from the Anex86 emulator for the character ROM, which works great though it doesn't quite cover the odd unusual and non-JIS character bitmaps seen on real hardware (outside normal shift-JIS range).

I have an important question about ANEX86.BMP. Is it legal to build it into DOSBox-X or should I just leave it as a file you have to pick up elsewhere off the internet?

[joncampbell123]

I've done a lot of work on the video emulation lately that some games are even playable. Even, surprisingly, Touhou Project (though you need a cycles count of at least 30000 to avoid flickering sprites, and the scoreboard on the right doesn't show for some reason).

I'm not sure what to make of the various INT 18h calls yet, so things are still iffy and this is where I need help.

• How do games call INT 18h in a way that clear the text RAM? Hard to play games with your DOS prompt still on top of the graphics...
• How do games switch between the 400-line and 200-line doubled graphics modes? (Marble Madness is playable but squeezed vertically until I figure this out).
• Can I legally incorporate ANEX86.BMP into Dosbox-X?
• If so, can I also incorporate some nonstandard (in font RAM but outside normal SHIFT-JIS encoding) characters that some games use? (ex. Hearts, sweat drops, gradient blocks, a ghost...)
• Why do Marble madness and Sim City act as if someone is always holding a joystick up and to the left?
• Anything use EGC graphics modes? Currently neither EGC nor 256-color mode are implemented.
• Any games that expect to manipulate the digital 8-color palette vs the analog 8/16-color palette?
• The 4th bitplane at E0000h on real hardware is mapped out until enabled. Where is the enable?

Considering the sparse and even a bit contradictory documentation I have I appreciate any inputs or corrections on the emulation as it progresses and it might help to playtest as many PC-98 games as possible.

[joncampbell123]

Update:

• Most games can call an INT 18h call to fill the screen with a character and attribute (normally to clear the screen). Other games seem to rely on GDC mode changes to clear the screen (my best guess that works well enough is implemented now, so that you can play games without your DOS prompt overlaid on top).
• Implementing font RAM load call in int 18h makes overlay text and graphics visible. Marble Madness is now able to show score and messages. Several other games are now able to show their menus. The only odd one out is Touhou Project which appears to rely on loading font RAM but does not use the BIOS to do it (??). If I can figure that one out the scoreboard and text will become visible.
• It turns out that, contrary to good MS-DOS programming practice, several games (including Touhou Project) relied on poking at variables directly within MS-DOS kernel memory. Touhou Project in particular relies on a byte at 0x70:0x12 to determine the number of text rows (or else, it cannot clear the text layer properly). This poking at DOS memory is even encouraged by the "undocumented PC-98 collection" with a full list of these variables. Eugh.
• I was able to add INT 18h GDC modesetting code well enough that games using the 640x200 graphics mode display correctly now (Marble Madness, Tetris, Pacman, some misc. beat 'em up games). However the PC-98 port of "Gods" doesn't page flip correctly, yet and some screens show twice instead of changing content.
• Page flipping and scrolling are supported in the games, but I don't believe I have the timing correct on when the GDC would latch the scan offset vs when to fire the vertical retrace interrupt. Many games when scrolling come off as jumpy and sometimes flicker, as if DOSBox-X is not matching expectations.

[joncampbell123]

Update:

• I figured out how PC-98 games were "page flipping" and made other fixes.
• Flickering in many games is resolved.
• Jumpiness and scrolling is perfect now.
• "Edge" opening "cut scenes" render properly, instead of one or two panels showing up garbled.
• "Gods" renders correctly now, though it runs very fast at high cycles counts.

Yet to resolve:

• Touhou Project isn't clearing the text layer properly, preferring to just draw new text on the old (making a bit of a mess). Also one sprite is drawn in a XOR ROP mode (the lens flare in the background of one level) that isn't properly emulated yet. Everything else is perfect.
• Based on running the same set of games on real hardware, "Edge" shows that there's at least some kind of horizontal panning control that the game uses during some of the opening cutscenes, but I can't figure out how to emulate that yet.
• A few games using the 8-color modes (Tetris) have stopped working entirely (nothing shows up). UPDATE: Just fixed that, Tetris works again.

Findings on real hardware:

• If you have the PC-9801-86 FM card, DON'T run Gods on an NEC PC-9821. The random noise is atrocious to the ears. Perhaps it's the same I/O relay problem with Yamaha FM synthesis that IBM PC games face talking to the Adlib ports 388 and 389, I don't know. Several other old titles have the same problem. The newer hardware is too fast, apparently. Newer titles do not have this problem. However, "PCM" digitized audio seems to work.
• The particular unit I tested on was the newer generation with VGA ports rather than the 15-pin analog connector. The PC-98 640x400 graphics+text mode was being rendered at VGA-like 70Hz mode (31KHz) rather than the 56Hz mode (24KHz) most games were made for. This is fine, except that the BIOS seems to misprogram the master GDC sync parameters in a way that causes horizontal sync to overlap the left edge of the active display area (over the first 16 pixels) which confuses my VGA capture cards a bit (some render that part dark and active video causes dark streaks over the picture, others won't capture properly). Since I found the datasheet for the GDCs NEC uses, I might write a tool to send new sync parameters to move horizontal sync off the screen later on. Windows 98 SE doesn't have this problem once the desktop switches to 1024x768 mode on the system.
• One game (Kemesis, I think) reprograms the graphics GDC in a way that produces scrambled rolling graphics beneath the text layer (meaning, now the text and graphics GDC are out of sync with each other)

I've gone as far as I can developing this code, so I will be moving on to other things now. A lot of what I've done is guesswork and a few hacks. The code assumes 16-color mode at all times at this moment, the switch between 8-color, 16-color, and 256-color is not implemented at this time (nor analog/digital mode). Have fun and throw your PC-98 library at DOSBox-X to see what works and what doesn't. Post your results here, with screenshots if desired.

[joncampbell123]

Additional information:

• One thing with the graphics GDC, by the way, is that there is parameter RAM that defines "display partitions" in terms of VRAM offset and number of lines. This can be used to do scrolling, and splitscreen effects. The NEC datasheet officially defines up to two partitions for graphics, and four for character mode. The latter 8 bytes are supposed to be for graphics drawing operations. "Edge" seems to have been written for hardware that permitted all 16 bytes to define four partitions, because otherwise some cutscenes will not appear correctly and the health bar at the bottom will not display correctly. DOSBox-X allows all four for this reason, however real NEC PC-9821 hardware appears to violate this assumption and enforce two (at least the late generation model I have). I do not yet know if older generations and PC-9801 allow four display partitions.

[joncampbell123]

One more thing to know:

• DOSBox-X does not translate filenames. If the game relies on Shift-JIS file names, then they will have to exist on your system with the exact byte sequence of the original filename, even if that appears garbled on your host system. Not a problem on Linux ext3/ext4 filesystems but may stand in the way of emulation on Windows. I'm considering adding code to use GNU libiconv on Linux to translate the filenames from guest to host for this reason (using the currently active "code page" in MS-DOS emulation).

[sikthehedgehog]

Good to know that PC-98 is just as messy as its IBM counterpart.

I'm assuming many old games just plain won't work on newer machines for touching things they weren't supposed to touch.

[cuba200611]

Hello.

Speaking of the PC-98, there's a quite active Discord server (of which I am a part of) in which people there can provide help.

I do own a real machine (a PC-9821Xb10/J8), but I need to do some things to it first (such as adding a soundboard and replacing the floppy drive (which is dead) with a HxC or a Gotek flashed with the HxC firmware).

[sikthehedgehog]

I honestly was under the impression that FM was never onboard, just that it was so common among gamers that games expected it if you wanted sound. But I'm not an expert on PC-98, admittedly.

This actually doesn't seem to be that far off from what happened in the West (where many PCs still didn't have sound cards and hence games would be stuck to either PC speaker beeps or outright no sound altogether… playing Half-Life 1 and not knowing what people were saying wasn't fun). Not surprising either, computers were still expensive at the time and not the norm at homes yet.

[joncampbell123]

From what I've found so far, you generally needed an addon card to get the FM synth.

However some documentation suggests there was a short-lived "CanBe" series that had some sort of FM emulation built-in (though the sources suggest it wasn't 100% compatible).

Of course I could be confusing a few things, recalling off the top of my head like this. Need to verify the sources.

[cuba200611]

This site has a list of models with built-in sound hardware: http://hp.vector.co.jp/authors/VA004562/ray/tips.htm

Although the CanBe models use an YMF288 (OPN3) with a Windows-compatible PCM chip - a Crystal one IIRC. The PC-9801-118 is basically the CanBe sound hardware on a card, and for it to work in DOS, you need to disable plug and play, but again, some games will not sound properly due to incompatible PCM hardware, among other things...

[stgiga]

No, the 118 is an opl3+opn3 chip called the ymf297

[yksoft1]

It might be made using Neko Project II and either NP2 or Windows chose a wrong font generating those characters.

those awkward glyphs are not generated from font, but embedded in FontMaker binary.

Seems I also found those glyphs in Neko Project II's fontdata.res file.

[joncampbell123]

Does VEMM486.EXE / VEMM386.EXE implement any additional function calls beyond the base Expanded Memory Manager interface?

I've already noted that Briganty crashes with EMM386.EXE loaded, both in DOSBox-X and on real hardware, however it doesn't seem to have any problems with VEMM386.EXE on real hardware (I'll check again to make sure).

However DOOM, DOOM II, Wolf98, Sim City 2000, and anything else involving a DOS extender crashes when VEMM386.EXE is loaded.

DOSBox-X already has an ems=emm386 setting, is it going to need a ems=vemm386 or ems=vemm486 setting too?

According to the original spec, function calls only go up to AH=5Dh. http://hackipedia.org/browse.cgi/Computer/Operating%20Systems/MS%2dDOS/EMS%2c%20Expanded%20Memory/Expanded%20Memory%20Specification%20%28Lotus%2c%20Intel%2c%20Microsoft%29%20v4%2e0%20%281987%2d10%29%5b2%5d%2etxt

[joncampbell123]

What does EMS function AH=70h do?

Touhou Project 4 seems to call it at level start. It doesn't prevent the game from running but I am curious what that EMS function is supposed to do.

[joncampbell123]

Good news. If PC-98 FM board emulation is enabled, and SOUND.ROM is in the current directory at startup, DOSBox-X will load that into memory instead of installing it's own stub routines. At least one game, Sente Hisshou, requires a working SOUND BIOS to play music and will only play silence with the stub routines provided without SOUND.ROM.

Of course said game will display nothing on screen without also working LIO BIOS routines...

[Corak667]

• info
  http://pc98.pulsethread.com/
  http://newsonya.narod.ru/pc9821/index.html
  http://euc.jp/articles/pc9800.en.html
• 1813 game set:
  https://archive.org/details/PC98_Games_1813

[joncampbell123]

pc9801v-keyboard-cable-pinout.pdf

[joncampbell123]

pc-kd854-video-connector-pinout.pdf

[joncampbell123]

pc98-dsub9-mouse.pdf

[joncampbell123]

pc98-mdin8-keyboard.pdf

[joncampbell123]

Thank you! Site snapshotting in progress: wget --mirror --progress=bar --timestamping --connect-timeout=5 --read-timeout=15 --limit-rate=250K --wait=10 --random-wait --continue --dns-timeout=10 --force-directories --recursive --no-parent --wait=2 http://pc98.pulsethread.com/

[joncampbell123]

https://twitter.com/drachen6jp/status/1210109285629227009

[RNMB15]

I found a list of graphics cards that are compatible with NEC PC-9821.

http://hamlin.html.xdomain.jp/VGA/VGA498/VGA498.htm

[roytam1]

I found a list of graphics cards that are compatible with NEC PC-9821.

http://hamlin.html.xdomain.jp/VGA/VGA498/VGA498.htm

there is more listed in http://hamlin.html.xdomain.jp/VGA/VGA98SE/VGA98SE.htm

[Wengier]

There is now a PC-98 draft Wiki page here which explains DOSBox-X’s PC-98 system and how to use it to run PC-98 games or applications in DOSBox-X:

https://github.com/Wengier/dosbox-x-wiki/wiki/Guide:PC%E2%80%9098-emulation-in-DOSBox%E2%80%90X

If there are any suggestions please feel free to let me know.

[RNMB15]

I have something about the PEGC:
https://www.satotomi.com/sl9821/sl9821_tec5.html

[stgiga]

I used Unifont-JP 13.0.06 to remake FREECG98.BMP.
https://cdn.discordapp.com/attachments/347494769296932864/850140815959130133/FREECG98.BMP

"1 June 2019 Release (Unifont 12.1.02)
These are the major changes, by Paul Hardy:

Added Japanese unifont_jp TrueType and BDF versions containing over 10,000 glyphs from the JIS X 0213 kanji character set in the public domain Jiskan16 font. The TrueType version includes the 303 glyphs from JIS X 0213 that are in Unicode Plane 2 — the only Plane 2 glyphs that I plan to add. A brief history of Japanese font encodings and of the conversion of JIS X 0213 fonts to Unicode appears on the Japanese Fonts page. "

(Unifont-JP [on https://unifoundry.com/unifont/index.html] uses proper Japanese forms of the relevant ideographs, and thus is more accurate than the old FREECG98.BMP which was made by me well before Unifont-JP even existed. The later releases of Unifont-JP added further improvements to Japanese characters) Please replace FREECG98.BMP with this more-accurate version.

[Wengier]

@stgiga Note that @roytam1 uploaded a new FREECG98.BMP earlier this year in #2132, and the updated BMP file is available from:

https://github.com/joncampbell123/dosbox-x/blob/master/contrib/fonts/FREECG98.BMP

(The original FREECG98.BMP file is still available here: https://github.com/joncampbell123/dosbox-x/blob/master/contrib/fonts/FREECG98_OLD.BMP)

Can you both check if there is any difference between the current FREECG98.BMP and the new FREECG98.BMP @stgiga posted and decide which one to use? Thanks!

[stgiga]

The part about "HyperSnap" and replacement has me worried, which is why I did this. If those improvements by @roytam1 matter they can be done again on the version generated from the same tool I used to generate the original FREECG98.BMP, just to be safe. Because I generated FREECG98.BMP using a version of NP2 that had TTF support that it would then output to a BMP with the filename "font.tmp". I did this same process on Unifont-JP for this new version. My advice is for roytam1 to do the same improvements as before but to this known-good Unifont-JP version.

[Wengier]

Thanks @stgiga.

And for @roytam1: How do you think about it? Thanks.

[Wengier]

I am adding support for Japanese EGA mode (machine=jega) in #2576, and this also makes use of converted fonts from FREECG98.BMP. So improving FREECG98.BMP will improve the default fonts in Japanese EGA mode too.

[roytam1]

@roytam1: How do you think about it? Thanks.

it contains improvements from unifont-jp already. using non-free tool doesn't affect the status of my freecg98.bmp since it is generated from free font(s).

[stgiga]

@roytam1 I wasn't concerned about tool status. I was concerned about accuracy in regards to the Kanji, and also whether or not your workflow involving HyperSnap could have caused any issues, because HyperSnap is a screenshot program. My regeneration of FREECG98.BMP was done via the same lossless process (NP2's generator mode) as my first FREECG98.BMP. You are welcome to port your improvements to that. I just wanted to be certain that there wasn't any Kanji errors, since a complaint in the original FREECG98 was that some Kanji were the Simplified Chinese forms. Unifont-JP guarantees fixes of the affected instances. A contributor is planning on doing Japanese EGA, which the dev says would benefit from better FREECG98.BMP glyphs, which in combination with the fact that Kanji form accuracy is often important, makes it a good idea to unify Roytam's improvements into the regenerated FREECG98.BMP to ensure maximum accuracy.

[roytam1]

@stgiga the font I use is Izumi Gothic 16 which is the font that unifont-jp adapts, while unifont-jp doesn't make use Izumi Gothic 16 fully and my freecg98.bmp used every glyph from Izumi Gothic 16 to generate, including half-width forms.

[Wengier]

With the latest code DOSBox-X will first try to load FONT.ROM and FREECG98.BMP, and if both are not available DOSBox-X will fallback to builtin DBCS font used by DOS/V and pre-generated SBCS font from FREECG98.BMP for PC-98 mode. Thus an external font file is no longer required for PC-98 support, but is still recommended if you want to use the original PC-98 fonts for rendering in PC-98 emulation..

[RNMB15]

So has anybody here seen this thing yet? Aparently it will allow you to upgrade an internal YM2203 to a YM288-M, basically giving you soundboard 86 compatibility.
Some caveats, according to the article, are that you lose joystick compatibility, balance between SSG/FM is off, and it's incompatible with some games. Still, very interesting that this exists now in 2023.

Links:

https://akiba-pc.watch.impress.co.jp/docs/news/news/1509513.html?fbclid=IwAR1_TPvKyQgbCBb433qItNOQlsy0Iwj3tzGavBdBhdl-Khbffy6a4pMhp5g

https://www.remambo.jp/auction/item/j1087087163?fbclid=IwAR2Gy7F4ZXrPvHXXJr7H1nNcxb1h395v0n95iqgmeSLSN5KsxLzsmCpnSS4#photo

http://offgao.net/pcb/001/?fbclid=IwAR0WJIstJGjhKCfu7KLz-VAlI5KIiLP88U7uTW3C_yVezSxnT93eF0ZSZRM

https://www.facebook.com/groups/179691252054199/posts/6641649715858288/?comment_id=6642563712433555