ZX81 BASIC on the Minstrel 4th

I have written this post several times, one got to over 4000 words and I wasn't even half way through, but they have all been a bit too rambling and probably going into more detail than anyone needs.

So, this is the forth attempt (how appropriate). This time with more pictures and diagrams and (hopefully) fewer words.

Let's see how I get on....

The aims:

• ZX80 4K ROM Integer BASIC running on the Minstrel 4th
• ZX81 8K ROM Floating Point BASIC running on the Minstrel 4th

I already have the ZX80 version working - see posts from 2023:

• http://blog.tynemouthsoftware.co.uk/2023/11/zx80-basic-on-the-minstrel-4d-part-1.html

ZX81 BASIC is going to be a bit more work, but I will get onto why later.

The ZX80, ZX81, Jupiter Ace and Minstrel 4th are all Z80 based machines with a 32x24 character based display, cassette storage and 40 key keyboards. All good. But there are differences.

Display differences

The Jupiter Ace and Minstrel 4th have a 32x24 character, memory mapped display. This uses 1K of dedicated video RAM at $2400 and is stored sequentially from the top left character to the bottom right. Each character on the screen is 1 byte of RAM. 768 bytes in total.

Looking at $2400, we can see where the display is stored.

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
2400	76	6C	69	73	74	20	20	20	20	20	20	20	20	20	20	20
2410	20	20	20	20	20	20	20	20	20	20	20	20	20	20	20	20
2420	46	4F	52	54	48	20	55	46	4C	4F	41	54	20	49	4E	54
2430	20	46	4E	45	47	41	54	45	20	46	2F	20	46	2A	20	46
2440	2B	20	46	2D	20	4C	4F	41	44	20	42	56	45	52	49	46
2450	59	20	56	45	52	49	46	59	20	42	4C	4F	41	44	20	42

What do you mean you can't translate ASCII character codes in your head?

Oh dear, OK, let be do it for you.

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
2400	v	l	i	s	t
2410
2420	F	O	R	T	H		U	F	L	O	A	T		I	N	T
2430		F	N	E	G	A	T	E		F	/		F	*		F
2440	+		F	-		L	O	A	D		B	V	E	R	I	F
2450	Y		V	E	R	I	F	Y		B	L	O	A	D		B

That is all quite logically laid out, starting at $2400, with each row of characters taking 32 characters and ending at $26FF.

The area of RAM $2400 to $27FF on the Ace is also mirrored at $2000 to $23FF. When the CPU accesses video RAM in the upper region, it has to wait if the video circuitry is currently drawing the screen. In the lower region, the CPU takes priority, and the display will be blocked. It cannot wait, so just shows empty regions on the display until it can get back. This creates the "snow" effect. The Minstrel 4th does not suffer from this, both areas are uncontended.

The display only used 768 bytes out of the 1024 available. That leaves 256 bytes at $27xx available as scratch RAM, although it's access is governed by the same rules as the video RAM.

ZX81 Collapsed Display File

The ZX80 and ZX81 also have a 32x24 character based display, but the way it is stored is very different. It's location is not fixed, and the format is different.

Let's have a look how that is stored in memory. I'll look at the ZX81 to be consistent throughout this post, but the ZX80 used the same display format with slightly different addresses.

The ZX81 only came with 1K of RAM, so a character mapped display like the Ace would use more than 3/4 of the available RAM. To get around that, those machines used the minimal amount of RAM for the display.

The RAM in the ZX81 starts at $4000, and the start of that contains various system variables. The important ones here are $400C and $400D, together they store the location of the display file.

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
4000	FF	80	FC	7F	00	80	00	FE	FF	00	00	00	98	40	93	43

In this case, it is $4098.

Looking at $4098, we can see where the "collapsed" display file is stored

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
4090	-	-	-	-	-	-	-	76	76	00	00	1D	1C	00	35	37
40A0	2E	33	39	00	0B	2D	2A	31	31	34	0B	76	00	00	1E	1C
40B0	00	2C	34	39	34	00	1D	1C	76	76	76	76	76	76	76	76
40C0	76	76	76	76	76	76	76	76	76	76	76	76	76	76	1C	18
40D0	1C	76	-	-	-	-	-	-	-	-	-	-	-	-	-	-

