• Tape loading

    Shiela Dixon • 6 days ago • 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 Dixon • 05/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 Dixon • 05/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

  • Keyboard - option 1, USB adaptor

    Shiela Dixon • 04/27/2023 at 13:05 • 0 comments

    There are a couple of options for the keyboard. 

    One is to develop my USB keyboard adaptor.  The MSX scans more rows and columns, but otherwise the functionality is very similar.

    The other is to build a mechanical keyboard. Others have done this already and published the details (Dino boards and skiselev / Omega) so there would be no  need to reinvent the wheel.  

    I'm going to go down both routes to get a handle on the cost and the pros/cons of each.

    The Omega project has a separate keyboard with standard MSX connector, so it's easy to simply order the board & parts and build one. While I'm waiting for my boards from China, I'll work on....

    My USB keyboard adaptor requires some enhancement. To start with, the 'row' lines are encoded and need decoding. (4 lines on the keyboard connector, can be decoded into 9 or more rows). That's easy with 2 x 74138's or a 74145. Then there are the extra rows and columns (the interface was designed for the Minstrel 4th / Jupiter Ace, which has 8 half-rows of 5 bits in its matrix. The MSX has 9 rows minimum (without numpad) and 8 columns). This means some extra logic. You can see all of this here on a breadboard and bodges to my minstrel keyboard adaptor. What I'm trying to do here is to prove that it works before designing a pcb for the USB adaptor.

    Obviously the keyboard logic will be included on the keyboard adaptor, with caps lock LED, keyboard-click buzzer and the proper MSX keyboard connector, so it'll connect with a ribbon to the PPI module and obviously via USB to the keyboard. 

    (Also on the breadboard there is another 138 which is used for decoding the slot select lines - see an earlier log.  I already have new boards on the way which include that on the PPI module.)

    Here is a movie of this in action, it demonstrates the 'paste over serial' functionality which is a great alternative to saving/loading. 

    Pros and Cons of the USB keyboard adaptor

    • Convenience - it allows you to use whatever USB keyboard you have around
    • Layout - type using the layout of the USB keyboard that you're used to
    • Speed - it buffers the keyboard input and allows you to type very fast, keys are entered at a speed that the computer can accept. Until I've built the mechanical keyboard, I don't know whether this is such an issue as it is with computers like the ZX81 and Ace.
    • Serial input - as you can see in the video above, pasting in a program over serial is a great alternative to saving / loading. Pasting is slower than loading (It'll probably go more quickly than in this video, I haven't tried yet) but I've found that I prefer working that way on the Minstrel 4th. 
    • Cheaper - even with the cheapest keyswitches and keycaps that I can find, this solution will probably be cheaper to make. 
    • Microcontroller - The USB keyboard adaptor uses a microcontroller for the USB communication, which I feel uncomfortable about. It's a more powerful computer than the computer it's connected to. 

  • More on RAM and ROM and a working* system!

    Shiela Dixon • 04/23/2023 at 22:38 • 0 comments

    I wrote an earlier log about RAM and ROM but this log supersedes that one. Earlier on I was trying to jumper existing modules to map everything into the 64k space (bios at $0000, cartridge rom (on the same rom chip) at $4000 and ram at $8000 upwards). This may have worked for certain scenarios but the MSX has the concept of 4 'slots', each of which covers the whole 64k. Software can switch these in and out (see last log) and so for a fully compatible MSX system I really need to replicate that slot selection system. 

    In a previous log I had a working PPI (as far as I'd tested it) which contains, among other things, the 'primary slot selection register'. That maps each 16k 'page' of the address space to one of four physical slots. My PPI design as it stands combines the bits of that register with A15 and A14 to provide two slot selection lines. 

    If I'd thought this through, I would have decoded that further into the 4 slot selection lines (active low) on the PPI module and connected those to lines on the backplane because that makes it very easy to enable each memory module depending on which 'slot' it wants to be in. (eg BIOS should be in slot 0, RAM is conventionally in slot 3, cartridge slots are 1 and 2.) 

    For now, I've got a '138 on a breadboard with 4 active-low outputs connected to the 4 spare lines of the standard RC2014 bus, which I'm designating 'Slot Selection 0,1,2 and 3':

    I'm using some standard RC2014 boards, it has been quite easy to bodge those so that they are enabled / disabled according to the appropriate slot selection line. Below are my two doctored ROM modules. One contains the BIOS, the other contains the cartridge ROM. They're hooked to different slot selection lines, and I've burned the cartridge ROM so that its data starts at $4000. (Later I'll come up with a hardware solution so that address $4000 selects address 0 of the chip - that will make burning the ROM chips easier.)

    The RAM board is hidden in this picture but it looks similar to those two ROM boards. (ignore the label you can see on the rom chip, I've had to do a lot of experimentation and that's out of date.)

    I had to do a lot of troubleshooting and experimentation. I wanted to use c-bios, partly because the code is open and partly because it's legit.  However, I've only got this setup working today after trying the original MSX1+BASIC rom. In a way this is preferable because I want to be able to use BASIC and cassette loading, neither of which is available in c-bios yet. 

    So here's the machine working* with the original MSX rom - it shows some details before arriving here at the BASIC prompt. You can't see it in the static image, but it's flickering a lot as if an invisible hand is mashing my non-existent keys. I guess this is because of floating keyboard and joystick connections. (which will be the subjects of further logs in the not-too-distant future).

    That's without a 'cartridge' module plugged in. Here's what happens with a 'cartridge module' in place (it's detected and run by the BIOS)

    Again, it plays itself because of the invisible hand mashing keys / joystick  but it's working* and there is sound.

    So here's the system as it stands. I'm using an RC2014 Pro backplane because I need a lot of slots. I think this will all work with the standard RC2014 bus.
    From front to back (the order that they're inserted isn't important): 

    • my PPI module (next job, make v2 of that), 
    • the Ed Brindley r6 YM/AY sound card
    • 'cartridge module' which is a bodged RC2014 Classic ][ ROM board
    • 'BIOS module' ditto
    • the J B Langston TMS9918A module
    • 'MSX ram module' which is a bodged RC2014 Classic RAM board
    • Z80 CPU module - any one will do
    • Clock module - I'm using my dual clock module so that I can jumper it to ~3Mhz   

    * working.... to a point.  I can't use BASIC or play a game because I don't have a keyboard or joystick. Yet.

  • Audio (and more i/o)

    Shiela Dixon • 04/21/2023 at 12:10 • 0 comments

    I don't know why '80s sound chips also handle some of the i/o  but it's the same with the C64 - the SID also handles the paddle input.

    I'd noticed that the MSX AY sound chip (or Programmable Sound Generator, PSG) also handles joystick(s). I'd spotted that the PPI (see previous log) handled cassette motor and cassette *out* (possibly just cassette write signal, I'm not sure yet) but I'd struggled to find where the cassette *in* action happens.  Eventually I found it on an MSX schematic - it's handled by the AY sound chip.  So the PSG is an important part of the system; it does more than produce the sound.

    I've had an Ed Brindley YM/AY sound card for RC2014 for a long time. It's a favourite module of mine, not least because of its two bidirectional i/o ports. 

    So I thought that my MSX PSG needs were sorted. But Ed himself has been in touch since I started this project to let me know that the version of the board I had (rev 5) wasn't capable of being jumpered for MSX ports and that I'd need a rev 6 module. 

    I'll keep my original board (top) jumpered for the standard RC2014 ports ($d0 & $d8) because I have the pt3 player along with lots of pt3 files on my CF card, as well as other music stuff that I've written. It now has an AY-3-8912 in an adaptor because that's the only spare chip I have. (Currently no use for i/o because the ...12 chip lacks an i/o register, and the adaptor board covers my i/o headers). Below it is the new board, jumpered for MSX ports. I haven't fitted the oscillator because it isn't necessary, it can use the clock signal from the bus and divide it if necessary. 

    I've tested the new card (register write port $a0, value write $a1, value read $a2) and that all seems to work fine. Thanks to Ed for his work on this module.

    A kit for the rev 5 board is available at https://z80kits.com/shop/ym2149-sound-card/ 
    Files and information for the r6 board are at https://github.com/electrified/rc2014-ym2149

  • MSX PPI

    Shiela Dixon • 04/17/2023 at 11:54 • 0 comments

    For a while I kept calling this module the 'PPE'. The pandemic has had lasting effects. If you see PPE anywhere in these logs, you know I mean PPI.

    PPI means Programmable Peripheral Interface. It's part of the MSX1 spec, an i/o device. The 82C55 chip is used, it has 3 registers accessed using 3 ports and another port is for commands. The MSX uses these for keyboard scanning, RAM/ROM slot control, some of the cassette functionality and some other things such as the caps LED and generating a click for the keyboard.

    This is clearly an important part of a working MSX and a module that I will need to add to the RC2014. Happily the 82C55 is still available new today (although there seem to be supply issues as I write this.)

    Credit to Dino who has published a schematic for an RC2014 PPI module and sells a PPI module as part of a keyboard kit. As I've said before, the yellow-board MSX system is available but it's MSX2+ which is more advanced than the MSX1 that I want to build.

    I've designed a standard RC2014 module that contains all of the functionality I need. As this is still experimental, I've left many of the connections on headers for now, including the slot select lines.  I think I will decode those into 4 active-low lines (for the 4 MSX RAM/ROM 'slots') and use the 4 spare lines on the standard RC2014 bus for those, but that's a decision for another day.  I've also included the wait-state generator on this board, but may take it off because I don't think I need it, even if I run at full RC2014 clock speed of 7.3 Mhz.

    Here's the board and a built module:

    Initially this didn't seem to work. But I realised that the 8255 is 'programmable' (basically the direction of the registers) and the very first thing that the MSX does on startup (as can be seen with a quick look at the source of c-bios) is an out to port $ab, $82 and an out to port $aa, $50

    The first out sets the mode so that the 3 registers work in the way that we need. The second sets the state of port C. (the PPI uses four port addresses - 0xa8 -0xab. a8 is the slot control and can be written and read)

    The screenshot above shows the module in my RC2014. I'm running SCM which allows you to easily read and write to the hardware ports) I can perform those two 'outs', then successfully read and write port A and read back the value written to port C.

    The next step is to bodge some RC2014 RAM and ROM modules so that they can be selected using the slot select lines that this module generates.

  • RAM and ROM

    Shiela Dixon • 04/07/2023 at 15:13 • 0 comments

    Initially I believed that the MSX memory map had bios in the first 16k, basic or cartridge rom in the next and RAM in the upper 32k. 

    This could be true but the story is more complex than that. The MSX1 specification has four hardware 'slots', each of which sees the whole 64 address space, and the memory space is divided into four 16k 'pages'.  A register in the PPI (Programmable Peripheral Interface) determines which slot is selected for each 16k page. (It also handles the keyboard and does some other things.)

    I have yet to fully understand what happens on startup, how the machine detects what cartridges are present and how it sets that configuration initially.

    My RC2014 Pro has a ROM module and a RAM module, each of which is very configurable  can contain 64k. So we're well on the way to the MSX goal. We will definitely need a PPI which can enable / disable those modules  based on that PPI register.  I think we can use a couple of the spare bus lines, and do a little bodging to the standard modules.  But that is all for another day.

    For now, let's see what we can get running with what we already have.

    One fantastic resource is c-bios, which is an open, compatible and free rewrite of the MSX bios. 

    I've bought some 64k EEPROMs so that I can experiment.

    I think the 16k BIOS ROM is always at address 0, so this is how the ROM module needs to be jumpered for the first 32k of the ROM chip to appear at address zero:


    I've jumpered the RAM module so that it appears to have 32k in the upper half of the address space. For reference, that looks like this: 



    The c-bios download has many versions of the ROM. Not all of them work for me at present but here is cbios_main_msx1.rom. It's a 32k image, with the bios in the first 16k and the next 16k almost empty. (I suspect that the few bytes that are there in the second 16k may be important). I found text within the rom image that explains that this version is only designed to start cartridges. Good to know. But at least I have something on the screen:

    At one point when I had forgotten to plug my RAM module back in, I saw this, so the bios' memory check routine is working, and I know the ram is jumpered correctly if I don't see this message:

    I have found ROM images online for MSX BIOS+BASIC but haven't had any luck with that so far. Maybe the PPI needs to be present, or maybe there's something else that I'm missing at this stage. 

    As mentioned before, it'll be important for my ROM and RAM to be capable of being enabled / disabled under the control of the PPI (Programmable Peripheral Interface). I have been doing lots of reading and have designed a PPI module, but that is for the next log.

  • Video using the TMS9918A chip

    Shiela Dixon • 04/04/2023 at 19:34 • 0 comments

    The first step is to have a working TMS9918A module. I've owned one for around 3 years, bought as a kit, following J B Langston's design. It hasn't worked until now and I've spent many hours looking at my module, the schematic and Mr Langston's example code. One potential issue is that the TMS9918A chips aren't available new, and if you buy alleged new old stock, you take a punt on whether you'll get a genuine and working chip.  The one in my kit was tested and so should have been fine and I now know that it was. I have bought a few more since and the ones I've tried are also good.

    There were multiple problems. One was hardware-related (a soldering problem) and one software issue. I'll leave the software answer here in case this is relevant to anyone else: J B Langston's examples all perform a port test at the start. it's a very clever and useful routine.  TmsProbe: in tms.asm tests commonly-used ports to see whether the video card is present. If it does find the video chip on any of the ports it tests, it'll use that port. If not it'll helpfully tell you that it hasn't found it and exit gracefully. The problem is that the first port in the list is $be which (on my RC2014 setup at least) is related to the ROM switching and the test causes the machine to hang. The solution is simple. (remove $be from the list. Or, as I did, make TmsProbe return immediately, and make sure that $98 is in the variable TmsPort at startup).  If I'd bothered to search the RC2014 Google support group I'd have found this answer there. 

    I'm glad that I had this problem and the soldering issue because I've gained a good understanding of the workings of the TMS9918A chip and J B Langston's module.

    Another important note is that the documentation says that to jumper this module for the MSX ports ($98 and $99), set J4 "3rd from right" but after looking at the schematic - and trying it in real life - I believe it's 4th from the right. 

    This chip has several screen modes and is very powerful thanks to its own video RAM (up to 16k) which is separate and additional to the computer's own RAM. (This does mean that all reads/writes to the vram are made via the TMS chip). Above is the 40-column text mode. It also has graphics modes with 16 colours and sprites too. It can even receive video and overlay its layers on top. 
    All of this makes me feel that the MSX computers are under-appreciated.

    Here's a static image of the Plasma example. This type of demo is now well-understood but still looks very impressive on an 8-bit computer

    (I've tweeted a video of this running: https://twitter.com/shieladixon/status/1640137090531745794)

    So that's video working, and jumpered to use the MSX ports ($98 and $99).