A Game Dad is a frankly awesome idea! It’s any portable, pocket-sized game-playing device that has a focus on emulation. I myself would say it needs physical controls, not a touchscreen, to control well, but that’s not part of the “official” spec given by Dan over at gamedad.club. It looks like site owner Dan agrees with me to an extent.
Game Dad is not a brand name. No company yet calls their device a Game Dad, it’s more an adjective that you can apply to things. Two special cases: A Steam Deck is not a Game Dad because it’s not pocket-sized. A smartphone is not a Game Dad because it’s not dedicated to playing games. Game Dads shouldn’t be something you do work on, or will pester you while you play. Game Dads don’t host apps. Game Dads don’t try to feel you algorithmic bullshit. Most Game Dads, when you turn them off, they don’t go to sleep. They turn off.
The picture here, from the site’s header, might help to fix the idea in your head. Notice that unlike a Gameboy it has four buttons and dual analog sticks, but it otherwise looks a lot like a Gameboy.
Lots of companies make Game Dads, or Game Dad-adjacent devices, and you should be able to get a pretty good one for around $70. That will typically get you something capable of playing up to PS1-era games. N64 games are a little more challenging since its processor was weirder. But as the site says, the best Game Dad is the one that plays the games you want to play. Dan’s site is full of advice and opinions, and all of them are good. The one he has personally is an Anbernic RG353V/RG353VS. Both run Linux, but the V version also has an Android partition and a touchscreen, two features that Dan considers inessential to Gamular Dadiness, and lowers the price by $20 to about $78, but the more expensive one also has more RAM and built-in storage, if those things matter.
At this moment a lot of the interest in retro gaming circles is in FPGA devices like the Analogue Pocket, which will be more expensive than this. This isn’t a device for complete cycle-accurate recreations, it’s for inexpensive, pretty-nice emulation for good-enough gaming fun.
The Colecovision version of Tarzan was a late release, and had unusually good animation for its time, and repetitive, yet atmospheric, music. Here’s a Youtube link of the first loop of that version of the game (5 1/2 minutes):
I tried a little of the 2600 version, and I couldn’t make out how to get further than a few screens in. That single button control scheme is a real hassle! Here that is (four minutes 1/2). Dig that opening theme song! Don’t dig that gameplay music, though. It didn’t sound as bad when I played it, I think it was an issue with the recording.
The article has a run that gets further into it (7 minutes):
Our friend Robin at 8-Bit Show And Tell lets us know of this cool and free Commodore 64 BASIC 2.0 extension, of a sort, called Hare Basic. It’s a successor to an earlier version called Bunny Basic. Here’s the video, 48 minutes long. My comments on it follow below, which you can read either after having watched the video, or before, depending on of you have most of an hour to spare right now.
Here are the downloads, which are hosted on the creator’s Dropbox, so availability may fluctuate.
Commodore BASIC is, in many ways, the worst of all worlds. It’s a slow interpreted language, a variant of infamous Microsoft BASIC, and it has almost no machine-specific features, but it comes with the machine, and it’s burned into ROM. You can swap it out for extra RAM if you have a replacement OS or are running something in pure machine code.
I could go on for a long time about the problems with Commodore BASIC 2.0, a language I’m quite familiar with having spent much of my teens programming in it. Sometimes it feels like it was designed especially to run slowly. One example: it supports floating point math, which ordinarily would be a good thing, right? Use integer math for performance, and just use floats when you need decimals, right? But no: internally, Commodore BASIC converts integer variables into floats when doing any math with them, and converts them back to store as integers when it’s done. Wilberforce Trafalgar Franklin?! Why?! It does these unnecessary extra steps to do all arithmetic as floating point even when it doesn’t need do, and doesn’t offer a way to do performant integer math at all! Need I remind you that Microsoft BASIC is based upon software written by Bill Gates himself? I suspect that I don’t!
Hare Basic is a highly optimized subset of Commodore BASIC that can be switched on and off as needed. It has to be coded in a special way which might throw beginners for a loop: Hare Basic can’t abide whitespace, for example, only allows for variables of one letter in length, has no support for modifying strings, and contrary to Commodore BASIC can only do integer math. There’s lots of other differences too, and if you want to play around with it it’s essential that you study the manual.
But once you get used to it, it runs blazingly fast, sometimes as much as 10 times faster! And the best part is you don’t have to use it for everything. You can start out with a standard Commodore BASIC program, then enter into Hare Basic mode with a USR function call. You could write your whole program in Hare if you’re up for it, or just loops, or other places where performance is necessary.
Of course, this is ultimately an enhancement for a programming language that runs on a home computer made in 1984. It’s not what one might consider of universal interest. But it might be of interest to the kinds of people who read this site. It’s interesting to me, at least. Maybe I should dust off VICE and see what I can do with it? I haven’t coded on a ’64 in nearly three decades, maybe I should get back into that….
I did a search of the blog to make sure I haven’t posted this before. I’m really an obsessive tagger, and it didn’t show up under the tag pacman, so I think it hasn’t been seen here before. Let’s fix that now!
It’s a video from Retro Game Mechanics Explained from six years ago, and it’s 11 1/2 minutes:
Here’s a terse summary of the explanation, that leaves out a lot. Like a lot of 8-bit games (the arcade version uses a Z80 processor), Pac-Man stores the score in one byte, making the maximum it can count to 255. Since it doesn’t use signed arithmetic, it doesn’t use the high bit to signify a minus sign and so flip to negative at 128.
As an optimization, Pac-Man’s code uses the depiction of the maze in the video memory, itself, in the movement of both Pac-Man and the ghosts. If a spot has a maze wall tile, then Pac-Man can’t go there, and the ghosts won’t consider that direction when moving.
At the start of every level, the game performs some setup tasks. It draws the maze anew, including dots, Energizers and walls. One of these tasks is to update the fruit display in the bottom-right corner. It was a common design idiom at some arcade manufacturers, especially at Namco, at the time to depict the level number with icons in some way. Galaga shows rank insignia in the corner; Mappy has small and large balloons and mansions.
Pac-Man’s code shows the bonus fruit for each level, up to seven of them. If you finish more than seven levels, only the most recent seven are shown. If you get far enough eventually this will be just a line of Keys, the final “fruit.”
The code draws them from right to left. There’s three cases (the video goes into much more detail), but generally it starts from the fruit of six minus the current round number, draws it, counts up once and moves left two tiles, draws that one, and so on.
An interesting fact about Pac-Man’s graphics hardware is that the screen doesn’t map as you might expect to the screen! A lot of arcade games have weird screen mappings. Most consumer programmable hardware will map characters horizontally first vertically second, like a typewriter*.
In Pac-Man, the bottom area of the screen comes first in memory, starting at memory location hex $4000 (16384 decimal), and it doesn’t go forward like an English typewriter, but is mapped right to left. The first row of 32 tiles comes at $4000, and the second row is $4020. Then the playfield area is mapped completely differently, in vertical rows going down starting from the top-right of its region, then the next vertical row is the one to the left of that, and so forth to the left edge of the playfield. Then comes the score area at the top of the screen, which are two final rows mapped the same way as the bottom area, right to left.
When Pac-Man’s score counter overflows, it breaks the check for the limit for only drawing seven fruit, and causes it to draw 256 fruit. This is why the tops of keys are drawn beneath the upper-halves of the fruit at the bottom of the split screen. It also breaks the tile lookup for the fruit.
As it continues writing its missourced fruit tiles in memory, it goes back in memory each time to draw the next fruit, and after the fruit section of the display it keeps going to the left, into the area where Pac-Man’s lives are displayed, then it keeps going and overwrites half of the maze tiles. Then Pac-Man’s lives (and any empty spaces that indicate the lack of lives) are plotted, overwriting fruit after the first ones drawn and obscuring some of the memory corruption.
Since the game’s actors use that data to decide where to move, and where dots and Energizers are placed, it means they can move outside the bounds of the maze, and that there won’t be enough dots for Pac-Man to eat to complete the level. That’s what makes it a kill screen: if Pac-Man loses a life, a few dots will get placed in the maze as the fruit are redrawn, but it’s not enough to bring the dot-eaten count to 244, which triggers the level clear function.
If the fruit-drawing loop didn’t stop at 256 (another artifact of using 8-bit math for the loop), it’d go on to clobber the rest of the maze, the score area at the top of the screen, then color memory (which has already been clobbered by the palette-drawing portion of the loop). Then, going by a memory map of the arcade hardware, it’d hit the game logic RAM storage, which would probably crash the game, triggering the watchdog and resetting the machine.
The visual effect of the split screen is certainly distinctive, enough that since Bandai-Namco has capitalized on its appearance at least once, in the mobile (and Steam and consoles) game Pac-Man 256. I’ve played Pac-Man 256: it’s okay, but, eh. It’s really too F2P unlocky.
* Yes, I just used a typewriter’s operation as a metaphor for something a computer does. It didn’t feel acceptable to use another computer thing as the comparison, since ultimately the reason they do it that way is because typewriters did it that way too. I guess the fact that it’s English reading order would be better to use, but I’m really overthinking it at this point.
The Youtuber: MattKC Bytes What he did: Unexpected things to Sega’s aborted Genesis/Mega Drive add-on. The address: here. The length: about seven minutes.
The explanation: Did you ever play around with a 32X? Evidently not a lot of people did. It was straaaange. Unexpectedly powerful! A bit misjudged! Hosted a port of DOOM! Had a port of Virtua Racing that compares favorably with the Saturn version! Had that crazy hard-to-play Knuckles game that gave us Vector the Crocodile!
Have you ever hooked one up though? Its hardware is odd. It’s like a completely separate console to itself. The Mega Drive wasn’t made to support add-on processors and chips like that, so Sega used a clever solution: the 32X has its own video output, and also a video input. You plug the Genesis’ output into the 32X, and then the 32X into your TV. The 32X mixes the Genesis’ signal into its own, as if it were chromakeyed. Since the 32X cartridge supplies the program running on the Genesis as well as itself and they can talk to each other, the two processors and graphics chips should be able to sync perfectly, if awkwardly.
But: because the Genesis’ video signal emerges from that console through this external wire before reentering the 32X, it’s possible to do things to it while in transit. The Genesis supplies video timing information that the 32X relies on, so you can’t get a signal from the add-on without the Genesis’ AV plugged into it, but the Genesis does produce a viewable video signal that you can see on its own.
All the details are in the video, which has been embedded below for your convenience and amusement.
On Romhack Thursdays, we bring you interesting finds from the world of game modifications.
We’ve not done Romhack Thursday for a while. As the winds of the ‘net, and my attention, blow around randomly, sometimes there’s more things that seem worthy of posting than others. This one definitely fits the bill though.
We’ve posted about 10yard’s intriguing Donkey Kong hacks Galakong and Vector Kong before. I don’t think they’re actually hacks in the classic sense of the term, modifications of a game’s software intended to run on its original hardware, or at least an emulation or simulation of it. Galakong might, and Vector Kong definitely does, rely on Lua support in MAME to produce, respectively, a version of Donkey Kong where Mario teams up with the ship from Galaga, and another version of Donkey Kong limited to the Girders stage, a.k.a. Ramps, but with sharp colorful line-drawn artwork akin to that produced by Atari’s later Vectorscan monitors.
10yard let us know that they have produced a front-end to a variety of Donkey Kong romhacks, 90 in total. It runs on Windows an Raspberry Pi, although if it runs on the latter I suppose it must also be possible to get it to work on Linux? Maybe?
It’s not just a front end though. It presents all of its mods through an interface that itself plays like Donkey Kong! You move Mario around the levels of the classic arcade game (they’re connected vertically), and each is littered with arcade machines. You can play them with coins collected them as DK rolls them through the boards, and also earned by getting good scores in each game. Collecting more coins not only gives you more chances to play, but it unlocks further games in the collection.
You download the package from the Github page linked above. You must also provide the MAME-compatible romsets for Donkey Kong, Donkey Kong Jr. and Donkey Kong 3. (It might work without without all of them, but fewer games will be available.) Of course, it’s up to you to rip, or otherwise provide, those files. If you provide them, it’ll handle all the patching for you automatically. It even includes its own custom version of MAME to play them.
Both Galakong and Vector Kong are among the hacks provided, but there’s so much more to see and play besides those, including Halloween, Christmas and Doctor Who themes hacks. There’s really too many to mention here, and I’ve only started unlocking games myself. I’ll leave you with the closing link, and some screenshots of the hacks included that I’ve managed to unlock so far.
DKAFE (by 10yard, for Windows and Raspberry Pi, on Github)
It’s only two episodes in, but this series from the Youtube channel What’s Ken Making is already really interesting, with episodes averaging at around 16 minutes each. The first part is titled “The Design of a Legend,” which doesn’t really grab me much, but the second is about the main processor, “The 6502 CPU,” which Ken admits near the start isn’t exactly accurate. The Famicom/NES’s processor isn’t precisely a MOS 6502; it’s a Ricoh 2A03 in NTSC territories, and a 2A07 in others. The 2A03 is licensed from MOS, but lacks the original’s Binary-Coded Decimal mode, and includes the Famicom/NES’s sound hardware on-die.
Episode 1 (15 minutes):
Episode 2 (17 minutes):
That removed BCD feature. Why? The video notes that the circuits are right there within the chip, but have been disabled by having five necessary traces severed. The video notes that the 6502’s BCD functionality was actually patented by MOS, and asks, was the feature disabled because of patent issues? Was Ricoh trying to avoid paying royalties?
The news comes to us by way of Apple cracker 4am’s Mastodon account. Wheeler Dealers was a cassette release, a format not as well understood as the Apple II floppy disk formats, but it’s playable on its Internet Archive page.
Its title screen gives it a copyright date of 1978, making it only slightly younger than the Atari VCS/2600. Wheeler Dealers was the first published game by M.U.L.E. creator Dani Bunten. Designed for four players, it came with a special controller to allow four players to participate in auctions on an equal footing. If played in an emulator, they often have settings to allow the buttons to be remapped to joystick directions, and from there to specific keyboard buttons.
It’s a stock trading game, written in BASIC, and much less polished than M.U.L.E. would be. It barely has graphics and has no single-player mode. I find it hard to control in the IA’s web-based Apple emulator. Basic stock trading games seem really simple these days. I think Wheeler Dealers (or “Wheeler Dealer$,” according to the title screen) is mostly interesting these days has a herald for M.U.L.E., which I find holds up really well to current-day tastes. Dani’s real-time auction mechanism would be honed to a fine edge in M.U.L.E., which to this day is probably still the best multiplayer auction mechanism in any game.
Dani Bunten left us long ago now, back in 1998, but her absence is still keenly felt. One of her last projects was a Sega Genesis/Mega Drive port update of M.U.L.E., which was infamously scuttled when publisher Electronic Arts insisted, as a condition of publishing, a mechanism by which players could directly attack other players with weapons. It is far from the only terrible action that EA would be responsible for, but it’s certainly one of the worst.
Clivefrog77 makes these nice gaming dioramas, often based on European Commodore 64 games, and sells them on eBay. He has a page on Google Photos. I’m not sure if all of those are his, but a lot seem to be.
EDIT: I got the name of the chip wrong, as xot pointed out in a comment. I knew the right now but I always get it mixed up. Corrections have been made, here is xot’s comment:
“The 65C02 is a low-power CMOS variant of the venerable 8-bit 6502 with minimal extra abilities. The 6502 successor used in the Apple IIGS is the 16-bit 65C816. It was designed by Western Design Center in collaboration with Apple, Inc. The story that Steve Jobs held back the IIGS in favor of the Mac is popular because it perpetuates Jobs’ mythic status of being a petty, conniving villain … but it isn’t true. The Apple IIGS was created atop a heap of questionable design decisions. No one decision doomed it but its CPU absolutely held it back. The very boring truth is that WDC could not reliably supply ‘816 processors at the speeds they promised (up to 14 MHz). The IIGS is limited to 2.8 MHz because Apple needed a stable product, which unfortunately was way slower than it should have been.”
Some of this slightly contradicts what was said in the video, but not that far. Whether Steve Jobs was petty and conniving or not I will leave to the ages, at least for now.
It had Apple’s first color point-and-click interface, and it ran on a 65C816.
It was the Apple IIGS. It was released two years after the original Macintosh, three after the Lisa, and it worked surprisingly well. It came with 256KB of memory stock but could be gotten with a whole megabyte, and could be expanded to up with 8 MB–in 1986! It supported hard drives and devices could be attached to it via the Apple Desktop Bus. It ran at less than 3MhZ, but its processor was capable of going much faster, with the rumor being that it was a decision of Steve Jobs to limit its processor so it wouldn’t steal the Macintosh’s thunder. (Jobs had been forced out of the company by the time the GS was released, but these decisions are not so easily reversed?)
What’s more the Apple IIGS was made to compete with the Amiga, and so it had considerable audio-visual advantages over the black-and-white Macintosh. 4096 colors and a sound chip designed by the people who had created the SID. And while it had a mode that made it compatible with Apple II software, it used an OS that looked and worked a whole lot like a Macintosh. It was surprisingly capable as a gaming machine; it took a long time, but in 1997 an Apple IIGS version of Wolfenstein 3D was made, although running at a pretty low frame rate:
The 65C816, a 16-bit version of the classic 6502, was used in a number of platforms but ultimately didn’t have the reach of its predecessor. But if Apple had thrown more weight behind the GS, we could well be living in a world where 6502 variants still saw use outside of embedded and hobbyist systems, instead of the Intel and ARM chips that dominate the market today.
I’m thinking along these lines because Vintage Geek made a video about the GS’s virtues, and it’s interesting to speculate about. It really was a kind of wonder machine, and the last gasp of the Apple II line. Here it is (15 minutes):
We’ve linked the Youtube channel of U Can Beat Video Games repeatedly in the past, most recently for their sprawling guide to Final Fantasy II(IV). Yet they keep making new videos. Just a few days ago they did a video on all of of Book I of Ys for the TurboGrafx 16/PC Engine, with one on Book II promised soon. And since they post (usually) weekly, if I did a post here every time they released a video, it’d become one-seventh of our posts!
Here is the video on Ys Book I, it’s 2 hours and 2 minutes:
And here is a directory of every game video U Can Beat Video Games has put up to date. I haven’t inlined the videos because there’s over a hundred!