For this fantasy console project I wanted to do something a bit more realistic than my Famicube in terms of hardware availability, as well as IP access.
Here I'm hoping to get away with using mostly off-the-shelf components, close to what the later versions of the SMS had, with FM sound and extra VRAM. At a glance it might seem possible to build this thing from salvaged parts, but in practice I think there are some quirks to their slightly customised chips which makes it hard. My system has a different Z80 processor, more RAM, a floppydrive* instead of ROM, and a different peripheral system.
*The SMS almost got a 3.5" FDD addon, but it didn't happen.
With so few games coming out for the SMS, it was never really pushed to its limits (or getting those rare lucky hits). I think the 16+16 colours restriction is quite enough for doing really nice stuff, and in a way it's close to my Famicube design in terms of colour count per sprite, as you're not likely to make use of all 16. Maybe 5-10.
It could be interesting to give certain SMS games a second chance by porting them to a slightly beefier, but similar system, and tighten up the graphics on level 3. NES IP is tougher to work with, as it's still in use and has great-grandchildren in terms of sequels and remakes. SEGA had to develop a lot of the great games on the SMS themselves.
I've been iterating the design to make it more injection moulding friendly, and managed to make the sides reusable like the top and bottom, making it... 3 faces total now, t/b, l/r, front (plus some smaller pieces, joypad etc). Machine-bent metal for the cage but I suspect that's a lot cheaper than injection mould tooling.
However, I need to rethink the interior. A SoC will fit but certainly not through-hole discrete ICs like I had envisioned. SOP might though, with a 4 layer board, but it's less... interesting to look at and visually troubleshooting traces is harder. I probably need to yank out the PSU and use a multi-board system.
My slim USB FDD stood model. Unsure about system architecture, need to read up on it again. CPLD bus/mapper? HDMI I do not like. However, a disadvantage with older signal types is that they have to be processed and upscaled by modern TVs, introducing minor (but apparently noticeable to gamers) delays.
Older concept with card slot. Mark II colours.
It was not uncommon back in the day for floppy disk drives to rival the host computer itself in power. Most likely, the only available floppy disk drives these days are USB ones, which probably means that I might have to resort to using a modern MCU (microcontroller) as an I/O interface. This MCU could control the drive, LED indicators, mode-switches (if any), joypads, and possibly serial flash memory.
Other the MCU, I'd like the system to reflect the design of a late '80s computer. I'm not sure how to integrate all of the components. It was often done using a gate array of some sort back then. Maybe a small CPLD is what makes sense now. FPGAs are expensive and can easily "emulate" the entire system, making it pointless. A cheap ARM chip could emulate the system in software but it's really only attractive as a (very) economical solution.
Zilog is still around making processors. It might be possible to use one of their off-the-shelf products (e.g. Z80180) as the main processor, preferably something with an MMU allowing for more system memory. However, their later Z80 variants have some modern features which are superfluous.
It appears Zilog also offers some sort of custom on-chip ROM feature, and more advanced SoC type customisation. Having an onboard VDP and audio capability is maybe a possibility, but it'd be expensive of course. The VDP is very likely still not in production so that chip will have to be made, in which case it could be given some extra features like better VRAM access and maybe a new mode.
Because this system uses the cheaper, more dynamic and fun floppy disks, and not ROM cartridges, it will need "a lot" of RAM, which is now cheap and also opens up fun game design possibilities.
Reading the Z80180 datasheet, I noticed that it has dual channel DMA capable of maybe 10-20Kb per frame, whatever that means for brute force bitmap modes I don't know. 20 address pins courtesy of MMU, so 1Mb range. 4k pages. Unsure if bank switching is a hassle or not.
There's some advantages to having uncontended VRAM for a tilebased VDP which then runs fairly independently. Easy to change the display with just a few bytes sent. For bitmap/screen type modes where the pixels reside in work RAM, contention is an issue. VRAM might be bottlenecked
The Z80180 (a somewhat arbitrary choice by me) has a DRAM controller. I think SDRAM is what's in production now (does not need to be refreshed), and it's actually hard to find in small sizes like 1 meg or smaller, so there's a potential problem. I don't want to put more in a machine which can't address it. Unit price is pretty much the same for any size but this project is not exactly aiming for performance per buck.
Game distribution on floppies is perhaps insanity, but it's a charming sort of insanity. Floppy disks do work well with the homebrew market, but that won't take off unless the console is interesting. It should definitely come with built-in software and perhaps bundled games on disk so it's not just a dead box. It needs the momentum. I don't think people would be interested in having to buy a physical game or two on top of the console when it's such a niche product.
I thought a lot about what kind of games would make the most sense. It's not the '80s anymore. There are plenty of great games out there, including old ones via emulation (legal or not). This rules out a lot of games. I came up with a list of criteria to meet:
Now a list of some SEGA titles to refresh the memory:
Action Fighter Alex Kidd Alien Syndrome Altered Beast Bonanza Bros. Golden Axe Golden Axe Warrior Fantasy Zone Master of Darkness OutRun Phantasy Star Psycho Fox Psychic World Quartet Shinobi Sonic Space Harrier Wonderboy 3 Zaxxon Zillion
When I tried to evaluate these games, I ran into trouble. I think I'd like to play polished versions or sequels of certain games, but I still think I'd lose interest after a while. One solution is to come up with an original name, based on these IPs, but that would be costly. Also, I think the VDP would not be up to snuff for some of my ideas:
|Psycho Zone Universe||-||An Elite Frontier-like, low poly game using characters from Fantasy Zone, Psycho Fox, etc. Fantasy Zone is an interesting shooter. I like its general idea with the freedom of movement, store, colourful graphics and dark story. This game has a lot of interesting worlds and enemy designs which would work nicely as a theme. I don't like playing space shooters with a joypad/stick however.|
|Monster Zone||A more open-world Pokémon style game where you catch monsters from the various SEGA franchises. I think the Pokémon games are a bit too linear for my taste. Many people come up with special self-imposed rules, or hacks to make replays more fun and challenging. Quite doable graphically and works with a controller.|
|Phantasy Command||-||I sketched a bit on a Phantasy Star X-COM style game a few years back. But, X-COM ran poorly even on the Amiga 1200 so it'd have to be something more akin to Laser Squad in looks.|
|Rogue Star||A Diablo-like would have to be pretty primitive graphically and sound-wise, which might kill the atmosphere. Some sort of rogue-like using Phantasy Star as a base could work quite well though! There re probably good code bases out there to work off too.|
|Alien Syndrome 3D||-||Whilst the setting is a very good fit (Quartet too), this would require a new screen mode and would still run like molasses.|
|Fantopia||-||A stress-free, semi-realtime colony building game like Utopia on the Amiga could be interesting, coupled with the Fantasy Zone setting which has neat alien terrain. Could sneak in some farming mechanics here.|
|Golden Heroes||-||Heroes of Might and Magic with Golden Axe characters. Maybe the original bestiary is too small for this to work. As an older person I like the tempo of these kind of games, and they might run fine on a weaker system.|
It's nice to have immediate access to a creative playground. Solitaire and Space Cadet Pinball were not the best PC games, but they were there, just one click away and didn't put demands on us. In a way, the same goes for BASIC on '80s computers. Just type some silly lines and off it goes.
I had some idea of using a physically small serial flash IC, which is accessed via the MCU. The data is loaded into RAM and it will probably be somewhat quick for smaller programs. Here are some top-of-the-head ideas and my thoughts. I'll tag my favourites with a spinning star gif from the '90s world wide web.
|Columns?||...or another puzzle game. The advantage with puzzle games is that they are pretty light to develop once the design is fully known (and hard if not). This is also a disadvantage, because they are easily cloned, and thus won't stay "exclusive" for long.|
|Snail maze||-||...I never played this, but I guess some people are nostalgic about it. It might be possible to mix it up a bit.|
|Solitaire||This sort of card game would be quite easy to develop I suspect. Adding a loot system could be interesting. Win a game and you get a quirky present (e.g. a random image of a SEGA character, card bounce animation, ditty, etc). I think it should not be progress-based though. There's a risk that it adds pressure on the player to collect all the things, turning the game into a to-do chore when it's supposed to be no-strings.|
|Pinball||Certainly more difficult to develop, but not too bad for just a single board or two.|
|Highscore arcade game||And a difficult, short one to wear down over time. My favourite in this category is Robotron 2048, but that's a twinstick shooter and not SEGA's IP. Maybe Alien Syndrome could be modified to play in a similar fashion, with deadly, hectic levels? Smash-TV also comes to mind. In Gunsmoke, combinations of B & A would adjust the aim so maybe that could work in conjunction with D-pad movement.|
|Alex Kidd||This game was bundled with some versions of the SMS. It might need something extra though, such as a graphical update. Having to always start from the same place and replaying the same old levels gets a bit old so some kind of surprise mode might be interesting. In the Mario games, the warp zones allowed the player to explore the game world a little. Perhaps the boss is hiding in a random level and you have to find it using clues or luck? In SMB3, I rarely visited some worlds because it felt like... Bowser was in world 8 anyways. A pity because a lot of the other worlds were more interesting.|
|Light simulacrum of Amiga Workbench / Mac System 7.5||-||
I guess an "OS" could be developed as a bare framework that's really just a window manager for dealing with files, starting programs and showing time. There would be no need for advanced OS features, printer support, etc. Users could then add their own utilities.
But because this project aims to be a little bit realistic than the Famicube, I think having an OS is a pipe dream. Also, window managers work poorly in low resolution, and accessing things via a window manager is not always immediate enough. You need to have the keyboard and mouse out, which takes up space. I don't like this about the RPi. It's a bit of a pain to hook up each time because I don't use it often.
On my MSX HiTBiT, there's a simple boot screen where you can access the various built in features of the system, like calendar, Memo, BASIC prompt, and some sort of tape transfer. You can do some "DOS" stuff from the BASIC prompt of course. On the Amiga 500, you'd boot into a sort of windowed environment if you didn't have a disk in the drive. With a game disk in, you'd boot that, so the system felt a bit like a console.
|Development environment||-||This too would require keyboard and mouse support. I had some idea about using a PS/2 style protocol with primitive support for some hardware. Branded mouse and keyboards could come later. I wrote about this sort of built in development environment on my Acorn page. It'd include a simple pixel art program, text editor, tracker/sound editor, hex editor, memory inspector and file manager. A modern BASIC would be really interesting to me. Compiling and editing is perhaps better off on a modern computer due to text space and compiling speed. A BASIC dialect can be just as fast as C, with a good compiler. Actually, I believe some dialects do indeed use GCC behind the scenes. This style of development is quite accessible and fun to play around with even for people who are not developers. I think much more-so than e.g. RPi development which not even I could figure out.|
Available soon-ish for only _three_ small payments of $100,000 each!
So if the development cost for this is $500,000*, and it sells 20,000 units, that's 25 dollars per unit. For the Parts cost, assembly, packaging, office work... I really have no idea. Maybe 50-100 dollars. So (75+25)+profit might easily put it at over 250 each, if not sold via retailers, but directly to the very scarce demographic, who are:
And many SMS fans are in Brazil. Tough market for foreign tech...
*All cost and time estimates should be multiplied by Pi, so 1.5M. VDP might need to be an ASIC, as it's out of production. It's perhaps a known working design though, and probably simpler than the $0.5-1M people often give figures for.
That said, I have to imagine SEGA backing this for the sake of the fantasy (I mean the whole idea is that it's a SEGA thing). It's a completely different situation from selling random garage-console.
Of course, the likelyhood of SEGA wanting to do such a niche console is... low. But, it's an order of magnitude higher than the chance of Nintendo going for the Famicube (still close to zero though).
Complex launch software could not be made for 100K, as that's just buys like... a man-year of work, only enough to cover the basics. Of course, my idea here is that I use similar hardware to the SMS, so some old titles can be ported or modified rather than being scratch-made. Still, provably looking at a man-decade of work or more in actuality, if there are to be any worthwhile games on this thing at launch.
Looks like SMS pads are very simple: 4 dirs, 2 buttons and a common. Perhaps that's why they worked with the Amiga/Atari. No shiftreg like in the NES pad. I think I'd go for a shiftreg or serial solution here though. Reduces wires. Might need an MCU for system I/O. Apparently the SEGA Nomad d-pad was pretty good but I've never tried it. Might be a more expensive design.
Slightly related, here I'm modifying a USB donor joypad to use a 74HC157D instead, which is a 2 channel, 4-bit MUX. It's for a PCE project. This is different from a shift register type solution where the peripheral controller (or whatever is listening) gets the bits one at a time. The 157 uses more wires though. A PS/2 solution uses the least wires but requires a bit more lifting.
I chose this connector because... it had the right amount of pins and is maybe still in production. It's a 1987 thing so it might fit thematically too. Actually using the protocol could mean easy keyboard/mouse support. I guess the MCU would have to handle if it's to be my peripheral chip.
Sleek MF2HD USB drives are available for 6 quid on China ebay so they were at least in production at some point in recent years. Diskettes are not reliable but I think RAIDing both sides avoids the problem of e.g. dust a little. Also, not using inner tracks. I think it's going to be hard to find non-USB drives, but maybe the USB ones can take a replacement board. Unsure if USB means drive is controlled more indirectly, which could be bad. There are USB host ICs like the MAX3421E but some MCUs might have the capability too.
Basically, if you have a cube sunk into a perfect fit mould, the vacuum will prevent ejection. That's why a NES looks slightly trapezoid
Just having two shallow pieces (less to machine out of steel mould) and squeezing the MoBo in place is very economical.
You also need to think about screw holes, which need to go in the direction of the mould separation, and obviously attach to something. A cube is so thick you might need an intermediate structure inside. Maybe that's why cube designs are less common. The more pieces, the less rigid, and also greater risk of creaking sounds. I tried to be clever and use parts which can be flipped for the other side of the cube. Still, there's the additional assembly cost. Maybe sell as a kit?
I found some service manuals and schematics of the SMS and the later "Jr" / II. I colour coded these to make them more readable. It's very hard to follow in B/W. Orange = Address. Slime = Data. Purple = Joypads. Cyan = Video/Audio... Audio? It seems the ti SN76489 is integrated into the VDP (Video Display Processor/Unit). Graphics are done by a modified ti TMS9918.
It's a shame the SMS II, Gamegear and Nomad had kinda boring case design. The Megadrive looks real nice though. Anyways, looking into what kinda ship consolidation they did for the SMS II... It seems like they moved the joypads to the VDP. Fewer video out options. VDP uses address lines for data as well.
There's some sort of EMI filtering happening on the joypad ports but I don't know much about it. If I were to guess... the joypad cables can act as antennas for the video signal/RF noise, and that's supposed to be contained according to FCC regulations. The joypads connect to the Gate Array. Traditionally, I think a Gate Array does what's called "glue logic" -- tying the system together. That can also be done using a whole bunch of e.g. 74 series ICs which ultimately gets more expensive. Gate Arrays are/were cheaper to make than the custom graphics chip:
VDP FOB price was ¥1182, more than the Z80A at ¥172. Gate Array ¥216. 8K RAM ¥420. ROM ¥645. Yen was not as strong then as now iirc.
For an updated VDP, I'd like to stick with the 16 colour style. Maybe definable or larger though. The SMS palette is okay, but has its limits. It's --BBGGRR. They probably needed an equal amount of bits per colour channel for some reason. A disadvantage with using e.g. 2-3-3 bits is that you get no true greys.
A chunky pixel mode is always tempting to have, but problematic if it has to go via VDP port bottleneck, or the VDP pulls it from work RAM and contends for that, slowing down CPU business (for that mode).
An 8-bit colour space is a bit richer than 6-bit. It seems to me that 4-greens is the worst solution, resulting in a unnecessary subtle hues of extreme and unusable colours. I once did a 3D RGB histogram from a somewhat diverse set of 256 photos, and there's a bias to the histogram shape moving through the cube. I suspect the 4-greens palette (here a simple 3D matrix) covers/hits this shape poorly, resulting in nasty colour-banding when I try to use the palette.
It might also have something to do with... the eye being better with green, and the worst with Blue. So, BBGGGRRR is best? R&G can modify Blue really well, so the blues don't suffer as much as one would think. After some testing: Yes 4-blues version the best, and quite massively so in all categories. BBBGGRRR performs uniformly horribly in comparison. K.O!
Best results would be achieved by discovering a simple function or DAC circuit which mimics this nonlinear, corner to corner distribution/cloud. Basically, certain corners should be less populated. The strict diagonal is gray. As a dirty solution, I've thought about throwing in a matrix (like BBGGGRRR) and then repel all points from each other to fill out the space, but also attract many them towards the weighted part of the 3D histogram. I could then pre-generate a palette from that. However, would be more efficient if the indices mapped automatically though natural means.
When I converted my 256 image collage to the 4-blues palette, I noticed that there were about 25-30 unused indices. Maybe a bit fewer than I had thought. But there were also probably many indices which were barely used (I didn't run a count).
I should add my SEGA art here, pixel overs, sketches, other case mockups. I have a few.
More, stuff, here - ayyy, yo.
Quartet pixel over. The Arcade (now mostly MAME) version is one of those games which looks very washed out without proper gamma/monitor adjustment, but because the SMS palette is quite high contrast and it's not a straight port, it looks okay on there.
The SMS Shadow of the Beast was a bit strange looking I thought, so I did this mockup. It's not a very interesting game (on the Amiga), atmosphere aside. It's probably better utilise the strengths of the platform instead (like NES Rygar did). By varying terrain height, multiple enemies can exist at different scanline heights. The SMS has 16 colours for sprites so 10 could be Beast+HUD, and 6 variable for local enemies. I'd prefer if it played more like Metroid or Rygar, with armour and weapon upgrades. Smaller sprite means more memory for varied actions.