MSX COMPATIBLE BOARDS FOR RC2014

I have finished and recently listed on Tindie, a new module - the YM2413 MSX-MUSIC module for RC2014.

This module is based on the YM2413 chip, which was incorporated into the MSX2 and MSX2+ standards.

My version of this module, fits into the standard RC2014 bus and includes its own embedded ROM image to provide BIOS and MSX-Basic extensions.

Here is a short video of the module in action: 

The sound quality, as captured on my phone, is not great - it sounds much better in person!

Some of the key design elements:

The YM2413

The heart of this module.  This chip generates the audio signals.  See the msx.org page for some details (https://www.msx.org/news/en/ym2413-application-manual-correction-and-cleanup) or the wikipage (https://en.wikipedia.org/wiki/Yamaha_YM2413)

Onboard ROM

The board uses the same ROM chip used on many RC2014 and other similar retro kits - the SST39SF040 512K ROM Nor Flash chip.  (it should also probably work just find with the smaller variants).

The ROM image only needs to contains a small 16K extension, for MSX-BIOS and MSX-BASIC, to enable programs to control the YM2413 sound chip.  Of course, there is nothing stopping any application software from directly controlling the YM2413 chip. 

As the onboard software only uses the first 16K of the chip, this leaves the rest available for future possibilities.  The ROM is mapped to slot 3-1, via the select signal from the MSX-MEMORY ROM/RAM module.

The ROM and logic are designed in such a way, that its possible to flash (write) to the chip using a software utility.  It does requires quite a bit of slot mapping trickery -- so I was very happy when I was able to successfully update the NOR flash using a MSX-DOS utility I wrote, MUFLASH.COM.

I also hope to add to my NEXTOR/MSX-DOS driver the ability to read and write to the spare space of the ROM as an extra storage drive.

Audio sub-circuit

The output signals of the YM2413, do need some further processing and amplification.  There are a few different designs that I found online ( mostly by hackers creating their own cartridges for MSX and some wiring up this chip to other micro-controllers such as Arduinos modules)

I settled on a single op-amp based design, to keep the circuit as simple as possible.  The sound quality it produces seems generally quite good - although it does have a tendency to pick up some stray interference - but when music and sound are playing, any background noise is no longer noticeable.

Most designs, using the MSX cartridges, power their op-amps using the +12/-12 rails - I found I could use a small charge-pump (TC7660) to generate a -5V from the +5V on the RC2014 bus and drive the op-amps with these voltages just fine.  The charge pump selected, oscillates at about 120Khz - and get the job done.

The board also has a header, to take in the audio signal from the MSX-GAME's YM2149 sound chip, mixing the 2 audio signals together.

Software

As the onboard ROM contains the MSX-BASIC extensions, small MSX-BASIC programs with MML embedded in them, operate the chip nicely, although I do find the code can be a little bit obtuse.  See the msx.org page (https://www.msx.org/wiki/PLAY)

I also download Laurens Holst's VGMPLAY.COM utility to play VGZ and VGM music files for the YM2413 chip.  

And of course, any games that use the chip will work just fine.

Bug

Nothing is ever perfect, and when I started trying to get the paging of the 512K ROM to work in the MSX Slots/paging system, I found I had goofed the addressing for the paging register.  This is the register that select a specific 16K page, that is then mapped into the Z80's address range ($4000 to $7FFF).  It was intended that writing to address $7FF7 would trigger the page selection register (as per the FMPAC cartridge design) - but due to my goof, I actually need to write to address $7DF7  (or $E000 for slot 3) to select the correct 16K page. 

This module is listed on my Tindie store at: https://www.tindie.com/products/dinotron/ym2413-msx-music-module-designed-for-rc2014/  

Although at the time of writing this blog entry, my store is currently paused accepting orders (expect for Australia), due to recent issues with international deliveries going missing - due to omicron/covid/post Christmas logistic issues.  My store will re-open for international order from Valentine's day 14th Feb.

In my previous post, I showed the progress for the Cartridge Slot extension.  I mentioned that I had yet to test with original cartridges.

Since then, I have received some game cartridges to test against.  I got a very groovy modern day game from https://www.msxcartridgeshop.com/, as well as the flash rom MegaFlashROM SCC+.  

Also received some previously owned 1980's era games. 

The game cartridges are for MSX1 machines, but the MegaFlashRom will allow me to test MSX2 type games.

The slot extender pictured in the previous posting, had my attempt to apply buffers between the RC2014 bus and the slots.  But in testing, I identified I had a flaw in the logic and was potentially generating a bus conflicts.  The game would be attempting to drive the data bus, and my buffer was also attempting to drive the bus to the cartridge - not good for the cartridge I am sure.  

So I decided on the next revision to simplify things and remove the buffer chips and just connect the slots straight to the RC2014 bus.  (Why didn't I do this from the start - would have saved me a lot of headaches!)

And with the much simpler design, things are now working very well indeed, including with the cartridges from the 80s.  My RC2014 rig has a total of 10 modules, in addition to the slot extender -- So it would seem to me that the fanout for the Z80 and other modules are within their tolerances.  (I suspect if I was using an early edition Z80, rather than the new modern CMOS ones available today, things might be less reliable).

So far, I have tested the following cartridges and they seem rock solid reliable:

1. PACMAN - dated 1984

2. SALAMANDER - dated 1987

3. Hyper Sports 2 - dated 1984

4. Mutants from the Deep - dated 2021

5. MegaFlashROM SCC+

The MegaFlashROM had a conflict with the NEXTOR/MSXDOS image burnt into my onboard ROM.  I did a hack and removed that (so I only had BASIC in the onboard ROM) - and it worked just fine.  Loaded up Space Manbrow and got full perfect game play with wonderful SCC sounds!  (Furture task is to 'fix' the software compatibility with my version of NEXTOR and the Flash ROM's version)

Part of the Slot Standard requires the supply of a +12V and -12V lines.  I don't think the cartridges I have tested require this - including the MegaFlashROM.  But I have footprint on the PCB to use an optional 5V to +12V/-12V dc converter - as well as screw terminals for optional external source.

Some things I have only limited tested are:

• The supply of 12V from the onboard DC converter .  Done some probing and also used it to drive an opamp on the still under-development MSX MUSIC module - all seemed fine.
• Testing having 2 cartridges inserted at once.  I have tested running the games in Slot 1 and Slot 2 -- but have not been able to test having the two slots operating at the same time.

See below the pictures of the board installed.

I hope to have the slot extender board on sale in my Tindie store soon.  Stay tune for more updates.

One of the developments that been wanting for time, is the development of a custom backplane and cartridge extension.  

In the picture above, you can see the 13 slot backplane, where the 13th slot connects to the Cartridge slot exertion board, with a custom built cartridge (flashed with pacman).

The backplane extension provides 2 buffered MSX cartridge slots. 

Now in this configuration, all seems to work - but I have not been able to test with an original cartridge - so its very possible I have a compatibility issue, that I don't understand/failed to implement correctly.  

I have some original cartridges coming from Japan and Europe - and also a couple of modern cartridges coming the msxcartridgeshop

So until they arrive - I can not have any confidence that implementation does not have some compatibility issue.

The main backplane has the full 80 lines (2x40) bus lanes, and avoids the need to use jumper wires between some of the modules when using the standard backplane.  It also have a bunch of LEDs between each slots, giving the whole kit a nice soft glow when powered on!

Over the last few weeks, I have been mostly working on the software interface for the RC2014 Wifi module.  

We now can download files from the internet directly to the CompactFlash, have the RTC modules time sync to the internet time, create telnet sessions to internet based BBS and a few other integration. 

The software needs some general tiding up and testing - but for the most part seems to work well.

It consists of custom firmware in the ESP8266 module and a couple of MSX applications to interface with it.

term.com - a simple terminal emulator for connecting to the ESP8266 and BBS telnet sessions.

esp8266.com - a general purpose utility to conduct a number of functions:

esp8266 set-wifi - configure the wifi credentials for the ESP8266 to use

esp8266 time-sync - sync the RTC module with internet time

esp8266 set-timezone - set the time zone to use for the time syncing

esp8266 wget - retrieve a file from the web

A longer term goal is to create a proper MSX compatible UNAPI network driver.

All the software builds and source can be found on the github project's page:  https://github.com/vipoo/yellow-msx-series-for-rc2014/tree/main/msx (in the apps directory)

And the custom firmware for the ESP8266 is at: https://github.com/vipoo/yellow-msx-esp8266-wifi-module

Over the last couple of weekends I have manage to get the RC2014 ESP8266 WIFI Module working in MSX-DOS.

I now have a 'WIFI' modem integrated into the serial communication.  Finally, my RC2014 no longer needs to be 'connected' to my main PC - it can reach out through the Internet all on its own.

I have been writing my own custom firmware for ESP8266 to give the MSX/RC2014 kit all it needs.

At the moment, I can:

• Use my terminal emulator application (formally called telnet) term.com to send commands to the ESP8266 module - initiate telnet connection and then access any online BBS.
• xrecv.com can now, with an optional command, receive a file from my main PC wirelessly (using xmodem over TCP/IP)

I needed to modify the WIFI Module to allow hardware flow control - otherwise the ESP8266 will overwhelm the RC2014's receive buffer.  This required adding a couple of resistors to map the 5V RTS from the SIO/2 to the 3.3V CTS/GPIO13 line.  Flow control is only needed in the one direction - from ESP8266 to SIO/2.  When transmitting from the SIO/2 to the ESP8266, the ESP8266 will easily keep up at the 19200 baud rate.

The RC2014 WIFI module provides a great prototyping area to make this modification so easy:

I have never used an ESP8266 before, so had to learn a few things - I used the Arduino Core library - making it very easy for me to code for the chip.

But I did struggle with a few things:

1. The RX line needs to be open drain - if the internal pull up resistor is active, then the on-board voltage divider of the WIFI module will not work.  The Arduino Core, by default, enables the internal pull up - and there seems to be no interface to change this.
2. Arduino Core also does not have any functions to flip the ESP8266 into using hardware flow control for the serial lines.

I solves these problems by directly manipulating the relevant ESP8266 registers.

To disable the internal pull up resister of the RX line:

void setRXOpenDrain() {
  GPC(RX_PIN) = (GPC(RX_PIN) & (0xF << GPCI)); // SOURCE(GPIO) | DRIVER(NORMAL) | INT_TYPE(UNCHANGED) | WAKEUP_ENABLE(DISABLED)
  GPEC = (1 << RX_PIN);                        // Disable
  GPF(RX_PIN) = GPFFS(GPFFS_BUS(RX_PIN));      // Set mode to BUS (RX0, TX0, TX1, SPI, HSPI or CLK depending in the pin)
}

And for flipping hardware flow control on and off:

void setCTSFlowControlOn() {
 pinMode(CTSPin, FUNCTION_4); // make pin U0CTS
 U0C0 |= (1 << UCTXHFE); // Set bit to activate Hardware flow control
}

void setCTSFlowControlOff() {
 pinMode(CTSPin, FUNCTION_4); // make pin U0CTS
 U0C0 &= ~(1 << UCTXHFE); // Reset bit to deactivate hardware flow control
}

The full code for the ESP8266 can be found at: https://github.com/vipoo/yellow-msx-esp8266-wifi-module

And an xmodem serial and TCP/IP client I wrote in nodejs can be found at: https://github.com/vipoo/xmodem-cli

And the main project is still at: https://github.com/vipoo/yellow-msx-series-for-rc2014

Working on my MSX for RC2014 is not a planned or organised project.  For the most part, when I have some time on the weekends and the occasional evening, I just follow my fancy - would ever takes my interest at the time I sit down.

Sometimes, I just do some research and reading, other times, I might work on a design for a new module or do some software or any number of things. 

The natural result of this, is there a few items in the backlog, at various stages of completion or operation.  

So this journal entry is to briefly note where some of these undertakings are at:

Serial Drivers

On the software front, I have been spending a lot of time trying to get proper serial drivers implemented.  This has required learning the serial driver specifications for MSX (extended bios and fossil).  To test the drivers I have a couple of applications.  A telnet for accessing BBS and a new implementation of a xmodem utility.  It is getting close to be able to make an official release over in the github project.

I certainly have spent far more time on this, than I anticipated would be required - but aint that just usual!

On the hardware front I have got a few things going:

New backplane:

This backplane supports all 80 pins, which includes the 'USERx' lines.  This allows me to avoid having hookup wires between the Memory and PPI modules, making for a clean and simpler install.  Very handy as I often am removing and replacing modules.  

It also aligns with the yellow colour scheme and includes some LEDS to add to the cool factor.  As a kid in the 80s, I always wanted my computer to have lots of leds - but never managed to achieve that goal.  After so many decades that dream is coming a reality!

I think the new backplane show off the kit just nicely:

Fully installed and operational

Cartridge Slot

Another reason for the backplane, was to make it a little easier to incorporate a backplane extension to support MSX cartridges. Its very early days for this module.  I have a PCB made, but have yet to build and test it.  

New Video Module

This one is still in the experimentation stage.  For the current Video board, I am not particularly happy with the quality of the Composite and S-Video outputs.  And the RGB is only just okay.  On the Composite lines, there appears to be quite a bit of noise.

So I have been trying to figure out what is causing the noise and how might I reduce it. This is an area where my skill and knowledge are lacking. 

I have a new experimental PCB design, that incorporates some improvements, including:

1. Improved layout of analogue and video lines to help reduce interference on the video signals from each other as well as the nearby digital lines.  
2. Added some filters for the analogue power of the CXA1645 and the V9958 as per the datasheets.
3. Ability to select different sync types for the RGB output, including TTL level sync.  The TTL level sync allows the video board to drive the low cost ebay arcade RGB to HDMI converters.  The converters are not as good as something like the OSSC - but do produce a very good image for a much cheaper price.
4. And finally, added a optional headers of the TTL RGB signals so I can more easily hack around with different designs for the converter circuit.

RTC Module

I feel that this module's design is now completed.  I have a working RTC and support for MSX's F4 warm start register.  Once adjusted, using a simple little timing utility - it seems to keep time just fine.

I intend to add this kit to my Tindie store in the near future:

Others

Also on the backlog is the MSX Music module, 3 1/2" Floppy interface, enhanced CPU,  designing 3d printable cases, software enhancements and lots of other ideas.  

Bloody hell, where will I find the TIME for all of this!

Between ZORK play sessions, I have been working on implementing compatible serial drivers for MSX BIOS and MSX-DOS.

No easy task.

For serial communication, the only software I have developed to date, is a little utility called xrecv, that talks directly to the SIO/2 chip to enable simple xmodem receiving of files.  I really want to access other serial based applications for the platform.  For that I need to implement serial driver for the standard RC2014 SIO/2 Module.

So I have been researching how MSX handled serial communications - and it seems like many computers of the era - the software support was a bit muddled. 

As I did not grow up with MSX - I can only rely on online archived docs, and guess at a few things.

There is an official bios interface for RS232 communications for the MSX platform - integrated through the MSX Extended Bios protocol.  This interface does seem to solve the problem of accessing interrupt driven serial devices, without knowledge of the specific hardware. (A feature missing in early IBM-PCs).  According the msx.org's page (https://www.msx.org/wiki/Category:RS-232C_Interfaces), there were quite a few products supporting this interface.  But I struggled to find application software I could use to test against.  This interface also seem to have performance issues - limiting to just 19200 baud.

What seems like a more popular driver model, are the Fossil drivers - developed by Erik Mass (https://www.msx.org/wiki/Fossil_driver).  I  assume (I could be wrong), this is inspired by the fossil drivers of the FidoBBS days (https://en.wikipedia.org/wiki/FOSSIL).  The interface protocol for MS-DOS and MSX-DOS are quite different.

Anyway, armed with this knowledge, I set a goal of writing both a MSX RS232 Extended Bios driver and a Fossil driver for my RC2014's SIO/2 Module.  

I had found some basic specification documents for the interfaces, detailing the API protocols.  But that alone will not be enough to ensure I have developed the drivers correctly.   The only way I can really verify compliance, it by testing with some applications.

Writing the drivers is proving to be quite an effort of endurance.  Getting the interface worked out, ensuring the interrupt handling is functioning correctly - resolving many strange and bewildering bugs.  But despite the hardships, I have, just today, been able to run a telnet application on my MSX machine talking to internet based BBS (using my PC as serial <-> internet gateway).

The slow text based screen drawing of the BBS pages were strangely thrilling to see.  The joy you can experience as you wonder what new image or content is slowly forming on your screen.  So different to the modern Web, where it usually a battle of trying to read your content as ads appear and content shuffles around.

The drivers are only partially implemented - the telnet app is crashing at odd times - but as you can see from the pics above, communication is starting to happen.

I think its a few more weekends, before I could say they are at least stable - hopefully then, I can post here its all working.

One of the aspects of MSX-DOS I find fascinating, is its CP/M compatibility.  In all the reading and conspiracy theories that MS-DOS stole from CP/M - I never heard anyone discuss MSX-DOS.  Here is an Operating System that bridges CP/M and MS-DOS.  It runs many of your favourite CP/M programs just fine, saving and reading from the MS-DOS compatible disk format FAT.

I haven't done a lot of testing of various apps, but I did try ZORK.

For the first time, using MSX-DOS, with the V9958 and MSX Keyboard, I was able to play ZORK on my RC2014 without the need of a modern PC.

Just received a report of an issue with the Video board - in particular the address selection logic.

I have not personally experienced the fault myself, despite building a few version of the module -- but that doesn't mean much. 

I have created a github issue with specific details to track the issue, copied below:

----------------

https://github.com/vipoo/yellow-msx-series-for-rc2014/issues/1

At least one person has reported an issue with V9958 Video board not working. They identified an issue with the address selection logic - in particular the diode based OR gates.

I chose to use diode base gates to reduce the chip count, but they can have issues with the fall time - which in this specific case, resulted in a board that would not work. (I have built a few iterations of the board, and never observed the issue myself, but really doesn't mean much!)

There were 2 fixes that each individually would resolve the fault:

1. Change the 74HCT138 to 74ACT138 , or
2. replace the 10K pull down resistor to a lower value - about 3.3K.

I have uploaded a pic to highlight the resistor that needed to be changed. PCB image

If be great to hear if anyone else has experienced this issue.

The latest iterations of Video, Game(sound), Memory and Keyboard modules have matured quite well - and with them now selling on Tindie for a while, I have now been able to spend a bit of time on developing some more MSX boards.

## RTC

The rtc module was the first board I had started with - but I paused it to focus on the others, as it was not required to be able to boot up in MSX BIOS/DOS.  I have since gone back to this module.

After a few attempts getting the timing right, I now seem to have something that keep fairly accurate time.  I also added to the board, support for the MSX F4 port.  The F4 port enables MSX BIOS to know if its doing a cold boot or a warm boot.  It's basically just one bit that is reset on power, but not on reset.

I have a new PCB arriving soon that includes the F4 - ready for assembling and testing.

## FM-MUSIC

This one is the most experimental for me.  The MSX-MUSIC system is based on the YM2413 sound chip.  There seems to be a few variations of implementation - again msx.org is a great source of information -> https://www.msx.org/wiki/MSX-MUSIC

And this project https://github.com/RBSC/F4-FMPAC is giving me a lot of clues.

I am learning a lot about op-amps - will see if I can figure this all out.

## Cartridge slots

I also designing a new backplane that provides MSX cartridge slots - although i am a little unsure how i am going to test this - i need to actually source some cartridges that don't cost an arm and a leg!