Minstrel Goes Forth

First there was the Minstrel 2. Then came the Minstrel 3. Now there is the Minstrel 4......th.

The Minstrel 4th is another Z80 based single board computer on a ZX81 shaped board, but this one is not compatible with the ZX80 or ZX81. This one runs Forth, and is compatible with the Jupiter Ace.

The Minstrel 4th started a long time ago as an attempt to build a Jupiter Ace clone. That didn't quite work, and was quite a challenge to fit into the 142x100mm form factor.

Several revisions passed as I tried some different approaches (long and detailed blog post to follow with all the gory details). With each revision I was trying to simplify the design, reduce the chip count and increase the capabilities.

The main change is the way the video is generated. I have used dual port RAM (the big chip on the right) to remove the need for the multiplexing and all the 1K resistors that were in the original design.

Yes, they look nice in a row, that that's not the point. I never got that version to work properly. The display was a bit fuzzy, and it would appear to be OK whilst it was working, but as soon as it stopped, the screen would be corrupted.

I redesigned the video circuitry in a much simpler way, without any 1K resistors. One concession though is the introduction of a microcontroller to do the counting. It's is just running a state machine counting through the cycles and generating the video sync and timing. Doing pretty much what a 6845 does in a PET. You might call that cheating. I don't. Anyway, I am the author. You are the audience. I outrank you!

With that the picture is considerably improved and there is no display corruption. With the extra control of the timing, I was able to add a back porch signal. This was originally missing on the Ace, but was much less of an issues with it's black text on a white background. I added a jumper so you can select black text on a white background instead. There is also a PAL/NTSC 50/60Hz jumper rather than having to have separate boards like the Ace did.

