Rants from Vas

Way back in the 1980s, the days of the exciting home computer and game console boom, Micom Soft introduced their XE‑1 line of game controller peripherals. From the humble XE‑1B two-button joystick for Japanese home computers, to the XE‑1ST2 switchable 4-way/8-way joystick with support for FM Towns and Sega consoles, to the fully programmable XE‑1SFC Super Famicom stick (with an LCD screen), there was something for everyone. They were known for their excellent build quality, unconventional features, and of course their rotating button clusters.

The XE‑1AJ Intelligent Controller is possible the most impressive, and definitely the most imposing, member of the product line. Also sold as the Sharp CZ-8NJ2 Cyber Stick, it is a large HOTAS flight controller for desktop use. Just the size and weight are impressive: it takes up a lot of space on your desk, the stick and throttle shafts are metal, it’s clearly built to last. It features an analog stick and throttle, a thumb button and trigger on the stick, a thumb button and two-way rocker switch on the throttle, and five panel buttons. The stick button and trigger functions can be exchanged, auto-fire is supported for the stick button and trigger, and a variety of special modes can be enabled by holding panel buttons while pressing the reset button. If that isn’t enough, the stick and throttle positions can be reversed for left-handed use. It can even be switched to digital mode for games that don’t support analog controls.

With the launch of the Sega Mega Drive in 1988, someone at Micom Soft must have started wondering, “How can we bring all the fun of the XE‑1AJ to couch gaming?” The result was the XE‑1AP joypad. Brought to market in 1989, the XE‑1AP was the first control pad to feature analog controls. It was nicknamed the horseshoe crab (kabutogani in Japanese) due to its shape. It actually succeeded in packing all the key functionality of the XE‑1AJ into a hand-held controller, and even added a few features. In many ways, it is the ancestor of modern game controllers, pioneering many features that were only popularised years later. Its features included:

• Ergonomic shape with grip handles.
• Analog stick controlled with left thumb.
• Analog throttle controlled with right thumb; could be rotated through 270° for horizontal or vertical movement in either direction.
• Two shoulder buttons on each side.
• Two face buttons on each side, plus Start and Select buttons.
• Auto-fire support for the right shoulder buttons.
• Modes to support Japanese home computers and Sega consoles.

The design of the Sega Saturn 3D Controller was directly influenced by the XE‑1AP – the similarity is quite striking. The Saturn 3D Controller was further developed into the Dreamcast controller, which in turn served as the inspiration for the Xbox controller. The Xbox controller was ridiculed for being excessively large, but the XE‑1AP is actually bigger. This is at least partly for practical reasons: it needs space for its 42-pin plastic DIP Fujitsu MB88513 microcontroller and the rest of the components that make it work. Electronics used to be a lot bigger.

It’s interesting how obscure the XE‑1AP has become. Perhaps poor marketing is partly responsible. It was supported by several Mega Drive, Mega‑CD and 32X games, but only mentioned in the Japanese versions of the manuals. The export versions of the manuals never mentioned the XE‑1AP, despite the export versions of the games supporting it in most cases. Micom Soft sold an adapter that allowed the XE‑1AJ or XE‑1AP to be used with the NEC PC Engine. Although five PC Engine games supported analog controls, this was never heavily promoted. Three of them don’t even give any indication when a supported analog controller is detected. The high price probably didn’t help either, but I can’t help wondering what could have happened if the XE‑1AP was promoted more heavily, leading to more adoption, and hence more games developed with support for it.

I recently added support for the XE‑1AP to MAME. In typical MAME fashion, the emulated XE‑1AP can be used with compatible games on several systems, including the Sega Mega Drive, NEC PC Engine, Sharp X68000 and FM Towns families. I’ve also written some basic instructions for using the controller with some of the games I tested.

Read the rest of this entry »

