Micro Professor EPROM Programmer Board - Part 1

This was meant to be a quick post just scanning over the schematics to work out the memory map and IO connections, but you know me......

Sometime last year, I repaired a Multitech Micro-Professor MPF-I.

• http://blog.tynemouthsoftware.co.uk/2023/05/multitech-micro-professor-mpf-i-repair.html

At the time, I remembered that I had bought some of the modules that would go with it from an electronics surplus seller called Greenweld Electronics.

Well, only a year and a bit after I sent the MPF-I back, I finally located the one remaining module.

This is an EPB-MPF-1BP (I can tell that because it says so).

I think I bought several of these for a few pounds each when they were being sold off, probably in the early 1990s. This board was very useful for spares, but I did keep this one intact, in case I found a use for it one day.

(update: found the advert in Everyday with Practical Electronics April 1994)

And there in the middle is the Micro Professor EPROM programmer board (£3.95 + P&P)

(I think they may have reduced them further before I bought them)

Well, only 30 years later, it may finally be time to put it to use.

It was originally designed to connect to the Micro-Professor using a 40 way bus which was essentially all of the pins of the Z80. (there is a second 40 pin header to daisy chain multiple addons)

I sent the MicroProfessor back to it's owner last year, so I can't use that, but I do have several things, such as the Minstrel 4D, which have RC2014 bus connectors. That is also a 40 way bus which is essentially all the pins of the Z80.

I also know that George Beckett has been working on porting the Micro-Professor monitor to run on the Minstrel 4D, so I plan to wire this up to a Minstrel 4D, and hopefully run the original code, or if not, write some simple code myself, and finally program an EPROM after more than a quarter of a century wait.

• https://github.com/markgbeckett/jupiter_ace/tree/master/mpf-i

In this first part, I am going investigate the schematics and work out what is going on. Part two will be trying to get it running.

The first page of the schematics shows the ROM, RAM and address decoding.

The board contains three 6116 2Kx8 static RAM chips and a single 2732 4Kx8 EPROM. (no I can't read what it says on the EPROM label either, but I know I put it there as that is a write protect sticker from a 5 1/4" disk)

The RAM chips are mapped as $D800-$DFFF, $E000-$E7FF and $E800-$EFFF, giving 6K from $D800-$EFFF. Combined with the standard 2K of RAM on the Micro-Professor at $F000-$F7FF, this gives a contiguous 8K block of RAM to use to store data ready to write to an EPROM.

Looking at the schematic, I was slightly confused by the connections to the 74LS138 at U10. It appears as though /RD is used as one of the gate inputs, which would make the RAM read only?

It would seem more likely that it should be /MREQ on that pin, so the RAM was only selected for memory accesses.

Probing the board confirms this, U10 pin 4 is in fact connected to /MREQ and not /RD. So, I will have to remember to not necessarily trust these schematics.

(update, I went back and checked the schematics in the scanned version of the manual, these were drawn differently, but also include the same error)

Although the extra 6K of RAM would have been very useful on the Micro-Professor, I will probably remove it when using it with the Minstrel 4D, as that already has a full compliment of RAM.

The 4K ROM is mapped to addresses $9000-$9FFF, and includes software for both versions of the Micro-Professor, the MPF-I (with 6 seven segments LEDs) and the later MPF-I-Plus with the alphanumeric LCD). As with the RAM, I will need to remove this and load the contents into RAM. That's fine as it will probably need various modifications anyway.

Also on this page is the decoding for the IO chips.

This generates two signals, one for an 8 bit latch clock and one for the chip select of the 8255 IO chip.

The three gate inputs are wired so that the chip is active when A6 is high, A7 is low and there is an IO request.

That means it covers the address range 01xx xxx, (0100 0000 through to 0111 1111), $40 through to $7F.

This is split into 8 blocks, each of which activate one of the 8 outputs Y0-Y7. These are controlled by A3, A4 and A5, so the blocks will be $40-$47, $48-$4F, $50-$57 etc. The last two will be $70-$77 and $78-$7F, and those are the ones that are used here to drive the IO chips on the next page of the schematics.

The latch will be activated by any address from $70 through to $77, and the 8255 any address from $78-$7F.

There are four registers in the 8255, and it's address lines have been wired to A0 and A1. No additional address lines are used with the latch, so it will cover the whole of it's address allocation.