What do you mean you can't translate ZX81 character codes in your head either?

Oh dear, OK, let be do it for you. Again.

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
4090	-	-	-	-	-	-	-	NL	NL			1	0		P	R
40A0	I	N	T		"	H	E	L	L	O	"	NL			2	0
40B0	G	O	T	O		1	0	NL	NL	NL	NL	NL	NL	NL	NL	NL
40C0	NL	NL	NL	NL	NL	NL	NL	NL	NL	NL	NL	NL	NL	NL	0	/
40D0	0	NL	-	-	-	-	-	-	-	-	-	-	-	-	-	-

The size varies depending on what is on the display. In this case, it only takes up 59 bytes, after that the rest is available for use.

The blank lines are represented by a single NewLine character only (highlighted above). This is very efficient in terms of storage space, but it is quite slow whenever you want to add a character as you have to move the entire rest of the screen down.

As the program gets bigger, the available memory decreases, so the screen gets smaller to compensate when you are running very low.

This display is implemented with very little external hardware. The ZX80 was incredibly cleverly designed, and the ZX81 followed on from that (again, continuing to refer to the ZX81, but also covering the ZX80)

A very quick look at how the ZX81 display works

The RAM in the ZX81 is mirrored so that addresses in the $4xxx range can also be accessed in the $Cxxx range, so the display file at $4098 can also be read at $C098 etc.. In the ZX81, part of drawing the display is to get the Z80 to jump to that higher mirrored address and start trying to execute the display characters as if they were code.

The video hardware detects when the higher address mirror is being executed as bit 15 of the address is set. When that happens, it intercepts the RAM read. It uses the character that has actually been read to draw the screen and passes a NOP to the Z80.

That makes the Z80 do nothing and move onto the next address.

This continues along the line reading characters executing NOPs until it hits a character with bit 6 set ($40-$7F and $C0-$FF). Those it does not display, it passes those through to the Z80.

The only characters in the display file in that range are the newline characters, $76. That just happens to be the Z80 OP code for "HALT".

Character Read

2D

2A

31

31

34

76

..

2D

2A

31

31

34

76

..

Z80 Executes

NOP

NOP

NOP

NOP

NOP

HALT

(waits)

NOP

NOP

NOP

NOP

NOP

HALT

(waits)

Character Displayed

H

E

L

L

O

H

E

L

L

O

The Z80 duly halts and waits for an interrupt, which the hardware generates at the start of the next line.

The Z80 wakes up, and starts executing characters again, and again continues until it hits a newline character.

(I am glossing over a lot of detail here, for example each line is read 8 times to build up the bitmap line by line, but I hope you get the general idea)

ZX81 Expanded Display File

This smaller but slower "collapsed" display file was designed to come with minimal RAM.

When 4K or more RAM is installed, the ZX81 switches to using an "expanded" display file. This is faster, but uses a lot more RAM.

$400C/D again tells us the display file starts at $4098.

Looking at $4098, things are a lot more spaced out.

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
4090	-	-	-	-	-	-	-	76	76	00	00	1D	1C	00	35	37
40A0	2E	33	39	00	0B	2D	2A	31	31	34	0B	00	00	00	00	00
40B0	00	00	00	00	00	00	00	00	00	76	00	00	1E	1C	00	2C
40C0	34	39	34	00	1D	1C	00	00	00	00	00	00	00	00	00	00
40D0	00	00	00	00	00	00	00	00	00	00	76	00	00	00	00	00
40E0	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
40F0	00	00	00	00	00	00	00	00	00	00	00	76	00	00	00	00

And so it continues, up to $4395 where the last NL is.

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
4370	00	00	00	00	76	1C	18	1C	00	00	00	00	00	00	00	00
4380	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
4390	00	00	00	00	00	76	-	-	-	-	-	-	-	-	-	-

Here you can see each line now takes up 32 bytes for the characters, plus 1 byte for the NewLine, and most of those are spaces ($00).

Address	0	1	2	3	4	5	6	7	8	9	A	B	C	D	E	F
4090	-	-	-	-	-	-	-	NL	NL			1	0		P	R
40A0	I	N	T		"	H	E	L	L	O	"
40B0										NL			2	0		G
40C0	O	T	O		1	0
40D0											NL
40E0
40F0												NL
....
4370					NL	0	/	0
4380
4390						NL	-	-	-	-	-	-	-	-	-	-

That takes up more memory than the Ace / 4th version, 32+1 characters per line, 792 bytes, actually 793 as there is an extra NewLine before the first one vs 768 bytes total on the Ace.

The clever thing is the hardware does not need to know what type of display file you are using, it can use either, or even a combination, a "partly collapsed" display file.

Running ZX80 BASIC on The Minstrel 4th

My first thoughts were to try to convert the ZX80 BASIC code to write directly to the Minstrel 4th video RAM rather than using the display file.

That was quickly abandoned as it would require an awful lot of changes, and would not be compatible with many programs that would be expecting the standard display file format.

Then the moment of inspiration came. The ZX80 spends most of it's time drawing the display. All I need to do is change that code. Instead of generating the video signal, it needs to parse the display file and writes that into the Minstrel 4th display RAM.

This could run every frame and so would keep the Minstrel 4th display updated, and as long as it didn't take longer than the time it used to take for the ZX80 to draw the screen, I can pad it out to the end.

This leaves the ZX80 still spending most of it's time drawing the display, just in a different way.

Let me interrupt you

The ZX80 display relies on getting an interrupt generated by the hardware at the start of every line.

The Minstrel 4th is based on the Jupiter Ace. There the display hardware only generates an interrupt at the start of every frame.

Ah, OK, no, that's not actually a problem.

Actually, it's great.

Again, skipping over rather a lot here, but the ZX80 display routine has a function it calls twice. The first time it draws the top border and the actual display lines. The second time it draws the bottom border.

This display routine sets up the line to be drawn and then starts executing the display as described above. When it hits a $76 / NewLine / Halt character, the Z80 halts and waits until the start of the next line. The IRQ wakes up the Z80 where it sets up the address of next line and away it goes again.

I have replaced that function with one that on the first call, parses the ZX80 display file and writes it to the Minstrel 4th video RAM.

On the second call, it halts the Z80 and wait for the Minstrel 4th video interrupt which happens at the start of the next frame.

Perfect.

Character Set

The ZX80 and ZX81 have a character set in ROM. 64 characters, and they get another 64 by inverting those in hardware.

The Jupiter Ace has a different character set, closer to ASCII, as seen above. That is stored in ROM in a slightly compressed format, but it is not accessed from there. At power on, it is copied into 1K of write only memory that is also shared with the video hardware.

All I need to do then is to copy the ZX80 font into that write only font memory at power on and bingo.

You can tell the ZX80 font by things like wide Z character and unslashed zero.

There are space for 128 characters in the Minstrel 4th character RAM, so the second 64 characters are unused. User software could make use of those to create user defined characters, or indeed redefine the standard 64 character set.

So far, I have not found any programs that actually write to the character ROM, as $2800-$2FFFF is not normally RAM on a ZX81.

OK, well one program, but SYSInfo wrote there deliberately to test if it was RAM or RAM.

That has detected correctly that there is 48K of RAM available. The standard ZX81 only tests for a maximum of 16K, I have left that alone for best compatibility. If you want to make use of the extra RAM, you need to POKE RAMTOP to set the new value.

ZX81 BASIC for the Minstrel 4th

Getting the ZX80 4K BASIC ROM working is great, but my aim was always to get the ZX81 working.

(side note the 4K BASIC ROM is, unsurprisingly 4K, and the Ace ROM was 8K, so adding extra functionality was easy just use the spare 4K. ZX81 BASIC is 8K, so adding to that could be tricky. Luckily I thought of this in advance, and the Minstrel 4th has an extra 5K of ROM available, so all the new code can go in there)

One of the main changes on the ZX81 was adding "compute and display" mode, other wise knows as "slow" mode.

"Slow" mode is better than "Fast" mode

Confused?

The ZX80 only runs in "fast" mode. In "fast" mode, the ZX80 or ZX81 can either be drawing the screen OR running code.

In the new "slow" mode, the ZX81 can draw the screen AND run code. It only does this during the screen borders, so does not get much time (about 6ms out of each 20ms cycle), so is about 30% of the speed of "fast" mode.

This used another clever trick. During the borders, they enable the "NMI Generator". When this is enabled, at the start of each line, it generates a non-maskable interrupt as well as the maskable interrupt.

It took a long time to get my head around the this works in code, particularly the way the stack is used, I have written a very long and detailed post on that, I may post that separately if anyone is interested (so far it seems no one is, but I might still post it to Patreon)

Very briefly, the function that is called twice now does only the top and bottom borders, and there is now a second function that does the actual display bit.

The display bit is the same in both "fast" and "slow" mode, it draws the lines like the ZX80 did by executing the display and halting on the newlines and IRQs waking up a the start of each line.

The border in "fast" mode are also drawn the same as they were on the ZX80.

In "slow" mode, at the start of each border line, it jumps back to user code until the end of the line when the NMI is generated and returns to the display code.

So user code is being run in the borders of the display and it gets onto drawing the display in between.

In my version, I do nothing in the borders, just return. In the middle section, I parse the display as before.

My version of the ZX81 NMIs trick is I then jump to user code until it is interrupted by the frame IRQ and comes back to the display code.

(credit to my backup logic analyser, in a week when everything was breaking, including my normal logic analyser, this one actually performed flawlessly for once)

The implementation is different, rather than running user code in lots of small bursts on the lines in the borders, it gets one long run between the end updating the video RAM and the start of the next frame. User code should know nothing about this, it will appear the same.

Time to give it a go.

Hurray! it works, and I was able to type in a simple program.

On the ZX80 when you run something like that, it goes away and fills the screen with Xs, then onto updates the display when it's finished so you see them appear all at once.

On the ZX81, you see it draw each one in turn.

That may not be the effect you are looking for, so you the ZX81 has a FAST command so you can turn off the display, do all the screen updates quickly, then use SLOW to go back to show the results.

The first proper test

Of course I wanted to try 3D Monster Maze, and yes, that is working nicely, the Ringmaster does his thing, and then it goes to "fast" mode to generate the maze.

The screen appears to freeze at this point, so I have added code to the ZX81 FAST command routine to fill the Minstrel 4th screen with the 50% gray character to create the "mists of time".

As soon as it returns to "slow" mode, the display routine starts to be called again every frame and the first one rewrites the display with the newly generated the maze.

Goal achieved.

More than just 3D Monster Maze

There were various other issues do to with the difference in hardware, as covered in the previous posts. The keyboard is mapped slightly differently and the tape input is on a different bit of the input port. All those can be fixed in the ROM.

It means any games which have their own load routines will not work. Likewise any that have their own keyboard scanners will misread the middle 8 characters of the bottom row as they are rotated by one character. Shift and space are in the same place, and that is all most things would be testing.

And anything which replaces the display routine for pseudo-high-resolution graphics will most likely not work. 

I did make many of the flicker-free games work in the same way as before

• http://blog.tynemouthsoftware.co.uk/2023/12/zx80-basic-on-the-minstrel-4d-part-3.html

I also needed to write new LOAD and SAVE routines, but since the Minstrel 4th video display is always active, I was able to add a countdown to loading and saving.

I tested lots of other things, and almost all that I expected to work did work.

I

Have

Done

A

Lot

Of

Testing

What works

• Most BASIC programs
• Most machine code programs
• Keyboard read which uses the standard INKYE$
• Keyboard read which uses $02BB keyboard routines and LAST_KEY
• Character based displays using the display file as normal PRINT, PLOT etc.
• Character based displays directly manipulating the display file
• Flicker Free games which jump back to $02B5 to display the screen
• The standard LOAD and SAVE commands
• Loading and saving to standard ZX81 tapes (ensure your tape signals are strong enough)

