Category Archives: Blog posts

RetroChallenge 2017/10 – Purely by coincidence

So here’s a thing. I recently met up with an old acquaintance who I hadn’t seen in years and as we’re both retro-computing fans we were talking about old machines.

I have just received an email from an old acquaintance of mine who is a dedicated retro-computing fan and has spotted my plight in these pages after following me on Twitter (@acollins22 if you’re interested).

He mentioned that he had had a similar problem on a Nascom a few years ago and it was caused by a buffer failing. Now I know this is wishful thinking but it’s worth a look.

The chip in question was an 81LS97, a 3-STATE Octal Buffer.

I’m not the most familiar with this to be honest, a keen amateur. My take on this is that Y1 will equal A1 when _G1_ is low. At other times it will be tri-stated. The other pairs (A2-Y2, A3-Y3 and A4-Y4 will do the same).

Is this right.

I wired up my old Blackstar logic analyser to IC47, the 81ls97 as follows…

  • CH0 – _G1_
  • CH1 – A1
  • CH2 – Y1
  • CH3 – A2
  • CH4 – Y2
  • CH5 – A3
  • CH6 – Y3
  • CH7 – A4

It’s set to trigger on CH0 being low. This is what we get.

What I see here is CH0 going low and so the outputs are enabled. Surely that means that CH4 should echo CH3 but as you’ll see, it doesn’t.

Does that mean I have a faulty 81LS97 or a faulty understanding of what’s going on. It seems a coincidence that a friend tells me how he fixed his Nascom and mine has the same fault but the trace above suggests just that.

Spooky.

RetroChallenge 2017/10 – More things it’s not

Having checked the clocks and finding things look well, it’s time to see if the ROMs are OK.

The Nascom uses 2708 EPROMs. These are 1k by 8 bits and must have been one of the first EPROMs available. The problem with them is that they need three different voltage rails and most modern EPROM programmers can’t do that. Even my old Stag won’t. :-(.

I can program 2716s however as these only need a single 5V rail and thanks to tkc8800 I was able to make a couple of plug in adapters so I can use the bottom half of two 2716s to replace the 2708s.

I have now put Nassys3 in the two 2716s and tried that.

Still the same… Arrgghhh!

 

RetroChallenge 2017/10 – Still looking for clues

In my last post I was suspecting the clocks.

Now I’m not so sure there is a problem with the clocks. Having traced them through everything looks fine. I’m not sure what I was doing wrong but the symptoms haven’t changed but I’m seeing bus activity now and also the _CS_ on the main 2708 EPROM is wiggling around as I suspect it should.

I’ll see if I can read the EPROM and see if it has bit-rot.

EDIT…. It turns out my programmer can’t read 2708s. Doh.

RetroChallenge 2017/10 – and the beat goes on

Yesterday I checked the voltages with my DMV and everything looked OK. Today I checked with the ‘scope just to check for ripple and they all look pretty clean to me.

Clocks

I also saw that there was a running clock but overnight I became increasing worried that it wasn’t a very good clock.

Here’s the circuit…

It doesn’t look too tricky.

Check with the scope.

A scope trace shows it’s a bit funny. I’m not sure quite what the Z80 needs but I thought it should have a better back edge than that.

More thought needed.

RetroChallenge 2017/10 – Let’s see what we’re up against

So, it starts.

In my last post I said that I intended to fix my newly acquired but already much loved Nascom-1.

Up until now I hadn’t even powered it on but the time has come.

Tada!

So that’s it, random nonsense. The reset button makes the screen flicker but the nonsense doesn’t change.

The previous owner said that he had tried a new CPU, cleaning all of the tarnish of the chips and the 74LS139 and 74LS11 associated with the video RAM address decoding.

He’s clearly better at this than I am but I’m still going to try and get this old one going.

First things first

Out with the multimeter and check the power supply. There are three rails; 5V, -5V, 12V and -12V. Helpfully there are four LEDS on the PSU board and they are all lit up. Also, the meter confirms that all are present and correct.

The bits on the bus go up and down

Sadly actually most of them don’t. I fired up the oscilloscope and looked at the signals on the pins of the Z80 CPU. There is very little activity. There is a clock signal on pin 6. MREQ is toggling. There is little else. There is no activity on M1 that signals the start of an instruction. The data pins are all high as are the address pins.

Surely there should be activity on the address bus?

That’s it for Today. I will read up on bus access and try to see why the address lines aren’t changing.

 

And you’re back in the room – Retro Computer Festival 2017

I has been several months since I last posted anything here. In fact is was my wrap-up of the work I had done during the RetroChallenge 2017/4.

I certainly haven’t been idle on the retro computing front. In fact I have been busier than ever. I just haven’t been writing about it.

Retro Computer Festival 2017.

Most of my efforts have been preparing for and attending Retro Computing Festival 2017 at the Centre for Computing History in Cambridge.

My old friend Tristan and I volunteered to fill a table with old bits and bobs and at the time of booking we brainstormed ideas coming up with “something to do with ASCII art”.

For those of you not in the know, ASCII Art uses the characters of the 7-bit ASCII set to represent brightness levels of bitmap graphics.

We decided to use a web cam, an old machine and a daisy wheel printer to take photos of people visiting the museum and print out low resolution ASCII version of them.

Non of the old machines we had in mind will support a web cam. They don’t even support USB so we decided to use a Raspberry Pi to grab images from the camera, turn them into low resolution grey scale images and send them to a retro machine over serial using the X-Modem protocol.

We weren’t going retro with the image capture but we were from that point on.

My first thought for a suitable machine was to use the Exidy Sorcerer but a quick internet search suggested that there was a problem with its serial port that might make things difficult.

Next up was my beloved Sharp MZ700 but that developed a fault in the PSU and started blowing fuses. The Wang laptop was to slow in GW-Basic and too unlike a PC for Qbasic or Turbo C.

We finally settled upon Tris’s 386 Toshiba laptop with its funky amber plasma display.

The printer of choice turned out to be an Epson dot matrix.

Other stuff.

It took a lot of mucking about to put this project together  and as the date drew closer we were getting a bit worried that it wouldn’t be working properly on the day and so we thought it wise to take a few other bits and pieces.

I the photo above you can see the Toshiba on the left, my Exidy sorcerer on the right. We also took a BBC micro incase of emergencies (we didn’t need it), my Creed 7B teleprinter and a Ti-99/4A.

In the end, the ASCII art worked pretty well and people seemed happy with the results.

Now, what to do next year.

 

 

 

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.