Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Retcon85 project updates (building a Master System clone from scratch...)

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Retcon85 project updates (building a Master System clone from scratch...)
Post Posted: Sat Jul 23, 2022 9:44 am
Last edited by willbritton on Fri Sep 08, 2023 11:09 am; edited 1 time in total
Hey all, it's been a long time in the works, but I'd love to share a personal project I've been working on for some time now.

Introducing the Retcon85 Project

Way back in the early days of the pandemic, in a bid to stave off insanity for both of us, I started teaching my partner the basics of how a computer works. I found an old Z80 gathering dust in my bits box and foolishly said: “I bet we can build a computer of out this”.
Inspired in part by a few other interesting projects out there, we quickly decided it would be a bit of a laugh to build a working Sega Master System clone all with parts still available today.
Over time, for me at least, this turned from a hobby into an obsession, and I saw the opportunity to market this thing as an educational kit for people learning about computers or digital electronics or both.

Pictured below is the second working prototype. The first was mostly on veroboard and used a Raspberry Pi Zero (with no OS) for graphics although I never got the sound working.
This v2 uses a Lattice ICE40HX8K FPGA demo board (specifically an iCEWerx - and it has been an absolute gem!) and implements full HDMI graphics and sound at 640x480. I wrote all the HDL for the VDP, PSG as well as the HDMI layer from scratch in SystemVerilog, based on the incredible documentation on this site as well as numerous industry specs for the HDMI and associated technologies. There were some existing projects out there which had implemented this stuff before, but I couldn’t find anything that would fit my device and it was an incredible learning experience getting so deep into all the protocols.

As well as writing my own BIOS with a small built-in game (Hang On!), I’ve also tested the system with 8 real SMS cartridges so far, 5 of which worked straight out of the box. Of the 3 which don’t I think 2 of them are failing the region check, since I haven’t been bothered to build port $3f yet (soldering fatigue set in…)

Here’s a video link to me playing Sonic the Hedgehog, which I think is the best looking of the working games I’ve tried so far. You can probably tell from the video jitter that it’s interlacing - this is in order to achieve full 480 screen height without buffering each line, although I might look into doing that one day, which should make for a smooth progressive display.

Current status

Right now, I’m working on prototype v3 which is a new mainboard, completely redesigned as a single board and laid out so that learners can build whatever project they like, but if they want to build a Master System clone it should require a minimal number of jumper wires, which are generally the most tedious bits. I’m also putting the finishing touches to a PCB layout for a standalone graphics and sound module. I call this the “Retcon-AV” and in theory it could be used to implement HDMI-enabled graphics modules for many retro systems, not just the Master System, so it might turn out to be an interesting product in and of itself. It could theoretically be used to “upgrade” an original console to HDMI output, and it’s also flexible and capacious enough to support other functionality like acting as a mapper chip, as well as providing some interactive live debugging tools and even as the core of an onboard Everdrive style multi-cart. So far I’ve implemented pretty much everything in Mode 4 of the VDP, but none of the legacy modes. The hardware is much faster than the original TMS9918, and is not subject to the same timing constraints as the original - it can handle a ridiculous number of CPU accesses per frame compared with the original. It can also support significantly more VRAM (my v3 prototype uses a 128KB device - vs. 16KB in the original console - because it’s the cheapest I could source, but could easily handle more) and extending the size of the colour palette is also trivial, even to support full 24 bit output colour resolution. I suspect that it would be quite possible to implement the Mega Drive VDP with this design, but haven’t verified for sure. I’ve not done much in-depth analysis, but the whole system seems to consume between 60-70mA when running an original cartridge game, so it’s easily powered from a simple USB power supply. I’d also love to have a go at adding the FM chip at some point too!

One of the most challenging things this year has been the global semiconductor shortage. For the Retcon-AV I’ve had to change the design considerably so that I can build a prototype with parts that are actually sourceable right now. In particular, I can’t get ICE40HX8Ks at all, but have managed to secure a few smaller ICE40HX4Ks. This means that fitting a full HDMI implementation on the FPGA is a little tight, although it should still be possible. To mitigate the risk here, I’m initially dropping down to DVI (which is way simpler than HDMI but uses the same connector and is still supported by consumer televisions) and adding a DAC onboard, which can be used to output audio via headphone jack. I’m hoping the semiconductor supply problems ease up in Q1 of next year. I’ll also design a crude control pad to go in the kit, although it works fine with an original controller as well as other Atari port compatible controllers (although these are quite hard to find these days).

Future plans

Once I’ve got the v3 prototype in hand and proven (hopefully in the next month or two), I’ll then start work on a Kickstarter campaign to produce and sell a decent run (I guess a few hundred to a thousand depending on interest levels) of the educational kits, and I’m writing a companion book for that in the background. I also plan to open source all the hardware, software and firmware for the project at some point. I’m not sure exactly what cost I will be able to manufacturer and supply the final learning kit for, but at a very rough guess I’d say somewhere between $50 and $100 retail complete with all the required parts, etc.; possibly cheaper at significant volume.

Thanks!

