MSX COMPATIBLE BOARDS FOR RC2014

Art is never finished only abandoned

Don't worry - I haven't abandon the project.

I've been working on the MSX Music Module (and listed a new revision in my Tindie store).

This revision further reduces some of that annoying digital background noise that could be heard when no music or sound playing. Its still emanate some background noise -- I think it be very hard to eliminate as so much of the various RC2014 modules will generate a lot of EMF noise.

The latest revision (1.9), increases the gain of the op-amp stage and adjusted some of the capacitors on the feedback. This seems to improve the signal to noise ratio, and it also improved its higher frequency responses.  Its sound much brighter.

Updated schematic on the github

Can you tell the difference between these modules - they are both sold as CH376 Modules?

Both were purchased from ebay/aliexpress traders. Both are sold as CH376 modules.  Both have the same CH376 chip.  

The one of the left though, has a different pin out.  Notice the 2x3 header pin.  Whereas, the one on the right only has a 1x3 pin header.  And just to add to the change,  the main headers have been swapped.  For the left/original, the outermost pins are the data lines, and for the right, its the inner most pins.

This alternative form-factor is not compatible with my PCB design.

On my Tindie store, I had packaged up some kits - and only at the last minute did I notice this very different pinout/form factor change.  I very nearly sent out kits with an incompatible module!  

I have not been able to source any more of the module as shown on the left.  Only seem to get the one on the right.  

It now seems that the ebay/ali-express traders are only selling the one on the right -- even if their product page shows the original 2x3 pin header.  You just can not trust what you will end up getting. 

So I had to redesign the PCB for my Cassette+USB kit to accommodate the change.  As this is just a form factor/pin out change - the software and electronics all still work the same.  Only need to re-route and reposition the cut outs on my PCB.

So now I have 2 PCB versions for this kit, to accommodate the 2 form factors:

I have just assembled a kit using this new module form factor - and so far all seems to work just fine.  I do need to do a bit of testing to double check everything.  So if u are waiting to get one of these kits - I can hopefully have new stock listed next weekend.

I have been updating the USB software over the last week or so and making some progress with support for additional hardware types.

USB Keyboard

I managed to get a USB keyboard to work.  At this stage, it has very limited functionality.  (arrow keys for instance don't work).  But I was able to boot and control the kit without the matrix keyboard attached - using a USB keyboard only.

Almost certainly, few games would work with the USB keyboard, but MSXDOS/NEXTOR and CP/M apps seem to work just fine.

The kit would need the PPI card (part of the keyboard kit) as without the PPI, the system will not boot. 

I still need to add extra support - arrow keys, caps lock -- and I do wonder if I am able to control the keyboard's capslock LED.

FTDI Serial Adapter

This one is interesting.  Have a couple of USB/Serial adapters I've used to connect my PC to the original RC2014's SIO/2.  But I thought, can I now go the other way?  

But this USB adapter is a vendor specific class.  That is, the USB protocol to control the adapter is not part of the USB specification - its the manufacturer's proprietary protocol.  I could not find any published specification - but there is the public Linux driver for it. The code is quite simple, and so by reviewing that code, it was quite easy to figure out how to configure the adapter and send/receive data over the serial chip.

This is still very early in the development - managed to get some experimental code to do a loop back test - (connect the TX/RX lines of the adapter).  The code confirms what it sends is also what is receives.  Have this operational at baud rates up to about 38400 - I think I can go higher!

I've only coded for the specific FTDI 232R chip - as I don't have any other chips to test and verify.  Including from other manufacturers. 

Also I am starting to run out of ROM space.  All my USB code, mostly written in C using Z88DK/SDCC compiler needs to fit in about 16K.  I am at about 15K!  All part of the challenge.

Okay,

This one has been quite an effort to get here.  But I finally have a version of the Cassette/USB module completed.  About to list the product on Tindie.

It was a huge effort developing the software for it.  There was a lot of 2 steps forward, 1 step back, 1 step side, and a few loop-do-loops!

Learning how USB protocols work for floppy, flash thumbs drives and old magnetic external HDD has been quite a journey.

After this massive effort, I can now :

1. Load a BASIC program from cassette (and save), then save it to a USB Flash drive. 
2. Boot MSX-DOS/Nextor from a flash drive (and use the same drive on my PC for quick file transfer)
3. Read and write to 1.44MB and 720K 3.5" Floppy disks
4. Format the floppies

And also - something that I think was kind of cool.  I got a USB to Centronics adapter and can now print to my 9pin dot matrix printer.

I have released on new ROM image on GitHub, that has all the new drivers and software.

More info at: https://github.com/vipoo/yellow-msx-series-for-rc2014/tree/dev-msx-usb-4/cassette-and-usb#msx-cassette--usb-module-designed-for-rc2014

Product will be on Tindie soon:  https://www.tindie.com/products/dinotron/msx-cassette-usb-module-designed-for-rc2014/

Its been a while since I posted here about the project. 

I have been really struggling to find the time (the usual suspects, work, life etc)

First, I want to express my thanks to everyone who has taken an interested in my little project, liked/commented here on Hackaday or purchased some of my kits.   Your encouragement and support is fantastic and much appreciated.

And with that, I was finally able to dust off the soldering iron and get back into developing and updating stuff.

I am working on 3 main tasks at the moment.

1. A new revision for the Video Module to support the V9938 chip.
2. A new revision of the MSX Music module that reduces the idle background noise caused by nearby digital signals.
3. And a new kit under development, the USB Module (based on the CH376 module). 

And I also managed to restock my Tindie store.

V9938 version of the Video Module

When I was restocking my store recently, I needed to source some new V9958 chips.  I found that the price for the chip has gone up a lot - at about $45-$50 USD.  That seems like its doubled in price since I started this project.  This would have been a better investment than an AI company! 

But the previous generation video chip, the V9938, still seems to be generally easy to source and at a lower price.  

One day though, these chips will become virtually impossible to get.

Given this, I decided to update the Video kit to enable support for the V9938. (I guess that makes it more retro!).

I also redesigned the power filtering and re-arrange the layout a bit to help reduce noise leaking into the video signal paths.

The V9938 has some minor differences to the V9958.  

It has features that were removed in the V9958, such as a mouse interface (I don't think was used very much) and direct support for a composite video out.

Graphically the V9938 does not support the 'near true' colour screen mode.  It also lack the support for smooth horizontal scrolling that some games took advantage of.  But it still offers a very similar capability, including all the other screen modes, sprites and memory support.  Its programmed in the same way, so the software and games just work.

Hopefully I can have this new revision listed in my Tindie store soon - with schematic and more details to follow.

New Revision of the MSX Music

One of the things I was less than pleased with this kit, is its susceptibility to the digital noise and nearby EMF interference, causing buzzes and hums to be heard when no music was playing.  This was especially noticeable when running the Z80 at the 20Mhz speed. After experimenting with a few inductors and capacitors, I managed to isolate a good chunk of the noise.  Its now much better.

I am perhaps starting to run the YM2413 audio chip at closer to its minimum power specification.  The low pass filter applied to isolate the digital noise, does drop the voltage a little.  If you combine perhaps a slightly lower than 5V source, some general loss in the backplane power rail - we start to approach the minimum spec voltage of 4.75.  But I think there is enough headroom to ensure its always above spec.  I have done lots of testing, and all seems rock solid reliable. 

The USB Module

This has been my main focus over the last few weekends.  The amount of effort applied to get this working is rather ridiculous when I think about it.  I was beginning to wonder if I was insane trying to get this to work.  Most of the effort is in the software.  I have had to learn a lot about USB protocols as well as the specific USB floppy and thumb drive protocols.   Not to mention figuring out how to enumerating devices plugged into hubs.

The CH376 module seems capable enough, but the documentation did leave me pondering a lot.  

Trying to fit all this USB protocol logic into a page of the ROM (approx: 8K) was also a challenge.  The poor Z80 was never meant for such heights.  But it continues, like me I suppose, to learn new tricks!

So far, I have implemented support for USB Hubs, up to four storage devices (mass storage thumb drives and other USB HDDs), floppy drives.  And just last week, I managed to get my MSX to print to a 9 pin dot matrix Centronics printer, using a USB to Centronics adapter cable.  So now my lab echoes with sounds of impact printing.  Oh Joy!

The current PCB requires a few bodge wires, so I need to get a new PCB manufactured and tested.  Stay tune for more details on its development.

If you have read all the way to hear, thanks - i hope you found it interesting...

I will try and keep updating the journal and provide more details of the project updates.

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/

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)

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 1 of 3 modes:

• Mode 1: Lock the CPU at 3.5Mhz - i.e. standard MSX compatibility mode
• Mode 2: Run CPU at 20Mhz, with clock slowed down for I/O, and additional memory request wait states
• Mode 3: Run CPU at 20Mhz, with clock slowed down for I/O, and fewer memory wait stats

2. When operating in Turbo Mode, the Z80 CPU and CLK1 and CLK2 bus lines are using independent clocks

3. Use PLDs to allow me to configure the number of wait states and clock slow down periods - so I can optimised the timing

4. I calculated that I would need to hold the clock slow for about 32 (@3.5Mhz) cycles upon any I/O operations to ensure that existing software will not overload the V9958

5. Use a socket for the 'Turbo' oscillator, so I can replace it with alternative values to allow for testing and experimentation

6. Have jumpers so I can select speeds for CLK1 and CLK2 bus lines as well as whether Turbo mode uses the onboard oscillator (20Mhz) or the 7Mhz clock

7. The RC2014 CLK1 and CLK2 are configurable as per the stock RC2104 dual clock module

8. Using higher speed CMOS chips were required to operate at the 20Mhz speed

9. Integrate a clock synchronising circuit, so that when we switch from 20Mhz to 3.5Mhz, that the phase differences are handled ensuring the Z80 always has a clean clock.  I stole the design from (http://www.6502.org/mini-projects/clock-switching/clock-switching.html)

Results:

• With Turbo Mode 3, my RC2014 in MSX configuration, boots into MSX-DOS perfectly and much quicker.  MSX-BASIC works perfect in Turbo Mode.
• Testing on a stock RC2014 also works - CP/M and MBASIC work just fine.
• Serial communications now run much faster.
• Had Pacman running just fine in the Turbo Mode (running using SOFAROM).  Seems to me to run at exactly the same rate.  So there is no advantage.  
• Other games, loaded in RAM via SOFAROM,  also work just fine.
• External cartridges typically don't like working in Turbo Mode - the old memory chips cant cope.
• My MegaFlashRom also did not like Turbo mode. 
• When slider is in Mode 1 (compatible 3.5Mhz) - everything works as standard.
• Ran some MSX benchmark utilities - and according to those I have a much faster MSX.

Here is a video of the module in operation, in an MSX configured RC2014. 

One gotcha

I discovered there is one issue with running in Turbo CPU mode.  In particular the SIO/2 module would not work correctly and I could not get serial communication to work.

The Zilog SIO chip (and other Zilog chips), have a requirements that their supplied clock is the same as the CPU Clock.  When operating in Turbo Mode, the Z80 clock and the SIO/2 (driven by CLK1) are not in sync as per the SIO/2 requirement.

The SIO/2 needs the clocks in sync, to enable a feature where the SIO/2 chip will release it interrupt state automatically.  It does this, by inspecting, via the data bus, what instructions the Z80 is executing.  It's looking for when the Z80 has executed the RETI (Return from Interrupt) instruction.  When it see this, it can then release its interrupt state/latching flags.

If it doesn't see the RETI, then the interrupt triggering will not work correctly.  In the case of the SIO, you get one interrupt when data comes in, but there after, no more interrupts will be raised.

By running the Z80 clock asynchronously to the SIO/2, the SIO/2 is not able to inspect the Z80 operation.  The SIO/2 will not know the Z80 is running at a different clock, and so might even see what it thinks is a RETI - when in fact the Z80 did not finish its interrupt handling*.  

To get serial communication working, in Turbo mode, I found 2 solutions that can be used:

1. Prior to executing the RETI, we perform an I/O instruction, thus dropping the Z80 down to 3.5Mhz in sync with the SIO/2.

2. Explicitly tell the SIO to unlatch it interrupt flag.

For MSX, I had to go with the 2nd option in my serial driver.  Option 1 would be difficult to implement, as it requires changing the interrupt handling code in the system BIOS.   As the MSX standard does not use any Zilog I/O I think this is fine.

For RomWBW, I will need to submit a patch to Wayne Warthen, that integrates the changes as per option 1.

* My experiments to date, using option 1 and 2, have produced very reliable and fast serial communications - so I gather that this is not really a problem.

I will add this module to my Tindie store soon.  The GitHub site for it is on my dev branch at: https://github.com/vipoo/yellow-msx-series-for-rc2014/tree/dev/turbo-cpu