There are two Việt words for crabs that you might hear frequently, cua and ghẹ, but there seems to be some confusion over the difference. Google Translate unhelpfully renders both of them as “crab” when translating to English. Well, cua refers to crabs in general, and not just true crabs (brachyura), but also the other crab-like crustaceans like hermit crabs (anomura) – if it’s a crab, it’s con cua.

Ghẹ refers to swimming crabs (portunidae) – crabs that have hind legs that are flattened to form swimming paddles. Well-known ghẹ include the ghẹ xanh (portunus pelagicus, the blue swimmer), the ghẹ dĩa or ghẹ đỏ (portunus haanii, the red warty swimming crab), and the ghẹ chấm (portunus trituberculatus). Note that not all crabs with swimming paddles are called ghẹ – a crab must live in the ocean or estuaries and have the characteristic angular carapace and long, narrow claws (chelae) to be called con ghẹ. The mud crabs scylla serrata (cua bùn) and scylla paramamosain (cua xanh) are called cua because they live in fresh water, their claws are large, and their carapaces are rounder.

There are other Việt words for specific kinds of crabs, including rạm or đam (varunidae), dã tràng (sand bubbler crabs), cáy (ocypodidae), cà ra (Chinese mitten crabs), and cúm núm (calappidae, from cua khúm núm, due to the way they appear to hide their faces – Google Translate amusingly renders “cúm núm” as “nipple flu” in English). Like ghẹ, these aren’t strict taxonomic or phylogenetic classifications – they’re common names based on appearance (morphology) and habitat.

Ghệ or ghẹ can also be used informally to refer to women, as in “ghẹ mới của tao” (my new girlfriend), but this is a little vulgar and should be avoided in polite company.

This is a detailed discussion of MSVC C++ ABI pointers to member functions, including some of the trade-offs they make. The format of pointers to member functions in C++ is implementation-defined, and a lot of incomplete and misleading information about this topic can be found around the web. There’s a popular article at Code Project that provides a reasonable overview of a several implementations of pointers to member functions, but not all the details are accurate. Raymond Chen has a very incomplete and somewhat misleading blog post. As far as I know, there is no publicly available formal specification for the MSVC C++ ABI.

In this article, MSVC C++ ABI with default options is assumed unless stated otherwise. Some of the values assumed to be int may actually be long int or int32_t, but without access to an LP32 or LP64 target using the MSVC C++ ABI it’s impossible to confirm one way or the other. This description is mainly based on the behaviour of MSVC 19.29 for x86-64 and AArch64. The usual disclaimers about implementation-defined behaviour apply: depending on this behaviour produces code that is not portable, details may change at any time, and the accuracy is limited by my understanding.

Read the rest of this entry »

The past decade has seen a substantial increase in rail freight in Australia. Capital investment like the Southern Sydney Freight Line and conversion of the Victorian North East line to 1435 mm standard gauge is paying off. Allied Pinnacle has a siding just south of Kensington station, and Southern Shorthaul Railroad (SSR) currently has the contract to deliver their wheat. SSR uses a pair of S class “bulldog nose” locomotives from the 1950s coupled back-to-back to operate this service. Right now they’re using S302 and S317, but they were using S312 earlier in the year.

S302 is named after the pioneer Edward Henty. Here it is at Kensington, in orange and grey livery:

S317 was the last S class locomotive to be delivered, and was named after Sir John Monash. S317 has been involved in two major accidents: it was rebuilt after a head-on collision with X33 in 1967, and collided with the read of the Spirit of Progress at Barnawartha in 1982 killing the crew. Here it is at Kensington:

Wait! What’s that below the cab window? It doesn’t have the old Sir John Monash nameplate any more. It seems to be named Jenny Molloy now! Who’s Jenny Molloy? Whoever she is, she definitely isn’t as well-known as Sir John Monash. She does have the same initials, though. Here’s a view of the nose:

Interesting paintwork inside the horns, too. If anyone knows more about the renaming of S317 or who Jenny Molloy is, I’d love to hear about it. Did the old name have too many bad connotations? Was the new name intentionally selected to have the same initials? Does the new name lift a jinx?

