Thursday, 30 July 2009

IM2 interrupts not working!

I tried getting vectored interrupts working last night but after several bleary eyed hours in the early morning realised it was not my dodgy software but my even dodgier hardware!

I'd not realised that the Z80 doesn't assert /RD during an interrupt acknowledge cycle, meaning that the buffers are not allowing through D[0..7] to the processor. This was confirmed by rewriting the software to work from one vector at I*256+0HFF which worked (all lines are pulled high when /RD and /WR are not asserted)

Tonight I'll try changing the buffering arrangement to work solely on /WR....

Friday, 24 July 2009

Full speed ahead....

I've finally got everything working at 4Mhz and almost working at 6Mhz.

I improved the routing of supplies and decoupling on the memory board (that actually made things worse!)

I added pull up resistors to the memory data lines (buffered) on the memory board and all is now well.

The thing seems to clock up to 6Mhz but then crashes at exactly the same point each time I reboot so it could be a memory/speed issue or it could just be a bug in my transmit code that is only showing up at higher speeds....

Source for z80 monitor

The sources for the monitor for my z80 machine are here:

This gives enough CP/M like functionality to run MBasic and BBCBasic

Thursday, 16 July 2009

It gets better....

Now I've got a proper Basic working! R.T.Russell's BBC Basic. This allows proper programming and outperforms MBasic in many areas and it uses a lot less memory!

Wednesday, 15 July 2009

Now for some real programming...

Yay! I've now written a monitor program to test things out it consists of:
  • A basic CP/M BIOS - no disk stuff yet
  • A "monitor" program - a hacked down version of CP/M 2.2 with no disk routines (to fit in 4k rom window)
  • An intel hex loader
With this I can now run a few CP/M programs, the screen shot above shows MBasic running, with this I can write some real programs ;)

Now to see if I can get any shareware games working!....

Monday, 13 July 2009

Full Duplex - With interrupts

I've now got Serial I/O working fine on one channel. I've made two ring buffers for receive and transmit and the interrupt service routine services the SIO and places stuff in the buffers. I can transfer huge files looped back through a simple program without losing a byte so it should do for now - though it is slow. I think I need to look at how it prioritises TX and RX as with the processor running at 1MHz and a baud rate of 19200 it doesn't quite give the throughput I'd hoped for more like 1000 cps. Still it will do for now if it is reliable.

For handshaking I've now tied the DCDA line low, ignore the RTS line and instead use DTRA on the SIO as a RTS/RTE this is controlled by the interrupt routine which turns DTRA high when there are only a few bytes left in the ring buffer and reenables it when the buffer is emptied.

Now to write a simple monitor so I can upload code without having to pop the Flash ROM out every five minutes - I'm bound to drop it in a cup of coffee or bend the pins sooner or later....

Sunday, 12 July 2009

Serial I/O I think I've worked it out

The SIO uses the old sense for the RTS/CTS lines (asymmetric) so I will have to use different lines. So I think I'll use DTR on the SIO to control data in and tie DCD to ground to auto-enable the receiver and see if that works.

Here's the I/O schemas so far:

Serial IO Working...well sort of!

I've made up a bit of ground on my Serial I/O card today and managed to print a few messages from the Z80 to a computer running Hyperterm in both 3-wire (no handshaking) and 5-wire (RTS/CTS) handshaking - however I've can only get 3-wire working in the opposite direction. I think I need to bridge some signals at the PC end to use just RTS/CTS or possibly use different signals from the SIO instead of its own RTS.

On the memory glitches I've now got it working 100% fine for all but the first bank which goes through a lot of different gates to get the boot rom select to work, I think I may have too many gates in the path and it is not settling quickly enough so I may have to rethink that bit!

Saturday, 11 July 2009

Memory problems

There are still a few problems with memory, running a memory test routine at 4MHz throws up a few spurious errors every now and again, fewer at 2MHz and non so far at 1MHz....more capacitor swapping might be in order. I'll get the soldering iron warmed up!

I've got a simple PS/2 PIC microcontroller program working - well it will display the scan code of the currently pressed key on a row of LEDs and send / receive keyboard commands. I'll hook this up to the PIO when I get it going.

First though I think I'll have a crack at getting the SIO going. I've got an SIO/2 chip here and a MAX232, should be enough to get a terminal interface going!

Wednesday, 8 July 2009

Back working again

Today I decided to try replacing all the metal foil caps with ceramics, after about half way through (I'd only done the memory board) I decided to check to see if the thing still worked at low speed and to my surprise it now works at full speed. So two conclusions:

a) It wasn't the metal foil caps causing the problem - the processor, IO and monitor board are covered in them still
b) It must have been some dodgy wirewrapping / soldering near the decoupling caps. I probably melted through a wire sufficiently to allow leakage but not a dead short which was causing problems!

Two feelings after this - elation at getting things working, despair at all the time lost messing about!

Anyway I've now got the LCD interface working reasonably well and written a little scroller - sorry no video, my crappy camera will not take videos of the LCD. Also written a memory soak tester - so far all my 32K RAM tests good!

Next up:

PS/2 keybaord interface
RS-232 interface
CGA/VGA card
SD/MMC Card interface
Graphical LCD interface

Not sure which order I'll attack these in but I'd like more info on my intended VGA card (pictured below). Specifically I'd like to know more about the dip-switch settings at the rear. I can see these causing headaches if I get them wrong!