Address	Register	Connected to
$70 (or $71-77)	273 Latch	EPROM VPP/OE/CS
$78 (or $7C)	8255 Port A	EPROM D0-D7
$79 (or $7D)	8255 Port B	EPROM A0-A7
$7A (or $7E)	8255 Port C	EPROM A8-A10
$7B (or $7F)	8255 Control	-

Various types of obsolete EPROM are supported, either 24 or 28 pin. Note the genuine (?) TEXTOOL socket (not TEXTDOL as seen on ebay fakes), complete with helpful annotation from a teenage me.

It might actually be useful for programming the slightly odd chips like the 2532 and 2564 that can be used to replace mask ROMs on Commodore machines.

The 74LS273 latch controls pins on the EPROM that require different voltage levels. VPP can be 0V, 5V or something up to 25V (modern EPROMs are more likely to use 12V, but EPROMs of this vintage needed a higher voltage). Sometimes this is mixed with the OE and/or CS pins to make room for more address lines on the EPROMs.

Each of the outputs drives one gate of 74LS06 open collector inverter. When it's input is low, it is effectively not there. When the input is high, the output is pulled low.

If I understand this correctly, when the value in the latch is all zeros (after reset), EPROM pins 1, 22 and 23 will be at 5V. If any of the bits are set to 1, then the voltages will change as follows:

Bit	Pin	Voltage
Q0	Pin 1	VPP
Q1	Pin 1	0V
Q2	Pin 22	VPP
Q3	Pin 22	0V
Q4	Pin 23	VPP
Q5	Pin 23	0V

So, obviously, don't set both bits for any pin at the same time or the 10Ω resistors and transistors will get warm.

Bit Q6 and Q7 are not used. I would have been tempted to wire those to LEDs to maybe one to show reading the EPROM and one to show writing?

The final element is the VPP generator. This is based on a TL497 switching regulator. Probably programmed for about 25V, with the option to include 5 diodes in series with the output, bringing it down by about 3V to 22V (ideally 25V and 21.5V).

Hmm, that doesn't look right. Resistors R3, R2 and R1 form a potential divider, which should make pin 1 1.2V when the correct voltage is reached. They are all shown as 15K, which would mean the target voltage was 3.6V?

Ah, no, it's meant to be 1.5K, that makes more sense (although the datasheets all seem to specify 1.2K).

That makes the voltage divider more reasonable, giving a target around 25.2V.

Another correction to the schematics.

Note to self, adding a second switch to short out one of the 15K resistors would bring the target voltage down to 13.2V which is probably close enough for modern 12.5V EPROMs.

I should also mention in passing that there was also an earlier version, the EPB-MPF. This had only a 24 pin EPROM socket, 4K of RAM and 2K of ROM, and there are a lot of difference to the implementation.

What is next? Well, I have read out the EPROM on there, and it does contain apparently valid code, which George has started looking into to see how painlessly it can be made to run on the Minstrel 4D.

Now I know how it is wired up, next time I will have a go at driving it.

In future, it might be interesting to see if this can be turned into a viable EPROM programmer with the addition of an RC2014 serial card, data could be read, edited, written etc. using the Minstrel 4D interface.

---

Advertisements

Minstrel 4D

The Minstrel 4D is a much more reliable and usable Jupiter Ace compatible computer, with all the extras like a joystick interface, SD card loader, RC2014 expansion bus etc. Available in kit and built form from The Future Was 8 bit.

• https://tfw8b.com/product/minstrel-4d-turbo-jupiter-ace-compatible-computer-kit/

More info in a previous post:

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

RC2014 Serial Card

My version of an RC2014 serial card is available from Z80kits.com, and is an ideal companion to the Minstrel 4D

• https://z80kits.com/shop/tynemouth-68b50-clocked-serial-port/

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 Patreon is currently getting a lot development logs on a new project at the moment. This also includes access to my Patreon only Discord server for even more regular updates.

https://www.patreon.com/tynemouthsoftware

Jelly Load with Artificial Sweetener

I should give a flashing images warning here. If you are affected by such things, give these post a miss.

We are still spending for more time on Jelly Load than any sensible person should, tweaking all the parameters to try to get it as fast and reliable as possible (those two things are normally in opposition with each other. Fast, cheap, reliable. Pick one)

