Create a series of boards designed for the RC2014 bus to achieve
MSX/MSX2 compatiblity

Similar projects worth following
Starting from
dinotron has 22 orders / 1 reviews
Ships from Australia
Is it possible to achieve full MSX/MSX2 compatibility on a RC2014 platform, using standard discrete components and no tricks?

Can a set of boards be designed and built (graphics, sound, RAM/ROM, IO, etc) which can be installed into an existing RC2014 build?

And once all boards are installed - can full MSX2 compatibility be achieved?

This project is my attempt to find out.

RC2014 is a retro Z80 based homebrew platform designed and sold by Spencer Owen. It allows for easy expansion - and there are lots of kits availble to make your retro computer shine. (

MSX is a series of computers sold in the 80s, standarised onto a common platform - providing a consistent hardware and software implementation. (

UPDATE: I have begun selling kits on my tindie store (

References and inspiration

  • RC2014 - Where this all started for me.
  • OMEGA MSX kit. Demonstrates that its possible to build a compatible MSX2 system, using off the shelf components with a few ebay purchases.  The published designs are a great implementation reference.
  • Artemisa MSX Computer System.  A MSX kit using discrete component. 
  • MSX Technical Data book.

Main Goals:

  • Each board to operate independantly.
  • Each board to operate on a standard RC2014 platform - with appropriate RomWBW HBIOS support.
  • Board sizes will need to be kept small enough to ensure PCB manufacturing costs are manageable.

Stretch Goals:

  • Figure out how to add Floppy and HDD interfaces - can we just use the existing kits available?

Targeted Specifications

  • Graphics: v9958 with full 192K of RAM
  • ROM/RAM Board(s) - Support for MSX Rom images and lots of RAM
  • YM2149 Based Sound chip and Joystick connectors
  • RP5C01 Based RTC
  • Full size keyboard
  • Support for 2 Cartridge Slot expansions (a new backplane perhaps)
  • Optional - cassette interface - because retro!

Portable Network Graphics (PNG) - 195.87 kB - 11/15/2020 at 22:29


Portable Network Graphics (PNG) - 123.48 kB - 11/15/2020 at 22:28



Schematic for RTC board

Adobe Portable Document Format - 89.58 kB - 10/26/2020 at 08:10


  • Video of MSX on RC2014 in action

    Dean Netherton03/29/2021 at 09:11 0 comments

    Made a video quickly showcasing Compact Flash storage and running a couple of demos to show off what my RC2014 is learning to do.

  • General Update

    Dean Netherton03/17/2021 at 07:56 0 comments

    It's been a while since I posted an update to my project.  Usual boring things like work and other adult responsibilities.

    I haven't had a chance to take any new pictures or videos.  So let me describe what's happened so far.

    1.  Selling on Tindie

    As you may be aware, I started selling kits online at Tindie.  This has been a fun experience - the V9958 Video board has proven to be quite popular.  I have struggled to keep the stock online.  

    To quote Lando Lando Calrissian:

    "We're a small outpost and not very self-sufficient. I've had supply problems of every kind. I had labor difficulties..... What's so funny?" 

    New stock of both the Video and Game boards are online, and I didn't make any deals with the Empire!

    Check out my Tindie Store, if you want to join me in the journey.

    2. Keyboard/PPI

    I've built a new iteration of the keyboard.  This design fixes flaws in the previous one - no bodging required.  Updated the design to utilise a diode for each switch, preventing key ghosting.  Without the diodes, some multi-key combinations can result in ambiguous key detection.   See the Key Ghosting section at

    3.  M1 Wait states

    MSX typically runs at 3.5Mhz, with 1 wait state during M1 memory read cycles.  My standard RC2014 does not have such a wait state, so I added some logic into the PPI board to generate this, helping with MSX compliance/compatibility.  It can be enabled/disabled with a jumper.

    4. Real Time Clock

    Updated the RTC board - just general improved layout using the larger board size.  For the most part seems to work well and keeps time reasonably accurately.  It has a trimming capacitor to adjust the clock rate a bit, but I think I need to revisit the values of some of the clock capacitors as the adjustment seems to be too limited.

    5. ROM/RAM Memory Board

    Updated the memory board to give me 1M of onboard RAM.  And improved/fixed some of the issues with the ROM address mapping.  

    The Memory board allows running of original MSX BIOS ROMs or CBIOS, with MSX-DOS (Nextor). 

    Spent many a night working on the MSX-DOS/Nextor drivers.

    6. Compact Flash storage system

    I have spent a lot of hours working on getting the drivers for MSX-DOS/Nextor.  I wanted a diskless bootable system, so I created an embedded disk image within the ROM banks - allowing MSX-DOS to boot up without a floppy or hard-disk.

    With the built in RAM disk feature, I am able to send apps/games over the serial and run from the RAM disk.  

    But it really needs persistent storage, so I was very pleased, that just last week, I was successful in mounting the CompactFlash card for RC2014 under MSX-DOS/Nextor.  The code for the driver was relatively simple to write, although I did stumble across the usual confusing and strange bugs.  Very pleased to be able to save/load games and apps to persistent storage.

    7. Fully Operational Battlestar - aka MSX on RC2014.

    For the most part, my RC2014 system is now a MSX computer.  I can play games, write my own code and continue my re-exploration of 80s computing.

    8. Compatibility/Issues:

    So far, I have only tested a few games and apps.  And of course, I do not have a cartridge slot to test with.  (The original ROM Cartridges for MSX are friggin expensive!)

    I am using a program called SOFAROM which allows me to run ROM images from disk storage.  It loads a ROM image from disk, and dynamically patches its.  This is required as the original code is expecting to run from a Cartridge slot with a specific memory bank switching model.  You can't just simply load the code.  As such there are the inevitable compatibility issues.

    Most of the MSX1 games seem to run just fine and some MSX2 game seem to work OK.  But some MSX2 games either don't load...

    Read more »

  • Sound & Controller Board

    Dean Netherton01/23/2021 at 23:43 0 comments

    Just completed the build for the game board.  This board is based on the YM2149 audio chip - with integrated game controller ports.

    Its ports are configured as per the MSX specification.  

    The AY-3-8910 chip could also have been used, but to keep thing simple, i just locked in the YM2149 chip.  They apparently have subtle sound quality differences with the major differencing being the Ym2149 has an onboard clock divider.

    The board also supports mixing in other external audio signals -- in anticipation for full MSX capability.

    The demo below is with my port of Octo/chip8 games running on a stock rc2014 build.

    (I have not tested it under the MSX configuration yet)

    The Chip8/Octo port project is at: (It's not fully implementing all the octo instructions yet)

    More details of Chip8/Octo can be found at:

    Game controller board project page: (includes schematic)

    And shoutout for the controller from:

  • V9958 Latest

    Dean Netherton01/19/2021 at 04:17 0 comments

    Last couple of weeks, I have revisited the video board.

    Version 1.4 of the video board arrived a couple of weeks ago - this board has a minor change in layout and silkscreen.  

    The main change was to add a mounting point at the back of the board for a spacer to help prevent flexing and making physical contact with any adjacent boards.

    All the boards I am designing for this project have this same rear mounting hole.

    I have refocused on making sure this board works in a standard RC2014 configuration with RomWBW - and have been hacking some software - learning how to fully utilise the hardware acceleration features of the V9958.

    I have decided that I would offer this board as a full kit on Tindie.  I have 4 kits built up and online at Tindie.  If there is demand - more will be made available - I seem to have collected quite a few spares!  The kits include everything needed (PCB, V9958, RAM, etc).

    Tindie Store Listing

    The latest version of the schematic and software can be found on the github project:

    The glorious PCB:

    Fully Assembled for PAL output

    Proudly installed in its RC2014 home

    What 8 bit graphic system is truly finished, without showing the ubiquitous mandelbrot set? (takes a while to produced - not timed it yet!)

    Video Showing running through its paces

    Video showing a chip8/octo game running.

  • SIO and Sound Board

    Dean Netherton12/29/2020 at 03:19 0 comments

    RC2014 SIO/2

    Managed to get the RC2014 SIO/2 Board to work with my MSX rig.

    Its took a bit of finessing to get the higher baud rate (57200) working with MSX BIOS interrupt handler - the overheads make it easy to lose data. 

    The application talks directly to the SIO chip.   A future goal will be to integrate the serial driver within the BIOS/Nextor systems.

    Sound/Controller Board

    After a few bodge fixes - i was able to get the sound board working (YM2149 chip).  I considered using the RC2014 Sound board, but I don't think the revision I have supports the MSX ports.  A later revision seems to.  

    The board I designed, also support controller ports -- if only I owned a MSX controller!

    (The missing chips are required for the controller ports - will install when i get an MSX controller to test with)

    In the next few days, I will try and get myself organised, and upload designs.

    In the meantime you can watch me playing PACMAN really badly.

  • BOOT ROM/MSX-DOS Startup

    Dean Netherton12/24/2020 at 02:00 0 comments

    So after what seems like a million and one flashes of the ROM chip, I now have a booting image.

    The BIOS and disk system (CBIOS and Nextor MSX-DOS) are now working nicely together to give a command prompt.

    I am able to run CP/M and MSX-DOS apps - although there will probably be some compatibility limits with CBIOS.

    To enable a bootable system, without an actual floppy or hard disk, I had to create an embedded virtual disk drive within the ROM image.  This ROM drive includes the boot executables (nextor.sys and as well as a few simple demo apps that I found online.

    A quick summary of the things I needed to do to get the software to work:

    • A fix to CBIOS for ROM initialisation, needed when booting Nextor.
    • A custom CBIOS image that includes extra wait states for the V9958 I/O and other minor tweaks.
    • For Nextor, as mentioned, added a virtual disk image driver.
    • And some changes to work around some design issues I have with the on-board ROM Mapper.

    Next steps:

    1. Fix the issue I have with the on-board ROM Mapper, to I can remove the workaround in CBIOS/Nextor.
    2. Add some key debouncing and support for CAPS LOCK in CBIOS.
    3. See if I can get the RC2014 SIO/2 board to work within the platform. Might have some issues with Baud rate and general performance.
    4. Explore the possibility to write drivers for the RC2014 Floppy and HDD interface boards. 
    5. Continue with the other MSX boards i have coming - sound/joystick, cassette.
    6. Will also need to explore designing/building a new board, to introduce the required wait states on M1 - as per the MSX spec. (This might be why I needed to add wait states in the CBIOS code for V9958 access)

    ROM Mapper Issue:

    The issue I have with the ROM Mapper, is due to the way I have used of a single ROM chip across multiple Slots.  

    When accessing the ROM in slot 3-3, the ROM Mapper allow access to all 16k banks, the first 8 of which are the CBIOS images, and are not relevant in this slot.  

    So to access the slot's first bank, you need to write $08 to the bank selector port.  If this is not done, then the BIOS' ROM search code will fail to see the MSX ROM marker in the slot and will not initialise and load the ROM code.

    Now it's easy enough to add an IO write in the ROM search code in CBIOS, but for other BIOS ROM images, this will not happen.  So to enable better compatibility I need to make sure the on-board ROM Mapper, for slot 3-3, always defaults to the correct initial bank.

  • Software for the MSX on RC2014

    Dean Netherton12/12/2020 at 00:37 0 comments

    I received and assembled the Memory boards.  Now i just need some software to put on it!

    Over the last couple of weeks, I have been working on the software platform.  

    Many modern MSX solutions (kits/emulators) use ROM images extracted from one of the original computers.  These ROM images are easy to find and download.

    I could follow this approach for my build, but I prefer a more open-source and legitimate approach. 

    Having access to the source code, will allow me to debug and verify the hardware, and be a good starting point to add additional features, such as support for RC2014's serial and IDE boards.

    There are 2 key projects that I have been exploring:

    1. CBIOS- An open source compatible MSX BIOS.  It does not include a Basic Interpreter.  It's distributed with many of the MSX emulators with a primary focus to enable the loading of various ROM images (typically games).  My fork of this project is at:

    2. Nextor- This is a fascinating project.  It is based on the original MSX-DOS 2 source code - and now officially opened source and apparently ok to distribute.  MSX-DOS is a CP/M compatible OS,  that is kind of half way between CPM and MS-DOS.  An interesting story within the history of the early home computer OS development.  My fork of this project is at:

    These two projects can be used as a foundation for the boot ROM.  They do require a bit of work to meet my needs.  The key enhancements needed were:

    1. Create a makefile build system for building nextor in linux.

    2. Tweaks/fixes to get nextor and cbios working together.

    3. Add an embedded virtual disk image within the nextor rom image - so that the key utilities are available on boot - much like how RomWBW cp/m boots up with a ROM and RAM disk. (Nextor already has support for RAM Disk.)

    4. Other fixes/enhancements required to boot up on the rc2014 hardware. 

    I have been able to get this all working within an emulator - so the next step is to flash a ROM and power up!

  • Memory Design/Requirements

    Dean Netherton12/12/2020 at 00:17 0 comments

    I have completed a first design and ordered a PCB for the memory board.  This board has had to solve a few challenges.

    (In this posting, when I refer to MSX, I primarily mean the later MSX2 architecture.)

    A complete RAM/ROM structure for an MSX involves quite a bit of logic.  The MSX memory requirements are, a little more complicated than the typical RC2014 RAM/ROM solutions.  Now remember, I did not have any experience/knowledge of MSX architecture before embarking on this endeavour, so the learnings I have summarised below may have some errors in them:

    1. Slots (aka Primary Slots): MSX systems use the model of slots, to segment the Z80 address space.  Upto 4 slots can be configured.  Each slot can address 64K, divided into 16K banks.  Each bank can then be mapped to the corresponding Z80 address range. 

    The first slot is reserved for the MSX BIOS and BASIC rom.  Slots 1 and 2 are typically reserved for the expansion cartridges. Slots are controlled by an IO register at $A8.  This register is provided by the PPI 8255, that also manages the keyboard interface.

    2. Expanded Slots (aka Secondary Slots):  Each of the primary slots may be expanded a further 4 times.  A slot is expandable, if writing to the memory mapped register at $FFFF within the slot, returns the 1's complement.  This memory mapped register controls which of the 4 sub slots are selected.

    (more details on slots)

    3. RAM Mappers:  Each of the slots may contain RAM - allowing each slot to provide upto 64k.  This solution has some limitations, so to further enhance the memory capability of the MSX series, a standard RAM mapper was introduced.  

    The mapper allow for the selection of a specific 16K bank to be mapped within the 64K address range of the slot.  The memory mapping is managed by 4 IO registers at $FC to $FF.

    With upto 256 banks available to be selected, a total of 4MB of RAM can be address within the slot. Surely that's enough!

    Multiple slots may implement the memory mapper, but all slots will share the same IO address range, thus bank selection will effect all memory mappers.

    (more information)

    4. ROM Mappers: There are many ROM Mapper strategies that were employed for MSX systems - usually within the context of an Expansion Card.  So if a game ROM or other application ROM needed to address more than 64K (or needed a better banking solution), they could implement their own mappers.  So a few solutions/standards were developed.  They typically involved writing to a write only memory mapped register. 

    The board I have designed, attempts to have all four of these models applied.  The logic is based around the same ROM and RAM chips used in the 512K ROM 512K RAM board (and many others);  ST39SF040 for ROM and ASC6C4008 for RAM.

    The RAM is mapped in much the same way as the RC2014 solutions, using 74HC670 registers.

    The ROM is a little more complicated.  I wanted/needed 48K ROM space for the BIOS/BASIC slot 0.  An additional 16K for a Sub-ROM BIOS, in slot 3-0.  And the remaining ROM space available using a ROM Mapper in SLOT 3-3.  

    This is a lot of logic to squeeze onto the 100mm x 80mm board dimensions.  In my initial concepts, I thought I may have to have 2 separate boards - one for RAM and one for ROM.  But after many iterations, I managed to fit everything onto the one board, with some support from the PPI board. (Little of this is tested; hopefully nothing missing or just simply wrong!) 

    * The PPI 8255 board has a couple of chips, dedicated to processing the Primary Slot register -- with 2 slot address lines mapped to a couple of the RC2014 user pins.

    * I added a ATF22V10C programmable logic gate to the memory board, to alleviate the logic load and also to give me a chance to rework things, should I discover any design flaws.  

    Will it work?  Well...

    Read more »

  • V9958 progress

    Dean Netherton11/27/2020 at 04:12 0 comments

    Here is a very short video showing the RC2014 running RomWBW, booting with TTY emulation using the V9958 and MSX keyboard boards.

    Then running a demo app drawing lots of random lines.  So many lines!

    This V9958 board is running with RGB output, with the OSSC converting to the HDMI LCD monitor.

  • V9958 update

    Dean Netherton11/26/2020 at 00:40 0 comments

    The new boards that use the 41464 DRAM memory chips have arrived and been built.

    A couple of interesting things were discovered.  On first power up, the board exhibited the same 'faults' as my SRAM based boards - what tha?

    The issues were:

    1. Running a test app to write/read to VRAM would identify the occasional failed write.
    2. Running RomWBW TTY emulation code (using the compatible TMS9918 driver) - would generate some on screen corruptions - some characters would be duplicated and some characters would get blanked.

    So perhaps the issue is not hardware but software.

    So in the course of investigating, I ended up learning two things:

    1. Although the V9958 is backwards compatible with the TMS9918, its timing requirements are a little different - especially in text mode - it needs a few more wait states for VRAM access - generally in the order of about 4us or about 30T states for a cpu at 7.3Mhz.  Once I updated the RomWBW TMS driver to include some additional wait states - the TTY emulator worked perfect.  Now my RC2014 RomWBW has native support for 80 column text.
    2. But what about the test code that was identifying failed writes?  Well it turns out I had failed to disable interrupts during some of the IO to the chip - the RomWBW interrupt handler within the TMS driver also interacts with the chip.  By not disabling interrupts, the sequencing of register writes can become disrupted, causing random like errors.  I knew this, but simply had not noticed a section without the appropriate DI/EI instructions.  It definitely was a facepalm moment.

    Perhaps the SRAM version works?  I may go back and test again with that version - but I don't have enough spare parts at the moment - so gonna keep moving forward for the moment, with the DRAM version.

    So far I have only been able to test using the composite video signal - using a cheap ebay video to VGA converter.  The conversion works, but colours are not very good - and text can be very blurry.  At 80 columns it very difficult to read text.

    So next step is to try the RGB signal, using the OSSC.  I wonder what drama awaits me?

View all 18 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates