Minstrel 4D Power Options

In a previous post, I looked rather too deeply into the  Power supplies of the 8 bit generation. The reason behind this was to decide how best to power the Minstrel 4D.

I wrote the following post on my Patreon with the intention of making a decision by the end of it. Did I achieve that? Read on and see.

The problem I have is trying to meet the following criteria for the power input on the Minstrel 4D.

1. Standard power supply, either 9V DC or possibly 5V USB
2. Soft power on
3. Sufficient power for board (~100mA) and RC2014 slots (?)
4. Good regulation, no noise or dropouts
5. Through hole parts for kit assembly

5V in, USB Type C

I ran a couple of polls to ask about power requirements, and was surprised that there was a lot of support for using USB power, several people also suggested that the USB should use a Type C connector.

The USB C connector is only available as a surface mount part as far as I am aware, and requires some microcontroller based negotiation (although I think the fall back is plain 5V DC, so maybe not). This is becoming a standard, which is good and bad. There will be a lot of availability of good 5V USB C supplies, such as the one for the Raspberry Pi, and some genuine phone chargers, but there are also likely to be an awful lot of ropey ones.

The cheaper the charger, the poorer the regulation. Both it terms of voltage (which can vary quite a bit with load) but also noise.

USB Power Delivery scares me. The ability to deliver voltages higher than 5V, particularly if the ropey cheap charger gets confused and shoves out 20V and fries everything on the 5V line.

USB Type C, nice idea, but not yet.

USB Type B

The old standard big solid USB type B connector is a contender. It gets around the surface mount connector and power delivery objections of USB Type C. However, it is even more likely to have awful cheap phone chargers used. Also no soft power on, but there is a way around that.

USB Type B + MOSFET

This version uses a MOSFET to switch the 5V from the USB port. As you can see, I tried this one out. It worked. It did the job. I'm just not looking forward with having to support problems caused by those all those awful USB phone chargers out there with their definition of 5V as being "somewhere between 4V and 7V".

During the course of development I wasn't happy using USB power, so I ended up adapting the board to a different solution.

9V in 5V Linear Regulator with Soft Power On

The solution used on the Mini PET 40/80 was MIC2951 linear regulators. These tick all the boxes, other than power, they are limited to 150mA.

I did consider fitting two of them, one for the main board, and a second for external things, in the same as was the Mini PET 40/80, but that seemed too limiting as it didn't give any option for further expansion. There would also need to be a third 2951 to provide the 3.3V for the SD card, so I don't think this one is going to win.

9V in 5V Higher Power Linear Regulator with Soft Power On

I have looked around for higher power versions of something like the MIC2951, but they all seem to be surface mount only, or those 5 pin packages where the pins are very close together which would not be great for a kit build. The ones used on the Mini PET 40/80D would have done the job, although heat might be an issue as it would for a 7805.

There are also lots of switching regulators that are mostly surface mount, these also have the potential for noise and also need inductors and diodes etc.

9V in 7805 Regulator

This is the standard on the Minstrel 2, 3 and 4th, as well as the original Mini PET. It meets most of the criteria, other than the soft power on.

One downside the the power available without a heatsink is enough for the board and maybe some simple RC2014 cards, but will need a heatsink for larger loads.

9V in, Switching Regulator

An option for higher current without a heatsink is to use a 9V switching regulator, such as a Recom or Traco regulator.

They have been used on Minstrels before, normally I supply them with the Minstrel 2 as it draws around 120mA with nothing on the expansion port, so a normal 7805 regulator can get a bit warm.

No soft power on, but a MOSFET switch will sort that.

9V in, Switching Regulator + MOSFET

I thought this was the way I was going to go. A 7805 replacement regulator with it's input voltage switched via a MOSFET. This seemed to tick all the boxes. It was a little more expensive, but not much in the grand scheme of things.

There was a problem though, one I didn't expect, noise. These are normally quite reasonable, and don't affect the video output. However, several I tried caused a hum to come from the piezo. This was quite annoying and unfortunately repeatable. Not being able to control what type of regulators we get, I don't think I could ship the kits if they were going to have that hum.

Yet again, I found myself modifying this during development, and yet again, I replaced it with a good old fashioned 7805