If you spent much time in video game arcades ’90s, you’re sure to have seen the QSound logo proudly displayed during the attract loop of games running on Capcom’s CPS-2 and ZN-1/ZN-1 hardware platforms, and heard the distinctive jingle. But What exactly is QSound? What does it actually do? Capcom was definitely keen to promote its inclusion, but did it really give an edge in any area besides marketing? Was it worth the licensing fees they undoubtedly paid, and the precious attract loop time they spent announcing it?

As implemented in Capcom’s arcade systems, QSound technology is provided by a digital signal processor (DSP) running an internal program that implements a sixteen-channel sample player/mixer. It produces 16-bit stereo output at just over 24 kHz. It supports 16-bit samples, but Capcom only ever used it with 8-bit sample ROMs. In addition to playing and mixing the channels, it applies “spatialisation” effects, intended to give the impression of a more expansive virtual sound stage. I know what you’re thinking: everything I’ve said so far sounds like marketing material, but what do the effects actually do, and does it actually work?

Read the rest of this entry »

In case anyone else wants to configure third-party equipment for a TPG fibre-to-the-building service, here are the details. Below the fold are screenshots of the settings entered in the web-based configuration UI of an AVM FRITZ!Box. Note that the SIP password is not the same as your account password, and you’ll need to obtain this somehow. TPG doesn’t make this easy, but it is possible.

Internet connection

Phone service connection

SIP connection settings

Read the rest of this entry »

Due to persistent issues with line quality, I switched an Internet connection from Internode ADSL2+ to TPG fibre to the building (FTTB). Although the connection quality is better, just about everything else about TPG is worse. I strongly recommend avoiding TPG. Problems include:

• Error-prone signup process
• Supplied modem/router is heavily compromised
• Phone service is tied to compromised modem/router
• No IPv6 support
• Support staff very inconsistent
• Good support staff hobbled by policy

My Internode connection had become very slow and unstable in hot, dry weather. Strangely it was fine in the rain, and even during flooding. It almost seemed like something needed to be damp to maintain an electrical connection. There’s no way to actually get these kinds of issues resolved, as the ISP and last mile provider will blame each other and the in-building wiring, and charge extortionate rates for technicians to be called out without actually solving the issues. The only other option I have for last mile is TPG. I’d been switching to Telstra LTE on bad days, and to be fair it’s actually not too bad at the moment. It seems to be pretty fast and stable, but I imagine that will get worse as more people start to use the network. But using LTE comes with a number of imitations, and it’s supposed to be my backup, not my day-to-day Internet connection.

Sadly, it seems that Internode may be going downhill since being acquired by TPG. After iiNet acquired Internode, they were allowed to operate independently for the most part. The call centre in Adelaide remained open, Internode continued to offer the same kinds of perks as before, including Usenet servers, Steam content mirrors, native IPv6 connectivity, and more. However, TPG has consolidated iiNet and Internode support and seems to be phasing out Internode perks. They’ve even started selling TPG nbn™ HFC (DOCSIS cable) under the Internode brand name, providing the same IPv4-only connection and obfuscated SIP phone service.

With the consolidation in the Australian ISP sector, there’s a big reduction in competition. TPG has merged with or acquired Soul, AAPT, Chariot, iiNet, Internode, TransACT, WestNet, PIPE, Westnet, and more. There doesn’t seem to be a good alternative at the moment. There may be an opportunity for an upstart ISP that understands what made “premium” ISPs like Internode successful in the first place.

Read the rest of this entry »

For lulz, I decided to rewrite MAME’s Intel 4004 CPU core and add support for most 4040 features. The new CPU core operates at the bus cycle level, and exposes most useful signals. It also uses lots of address spaces for all the different kinds of memory and I/O it supports (thanks OG). Some CPU core bugs were fixed along the way – notably intra-page jumps on page boundaries were broken.

