I think I've got my TIM-1 board mostly going now, but I'm having a bit of trouble with the serial ports.

As far as I can tell the extent of the documentation in the TIM-1 manual is that the serial port works up to 300 bps, and the schematic which shows the pins used and what appears to be a non-standard inverted signal level at the 6530.

I've got a small logic analyser and using that everything around the CPU looks good. There's a nice 1MHz clock and now the address decoding is also working as it should. I found one problem there which was caused by an error in the schematic. Two wires in the schematic were touching but not connected. This translated to two of the enable pins in the 74LS138 being connected to each other but not to ground, and no netlist error. A little blue wire fixed that, and I couldn't see any other cases of similar mistakes.

I could probably do with a ROM listing to see what is going on. On the one hand the benefit of this project is that I don't need to program a ROM, but the disadvantage of that is that I'm not entirely sure what is going on.

The manual says it'll detect any baud rate up to 300 bps. Luckily my computer will do 300 bps, but no slower. I'm using a serial to USB adapter which does seem to be quite temperamental. I've been using the logic analyser to confirm that it is working. The TIM manual makes no mention of parity or stop bits, so that is one area to investigate. I'm not sure what was normal back then, but I assume 1 stop bit and no parity.

My serial hardware is exactly the same as the EIA portion of the TIM-1 manual and appears to be working correctly.

When I send a character to the 6530 the transmit pin pulses down for 0.125us. This pulse is normally at the end of the second bit of the character being sent. This leads me to believe that the software is detecting the incoming character and rejecting it, but it's not transmitting anything for some reason. So starting to run out of ideas. I've just changed some of the chips over just in case, but that hasn't made any difference. The TIM-1 schematic has two MC/LM1489 stages on the input, which is a double inversion, but the signal on the wire is sent inverted by convention, so normally one inversion is all that is needed. This appears to be non-standard, but is according to the schematic. At present I don't think this is the problem.

The manual says to send a carriage return and this will be used to determine the baud rate. At first I was hitting enter, which was sending a newline, now I'm sending a control-M which should be the correct carriage return character (0A).

Does anyone have any experience with 1970's serial terminal conventions or even the TIM-1 (or a listing of the ROM, I can't seem to find that)?

From the receiver's point of view, the length of the "stop" signal is irrelevant; you can safely set it to 1.5 or 2 bits, even if the receiver expects only one. The more critical factor will be the byte length (5, 7, 8 bits were used at various times in the past) and the parity. You can rule out 5 bits because that was only used with Baudot-code teletypes; terminals for computers always used either EBCDIC or ASCII, usually the latter.

I think it's worth trying 7N2, 7E2, 7O2, 8N1, 8E1, 8O1 settings, N is no parity, E is even parity, O is odd parity. Using two stop bits with 8 data bits was never common, but 7-bit ASCII with parity was at least moderately common.

If it’s this TIM then the software seems to expect 8N1. The write routine sends 8 bits without a parity bit. The recieve routine reads 8 bits and masks off the parity.

http://retro.hansotten.nl/uploads/6502docs/timman.html

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

More 6530-004 info (including listing) is available at http://retro.hansotten.nl/6502-sbc/tim-6530-004/.

Looking at the listing:
Just after reset, it measures the length of the 1st start bit & 1st data bit it sees - assuming idle is 0, the start bit is 1, the LSB data bit is 0, the next data bit is 1.
It'll need a carriage return (hex 0d) from the terminal, not a line feed (hex 0a). Control M should do it.

The bit pulses on a serial line at 300bps should be 1/300 sec wide.
You should see these from your USB to serial adapter transmitter & the 6530-004 transmitter.
0.125us seems much too short.

You can read serial data with your scope.
Time per bit is 1/baud_rate; 300 baud is 1/300 sec = 3.33 ms.
8n1 format bits for each character are:
- start bit
- data LSB
- data next bit
- data next bit
- data next bit
- data next bit
- data next bit
- data next bit
- data MSB
- stop bit

Good to know that it is expecting N81, which is what I am sending. I have been testing with sending control-m too, that was a bit of a mistake saying I sent $0a (I was at first), I am sending a control-m, $0d and see that on the logic analyser. Pulses are 3.331 ms wide which appears correct. So I think that confirms that the serial message is correct.

Which leads me to believe that the serial port is not the problem. The source code link above should be a big help, thanks for all the help, there really is a lot of knowledgable people here.

Using a 6504 has probably made this a lot harder, and with reduced functionality too. Too late now though, hopefully I'm almost there. My current thinking is that the address decode is working as designed, but maybe I had a wrong assumption in the design. I've spent quite a bit of time checking it but haven't found anything wrong yet.

I've had a look at the address and data bus's with the logic analyser, it's definitely not correct but I haven't been able to make sense of it yet. I've only got 8 channels so I can't see much at a time, and if you add something helpful for context like the clock or R/W then you don't even have a full byte to look at. Looking at the ROM, the code should get to a loop waiting on input and wait there until it receives a byte, it looks like it is stopping in a loop, but I can't make any sense of the data on the bus. I'll just have to keep investigating until something comes up.