Thursday, 30 July 2009
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
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....
Thursday, 16 July 2009
Wednesday, 15 July 2009
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
Now to see if I can get any shareware games working!....
Monday, 13 July 2009
Sunday, 12 July 2009
Here's the I/O schemas so far:
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
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
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!
PS/2 keybaord interface
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
- 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
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
- 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?
Friday, 3 July 2009
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"!
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
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....