The card is marked MAGIC VGA, CT-8490 and uses the Cirrus Logic GD510A Chipset.

Tuesday, 7 July 2009

Progress of sorts...

After much messing I've:
  • added extra decoupling capacitors - this seemed to make things worse! [I used metal film caps as I've got loads but these may be making matters worse - I'm getting some ceramics today]
  • tried removing the clock signal from the bus to make sure it was getting to the z80 cleanly
  • tried different z80 chips
  • replaced all the 74LS244 buffers on the processor board
  • tried adding pull-up resistors to the data bus (tried 10k and 2k2)

This all made no real difference with the processor often randomly jumping to FFFF or 03FF and register load/saves containing random data

Finally, in depsperation, I added a set of 74LS244 buffers to the memory card databus and can now get reliable operation but only up to 1 MHz whereas before all this started going wrong I could acheive full 4MHz if not 100% reliably.

Next up I'll try swapping all the decoupling caps for 100nF ceramics (should have lower inductance and better a mopping up spikes?) and check that I haven't got any decouplers connected to the wrong lines!

Anyway after all that messing I got my LCD I/O Port working at about 1am, enough to display a hello world anyway!

Sunday, 5 July 2009


A very frustrating day, first I blew my last LCD panel by getting the power connections mixed up...

Then about 6 hours trying to figure out an intermittent problem that has now become permanent:
  • Stepping through program slowly / by hand register contents are random
  • Sometimes works at full speed
  • Sometimes randomly jumps out of program
Tomorrow will have a few checks:
  • Is interupt /NMI getting generated? I've not noticed any IORQ + M1s - these lines should be pulled high
  • Is ROM corrupted - had trouble then it worked then trouble so doubt its the ROM
  • More decoupling!
  • Buffer memory data bus?
Very frustrating!

Friday, 3 July 2009

It lives!

Yay after a few false starts I've got all the 7-segment displays wired up and the system now functions.

I had to do a fair bit of debugging and re-wiring to get all of the displays to work properly - I shouldn't sing along to the radio when wirewrapping.

When all was well I retried the test program from yesterday and this still didn't work. After a lot of debugging and getting nowhere. The thing was following the program flow but writing out random data on all MREQ+WR's and IORQ+WRs from the processor which I put down to my processor buffers being wired wrong - then I spotted that it was wrong *differently* each time....after much messing about I tried a different processor chip - hey presto it all works! Only a couple of hours wasted!

Here's a picture of the board halted (A=E12F D=ED, during an M1 cycle read)
And below is a video showing me single-stepping through a test program, then in the second half the test program running at full speed (4MHz). The program outputs repeatedly to the top 7 IOnn lines to make a simple fading routine to make each LED light up bright then gradually dim - well that's the idea anyway.

Next up I'll tackle a simple LCD board so I can do a "hello world"

PS: Sorry I made the videos "upside down"!

First Run...

Yesterday I finished wiring the processor board and I wired up a new board with a 24 LEDs and buiffers to help diagnose any problems (they cover the control and IO[0..7] bus signals) I'm going to also wire up 6 x 7 segment displays to display the current A[0..15] and D[0..7] lines as hex (well as the odd hexadecimal that the 74LS47 makes)

However I couldn't resist (it was taking so long to wire up the seven segment displays) so had to plug in and give the thing a test.

First there was a problem with the thing just hanging which I managed to trace back to the WAIT signal always being asserted, this due to me not wiring the pull up resistors to Vcc but instead to GND. Wiring up all those LEDs has already proved its worth! I'd never have spotted this so quickly without them!

Next I tried running at full speed, the ROM is blown with a program that should reset the memory controller then access each of the IO1..7 lines (not 0) over and over. When I ran it these all lit up dimly! Success...maybe

Next I tried single stepping, this was less successful firstly it gets stuck after a reset.....then I found that reset only works by holding down reset and doing a number of clock cycles. Then it kind of seems to work but is not running the program I intended there's a few M1 cycles showing up but sometimes it will do a lot of cycles without and M1. I'm not sure if this is due to the single step switch bouncing - I'll try a bigger debounce cap or if there's something bad happening. Also the IO1..7 lights don' light up as expected so I reckon something odd is going on!

Next I tried wiring up the most significant digit of the address lines to it's 7 segment display this should be showing E all the time but actually jumps about all over the place which suggests to me that there's a problem....anyway I'll try and connect up the other digits and see if I can work out what's going on.

Back later with some pictures...

Thursday, 2 July 2009


After a few days of construction - processor board part built (z80, buffers and clock generator) I've made a few changes.

I spotted a few mistakes on the memory chip select logic - still not sure I've got it quite right, when it boots the ROM bank at 3F000 (in the ROM) should be mapped at both 0000 and E000 in the Z80 address space. Any write to IO0-32 should then remap the ROM if bit 6 is set then RAM will be mapped at 0000....we'll see if this works.

Another change was to add 40106 to detect the reset and clock switches as normal TTL logic gave noise at the switch over (the 40106 is slow and has schmidtt inputs).

Lastly I moved the clock signal to be away from other lines and between two ground lines - it was giving a lot of cross-talk to other lines at 4MHz and as this is the highest frequency line I supposed it would be better away from the other lines. If the other lines prove to cross-talk too much I may have to completely re-think the bus!

Anyway here's the schematics so far....