What does not work

• Anything which includes it's own display routines 
• Anything which includes it's own keyboard scan routines
• Anything with a custom loader
• Anything which disables interrupts or relies on line interrupts

The only one I expected to work but unfortunately did not was Tut-Tut. I am not sure why, as Minoss Knossoss, it's sequel, works fine.

It is a display or timer issue, it starts to write to the screen, but only gets so far and then fills the screen with a pattern and locks up. I suspect either Z88DK is jumping into a place I am not expecting, but I haven't got to the bottom of that yet. Hopefully I will be able to provide a patched version once I find out what's wrong.

Time Critical

The display copy routine is time critical, and I have been working on speeding that up. I will write a separate post about it as it's is (hopefully) quite interesting.

I was able to speed it up about 3 times by skipping the check for newlines and just assuming that everything would be using an expanded display file. That is probably going to be OK, most of the time, but I can't leave it like that. That would run code for 14ms out of 20, so 70% of the speed of "fast" mode.

Putting the test back in place to support collapsed and expanded (and partly expanded) display files, I have managed to reduce the number of cycles it takes by almost a half thanks to some crafty coding and various suggestions on blusky.

Anything which uses PAUSE or the frame counter for timing will be fine, but things that just run as fast as they can, would run twice as fast. You might want that, in the case of Rex, you do not want him to run twice as fast!

For the moment, I have added in a delay loop to slow it back down. I have tweaked the timing to make in run the same speed as a ZX81, at least according to the one test program I have been using.

Currently Shipping

The Minstrel 4th kits are currently shipping with a ROM containing the following:

• Standard Forth ROM (for best Jupiter Ace compatibility)
• Forth ROM with serial support and extra words - see https://github.com/nihirash/Minstrel4th-rom-patch/tree/master
• ZX80 Integer BASIC (experimental)
• ZX81 Floating Point BASIC (100% speed version, experimental)

I think I need to add a bigger EPROM and an extra ROM jumper(s) on the next board revision, there are lots of ROMs to add)

