Category Archives: Retrochallenge

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.

 

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;
}
}

 

 

Retrochallenge 2016/2 – Interak keyboard

So RC is upon us and I have decided to replace the failed keyboard on my newly acquired Interak-1 with a modern USB item.

The Interak keyboard uses a 7 bit parallel interface to present an ASCII character to machine itself with a strobe line to say that the data is ready. It’s a bit much to ask the Interak to cope with USB directly and it’s a bit much for me to learn enough about USB to be able to program a Z80 to cope in the time allowed and I don’t want to.

161001-img_20161001_181323Enter HobbyTronics who produce a small USB host board that just needs 5v and a USB keyboard and will produce a serial output.

The serial output can’t go straight in to the Interak either but serial to parallel isn’t too bad.

Enter Arduino.

161001-img_20161001_205049So, here we have an Arduino UNO with a prototype shield and a tiny USB keyboard. At the moment it’s just reading the serial input from the keyboard adapter and squirting it down the serial port to the PC but it’s a start.161001-img_20161001_205115 Next is to set up some pins for the parallel interface.

Keep watching (if you want).

Retrochallenge 2016/2 – Throwing my hat into the ring.

It’s Retrochallenge time again and how quickly it comes around and how ill-prepared I am.

Recent competitions have seen great entries by talented retro-folks the world over whereas my contributions have been less glorious but filled with enthusiastic zeal.

This time around will be no different 🙂

I’m not sure what I will do to be honest. I may take a broken retro system down from the “shelf of good intentions” and try to fix it. I may try and interface a ZX printer to something non-Sinclair or perhaps get the Tandy 4 colo(u)r plotter talking to my PDP-11. Who can say?

Whatever happens there will be joy and frustration but mostly joy.

In the words of poppy-funster “Jem”

It’s just a ride, it’s just a ride
No need to run, no need to hide

Though there may be a need to solder…

See you on the other side.

 

Retrochallenge 2016 – End of the line. All change.

Well, another RC comes to an end an if there’s any truth in the saying “It’s not the winning, it’s the taking apart” then all is well. If, however, it is the winning then we have another “success deficit” on our hands.

So far I have the VT-180 in pieces. I looked at a few signals on the video board and compared them to those marked on the schematic but they all looked fine (see the photos).

160116-IMG_20160116_181840 160116-IMG_20160116_181754 160116-IMG_20160116_181725So next up I wondered if the 2114 static RAM chips have failed. I’ve seen them go on my DEC Rainbow and also on a Commodore PET a friend of mine has, so it’s quite common really. It would explain the garbled output.

One thing I like about DEC kit is it’s well made. The downside is that they used a lot of solder and getting chips out of any DEC board I’ve ever worked on is very difficult. So, as the last few hours of RC2016-1 tick away I have3 chips out, new ones on order and crud to clean out of the holes in order to add sockets.

The nice thing about Retrochallenge is there’ll be another one passing by any minute now.

Retrochallenge 2016 – Week 1 done. Some progress.

So here we are, one week in to RC2016-01 and what do we have to show for it?

As you saw in my previous post, I have taken the lid off the VT180 and it sits as a bare metal cage while I try to figure out what’s wrong.

151231-IMG_20151231_174248The initial display (shown on the left) has changed and is less verbose. 160106-IMG_20160106_194827 I’m not sure what happened to trigger the change.

The screen display is no longer in sync and rolls very quickly.

In order to help with the repair I have taken the VT100 board out of the card cage and I have it plugged in to the cable that was powering the card edge connector on the card cage. It’s clearly straight through so should be fine.

160106-IMG_20160106_194705That means that I can get to the board with my meter and ‘scope etc. I have also removed the AVO (advanced Video Output) board and the small inter-connect board. This hasn’t changed the symptoms at all.

The first real diagnostic work was to measure the voltages from the PSU. They all seem fine.

I have been able to use a logic analyser (borrowed – I really want one of these) and I’ve been taking a look on the bus.

have attached three screen shots taken of the logic analyser screens. I have 18 channels and so I have the data bus, the lower 8 bits of the address bus and the synch pin. All signals are from clips on the 8080.

I have the triggers set to stable high on sync (start of new instruction) and 0 on the address bus. I put the analyser to wait for trigger and turned on the VT180.
The three shots are from the same run and I’ve just stepped through the time a little to show what happens at start up.

vt180-digiview-3vt180-digiview-2vt180-digiview-1I get this with or without the keyboard. With the keyboard, all of the lights are lit. When I first started on this repair, a few, normal looking lights came on first and then, after a while, they all came on. It’s a funny old world.