I had designed the PCB with a few options in mind as well as the switching regulator. There were also mounting points to take a 7805 + heatsink as an alternative, but that is not going to be an option now as there will be a perspex top plate.

9V in, 7805 Regulator + MOSFET

So we are back here. The solution I have ended up with on both development boards is 9V DC in, MOSFET to switch the 9V on and off and 7805 to regulate it down to 5V.

The final choice

Just reviewing the original options,

1. Standard power supply, either 9V DC or possibly 5V USB
2. Soft power on
3. Sufficient for board (~100mA) and RC2014 slots (?)
4. Good regulation, no noise or dropouts
5. Through hole parts for kit assembly

I think I now have two solutions that tick boxes 1, 2, 4 and 5, but both leave potential limited current available for expansion.

• 9V in, 3 x MIC2951
• 9V in, 7805 + MOSFET

I think the final choice comes down to limiting options. With the 7805, there are ways that can be expanded, but the 2951s are always going to be limited.

So I think the 7805 + MPSFET is the best option. It works for most cases, and can be adapted to suit all needs. I have enlarged the pad around the 7805, so a flatter heatsink could be fitted if required. Even some sort of arrangement like the ZX Spectrum toastrack. 

I've been using this pretty much all day, every day, for the last couple of months (seriously, I have), and it only gets a little warm. It will only need a heatsink if you add lots of power hungry cards, and then it is left to the builder to resolve the issue to best suit their needs. 

Now the production boards are here and decisions have been made. 

The decision is to provide an option which will work for most use cases, but with the option that the builder can adapt it to their situation if they think they will need more power.

The kit is supplied with a 7805 regulator, which can be soldered to the board, or riveted (which is my preference).

Or it can be bolted to the board

Or you can fit a small heatsink if you like

Or you can fit a switching regulator if you prefer, this style of 7805 replacement looks like a good option (although I have yet to try this particular one).

---

Advertisements

Minstrel 4D

The Minstrel 4D is available for preorder from The Future Was 8 bit. The parts are all here and the kits are currently being assembled to ship in the next few months.

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, so check it out if you want to read about all the different approaches I tried to video RAM priority access control. This now includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Valkyr - One Game, so many changes.

One of the things that have come out of the work on the Minstrel 4D is I am getting to try out so many more Jupiter Ace games. It is now so easy to load any tap files that I have been trying quite a few one.

Tetris and Snakez++ are ones I keep going back to.

Another one that stands out is Valkyr by Colin Dooley. It is a very good game, but has led to much work and many design changes during the development of the Minstrel 4D  (even though it turns out that although it was written in 1985, it was never actually released)

None of them are exclusively for this game, it is just that it was a good test case to demonstrate a few things that came up during development.

1) Bus pull ups.

This was sparked by a question on Twitter -  what values is returned when an unimplemnted address is read. On a real Jupiter Ace, this seems to be 0x20 most of the time, but not always. (0x20 is the ASCII code for a space, so is probably caused by that being read from the video RAM during a screen update).

Emulators such as EightyOne return 0xFF, as I would have expected. (N.B., since writing the original version of this post on Patreon, it seems EightyOne has been updated to return 0x20)

The Minstrel 4th seems to always return 0x58 (88 in decimal). The Minstrel 4D is the same.

This become important as Valkyr uses Z80 Interrupt Mode 2, where the interrupt address is composed of the interrupt address and whatever value is read from the databus. This is normally triggered by hardware (such as the Z80 SIO/2) which provides the appropriate value on the databus. In this case, it is triggered by the screen interrupt, an no such data is provided.

The Valkyr code seems to assume it is 0x20, and if it is not, you get the introductory screens, but as soon as the game itself starts, it locks up.

Valkyr is distributed with a second version (valkyr-em) which has been modified to expect the value of 0xFF, which meant it worked with emulators.

Many Z80 and 6502 machines have a bus pullup resistor to ensure a value of 0xFF will be read for any unallocated addresses, so it seemed like a useful thing to add to the Minstrel 4D design.

My first try was just adding a resistor network to one of the spare RC2014 connectors.

That seems to be working as expected, let's give Valkyr a go.

That is now working correctly as well. I am not aware of any problem caused by having the bus pullup resistors being present, so I have added that to the design, in almost the same position.