This site and forum in particular have been instrumental in getting me as far as I have with this thing, and it’s been so much fun, so thanks to all here who’ve (probably unknowingly!) inspired me with their general chat, enthusiasm, and questions and answers in particular around that tricky VDP :)
If anyone in this community would like to know more about this project, would like to support in any way or thinks they might be interested in acquiring one of the first kits, I’d love to hear from you and would be happy to field any and all questions you might have about the project!
IMG_7725.jpg (601.16 KB)
IMG_7725.jpg
IMG_7724.jpg (893.24 KB)
IMG_7724.jpg
IMG_7722.jpg (699.03 KB)
IMG_7722.jpg
IMG_7718.jpg (624.44 KB)
IMG_7718.jpg
IMG_7708.jpg (399.14 KB)
IMG_7708.jpg

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Sat Jul 23, 2022 10:07 am
That looks really amazing, congratulations on not only achieving a working system but also being on the way to sharing it with the world.

How difficult would it be to scale it back to a VDP replacement for a real system? This would be the “HDMI mod” needed for modern TVs, but it would mean the VDP pinout would be the interface.

Is the 480i output the only option without adding in the complexities of a scaler? I think we’d like to see 1080p60 for the sharpness…

Did you emulate sprite limits or make it optional?
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Sat Jul 23, 2022 11:05 am
Thanks Maxim!

Maxim wrote
How difficult would it be to scale it back to a VDP replacement for a real system? This would be the “HDMI mod” needed for modern TVs, but it would mean the VDP pinout would be the interface.