I did look at adding a checksum to JellyLoad, but just couldn't get it to fit into the available space (the loader code has to run from the cassette buffer). It would have needed a bit more restructuring and rewriting, so I have given up on that for the moment.

There are some safety checks at the start, a sequence of patterns that for the header that have to match the expected sequence, then the load address needs to be valid.

That also checks you have the correct version of the loader. There needs to be three different builds for the three different VIC20 load addresses.

Memory	Load Address
Unexpanded VIC20	$1001
VIC20 + 3K	$0401
VIC20 + 8K or more	$1201

(Yay for standardization. Standards are great aren't they, there are just so many to choose from.....)

If/When I add this to the Penultimate Cartridge, I will need to tie it in to the RAM selection so you always have the right version for the RAM selected. (or I need to write a version of the loader which required 35K RAM to be selected and then fudges the VIC's memory detection so it switches to the appropriate mode)

Colour Bars

This is the test program we have been using recently. Credit to TFW8b for this one, it's quite a neat idea.

It is just a series of PRINTs, it is important that it is not just a loop.

If any of the program bytes are corrupted, skipped or repeated, it should immediately show on the screen.

One extra space caused by a rogue clock pulse will move everything else out of sync.

I don't know what's gone wrong here, but it's certainly not right.

Artificial Jelly Load

The current setup involves pointing a webcam at some LEDs. We have proved that can be done, and that it works.

I was wondering if I could bypass that step (and any potential problems that could introduce) and generate the video file programatically to give the best chance of success.

I did look at directly generating video from Python, and that seemed like it was getting complicated, so I decided to take an "easier" approach.

An "Easier" Approach

The plan was to create a folder of images, one for every combination of LEDs, and create an animated GIF or a video file from those.

I was thinking I needed to create images of all the possible patterns, and I could then create a folder of frames that were copies the appropriate images.

(side note, I am working on linux, so I will actually be creating symbolic links to the appropriate images, rather than copying them, but if it helps, just think of it as copying the files rather than creating shortcuts)

OK, so how many patterns are there? Well, it's 9 bits, so that is 2^9, or 512. Or put another way, each byte of the source file can be one of 2^8 or 256 values, and I need versions with the clock high and low, so 512 in total.

I could sit and colour in the appropriate bits of over 500 images, but I would rather not thank you very much.

So I need to generate these myself. Again, there are programmatic libraries for generating images, but I want the "easy" way.

I had worked out all I need to generate is a 3x3 pixel image. This can then be enlarged in the video player, and TFW8b was already applying a mask to the image to just leave between 0 and 9 clean white circles on a black background. (more recently this has become a transparent background)

I created a 3x3 test image and tried saving it in various file formats, to see how large the files were, and how easy it would be to generate a run of 512 of them automatically.

Most image files have headers that would need to be generated. The actual image data is usually compressed, either lossily like a JPG file, or lossless compression like a PNG file. Some file formats also contain palettes and even thumbnail previews of the larger image. All of this adds to the complication of generating these without getting bogged down into an image generation library.

I also looked into SVG vector images and the potential of creating a font, bit it seemed that standard raster images were the best option.

One file format that looked promising was .RAW files. Saving in that format produced a file that was only 9 bytes long, and it turned out that was one byte per pixel, either 00 or 01.

It also generated a six byte RAW.PAL file, presumably a palette file, with a 24 bit RGB value for the two index colours. 00 00 00 and FF FF FF, black and white respectively.

Great, that will do nicely.

I set about writing a simple bit of C code that generated all 512 of these 9 byte files.

512 files, check. Now I can use FFMPEG to render a video based on this folder full of images.

Well, no, it seems it does not support RAW files.

Damn. (should probably have checked that first)

Plan B.

I know it can work with PNG files, so I can use the imagemagick Convert program to convert all the RAW files to PNG.

Except that doesn't support RAW files either.

Damn. (should probably have checked that first)

Plan C.

I don't want to get into generating PNG files directly, so I just need to find a format that I can generate easily, and that can be easily converted to PNG.

OK, what file formats does Convert support?

I looked through various options doing the reverse process. Taking a 3x3 pixel PNG file and converting it to various supported formats that looked promising and seeing what size files they produced. All the ones I tried were too large / complex.

Then I found .MONO format and that looked interesting.

Not exactly sure what a "Raw bi-level bitmap" is, but it sounds like just what I need.

I converted the .PNG to .MONO and the resulting file was 3 bytes long. (.GRAY also looked interesting at 9 bytes, and would have worked, but I went with .MONO in the end)

I assumed that was a mistake, but when I loaded the .MONO file in GIMP, it was the correct pattern I had started with.

3 bytes? How?

Looking at the file in a hex editor it appears it is a line based bitmap.

05 02 05

The first (and last) line is 000 0101 in binary, and the last three digits match the pattern. The second is 0000 0010, again the last three match.

I wasn't sure of the bit ordering, so I created a test file to see if I had understood correctly.

07 00 01

Yes, I understood correctly, and it's starting with the leftmost pixel. So the line has a 1 if the leftmost pixel is black, 2 if the middle one, and 4 for the rightmost.

I modified my C program to generate 512 of these 3 byte .MONO files.

Perfect.

FFMPEG didn't accept them, but that's fine, I wasn't expecting it to.

I wrote a little bash script to convert all the .MONO files into .PNG files.

OK, look good so far. I think I will call these Jelly Moulds.

Now, I can feed those to FFMPEG and I generated a video.

That looks promising, so I set about writing a program to read in a PRG file and generate the appropriate series of frames.

The test program produced 3031 frames from a 1.5K PRG file (two frames per byte to allow the data to settle before toggling the clock).

I generated various MP4 files from that series of images, there are two parameters to set, both frame rates. The one that is normally used, the "r" parameter is the frame rate of the output video. 60 frames per second seems the optimal, and we have been able to feed these into and out of YouTube successfully.

The other is the "framerate" parameter, and this is the number of source images are used per second. So a frame rate of 1 would show one of these block patterns every second. A frame rate of 60 would show one pattern per video frame. This is the highest speed we could hope to achieve if the light sensors (and VIC20) were fast enough.In this case, 8 seems to work well, that works out 125mS per pattern, two per byte, so 4 bytes per second.

Mono files => PNG files => Symbolic links based on PRG file => MP4 files => OBS => YouTube => Light Sensors => VIC20 => PRG file loaded

I should really draw a flowchart.

Programatically generated Jelly Load. It's hypnotic. (N.B. I can neither confirm nor deny the presence of subliminal messages that may cause you to buy my stuff)

Look into the squares, look directly into the squares, the squares, the squares, not around the squares, don't look around the squares, look into the squares, you've loaded.....

Those videos are now off to TFW8b to experiment with. I think the squares version rather than the dots is favourite so far.

STOP PRESS

The latest tests include "Micro Jelly Load", a smaller and less obtrusive version. Hopefully will not be as distracting and disappear into the background like the flickering squares that used to indicate the adverts were about to start on ITV, or the white dots that indicate the end of a reel on old movies.

Side Quest

When I first tried to generate the MP4 file from the PNG images, it failed. 3 pixels wide was not appropriate as yuv420p video format requires an even line length.

I initially added a scale by 2 operation to the mono files in the convert operation. That produced 6x6 files, which worked, and generated videos, but on playback, the images were blurred as the video player performed some smoothing of the scaled images.

I think that would probably still look fine behind the mask, I thought it was best to scale the images to the size of the box in the final YouTube videos. I changed that to scale by 128, so 128x128 per square, 384x384 overall. That produces the cleaner square videos seen in the rest of the post.

Just watching those videos makes me think I have seen that before.

Ah, there we go. It seems someone else was experimenting with Jelly Load in the 80s.

They even tried the transparent version.

---

Advertisements

To load these programs, you will probably need a Penultimate +2 Cartridge

• https://www.tfw8b.com/product/vic20-penultimate-plus-two/

There is also my store with the full range of Minstrel and Mini PET accessories. Mini PET kits are all sold out now, but I do still have some Minstrel 3 kits left, which will last until I run out of Z80s.

I can ship worldwide, use the link at the top of the page to contact me with your location and what you want. Sorry I have to keep saying that. I am working on an alternative.

All the links can be found here:

• http://blog.tynemouthsoftware.co.uk/2023/09/minstrel-and-mini-pet-kit-updates.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. If you want to see more posts like this, it would be great if you could give me a bit of support on Patreon, or via the PayPal link at the top of each blog post.

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