I also added a spot to add a bus pullup resistor network to the RC2014 Joystick card I made, so you can play Valkyr on a Minstrel 4th if you want.

2) Boldfield Joystick

I am sure I looked around several times for Jupiter Ace joysticks, and all I found was a magazine article about a DIY version that was one of those one that presses a different key on the keyboard for each direction.

In the absence of any existing standard, I decided to adopt one from the Spectrum world, and implemented a Kempston compatible interface for the Minstrel 4D.

It seems I somehow missed the Boldfield Limited Computing Joystick. (yes, they are Boldfield. They do a limited amount of computing. Just enough, but not too much).

This is much the same as the Kempston joystick interface I had already implemented, just at a different address, and with the bits in a different order. Since there is currently 1 game that supports Kempston (which I wrote), and at least 3 existing titles that support the Boldfield one, it seems sensible to change over to that.

It was time to start making mods to my beautiful, pristine development board I had just built.

That first mod was to the address decoding, just a case of changing to address to match from 0x1F to 0x01. The second was a little more intrusive, this time to the buffer IC, rearranging the bits to match to Boldfield design.

It wasn't just for that one game. As part of the load testing I have been doing, I have been lucky enough to be able to borrow a selection of real Jupiter Ace tapes. One of these is Atic Raid, a little bit of a rip off of Atic Atac for the Spectrum.

This supports the Boldfield joystick (since it was published by them).

And indeed, my modified joystick allows me to navigate around the screen.

Since writing the original post, George Beckett has adapted his ports of Tut-Tut and 3D Monster Maze to also support the Boldfield Joystick - https://github.com/markgbeckett/jupiter_ace

3 - Sound

The game supports* two sound modes, Ace sound and the Boldfield sound box.

* is meant to support.

It seems the sound support is not working, other than an initial beep.

This was tracked down to the only instance I have found so far of any software writing to the speaker using any address other than 0xFE.

The Ace used the same IO address decoding as the ZX80, "any even address", so it ties up half of the addresses from 0x00 through to 0xFE, but only ever accesses 0xFE. The Minstrel 4th and the Minstrel 4D both refined this to only 0xFE, to free up 127 more addresses for use with RC2014 expansions.

Side note: The Boldfield joystick is nominally address 0x01, but decoded "any odd address", so tied up the other half the addresses. An original Ace with an original Boldfield joystick interface would have no free IO addresses, despite only needing to use two.

Back in the development versions of the Minstrel 4th, I did have a jumper to select between the wide or narrow address decoding, but it didn't seem necessary, so didn't make it to production.

Since it was just this one game, rather than altering the decoding, George Beckett has modified the code to always use 0xFE, and now the Ace sound is working, and driving the Piezo sounder on the Minstrel 4th and 4D.

There were also some issues with the SoundBox, and George has also modified the code to be able to drive an RC2014 YM2149 card.

https://github.com/markgbeckett/jupiter_ace/tree/master/valkyr-minstrel

4) Snow

It was whilst testing the joystick, that the third problem started to annoy me.

It is difficult to take pictures of because it is only there for a second. But there is noticeable snow on something like this simple forth program to read the value of a port and print it on the screen. Most evidently in the part where it is scrolling the screen up, which involves a lot of reading a line of characters and writing them back at a different position.

This is caused by the CPU and the video circuitry both trying to access the video RAM at the same time. The way the 4th works, if the video is accessing RAM and the CPU tries to read exactly the same address, the Z80 CPU is put in a wait state until the video has finished.