Yeah definitely I've thought about a VDP replacement. The AV module I'm designing at the moment is 38mmx86mm to fit into one of the slots on the main board, so it's a bit larger than a wide DIP format, although it should be very easy to design an adapter board that can replace the VDP and stack the AV module on top. I believe the original VDP also did a little bit of the address decoding logic (KBSEL, CSRAM, etc.), so that would need to be duplicated too, and I'm not 100% sure that the system would be super happy about removing the original VDP and leaving the analogue display components without driving inputs (I don't currently have any analogue video capability on the module, although it might not be too hard to make a dual analogue / digital variant), but anyway, a naive look at the schematics suggests it might be possible. I'd love to try it one day.

Maxim wrote
Is the 480i output the only option without adding in the complexities of a scaler? I think we’d like to see 1080p60 for the sharpness…


Technically it's outputting 480p - the interlacing is just a cheap way to upscale 192 lines to 384 - if I have enough resources to buffer each line I can use the progressive display to full effect.

As for 1080p, not sure yet, but probably not. Originally I wasn't even sure how far I'd get with the high speed serial interface needed for HDMI so I went for the lowest resolution possible. 640x480 is essentially a base fall-back mode for DVI/HDMI so all displays should support it without negotiation, and it needs a bit clock speed for the serial interface of around 252MHz (800x525x60x10) which the FPGA (as well as my PCB design skills!) is quite capable of dealing with. 1080p on the other hand needs 1.48GHz (2200x1125x60x10) which I think might be out of the question without bumping up to some more advanced hardware.

Maxim wrote
Did you emulate sprite limits or make it optional?


I've replicated the sprite limits as per the original, although in theory the system should be able to accommodate a fair amount more sprites. In terms of footprint the sprite buffers are one of the highest cost items - they need 5x 8-bit registers plus change for each sprite on the line - so I don't think it can be pushed stupidly far with the device I'm working with at the moment although for sure I can fit more than the standard 8.

The 64 sprite limit can probably be extended more easily - it just affects the timing, which has plenty of room to spare in the absolutely enormous HBLANK period available from the upscaled display. The only thing there is obviously you'd need a different VRAM convention than the original 256 sprite attribute table to hold more than 64 sprites. Given there's that little "gap" of 64 bytes in the middle, it would seem reasonable to use that for another 64 VPOSes and then tack on another 128 bytes of HPOS/index on the end of the table.
  View user's profile Send private message Visit poster's website
  • Joined: 13 Jul 2018
  • Posts: 17
Reply with quote
Post Posted: Thu Jul 28, 2022 11:47 am
Hi willbritton

Good job, really interesting. I would like to refresh the HDL I learnt in my degree because I forgot almost everything…

Have you seen the Mister FPGA project? It is quite aligned with yours.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Thu Jul 28, 2022 12:25 pm
Thanks!

Yeah have seen Mister, it's really incredible, I'm amazed by just how much they've managed to implement, especially given lots of the arcade originals must need to be reverse engineered from scratch by decapping in some cases.

I think Mister is a great choice for people who want to do some serious retro gaming but it's quite an expensive investment. I also saw the mega SG recently and that's also very cool.

The RetCon project is intentionally much more basic than both of those as I wanted to find a system that could be built entirely by a beginner by wiring a few chips together, the only complication being that you can't buy the VDP / PSG off the shelf which is why I somewhat reluctantly turned to an FPGA for that.

Glad you're interested - I'll be happy to share my HDL on Github when it's all tidied up, but I think I saw at least one other project which implements the SMS VDP in HDL so you might take a look around in the mean time.

I've also been thinking more about Maxim's question of a straight up VDP replacement chip for original consoles and think I'll prototype that too, it should be very low cost with everything stripped right back.
  View user's profile Send private message Visit poster's website
  • Joined: 13 Jul 2018
  • Posts: 17
Reply with quote
Post Posted: Thu Jul 28, 2022 10:58 pm
I agree with you. Maxim’s idea about replacing original VDP is quite interesting. Recently, I bought an AV2VGA converter from AliExpress for my new TV (without AV input) but it doesn’t work fine
There are other VGA converters based on FPGAs, but they are quite huge

About the FM chip you have said you would love to add, have you seen the Tim Worthington PCB in the Etim Australian website? The sell a PCB add-on but they also show the schematic and HDL code
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Fri Jul 29, 2022 8:09 am
A similar idea, although more advanced, is the Hi-Def NES:

https://www.retrorgb.com/hidefnes.html

This uses pass-throughs to allow the existing APU to work, just sniffing the bus; and it also sniffs the CPU bus in order to do more stuff on the FPGA like emulate expansion audio. Being a big FPGA it can also do more options for the upscaling.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Fri Jul 29, 2022 8:31 am
That is really cool.

Haven't read through the installation instructions, but looks like there's a daughter board which sits under the original APU. Are those normally socketed in a NES or do you need to desolder it?

They're soldered straight in on an SMS though, right?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 435
  • Location: Auckland - NZ
Reply with quote
Post Posted: Fri Jul 29, 2022 9:52 am
Would 3d support be possible with this over hdmi? I have no idea what resolutions are supported with 3d modes on modern tvs. You would have to alter the way it works as the 3d adapter for the master system controls which eye sees which frame based on the game writing to a particular memory location and the adapter watching that same location. On modern tvs the glasses are synced to the tv refresh rate and then run at fixed frequencies (120hz?) so youd have to buffer the left and right frames and keep feeding them to the tv. Then youd need to update each frame when the memory location is updated. Im guessing that would work anyway.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Fri Jul 29, 2022 9:58 am
wasup wrote
Would 3d support be possible with this over hdmi?


Lols, when I first started reading this I had flashbacks to the "advanced mathematics for 3d polygons on the SMS" chat, but you're talking about 3d glasses, phew!

You know I don't see why not, but would need to look into the technology a bit more. If it's just based on vsync then that is available pretty much right up until the point that the DVI signal is serialized so there should be negligible lag in flipping between left and right, assuming the glasses just need a vsync reference to work.

And I assume it actually halves the frame rate - so at 60Hz one field is for the left eye and one for the right, so it's 30Hz per field.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Fri Jul 29, 2022 10:45 am
Yes - on a CRT, the SMS just blocks one eye per frame and controls what's left/right that way. On a 3D TV - if those still exist? - I guess it's some extra data sent over the connection?

I don't think NES had sockets inside. Perhaps it could be done using a carefully-cut board that would solder onto the VDP legs, similar to the no-wire GG LCD mods?
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Fri Jul 29, 2022 11:00 am
You can get spring clip test adapters for DIPs although they're pretty pricy to pick up.

For sure some kind of board that sits on top of the chip and is soldered onto the legs is doable, if a little fiddly.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Fri Jul 29, 2022 11:07 am
Although actually if we're just talking about sniffing the bus you can do that pretty much anywhere - e.g. on the expansion port or as a cartridge adapter.

The VDP obviously does write some data to the bus (interrupts, VRAM reads and vcounter), but if you've got an analogue VDP running in parallel I reckon you could rely on that to write the state to the bus and shadow the display purely with bus reads.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Mar 2021
  • Posts: 120
Reply with quote
Post Posted: Fri Jul 29, 2022 5:56 pm
On a CRT, only one field is displayed at a time, so the LCD shutter glasses can just say "this upcoming field is for the left eye" or "for the right eye", like:

L yyyyyyyynnnnnnnnyyyyyyyynnnnnnnn
R nnnnnnnnyyyyyyyynnnnnnnnyyyyyyyy

(The existing 3D software for the SMS uses a memory-mapped port at $FFF8, and the lsbit controls which eye is opaque)

Unfortunately, on an LCD, both fields show up during redraw (see the SloMoGuys yt video), and there's only the brief moment around vertical blanking when exactly one field is visible.

Shutter glasses with this kind of display would need to say "right now: left eye is clear. now both are opaque. right eye. opaque"

L yynnnnnnnnnnnnnnyynnnnnnnnnnnnnn
R nnnnnnnnyynnnnnnnnnnnnnnyynnnnnn

Plus HDTVs usually add some fixed unknown amount of delay, not exactly one redraw.

But if you can compensate for both of these effects, I don't see why it'd be impossible
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Fri Jul 29, 2022 7:41 pm
I didn't realise about the software interface but actually that makes it easier right, we don't need to transmit vsync because it's the software's responsibility to flip the eyes every vblank.

lidnariq wrote
Unfortunately, on an LCD, both fields show up during redraw (see the SloMoGuys yt video), and there's only the brief moment around vertical blanking when exactly one field is visible.


Just trying to figure this out, are you saying that there's no period in vblank where the screen is completely blank, and so the timing to switch eyes must either be very precise to coincide exactly with the frame switching, or we need to insert a short buffer period where both eyes are off to increase the timing tolerance?
  View user's profile Send private message Visit poster's website
  • Joined: 05 Nov 2014
  • Posts: 435
  • Location: Auckland - NZ
Reply with quote
Post Posted: Fri Jul 29, 2022 7:52 pm
I believe the video thats sent to the tv is 2 frames either side by side, or one on top of the other. The tv decides which frame (left eye or right eye) is shown and tells the glasses what to do. There must be some control protocol embedded in there some how to tie it all together so the tv can match the actual video data. The glasses themselves work differently depending on brand and type but there are sync pulses involved and the timing is fixed. Dont quote me on all this though..

On the master system as its software controlled via the 3d interface the timing might not be exactly 50% left vs right and its a bit crude so its probably good enough to work well enough given the technology of the time
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Fri Jul 29, 2022 11:22 pm
I think the point is that the SMS shutter glasses would have a hard time syncing with a modern display technology because they don’t work by persistence of vision (and also aren’t timed exactly by the signal produced by the SMS). However the print for 3D is to use the TV’s own 3D capability and glasses to do the shuttering, then all you need to do is get the TV to know about the left/right images coming from the SMS. That may still need to be buffered up to 120fps or a side by side image or something.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Mar 2021
  • Posts: 120
Reply with quote
Post Posted: Sat Jul 30, 2022 5:38 pm
willbritton wrote
Just trying to figure this out, are you saying that there's no period in vblank where the screen is completely blank, and so the timing to switch eyes must either be very precise to coincide exactly with the frame switching, or we need to insert a short buffer period where both eyes are off to increase the timing tolerance?
Stronger than that: I'm saying that on a modern LCD TV, there's no moment at all when the screen is dark. In slow motion, you just watch the new row of pixels rolling into the screen from top to bottom.

Here's the relevant bit of the youtube clip I was talking about:

You'll note that there are moments when the screen isn't changing at all. You might be able to get away – if you can handle the unknown amount of delay thanks to the HDTV – with shortening the amount of time each eye sees the screen through traditional 3D active shutter glasses, so that these moments of rolling updates aren't visible at all.
  View user's profile Send private message
  • Joined: 12 Jul 1999
  • Posts: 891
Reply with quote
Post Posted: Thu Aug 04, 2022 12:32 pm
Would it be possible to output to a 3D TV in the correct format, though?

...not that anybody has those anymore...
  View user's profile Send private message
  • Joined: 24 Mar 2021
  • Posts: 120
Reply with quote
Post Posted: Thu Aug 04, 2022 5:17 pm
Seems likely? I don't know if "just" sending a 1280x480@50/60Hz frame will do the right thing or not.

It looks like https://github.com/hoglet67/RGBtoHDMI should provide enough power to sample, upscale, and then merge pairs of fields.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Thu Aug 04, 2022 9:33 pm
Oh that's a nice project, hadn't seen that before!
Looks like video only though. As I said in my initial post, I had a working bare metal Pi Zero solution PoC but without audio. I know it's technically possible but hard to find docs / examples on how to approach it. My best guess was trying to reverse engineer Linux drivers but that was tough going.

The original pi zero is borderline not powerful enough to deal with the full emulation task, I had to optimise the code quite heavily and go to max clock rate to get the video alone working. The newer models should be more than capable but finding a supply is tough right now.

I/O speed is almost a problem on at least the early pi zero as general consensus is you can top the GPIO out at 1MHz. To be properly responsive I reckon you'd need some external 8 bit registers, at the very least to buffer reading from the status and data ports which on orignal hardware are instantaneous. At the time I just asserted the ~WAIT line to stall the CPU until the pi caught up, which actually worked pretty well but it didn't feel like a great solution and it did noticeably slow the responsiveness down for VDP intensive games.

Out of curiosity in terms of 3d interest, I'm not quite clear, are most people interested in playing SMS games on a native 3d TV, rather than getting the original sega 3d glasses working with modern TVs?
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Thu Aug 25, 2022 10:52 pm
Quick update on this project

After what seemed like an infinite loop (pun intended) of revisions, the next set of board designs have finally made it to the supplier for prototype production.

Attached are some 3d renders by way of sneak peeks.

Project board

The main project board is around 230x170mm, and separated into 9 "modules", each of which is connected to the common bus. The module in the top right hand corner has some extra pins to accommodate the retcon-av module for AV out and other stuff. The board is intentionally pretty generic, although there is the obvious SMS-compatible cart slot at the top as well as two break-outs at the bottom for control pads. There is space for four push switches on the bottom edge, which could be general purpose, but as an SMS clone two could be wired as the pause and reset buttons. The silkscreen is also Z80 specific, although the bus is theoretically unopinionated.

On a whim, I designed the layout of the project board so it could be mounted in a PC case (I can't remember which of the many confusing formats, maybe micro ATX); but it can also be used standalone, with some rubber feet or maybe in a nice acrylic mount or something.



AV board

I actually designed two slightly different versions of the retcon-av board – one with a micro-HDMI connector next to a micro-USB connector; the other with a regular (type A) HDMI connector and no USB connectivity at all. I'm going to see which one I think is more practical. The ones pictured here are slightly earlier revisions of the one with the micro-HDMI and micro-USB. Otherwise the board is absolutely packed with components (there are loads more on the back side) not all of which actually need to be mounted. There is capacity for HDMI, USB (except for as noted), SD/MMC as well as 3.5mm stereo audio out via an ADC with built-in headphone amp. I/O-wise both these prototype boards interface the full Z80 bus, and should support bus control so that the board can be used to reflash ROMs in-situ so that you don't need an external programmer. There's also an SPI-bus on the extended connector, which can be used to reflash the FPGA as well as, in theory, allowing a general purpose serial I/O interface including direct access to the SD/MMC (with appropriate level shifting).





I've also attached an "artist's impression" of the whole kit assembled with components necessary to implement the SMS clone, although without indicating any jumper wires:



Other developments

In the meantime, I've been working on a BIOS which will serve the purpose of being a portal into the system, a place to run some diagnostics from, and boot cartridges, and also potentially as the core of a practical tutorial on writing some software for the system one step at a time.

So far it's a splash screen, a basic cartridge diagnostic screen, a diagnostic screen for port $3f (needed while I tested building it – that I by chance happened to have a Megadrive controller plugged in during that episode cost me many hours of confusion!), and also the ability to detect and identify TMR Sega carts from a database, which is a bit of a gimmick but I think the user experience is quite special. Any games built into the BIOS can be launched from here too.

The BIOS actually does work, but I can't be bothered taking photos of my TV right now, so I've attached some screenshots from it running on Emulicious to give a rough idea of what it looks like.








bios_port3f.png (13.95 KB)
bios_port3f.png
bios_cart.png (10.9 KB)
bios_cart.png
bios_main.png (10.96 KB)
bios_main.png
bios_splash.png (17.2 KB)
bios_splash.png
retcon-pb-stuffed.png (602.17 KB)
retcon-pb-stuffed.png
retcon-av-plan.png (168.29 KB)
retcon-av-plan.png
retcon-pb-empty.png (640.49 KB)
retcon-pb-empty.png

  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Fri Aug 26, 2022 3:11 am
what an awesome work!!
  View user's profile Send private message
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Fri Aug 26, 2022 7:52 am
Love it !
Very impressive work.

PS. do not trust headers. Better to use a database of checksums it will be more reliable as many japanese games have literally no header.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Fri Aug 26, 2022 8:09 am
Thanks both!

@ichigo yes, absolutely, playing with crc is somewhere on my long list as are handling SDSC headers.

For now the cart recognition is a bit of extra jazz but not necessary to boot to carts, it just says "Play unrecognised cartridge" instead.
  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2013
  • Posts: 384
  • Location: Osaka
Reply with quote
Post Posted: Sat Aug 27, 2022 8:01 am
An option to keep the loader code small may be the following. When a rom needs something special (say, a non sega mapper) there's a ".ini" file with the same name. The rom listing program checks the fat's hidden attribute, and does not show hidden files (which anyway you need to do to hide the volume label). All ini files have the hidden attribute set, so they do not clutter the rom listing. At the same time, if new games surface, you do not need to update the "bios" code, but just, possibly, need to add the corresponding ini files.

I automated the creation of such ini files. They are generated using meka.nam (from Bock's meka) database. I just uploaded the code to github

https://github.com/fabiodl/mekarenamer
If you invoke
python3 mekarenamer.py sourceDir outDir

the script searches roms (recursively) inside sourceDir and places them in outdir using the names specified in meka.nam.
ini files are generated together for "non standard" roms. .ram files are also generated for roms that have save ram.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Sat Aug 27, 2022 9:12 am
That's really interesting, @kamillebidan, I'll take a proper look at some point!

To clarify, at the moment I don't have anything as sophisticated as an external file system with ROMs, like an Everdrive. Right now it's simply able to boot physical Sega carts and detect and identify them from a relatively compact database on the BIOS ROM, so for that I don't need to know anything about the mapper or on-cart RAM etc. naturally.

But the retcon-av does indeed have the capability to act like a mapper, as well as interfacing with an SD card so it should certainly be possible to use it like an Everdrive. I'm not totally sure yet about provisioning on-cart RAM for soft carts. It depends how much the cart needs. The FPGA I'm using on the prototypes has 8KB of RAM and I'm using some of it for the color RAM and I also anticipate I'll need some more for various things like full line doubling so I reckon there might be 4KB left.
My understanding was that very few games use on-cart RAM so tbh it wasn't something I was thinking too seriously about.

Your ini metadata system is definitely a good idea, and I had similar thoughts about how to capture cart specific requirements, so would love to come back to this one day for sure.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Sep 05, 2022 12:12 pm
:D





  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Thu Sep 08, 2022 8:14 pm
Day 2 of assembling first prototype board - managed to get the FPGA programmed and blinking!

Videos:
https://photos.app.goo.gl/WXuksVkDPUn22NLE9
https://photos.app.goo.gl/BguTPick5fTfky8o9

Have soldered probably half the components on the board at this point, and testing as I go. My SMT soldering technique has come on considerably in the last couple of days and am now wishing I went for the even smaller 0603 parts rather than 0805 :)

I thought disaster had struck yesterday when I realised that one of my two alternative board designs for the AV module was totally non-functional, due to a mistake while I created the panelised design (i.e. multiple PCBs on a single large panel). Lesson learned: if you don't think you've checked your final gerbers too thoroughly, then you haven't checked them thoroughly enough. Very lucky that I had two designs and luckier still that I only f*&ked up one of them! It's the variant with the USB connector which doesn't work, so I won't be able to prove that yet. Will have to get ROMs on the system via SD card (or hey, I could bit bang controller port! ;) )

Other than that, only 2 mods needed so far to correct mistakes, which I feel is pretty good going by my standards.

I also ran out of isopropyl alcohol so feel very ashamed that the board is covered in flux stains for the video :/

Planned next step: solder the HDMI connector on already and plug it into a screen with a test pattern!

(EDIT: also the first opportunity I had to verify that the FPGAs I very reluctantly ordered from a Chinese aftermarket vendor actually work. All official stockists have been sold out for months and I paid around 3x their retail value to get five of them from this place. All the other Chinese vendors stuck another zero on the end – a total non-starter – so I was suspicious of these "cheap" ones, and very glad indeed that they seem to work!)
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Tue Sep 13, 2022 12:25 pm
willbritton wrote
Other than that, only 2 mods needed so far to correct mistakes, which I feel is pretty good going by my standards.


Definitely spoke too soon, as I found a major fault with the HDMI connector. Somehow, either by downloading a bad schematic symbol or – much more likely – mistakenly reusing the symbol for the micro-HDMI connector for the regular type A connector (the pinouts are different), I got the pinout completely wrong. Worked around for now by wiring up a little female to female adapter from two HDMI breakout boards I had lying around and finally proved DVI video with a test pattern!



What is even more exciting, the quality of the electrical signals is much better than with the icewerx development board I was using before, so that my portable Asus screen now accepts the signal and displays a clean picture.



This last picture proves the core VDP actually works – I took a dump of VRAM from my BIOS splash screen running on Emulicious, and then initialised onto the FPGA onboard RAM, with some modified initial VDP register values. I don’t have the I/O working yet, so it can only display a static image from VRAM. Since I haven’t installed the external VRAM yet and there is only ~10KB of RAM on the FPGA, I limited the VRAM to 4KB and set the name table and the sprite attribute table to be further down than the usual defaults.

I am also now able to store CRAM in the FPGA onboard RAM, which saves a good number of much needed logic registers and – most excitingly of all – this also frees up enough onboard RAM to implement full line doubling, which you can clearly see here with a closeup photo. This is the first time I’ve seen the AV drawing non-interlaced double-height images and I must say I think it’s a thing of beauty. I have easily enough RAM to run line doubling for lines of the full 640px resolution at 24 bit colour, although obviously I only need somewhere between 256 and 320px at 6 bit colour for SMS graphics and, as it happens, that’s what we’re seeing here for now.



Next on the list is testing the external VRAM which should allow the full 16KB needed for the SMS VDP to run. For a laugh I might also play around with a frame buffer, I should be able to display a 15 or 16 bit image at 256x256 with the 1Mb device I’m using, which should be enough for a nice picture of my cat or something :)
closeup.jpg (1.28 MB)
closeup.jpg
vdp.jpg (447.12 KB)
vdp.jpg
test_pattern.jpg (412.04 KB)
test_pattern.jpg

  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Tue Sep 13, 2022 2:00 pm
