Close
0%
0%

MSX on RC2014

in which I attempt to make an MSX1 compatible computer using RC2014, keeping to standard RC2014 backplane and modules as far as possible.

Similar projects worth following
Starting from
$44.00
shieladixon has 152 orders / 2reviews
Ships from United Kingdom
MSX was an early attempt to standardise home computers, initially based on Z80 processor, TMS9918A video chip and AY sound chip. The RC2014 is a Z80 modular computer with existing modules available for those particular video and sound chips. Dino has already achieved an MSX2+ using the RC2014 backplane but I'd like to achieve MSX1 compatibility using (as far as possible) standard RC2014 modules, a little hacking and the odd new module.
  • Addendum - MSX BASIC working without modifying ROM and RAM modules

    Shiela Dixon11/30/2023 at 14:08 0 comments

    This is merely a bit of a curiosity, I don't intend to explore this further now that I have a 'MSX2014' which works pretty well.

    However, I did state in my earlier logs and instructions that it's necessary to add slot selection lines to ROM / RAM / Cartridge ROM modules. I wasn't able to get BASIC working at that point without doing that. 

    At that point though, I'd been trying to use c-bios, which I believe was never going to work with BASIC anyway. Out of curiosity, I took a standard RC2014, minus the serial i/o module and plus my MSX PPI module and lo and behold:

    This is far from ideal, and I'm a little surprised that it's working at all, but it is working. 

    The first thing that the BIOS does is to switch in each slot in turn and see what RAM it can find (the longest contiguous amount of RAM that it can find, counting down from FFFF, is the slot that it will use for RAM. It also tests each slot to see whether a cartridge ROM is present. The slot selection won't work in this case and it'll see the ROM and RAM on every slot.)

    But it does start, and BASIC appears to work well. This is working at the standard RC2014 clock speed of 7.3Mhz.

    I assume that tape loading would work if I used my tape module (This would require a bigger backplane as the tape module depends on the AY sound module). Cartridge ROMs may work (again, haven't tried) if you make a rom with the BIOS in the first 16k and a 16k cartridge rom in the next 16k, and RAM in the top 32k.)

    Note that I've had to use the bigger 64k ROM module, jumpered so that my ROM (BIOS and BASIC) is seen in the first 32k. It may be possible to bodge the smaller RC2014 Classic ROM module so that 32k of ROM is seen, but I haven't gone into how to do that.

  • Yet another joystick module and a milestsone reached

    Shiela Dixon08/17/2023 at 13:31 0 comments

    Finally... the third iteration of the joystick module works without bodge wires. I've been using it to work on my hi-score for Monkey Academy. Beat that!!

    I've had no luck so far with the floppy drive module. I believe it should work but it hasn't yet. This isn't so important to me, just a nice-to-have if I can manage it.

    I'm calling this a milestone rather than a completed project because I do have an (ambitious) idea that I'm going to run with. I won't reveal that just yet until I've made some progress.

    Otherwise I'm just going to enjoy using my MSX2014 to do some fab things; use MSX basic, port some games to MSX cartridge, see which other RC2014 modules will work.

    Now that I have some complete sets of good boards for this project (including Omega keyboard pcb, not in the picture above) I'm listing those on Tindie.

  • Joystick ports and other refinements

    Shiela Dixon07/11/2023 at 15:04 0 comments

    This week I've received two new modules. 

    The first is something that I didn't really consider essential - especially after making such a nice mechanical keyboard. But I find that it makes games so much more fun (and I'm getting better scores!)

    The MSX standard allows for two game / general purpose ports. Like everything MSX, it's nowhere near as simple as reading a hardware port.  The ports are read via the sound chip (it has two configurable i/o ports of its own) with some multiplexing.  Therefore this module needs connections to the YM/AY module. I've made a ribbon lead which doesn't look too shabby. 

    We already have a similar ribbon between PPI and the keyboard, so the new one between the game port module and AY doesn't look out of place. 

    I've been exploring more games and have found a port of the 'fictional' Spectrum game, Nohzdyve, which I absolutely love on the Speccy and this version is even better. It controls a little differently. Rather than simply moving left and right (and continuing to move after you've let go of the key), you still continue to drift left or right, but more slowly than when you actually move left or right. It's hard to explain and not something you immediately notice but makes it more fun to play. Like most of the games I've tried, it supports the joystick.

    You can see from the picture above that I'm continuing to use a backplane 8. This is only possible with this new module:

    I'm calling this the 'spacesaver'. I respect Spencer's decision to keep the official RC2014 highly modular, but with this project I've found it a little frustrating that the CPU and clock should take two backplane slots. Here we have the Z80, a clock generator and a reset circuit on a single module. The 'enhanced bus' connections are there too if anyone wanted to use this with an enhanced-bus RC2014.  I've fitted this with a 3.58Mhz crystal so that it's specific to the MSX2014 project. The reset circuit means that I no longer have to press the reset button when I power up. 

    The whole thing looks very neat. You can see that I'm down to seven modules on a standard backplane 8 (I have a heatsink on my TMS video chip, unfortunately meaning that it hogs the slot in front of it). This works fine if I switch the cartridge ROM module with the tape module as needed (which are mutually-exclusive anyway).

    This setup is working beautifully. Unfortunately I've got to order a new version of the joystick module pcb because I had to do some troubleshooting there and found a connection I missed - the version I'm using has a couple of bodge wires. 

    Apart from that - what next? I'm not quite sure. I have been tempted to use an enhanced-bus backplane and put those joystick and cassette signals on the enhanced bus. I'm still sleeping on that one. I'd also like to learn about floppy interfaces and possibly get MSXDOS running with a Gotek.

    I guess I should get on with some of the software projects that I've started, which for me is the main point of building this computer. Here's some of the cool stuff that I've been messing around with. They include Conway's Life, using RC2014 modules with the MSX, type-ins from a book and from the web.

  • More programming / using RC2014 modules

    Shiela Dixon07/05/2023 at 20:46 0 comments

    One big advantage of building this MSX computer using the RC2014 backplane is that you can use many of the RC2014 modules.

    First I tried the 8x8 LED matrix. Using BASIC and 3.58Mhz it was a bit flickery, so it was necessary to switch to assembly. I then found my preferred way to work was assemble on my Mac and burn the program to a 'cartridge' ROM.

    This made quite a neat development cycle. These little programs are nothing to shout about but they do demonstrate that these modules work well with this computer and that it's perfectly easy to write code to use them.

    First I tried the Conway's Life that I'd already written for the 8x8 matrix on RC2014.  I thought that this would be little more than a copy and paste into a cartridge template*. In the picture below and in the video I'm using the full RC2014 clock speed of 7Mhz for the best flicker-free display and the fastest regeneration cycle.

    The biggest problem I had was due to me forgetting that any 'variables' declared within the ROM space would not work! They have to be replaced by a reference to a location in the RAM space. 

    I also had a few calls to the CPM Bios for things like keyboard input and screen output, but there are similar routines in the MSX BIOS.

    The video below shows my Conway's Life for 8x8 matrix running. It wraps both vertically and horizontally, as you can see from the glider.  Before that is an oscillator it came up with which has about 20 steps.

    Before that is a demo of my Simon game. I've switched back to the MSX clock speed of 3.58Mhz for that. I'm timing the beeps and animations using a delay, which of course has to be adjusted depending on whether the clock is 7 or 3 Mhz. A better idea is to use the TMS chip for timing which means that games or animations run at a predictable speed regardless of computer clock speed.

    This little game looks particularly good on the colourful Pride-edition digital i/o.



    * 'template' sounds a bit grand. All you really need is an org $4000 and a 10-byte header:

    There's more information about making a cartridge rom in the previous project log.

  • Processes for development

    Shiela Dixon06/23/2023 at 22:28 0 comments

    This may look underwhelming but it took a while to get here and I count it as a big win.

    Obviously I could have typed a few lines of BASIC to do this. Now that I can save to cassette or, more conveniently, my phone (see the last log), development in BASIC is sorted and that has its place.

    But how about working in Z80 assembly and making a cartridge ROM or .cas file? I haven't yet investigated what tools are available for assembling directly on the machine, but for practical reasons I'd like to use my favourite text editor and assembler on my modern machine.  But how about transferring that to the real hardware?

    One option is to make a .cas file. I don't know how to make a .cas image yet, but I've been using a tool called MCP to convert downloaded .cas images to .wav. It's easy to drop that onto my phone and load that into the computer via the tape interface.  I do have a tzxduino, which I've upgraded to maxduino firmware, which can play .cas files from SD card -  very convenient. I believe that will work, but it seems to be playing at the wrong baud rate and I'm having trouble accessing the menus on my particular device to alter it.

    Another option is to assemble my code to .rom, burn to a rom chip and slip it into the zif socket on my 'cartridge module', which is what you can see in the picture above. 

    This may sound clunky but it works very well indeed, you can see the procedure in the video below. A particularly nice aspect is that you can simply drag and drop the built image onto an emulator while developing/testing before going to the trouble of burning to the eeprom.

    It took a while to get to the point of building that rom image.  There are a few things to know. I'd sussed most of them out before finding this video which explains everything and filled in the odd gap for me. 

    Here are a few pointers in case you're doing this:

    • at $4000 there should be a 16-byte header, as described here. There's an id at the start and then a pair of bytes gives the 'main' address of your program, often $4010
    • it's necessary to pad your program to a total of $C000 for emulators to recognise the binary as a cartridge rom. an 'org $C000' at the end of your code should do it
    • The BIOS contains some useful stuff, eg setting screen mode and outputting characters.

    If you're interested in getting started, my 'hello world' is here

  • More tape shenanigans and a great storage solution

    Shiela Dixon06/10/2023 at 18:10 0 comments

    In my last log I thought I had a working tape interface. In fact it has taken a little bit more messing about in order to be able to save and load reliably. 

    I have a couple of tape players. I've had to replace a stretched belt in this one (a car boot sale find) but it now works really well. The record and playback levels seem perfect and the counter works perfectly too (it could still use a clean). 

    With reliable csaving and cloading,  I've been trying some BASIC development of my own plus a type-in from this book:

    It's a brilliant book, all about the amazing patterns you can get from a bit of maths and it has some type-ins at the end. These are written in QuickBASIC and  I assumed they'd need a lot of translation but I'm amazed to discover that they can almost be typed in directly (with the addition of line numbers and taking care of variables that start with the same first two characters). I'm only just getting familiar with MSX basic but some of the unfamiliar commands in these programs such as DEFDBL, PSET, PRINT USING and more  are all present in MSX basic.

    Having said that, the program doesn't run properly and I've got some debugging to do. I'm also not expecting this to produce a pattern as impressive as the ones in the book, but we'll see.

    Alternatives to tape 

    Having said that saving to real tape is working reliably now (which is good because the type-in program above is the best part of 100 lines) I've been thinking about better storage solutions.  I will investigate MSX floppy interfaces with a view to hooking up a Gotek. In the mean time, I've been thinking about developing a microcontroller-based solution that can sample and play back the signals. 

    That's become unnecessary since I've tried this and found it to work:

    I had to make a 4-pole trrs to 2 x mono jack adaptor, which was very easy and I'll publish instructions for that. (Don't judge my work, I used parts that I had to hand.) I've also had to tweak my interface design a little (technical detail - in order for my phone to detect the presence of a 'microphone' on the lightning connector and use that as an input rather than its own mic, the resistance between the mic and ground connections has to be more than a couple of hundred ohms, I discovered).  

    You'll also see that I now have my MSX tape lead (8-pin DIN to mic, ear and rem) thanks to Retro Computer Shack who make fantastic leads.

    With all that in place (and with the volume turned well up, which prompts some warnings from the phone's system about the health of your hearing) it works really well.  Another important note (as much a reminder for me as to inform anyone else trying this) is that it's important to switch the quality setting for your memo app from 'compressed' to 'lossless'. (Compression will diddle with your nice clean recording and produce artefacts which mess up the data.)

    It's brilliant being able to:

    • trim any blank space off the start and end of your recordings
    • name them
    • scroll through your recordings and access them with a tap
    • see the save date and time

    Obviously we're still saving and loading at tape speed* and have lost the 'rem' functionality (casette motor switch - I'm managing fine without it so far) but I'm thinking that I might even prefer this to a floppy emulator. 

    * I haven't yet tried the double-speed 2400 baud that the MSX offers yet, but I will.

  • Tape saving and loading

    Shiela Dixon06/05/2023 at 19:36 0 comments

    It's rare that a PCB is perfect on the first go. In the case of my PPI module, this is the third set of 5 boards and we're into minor improvements now.

    It's nicely refined now. I've gone for a latching connector. It's essential - not for latching the plug but for extracting it. The 'box' type are fine if you want the plug in there permanently!  I've been working on two keyboard solutions and therefore have been swopping. 

    I've added resistor arrays (pullups for the keyboard columns). Previously I had those on my keyboard interface but the Omega keyboard doesn't have them, so it seems sensible to move them to this end of the deal. There's one more improvement I may make yet - note those header pins labelled CO and CM.

    There's not much more to say about this module, it works just as well as the previous version. I really like the look of the latching connector.

    Tape module

    The second significant thing to report today is that my tape interface has moved off the breadboard and onto a pcb. 

    When I say 'moved off the breadboard', I had only built the input part of the circuit on the breadboard.  Here we have the output signal and the remote (cassette motor) switch as well. (I've used an SSR for that.)

    I've put the standard MSX 8-pin DIN on there and also the possibly more traditional 'mic' and 'ear' audio jacks. For the sake of the picture I've plugged them all in, but obviously you'd use one or the other.

    Nostalgia for cassette loading?

    If I wanted to re-experience the 'joys' of sketchy tape loading, boy I've had that today. I don't know how many times I've pressed 'play' on the tape and watched the screen hopefully but in vain.

    Initially I had nothing. Here are the problems I've found and fixed, roughly in chronological order.

    This is the lead I was trying to use at first. It breaks out the 8-pin DIN to ear, mic and rem  jacks.  This is the one I use for the Oric, BBC and Electron.  I may have given the pinout a quick look or I may have assumed that the pinout is the same for the MSX. They were trying to establish a standard after all. But it turns out they're not quite the same.  The MSX standard (which I worked to with my module) is almost the same but slightly different. Why would they do that??

    Not a big deal. I found this issue easily and have an MSX-compatible lead on the way from Retro Computing Shack. Plus I put ear and mic jacks on my module, so I can use those in the mean time.

    But I couldn't make those work either.  My breadboard circuit worked great for loading from real tape. My new module should have been exactly the same circuit but just seemed dead.

    After much time spent checking the resistor values (check the picture above, there are so many different values on that board!) I eventually noticed an error with my schematic. I'd worked from the reference circuit when building the breadboard version and worked from the same reference circuit to make my schematic. Except that i had missed two important connections - the op-amp's  v- and ground, both of which are tied to 0v in this case.  

    Two bodge wires later and we can load from a pre-recorded cassette (the only one I own for MSX!)

    Saving went more smoothly, or at least appeared to at first. 

    I had found this unopened blank tape in a charity shop about a year ago. 

    This seemed like the perfect time to crack it open!

    It appeared that my test program had saved successfully, I could listen back and it sounded pretty crisp.  

    But the computer wasn't recognising my saved programs. It would still load the commercial tape, so I assumed that it had to do with levels and spent waaaay too long trying different levels and two cassette players.

    Eventually I tried capturing the sound using a modern computer. This allowed me to view the waveform and see that the output signal was *really* puny. 

    By amplifying it up ( several times...

    Read more »

  • Tape loading

    Shiela Dixon05/26/2023 at 09:41 0 comments

    My original stated goal was to build an MSX1 computer but that's a bit vague. ie I don't really know when I've achieved that goal. What didn't say but always had in mind is that I really wanted to be able to load and play one particular game from tape. 

    My own nostalgia is for computers that had BASIC on startup and tape saving/loading, so I feel that the tape loading is an essential part of this project.

    The reference circuit I used has an op-amp to turn an audio signal into a logic signal. Here's the circuit on a breadboard, in which I had very little confidence.

    Imagine my astonishment when the game loaded on the first try....

    (It's a new-ish game from futurewas8bit on a multiformat tape. Playing it here on my MSX2014 has checked off one more format, leaving just one of the eight to go.) 

    t's a great game and this MSX version is a particularly good one. It's very addictive and my 'arrow key' hand ached after a while. This is the incentive I need to build the joystick circuit!

    The thing that I'm finding harder than building the working tape and joystick modules is how to organise them and how to connect them.

    Electrically it makes some sense to build the tape and joystick modules on one board.  But from a user point of view that makes no sense and gets away from the modular nature of this build, so I think they should be separate modules.

    But that introduces some problems with connections. The tape interface (assuming we want both loading and saving, which we do) involves one connection to the sound module (because sound chips weirdly also tend to handle some of the i/o) and one connection to the PPI module.  The joystick module also needs connections the sound module. 

    I've already used the spare lines on the bus for the very important slot selection lines.  I could use lines on the RC2014 enhanced bus, but I'd like this project to be buildable with the standard backplane. 

    While I think about that, I'm going to play more Rodman.

  • Some refinements, a first look at MML and a type-in

    Shiela Dixon05/22/2023 at 17:26 0 comments

    I've been having trouble fitting all of the necessary modules onto a backplane 8 and have had to use a Pro backplane with 12 slots. 

    I've tried to bodge an RC2014 ext-clock module* onto a Z80 module - it seems a waste to have those two basic things on separate modules. More than one person has designed a combined clock/Z80 module, so I may buy one of those. It doesn't help that some things hog two slots because of sticky-out bits.

    One contributory factor to the slot shortage is that the BIOS ROM, RAM and cartridge ROM  are separate modules.

    So the first new thing today is a combined RAM / BIOS module. 

    It replaces my bodged individual modules with a single nice neat, standard-sized and shaped module. The downside of this is that it gets away from my original goal of "using standard RC2014 components as far as possible". (the c-bios label is out of date. I didn't get that to work and see no point when the original MSX1 bios+BASIC is working so well).

    So here are a couple of shots of the machine as it stands, configured to run BASIC. Even with the separate clock* and Z80 modules it all fits neatly onto a standard backplane 8.

    Composite video isn't fantastic, but it does look better in real life than captured here on my phone's camera.

    I can even fit the 'cartridge ROM' onto that backplane. (That's still a bodged RC2014 ROM module.)

    In the shots above you can also see the other refinement. I've now got keycaps on my Omega keyboard, and wow, is it nice to use!  I picked up some Gateron swtiches at a great price. It's really fun playing games with it, the inverted T arrow key arrangement works well for me.

    I have yet to add stabilisers.  I didn't know anything about mechanical keyboards before making this one, it's a bit of a learning curve. But even without those, the longer keys actually work pretty well, even the space bar. My very cheap set of keycaps worked almost perfectly - the @ is in the correct place on the 2. There's even a keycap (to the right of the spacebar) with a symbol that works perfectly for the MSX 'select' key (an important key). All of this without a key having to be on the wrong row for its profile. Great work from the Omega project.

    MML

    Ed Brindley, the maker of the YM/AY sound module for RC2014 (an important part of this project as it handles some of the i/o as well as the sound)  mentioned to me that MML (Music Macro Language) was a bit of a rabbit hole. 

    It's a notation system for music and is supported by MSX BASIC. The musical notes and other information are contained in strings, which you pass to the PLAY command.  It allows for multiple voices and gives you access to the AY's envelope system (which isn't fantastic but does allow for some rudimentary FM experimentation). 

    I've had a look around for tutorials, and I found some good information in Graham Bland's book, MSX Programming.  Obviously the examples have to be typed and so what better way to test my new keyboard?!

    There's quite a long example (program 7.10 on page 112 in the book) and so I made a cup of tea and got started!

    I video'd the whole thing. Fortunately the camera kept rolling for the whole half hour and the result is not as disappointing as you might expect a type-in program to be. 

    This may be the most boring video on Youtube if you're not interested in MML or MSX BASIC, but here it stands as a record of my first real test of the Omega keyboard and MSX BASIC's MML capabilities.

    * The RC2014 dual-clock module is great for this project because it allows you to jumper the clock to 3.68 Mhz which is very close to the MSX standard 3.58, plus you can switch to 7.3 Mhz to give MSX BASIC a real boost. For perfect compatibility I've made myself a 3.58 Mhz clock module on a spare RC2014 ext-clock board and tend to use that cor compatibility / authenticity.

  • Working keyboard options, usable BASIC and playable games

    Shiela Dixon05/13/2023 at 10:14 0 comments

    In the last log I proved that an altered version of my USB keyboard interface could work with MSX. It was on breadboard plus a heavily-bodged Minstrel keyboard interface. 

    I've put that onto a pcb so it now looks self-contained and neat. I've also developed the software to a point where it's working well, with a few things to sort out. Here it is in action, It has a serial input, so BASIC programs can be pasted in via a terminal. Here's a drum machine program, originally published in MSX Computer Magazine in 1986 and now available for download at  http://marmsx.msxall.com/basic/revista/english.php



    Obviously after entering the program, I'm using the USB keyboard to run and use the software. 

    The USB keyboard adaptor is in the shape of a standard RC2014 module and has the footprint for the backplane connector so that it could sit in a spare slot for neatness. It doesn't need the connection to the backplane, so could just swing in the breeze as here (or sit in a smaller separate backplane) 

    This is a great solution, it's cheaper than  building a dedicated MSX mechanical keyboard and it has the serial input feature. The elephant in the room is that it uses a microcontroller which is way more powerful than the target computer. Replacement parts or add-ons for 8-bit computers which use microcontrollers are nothing unusual today but it doesn't feel ideal to me. 

    Here's a shot of the computer as it stands. When using BASIC as above, the whole lot fits on a backplane 8. In this shot you can also see the Mk2 PPI module which now contains some logic previously on a breadboard. I've had to bodge on a resistor network for pullups on the column lines, so this still isn't the final version. I'll probably also fit a right-angled connector so that this doesn't hog two slots as here.

    In order to explore all of the options, I'm also building a mechanical keyboard. The Omega keyboard exists and works with this project. I've managed to order all of the parts for about £40 (and now have some spare pcbs). It has the special keys such as select and stop (required when using programs and games) and it has 'inverted T' cursor keys which work well with all of the games that I've tried.

    This is a work in progress, obviously the keycaps haven't arrived yet but it's perfectly usable. Here's another video of me playing a few games. I've switched to a Pro backplane because I need a 'ROM cartridge module' plugged in. I've now fitted a ZIF socket and have put a few games onto separate rom chips, so switching cartridge games is really quick and easy. 

    Here are some shots of some other favourite games I've already burned to rom chips

View all 16 project logs

  • 1
    Introduction and some important notes

    I love the RC2014's modular form factor and the fact that it's an 8-bit computer built from new parts.  However, my own nostalgia is for character graphics and bitmapped screens rather than terminals and serial i/o. For me, the addition of sound and video cards takes the RC2014 to another level. 

    RC2014 kits available from z80kits.com
    RC2014 kits available from z80kits.com

    The MSX1 standard specifies TMS99xxA  video chip and AY sound chip. Modules already exist for the RC2014 that use these chips.

    I should be totally upfront about the fact that my own goalposts have moved a bit. I began my Hackaday project with the statement: "I attempt to make an MSX1 compatible computer using RC2014, keeping to standard RC2014 backplane and modules as far as possible".  Although my attempts at hacking standard modules such as RAM and ROM were successful, I've gone on to design custom boards (for reasons that I'll discuss when I come to those parts in the instructions). The only original RC2014 part left in my own MSX build is the backplane, since I have  designed a combined CPU/clock/reset module.

    MSX pacman
    MSX pacman

    Having said that, this instructable takes a staged approach, starting with a working RC2014 (classic 32k, Pro or Zed) and transitioning to an MSX1-compatible computer, switchable back to RC2014 by swopping out modules for the original ones.

    Some reasons why this may be for you

    • The modular nature of the RC2014 makes this highly customisable and upgradable. It means that you can build the computer in stages, which is the way I've written the instructable.
    • It also means that you can easily plug in regular RC2014 modules (for example, digital i/o ) and use those via MSX basic or machine code.
    • If you're already invested in the RC2014 world, you'll already have a backplane and some modules such as clock and CPU.  You may already have the TMS video card or the AY sound card. You could modify other existing modules such as ram and rom.

    Some reasons why this may not be for you

    • If you're not already invested in the RC2014 world, this is not be the most economical or compatible way to build an MSX computer. 
    • Please also note that this project aims to build an MSX1 computer. Some of the more impressive software, demos and games out there may be MSX2 or MSX2+ which have better video and sound chips.  
    • Dino's yellow board MSX and the Omega project are both MSX2+ computers that may suit you better. (Omega is open-source, the yellow-board project has schematics.)
    • If you've started to build the yellow boards, no, my modules don't attempt to be compatible and mixing the two projects isn't supported.
    • This project won't be open-source. I will be supplying everything you need and I prefer to sell assembled and tested modules rather than kits. I am also supplying a set of PCBs if that's your bag.

    Overview of the staged approach

    If you're still with me, this instructable takes a staged approach, outlined below. 

    First stage: RC2014 + video & sound (aka RC2014 + TMS + AY)

    There is a small library of software and example code for RC2014+TMS video card (and in some cases +AY card). I am actively adding to it and J B Langston's library is excellent. Porting programs and games from other Z80 systems with similar screen resolutions is easy and I found porting 3D Monster Maze lots of fun.

    Second stage - a working MSX1 with BASIC

    The conversion to MSX1 by adding PPI, keyboard and BIOS/BASIC ROM gives you an advanced version of BASIC which includes commands for the screen modes, graphics functions like circle and line and the Music Macro Language (MML) for writing music . You could even give this BASIC a boost by using the RC2014 7Mhz clock.

    Third stage - cartridge games / software

    Adds a cartridge module which allows you to burn and run MSX1 16k and 32k rom images, including your own software if you write Z80 assembly. This opens up much of the huge library of software and games for MSX1, some of which look and sound fantastic and are very playable. 

    Fourth stage: tape saving and loading, joystick

    More optional modules.

    What you'll need

    If you don't already have an RC2014 then buying an RC2014 kit and then the parts for this project will not be a cheap way to build an MSX, as I've already said. 

    Any of the 'backplane' RC2014s will be fine - classic 32k, CPM or Zed Pro. I have tended to work on a backplane-8 (with standard bus slots) and the smaller classic modules when building mine, but it does quickly become a squeeze when we start to add MSX ROMs / RAM / PPI and you will probably need to consider extending your backplane 8 (by connecting a 5 or another 8 ) or upgrading to a backplane 12 at that point. 

    You may already have an RC2014 TMS video module and RC2014 AY sound module but if not, you will need those. (Note that there is a complication with the sound card - the R5 AY card uses ports considered traditional for RC2014 but can't be jumpered for MSX ports. The newer R6 AY board can use MSX ports but not the traditional RC2014 ports.) 

    To go beyond RC2014+TMS video card, you will need to be able to burn a ROM image to an EPROM. (the MSX1 BIOS and BASIC as well as any cartridge ROMs or your own software that you want to run) The ROM images can be found online but I don't have the rights to distribute them. 

    There are other core modules which are definitely required, such as the PPI and some kind of keyboard solution. There are some optional modules such as the dual-joystick and tape interfaces.

  • 2
    Adding video and sound cards to RC2014 aka RC2014+TMS+AY

    In this step we will add the video module and optionally the sound module at that point you'll be able to run demos and games written specifically for this setup. Unless you want to run MSX BASIC or MSX games then you may want to stop there.

    RC2014 + TMS

    The TMS9918A is a very capable chip (as used in many '80s computers including TI-99, Colecovision, Memotech MTX and MSX). It has a text mode, tile mode, multicolour bitmap mode and 32 16x16 sprites. Video RAM is 16k of dedicated RAM which is in addition to your machine's regular RAM and communication with the video ram is very fast.

    Be aware that the chip is no longer made. I have found that it's easy and cheap to get hold of and the ones I've bought do appear to be genuine.

    The module I recommend is by J B Langston and is open-source.  He recommends and approves the kit from Michael Kamprath and I also have permission to sell assembled modules, which are complete with TMS chip and thoroughly tested.

    Port settings

    There are several configurations available which are more thoroughly detailed on Mr Langston's Github page. Here is a simplified guide with the relevant ones for this project.

    For 'classic' 32k RC2014 (specifically with ACIA/68B50 serial) I recommend Tatung Einstein ports, 08/09:

    For CPM RC2014, I recommend the MSX ports 0x98/0x99:

    (Note that the Github page for this module says for J4, MSX "3rd from right" but the setting is as above which I feel is best described as 'fourth from right').

    Mr Langston's repository has software examples, his library is brilliant. If you want to write your own Z80 or C code targeting this video chip then I highly recommend using that. 

    Depending on your configuration, you may have trouble building and running those, so for convenience I have provided pre-built examples for 32k RC2014 and cpm. (For ROMWBW, you will have less trouble with J B Langston's examples).  My examples also include my port of 3D Monster Maze and my own game. I'm working on Mazogs and there may be others.

    If you want to use the library to write your own code, one important note is that in tms.asm,  TmsProbe: will check a list of ports to detect your card. One of the ports on the TmsPorts:  list is 0xBx and if you're using CP/M then this conflicts with the ROM/RAM paging and unfortunately the code probes this port first. You will need to take that port out of the list and make TmsNumPorts equal the number that you want to leave in. Or just put your port number in TmsPort: and leave out the call to TmsProbe:

    At this point you'll still be using the terminal as before when the computer starts up and loading the programs in the way that you usually do (I'm providing IHX files for the 32k machine and .coms for the cpm). The composite out should give a valid but black signal, 60Hz if you're using TMS9918A. When your program runs, it'll use the TMS display.

    Try a simple demo like "ascii" first to make sure that your card is working. Other demos will demonstrate other aspects of the  chip such as bitmap mode and sprites. 

    Adding AY

    I recommend the YM/AY module by Ed Brindley, which is also open-source.

    This card has been around for a long time and is popular in the RC2014 community. 

    But please note that revision 5 and earlier can be jumpered to ports 0xD0 and 0xD8, which I consider 'standard RC2014 settings', and most of the RC2014 software will expect to use those ports.

    MSX uses ports 0xA0 and 0xA1.  Unfortunately, there is a complication here. The older AY boards can't be set to these ports. Ed has revised his design and the R6 board can use MSX or Spectrum ports, but not the established RC2014 ports. 

    What this means is that 

    • If you have an AY card already, R5 or earlier, then you'll be able to use it with the RC2014 setup but it won't work with MSX software. 
    • If you're writing and building your own software and sticking with the RC2014+TMS+AY setup, then this isn't an issue because you can configure your software to use the ports that you have. 
    • If you want to go forward with the MSX build then you'll need an R6 AY sound card.

    The only demo that I have (so far) for RC2014 that uses both AY sound and TMS video is the Nyan Cat demo, which is well worth running. The builds in my own collection currently use RC2014 ports, though I will be adding built examples that are configured to use the  R6 AY sound card on MSX ports. 

     (interesting note: The Nyan demo makes use of the little-used 'multicolour hires mode' which can set any 'pixel' to any of the 16 colours, but those pixels are huge - 4x4 - see below.)

  • 3
    A working MSX1 with BASIC

    The conversion to MSX1 by adding PPI, keyboard and BIOS/BASIC ROM  gives you an advanced version of BASIC which includes commands for the screen modes, graphics functions like circle and line and the Music Macro Language (MML) for writing music. You could even give this BASIC a boost by using the RC2014 7Mhz clock.

    Clock options

    If you have an RC2014 dual clock, this is ideal. You can jumper it to a near-MSX-speed of 3.68Mhz (MSX spec says 3.58). You also have the option of giving your MSX BASIC programs a boost by running the computer at full RC2014 speed 7.3Mhz, which appears to work fine.

    I have built myself an MSX clock module using a spare RC2014 clock pcb fitted with a 3.58 crystal, actually 3.579 which was the closest I could get (in my case the small 'ext clock' pcb which isn't available any more but any of the RC2014 clock module PCBs will be fine) .

    Spencer has no plans to design an official RC2014 combined clock/CPU module so I've recently designed myself a 'spacesaver' CPU+clock+reset circuit. This saves a slot, and if you're using a clock without a reset circuit then that's a nice-to-have. I'm currently supplying this board as part of the set of 9 MSX2014 boards.

    CPU options 

    Any RC2014 Z80 module should be fine. I've run this project using a classic CPU module as well as the standard CPU module from my Pro. These do little more than connect your Z80 to the bus.

    See the above comments about my spacesaver CPU+clock+reset.

    PPI module

    You will need a PPI (programmable peripheral interface) which is the i/o logic. It's based on the 82C55 chip which is now out of production but hasn't been out of production long and so there's plenty of new stock about. This provides three programmable ports which the MSX uses for keyboard scanning, memory slot selection and provides some other lines such as cassette output and key click. 

    This project uses 4 spare backplane lines to carry the decoded active-low slot selection lines, which makes it very easy and neat  to have a RAM or ROM module be selected according to the appropriate backplane bus line. 

    I am supplying this module built and tested. Optionally with the ROM/RAM and cartridge modules as discussed below.

    It connects to the keyboard using a ribbon cable with IDC 8x2 connectors. That latching connector is important because it helps with extracting the plug which can be tight.

    Keyboard options

    The system scans a matrix of up to 11 rows and 8 columns (it contains various control and modifier keys and can contain a numpad if you want). As usual with the MSX, you can't just hook up switches, there's a certain amount of multiplexing involved. The PPI provides the bi-directional ports and the keyboard itself needs to do some decoding (rowA-D into row 0-11). 

    The Omega project has a separate keyboard which is entirely compatible with this project and I found it surprisingly cheap to build. I found a set of Gateron switches on eBay for £20 and bought some very cheap keycaps for £6 which almost entirely have the correct symbols (eg @ sign on the 2 key).  I love using this keyboard (see picture above). It has a modern layout and has the important keys for using MSX BASIC and some games (eg 'select' and 'stop'). In order to make mine I obviously ended up with some spares, speak to me if you're interested in one of those.

    I've also designed a USB keyboard adaptor which works surprisingly well. The circuit is solid, it just needs some wrinkles ironing out in the firmware. One downside of this solution is that it uses a microcontroller, something I'm not particularly keen on in retro computing. Some upsides are that it's a cheaper solution than building a mech keyboard and that it also has a serial port so that you can paste basic programs via a terminal. If you're interested in one of these, please speak to me.

    BIOS/BASIC ROM and RAM

     You will need one ROM containing the MSX1 BIOS which is 16k starting at location zero, and the MSX BASIC which is another 16k starting at $4000. You can obtain this as a single 32k image online, contact me if you're unable to find it.

    [EDIT]

    These instructions originally said that it was necessary to use modified or custom ROM and RAM boards, because the slot selection lines are essential. However, I've since had an 'MSX2014' working with standard unmodified RC2014 ROM and RAM modules. See the project log here.  It's far from ideal. BASIC works, tape loading may work, some cartridge roms may work, but it won't be as good as using RAM/ROM modules with slot selection.  You may like to try that though as an intermediate step. 

    [/EDIT]

    My boards are designed to take the 27C512 EEPROMs, which are 64k and you can program over and over.  These are not in production but not too difficult to find. And the 62256 RAM which is in production and easy to obtain.

    You will also need 32 or 64k of RAM (if 32k, it must start at $8000). 32k is fine, some games may use 64, but it's not common or easy to use the extra 32k because that involves using the BIOS routines to do the switching. I may eventually extend my RAM/ROM module to have the full 64k.

    It's important to know that the MSX is designed to have 4 'slots' for RAM and ROM which can each potentially be 64k. This isn't simply 'mapped', but 'sideways' - you can potentially have 4 x 64k, selected as needed. You'll see from the information above that even with a simple system there can easily be some overlap. The PPI and the slot selection lines are required to manage all of this.

    I began this project by bodging existing RC2014 ROM and RAM modules as this fitted with my original goal of using as many standard RC2014 parts as possible and I did plan to give full instructions for doing this. There are many reasons why this is very difficult and it makes much more sense to drop in specially-designed modules:

    • The bodged modules look very untidy
    • Spencer does not supply kits or pcbs for the core modules like ram and rom
    • The MSX ram/rom modules are simpler than the RC2014 - less logic needed
    • The modifications are reversible but not easily. Much easier to have a set of MSX RAM/ROM modules and a set of RC2014 modules
    • There are many versions of the RC2014 modules with different layouts and that's not counting third party modules. Telling you which points to connect and which pins to fold out is impossible without identifying your particular module and studying its schematic.

    Instead I propose including the pcbs for my own MSX2014 RAM/ROM and cartridge modules with my PPI module. These consist of one standard-sized module which holds the BIOS/BASIC ROM and 32k RAM, and one 'cartridge ROM' which has a ZIF socket for game ROMs. (dealt with in the next step).

    If you do wish to go ahead with modifying your own ROM / RAM modules then here is an outline of the information you need:

    • My PPI module uses the spare 4 bus lines (pins 37-40 bus) as 'active-low' slot selection lines. 
    • Bus pin 37 is designated 'SLOTSEL0' and should select your BIOS ROM, which contains the MSX BIOS/BASIC at $0000 to $7FFF. When high, should leave that ROM disabled
    • Bus pin 40 is designated 'SLOTSEL3' and should select your RAM. This can be 32k in the upper 32k, or 64k in the full address space. When high, should leave the RAM disabled.
    • Bus pins 38 and 39 are designated SLOTSEL1 and 2. Your cartridge rom should be selected when one of these lines is low. 16k and 32k cartridge ROMs usually start at $4000 although I don't think this is a firm rule. The easiest way to achieve this is to connect or jumper your 64k ROM so that it starts at $0000 and burn the chip so that the data starts at the right place (usually $4000)
    • Always use a spare logic gate on the existing rom or ram module to include the appropriate SLOTSEL line in the chip's chip or output enable.

View all 5 instructions

Enjoy this project?

Share

Discussions

Shiela Dixon wrote 06/18/2023 at 12:00 point

That's good to know, thank you. Is there any reason why those specifying the MSX1 standard chose the NTSC frequency? The TMS video chip that they specified (VDP) requires its own signal of ~10.68Mhz and has its own crystal in MSX computers (and J B Langston's video module which we're using here). I don't think the original MSX machines (from various manufacturers) always stuck exactly to the 3.58Mhz.

  Are you sure? yes | no

Keith wrote 06/18/2023 at 11:29 point

The correct frequency is the NTSC colour carrier which is exactly 315/88 = 3.57954 MHz with the last two digits recurring. It tends to get referred to as 3.58 MHz but it will be the NTSC frequency. 4xNTSC = 14.31818 MHz is also a common frequency, you can divide that by 4 or 2 to get 7.15909 and 3.57954 MHz respectively.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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