The inverse option is there for those who prefer it, but I have found I preferred the black on white style as used on the ZX80 and ZX81, so that is the 'normal' setting. (see above statement about who's in charge here).

Other than that, the Minstrel 4th is able to run Forth and Jupiter Ace programs just like a real Ace would. And the video output looks great, doesn't it?

Loading files was a bit of a challenge, I'll go into that in more detail in the subsequent posts, but I spent ages going round in circles, and it turned out the problems I was having were down to the files and the programs I was using to get the audio out. Once I found the right combination, it loads fine every time.

Thanks to George Beckett for providing me with work in progress versions of his Jupiter Ace port of Dave Stepenson's Tut-Tut. That's been good for testing the hardware along the way.

I have followed the Ace memory map, but filling in the gaps with more ROM and RAM. The ROM is now 13K rather than 8K, with up to four ROM images in a 27C512 EPROM. The RAM is now 1K + 48K system RAM (+ the 2x 1K video RAM).

The Ace had an edge connector, but there weren't many add ons available, and these were mainly RAM packs. The Minstrel 4th doesn't need those as it already has the full complement of RAM.

Unlike the ZX80 or ZX81, the Z80 isn't involved with drawing the screen. It couldn't care less. It just writes to the memory mapped video RAM (and can also write to the font RAM to redefine all 128 characters). You maybe able to make out the white border isolating the video section. All that is connected to that is power in, clock and interrupt out, and the left hand side of the dual port RAM.

Other than that, it is a Z80 single board computer, which means the Z80 is free to run user code all the time, and can use any add ons that a Z80 can, so I thought why not give this an RC2014 bus connector, then it can use all the RC2014 expansion modules.

The Ace (like ZX80 and most of the other Sinclair machines) minimally decoded the IO, just using 'A0 is low', so even though it only ever accesses 0xFE, it ties up 0x00, 0x02, 0x04 etc. as well. That would limit things, so the IO is fully decoded on the Minstrel 4th to only use 0xFE. That leaves the other 255 IO addresses available for all manner of add ons.

I have been looking at porting the NASCOM BASIC that was the starting point for the version used in the RC2014 and Grant Searle's Z80 SBC. It's not quite ready yet, so a new ROM image will be released once that is fully tested and bug fixed, you would then be able to select Forth or BASIC via the ROM jumpers. Anyway, I think it would be far more fun to see people struggling to get their heads around Forth before I give them an easier option.

Although the Z80 needs to run at the original 3.25Mhz if you want to do Ace stuff (tape loading and beeps are speed dependent). 6.5Mhz is also available on board, and it runs fine at that speed. You can even load programs if you speed up the audio 2x. Neither of those speeds are ideal if you want to use a serial card, which normally need 7.3728Mhz to divide down to the standard BAUD rates.

To get around that, I designed a new RC2014 serial module with a built in clock, so you can use that with the Minstrel 4th without need for an additional clock module. You can also run the Z80 at 7.3728Mhz if you want that extra boost.

I'm not keen on using new old stock parts, and I couldn't find a suitable UART that was still in production (since the WDC 65C51 is useless due to a bug that has been reclassified a feature, and I overlooked the Z80 SIO due to Zilogs mad part numbering scheme). So, I designed a serial board that didn't need a UART, and used a microcontroller to interface directly as a USB serial device.

That's not available yet as I need another spin of the board, and it's getting a bit silly the number of chips it is using.

The Minstrel 4th and 6850 serial module with clock are now available in kit and assembled form from my Tindie store, which has now reopened. Postal options are a bit limited at the moment, and are likely to be a bit slower and be a bit more expensive, so please bear with me if you don't get your order within 24 hours.

To simplify the postage options, I have moved all the 'PCB Only' options into a single listing, so that can be set for letter postage. Everything else needs courier collection.

So that's the Minstrel 4th, I hope you like it.

May the 4th be with you.

2022 Update: Yes, I did go to the effort of launching the Minstrel 4th on May the 4th so I could do that joke. We did a run of Minstrel 4th Final Edition kits last year, and they all sold out quite quickly. It is unlikely there will be any more. At the time of writing, there are still a few Minstrel 2 (ZX80) and Minstrel 3 (ZX81) kits available from  The Future Was 8 bit 

There are some "Minstrel 4th PCB + programmed parts only" listing available from my SellMyRetro store

---

Advertisements

Minstrel 4D

2023 Update, Now, of course, there is the Minstrel 4D, available in kit and built form. Shipping now from The Future Was 8 bit.

https://www.thefuturewas8bit.com/minstrel4d.html

More info in a previous post:

http://blog.tynemouthsoftware.co.uk/2022/08/minstrel-4d-overview.html

Patreon

You can support me via Patreon, and get access to advance previews of posts like this and behind the scenes updates. These are often in more detail than I can fit in here, and some of these posts contain bits from several Patreon posts. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Commodore 16 PAL to NTSC switchable conversion

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I was looking to test some upcoming game releases from The Future Was 8 bit, and I had a title for the Commodore 16 / plus 4. I like to test these on PAL and NTSC machines to make sure there are no issues. In the past I had converted a Commodore 16, but I couldn't locate it, so I converted another one.

I have some older post about converting a PAL VIC20 into NTSC. This required a change of a crystal, a ROM, the VIC chip and a few miscellaneous parts.

The TED series made this much easier. The only differences were the clock frequency and the KERNAL ROM. I think in the past I had fitted a crystal socket so I could switch between the 14.31818MHz for NTSC and 17.73447MHz for PAL.

I thought I would try a different approach this time. The clock circuitry is all arranged neatly below the TED chip, along with some potentially useful test points.

Rather than change the crystal, I went down the route of building a second crystal osciallator. The onboard one does the PAL frequency, so I just needed to built one that did the NTSC frequency. I build a fairly standard oscillator circuit around an inverter (I actually used a NAND gate as it made the layout easier, but the principle is the same).

I also added a '257 multiplexor so I could switch between the two clocks signals without running them through a switch or jumper. A rough schematic just to give the general idea.

The plan was to disconnect the clock signal from the output of the existing clock circuit, and feed that into the 257 mux. The output of the mux would then into the TED chip.

This is the board I am going to change, the transistor Q2 and resistor R7 on the right are the final stage of the original clock circuit, and TP is the test point with that signal on.

It didn't quite work out like that because the layout of the board meant I had to cut the link between the bottom of R7 and the collector of Q2 and rejoin them missing out the second (unmarked) test point.

I picked up the clock out (blue), clock in (green), ground  (black) and 5V (red) at appropriate points and wired to a 4 pin header.

There was loads of space in the C16 case to mount the board, I wanted it close by to keep the clock wires short.

The white wire on the left is used to switch the ROM image. I burned a 27C256 with both the PAL and NTSC KERNALs in.

Time to fire up, I am using the DIAG264 cartridge from TFW8b.

The refreshed version now comes in black and has a PAL/NTSC jumper.

First off, I will try the original PAL clock routed through the new board.

So far so good, this is an updated version of Diag264 by Rob Clarke. Time to give NTSC a go.

Excellent, that looks good to me. I also added a label to the mod board so I remember what this board does in five years time when I open up this Commodore 16 and stare confused at a bit of veroboard and a couple of chips on and wonder what I did that for.

So I am pleased I couldn't find the one I modified before, this has been a much nicer solution. This is my test board where I have ZIF sockets for the two most common chips to fail, the TED which is heart of the system (sound, graphics, IO etc.), and the 7501/8501 CPU (which from now on I intend to call Dougal).

Commodore 64 IEEE-488 Cartridges and the SD2PET future

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Today I answer one of the important questions of our generation. A question that literally no one has dared to ask. Can you use an SD2PET future with an IEEE-488 cartridge on a Commodore 64?

The answers is sort of. It does sort of work, but not well enough to be much use. Let me explain further.

This is a DAMS IEEE-488 cartridge. It may looks like a VIC20 cartridge case, because it is a VIC20 cartridge case, but it does plug into a C64. I have used the same technique myself for things too big to fit into a C64 cartridge case, like the prototypes of the Marina 64 cartridge.

They seem to have taken it a step further, and have designed the board so that they can make either a C64 or a VIC 20 version and just cut off the bottom part of the board with the C64 edge connector on.

The contacts were a big corroded, so I ended up retinning all of them to get a nice clean connection.

That was a case of using fresh solder and extra flux to clean and tin the pads, then removing most of the solder leaving a clean flat contact surface.

I presume the VIC20 version would have a different ROM image, here there is a 2532 ROM with a label that says C64 IEEE V.35 I think.

The rest of the chips are a 6821 IO chip, which gives two 8 bit parallel IO ports and a few extra handshaking lines. The 6821 is essentially the same as the 6520 used in the PET, an earlier, simpler version of the 6522 and 6526 chips used in the VIC20 and C64.

There is also a pair of 75160 and 75161 IEEE488 bus drivers, so this should be properly compatible with the IEEE-488 bus specification. I have seen some C64 IEEE-488 cartridges that do not contain IEEE-488 bus drivers, and those will probably not work reliably with something like the SD2PET future.

Notice the 75160 is marked made in England, you don't see many of those. The rest are the usual Portugal and Malaysia. The board is marked Ferranti LTD 15 April 1983 (happy 37th Birthday for last week).

On the back it's marked copyright RAMS 1983. The back also has a nice soldermask, which is missing on the top side of the board.

With all that cleaned up and the ROM dumped, I gave it a go.

The ROM autostarts, and adds a DAMS IEEE CARTRIDGE banner to the screen. I couldn't see that string in the ROM dump, so it's probably encoded somehow.

OK, power off and lets wire up the drive. The SD2PET future plugs into the edge connector at the top, the same as the one used on the PET.

The power connector didn't reach, so I had to make an extension for the power cable. I used a userport cable to supply the power, you will see why later.

That all sticks out quite a way behind the C64, that is as far in to the cartridge bay as it goes. That's an awful lot of exposed traces, not very keen of that.

Powering it on, it looks promising, LOAD "$",8 loads a directory listing as normal.

You can load simple programs like this 10 PRINT favourite

But, anything that requires multiple file loads, anything that doesn't use Kernal routine, any fast loaders etc. all of those will probably not work due to the way it integrates with the C64 Kernal. There are some functions which are not vectored which means they cannot be replaced by a cartridge ROM and are hard wired to use the IEC bus, so anything more complicated than plain LOAD and SAVE will probably not work. There are also potential issues with memory at the same address as the cartridge ROM, The only way to do it properly would be with a replacement Kernal ROM rather than as a cartridge.

I tried various browsers. the normal file browser FB / FB64 etc. worked. I tried CBM commander and the splash screen loaded.

but both SDBrowse and CBMCommander locked up trying to read directories. So they were hitting the issue of either custom disk access routines, or using the non-remappable Kernal routines which will not know they need to talk out the cartridge port to an IEEE-488 bus rather than the usual IEC bus.

I was interested to see how it would cope with IEC devices used at the same time, so plugged one in (which is why I left the datasette port clear for power).

OK, it's getting quite congested back there, that's an old SD2IEC which has been set to act as device ID 9, and that does work as expected. The IEEE-488 drive is ID 8, and if the IEC device is also ID 8 it will be ignored, but if you set the the IEC drive as ID 9, you can access both of them at the same time.

I did notice it was a lot faster loading things from IEEE-488 compared to IEC, approximately 30 seconds to load Rodman from IEC and 5 seconds from IEEE-488, so that is an advantage. This sort of thing would have been used back in 1983 to attach big old PET drives or the newer faster SFD-1001 type drives to a C64 for BBS work. Fast access to lots of plain files. For that it should work well.

If you want to load cracked games with custom fastloaders, forget it. With so many thing won't work and your desk will be such a mess that I really couldn't recommend it.

So, in conclusion:

• Can you do it? - Yes
• Does it work? - Sort of
• Should you do it? - No