Project Logs

Collapse

• Sponsorship from PCBWay

  Dean Netherton • 05/07/2022 at 03:30 • 0 comments

  As I started to design and explore creating a USB/Cassette storage module for the Yellow MSX series for the RC2014 platform, PCBWay reached out to me and offer to help me out with my little MSX project.  

  It was amazing to get the support for my little project from PCBWay - to be noticed was a little overwhelming.  I have seen PCBWay sponsor and support many in the Retro community - but I never thought in a million years that they would be so kind and gracious to support my little adventure.

  Last weekend I received my first PCBs under their sponsorship support.  I was very excited as I open and saw my latest PCBs - including the next iteration of the USB module.  I need an updated iteration for the module to allow the CH376 to fit nicely.  It requires a 'cut-out' space for the USB socket.  PCBWay had manufactured the board precisely and the CH376 module fit perfectly.

  I am very excited to solder this board up and test it all out.

  Thanks PCBWay for your support https://www.pcbway.com/

  The production and delivery of the boards were very prompt.

  What's in the box?

  Packaged safely and securely.

  
  PCBWay had supplied with new Video and MUSIC boards for my tindie customers, and the latest prototype for the USB/Cassette board!  See the odd cut out for the CH376 module!

  The CH376 module fit perfectly and keeps a low profile on the new board
  

  Thanks again PCBWay for stepping up and supporting me and the community of hackers and tinkers.

  https://www.pcbway.com/