Your cat scratching its head suits the situation quite well :D
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Tue Sep 13, 2022 2:27 pm
Calindro wrote
Your cat scratching its head suits the situation quite well :D

If I'm honest she's not the best helper. I'll take head scratching over chewing the cables any day.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Sun Oct 23, 2022 4:02 pm
Much faffing with CPLD's later...

AV module working :D



This is with the new AV board connected to the old prototype base system, and I'm really playing Shinobi from a cartridge here, albeit with no sound as still need to finish that off.

Next step: build up main project board so I can demo the system as it would look like when finished, then I should have all the demo-ware I need to start thinking about putting a funding campaign together...
av_shinobi.jpg (94.28 KB)
av_shinobi.jpg

  View user's profile Send private message Visit poster's website
  • Joined: 16 Oct 2022
  • Posts: 41
Reply with quote
Post Posted: Sun Oct 23, 2022 10:17 pm
Wow, what an incredible project. I wouldn't know where to even start with something like this! I'll absolutely contribute something to the kickstarter when you get there Will.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Oct 24, 2022 1:15 pm
Mondo wrote
Wow, what an incredible project. I wouldn't know where to even start with something like this! I'll absolutely contribute something to the kickstarter when you get there Will.

Thanks so much for the kind words @Mondo! I'll make sure to keep people here up to date as and when the kits finally become available...
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Nov 07, 2022 12:41 am
Last edited by willbritton on Mon Nov 07, 2022 9:18 am; edited 1 time in total
Update on 6th Nov 2022

