I haven't done too much webpage work recently (compared to my usual high output, eh?) Why? The usual culprits all at once: work got busier, wife got pregnant, bought an apartment, scurrying around everywhere with loan documents, city documents, hospital documents, etc. Then finally the move and birth of my first child in March, 2012.

But I have been busy trying to keep my sanity through all this, so that's what I'll document.

Well, it has been a long time since the last update!  What has changed?  Well, that's not important right now; what HASN'T changed is that almost every day I listen to lovely video game music on my music player of choice, the Dingoo emulation system, mentioned a full 9 years ago at the bottom of this page. The program OldPlay running on the Dingux OS on this device plays most retro music formats, including SID, NSF, GBS, VGM, SPC, HES, etc.  It reads WinAmp-style .m3u playlists, plays subsongs in ripped formats like NSF and SID, and even detects silence at the end of a track in order to move on to the next (sub)song.  It's great!  And I still haven't found a device with the right music software to replace it, despite my Dingoo's screen getting all scratched up and looking like the rotated feature phone screen that it really is. Finally, late in 2019 a budget system, the "New" PocketGo, or PocketGo 2, caught my eye, as it was (finally) performant enough for 60fps emulation, but also had OldPlay among its list of applications.  Well, I am happy that it has OldPlay on it, but unfortunately OpenDingux OldPlay is not Dingux OldPlay.  The person who took on the OldPlay project to port it to a different OS/Hardware type introduced some changes, which introduced some bugs.  This was unfortunately in 2013, on message boards, so finding a solution to the following problems might cause me headaches. But anyway, my laundry list of New OldPlay complaints: In older versions of OldPlay, it would play through all subsongs of a single file before moving on to the next file. OldPlay would auto-detect silence in a subsong, and move on to the next subsong. The same applies to .HES, .GBS, .KSS files which may have an .M3U playlist, which sets a subsong ordering (and timing for each subsong). The 1.35 version of OldPlay does not do this. It plays through whatever subsong is last chosen by the user, then when that one subsong's time is up, OldPlay loads up the next file. Meaning, the normal way to enjoy NSFs, SIDs, GBSes, HESes, KSSes, is now broken.
	Top: The old Dingoo A320 from 2009. Bottom: the New PocketGo. You'd think that a span of 11 years would mean emulation quality and clock speed growing by leaps and bounds, but... not so much.
There's no way to set controls / key mappings, as in the old OldPlay. Thus, no HOLD (button lockout) combination, screen blanking, etc. I've found that on the PocketGO 2, holding Power+B does a controller/button lockout OF SORTS. GZIPped files, which would get decompressed & played in the old OldPlay, now no longer play in OldPlay v1.35. This means to play Sega (Genesis/SMS) VGZs, you have to decompress them all onto your SD card to play them. In OldPlay v1.35, subsongs 1 and 2 of SID files seem to play the exact same tune, meaning the final song in any SID can't be accessed. So, yeah, any one of these can be called the straw that broke the camel's back.  I still, unfortunately, have to stick with my old Dingoo system.  I would like to find the authors of OldPlay and ask them to fix these bugs; if you are in contact with them, could you send them my way?  In the meantime, I'm almost of a mind to get the OpenDingux SDK and try to fix the bugs myself, not that that would be any easier. Well, until next time, folks.

Wow, has it really been that long since I updated this page?  So, what's been going on since the fall of 2014?  Quite a lot -- some things really interesting, and others not so great.  In November of 2014, I released a little game on the PC-Engine named HuZero.  I'm glad with the way it turned out and the reaction it got from people.  Of course, it being "not really Mode 7" on the PCE, it had to fit precisely halfway between the old-fashioned linescrolling racing game and true rotaty-spinny-zoom-in-and-outy Mode 7 racing, which brought a few complaints about its gameplay or control scheme.  Ah, well.  I just hope the game gets remembered as the months go on.  Plenty of people continue to send me their high scores for HuZero, but I have a slightly nagging fear that retro forums and news aggregate sites keep looking for the "next big thing", making cool game releases on retro hardware each have a shorter time in the public limelight than they deserve...

After that, I spent my free time in December '14 making a cool music player for the PCE, where it would play ripped game music while displaying its notes & instruments on-screen.  You could even mute or solo each audio channel, to really pick apart your favourite songs on the PCE.  Over new year's, I was stuck in Iwate (Northern Japan) at the in-laws' house with no internet connection whatsoever for several days, so I did more game music ripping for this player.  I have some fond memories from 11pm on New Year's Eve, lying under the warm kotatsu, next to a crackling fireplace (the house finally silent since everyone had already gone to bed),  finishing off a rip of Devil's Crush and working on Ninja Spirit as the last programming of 2014.

Anyhow, moving on to this year, I was kept busy with awesome new projects and "firsts".  First off in January, I was asked to help out with the reverse-engineering of the obscure SEGA AI educational computer.  I was able to program in Intel 80186 assembly for the first time in 19 years, would you believe it?  This was necessary to create an (again!) RS-232 interface between the AI and my PC for RE-ing work.  Then in February-March, I did more Sega programming, this time in (similarly almost forgotten) Z80 code for the Sega Master System.  I made a fun little program to manipulate the FM sound hardware of the Japanese SMS for some wickedly weird music and sound effects.

April and May...  ...were not good months for me.  In fact, I'd like to pretend that they never happened, as they cast a pall over my mood this year, even as late as December.