One nice benefit we get from this is being able to hook up the I/O for the Bally/Nutting solid-state Flicker pinball prototype (supposedly the first microprocessor-controlled pinball machine) how the hardware actually worked. I also hooked up the playfield lamp matrix as outputs and the operator adjustments as machine configuration while I was at it. We need a proper thermal model of a lamp with PWM dimming support before that part can be declared perfect. (It previously used a hack, pulling the low bits of RC out of the CPU using the state interface. This worked due to a quirk of the game program, and there was no way to implement it properly without the 4004 CM-RAM signals being exposed.)

Possibly more interestingly, we can now emulate the Intel INTELLEC® 4/MOD 40 development system. There seem to be very few surviving examples of this system, but fortunately we’ve got monitor PROM dumps, and there’s some information floating around the web. It has interesting debugging features on the front panel. There’s a scanned manual, but the schematics are very poor quality. However, with some idea of how it works, it’s possible to work out what all the chips are supposed to be. That’s the fun part. Turning it into MAME code isn’t as much fun, but it’s doable.

The front panel looks like this:

That requires clickable artwork for the switches and outputs for the LEDs to get a usable experience (writing the MAME XML layout really isn’t fun). There’s a simple monitor in PROM, designed to be used with an ASCII teleprinter with paper tape reader and punch (e.g. a Teletype Model 33 ASR). MAME’s RS-232 video terminal will have to do as a substitute for that.

If you get bleeding edge MAME (i.e. built from source no more than a day or so old), you can try it out in emulation. Did you ever wonder how developers may have debugged 4004 code in the mid to late ’70s? Well even if you didn’t, now you can find out.

The front panel looks like this in emulation (without the explanatory labels), and by default MAME shows the video terminal below this:

All those LEDs are functional, and all those switches are clickable and visually reflect their current state.

So how would you actually use it in practice? That’s where this brief instruction manual on the MAMEdev wiki comes in. It’s complete with examples of how some of the monitor commands and front panel debugging features can be used. It’s marked NOT_WORKING in MAME for now because you need to manually set up the terminal the first time you use it, and I haven’t finished implementing the universal slots and storage cards. But you can do all the things described on that page.

Does anyone care? Probably not. Will anyone actually even try this system out in MAME? Probably not (apart from Robbbbbbbert). But this is another example of something that you can only do in MAME, and how completely unrelated systems can both benefit from emulating the same chip properly. It also gets rid of one previously unavoidable hack, and gets us one step closer to feature parity with EmuAllSystems.

ShouTime dumped the incredibly rare game Omega (Nihon System). It’s a ball-and-paddle game running on similar hardware to Sega’s Gigas. These games use an NEC MC-8123 CPU module containing a Z80 core, decryption circuitry, and an 8 KiB encryption key in battery-backed RAM. When fetching a byte from ROM or RAM, the CPU chooses a byte from the encryption key based on twelve of the address bits and whether it’s an M1 (opcode fetch) cycle or not. This byte from the encryption key controls what permutation (if any) is applied to the byte the CPU fetches. This encryption scheme could have been brutal, requiring extensive analysis of a working CPU module to crack, if it weren’t for a fatal flaw: Sega used a simple linear congruential generator algorithm to create 8 KiB keys from 24-bit seeds. That means there are less than seventeen million encryption keys to test. Seventeen million might sound like a lot, but it’s far less than the total possible number of keys, and definitely small enough to apply a known plaintext attack in a reasonable amount of time.

So how do we go about attacking it? First we have to make an assumption about what the game program is going to be doing. Given that the hardware looks pretty similar to Gigas and Free Kick, I guessed that one of the first things the program would do is write a zero somewhere to disable the non-maskable interrupt generator disable maskable interrupts. So I wrote a program to find candidate seeds (no, I won’t show you the source code for this program – it’s embarrassingly ugly and hacky, not something I could ever be proud of):

• Start with first possible 24-bit seed value
• Generate 8 KiB key using algorithm known to be used by Sega
• Decrypt first few bytes of program ROM using this key
• If it looks like Z80 code to store zero somewhere and disable interrupts, log the seed
• Repeat for next possible seed value until we run out of values to try