Finally got to the stage of getting a cart working on my first trial assembly of the project board. The only thing missing at this point from a fully compatible SMS clone is port $3f - there are two more chips to go on to implement that.



All the carts I have work except for California Games, which I think is region locked, and for some reason GP Rider doesn't work properly, the graphics are all over the place. I'm sure it worked fine on the first prototype. Interestingly though, Hang On now works perfectly, whereas the cart didn't work properly on the first prototype, even though the same code did work when running from the onboard ROM.



Just one fairly minor error on the project board - I had half switched ~M1 and ~RST around at some point, so the AV board was inconsistent with the top silkscreen on the project board as well as the SMS cart connector, so I had to do a small mod near the cart connector to correct that.

Observations on assembling the project board

I had previously put a great deal of thought into how to lay out the project board so that soldering the project wouldn't be discouragingly onerous for beginners, or those not hugely enthused by soldering. I'd say that this goal was partially achieved - the RAM and ROM go on very quickly, and the Z80 goes on quick to start with, but then needs a fair amount of fiddling around to get half the pins on the bus. The address decoding logic is really quite torturous, even though there aren't really so many wires to hook up.

As can be seen in the photo, I did all the wiring on the top side of the board, as personally I really like to see all the wiring. I also try to make it look relatively aesthetically pleasing by routing the wires round the chips more or less orthogonally. However, I reckon it might be a lot less difficult "in real life" to wire on the bottom of the board, since then we can wire point to point without needing to negotiate components, and also there will be more pads available as currently a fair few are underneath the IC sockets, necessitating the occasional doubling up of wires on pads.