If the CPU is first, when the video tries to access it is blocked and the video output is set to black, which is the spec of black snow you see. (incidentally, you don't see this if you have the inverted screen set as the snow is black, on a black background, so you only notice it if it is part of a white character).

The Jupiter Ace did things differently. It had two modes, depending on which address range you used to access the video RAM.

• 0x2000-23FF is CPU priority. If you read or write to the video RAM via this address, the Z80 CPU always wins and if the video RAM wants to access it gets blocked (and will just display whatever data is on the bus, giving a snow effect.
• 0x2400-27FF is video priority. If you read or write the video RAM via this address and the video circuitry is currently generating a screen line, the Z80 will be halted until the video line is complete and will then continue.

The Minstrel 4th Approach.

The Minstrel 4th relied on the dual port RAM chip to handle arbitration. It would allow simultaneous access by both video and CPU unless they happened to access the exact same address. If the video was first, /Wait would be pulled low briefly. If CPU was first, /blank would be pulled low, generating a black speckle on the output, the snow.

Here yellow shows the Z80 access, green the video access and blue the conflict signal from the dual port RAM. As you can see most of the accesses are fine, just the very occasional incidence when they both want the same address at the same time.

This was the same for either address range, it works fine most of the time. You get the occasional snow and it's otherwise fine.

Valkyr for some reason was particularly bad on a few of the information screens, with quite a lot of snow. (not sure why, but it seemed to be continually redrawing the screen?)

So, what can I do about it?

Well, I will spare you the details. There is a very long Patreon post going over all the things I tried. I was basically trying to apply the Jupiter Ace addressing mode with a CPU priority and a video priority address range.

I tried various ways, all of which mostly worked, but had the odd issue.

I even hard wired a couple of the options, in case it was the long wires which were causing issues, but to no avail.

In the end, I decided to take a different approach.

The video circuitry has a lot to do in a short time. The shift register shifts out 8 bits of each line of each character in 8 clock cycles at 6.5MHz. This means the CRTC has 8 instruction cycles to read the character from video RAM, and then look up the appropriate line of the character in the font ROM and load it into the shift register just in time for the previous character to have finished.

Whilst doing all that, it just keeps the video RAM chip select line low, as there isn't really time to switch it on and off, even though it is only actually being accessed for two of the eight cycles. Yellow is the video side select line. Green shows the Z80 accessing video RAM when the screen is not being drawn, and blue shows the "busy" signal that halts the Z80 whilst drawing the screen.

The way it is implemented, when a conflict is detected, the /Busy line on the dual port RAM causes the output to blank, so you get black dots on the display. It shares the /Blank signal that the CRTC uses to blank the pixel output during the borders and sync pulses.

I decided to try just unhooking the /Busy line, leaving everything as it was in the Minstrel 4th, relying on the conflict resolution system to deal with the issues. The only difference was it now wouldn't put a black dot on the screen if it detected a possible conflict.

What that means is when there is a conflict, the video display will not be blanked, it will just continue as normal, and for 6/8 of the cycles, this will continue correctly.

For 2/8 cycles, the read may fail or return the wrong value but in practice, I am not seeing any snow any more. Any errors are appearing in the background colour rather than in black, so the display is nice a clean.

Links to the games mentioned in this post:

• https://www.jupiter-ace.co.uk/sw_Valkyr.html
• https://www.jupiter-ace.co.uk/sw_boldfield_atic_raid.html
• https://www.jupiter-ace.co.uk/sw_frogger_bold.html
• https://www.jupiter-ace.co.uk/sw_tetris_rf.html
• https://gldm.itch.io/jupiter-ace-snakez
• https://gldm.itch.io/jupiter-ace-pac-man
• https://github.com/markgbeckett/jupiter_ace/tree/master/3d_monster_maze
• https://github.com/markgbeckett/jupiter_ace/tree/master/tut-tut
• https://github.com/markgbeckett/jupiter_ace/tree/master/valkyr-minstrel

---

Advertisements

Minstrel 4D

The Minstrel 4D is available for preorder from The Future Was 8 bit. The parts are all here and the kits are currently being assembled to ship in the next few months.

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

More info in a previous post:

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

Joystick for RC2014 PCB Only

https://www.sellmyretro.com/offer/details/9-way-d-joystick-card-for-rc2014-or-minstrel-4th-pcb-62828

As it says, this is just the PCB. You need to source the rest of the parts yourself. A full parts list and schematic will be provided in the datasheet.

Joystick for RC2014 PCB + Kit

https://www.sellmyretro.com/offer/details/9-way-d-joystick-card-for-rc2014-or-minstrel-4th-full-kit-62829

The kit version includes all the parts required, including sockets and jumpers and the bus pullup array. You can omit any of all of those if you like.

So you can build a minimal or fully loaded version as required.

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, so check it out if you want to read about all the different approaches I tried to video RAM priority access control. This now includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware