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.
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.
The new Mac Minis seem expensive even for Apple. My last MacMini was the low-end 400-500 dollar model. I'm sad there's only the 1K option 5 years later. Similar spec'd Windows machines are like 1/3rd the price. The i3 8100B's bang-for-buck value stood out to me on PassMark. I was wondering at first why they didn't pick another of the 8th gen i3s after but looking at benchmarks it seems then you can be paying for low power traits and such.
Tangent: I wish apple had gone for AMD instead... It might've been more interesting & I like that company a bit more. Supposedly the i3 is good at video editing, but I think there's a slight bias to CPU reviews because many reviewers do video editing... for their reviews, which is not really normal usage. Looks like $133 for the i3 8100B (cpu mark 8431) and $100 for the Ryzen 3 2200G (7310). Potentially lower Watt on the Ryzen, maybe nice for silent machines.
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.
I've talked about elsewhere, but I've often wanted 9 buttons but this means using two 8-bit ICs. However, because pause/start is rarely or never held or spammed, impossible directions (like L+R) on the physical plus-pad could be used to make a 9th button. There's not much point in making it U+D+L+R as that would use 4 diodes instead of 2. I use diodes because one can't rely on simultaneous contact in a physical button. There are 7 possible ...impossible directions. Every game on a system with this joypad would need a movement handler able to filter/detect impossible dirs so the game character doesn't bug out. There's an advantage to keeping it 8-bit as that's a single io memory access (several clockcycles). Extraction into registers using bitlogic is fewer cycles, I think... I don't do low level ASM.
Of course, if you have a custom peripheral interface IC, then it could do all this bit-field decoding 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.
ABCD 0DIR = 0-7 clockwise ABCD 1000 = No direction ABCD 1001 = Impossible direction RL ABCD 1010 = DU.
Without this bitfield translation, as seen in my schematic: RLDU DCBA, or something like that. One would mask out RL (MSB) and check just that for 9th button detection. Note that it's possible that down or up are held by the player while pressing 9th button, so at most another impossible direction button can be added... DU. Those bits could be used to indicate "Not a standard joystick" - treat bitfield as device type & shift count? Some devices might use several chained shift registers.
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.
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. Don't mind 3 button only controllers... I think I prefer less buttons actually. My old brain can't handle four -:- buttons and then shoulder buttons, etc. If B is the most common button I think I'd prefer having the tip of the thumb on it, rolling up to C or to A with the joint. Hard to say without testing though.
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 mirrired!).
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.
|My List (40)||Official List (30/40)|
Some comments to go with that: Monster World 4, Castlevania 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, 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? Alternatively, this slot could be 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! Road Rash III... 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. 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 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.
Wonder Boy in Monster World pixel-overs using the original palette.
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 was used for the Hu-Cards, which were ROMs, except the The system/arcade cards which could also include RAM. The second MB was mostly unused, except near the end. The PCEII/SuperGrafx only had 4×8kB (3 extra pages) there, and some hardware I/O at the very end. I think it might be possible to squeeze in more RAM somewhere in the range. 640kB ought to be enough for anyone.
With the SuperGrafx, intended to be the PCEII, they quadrupled the work RAM but it was still only 32kB, which means only 8kB in the original. Having programmed microcontrollers, 8kB is quite a lot, but games tend to eat it up when doing pathfinding and other heavy stuff. Strangely, just adding another graphics chip (dual) into the SuperGrafx was possible, enabling layered effects.
The original PCE was quite competent for its size due to ASICs/consolidation. Both the TurboGrafx & SuperGrafx were needlessly huge. My version here uses 210MB 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 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. either.
As usual, it'd 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 too.
On the Amiga, graphics manipulation was tedious blitting/scanline work 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 is probably accessed via narrow ports and memory blocks. This would perhaps have made the latter system more beginner friendly for programming games with scrolling and sprites.
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 PC 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 despite apparently not being very good.
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.
FM Towns Mini.
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.
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?