So I'm going to do another run at the project board, this time wiring on the bottom and trying to avoid any doubling up on pads. I'm going to time it too, to get an idea of how long it might take a real user. After that I'm going to pass the third board onto my partner and get her to follow the instructions to see how easy she finds it!

One other thing I'm maybe considering is designing some "adapter boards" to make it easier, for example there could be a Z80 adapter board which sits on top of one of the module slots like the AV does, so the user can just solder the IC and other components on and no wiring needed. Will get some feedback on the generic project board first though.

I'm also thinking of adding provision in to map A13, which would allow, for example, faithful mirroring of 4KB of RAM like in the SMS if desired, although I think someone asked the question here recently of whether or not any games actually depend on mirrored RAM and it sounded unlikely. In practice, no change is really necessary to add another A13 line, only a silkscreen change. On reflection, there are several lines currently on the silkscreen which really don't need to be on the bus, since they are only used for one interconnect, or none at all.

Tutorials

I intentionally assembled the board in logical steps, pausing at various points to introduce some electronic & programming tutorials.

It's still very much a work in progress right now, but for those who are interested here's a rough order of service:

1. Practice soldering on some easy stuff, so the sockets and headers needed to plug in the AV module, the mini USB power socket, main power switch, power LED and resistor.

2. Mount the Z80 CPU (and probably the 5 pullups for ~INT, ~NMI, ~BUSRQ, ~WAIT and ~RST). At this point I think the AV module should be able to act as a debugger unit and demonstrate the CPU attempting to read memory, although none is connected yet.