This ran in just a few minutes on an i7 notebook, and narrowed down the millions of possible seed values to just five candidates: 36DF3D, 6F45E0, 7909D0, 861226, and BE78C9 (in hexadecimal notation). Now I could have tried these in order, but it looked like Sega had made another misstep: besides using a predictable algorithm to generate the key, they also used a predictable seed value to feed this algorithm. The candidate seeds value 861226 looks like a date in year-month-day format. It turns out this seed generates the correct key to decrypt the game program, so I guess we know what someone at Sega was doing the day after Christmas in 1986.

Brian Troha hooked up the peripheral emulation, and the game will be playable in MAME 0.183 (due for release on 22 February). Colours aren’t quite right as we don’t have dumps of the palette PROMs yet, but we expect to resolve this in a future release. Thanks to ShouTime and everyone else involved in preserving this very rare piece of arcade history.

Back in the distant past, MAME started cataloguing programmable logic devices (PLDs) in addition to ROMs. This was met with considerable hostility from certain segments of the community, as it was seen as forcing them to obtain files they saw as unnecessary for emulation in order to run their precious games. However PLDs are programmable devices, and it’s important to preserve them. So far though, the PLD dumps have mainly been used by PCB owners looking to repair their games. The haven’t been used by MAME for emulation. However, PLDs are key to the operation of many arcade games, performing functions like address decoding and video mixing.

One such arcade board is Zaccaria’s Laser Battle, also released under license by Midway as Lazarian. This board uses complex video circuitry that was poorly understood. It includes:

• TTL logic for generating two symmetrical area effects, or one area effect and one point effect
• TTL logic for for generating an 8-colour background tilemap
• Three Signetics S2636 Programmable Video Interfaces (PVIs), drawing four 4×4 monochrome sprites each
• TTL logic for generating a single 32×32 4-colour sprite
• A Signetics 82S101 16×48×8 Programmable Logic Array (PLA) for mixing the video layers and mapping colours

On top of this, they decided it was a good idea to use some clever logic to divide the master clock by four when feeding the Signetics S2621 Universal Sync Generator (USG) that generates video timings, but to divide it by three to generate the pixel clock feeding the rest of the video hardware. This lets them get one third more horizontal resolution than the Signetics chips are designed to work with. They need additional logic to line up the pixel clock with the end of horizontal blanking, because the number of pixels in a line isn’t divisible by three, and some more logic for delaying the start of the visible portion of each frame and cutting it off early because they wanted less vertical resolution than the Signetics chips are designed for. It uses an GRBGRBGR colour scheme where the most significant bits are are in the middle of the byte and the missing least significant blue bit effectively always, so it can’t produce black, only a dark blue Was this design effort worth it? I guess they must’ve made some money off the Midway license at least.

Anyway, this game has never worked properly in MAME. It’s always been missing the area and point effects, the colours have always been completely wrong, and the mixing between layers hasn’t properly either. And that’s done inside the PLA. The PLA has 48 internal logic variables, each of which can be programmed to recognise an arbitrary combination of levels on the 16 input line. Each of the internal variables can drive any combination of the eight output lines. The outputs can be configured to be inverting or non-inverting.

In theory this sounds like a job for a ROM, so why use a PLA instead? Well a ROM with 16 input bits and eight output bits would need 64kB of space. Such a ROM would likely have been prohibitively expensive when this game was produced. I mean, its program ROMs are only 2kB each, so there’s no way they’d be sourcing a ROM 32 times that size just for video mixing. The PLA maps the same number of inputs to the same number of outputs with just 1,928 bit of storage, or a little less than one of the program ROMs. It can’t produce absolutely any arbitrary input to output mapping, but it’s more than enough for this application. In fact, it turns out they didn’t even need to use all the space in the PLA.

Read the rest of the post if you want to know more about the process of decoding the PLA bitstream and examining its contents.

Read the rest of this entry »