• USB

  Dean Netherton • 05/07/2022 at 02:40 • 0 comments

  One of the final things missing from the Yellow MSX series of kits for the RC2014, is the ability to access typical MSX storage devices (floppy and cassette).
  

  Without storage such as this, its hard to claim that we have achieved full MSX compatibility.

  There are plenty of schematics online for how to give the MSX access to cassette storage.  Its not a very complicate design -- that is the easy part - although I have yet to get a working old-timey cassette player that works - so that makes it hard to test and validate cassette storage!

  For the floppy interface, I considered designing something based on the work of Dr. Scott M. Baker (https://www.smbaker.com/z80-retrocomputing-part-14-rc2014-floppy-controller-boards).  I have actually built one of his designs for the RC2014 CPM configuration - and its worked well - it would only need the appropriate software driver written to support MSX-DOS/Nextor.

  But I decided to go for a different and slightly more modern approach and create a USB interface for the system.  Based on the very cheap and easy to source CH376 modules.  There has been a fair bit of effort by some members of the MSX community to support this module.  The work done to date was invaluable to get the software and hardware working: 

  https://github.com/S0urceror/MSX-USB 

  https://www.msx.org/news/en/use-your-msx-as-an-usb-keyboard
  

  http://rookiedrive.com/en/

  https://github.com/Konamiman/MSX

  By going with USB it gives me:
  

  * A more reliable access to floppy - purchasing cheap new USB drives, will be more reliable than attempting to use old used floppy hardware.

  * Aside from floppy, we can access many other storage systems: flash storage, USB HDD, etc - making it easy to transfer files from a PC to the system

  * Other device types can be considered - if the software can be written - such as network interface, serial interface, keyboards - so many possibilities - although the software work is quite demanding.

  I have uploaded 3 videos that shows the work in progress for access floppy, flash storage.  The driver written to-date, currently supports many USB thumb drivers - and I have tested the floppy access for 2 floppy drives (an older IBM/Teac drive and a brand new no-brand drive from ebay)

  It took an enormous effort for me to learn how to access drives over usb, how to use the various USB protocol/standards for floppies, flash and hub access.  The software still has more work -- it currently is about 8k in length.   

  The video shows an early version of the PCB and schematic.  It changes a bit.  With better physical support for the CH376 module and the layout for the cassette design (cassette is yet to be tested and validated)

• Turbo CPU

  Dean Netherton • 02/19/2022 at 23:16 • 0 comments

  Another module I been developing in the MSX for RC2014 series is the Turbo CPU.  This is a module that run the Z80 at 20Mhz, instead of the stock 3.5Mhz speed.  

  This module is not designed to a particular MSX standard - but I wanted to make my machine go a little faster, yet still be compatible (for the most part) with existing software/games.

  The compatibility issue is not a simple one, when you increase the CPU speed, to 20Mhz, many other chips in the system will not be able to keep up.  And in particular the V9958 will have issues.  A lot of software written for the MSX, assumed its running on a Z80 at 3.5Mhz, and will have issues, typically with video, if this is not the case.

  MSX did come out with a 'faster' machine - the Turbo MSX.  They solve the compatibility issue by having 2 CPUs.   A stock Z80 running at the 3.5Mhz for compatibility and a R800 (basically a custom Z80, similar to the Z180/280 etc, that ran much faster).  Unlike the Z80, the R800 is not available today - at least not as a recently manufactured brand new item 

  The fastest Z80 this is available today, in DIP40 configuration is rated at 20Mhz (and can probably go faster).  A MSX running at 20Mhz - sounds super fast to this old-timer!

  The typical way for the Z80 to manage access to devices with slower timing requirements, is by triggering hardware wait-states.  So when the Z80 requests an I/O operation - we need to hold Z80's wait line active for a small number of clock cycles - allowing the communication with other devices to be 'slowed'. 
  

  The number of clocks cycles that need to be 'waited' is dependant on the speed of your Z80 and the timing requirements of the other chips.  For a generic designed circuit, suitable for a most situations, we need to wait for the slowest component in the system.

  But we also need to consider more than just the timing requirements for IO communications.  The Video (V9958) is a processor also - and when it receives commands from the Z80 - it will take its own time to process those commands.  The chip has its own clock - and as such will work through it logic, at its own independant pace.  

  So any software that assumes its running on a Z80 at 3.5Mhz, but is actually running at 20Mhz, will probably have severe video corruptions as it issues commands to the V9958 at a rate far too high.

  We could solve this issue by waiting (pausing) the Z80 every time it communicates with the V9958 VDP, but we would need a fairly large counter to ensure good operation.  

  Another approach to solving the timing requirements, is instead of using hardware wait states, we just simply 'slow' down the Z80's clock when it initiates any I/O operations.  That is, we switch the Z80 to the standard 3.5Mhz when it starts an I/O operation, and maintain that speed for a number of cycles, before resuming to full speed.  So from the view of the running software, its timing to the V9958 will be unchanged. When the Z80 goes on to do other operations - it will resume at full speed.  Well least that's the theory - there is only one sure way to find out if this works. 

   (The GR8BIT has published a similar mod for their system: http://kb.gr8bit.ru/KB0009/GR8BIT-KB0009-Accelerating-your-GR8BIT.html, so that gave me hope this would work)

  Of course, a Z80, doesn't just communicate with I/O devices - it also accesses RAM and ROM, across the RC2014 bus.  Will the memory chips keep up?  Will the RC2014 bus operate at this speed ok?  On the surface, the timing for the ROM and RAM chips will not work at 20Mhz - but if we note that although the Z80 is running at 20Mhz, it will not access memory at this speed.  Again, only way to truly know, is to try it out.

  So I came up with a design that has the following characteristics:

  1. use a 3 way slider to 'switch' the operation mode into...

  Read more »

• MSX Music

  Dean Netherton • 02/01/2022 at 23:50 • 0 comments

  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...

  Read more »

• Slot Extension for MSX Cartridges

  Dean Netherton • 11/23/2021 at 22:50 • 0 comments

  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.

• Backplane and Cartridge Extension

  Dean Netherton • 11/01/2021 at 23:09 • 0 comments

  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!

• Wifi Module update

  Dean Netherton • 11/01/2021 at 22:41 • 0 comments

  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

• Integrating the RC2014 WIFI Module

  Dean Netherton • 09/11/2021 at 23:56 • 0 comments

  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

• Update July 18th

  Dean Netherton • 07/18/2021 at 07:19 • 0 comments

  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!

• Serial Drivers and BBS

  Dean Netherton • 06/27/2021 at 01:32 • 0 comments

  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.

View all 32 project logs