M5-Multi-II ... II

A couple of tweaks have reduced the size of the board by nearly 2 square inches, meaning that the medium run service from OSHPark is now feasible.

I just need to adjust the size of the printing on the front and move a capacitor so that the EEPROM socket doesn't foul on it but other than that I believe it's good to go!

Sord M5 - Multicart V2

Finally the ennui has passed and some time was devoted to seeing what I could rescue from the ashes of the original M5 multi-cart.

Long-time readers may remember this board from a few years ago now. It's a complicated little thing, with lots of chips and passives and switches and chips and passives and things. It was a pain to make and to top it all the failure rate was in the high 70%.

There were a number of factors that contributed to this situation and I dare say that I could probably get it working now that I've had some support and debugging help from a friend and fellow enthusiast - Bas at BetaGamma.

The main issue with the board was that the ROM images needed to be stepped through one-at-a-time by pressing the button on the front. It was a chore and the reset method I devised was at best unreliable.

What I really wanted was a menu-driven design which was simpler. So I came up with this.

Simple, eh!

Gone was the PIC microcontroller and its supporting hardware. Added was my CPLD of choice, a Xilinx XC9500XL series chip. 5V tolerant, and in my experience utterly bomb-proof.

The M5's cartridge slot contains a few signals which are very useful - IOWRITE and EXTIOB. The former is what you'd probably guess - asserted when an IO write is in progress by the Z80. The latter is a signal originating in the M5's memory controller custom chip, and is asserted when an IO access is made to a port in the range $70-$7f. Under normal circumstances nothing in the system writes to this IO port.

My plan was to watch for writes to one of the $7x ports and capture the data bus content. This would be used as a base page number for selecting any one of the 64 8K pages of rom in the multicart's EEPROM. Most of the M5's carts are 8k, with the exception of BASICs F & G, and FALC - the M5's spreadsheet.

The M5 has 3 ROM select lines on the cartridge slot. ROM1, ROM2 and EXT-ROM.

ROM1 selects 8k in the region $2000-$4000

ROM2 selects 8k in the region $4000-$6000
EXT-ROM selects 4K in the region $6000-$7000

The CPLD outputs 6 address lines used as bank selection on the EEPROM. The bank number output is a sum of the base bank number set by the Z80, and a 2 bit number formed by ROM2 and EXT-ROM being bit 0 and bit 1 respectively.

With this logic in place and a suitable menu program written and debugged using MESS, I finally had the multicart working that I'd originally imagined.

A fairly simple job of re-working the original schematic and board in EAGLE, another simple job of uploading the design to my favourite short-run fab-house and a final simple job of waiting for 2 weeks and here is the result:

Perfect. Purple.

I just need to sort out a manufacturer for a mid size run of boards then I'll be selling these.

Sea Dragon. SEA DRAGON!

There's always Sea Dragon.

Loading from SD card, natch. This time on a Video Genie.

Feeding the Genie

The einSDein interface is quite versatile. At its connector it is simply a very basic set of Z80 bus and control lines.

RD, WR,IORQ, M1. A[0..7] and D[0..7].

So it shouldn't be hard to interface to other Z80-based computers, right?

Right!



Here is an issue 2 einSDein wired up to a Video Genie, the UK version of the popular TRS-80 clone made by the EACA corporation. It is variously known by other names such as the Dick Smith System 80, PMC-80, TRZ-80 and so on.

The expansion connector breakout was custom made one rainy afternoon, and while it looks a mess it does the business.

A small machine language program was written to perform a directory listing of the SD card. This was converted into a cassette image format, then loaded using PlayCAS.

Here is a video on arguably the best known video distribution channel in the western hemisphere. It shows the aforementioned program pulling a listing from the interface pictured above.

The more eagle-eyed may recognise that the programs on the card are not Genie programs. This is being attended to, dear reader. I have written a converter program which takes cassette image format files and spits out a raw-ish binary dump which can be loaded from SD card. It only works with 'system' or machine language programs at the moment, but a gander at the Level II ROM reference book will soon see to that restriction.

Armed with a copy of MAME and its fine debugger I will spend a few quality hours stepping through the cassette loading functions to see what I need to do in order to craft a work-alike in order to load BASIC from the SD card.

Bit-ing the bucket. A tale of mixed metaphors.

I have a few Mercurial repositories in BitBucket that I wanted to convert to Git, after undergoing something of a conversion myself. After a lot of onlinesearchengining for automated solutions, and being disappointed with the amount of effort involved, I came up with a rather nifty way of doing this without having to install and configure the HG command line tools. Sure enough, the hggit plugin sounds very quick and convenient - assuming you have HG installed. My way is undoubtedly clunky and a bit of a hack, but that's the way I like it, baby!

I will assume that if you want to do this you have a BitBucket account already set up and you have, or will soon have, a GitHub account. The GitHub account is only used temporarily.

Step 0. BitBucket

Rename the convertee BitBucket repo, unless you will give the new git-i-fied version a different name. Click the gear icon in the left hand panel on your repository details page to get to the repo settings page where this can be achieved.



Edit the repo name and click the large 'Save Repository Settings' button.

Step 1. GitHub.

Click on the '+' icon at the top right of your GitHub home page.
Select 'Import Repository'.



Enter the URL of the BitBucket repo you wish to convert.
Give a name to the GitHub copy. Choose anything, it won't live for long.
Begin the import by clicking the big green button.



You may be prompted to enter your BitBucket credentials. GitHub will not store these.



The repo will now be imported.
If there are questions about contributors, you can safely ignore them if you wish.

Step 2. BitBucket.

Select the Repositories button in the menu at the top of the page, and choose the Import option.
Enter the URL of the newly created GitHub repo.
Nominate a new name for the converted repo.
Click the 'Import Repository' button.



Machinations!



And that's it! This process has worked for me quite successfully on a number of projects.

May the Petits Fours be with you.

This