Category Archives: Blog posts

Retrochallenge 2017/4 – Interak CF card – Wrap up

Well Retrochallenge 2017/4 is coming to an end and it’s time to wrap up this season’s efforts.

I set myself the challenge of adding CF card support to my Interak-1 and basically, I didn’t make it.

However, since the last post I have made some progress; I have tried two new CF cards (thanks to Spencer at RC2014.co.uk for that). These gave different results to the original and seemed to work better.

I still don’t understand why two different but equivalent I/O commands give different results. It has been suggested that timing is the issue here but I don’ know enough about Z80 hardware to try and add a wait-state when accessing the CF card.

The current state of play is that I think I can read the card but as I don’t have a way of writing to the card on a different machine, I can’t prove it :-(. I have a write routine written on the Interak but I don’t think it’s working.

On the plus side, I have built an adapter to add a CF card to my machine by adapting hardware intended for the splendid RC2014 machine. That’s not too shabby.

There is more work to be done here.

 

So long Retrochallenge, it’s been fun. See you in October!.

Retrochallenge 2017/4 – Interak CF card – Part 4

We are well into the second half of Retrochallenge now and it fair to say that I’m not where I wanted to be. However I am learning a great deal about Z80s and CF cards are their respective wily ways.

Things continue to be confusing.

A quick re-cap of my previous posts…

It started off with the status of the CF card never showing that the read transfer was ready. However, using the ROM monitor on the Interak rather than the program showed that it was. There were various trials and hair being pulled out but what it boils down to is this.

If I use…

    ld        BC, (0x0067)
    in        a, (C)

I get one value but if I use…

    ld        a, 0x00
    in        a, (0x67)

I get a different answer.

Note 0x67 is the CF card status port.

According to the Z80 manual from Zilog, in a, (C), puts B on to the top of the address bus, C on to the bottom and reads from the addressed I/O port. So that’s 0x0067.

Now, in a, 0x67, puts A on to the top of the bus (previously loaded with 0) and 0x67 on to the bottom and reads the addressed I/O port.

These two are functionally the same but give different results.

One suggestion that has been made though the VCfed forums is that it’s a timing issue as the in a, (C) version takes a little longer.

I have a few things to try. I have a couple of other CF cards on order and they should arrive soon. I’ll try them to see if there is some issue with the timing of this card. I’ll also look to see if I can get a wait state in to the IN operation.

More news when I have it.

 

Retrochallenge 2017/4 – Interak CF card – Part 3

Things are a little weird as I suggested in my previous post.

I have the CF card installed and if I use the ROM monitor in the Interak to access it through a series of Port commands, I can see what appears to be sensible data. If, however I use a piece of Z80 assembly language, I never see the CF card become ready.

I have tried my own code and two other variants found on the web.

Let me show you what I mean. This snippet came from Scott Baker’s website…

1069:         	WAITDRQ:
1069: F5      	        PUSH    AF
106A:         	WAITDRQLP:
106A: DB67    	        in 	A,(I7)
106C: E608    	        AND 	08H
106E: FE08    	        cp 	08H
1070: 20F8    	        JR	NZ, WAITDRQLP
1072: F1      	        POP 	AF
1073: C9      	        RET

To use this, I have set up the sector and all other parameters needed for a disk read. If I run this routine, it never finishes. breaking the code at 0x106C shows that the accumulator is either 0x40 or 0x41. Which means “Drive ready” or “Drive ready + error”.

However, if I use “P 67” at the monitor, I get “0x58” which means “Drive ready + Drive seek complete + Data request ready”.

I can run from 0x106A to 106C again and again I see 0x40 or 0x41 in the accumulator. If I use “P67” again, again I see 0x58.

Can anyone see the deliberate mistake because I can’t 🙁

Retrochallenge 2017/4 – Interak CF card – Part 2

In part 1 I was able to build a CF card adapter for the Interak. Mostly this involved using RC2014 parts.

Now it’s time to tell you about the testing and things are pretty weird.

A bit of background.

At the moment, my Interak-1 has no mass storage at all. No hard drive or floppy. Nor does it have a serial port that I can connect to my PC.

It only has cassette, screen and keyboard. This is making testing challenging.

In an earlier post, I described a USB keyboard adapter that I had built during last year’s Retrochallenge. This gives me a USB keyboard. At the end of the post I mentioned adding USB serial in so that I could use a serial terminal emulator to “squirt” data at the Interak as if it had been typed in.

I did that mod and this is the method I am using for testing because no one wants to type in a couple of hundred bytes of hex manually that may well crash.

It has no handshaking and so I have to be careful not to send too much at once but it’s working well.

First steps.

I am following in Scott Baker’s footsteps a bit here. Scott has added CF to the RC2014 and it’s his board design I am using. He describes the process of setting up the card and reading a sector as follows…

Setup:
read register 7 until the busy bit (0×80) is unset
write 1 to register 1
write 0xEF to register 7
write 0×82 to register 1
write 0xEF to register 7
0xEF is the “set feature” command. Feature 1 enables 8-bit mode. Feature 0×82 disables any write caching. You should do this whenever the compactflash is reset or power cycled.
Read a sector
read register 7 until the busy bit (0×80) is unset and the ready bit (0×40) is set
write 1 to register 2, to set the sector count to one sector
write bits 0..7 of the block address to register 3
write bits 8..15 of the block address to register 4
write bits 16..23 of the block address to register 5
take bits 24..27 of the block address, or them with 0xE0, and write to register 6
write 0×20 to register 7. This is the “read sectors” command.
read port I7 until the busy bit (0×80) is unset and the DRQ bit (0×08) is set
read 512 bytes from register 0

By using the PORT command (P) of Zymon 2 (the Interak’s ROM monitor) I can carry out the above instructions and it seems to work well.

Just a note. Zymon is a little quirky and it’s not the easiest thing to follow. I can’t put blank lines in for clarity, they get ignored. Also, the P command reads from (no parameter) or writes to (one parameter) an I/O port. However, if I type, for example “P 67” to read the status byte on the CF card, Zymon puts the byte on the same line making it impossible to see whether or not I wrote to the port or read from it.

In this photo I set up the card ending with the line “P 67 EF”. I then do the read (up to line “P 67 20”). I get the status with “P 67”, the result is “58” – Drive ready + Drive seek complete + Data request read.

The, the following “P 60″s show data being read from the first sector of the drive.

Yea!

Now the weird. I have tried doing this using a bit of assembler code and it doesn’t work.

I’ll put the full details in my next post.

Retrochallenge 2017/4 – Interak CF card reader revisited – Part 1

Retrochallenge is well under way now and so it’s time I made a start and got something blogged about. Although my posts here don’t show a lot of activity, I do some work on one or other of my retro systems most weeks throughout the year but Retrochallenge is a good reminder to blog about some of this activity in the hope it may be useful to someone else or help to promote interest in our hobby.

Catching up.

A little while ago I tried to get a CF card adapter to work on my splendid little Interak-1. That didn’t work properly but an email conversation with a friend of mine who also has an Interak suggested that my cables were too long and that I needed to get the CF card as close to the CPU as possible.

So, my first Retrochallenge project this time around is to re-visit that project and try and get it to work.

In the previous attempt I used a CF card adapter intended for the RC2014 (itself a Retrochallenge project). In order to get that to talk to the Interak I needed to make a bus adapter and to do that I modified an Interak prototype board.

As I said  above, the suspicion is that the CF card was too far away from the CPU.

Lets build a Mezzanine.

One way to get really close to the CPU is to slip a PCB between the CPU and its original socket and use this new PCB to link to the CF card adapter. This is the approach I’m using here.

I still want to use the CF adapter for the RC2014 and so I still need to convert from my Z80 CPU to the RC2014 bus. What better way to do that than to use an RC2014 CPU card?

Spencer Owen of RC2014 had a small number of prototype CPU cards in his Tindie store and bought one of those, soldered a wire-wrap socket to it, plugged that into a conventional socket and on into the socket my CPU originally sat in. (This is going on a bit, see the pictures).

Now the Z80 sits on the RC2014 CPU board and the Interak CPU board with the CF adapter over to the side.

 

Interak Compact Flash adapter – Part 1.

I have been making good progress with the Interak-1 and having a lot of fun on the way. I have made an adapter so that I can use a modern USB keyboard. I completed the VDU2K video board that was given to me with the machine so now I want to improve its storage.

My machine came with a twin port cassette card and a floppy disk controller.

I don’t think cassette is a goer these days. It was OK back in the day for home use but this machine deserves better. The floppy disk controller will be useful but I’m rather taken by Scott Baker‘s Compact Flash adapter for Spencer Owen’s RC2014 Z80 retro machine.

Spencer is an old friend of mine and his RC2014 has become very popular, with many kits being sold through his Tindie store. As with other good ideas, RC2014 has been a focal point for other people’s efforts and Scott Baker has contributed some great projects that build on the RC2014 is very cool ways. The Compact Flash adapter is one such project.

Scott has generously put his designs out there and made his PCB designs available through OSHpark.

The bits on the bus (go up and down)

Both the Interak-1 and the RC2014 are Z80, slot based machines with easy access to the bus. The first thing to sort out is to get the buses to match.

I was given two blank prototype cards with the Interak and so one of those will do fine.

There is a possibility that I will want to add more than one RC2014 board to my machine and so I didn’t want to just solder one of Scott’s PCBs to the proto card. At this point I bought an RC2014 5-slot backplane and planned to fit that to the proto board and link between the to buses.

In this photo you can see that I have soldered a pack of short links from the Interak bus connector. These will go on to have their loose ends swapped about and fitted into the RC2014 bus.

Here you see that I have pushed the flying leads into one of the backplane’s slots. At this point I was just setting things up and testing the connections.

OK in principle but I need A bit of Vero

The problem with the approach shown above is that the backplane is just a bit too big. I could cut the top and bottom off it, there isn’t anything important there, but that would spoil it. I’ll keep it for later. Maybe I’ll build an RC2014 ad I’ll need it then.

As there isn’t anything too complicated about the backplane, I substituted a piece of Vero stripboard instead.

That fitted much better.

The CF card adapter.

As I mentioned above, Scott Baker has published his PCB design on OSHpark for anyone to order. OSHpark has a minimum order quantity of three and I only wanted one but, someone else only wanted one it seems as a blank PCB appeared on ebay. Yea, here we go.

The circuit for this card is very simple and it would be very easy to lay it out on the proto card except for the fact that CF card sockets have tiny connectors and really don’t work with 0.1″, through-hole boards. A very good reason to use the RC2014 card.

Here we have the populated CF card adapter plugged into the stripboard backplane.

Next time I’ll try it out.

 

 

Interak VDU2K progress.

In my previous post I talked about a second VDU card that came with my Interak-1. This is a VDU2K and supports 64×25 characters in its 2K of video memory.

When I finished the card and plugged it in, it mostly worked but there were problems.

Clearly the monitor ROM was expecting half the resolution and put the prompt half way up the screen but it wasn’t clear whether or not there were other problems. I needed to try and clarify is there was a hardware issue too.

To cut a long story short, I have blown a ROM that tries to clear the screen and then output every character in the character set.

The photo shows that the character set looks fine but clearing the screen has failed. This particular photo is misleading as it shows the screen filled with a single character. That is unusual. I usually see a repeated pattern of two or three characters. I’ve tried a few versions of this test. I’ve put the character set in various places but it makes no difference. The result is always that the screen doesn’t clear properly but the character set is fine.

I think the problem is somewhere in the circuit that looks after memory reads.

Outputting the character set.

;
; Now. Just dump out the character set to the screen.
;				
   ld		hl, SCR_START;
   ld 		b, 0x00
   ld		a, 0x00

loop:
   ld		(hl), a
   inc		hl
   inc		a
   
   djnz	loop

When I output a character set, I’m getting the CPU to write ascending values to successive memory locations. Just writes.

start:   ld		hl, SCR_START
         ld		de, SCR_START + 1
         ld		bc, SCR_WIDTH * SCR_HEIGHT - 1
         ld		(hl), 0x00
         ldir

When I clear the screen I’m writing a 0 to the start of memory and then using the Z80 instruction LDIR to copy that throughout the scree’s memory. In order to do that, the Z80 must read the first location and copy it to the second. It then reads the second location and copies it to the third and so on.

The LDIR has to read memory and I think that’s the bit that’s going wrong.

Further reading.

When my friend Dave got this card, it seems that not all of the documentation was available. However, thanks to a chance discovery, I had been in contact with Dave Parkins of Greenbank Electronic the original designer and he generously found and emailed the design notes for the card!

As I was reading through these notes I came across this paragraph:-

In a current Interak 1 disk system all of the 64k of RAM should be enabled. All elements of the two DIL switches on the DRM-64 card should therefore be OFF.

My RAM card had been set to just use 48K. I switched in the remaining 16K and Bingo! we have a clear screen.

The new card seems to need the RAM beneath its own. I think it has something to do with the way the Interak avoid snow on the screen. However, we are up and running now.

As you can imagine, the monitor ROM doesn’t know about the extra screen real estate but it does work and so does the keyboard.

I was recently given some other binaries to try, including a monitor that can cope with 64 columns but it needs some attention as it was intended to run under CPM from disk.

Progress! I’m rather chuffed.

Interak video card upgrade.

161105-img_20161105_145915When I received the Interak-1 it had two video cards. One (VDU-K) was finished and working. The other had all of the passive components fitted – resistors, capacitors etc – but the semiconductors had not been added.

I wasn’t sure why there was the second card at first as they both looked the same but on closer inspection the second is a VDU-2K and at the back of one of my manuals is a preliminary description of the card. I think it was pre-release when the previous owner got it as the documentation isn’t as thorough as the other manuals but it appears that this card is 64 characters wide rather than the 32 characters of the VDU-K.

I went through the parts list and bought the missing ICs, fitted them are here we are.

There are a couple of problems. Firstly, in 64 column mode, the line input is half way up the screen. Secondly, whatever is typed in on the keyboard is misunderstood and a “>” character is printed.

The first problem could be just the the ROMS don’t know how to drive the new card and that I need new ROMS.

The second problem is more interesting. I don’t know yet why the video card is affecting the keyboard input, I have a keyboard input card in a separate slot so it’s all a bit odd.

More news to follow.

Interak keyboard – proof of the pudding

This is just a quick post.

I’ve spent some of the afternoon in a happy state re-living the 1980’s by typing in a hex dump from a magazine and spotting my mistyping.

161023-img_20161023_201745The magazine in question was Interaktion – newsleter No. 2 from the Interak user group and as you can see, the program is a version breakout.

You can see in the photo that I have added the USB serial mod I hinted at in the last post. This enables me to use a PC to squirt data through a virtual serial port and have it appear at the Interak as though it had been typed in.

Thanks go to Alan Paton at http://www.interak.co.uk for putting the newsletters onto the ‘net.

 

Retrochallenge 2016/2 – Interak keyboard wrap-up

160915-img_20160915_204655In my last two posts I wrote about how I made an adapter for my 1980’s Interak-1 computer so that it could make use of USB keyboards as the original Alphameric keyboard had failed.

Those posts were a bit rushed and the adapter was still a work in progress. It’s finished now and so in this post I’ll try to tell the full story and in more detail so if anyone else has the need for a USB keyboard to 7-bit parallel ASCII keyboard they will have something to follow.

The problem.

The Interak comes from an era before USB became ubiquitous, when a parallel cable running from a semi-intelligent keyboard to the main CPU was commonplace.

161005-img_20161005_192546With these keyboards, when a key is pressed, the binary representation of the key, in ASCII, is presented on seven data lines. An eighth bit called Strobe is then pulsed high (5V) and then low (0V) to indicate to the CPU that a character is ready.

Sadly, the keyboard that came with my Interak had developed a fault and several columns of keys didn’t work at all. I tested the socketed chips with my IC tester but they seemed OK and so I suspected the micro-controller and I didn’t want to go too far down that road and so I decided to do away with the  original keyboard.

What to do now?

I looked around for a while and found a number of solutions that will use PC keyboards with the PC-mini-DIN connector but they haven’t been mainstream for over ten years and I didn’t want to end up with the same problem later.

USB is the way to go.

When USB is the solution… Crikey.

161001-img_20161001_181323In all honesty, I don’t know a great deal about USB and the though of writing a USB host to interface with a keyboard seems like no kind of fun (Retrochallenge is meant to be fun) and so I looked around for solutions and found HobbyTronics who produce a small USB host board that just needs 5v and will produce a serial output.

Although a serial stream isn’t what’s needed, it is easy to pipe it into an Arduino and get that to output the ASCII in parallel on its IO pins.

161001-img_20161001_205049I made a prototype using an Arduino UNO connected to the Hobbytronics board.

To make debugging easier I used a software serial library to keep the hardware serial port free. More on that later.

The real thing.

The Arduino UNO worked very well. Well enough to convince me to use a small Arduino Pro Mini and make the thing real.

The Interak uses a 15 way D type on the front for the keyboard connector and so I soldered the Pro Mini as close as I could to the connector and the the three wires to the USB board.

161003-img_20161003_210244Next, get it into a small case… 161005-img_20161005_200524

Proof if proof were needed.

161005-img_20161005_200700So there you go. My beloved Interak has a new lease of life.

One more thing…

There is a nice little addition waiting in the wings here. The Arduino has another serial port, the hardware one and so It would be quite easy to add the standard USB to serial board and then the Interak’s keyboard port would appear to my PC as a serial port and I could squirt data into from a terminal emulator. There would be no handshaking and so I’d have to artificially drop the data rate with delays but it would work.

The code.

/*
* Interak-1 USB keyboard adapter
*
* By Andy Collins.
*
* This code is free to use.
*/
#include <SoftwareSerial.h>

#define CR 0x0d
#define LF 0x0a

SoftwareSerial mySerial(11, 12); // RX, TX

const int STROBE = 9;
const int D6 = 8;

int inByte = 0; // incoming serial byte
int lastInByte = 0;

void setup()
{
// Open the hardware serial port for debugging
Serial.begin(9600);

// Start the SoftwareSerial port
mySerial.begin(9600);
DDRD = DDRD | B11111100; // Using d2-d7 as output. Saving d0-1 just in case.

pinMode(STROBE, OUTPUT);
pinMode(D6, OUTPUT);

digitalWrite(STROBE, LOW);
}

void loop() // run over and over
{
inByte = -1; // Nothing yet

if (mySerial.available()) // USB Keyboard
{
inByte = mySerial.read();
}
else if (Serial.available()) // USB Serial port
{
inByte = Serial.read();
}

if(inByte != -1)
{
Serial.write(inByte);

if( (inByte == LF) && (lastInByte == CR) )
{
;
}
else
{
PORTD = inByte << 2; // Shift left to avoid TX, RX;

// Catch the overflow.
digitalWrite(D6, inByte & 0x40);

// Bits set up. Now Strobe;
digitalWrite(STROBE, HIGH);
delay(30);
digitalWrite(STROBE, LOW);
delay(100);
}

lastInByte = inByte;
}
}