3. Mount the ROM. At this point we can write a hello world program and use the AV module to program the ROM and run it. I've actually got a 64 byte machine code program written which prints "Hello, World!" on the screen, I thought that would be a cool place to start as it's as low level as it gets. The program actually relies upon the AV module pre-loading a standard font into VRAM so no tile loading is necessary.

4. Transition from machine code to assembler with the same hello world program. I was considering going via some relatively simple assembler before hitting WLA-DX but in retrospect I think that complicates things.

5. Mount the RAM, and some minimal address decoding logic to support. Interestingly both the ROM and the RAM are far more capacious than the SMS memory maps allow for, so at this point only a fraction of their address space is accessible. The AV module acts as a mapper for advanced usage much later on.

6. To demonstrate RAM I've written the beginnings of a Pong game, at this stage it just bounces a ball around the screen. Here we introduce basic usage of RAM (tracking ball position and direction) and also interrupts (to time the animation). I'm going to gloss over subroutines at this stage, although the addition of RAM technically makes them possible, as well as that interrupts effectively require RAM to fully work for the same reason.

Video of bouncing ball

7. Mount the player 1 joypad port and associated logic to support. Just two more chips to allow this, so it's easy enough, and here we add to the bouncing ball a moving bat on the left hand side of the screen, so it's starting to look quite Pong-like! The ball still bounces off the walls but you can pretend it's bouncing off the bat!

8. Mount player 2 joypad port - just one more chip needed here. Add another bat on the right hand side of the game.

9. Here I was going to basically finish the Pong game in assembler, at some point introducing subroutines along the way, and then I was thinking of transitioning over to C to demonstrate how a higher level language achieves the same results with notably easier development experience. Haven't 100% decided this is the right stage though yet, and haven't yet written the tutorials at this point. I will also need to probably explain the VDP much more thoroughly, and of course to demonstrate the PSG at some point too.

Note that at this stage the hardware is effectively complete - an enterprising learner could write pretty much anything they wanted. The system has a whopping 512KB of RAM, 256KB of ROM, mode 4 VDP (TMS9918a clone), PSG (SN76489 clone) and two read-only joypad ports for two player games. Also the CPU is clockable up to 10MHz, with the configuration menu on the AV module being able to adjust the clock speed.

However, at least one more set of hardware steps are necessary to play original SMS carts:

10. Mount memory selects (port 3e) and associated modifications to address decoder / io decoder logic. Mount the cartridge connector and wire up the 7 additional lines it needs (~CE, ~CONT, ~KBSEL, KILLGA, ~MC-F, ~M0-7, ~M8-B). KILLGA also needs a pull-down resistor.

11. Somewhat optional, mount port 3f which is, I believe, the final hardware feature needed for full SMS support (excepting FM chip for now); needed for a few games that do region checking and also to support peripherals other than read-only SMS joypads.

Next steps

I'll get the sound working again (need to fit it into the smaller FPGA) and then I can start recording proper videos. Otherwise, I think it's at the stage now that it photographs well, so I can start building up some content ahead of a launch campaign!
retcon-pb-asterix.jpg (521.76 KB)
retcon-pb-asterix.jpg

  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Mon Nov 07, 2022 8:16 am
Doesn’t almost every game rely on RAM mirroring to allow reading back from $ffff to work?
  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Mon Nov 07, 2022 8:18 am
Superb !

Patiently waiting for the ultra compact revision ^^
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Nov 07, 2022 8:27 am
Maxim wrote
Doesn’t almost every game rely on RAM mirroring to allow reading back from $ffff to work?

Don't think so - without mirroring so long as you write to $ffff and read from $ffff you should get out what you wrote in. It assumes the mapper and the RAM both decode the same addresses on write.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Nov 07, 2022 8:30 am
ichigobankai wrote
Superb !

Patiently waiting for the ultra compact revision ^^


Aha! How compact would you like??

Technically I think there's room to implement a whole SMS system on just the AV module with a soft Z80 core but where would be the fun in that!? Certainly could be an exercise for the reader...
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14683
  • Location: London
Reply with quote
Post Posted: Mon Nov 07, 2022 8:53 am
willbritton wrote
Maxim wrote
Doesn’t almost every game rely on RAM mirroring to allow reading back from $ffff to work?

Don't think so - without mirroring so long as you write to $ffff and read from $ffff you should get out what you wrote in. It assumes the mapper and the RAM both decode the same addresses on write.

I guess some games could mess around with reading back from $dfff or writing to it which your “readable mapper register” wouldn’t support… but I don’t know of any examples.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Nov 07, 2022 9:02 am
Maxim wrote
willbritton wrote
Maxim wrote
Doesn’t almost every game rely on RAM mirroring to allow reading back from $ffff to work?

Don't think so - without mirroring so long as you write to $ffff and read from $ffff you should get out what you wrote in. It assumes the mapper and the RAM both decode the same addresses on write.

I guess some games could mess around with reading back from $dfff or writing to it which your “readable mapper register” wouldn’t support… but I don’t know of any examples.

Certainly possible but I would have thought unlikely - you can only write to the mapper at $ffff so can't think of any reason to wanting to create a second address definition to read back from.

Funny, I was sure I was reading a thread on here recently about this but can't for the life of me find it now. Maybe I dreamt it...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Nov 07, 2022 10:47 am
willbritton wrote
All the carts I have work except for California Games, which I think is region locked


Region locked? It might be trying to identify the region but I don't think it's locked. Also, can you switch 50/60 Hz?
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Nov 07, 2022 11:08 am
sverx wrote
willbritton wrote
All the carts I have work except for California Games, which I think is region locked


Region locked? It might be trying to identify the region but I don't think it's locked.

Yeah maybe it's something else, I was just under the impression that some games wouldn't work at all unless they could do a region check, and on the last prototype I vaguely remember I couldn't get all the games working until I'd built port 3f.

sverx wrote
Also, can you switch 50/60 Hz?

Nope, it's 60Hz only, because that's the refresh rate for 640x480 DVI and there's no 50Hz mode at that low a resolution.

To be honest, I feel like of the two possibilities, 60Hz is miles better than 50Hz as it's my understanding that most if not all games were written for 60Hz.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Nov 07, 2022 11:11 am
willbritton wrote
60Hz is miles better than 50Hz as it's my understanding that most if not all games were written for 60Hz.


Unfortunately there are a few games that do require 50Hz to run properly.

(also, California Games II is in the list )
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Nov 07, 2022 11:16 am
Oh that's interesting - thanks for that link!

I have both Sonic 2 and Xenon 2: Megablast and both seem to work fine on this setup, although I'll warrant I feel Xenon 2 can be mildly glitchy, not sure what it should feel like on the real thing.

I've definitely had California Games working on the other prototype so I don't think it's the refresh rate.

EDIT: it may be the reason that those games only work well on 50Hz is that they are pushing the VDP timing constraints, which just don't apply on my AV module because it's so much faster than the original hardware, so that might explain why they seem to work. Another difference is that my system clock is ever so slightly different from both the original PAL and NTSC system clocks, although that's less likely to be significant.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3758
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Mon Nov 07, 2022 12:00 pm
willbritton wrote
it may be the reason that those games only work well on 50Hz is that they are pushing the VDP timing constraints, which just don't apply on my AV module because it's so much faster than the original hardware, so that might explain why they seem to work.


yes, some require a longer vblank and would write too quickly to VRAM outside of vblank at 60 Hz, creating image corruption on the real hardware - in your case of course that won't likely happen.

California Games TWO is in the list, not the first one anyway.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Jun 2010
  • Posts: 757
  • Location: Pennsylvania, USA
Reply with quote
Post Posted: Mon Nov 07, 2022 2:01 pm
Looks great and you're doing an awesome job. Can't wait to see the finished product!
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 593
  • Location: London, UK
Reply with quote
Post Posted: Mon Nov 07, 2022 5:22 pm
Maraakate wrote
Looks great and you're doing an awesome job. Can't wait to see the finished product!

Thanks @maraakate!
  View user's profile Send private message Visit poster's website
  • Joined: 14 Apr 2013
  • Posts: 623
Reply with quote
Post Posted: Mon Nov 07, 2022 5:43 pm
I'm not aware of any SMS (not sure about GG) game having a region lock. The only thing that comes close to a region lock is that Back To The Future 3 detects if your system is running at 50 or 60 Hz and in case of 60 Hz locks itself up deliberately.

The other games listed in https://www.smspower.org/Tags/PALOnly only suffer from glitches when run at 60 Hz.
  View user's profile Send private message Visit poster's website
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!