This is the PCB of a NES joypad. PCB traces were hand-drawn back in the day so it's rather curvy looking. I've had this idea for a while of making compatible PCB with SMD(?) pads for a shift reg (4021), MD/PCE mux (74HC157), or plain Amiga/Atari wiring. Mod/breakout friendly. Custom PCBs are very cheap nowadays, unlike making plastics. Unsure if the pads need to be coated with the black carbon(?) stuff or not. Some of the cheaper joypads do not have it.
A swap-in PCB for the NES joypad shell. The layout needs some work and I might've made some errors on the schematics. The idea is that one would pretty much just solder on the required IC, a resistor network, then the wires for the new cable (likely a DE-9 or mini din). Omitted ICs would leave those traces unconnected so there would be no conflicts that I can think of... if there are, I suppose a few solderbridge-jumpers could be used (1A-2A-GND in MD circuit?).
The MCU has a few breakouts for custom connections, USB, and some exposed ICSP stuff. With an Amiga/Atari/MSX/SMS, no IC or RP would be needed as it's just dumb switches, so only the relevant DE-9 wires would have to be soldered on. I've added a minimal 555 circuit so one of the unused buttons can act as autofire of some hardwired frequency. Suitable resistors might be 10K and 1K for pull-ups and current limiting, but the 555 might need larger values to remain compact. In some cases the resistor pads could be given both SMD pad and through-holes.
I had to make some guesses with the schematics. R7 in the 3 button MD pad seems to pull-up the select pin (1). Hard to tell by pics of the SMD PCB but the through-hole PCB has it there. The PC-engine's original controller had no autofire switches (nor does the NES pad) but I can't find PCB photos of it to work from. It might need current limiting resistors on the Y lines and some pull-ups on the select and enable pins (see "???" areas).
I'd like to support the cheaper 74HC165 SOP as a 4021 replacement, as it would free up a lot of space on the PCB for traces, but it's unclear if it's fully compatible. The LS variant is more pricey. SMD isn't that hard to solder (might be for a first-timer) and the space-saving is significant as with through-hole you also lose the back of the PCB where the legs poke out, and can't run traces there easily.
Another PCB solution (if no room for all ICs) is leaving a dock space top-center for a small daughter-board, which has the relevant cable and IC on it and can be swapped. The main PCB has just the button wiring and an angled/flat 0.1" header. I noticed NES schematics say 1K pullups but I measured 42K on my old NES pad.
Pull-ups are used to make the buttons default to a HIGH state. When a button is pressed, it's connected to GND and goes LOW. Without a pull-up, an unpressed button would "float" as it's not connected to anything and most ICs would then read it as jitter.
The shift registers mentioned can take 8 parallel inputs, store them as 8 bits (LOW/HIGH), and something else can then request these bits one at a time serially over just a few wires (rather than 8).
A mux, or multiplexer can also send data over fewer wires, but use channels to do this instead. The 74HC157 only has two channels, i.e. a single bit to select between the A or B channel. It can handle 8 buttons as input, but outputs sets of 4 in parallel.
Computers are plenty fast enough and I don't need a new one, but looking at Apple's current 2019 Mac Mini lineup I was a bit disappointed. Same design aside from the soot tone, and a rather expensive low-end version. I did a mockup for an Apple IIc modern slim office variant to make myself happy. 2020 called and says M1 is here. Mini price more reasonable.
There's unfortunately no room for function keys on this design without modifying the original Apple IIc keyboard. Could maybe do an Atari ST solution as the designs are kinda close. The FDD slot could be re-purposed as a neato accessible SATA drive bay, with that locking tab. Apple earns much money from soldering storage and overcharging though. I iterated this concept a bit on another page.
Simple controller based on the apple disk drive and IIc case.
I think using an IC was the correct choice for joypads back in the day. The NES used a shift register whilst the Megadrive & PCE used a multiplexer. The Amiga/Atari really suffered with its single button games. The CD32 was too late. Anyways, on the NES pad, SELECT felt redundant and was too hard to access in action games like Metroid, so I would perhaps have preferred a third button like drawn, or a shoulder button. the advantage with those is that they can be held down while using all other buttons, which is great for speed control, tank turrets etc.
After seeing the XPD-1LR with the dual D-pads (second uses a 157 mux) I had to doodle something, using a 165 instead. I guess a rhombus button arrangement (SNES, Gamecube) might work in games like Robotron but I never liked the feel of it and when it comes to buttons I prefer spatial discreteness.
This design only has 4 buttons, so the right D-pad also triggers B,A & L,R shoulders. But what about HomeMenu and Pause? Well, you have to let go of the left D-pad to press them, and are likely no longer playing, so I think it's okay to use the physically impossible directions (L+R, U+D).
Every game on a system with this joypad would need a movement handler accounting for impossible dirs so the game character doesn't bug out. Why not just use another shift register like the SNES? There's perhaps an advantage to keeping it 8-bit as that was the databus size on old peripheral chips and it's a single shift.
Of course, if you have a custom peripheral interface IC, then it could do bit-field stuff automatically and save the programmers a little work, producing a nice 3-bit 8 direction nibble. Actually, 4-bit because of no-direction. The advantage would pretty much just be a better structured bit-field for more compact jump-tables in movement handlers.
0DIR = 0-7 clockwise 1000 = No direction 1001 = R+L 1010 = D+U 1... = Unused
It's always interesting to mismatch the top/bottom parts of an enclosure/case, like with uh, bikinis. The ORIC Atmos did that... I discovered only recently because most pics are top views.
The Commodore CD-Cube mini from Universe 18 used...uh, Mini CDs? B-card? Minidisc? I looked into the workings of CD32 joypads but it's rather quirky stuff with the legacy support and tri-state buffer.
Center analog pads, for Robotron/arena games, and racing. The N64 solution kinda locks the hand to that center handle, with no access to face buttons. I added a rotary encoder (like a mouse wheel). These joypads could use my (7-wire) peripheral IC detailed later on this page. Simpler and with lower latency than USB, I think. Wheels on L/R might be more practical than on face. A rotary encoder is about 1x1cm without the legs so it might fit, but can't be clickable without serious/expensive engineering. The shoulder buttons are near so whatever.
This region is about the size of the "Sidewinder", so the thumb-stretch (5.5cm) isn't too extreme.
Dissected rotary encoder (from a mouse). I'm guessing the common leg (solid ring slice) connects to the brushes on the wheel then to the quadrature legs (striped slices). L/R spin produces different pulse patterns. The groves on back of wheel just go BRRR against the metal piece with a bump. Unsure if for alignment or just feel.
I could imagine getting the Megadrive mini. Ok price point, inhouse hardware/dev (through very likely emulation), and I never really played that many MD games. I don't mind 3 button only controllers... I think I prefer less buttons actually, for thumb actions at least. My old brain can't handle four buttons in a plus formation, or 6. It gets spatially confusing to have them all on the thumb. I don't play fighting games, but I suspect using shoulder buttons to modify low/high or whatever could make sense. Hard to say how the thumb will roll over this triangle formation of buttons without testing.
The SEGA Mega Drive seemingly has some potential to be a competent gaming-computer. I mostly just wanted to draw a keyboard model though.
The keyboard is a Dvorak variant layout, 13u wide so less hand-sidewaying. Number entry at lefthand top. Text editing lefthand bottom (bs/del, cursor movement, tab, enter, shift select) (find-cut-copy-paste could somehow go on arrow keys too, not qjkx as the keys can be pulled and rearranged into e.g. qwerty). Probably Fn key + numbers for Function keys etc. There's a Shift+Alt combo key where tab is normally. Diacritic dead-keys are top-right. The German hard-S (here on Z) is actually not a Greek Beta but an old germanic glyph. Phi and small Omega are useful for drawing cat faces.
The keys are half-height (based on my Logitech K120), cheap membrane (I'm not really a fan of full-height cherry keys&switches). Case size is ~92% of an A4. Floppy drive probably have to be a compact/thin modern variant to fit under the keyboard. Drive acoustics are very important for the right feel, so I'm thinking the 16-BIT dome is... sort of like a church here. The upper case part doesn't have a big hole for a PCB keyboard since it's a membrane variant. Instead there's an array of key necks in a basin. This makes the case more rigid, and kinda spill-proof. The flex PCB typically lies on top of the bottom case, but this would leave no room for a computer beneath and cause issues. A small SBC/SoC sized might still fit under the dome if PSU is top-left. Bottom border with the MEGA DRIVE III logo could be extended a bit I think.
It's always to imagine all of the volumes and intersections when drawing topdown. I guess a side view might look something like this. I notice that if made very thin, then the floppy will eject onto the table and not into the hand... hard to push the button. Older wedge keyboard computers were deeper and thus got further up. Sometimes their drives were angled (helps with mould separation). I get wrist pains if the keyboard is too far off the table so I can't elevate it much. Also, it's not possible to use the lower case as backing for the entire keyboard membrane+flex (e.g. under +-) without exposing the drive to open air having a third case part. Unsure if a metal plate works, as it might need tabs to hold the flex in place (could have holes in it and the basin's bottom has pegs/posts). Because of mould separation for the keyboard necks/basin, certain tricky constraints are put on the dome panel lines and screw posts (has to be angled right). Also, lots of pad printing on this case, and that gold effect which I notice they skip on budget MD models.
SEGA had a lot of experience making arcade machines, and it seems to me like the Mega Drive was a cost reduced, consolidated version of the SEGA System 16 arcade boards. There's a Motorola 68K and Z80 (with an YM + AudioRAM) for sound (the Z80 also ran SMS games on the MD?). However, System 16 machines can pump out a lot of large sprites and have line buffers. Separate ICs are used for sprites and backgrounds. The game data is stored in onboard ROM chips (rather than on game cartridges). PIO is managed by nearly 20 off-the-shelf logic chips, such as optocouplers and multiplexers. There are a lot of logic chips (e.g. 74 series).
The Mega Drive has similar graphics capabilities with two planes+text window but the sprites-per-scanline limit is lower, sprites can't be as wide, VRAM is smaller, and the colour resolution is lower (3+3+3 bit nonlinear). Both systems feature a 68K processor which can address several megabytes of main memory (+cart ROM & expansion area). VideoRAM and AudioRAM are separate, sort of. The MD only has 64kB VideoRAM, which in 16 colours is enough for 292×292 to 328×328 pixels worth of (simultaneous) graphics* (sprites+BG). It's not much space for fancy extra animations or big unique BG landmarks (unless those stream/DMA in during play rather than level change).
* Obviously the graphical space is more like a long string of 8×8 tiles but it's hard to imagine how much space 1300~1700 tiles is. I'm guessing the BG is more space efficient than max size sprites which likely have some air waste.
Then we have SEGA System 24, which does look quite interesting! It is a floppy drive system (hooray!) rather than ROM based. It has enough RAM for a MF2HD load. The resolution is 496×384, which is good for Desktop OS stuff where 320×240 is a bit tight. I don't think I'd like to pixel game assets for 496×384 however. There's also some complexity with dual 68K processors, and the game library isn't all that, aside from Bonanza Brothers and Gain Ground.
So what would my ideal 16-bit SEGA computer look like? It would have to be easy to develop for, so I have a few requirements:
Some simplified schematics for my Megadrive. Later MD models consolidated the a lot of ICs into one ASIC (FC1004). Unlike the Z80, the (regular) 68000 is seemingly out of production*. The 68K supposedly has 68K transistors, VDP... 100K? Much more if buffed The Saturn VDP was 1M. PIII: 9.5-45M, Apple M1: 16B.
* I'm seeing some MC68SEC000 on digikey. Datasheet bits: T/QFP-64, 10/16/20MHz, HCMOS 3.3 or 5V (handy). Code for it runs on other models but possibly not the other way around as a few minor features are missing. A little pricey ($8-20 @ low qty.) but seemingly available by the thousands. Datasheet is dated 1996...
I suppose the 68K could be replaced with a RISC-V or ARM (which have a lower transistor count) but then all legacy software would need a binary translation / port, though the VDP & sound bits would still run fine. It would need to be moved onto the floppy format anyways.
The PIO could be moved out to a cheap MCU to reduce transistors/costs. It was not uncommon for them to be used (A1200 keyboard had one). The MCU can handle the shift registers, muxes etc for peripherals, and also set up a boot vector and BIOS since there's no ROM.
Unsure about memory type. Maybe 8-bit SRAM for Video and cheaper 16-bit PSRAM (with built in refresh) for Work RAM. Modern fast SDRAM runs into trouble if down-clocked but I don't know what the limit is in Mhz.
There are a couple of other enhanced MD projects out there, by fans, and by more official sources, such as M2 with their GigaDrive. It mainly focuses on 3D display though which is a bit exotic. My project turns the MD into an independent development system (convenient architecture, keyboard, writeable floppy media), which would help with software creation/porting and distribution.
Perhaps a system with wave tiles can be used to add some dimensionality to the sound, giving it a SID like quality. Unsure if instrument memory makes sense. Could reduce traffic a bit.
Here repurposing a cheap USB joypad into a PCE pad. Using a cut DIP-16 socket to make a simple connector. 74HC157 SOP daughterboard. I found a DE-9 to mini din cable that might be handy. On the mini din, note that the center pin should be offset to work with the PCE (shown unit-end on my schematic here but it's reverse on the pad plug... it's easy to wire up mirrored!).
Finally got around to modifying the very cheap China pad. Decided to not put any circuitry inside so I can just plug an adapter onto the DE-9 externally. Attached is a test board with 8 LEDs (and random old junk). I had to merge some buttons L/Select, R/Start, etc.
...it's oddly satisfying to just make the lights dance. Bare minimum gameplay right there.
I think when you roll between Y and B with the thumb, the positioning of the hand makes reaching the shoulder button with the index finger kinda strained. It needs to be further in and/or lower down towards the backside of the controller.
A simple door/window sound alarm, using power only when triggered. It might be better to make a leaf-switch instead, similar to those found in pinball machines. Put a weight on it, and a card between, then a tripwire to the card. When the card is pulled away the contacts close. This way multiple windows or a hallway can be covered by a single device.
Here's a random idea for an... uh, general purpose peripheral interface shift register. It's a bit anachronistic as a modern solution. Nowadays we'd use a MCU (micro controller) communicating over USB, though USB is a bit bloated for simpler devices. Also, I think I've read that a (slower) MCU is not fast enough to properly emulate the timings of shift registers in some cases.
This design has internal accumulators for rotary encoders (e.g. a mouse) to increase precision in low frequency polling scenarios. The button pins can be hardwired to provide a device ID. The chip is a bit like an MCU without processor.
For the ADC, 6 bits (64 levels) might be enough for games, though some will be lost in calibration. Less bits keeps the comparator count lower and data length down. I'm not sure if the rotary encoder accumulators (with Schmitt triggers) could use Johnson ring counters, they'd have to be signed somehow.
Thinking about that SEGA Mega Drive mini and those systems in general... I might actually prefer to not be overwhelmed by 30-40 games, because I'd probably just skim. 10-game cartridges might be preferable, and scalable, and more authentic.
The emulator (seems likely) will probably just pull the game image from flash mem or something into RAM. 10 games might need a 32MB/256Mbit IC. Slap it onto a PCB and into a tiny cartridge. Would increase cost of the system but it might elevate the experience.
SPI flash could fit because it's simple linear storage. I see there's "Quad" I/O SPI Flash so maybe a second for a 256Mbit load...? It's 16-SOIC so it would make the cartridge connector look sufficiently populated. Then there's the boot time of probably-linux though. Each cart would need some game-menu data... maybe the menu is an actual game. I'm not much for fancy HD flippity-glide menus. The cartridge label could show the characters from the games.
I made my own Megadrive / Genesis Mini wishlist, not being perfectly pleased with the official one. I included some games I'm just curious about, and a few strategy ones, and a sexy game. I only ever saw & played the MD in the stores back then so this list isn't very informed or objective.
|Official List (42)||My List (42)|
I'm not that interested in:
I'm more interested in:
Some comments to go with that: Monster World 4, Castlevania (jp ver?) and Contra seems like the games I'd be most likely to spend time with after the initial appeal. Alien Soldier looks great, condensed and hectic. Space Harrier, Moonwalker, Altered Beast Golden Axe, Castle of Illusion, Truxton are all games I might not play much but they certainly made an impression on me when I first saw them. I feel like they belong with the system. Alien Storm has an interesting aesthetic going on. I actually bought Gunstar Heroes and Golden Axe for the wii but discovered that you kinda need two players. I'm too old&busy for enduring the... dying on bosses and starting over procedure, so the fun probably would come from the social aspect there. Megalomania (jp ver), Dune II, Herzog Zweii, Starflight, Buck Rogers, are all sort of strategy-action thinky and nice for pace variation. The latter is a wildcard though. Sub Terrania is some sort of Thrust game, and I like those. Seen on hidden-gem lists. So is the graphically interesting Atomic Runner. Blades of Vengeance: big sexy sprite! Leander vibe? Valis III: This series met a distasteful end with the anatomically awkward Valis X character H-games. I think it was some sort of desperation move by the dying publisher. But never mind that. Valis III has interesting cut scenes and a cheesy plot iirc. Maybe more-so on the PCE CD tho? Gauntlet IV: Unsure if good, but I always found Gauntlet's presentation interesting, like a diorama. I want to reach down and grab the figures! The palette looks a bit miscalibrated. Road Rash... I don't like Outrun type games unless they have a twist and this one seems like mindless silly fun. Micro Machines: I like top-down racers. Target Earth. Little chunky gliding mechs, yes please. Looks a bit iffy, but it's little chunky gliding mechs. Madou Monogatari: Mostly interested because I like the Puyo Puyo character designs and this is the source (maybe never translated). Japanese MD Mini has it I think. Their list is quite different. Devil Crash is one of those non-realistic pinball games. Quite neat looking actually. I prefer realistic tables, but looking at Psycho Pinball the screen is just too small/claustrophobic for that. SpeedBall 2 & Mutant League Football... fantasy sport titles are more evergreen I feel. I'm not a huge Bomberman fan but worked up the mood with my recent drawings, so... yeah, Mega Bomberman, sure. Looks fairly varied compared to the original so I might get sucked in. Strong singleplayer in this one? Strider looked balls to the walls amazing when I first saw that mechanical gorilla somewhere. Unsure if I could get into & wade through Shadowrun, but have heard good things about it. Apparently Turrican II was turned into Universal Soldier. Mega Turrican looks nice but is perhaps the worse game? Thunder (Lightening) Force IV & Ranger-X are both graphically impressive but unknown to me. Truxton was a much earlier game but I remember being impressed by the lightning strike effect. Streets of Rage II is apparently good. I never played these kind of games much, except for Bop'n'Rumble on a C64 + tiny B/W TV. Now, Pulseman I recognize because it's associated with Gamefreak of Pokémon fame. It's a pretty effective character design. Gameplay looks a bit flat though. I'd rather play it over Megaman WW which the 16-bit gfx is doing no favours, but I could perhaps pick another game for this slot.
As for the official-list games that I didn't include: Several were cartoon style games. I think these age poorly, focusing so much on big, floaty wacky animations. boots. Beyond Oasis: walk animation, swing animation, walk animation. Mean Mean Machine: I prefer original Puyo theme. Landstalker: I... don't like his big Street Fighter... it's a bit too ubiquitous and maybe better elsewhere. Not a thing that's strongly MD. Alex Kidd and Monster World not-4. I really wish these looked & played better but they don't. GnG is a bit sluggish and somehow atmospherically oppressive. Shinobi 3 looks great and silly and I should probably include it.
Wonder Boy in Monster World pixel-overs using the original palette.
Mega Drive Altered Beast pixel-over. Some additional colours but not yet 16. Unsure what practical restrictions there were ingame... the MD sprites seem a bit rushed/unfinished. Sonic, Golden Axe and Alien Storm was out by the time I saw the MD here in Europe, so Altered Beast was kinda dated. I remember playing and craving those cool powerups though. I wonder how to improve the game... more moves, contextual animations, but skip the first power up level to reduce animation work.
Tyris Flare pixel-over, from arcade ver. which needed some gamma adjustment for the palette. Also some bikini adjustment.
Had to do Gunstar Heroes too (just reshading, didn't touch the leaning). Discovered that one of the palettes (at least on rip sheet) is almost a 1:1 match to the generic 16 colour palette I started on back in the pixelation days. I think Pico-8 used it vaguely as a base but I could be mistaken.
A few more pixel-overs from MD/Arcade/Amiga games. Alien Storm: Adding some chrome burn on weapons is always fun. Blades of Vengeance: Look at the musculaaarity. Alisia Dragoon: The original character palette was most peculiar. Despite having a dedicated 16 colour palette, there was no green (as called for by the character concept), instead they seemingly... dithered blue and yellow. It was a rather inefficient palette so I added the greens. Rocket Knight / Sparkster: Got some gunstar legs and sonic hair. GnG Arthur: His palette is pretty minimal and could use a few more colours. Zool: In Gunstar scale/style. The legs makes it look more insect'y but with those green ears and limbs I'm not sure what's going on with the design. Strider: Complete style conversion. Moonwalker: Inconsistent lighting in digitized music video stills (front or back/rim). I brought out some press folds on pants. The suit was probably close to white irl. It had some asymmetrical features which was removed due to sprite flipping in game. Wily Wars: Chonkified. Streets of Rage: Palette modified for subtler skin tone. No pantyshot in US version afaik. Shinobi: Added some detail like the glove spikes and flattened some areas a bit to balance the added detail. He's quite animated, stretchy and toetippy. Moonstone: Couldn't really solve well. The rest are Baal, Magic Sword, Chuck Rock, Turrican, Leander.
Considerations doing these:
• Figurative portrayal (what things are, figure gesture, texture) and context against other frames / complimenary info therefrom (or from peripheral art).
• Palette. I'm fairly sensitive and noodly here, trying to find pleasant and more useful colours, which can usually be done without departing too far from the original palette. Usually the problem is in the darks, lack of hues in ramps, muddy ramps, unusable garish extremes.
• Pixel technique (I don't spend much time on this if the other stuff kinda works).
• Just having fun.
Battle Mania pixel-over. I somewhat averaged the palettes from the original & sequel. Pushing flats more. Tried to also match the character promo art a bit. I haven't seen any sprite sheets from these games, hardly any screenshots even... The sequel looks pretty good, kind of goes nuts with ramps and AA but generally makes it work, though it's not a style for me. The original has some overexposure and magenta skin... and fun naiveté, I guess. I wanted to mix em and throw in some ideas of my own. The car uses the same palette as the character. It's reminiscent of a 1988 Mini convertible. The cover version has the same luggage rack as a vintage Fiat 124.
Pixel-over of the blue bee. Gave it some frames to make it less of a sliding cardboard figure. And a little pilot. Debris & pilot could scatter on explosion.
Bravely attempted to pixel-over a BitmapBros game. The armour designs in Speedball are inconsistent between all sources, but I imagine it's just different models, as you can upgrade ingame. The style is very UK comic / Judge Dredd but also has this chunky-rounded-metal-shapes thing going on. Anyways, I thought it would be interesting to do a female armour variant. Chainmail pant might fit the setting and BitmapBros often dithered fields for texture. Rastan didn't have a MD port that I know of. It was only on the SMS. The barbarian has a pretty rich palette, compared to games by BitmapBros who often used two longer ramps in some tone, with subtle hue shifts.
I wanted to pixel-over the snake boss from (SEGA System 16B) Cotton but found no screenshots, so I had to dump from a ROM. I'm not comfortable pixeling larger things. Arcade games of the era have larger sprites and more frames. The Cotton atmosphere is spooky and fun and it seems to play really well. Cotton was also on the PCE but in lower rez. The PCE also had Magical Chase.
Speedball: Out of Bounds - Just wanted to draw a Speedball II character from the side at Gunstar scale, using the original palette. I'm thinking it's a jump'n'gun where a player leaves the arena and goes into the wilds (probably some sort of Judge Dredd / Nemesis Warlock world). Armour and upgrades areaquired along the way. Perhaps the Speedball gear is also general armour in this rough world, rather than sports specific.
I don't really like pixeling with these long ramps, because more time has to be spent building shades, doing AA and just choosing between subtle colours, and this takes time away from getting the shapes down properly. High friction process. I suppose ideal ramp length depends on graphics size, but on the Amiga the palette was often shared between larger BG tiles and scenes, and the smaller sprites. I think the 1-pixel-2-birds type problem solving goes away at highrez, and it becomes more focused on managing and cleaning vectors and gradients.
1: Gladiator/Arena pits. You wake up naked, wounded and betrayed in a morgue/cell. Cross the empty arena and enter:
2: Sewers (Killing Game Show style) up into:
3: Dredd city. Find antagonist, who escapes into:
4: The infested wilds/wasteland (Amiga Ork), then to:
5: The ancient temple (Gods).
Some of the armour variants.
A Sonic redesign done randomly and for no purpose.
It's difficult to turn these kind of overly detailed characters with more realistic proportions into sprites. They lose the oomph and perhaps only work in Playstation era+ games (higher resolutions, maybe 3D). I think the original Sonic design is probably one of the best mascot designs around, but it's hard to put a finger on why it is so. I think it's the immediate familiarity combined with a memorable foreign element (hedgehog -> blue), and the powerful silhouette and simplified forms, and the shoes (and also swoosh-line spikes) indicate speed. Pikachu pulls a similar number. Mouse, yellow, electric (as indicated by tail). Good silhoette too. Pulseman sort of works but doesn't communicate as effectively as Pikachu does.
There were so many attempts at the time which didn't stick. With Ristar, I don't really care about a humanoid star I guess. Same with Cool Spot. Zool has pretty boring colours and shapes and the figure doesn't say much about what it is. Croc is too much of a generic green cartoon crocodile. Then there were a whole slew of generic brown cartoon animals (Bubsy, Titus the fox, Banjo).
Marina Liteyears is one of my favourite character designs from the '90s. I think it could've become a successful mascot and it's a bit of a mystery why it didn't. Maybe the weirdness and monotony of the game. Carbuncle from Puyo Puyo is good too... but the name is... unfortunate.
PC Engine III. An early '90s PCE variant. Memory mapping is a bit all over the place on the PCEs. A 21-bit address bus and 8-bit data bus equals a 2MB limit. The first MB was used for the Hu-Cards, which were ROMs, except the the system/arcade cards which could also include RAM. The second MB was seemingly mostly unused, except near the end. It might be possible to squeeze in more RAM somewhere... 640kB ought to be enough for anyone.
With the SuperGrafx, intended to be the PCEII, they quadrupled the work RAM from 8kB to 32kB. Having programmed microcontrollers, 8kB is really quite a lot (generally it's variable space as programs are stored in ROM), but games tend to eat it up when doing pathfinding and other heavy array stuff. The original PCE also use 2 byte words for the VRAM, which I think means it could've been able to address two 64kB VRAM chips rather than just the one it had. Strangely, just adding another graphics chip into the SuperGrafx was possible, somehow enabling dual/layered effects. Unsure how they talked or shared VRAM, which was doubled. The PCE just put the sprites on top of a single background.
It was competent system for its time, and very compact due to ASICs/consolidation. Both the TurboGrafx & SuperGrafx were needlessly huge. My version here uses 210MB Mini CDs just because it's cute. I suppose the system card is integrated, meaning no backwards compatibility for card media. I think Mini CDs could've made sense then only if MP3 had been around so an album would fit. On such a slow GPU compressed audio might need HW accelerated decoding though, and streaming due to the severe memory limitations. Some PCEs had battery backed RAM, 2kB, for saving... I'd rather add a floppy drive of course, but didn't draw one. Serial Flash (accessed via a port?) is a more modern solution. With a drive rather than fast ROM, you'll need tons of RAM to read into. either.
As usual, my redesign would have a keyboard and run an OS, maybe from the system-card. I think Hudson had HuBasic and... Human68K? I've never really looked into those. Did manage to compile and run some HuC stuff (a C-language) years ago. With a GPU, maybe hand-optimized ASM is less critical. It unloads the CPU and makes GPIO timing stuff more reliable.
On the Amiga, graphics manipulation had to be pretty low level and BASIC was not enough to make it sing. I think on the PCE you'd mostly just set up the GPU for each frame (similar as Playstation?). VRAM on is generally accessed via narrow ports and memory blocks, with the disadvantage that it's slow for custom graphics, like Doom, Lemmings, drawing, vectors.
The PCE 3+3+3 bit (512 colour) palette sorted as a cloud. Because RGB has 3 dimensions it's not possible to unwrap it onto a 2D plane. Here it ended up taking the shape of a hexagon with some of the more grey colours mingling at the centre.
Colours and pixels look quite different on real hardware + CRT so I'm not sure how accurate this comparison of the Mega Drive and PCE palette is. What I wanted to study though, is the difference of evenly spaced colour increments (PCE) and uneven (MD). The PCE palette is quite garish. I never liked these kind of low bit full-spectrum palettes. The MD palette has uneven colour increments according to a document I found, so it features more mid-tones and muted colours. It becomes apparent if the images are overlayed and animated. A hand-crafted palette would provide a more useful colour space, but I think at the 256+ colours point, it is better to just go for a 4+4+4 bit palette, like the Amiga. That's 16 steps per slider.
Faussete Amour pixel-over... it's one of those games which has a mysterious appeal, but it was not included with the PCE Mini, perhaps, probably, likely because it's lewd. The PCE Mini game lineup seems pretty good overall, but there are some missing titles. I would've liked to see Magical Chase and Cotton, but maybe they were excluded for reasons. Some of the included titles had variants/sequels, like Galaga '90, Devil's Crush. I'm not sure if I saw Parodius Da, but it's cute. Metal Stoker looks quite unique and interesting. I don't know if the Populous port is any good (I guess there's Nectaris for strat). When it comes to Raiden, I think I prefer Raiden II on PC/Arcade. Pool... maybe?
FM Towns Mini.
Another idiotic mockup. It's the Philips CC-i (Cassette Computer), an 8-bit computer with a 4-bit blitter. The tape deck is under program control (like a '70s mini-computer tape station). It can scan data tapes and store a little FAT in battery backed memory for quick access later, via program or buttons 1-8 for the first entries. This means CC-i formatted data tapes contain periodic tape-name & position segments, allowing the system to understand what tape it's currently reading. Tape contents can be monitored on the display. When inserting a user tape the deck will search for a tape id segment, check with FAT, then list the files, which could be something like 18 saved BASIC programs, then wind to whichever. A commercial game might only use a few entries, like 1 for game, 2 for editor, maybe saves. Obviously, if you borrow a friend's tape, you'd have to scan it to register the contents into FAT which could take some time. Computers often used general purpose music cassette players. Possibly a custom tape deck could read contents at a higher speed.
Zilog actually had a comic hero mascot at one point. Also seen: redesigns of some other chars.
"Bar Codes: Next Craze for Kids? : Games: An electronic toy that encourages players to buy everything from hot dogs to tea is coming soon. Critics warn that it's a bad influence on children."
-LA Times June 16, 1993
Barcode World handheld. I remember being curious about Barcode Battler back in the day, but i didn't know there was a larger ecosystem around it with NES and SNES games and various companies producing cards with their characters.
The barcode data format is somewhat interesting. Because a barcode needs to look barcodey to be recognised by a dumb/quirky reader device, it's not possible to just store numbers using binary (black and white) bars. Because of this, a range of 0-9 actually needs 7 bits to get the right stripey-ness. There also needs to be a checksum, a few bits to start, center and end the barcode, and some bits for orientation so products held upside down are read properly. I think Barcode Battler uses the numbers as a random seed for generating the character/item values.
Sporty not-Twin Famicom. Yip Yip! Having a proper button for Select would help in Metroid, and games like Robo Warrior might've benefitted from item hotkeys like Select-Up for EN refill. I didn't do a flat bottom on the joypad for ergonomic reasons but it might be detrimental to people with disabilities who play with the pad on a table. A shoulder button requires more engineering but it would've been great in Metroid for temporarily shifting to missiles /while/ firing (and maybe even jumping).
Could Pokémon have been a NES game? Yes (there is a Chinese port), but it's less realistic as a 1987-89 product because the mindset was different then and cartridges were smaller. Also, I read that it took six years to develop the first game. Probably a lot of trial and error, iteration.
I'm still curious about the size issue. I'm likely underestimating things... but maybe 256 kilobytes would be doable if kept simple. Under 128 seems unlikely given the large monster & trainer images, but 128 was seemingly the big size back in the mid-late '80s. Game code (ASM) is very compact compared to graphics.
I believe games with dynamic tile tables might've used an SRAM in the cartridge (ah, it's called CHR RAM), which would add to the cost. Back views appear to be 4x4 tiles scaled up using 2x into a 7x7 table. With 120 monsters that's an extra 26KB.
RLE compression (used by the GB games I believe) is not super effective on the monster images, compared to regular tiles. Maybe 10-20% smaller on the larger images. Dithering makes it worse.
Ultimately I'd probably use regular tiles. Since none of the tiles on the figures occur more than once (they are all unique), storing them in reading order makes sense. The tile map is 7x7, so 7 bytes could act as a bit mask/field for where the stream of tiles will go, and not (white/blank spaces).
How about a PCE OS using Hudson soft characters? I don't know much about Human68K or SX Window but skimmed the manuals. I think I prefer booting into either a window manager or BASIC over a boring DOS terminal thingy. I've tested HuC a bit and it seems to work well for compiling games on a personal computer then running the ROM in an emulator. Still, there's something neat about direct (low level) GPU access via a high level language like BASIC. With the 2MB address space (and maybe 2 GPUs), maybe it would be possible to compartmentalise the game and OS areas. I think lively icons would help function memorisation, like, feeding files to the trash crocodile... there's a stronger association with peril there.
Hudson Soft did a few of the best looking looking games for the PCE, like Dungeon Explorers, Military Madness and Soldier Blade.
Neutopia was Hudson's Zelda-like game. I did some pixel-overs, but imitating aLttP is kinda... obvious? The PCE sprites are multiples of 16 px, with 16 colours and 16 palettes. I'm not using that many colours here though. Tiles are multiples of 8 px. Both tiles and sprites are transferred from ROM (up to 1MB card) to VRAM (64kB), so I guess objects can be streamed in on demand. 64kB is enough for maybe 200-300 pixels square of graphics (tile maps and tables take up the rest of the space). In aLttP the graphics supposedly did not use all 16 colours to save ROM space, but I think above 8 there are diminishing returns and often antialiasing will just blur and muddy the look, unless it's a large object (prop/boss) which needs smooth shading or extra accents. Neutopia 2 skipped the white of the eyes, which lowers noise & is kinda Bomberman (both are Hudson soft titles).
Neutopia 2 props, pixel-overs.
That police car in the Bomberman 2 (NES) intro feelt a bit dinky. BM2 is pretty nice graphically otherwise. Bomberman Quest (GBC) is even more impressive. The Saturn version is very polished too.
I think Bomberman is some kind of multi-sprite. It was perhaps affordable in this type of game. Japanese police cars had a lower black stripe like this in the '80s. Dollars were stolen though. Bomberman Jetters had neat bulbous hover vehicles and I wanted to echo that.
Suit redesign. I guess Bomberman would work as a minecraft clone. Replace pickaxe with bombs. Upgrade finding/crafting. There's already a fun fauna of suitably chunky monsters of course. I guess I already thought a bit about ecology on my Bomber Queen page. Certain blocks are invincible to weaker bombs. Different bomb types could do different things, like focused beam for making tunnels (bombing one block at a time, backing off would be a chore). Incendiary only. Specific block type destruction. X-ray blast for spotting resources/tunnels. Then all these Bomberman Quest items.
Phantasy Star 4's Fal.
A Rocket Knight.
Felix the Cat is perhaps the source of everything. I forgot to draw the whiskers here for some reason. Hudson actually did the NES game.
SpaceHunter Felaran... in Popful Mail armour?
There's a Ms.Do in the Neo Geo version I think. Robotron: 2084 is one of my favourite arcade games though I'm not very good at it. Midway (?) used to have a playable browser version.
I've been wanting to build a modular arcade cabinet with wood grain and custom art, but it's a lot of work.
The control board is the first module. I want to include a trackball for centipede but have none at the moment. Each game has a small button layout card which can sit somewhere visible. I'm hoping to play Robotron: 2084 on this.
Prototype build. I wanted to try multiple layouts. Is it possible to play Smash TV using a D-pad button layout? Well sort of. Twin-stick feels much more responsive though. The best button layout is probably the traditional one seen on most arcade joysticks. My buttons should've gone a bit higher up too, to increase palm rest space. The small buttons on the front are for MAME stuff. I should paint this '70s brown.
I used plastic lollipop tubes as spacers for the USB joystick PCBs. They have connectors for up to 12 buttons and 4 directions, and some mystery stuff. I was too lazy to make a PCB for my small front panel buttons so they're just held in by a stick. I didn't fully secure the eclip in case I need to take this apart later, but it's on well enough. Some of the crimp terminals were a size too small to fit on the microswitches so they're just hanging on by the insulation.
These buttons are a bit rattly but a bit of padding (paper or green stuff) improves contact between the button feet and switch. Without, if pushing on the very edge of the button opposite to the switch foot, the press won't register.
My old eeePC netbook is too slow to run MAME, but my Celeron G550 Desktop seems up to the task. It has a cheap graphics card but I think MAME is mostly a 1-thread software thing. If I were to build a new machine for it, I'd go for a Deskmini A300 with an AMD Athlon 3000G. It's newer and faster than the Celeron G550 and I don't really need the cores of the Ryzen series. Maybe some fast RAM would be nice though (3200?).
As for my MAME settings, I'd probably adjust the gamma of a dedicated monitor to match that of an old CRT. Otherwise I go for Brightness 1.040, Contrast 1.050, Gamma 0.850 for most games, and towards Brightness 1.080, Contrast 1.100, Gamma 0.550 for particularly washed out / pastel looking games like Alien Syndrome, Space Harrier, Contra, Altered Beast, etc. They actually look quite nice with a proper gamma. Most people don't seem to adjust and are missing out. Some ports to modern systems keep the washed out look for some reason. It's like playing playing Skyrim on a '70s monochrome amber monitor thinking that's Skyrim's natural look. This said, I prefer it when screenshots are raw so I can apply my own adjustments when referencing them for a pixel-over and whatnot.
Additionally, I don't think audio filtering is done in MAME. Each board probably had some high+low pass filtering components (and EMI). The Amiga had a low-pass filter IIRC. I made a low-pass filter for screechy high pitch games like Bubble Bobble just to save my ears.
I actually don't like joysticks much but wanted to design one with multiple buttons (using an 8-bit shift register).