• MPF-I - George's conversion of the Microprofessor monitor ROM - https://github.com/markgbeckett/jupiter_ace/tree/master/mpf-i
• ZX81 Floating Point BASIC (195% speed, experimental)
• ZX81 Floating Point BASIC (285% speed, experimental, does not support collapsed display files)
• Shoulder of Giants ZX81 upgraded ROM?
• Lamba 8300 ROM (might be useful as it is a version of BASIC where you type P R I N T etc. rather than pressing P, so you don't need to look at an overlay to find the right key) - Anyone have a disassembly of the ROM? - http://blog.tynemouthsoftware.co.uk/2019/12/a-minstrel-3-based-clone-of-the-lambda-8300-ZX81-clone.html
• Husband Forth or one of the variants of that?
• Hi-Soft Pascal for the ZX Spectrum?
• A Z80 assembler / disassembler ROM of some description - possibly based on this one - https://github.com/markgbeckett/jupiter_ace/tree/master/z80_disassembler

Lots of things to think about for future:

• I would like to add a simple monitor (like the one in the PET) to the existing Forth and BASIC ROMs, to that end I have added an NMI button in preparation for this.
• I would like to add IN and OUT commands to the ZX81 BASIC. These are missing, but are on the Spectrum. I spent a while on this and had completed the OUT command, but IN was proving complicated as it meant moving a lot of things around to fit it into the operator precedence table, I will have to revisit that.
• It would be nice to add a BEEP command, I expect something that will take bits from both the ZX Spectrum and Jupiter Ace BEEP keywords. That is going to need a lot more work.

I will be putting the various ROMs on my github, but for the moment if anyone wants to try those, I have posted the ROM on my Patreon.

---

Adverts

This Minstrel 4th (with the updated ROM including ZX81 BASIC) is available as a kit or built and tested, from my Tindie store.

• https://www.tindie.com/products/tynemouth/minstrel-4th-z80-forth-rc2014-jupiter-ace-kit/

It is now also available from Z80kits.com, home of the RC2014. 

There you can get a bundle with the Minstrel 4th, RC2014 backplane and whatever modules you wan to go with it.

• https://z80kits.com/shop/tynemouth-minstrel-4th/

---

Patreon

You can support me via Patreon, and get access to advance previews of development logs on new projects and behind the scenes updates. New releases like this will be notified to Patreon first, if you want to be sure to get the latest things. This also includes access to my Patreon only Discord server for even more regular updates.

• https://www.patreon.com/tynemouthsoftware

Some tips for building (and troubleshooting) a Minstrel kit

I have covered this sort of thing before, but I thought it was a good time to revisit the process of building one of my Minstrel kits, and some of the steps you should take to troubleshoot any issues you might have.

This is based on my experiences and my preferences. Yours may vary. Feel free to not tell me about anything you disagree with.

Most kits work first time, or just need a quick repair to a bad solder joint. Please tell everyone about those.

You can order the kit pre-built, so it will arrive already built and tested, but if you want the fun of building it yourself, it will arrive in kit form. A good first step is to sort out all the parts.

I do my best to make it easy to identify the parts from the parts list. The resistors are all colour coded with the good old fashioned 4 band approach, and the colours are shown in the parts list.

The only tricky one in this kit (the Minstrel 4th) are the 22pF and 47nF capacitors, there are two of each.

I have used a different brand for the 47nF capacitors which are more clearly marked, so you can see the 473 marking (47 and 3 zeroes, 47000pF, 47nF). The 220 from the other brand is less clear (22 and 0 zeroes, 22pF). I am hoping the other brand will start to do more values so I can make them all the more clearly marked versions.

Lead free solder will ruin your day. I get the environmental concerns, but so much modern stuff fails due to bad solder joints caused by lead free solder that it probably generates even more e-waste. So step 1 is to throw your lead free solder in the bin and get some 60/40 tin lead solder, 0.7mm or whatever that is in other units. Something with lots of flux in it. I also use 1.2mm for soldering the larger connectors, I have always done that, it makes sense in my head, but that's up to you.

Once you have checked out all the parts, it is a good idea to fit all the lowest components first. The axial resistors, capacitors and diodes. (I forgot to take a picture, so here is one of a Minstrel 3 that I assembled previously)

I prefer to rest the board off a shelf (or you can get PCB stands) and insert all the components from the top in one go. I then solder them from the top of the board. I find that far easier than keep spinning the board around, and I think it looks neater as well.

You can then flip it over and cut off all the pins from the back in one go.

You will notice I talk a lot about aesthetics, I like things to look nice. The components are all lines up to look neat, but also I find it easier if I need to check the values when they are all lined up the same way.

Normally I have the black band on the diodes, the cathode end, lined up with the gold stripes on the resistors, the tolerance band (gold = ±5%). I also try to get the capacitor values upwards so they can easily be read.

What's that, you have got an extra 100nF capacitor?

I bet this is the one you missed.

Next come the ICs. I prefer to solder the logic ICs directly to the board. You can order the kit with sockets for all ICs if you like, or you can use your own. But please do not use cheap ebay dual wipe sockets. They are often very poor and do not give a good connection.

I like the way the 14 and 16 pin IC packages are the same size, so have arranged the positioning so they line up nicely (aesthetics again).

With sockets, you end up with the 16 pins chips on the end standing out more.

Personal preference, you do what works for you.

Next comes the sockets for the larger ICs, these are included in the kit.

These are good quality turned pin types (and not wire wrapping sockets as one commentor recently said on a YouTube video). I prefer this type. I find they give good reliable contact, and as long as you are not using reclaimed, desoldered chips with wonky legs covered in solder, they work well. Some people don't like them, so change them if you want.

Next is pretty much everything else.

Switches, connectors, jumpers, transistor, crystal, electrolytic capacitor, piezo sounder and voltage regulator.

The Minstrel 4th, even with a few RC2014 cards only uses 100-150mA, so the regulator does not need a heatsink. You can leave it free-floating, but I normally rivet it down (as shown here on an older board).

For a change, I soldered the tab today, but again, whatever works for you.

At this point the board is going to be covered in flux and some small flakes of solder or tiny off-cuts of leads etc. You really need to give the board a good clean at this point. It can make a big difference, and does sort out quite a few issues.

I recommend a good flux cleaner, I am currently using one with a built in brush and that is very effective. Follow that with a couple of washes with IPA to get rid of everything else and leave everything nice and clean.

Once the board is clean, give it a thorough inspection. You are looking for missed solder joints, solder bridges, dry joints, anything out of the ordinary. It can help to use an illuminated magnifier and hold the board at different angles, the bad joints often shine differently to the rest.

When I was building this one, I spotted a couple as I was working and thought, oh good, they will be good examples for the blog post. I then proceeded to absent-mindlessly fix them by force of habit before I took any photos.

I did have one I built recently where I missed a pin, easy to do, specially when you solder like I do, dragging the iron along, relying on flux and surface tension.

Based on 10 years of building these, remotely troubleshooting for people who have built the kits and investigating ones that have been sent to me to check over, I can honestly say that 95% of the problems are fixed by cleaning the board properly and fixing those little soldering issues.

Next it is time for the keyboard. Insert the switches carefully, they are a tight fit, so make sure not to fold any of the legs underneath. 

You can rest the overlay PCB on them to check they are all inline and sitting flat.

You don't actually have to solder the switches in, they make a decent enough contact just with the PCB holes, but it wouldn't hurt to solder them all in, but wait until the faceplate is bolted on to keep everything straight and level.

Fit the four longer screws and 4mm spacers to the overlay PCB.

And then fix that in place with four of the 10mm pillars from the back.

Fit the remaining two pillars with the shorter screws at the rear of the board.

Now it is time to install the socketed ICs.

The final step is to set the jumpers. Refer to the manual for full details, but set the video jumpers to suit. Both to the left is PAL video and black text on a white background.

The clock jumpers as shown below is 3.25MHz (Jupiter Ace standard) and that clock fed to the clock#1 pin on the RC2014 bus.

The A15 and A14 jumpers select the ROM from up to four different ROM images. Left is high, both left is the highest 16K ROM block in the ROM, which is the standard Forth ROM. There are another three combinations, more details on those in the next post.

Finally power. Both jumpers horizontal is for centre negative power supplies, as used on the ZX Spectrum, Commodore 16, and many guitar pedals etc. Both vertical is for centre positive which is pretty much everything else.

Ready to go, time to apply some power.

8-12V will do, 9V is the standard voltage. If you plan to use some power hungry RC2014 cards (i.e. something with a Raspberry Pi or display on it), you use a powered backplane or you could fit a 7805 switching regulator regplacement. They often have input ranges like 7-35V or 8-28V (as shown). You would need to change the electrolytic capacitor if you plan to use over 20V.

Power on, and all being well, you should see a small black square in the bottom corner.

It is a legal requirement that the first thing you should type is vlist.

After that, you can try some forth programming, load some games, even try some of the other ROM images.

Does it work?

If your kit works first time (or thereabouts) please tell the world, it will be greatly appreciated by the designer of the kit, and it's always good to hear positive news.

If it doesn't please reach don't tell the world until you have gone through some simple trouble shooting steps, and if that fails, try to reach out to the designer and try to get it resolved. 

It can really damage the perception of a new kit that someone may have been working on for months and spent lots of their own money on. If the first social media posts or YouTube videos that are seen show "I built this and it worked first time". People will think, "oh, I could do that and maybe my kit would work first time as well".

However, when they see posts about failed builds, they may think "oh, I don't think I will get one of those, mine probably won't work either". Fair enough if it is a bad kit, if the design or documentation is bad, but if there is nothing wrong with the kit itself, it might be casting it unfairly in a bad light.

Likewise, if you find issues, try to report those to the designer first. Sometimes those are not really issues, or get fixed for the next release, but the post stay out there and continue to have a negative impact as people might assume they are actual problems, or they have not been fixed. I hope it's not unreasonable to ask you to consider how things might be perceived, that's all I am asking. 

Troubleshooting

If you haven't already cleaned and checked over the board with a magnifier or a set of eyes younger than mine, go back and do that. It should solve 95% of problems

• Missed solder joint
• Solder bridge
• Dry joint
• Parts in the wrong place
• Incorrectly oriented parts
• Tracks damaged from rework

As well as those, there are occasionally issues like these:

• Wrong jumper settings
• Inappropriate power supply
• Monitor / HDMI adapter that does not like monochrome composite video

It is very rarely anything else. If you went for the PCB only option and are using an assortment of "new old stock" ebay chips, it is quite possible you have fake / remarked or just plain faulty chips. That is particularly an issue on the Minstrel 2 with vintage 74LS series parts that might not be up to the job anymore. Particularly the higher frequency parts such as the 74LS86, 74LS74 and the 74LS157s.

If you have exhausted all of the above checks, then its time to look deeper into the circuit, but most of these builds just work first time, or sometimes need the odd soldering misdemeanour corrected and then are up and running, so be wary before going too far.

It can be counter-productive to start delving deeper without having done the cleaning and checking stages. Once you get into rework and replacing parts and the chances of success start to drop. Take a step back. Run some IPA over the board again, get out the even brighter light and the even stronger magnifier and look again. I can promise you most of the problems are there.

First checks

Power, clock, reset.

That is always my starting point.

Power

Check the incoming supply and all the supply rails, check various ICs around the board, both ground and VCC pins and make sure everything is connected correctly. Most chips have ground bottom left, and VCC top right, but not the Z80, 65xx chips or for some reason the 74LS93.

If any of the rails are high, low or simply missing, power off and check the jumpers, look for shorts or any chips getting hot.

Clock

If you have an oscilloscope, check for the appropriate clock on the CPU and anywhere else it is used, if there is no clock there, check the jumpers and trace back to the clock crystal and the driving chip. On the Minstrel 2 and 3, the clock is generated by a pair of 74x86 gates. On the Minstrel 4th, the crystal is driven by the microcontroller, and the clock is output on one of it's pins.

Reset

The reset pin on the processor should be high with a brief low pulse when power is applied or the reset button is pressed.

Data, Address and Control lines

If all of those are OK, time to start looking around at the data and address bus and control lines.

Look around various chips on the board. You want to see signals that are changing between high and low cleanly. If you find any that are in the muddy grey area around 2V-3V you have a bus conflict somewhere. Two chips are trying to drive the bus at the same time, could be a bad chip, or could be the control signals are incorrectly enabling multiple chips at the same time.

The kits use all new parts, and the programmed parts are all tested when the kits are assembled. The few exceptions are the Z80 and 7132 dual port RAM chips, but these are using stocks purchased before they were discontinued, so were new at the time, have just been sitting in a box in my workshop for a few years.

---

Adverts

The Minstrel 2, 3 and recently relaunched Minstrel 4th are available on my Tindie store.

• https://www.tindie.com/products/tynemouth/minstrel-2-with-keyboard-z80-based-zx80-kit/
• https://www.tindie.com/products/tynemouth/minstrel-3-with-keyboard-z80-based-zx81-kit/
• https://www.tindie.com/products/tynemouth/minstrel-4th-z80-forth-rc2014-jupiter-ace-kit/

The Minstrel 4th now features multiple ROM images, so you can run Forth or ZX80 or ZX81 BASIC, including slow mode. The BASICs are still experimental. They are fairly compatible, most things work, with a few caveats if programs have their own video routines for pseudo-high-resolution graphics modes or fancy loaders etc.

Yes, you can run 3D Monster Maze - that was my target. This is the original unmodified version, loaded from tape.

---

Patreon

You can support me via Patreon, and get access to advance previews of development logs on new projects and behind the scenes updates. New releases like this will be notified to Patreon first, if you want to be sure to get the latest things. This also includes access to my Patreon only Discord server for even more regular updates.

• https://www.patreon.com/tynemouthsoftware