Maybe that was just me then? I was originally trying to get LM1488/89 and they were hard to find. Once I realised that MC1488 was more common it did get a lot easier.
Maybe that was just me then? I was originally trying to get LM1488/89 and they were hard to find. Once I realised that MC1488 was more common it did get a lot easier.
Look for the 14C88 and 14C89. Both are upgrades to the original parts.
So I've been waiting for things to arrive. In the current circumstances this has been very frustrating with things taking much longer that I thought. I've got most of the parts apart from the bypass caps, two diodes, DB-9 connector and the power connector. The one that I was most worried about was the crystal. It appears to be really hard to get a 1 MHz crystal now. Of course anyone today would be better off with an oscillator, and probably a faster one that 1 MHz, but this is what the TIM-1 suggested schematic had, so I went with it. I also wanted a large one like was used at the time, and designed the PCB with a HC49/U footprint. In the end all I could find was a HC51 crystal (which was also quite expensive). It's just arrived and it is huge, luckily it just fits in the space, but only just.
Huge Crystal
So back to waiting for parts now. Then see if it goes or blows.
However, the old 2114 RAMs present a timing complication, because it's quite possible to have a glitch on the /CE line while the address lines are changing and /WE is asserted. You therefore want to have a Phi2-qualified /WE signal to the RAM (but not to the 6530), to prevent writes to other locations potentially corrupting RAM. This requires another pair of 2-NAND gates (or one 2-NAND and an inverter). It's up to you whether you want to use one '00 and one '04 (using only half the available gates on each), or two '00s (leaving two gates spare).
I may have gotten this wrong too.
Looking at the timing diagrams to confirm, I want WE to only be low when PHI2 is high, which means I want !(R/W) NAND PHI2.
What I have built is !(PHI2 NAND R/W), which in english means WE is low when either PHI2 or R/W is low, so basically in the wrong clock phase.
I am a little stuck now. The good news is that everything I have investigated appears to be working, but still no serial output. I only have 8 channels on my logic probe so I can't look at the entire address bus and data bus at the same time, so there is a bit of guesswork involved. Also I don't have a single step circuit which would be helpful. But the CPU appears to respond to serial input, which is a good sign. The advantage of the 6530 TIM chip is that it does almost everything, but the problem with that is it's harder to look inside.
It looks like the CPU is running, and reading the ROM as I can match up the reads and writes to the listing, right up until BRK is executed which should use the interrupt vector to jump to the start of the monitor. I can see 8 writes where it's copying the vectors into RAM in a small loop, and then three quick writes where it is zeroing some variables using 3 STX's in a row. Then it should output a CR, after saving all the registers. But it doesn't get that far.
I had convinced myself that I had the serial lines inverted from what the ROM was expecting, but when I changed them over it seems to be worse rather than better, so maybe that was a mistake.
I feel like I'm very close to having it working, but not there yet, and the hours are mounting up. And the blue wires too actually.
Hmm, well, actually you either need to capture a clock as well (so that's 9 channels needed) or you need some way to use the clock to cause your logic gadget to sample the databus once per clock.
Yes, an 8 channel logic analyser is quite limiting. Just checked the price for Salae Logic 16 and I don't think I'll be getting that ($999), but there are some good lower cost options. I'm considering just capturing the clock and 7 bits and reconstructing from there, but that would be painfully slow. Having R/W is a big help in seeing where you are up to as there are relatively few writes so they tend to be identifiable.
Hoglets decoder is a very clever and useful project, it would be very helpful.
I am getting some very small low glitches on the RAM CS which I think are just 0's on the address bus on internal cycles or even just glitches during setup times, there's no clock qualification on the RAM CS, but there is on the WE signal, so I don't think this is a problem.
There is a lot I can test and verify, so I feel very close, but you just can't tell. The ROM sets PB4 low in the second instruction after reset, and I see that happening, so that gives me faith that the ROM and IO decode are working. Most likely I've made a mistake in the address decoding as that is quite complex. Maybe I'll try monitoring the RS, CS1, and CS2 signals of the 6530 and see if that reveals anything.
At one stage I was thinking this is a very humbling experience. I'd discovered about three simple mistakes in a row then. But now I can report...
It works!
As I almost could have guaranteed it was a simple error. At one stage I removed 2 of the 4 RAM chips on the assumption that the simpler it was the better, and I wanted to swap RAM around just in case I had a faulty chip. So I removed the two rightmost chips, possibly assuming that they were in the same order as on the schematic. It turns out I needed sockets 1 and 3 to be filled, and as soon as I did that, away it went. this is of course after fixing the other errors.
It's not too bad for errors really, this is what I found:
1. The 74LS138 inputs were connected in reverse order.
2. One connection was missed because it touched on the schematic but wasn't actually connected, so the DRC check didn't pick that up.
3. Got the write qualification logic wrong for the RAMs.
4. I have a break in the 5v connections somehow, I don't know what this is, and feel like it developed after initial connection, but it probably was there all the time and is another hazard of KiCAD, you can have islands of connections that are not all connected together and it doesn't raise an error.
I have enjoyed using KiCAD in general though, and it has been helpful in the debugging phase to trace PCB signal paths.
The board appears to be very slow, but then I remembered it is running at 300 baud.
I have a USB to parallel cable that I intend to try and get working as a fast download system. My DB25 connector still hasn't arrived so that will probably wait for a bit. And one other plan was to build an (E)EPROM programmer expansion board to actually make this useful. But just today I receive two brand new R65F11 chips in the post, so that could be the start of a new project.