So, if you're wondering why my entire post this time seems to be programming, programming, hacking, and more programming, maybe there is some kind of connection.  When life was stressful or uninspiring for me, delving into the cool details of retro software and hardware proved extremely therapeutic and even uplifting.  Perhaps in a way akin to Bob Ross' mantra, every day that you spend programming is a good day.  Even as early as February, or maybe even last year, I had cool ideas building up in my head that I had to try out someday, and now here I am, laying them out in sequence: PCE audio, SMS FM, FDS, PCE RS-232, and so on.  I have a backlog of cool programming things to try, and my enthusiasm for them hasn't waned even with them being on the backburner for months.

In June, I started doing a translation of an FDS game from Japanese to English, then moved on (by an irresistible urge) to making an RS-232 serial monitor/dumper/uploader/savestate all-in-one program for the PC-Engine.  This was so fun, so interesting, cool, and actually so useful that it made me fall in love with the PCE even more (and no, I'm not going to marry it!).  The Famicom/NES is my favourite videogame console of all time, but darnit, the PCE is first for coding, and for gaming it might be a close second, perhaps... maybe... even beating out the SNES/SFC (which itself got almost no playtime this year, tellingly).

So I think I'll write some more extolling the benefits of doing some programming every day, specifically ASSEMBLY programming, especially PCE ASM programming, on its own page.  I've gone on for long enough about that sort of thing on this one.

Well, I'll wrap this up with a hope that everyone has an amazing, fantastic, and peaceful 2016.  For those that haven't found the hidden secrets in my PCE demos and games: Hey, there are some hidden things, you know.  Try looking for visual hints.   Or waiting.  Or use a HEX editor.  For those that have found them: Keep fighting the NSA, listening to your hearts telling you what's fair, and listening to the Earth telling you what can't continue.

Well, I've been keeping busy this year, especially since Feb./March with a really fun project that I actually had had the idea for way back in 2009, but I reattempted it and got it working this year, at last. I can't talk about it now, but perhaps sometime soon. For now, I'll just put up a choice 80s-style logo:

Other cool things I'm happy about this spring: I delved into 68000 (Amiga) and 65816 (SNES) assembly programming for the second time in my life. Second??? Well, back in university (1998-1999 or so) I tried picking up 65816 assembly and found simply initializing the SNES hardware too complex for my young mind at the time. And around the same time, I bought some second-hand Amiga Hardware Reference Manuals that had assembly examples for dealing with the registers and memory structures -- needless to say I found them even more overwhelming and never wrote a single line of code at that time.

Years later, here I am still crazy about my Amiga, and with video tutorials on Youtube to make Amiga demo coding more accessible than ever, I made my first steps by modifying the tutorial code to my liking... I've nothing to show for it just yet, but perhaps some day I will (hopefully not after another 16-year gap, though!!)

I also went back to the 65816 instruction set and found it easier to learn the new opcodes and special SNES registers than back in the old millennium, and I coded up my first SNES demo with 2850 colours on-screen, simultaneously. (see right.) Okay, so all it does is display a static image of the colour spectrum, with brightness adjustment to fade in from black, and fade out to white. But I made the code, tile graphics and tilemap from scratch (ie: no tutorials or pre-made programming templates.) Also, my code is very simple: I make use of an H-Sync interrupt (in the form of HDMA) only once in the middle of the screen when I switch from colour subtraction to colour addition. The rest of the hue/brightness interaction is done with BG1 and BG2 blending through the SNES' transparency mode. BG1 has a simple rainbow palette going horizontally across the screen, and BG2 has a black->white gradient going vertically down the screen. Combined they make the rainbow mathematically fade through various levels. Nothing spectacular, but... I looove the colours!

So, yeah, I consider the first half of this year a time of coming full-circle: achieving some (small but) long-term goals that had lain dormant for 5, 15, or more years. I hope there'll be more achievements to come!

Last but not least, I received an e-mail from a couple of NES sceners living in Finland. They were coming round to Japan and wanted to know if I'd like to meet up with them. Hell, yeah! So I met up with the demosceners Markus (Mankeli), Visy, and Paaris in Akihabara, and we chatted for a while about 6502 coding, demos, retro gaming, the NES scene in Europe, lots of fun things, over beers. Then we went off to a retro arcade/museum where we played original, ancient arcade games like Toki, Fantasy Zone, and others that were even older! All in all, I had a great time and I'd love for more retro meetups of this type. Anyway, here's a memorial pic (me in the middle):

Well, here we have arrived at the end of the year 2013, and though not exactly eventful for me, it has been a busy year that felt like it flew by.  In the Spring, my son started daycare, which meant an extra hour of free time for me every morning, and mmmmaybe a whole Monday to myself.  Fate steps in on occasions like these, though, and administers a proverbial enema -- that is to say, if there's one night of the week when my son will get ill, catch a cold, or come down with a fever, it will undoubtedly be Sunday night and thus the daycare staff will not look after him the following day.  Ah, well...

So, in the Spring my wife, son, and I took a 2-day driving trip down to Ito resort in Izu, south of Tokyo.  It wasn't quite warm enough to enjoy the beach just yet, but we did manage to relax a bit and feel like we were actually on holiday.  I found a reasonably-priced "business" hotel on the beach that we discovered was really "quaint" and "old-fashioned".  Just look at the quaintness of our room modeled after a 1940s-style Japanese house, complete with dial phone!

The owner of the hotel was similarly old-fashioned; while my wife heard his right-wing views before we checked out, I espied a few arcade games in the dining area and had a go on a couple of them.  The sit-downs were the common Super Real Mahjong PII by Seta, and Tetris, by Sega!  I had a go on Tetris, but the joystick and rotate button were wonky, so I didn't last too long.

The one game that I really wanted to have a go on was Dirtfox, a racing game by Namco with a scaling & rotating overhead view similar to their better-known Assault.  It was a lot of fun, and I was lucky to play some long, lost arcade games on my holiday.  Most of you out there should know how rare it is these days to find some classic games in a hotel lobby -- not to mention in actual video arcades! While on vacation, we did the usual touristy things: go for short hikes along the coastline, eat delicious deep-fried seafood, get lost down winding roads...  I also picked up a bottle of the local "specialty", Shizuoka Cola, which, as revealed by its colour, is a green-tea-flavoured cola.  Not relishing what horrors awaited me, I was pleasantly surprised when it tasted quite delicious, similar to all the other designer colas around the world, I suppose.  It actually had barely the slightest flavour of tea to it, but I guess the company succeeded in nabbing another sale from tourists and curio-seekers like me.

Finally Seeing the Light: RS-232 Cables and FDS Rewriting

Another very interesting thing that I started this year, and which has paid dividends over several months in terms of programming challenge, technical elucidation, and even practical enjoyment, happened in March.  I had finished wiring a data transfer cable for the C-64(DTV) used in tandem with a program called DTVTrans.  DTVTrans (as the name implies) is a simple, fast synchronous way of transferring programs from the PC to a C-64, using the PC's parallel port and the C-64's joystick port.  Well, anyway, one day in March I looked at my DTVTrans cable... and I looked over at my Famicom... and I looked back at the cable.  I then wondered if there couldn't be some way to get my PC transferring data to the Famicom/NES in the same way! Well, fortunately the DTVTrans "safe boot" protocol is very simple, and the cable only requires 3 data lines one way, and an acknowledge line going the other way, something which I believed the Famicom's expansion controller port had.  So, hardware-incompetent me delved into the pinouts and bit mapping of the Famicom's expansion port, and wired up a connector that fed into the DTVTrans cable.  I then wrote an NES program that monitored and toggled these data lines.  It was quite a learning experience, because for the first 10 minutes, all the data looked totally random and strange until I wrote down the bit patterns on paper and realized that on the Famicom, logic levels are reversed!  That means a "1" is 0 volts, while a "0" is +5 volts.  After finally realizing this basic truth (about many game systems/electronics projects, by the way) I verified that the data coming into the Famicom was valid.  In only a couple of hours, I had high-speed uploading & software booting happening reliably on the Famicom.

The most practical thing to do with this feature, in my eyes, was to expand my NES/Famicom program TapeDump to allow for FDS disk rewriting, something that hasn't really been possible since Brad Taylor's FDSLoader.  FDSLoader was great and all, but I hadn't been able to use it since 2004 or so, since it required a Windows 9X computer or earlier, and in pure DOS mode, at that.  So, at first, I experimented with getting files copied over to the Famicom and simply booted in FDS RAM.  Next I learned how to write files to the FDS, and then finally after a day of trial-and-error, got full FDS rewriting happening, including "manual" rewriting of the disk's header file.  I now had an extension to TapeDump that did fully automatic .FDS file uploading and disk rewriting!

Since FDS rewriting was a reality for me once again, I went on a fun shopping trip to Akihabara, picking up any cheap, "junk" FDS disks that I could find.  Here you can see the picture of a good day's haul: Magician Lord and Crossed Swords for the Neo-Geo MVS, and about 30 FDS disks that I can use as rewriting fodder in the future.

Soon after this, prodded perhaps by some complaints that parallel ports were themselves a dying breed in the PC world, I endeavoured to get more barebones ways of data transfer to the Famicom working.  One of the ways requiring the least amount of hardware was again the simple KCS audio transfer method, this time using the Famicom's microphone embedded in the 2nd controller.  I found some KCS code in a few Famicom games that use the data recorder, and modified their routines a bit so they would listen to the Fami mic, operate at different baud rates via timing loops, etc.  This second method of receiving data now allowed for FDS disk rewriting with no interfacing hardware at all... just a direct wire from a PC's audio output to the Famicom's microphone wires.

A third big geek-out happened for me in the summer when my retro computing interests were piqued by the Epson HC-20 vintage portable computer (seen in the pics above and below.)  Tape transfer of BASIC programs was extremely slow and unreliable on the HC-20, so I finally bit the bullet and bought a USB serial port adaptor.  Not only was I able to transfer programs smoothly and semi-quickly (4800 baud maximum) between the HC-20 and my PC, but I discovered I was also able to update the PIC firmware inside my Minimig to a much more capable level, including support for Turbo CPU speeds and hardfiles on SD card.  Transfers between my PC and Minimig also became really smooth by using the serial port rather than slower SD card transfers by .ADF bullshit.

In short, I discovered anew the versatility of the RS-232 transfer standard, as it spans over 50 years of computing and still remains compatible & simple to set up and understand.  So, I also started working on implementing RS-232 game dumping as well as FDS data uploading in TapeDump.  It works, but implementing it has been much more error-prone and frustrating than the DTVTrans method.  I still haven't totally finished up the new version of TapeDump, but when it is finished, it'll be able to dump games via 2 different methods, and rewrite FDS disks via 3.  There has been a lot of head-wall interfacing this year, but thanks to my family and some engrossing and rewarding hobbies, my free time has never been dull.

I recently picked up a piece of computing history -- and a fun gadget in its own right -- an Epson HC-20. It's the Japanese version of the Epson HX-20, both of which are considered the world's first notebook computer. Not a suitcase-sized "luggable", nor merely a calculator with BASIC tagged on, but a computer with full-sized keyboard, storage and printer. Okay, so the display is a disappointing 20x4 characters, an Achilles' heel of the machine. Still, it's a lot of fun to play with, as it can hold 5 separate BASIC programs even with power off, has a fully automated microcassette recorder for permanent storage, and a dot-matrix printer for printout of anything under the sun -- program listings, screen dumps, you name it! The integrated input/output features of this computer are really what make it an item useful in many fields -- well, in 1982, anyway! Unfortunately, the model that I received (at a decent price, mind) had a non-working microcassette drive, a dry ink ribbon in the printer, and a totally dead wired NiCd battery pack (Achilles' heel #2), so I knew it would be a bit of a fixer-upper when I bought it. In due time, I got a new printer ribbon and a 4xAA battery holder for power, but the tape drive was another matter. At first, the door wouldn't even open to release its microcassette trapped inside! So, it was time to do a little diagnostic surgery on the (removable) tape module.   Next: Microcassette Drive Repair... or not.

The tape drive is an extremely compact device, driven by a large motor in its top-left, with the read/write head engagement mechanism driven by a separate small motor at the bottom-left. I first found out that the door wouldn't open because the head mechanism was still engaged with the tape, with a further lock on the door latch when this is so. I wired up a battery to this motor and watched it cycle between read/stop modes via its oblong engagement gear, and then got that microcassette the hell outta there. A little bit more time applying power to the main drive motor, and I was satisfied that this thing would spin the tape spools, anyway. When I re-connected the tape unit to the HC-20 and typed in "LOAD", the drive still showed no signs of life, so I opened up the computer itself to see if there were some connection problems. The cassette/expansion connector is wired to the main board by a flimsy flat cable covered in cellophane, all of which was in the process of rusting and/or disintegrating. (All inter-board connections use flat ribbon cables, which is the HX-20's Achilles' heel #3.) Turns out one or two of the connections are broken there as well, so I temporarily taped down some of the cracking wires for mechanical support. Now, with all this, the tape drive could be controlled: rewinding & fast-forwarding worked, and the LOAD function made the tape start up... but it gave up with an IO ERROR a couple seconds later. Hmm... Well, it was pretty clear that under normal operating conditions, the drive belt in the microcassette unit was simply too weak and loose to get the tape playing at a decent and constant speed. The belt has degraded and cracked over the years, as anything made of rubber will eventually do. Drive belts truly are the bane of a retro gamer's life, and I am so glad we've moved on to solid-state media.

Still, I wanted to find out what was on that microcassette tape. I thus went to the local Hard-Off and found a "junk" Sony microcassette recorder for 500 yen. I took it home and it, too, refused to play the cassette. Blah. So I removed its casing and got deep into its innards to find that the recorder could play the tape with a little mechanical coaxing of the winding spool (I used a toothpick on the tape spindle for this.) However, on playback, the spool still crunched and stuttered noticeably, like a gear somewhere was loose. Worse still was that this stuttering was audible through the speaker, meaning recording the audio on my PC would be impossible. I disassembled the recorder further until it was a bare skeleton of capstans and gears, and found out that the forward drive gear was missing a single tooth! A small flaw, but it was enough to cause freezing or stuttering of the tape on every revolution. (Plastic gears becoming brittle over time and cracking is bane #2 of a retro gamer's life, I hardly need to add.)

Anyhow. I just ripped all these gears out. The tape motor and drive belt (working well enough, thank you) still spin the read head's capstan at a constant speed, so I can play the tape and do all winding myself -- yes, 2 1/2 minutes making little stirring motions with a toothpick is truly a surreal experience that I recommend to everyone at least once in one's life. Well, with the recorder's headphone output hooked up to my PC's audio in, I captured a good recording of the game stored on tape, despite all the flutter, the muffled signal, and other unwanted noises on the tape. I then played back the recorded audio file to the HC-20 through its external cassette line input jack, and it recognized the game's header right away, loading perfectly the first time round! So! On to the game...   The Game: Jumping Pawn

I'll be honest right at the start and tell you that it's not a very exciting action videogame or anything... It's a simple strategy game where you have to advance your "pawns" on a 9x3 grid to check the opponent's pawns. The loser is the one who has his rightmost 9 squares occupied by the opponent's pawns. Not even a strategy game, really, more like a mathematical-based Towers of Hanoi or NIM-styled game where your first move predetermines everything. What is interesting about this game is that since it's written in BASIC, anyone can look at its source code and learn its inner secrets. I did just this. When I was sure that the game worked fine, I reloaded it and straight away printed the whole program listing onto paper. It is very cool to look at source code from 1982, with the programmer's name and everything, and to think just how far we have come from those days. An added bonus is finding out a few of the tricky ways that the author tried to protect his program from tampering. While Jumping Pawn has no copy-protection as such, it does protect itself from your untrained doofus who might try to edit the BASIC program out of curiosity or mischief. I'll document some of these protections below.

 1  '**************
 2  '*            *
 3  '*JUMPING PAWN*
 4  '*            *
 5  '*    by      *
 6  '*Makoto Horai*
 7  '*            *
 8  '*Programmers3*
 9  '*Copyright(c)*
 10 '* '82 Nov/15 *
 11 '*            *
 12 '**************
 13 CLEAR 500,0:MEMSET&H0 
 B00:SCREEN0,0:WIDTH20,4
 14 FORI=0TO119:READX$:PO 
 KE&HA40+I,VAL("&H"+X$):N 
 EXTI:POKE&H11E,&H0A:POKE 
 &H11F,&H40:IF PEEK(&H198 
 F)<>&HAE THEN 61
  ...

 61 TITLE " ":NEW:PRINT "
                       
  IX=A:D1$(A)=LV$:GOTO 1000 

 61 IX=A:D1$(A)=LV$:GOTO 1000 

Download a reconstituted WAV file of Jumping Pawn here.

Here's something quite cool that I found recently in a junk shop:  a wireless PC keyboard using a PS/2 interface!  Of course, these are not that special nowadays, with teensy-weensy Bluetooth KBs everywhere, but back in 1998, if you wanted to get untethered from your computer, such things were rare. The infra-red box plugs into your PC's KB and Mouse ports, as well as having its own PS/2 combination jack as a peripheral pass-through.  The hand-held unit runs on 2xAA batteries and is extremely tiny and slim.  There are switches for "default" operation, as well as buttons for momentary switching of operations.  (The mouse L and R buttons operate all the time.) If I want to type on the keyboard, I can use a fingertip nail or use the metal stylus that slides out from the bottom of the unit.  To switch to mouse operation, I can slide the switch, or tap the square at the top-left of the input surface.  The KB surface acts as the input device for both tablet and "mouse" input, with the difference between the two being that merely touching the surface in tablet mode registers as a mouse click, while you need to press the L or R buttons to register clicks in mouse mode. (Double- and triple-taps are accepted as mouse button clicks in mouse mode as well.) Despite the microscopic keyboard keys, this is an extremely intuitive and useful combination input device that will save space when I'm playing with my Minimig or C-64 DTV!

<------ Do you know what these things are? If you're from Europe, you certainly do.  If you do any retro gaming (and if not, honestly -- why are you here?) you'd probably know something about the 21-pin RGB standard in Japan and Europe. If you still have no idea what I'm talking about, then check out this cute screenshot of Shinobi Kidd over to the right!  There's more Sega love to come during this diary installment, so you can at least look forward to that! Sad to say that North America never got an RGB connection standard for consumer TVs & video games.  But Europe still has their SCART standard.  Even in Japan, RGB is becoming a forgotten format.  It appeared in the mid-80s (as far as I can tell) but with the advent of the D1-D5 connector (see sad-looking guy in the middle) TVs from the late '90s began to stop using RGB.  So there now are fewer and fewer picture-perfect analogue TVs than before... But, my purpose is not to get all wistful on you.  It's to do a little technical dissection of the Japanese 21-pin RGB connectors that I have.  You will see that not all RGB plugs are created equal. ;-)

Pictured above, clockwise from left, are: a 3rd-party multi-system (SFC, PSX, DC, XBox) RGB cable with gold-plated connectors; a 3rd-party MegaDrive cable; an official Nintendo SFC cable, and an official Sega Saturn cable.   They all have a slightly different casing and, like your best-not-spoken-of kin in Arkansas, not always a full set of teeth.  Surprisingly, the highest-quality and most solid connections are in the gold cable, and the worst are in the SFC and Saturn cables.  Why the difference?

Well, in order to provide an RGB signal to a monitor, the bare minimum number of pins that are needed is five: pins for Red, Green, Blue, Sync, and Ground.  Add one or (if you're lucky) 2 more pins to this for Left and Right audio if desired.

Sadly, Sega cheaped out and took this route.  Take a look at the Saturn's 21-pin RGB connector below.  It has those 5, plus stereo audio, and only one more pin for +1/+5 volts to the monitor.  And that's all.

The outer shield of the connector has its own wire going to it as well, but that's mainly for insulation, and goes to the ring around the mini-DIN connector on the Saturn.  The result of this bare-minimum approach to RGB cables is often that the picture, +5V, and audio pins use only a single common ground connection, leading to crosstalk on the signals.  Crosstalk in its most noticeable form is noise through the audio output.  I was always a bit annoyed when I ran the Saturn through RGB because with only one ground pin, it had to be connected in just the right way, or else the sync would be missing.  Or one of the colour components would be gone.  Or the sync pin would come out of the speakers as a loud buzzing instead.  Nasty.

An ideal RGB cable is supposed to (spec->) have separate ground connections for each of the RGB components, separate ground for audio, more ground connections for sync/video, and even an extra "pretty-please" ground on pin 14, which actually happened to be the lynchpin for my monitor.  No ground connection on pin 14 when I used my Sega Master System in RGB, and the picture was dimmer and the audio more buzzy.  Go figure why such a thing is needed, but it seems to be.  It was (still is) also missing from the Saturn's RGB cable.

Here's the Super Famicom's RGB end-connector:

When I first got this thing, there was hardly any picture at all, due to some 14-year-old capacitors going bad (the SFC is from 1990, after all.)  The circuit board loaded with working electrolytic caps is necessary to remove the SFC's weird DC-biased RGB levels down to normal, but since this thing was so rusted and corroded anyway, I just bought the much nicer 3rd-party cable instead.  I now use this SFC cable (sans capacitors) for general RGB connections to my PC-Engine, Neo-Geo, Minimig, SMS, etc.  Anyhow, the SFC's cable was mostly properly connected, but still missing any connection to its shielding.  Plus the pins are cheap and too easily bent and corroded.  They cannot guarantee a good connection to your TV at all times.

Why am I talking about this in the first place?  Well, I wanted to play me some old-fashioned Sega goodness.  Take a look:

	Alex Kidd in RGB World
Good old Wonder Boy in its Japanese form (note the superfluous "Super" in the title)	"Hustle Chumy", dunno what it means, but it's a fun little platform chase for the SG-1000

Yeah, I had some fun playing the classic SMS games that I had, and even ran some really old SG-1000 ones that I had yet to discover for myself, via Tototek's SMS flash card (seen atop the towering US->JP converter on the right.)

The Japanese SMS is pretty fantastic since most of the games released from mid-1987 - 1989 had FM music that sounded pretty groovy on it (or on a Mark III with FM-pack attached.)  It's not as rich and elaborate as Genesis or arcade game FM music, but it's alright considering the slightly limited OPLL chip it uses.

An aside about SMS FM music:  Why does it sound a bit limited?  Well, at first I thought it was simply because the composers had to make a composition that fit two separate sets of audio hardware (the second being PSG for regular Mark IIIs and overseas SMSes) thus they couldn't do any crazy FM warbles, do extreme pitch changes, etc.  But actually the YM2413 OPLL chip that is in the JP SMS is itself quite limited.  Not only is OPLL only a 2-operator FM, compared to the Genesis' 4-operator FM, but it's a also low-cost version that means 15 out of the 16 instruments are hard-coded.  (Think of a Yamaha keyboard that only has 15 presets like "trumpet", "electric piano", or "synth bass" and you wouldn't be far off from the truth.)  Only one single instrument can be freely defined on the chip.  Which means that all FM SMS music uses the same 15 instruments for everything.  Maybe if you're lucky, you'll hear a custom instrument...

Playing the SMS this way was fun, but finally I got sick and tired of the groovy FM audio coming out of the dinky single speaker of my RGB monitor.  Same goes for the Saturn on my RGB monitor, as both the SMS/MD and Saturn cables have no break out jacks for hooking up the audio to a stereo system.  See the picture directly above?  Those speakers on the sides are outputting nothing because the RGB cable imprisons the audio signals.  The SMS is not a big loss, but all those awesome games on the Saturn lacked something without clear subwoofer-enhanced stereo output.

Time to make a breakout box, then!

I had a female 21-pin connector already in my electronic parts box, but I needed some way to connect the flaky Saturn and SMS RGB cables to the much better gold multi RGB cable.  The easiest way was to go to the local Hard-Off shop, get a PS1 A/V breakout box, and modify that.  I picked up two of them just in case from the junk bin and removed the male connector from one.  I then checked out how the gold RGB connector wanted its signals and wired the female RGB connector into the PS1 breakout box.  The gold connector turned out to be very well-connected, with the outer shield and audio ground wired together, and the video grounded properly on separate lines.  Funnily, they gave Bue and Green ground lines, but not red... so I fixed that. So, in the end, I can keep my trusty gold-plated multi-system RGB cable connected to my monitor at all times, which will undoubtedly save wear and tear on its 21-pin connector.  I can then use the existing RGB cables that I have and connect them to this breakout box.  If a poor ground connection is made, I can put lots of pressure on this box's connector rather than do a reach-around at the back of a monitor.  And best of all, I can connect stereo audio cables to all my systems through RGB and blast some great music through a nice subwoofer and speakers.  A nice, simple hack, and a learning experience for me about the Japanese 21-pin connector.		Left: Male PSX pre-op.  Right: Female RGB post-op

Oh, dear.

From time to time I get homesick about my Amiga. It's a long, bygone era by now, but I still miss that computer. I played on my friends' Amigas (3 of my friends had them, and that's amazing considering this was North America) from about 1990 onwards, and I finally got my own A1200 in about 1993.

Well. When I moved to Japan in 2002, I had to pack away my 2 Amiga machines in storage and leave them in Canada. ;_; I could only take my Toshiba laptop with me to Japan, and that just barely ran UAE. Still, I made do for several Amiga-less years.

One day around 2009, a Japanese friend of a friend came and visited me. He was and is deep into FPGA hardware design, making Famicom and PC-Engine implementations on them. Pretty amazing stuff. He also happened to have been sent a Minimig for testing and programming on, so he brought it over to my place on that day. After scrounging around Hard-Off for a PS/2 keyboard and mouse and a suitable regulated power supply, we had a Minimig up and running. For what it is, even the first-generation single-floppy-disk-with-no-writing implementation that he had brought over, the Minimig is nothing short of amazing. It's basically a (slightly incompatible and admittedly crippled) Amiga 500 that can run most games from SD card and display itself on a VGA monitor. Sweet. My friend let me keep the Minimig from that day. 8-D

Well, it was fun for quick doses of nostalgia, but the PS/2 keyboard was heavy and bigger than my desktop's, and the Minimig and my PC had to share the same monitor... plus it seemed to annoy my wife with it taking up space (as cables jutted out of all 4 sides of the damn thing) so I put it away eventually and kinda neglected it.

Anyway, nostalgia comes and goes in waves, and thus did it build in late 2011. I started getting urges to play those old Amiga games and demos again on a proper CRT monitor, not through crappy vaseline-smeared LCD interpolation. Well, the Minimig can output 31Khz VGA frequencies, but it also has a jumper setting for 15Khz (ie: TV scan rates). So it is at least possible to hook it up to the old RGB monitor I play almost all my games on. First step: get a VGA cable that can be easily modified into an adaptor for my RGB cables (9-pin D-SUB). I found one at (again,) Hard-Off that had a VGA+PS/2 cable on one end, and a LAN jack at the other end. The jack was in a plastic enclosure, soldered onto a circuit board, so I could simply remove the board completely and keep the RGB pins that I needed. After a bit of adaptor wiring and some cursing, I had a working VGA->RGB adaptor that could be plugged into my old monitor (or even an X-RGB or Japanese TV thru the 21-pin connector).

Minimig with homemade VGA->RGB adaptor

One problem: The Minimig usually outputs a 50Hz (PAL) display, which my VGA monitor handled fine but my RGB monitor, X-RGB, and TV in the living room can't stand. Not a surprise, since generally only European (or Chinese) tube TVs can handle both 50Hz and 60Hz standards. Fortunately, the Minimig also has a 60Hz NTSC firmware implementation for such people, so I used that. For the first couple of weekends and holidays, I had a good time checking out the ADF files I had, testing whether they ran in NTSC or not. About umm... 75% of them did with no problems, so I was pleasantly surprised.

After 2 weeks of good fun, my winter holidays started. This meant about 9 days free to play games or do some hacking. I first hooked the Minimig in NTSC up to our living room TV via an AV Demilo box. That same day, I decided to look inside of my RGB monitor to see if there was any way of making it work with PAL frequencies. Now, I've pulled TVs and monitors apart before, but each time I did, I was always deathly afraid of getting a nasty shock out of the electron gun with its 10000 live volts even when unplugged. So, I kept my distance from the cathode-ray tube and, just in case, made a screwdriver-type tool on the stove out of a plastic spoon.

I put in a game that had a PAL/NTSC switchable cracktro, so I could toggle 60Hz and 50Hz frequencies at will. At 50Hz, my monitor rolled uncontrollably, but I found inside the monitor the potentiometer for V-Hold and experimented with bypassing it using different capacitor values across the wires.

Well, in the course of that, I actually found the V-Hold "sweet spot" where the image would be stable at both 50Hz and 60Hz without the need for constant adjustment! So now my monitor snaps into sync whether the Amiga boots into PAL or into NTSC. Fabbo! *** Erm, not so fabbo... *** Turns out the monitor, with its lovely 50Hz/60Hz "sweet spot", switches great for my Amiga, Neo-Geo, PC-Engine, Saturn, MegaDrive and Playstation... but the lonely Super Famicom -- of all things! -- makes the screen roll uncontrollably. I got sick of the whole thing and desoldered the V-Hold pot, ran wires out to the back of the monitor, and soldered the pot in place externally. Why Sharp decided to put a useful control like V-Hold (and why not H-Size too?!?) on the inside of a general-purpose computer monitor just baffles me.
	Don't try this at home, kids!	That's the culprit on the left!

Anyway, now I can play any old Amiga game (and especially any demo) without worrying about monitor incompatibility or anything. Gaming ensued.     Lorraine's hooks were in me again!

Next thing I wanted to do was get a smaller keyboard and a mouse that I could actually use sitting on the sofa, or a cushion on the floor. It's not the Amiga experience at all if you have to lay the keyboard next to your lap and twiddle the mouse ball one-handed with your fingers to move the damn cursor. (Even with 95% of my playtime being games (and not application software) most of the cracktros out there on the Amiga require you to navigate with the mouse or lunge for the Function keys...) I scoured various Hard-Offs to no avail and then went to Akihabara to see what was for sale. Quite a few shops actually had really tiny mini-keyboard and mouse combinations that ran over Bluetooth... cool, but I was sure it would be a big pain getting it running into a PS/2 interface, if such a thing is even possible at all. I kept searching. Eventually, I found this in the dungeon of Akihabara's veritable electronic parts labyrinth, a small DELL PS/2 keyboard and trackball combo, in a cool shade of black and missing one key... but hey, the shopkeeper parted with it for 300 yen. Great. I could rest the little thing in my lap when necessary, and use the keyboard and trackball without having to balance, pick up, or risk dropping any loose peripheral.

Step 3 was modifying my Sega joypad to activate the Minimig menu, which meant not having to reach over to the Minimig itself, nor having to hit a key on the keyboard for this function. The updated Minimig firmware displayed its menu whenever UP+DOWN on the pad (impossible, of course) were pressed at the same time, so it was a simple (and Qn'D) matter of rerouting either direction to the MODE switch on my Sega pad. Now I could do it all from the sofa. No more reach-arounds for this guy.

The final problem was this ungodly mess of wires -- the Minimig itself. For some reason, FPGA hardware designers think it's funny and cool to have tiny boards yet which have connectors poking out of each side like some cyborg brain in a jar in any Japanese anime. Connectors on all sides negate space savings. Indeed, they double the footprint of the device at times. Take a look at the Minimig. It doesn't sit comfortably on a table, can't be sat vertically, can't be placed cleanly under or on top of a monitor without the risk of it looking like a squashed spider or prone face-hugger. Bundle all the cables together and it still looks like an octopus in a net. Look, it's poor design, if you've missed my point so far. The Amiga 1200 and 500 both had EVERYTHING coming out of the back, and it worked great.

So I looked around my room for a quick solution. One idea was to make a case for the Minimig out of a Neo-Geo MVS cartridge shell. It aaalmost all fit, except one of the two screw pillars for the MVS case buts against the Minimig PCB, so that was kind of a no-go. The second idea was just to get a small enough cardboard box and fit the Minimig inside tightly. So that's what I did with the box one of my MVS carts came in. I cut slots in the front-facing layers of the box where the SD card would slide in, and holes to let a glimmer of light from the disk and power LEDs shine through. On the side, I made a hole for one joystick port and a single square hole/flap from which all the various-facing cords could be led in a single bundle. The inserted joypad plug keeps the lid of the box tightly closed and thus an omnidirectional mess becomes a simple nondescript wires-out-the-back box.

Yeah, okay, so it's real ghetto to fit an electronics project inside of a cardboard box, but it works very well for me. And to highlight its added ecological benefits, I made a suitable label for my Minimig case:

Yeah, this post will probably annoy those die-hard silver-spoon Neo-Geo game collectors, but I bought another Neo-Geo multicart. I already had a 108-in-1, which is pretty good but lacking some of the oldest NG games. Plus, a couple of games were actually beginning not to work at all. So, I decided to buy the now-cheap 138-in-1 MVS cart. This multicart has a very good selection of games that even larger multicarts don't have, such as Nam-1975, and, er, others. It has all the Metal Slugs and hacked variants, Viewpoint, Blue's Journey, 8 Man, Shock Troopers, Zed Blade... the works!

The only thing that sucks about this multicart is that it has a JAMMA connector and PCB tethered to it as a "dongle." I discovered to my chagrin that it even bypasses my MV-1F's regular joystick ports when selecting games, so I had to attach a joystick connector to my little homemade JAMMA "supergun" that you can see below. The dongle actually has its own microcontroller and graphics display chip which overrides the Neo's own video when the machine is turned on. (Again, another example of Chinese pirates devising a hardware solution because they can't figure out how to do it the (much simpler) software way.) The joystick connected through the JAMMA harness selects the game from the menu, and using a few dip switches on the dongle, you can change default difficulty and lives for each game, and even hide/reveal games individually from the main menu (a godsend with all those boring fighters I never play.) After you choose a game, the multicart menu tells you to wait for 30 seconds as it resets the Neo-Geo TWICE (you can hear this all happening), I suppose as it communicates with the cartridge it's attached to, adds credits (and does some other mysterious things with the joystick.) It then relinquishes joystick and video (via the click of a relay) to the Neo-Geo itself, and the game starts up. A kluge if I ever saw one.

Multicart dongle (center), MVS 1F and multicart (right)	The smallest "supergun" ever, with joystick, RGB and power connectors, plus coin and power switches.

Anyway, the play's the thing, and this cart adds many more great Neo games at a low price, so I am, as they say, happy.

One more interesting thing to note about Neo-Geo multicarts: On NG collectors' forums, some people mentioned that certain games had glitched graphics and incorrect samples/audio. I wondered what they meant, since a game either has the data for these games, or it doesn't. Did some multicarts leave out entire sections of sample ROM area? How? And, why? What purpose would that serve (with so much space used willy-nilly for duplicate game hacks anyway.)

Well, when booting up some games like NAM-1975 and Cyber-Lip, I did in fact notice that whole instrument channels were missing in the former, and long samples were missing from the latter. The problem seemed to affect only the earliest Neo-Geo games. I did a little investigating and found out something new about the Neo-Geo and its YM2610 FM/ADPCM sample chip that I'd never known before. The YM doesn't have flexible, general-purpose PCM sample channels like the Amiga, or something. Rather, it has 2 separate buses for sample ROMs, an A-bus and a B-bus. The A-bus can play 6 channels of samples simultaneously, but at a fixed sampling rate of 18.5 Khz and at 12bits uncompressed. The B-bus has a single sample channel connected to it, and is the only channel (at 16 bits) that can have its playback frequency and loop point defined. Both buses use ADPCM compression to store their ROMs as 4-bit data.

Anyway, on the oldest Neo-Geo games, there were separate ROM chips (and indeed ROM buses on the PCBs) for storing samples of each type: A and B. Soon enough, SNK put a multiplexer chip into their cartridges so that sample buses A and B could share the same ROM chips. Obviously, these Neo-Geo multicarts emulate the multiplexer chip and thus haven't bothered to emulate the original separate A and B sample buses. Thus when an old game (Cyber-Lip, eg.) tries to point to a 16-bit sample on bus B, the multiplexer is still fixed to the bus A ROMs and we hear the wrong 12-bit samples or no samples at all.

Good, at least I now know technically why it's happening. Fixing the problem... well, that's sadly impossible for a mere mortal like me. :-(

After a long hiatus, I did some programming on the Famicom again. The trigger for this was to dump safely a Konami demo cart that had its EPROMs soldered in. I started building up a program that would dump the cartridge as binary data over the audio output of the Famicom (a well-established way of dumping on low-spec systems). In the end, I made my program a pretty automated process. But before that, just to get it working, I had it dump 16K at a time. I'd dump the same 16K a few times, make sure it worked OK, then move on to the next bank of the cartridge and repeat. Of course this meant 20 minutes of waiting while the screeching audio dumping did its thing, pressing one button, and then waiting another 20 minutes...

Not acceptable. I was a busy guy and had to assemble a couple of bookshelves in my game room (separated from my computer, TV, and Famicom by a kitchen and hallway) so to make the dumping process easier, I got out an old infrared (wireless) Famicom controller that I bought as junk at Hard-Off, cleaned the battery compartments of rust and dirt, and got it working with the IR detector across the room. Then I connected another (wired) Famicom controller into that controller (the wireless one has a 15-pin Famicom joystick port on it. Handy!) and led the wired controller around the corner and into my game room. When I heard the audio stop, I could just reach out and push a button to continue the dumping process happening 25 feet away in the other room. Handy indeed!

So, here's a picture of this Rube-Goldberg setup.

Well, I'd been playing around with 3-D stuff for a long time now, even taking 2 pictures side-by-side manually with my regular digital camera. The results I produced looked pretty good -- I thought -- but as soon as I showed a couple to a camera nerd friend (Hi, Lawrence!) he picked them apart and said they were hard to read as 3-D pictures. Bah. The moral of the story is, naturally: If you want to take satisfying, high quality 3-D pictures, simply never show your usual ones to camera nerds.

Check out more pictures on a new page here.

I also got a Nintendo 3DS at the same time, which is pretty awesome to play around with and has surprising 3-D depth considering you don't have to wear glasses. I sat around all summer vacation flying around with Pilotwings 3DS and racing with Ridge Racer 3D -- the only 3DS games I've bought so far. Um... Well, anyway, the 3-D camera built in is of really low quality, so I guess it's back to the normal camera for 3-D pictures, anaglyph glasses, picture processing, and all that hassle. Blah. This was last summer, remember, which is why it's in a diary and not on a constantly-updated page of its own... Then I got a Dingoo A-320 and all my game-playing, music-listening, emulating time moved over to that great little unit. I haven't played a single DS game since then... :-/ I've played 3DS a few times, of course, but since getting the Dingoo my train-riding time (1 hour 20 mins...) each day has become either Dingoo Dingoo Dingoo or Computer Computer Computer. (What has happened to my Japanese studies...?)

Dingoo, the emulation machine.