Close
0%
0%

MSX COMPATIBLE BOARDS FOR RC2014

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

Similar projects worth following
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. (https://rc2014.co.uk/)

MSX is a series of computers sold in the 80s, standarised onto a common platform - providing a consistent hardware and software implementation. (https://en.wikipedia.org/wiki/MSX)

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.
  • https://www.msx.org/

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

Preview
Download

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

Preview
Download

Schematic_RC2014-MSX-RTC_v1.0.pdf

Schematic for RTC board

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

Preview
Download

  • Sound & Controller Board

    Dean Nethertona day ago 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: https://github.com/vipoo/rc2014-chip8 (It's not fully implementing all the octo instructions yet)

    More details of Chip8/Octo can be found at: https://github.com/JohnEarnest/Octo

    Game controller board project page: https://github.com/vipoo/rc2014-game (includes schematic)

    And shoutout for the controller from: http://retrogameboyz.com

  • V9958 Latest

    Dean Netherton6 days ago 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

    https://www.tindie.com/products/22479/

    The latest version of the schematic and software can be found on the github project: https://github.com/vipoo/rc2014-v9958

    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 command.com) 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: https://github.com/vipoo/cbios/tree/dean/spike

    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: https://github.com/vipoo/Nextor/tree/dean/spike

    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?

  • V9958 Testing Continued

    Dean Netherton11/23/2020 at 03:40 0 comments

    Well I think I am gonna abandon trying to get the V9958 to work with SRAM.  

    Latest testing was producing the occasional write failure -- its probably a bit beyond my skills to fully understand..  I suspect i need to do a bit more latching of the address lines - but doing this increases the chip count - so to keep moving forward I have changed the design to a more conventional DRAM model.

    I can only fit 128k VRAM on the board's dimensions - but thats more than enough.

    New PCBs have been ordered - so just have to wait until they arrive.

  • V9958 Testing

    Dean Netherton11/15/2020 at 22:35 0 comments

    Just completed some initial testing of the Video board.  Wrote some code to write and read blocks of VRAM - so far no issues detected.  The code writes to a VRAM location, then reads it back and verifies - there are no NOPS or delays in the reading and writing.

    I would like to do a bit more testing on this.  Need to get the chip into one of the higher res modes - to make sure the RAM is being fully tested.

    I did not see the WAIT line get activated in the testing, which confused me a bit - I was expecting this line to go low under lots of memory writes - not sure what i am not understanding here.

    Also wondering if the writes are impacting other locations?  Need to do lots more testing before i gain confidence that the timing for memory will work.

View all 16 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

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