PDA

View Full Version : Cromemco Z-2D revival - RDOS prompt info?



DoPECC Harry
June 16th, 2016, 10:19 PM
Hi,

Am in the process of reviving a Z-2D, at this stage have sorted out and reformed the power supply and have a ZPU, 64KZ RAM and 16FDC controller in the chassis.

It's set to boot into RDOS and it signs on but I think the serial comms are still not right. The RDOS signon looks mangled and I cannot get any response to input. I'm using a USB-serial dongle that has been pretty reliable in the past.

Before I go chasing signals (the Z-2 box is sturdy, but card access is not so good!), can anyone tell me what a good RDOS signon should look like?

I am getting:


Cromemco RDOS 02.52
;^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ @^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@


If I know exactly what I should expect, that will help to figure out why it's going bad.

Thanks in advance!

MicrocomputerSolutions
June 16th, 2016, 10:40 PM
I'd strongly suggest that you check the power supply outputs very carefully with a oscilloscope. I noticed back as early as 1990 that the power supplies used/built by Cromemco in Z Series mainframes were suffering from failed filter caps, which were allowing ac onto the dc bus blowing out caps and chips on the individual S-100 boards.

amouse
June 17th, 2016, 03:50 PM
I am hoping the answer is baud rate and parity issues. I know from the initial ASCII display of Cromemco RDOS what I am saying is slightly illogical [captain], but hey.

Is thhe output you described exactly repeatable? i.e. the full text always displayed?

Try a different PC emulator
Try different parity, stop bits, then baud rate

Randy McLaughlin
June 17th, 2016, 04:54 PM
The controller card is receiving a break signal (the equivalent of hex 00's which). Rdos is echoing what it is receiving Control-@. The fact it displays the normal logon prompt first tells you that you have correct baud rate.

The Console cable can be wrong, or the RS-232 receiver on the controller could be bad.

Cromemco needs a three wire cable, do not connect more wires just use pins 2,3, and 7 on the 25 pin connector, the RTS, CTS, DCD, etc. are not used and should not be connected.

Cromemco uses some of the other pins for current loop which will interfere with some terminal connections.

RDOS is a decent monitor, there should be online PDF's for it:

One simple command to test is d 00 ff, it should show the contents of ram locations 0000 through 00FF

The command b says boot from first floppy drive.

There are lots and lots of commands - to numerous to give them all.




Randy

Randy McLaughlin
June 17th, 2016, 08:02 PM
Some of my previous posts refer to the 4FDC an older disk controller, mainly the 16FDC accepts a 25 pin cable ignoring other input pins and tying all other output pins to true.

So a three wire cable can work but also a 25 wire cable should work.

The correct manual for your controller is:

http://www.classiccmp.org/dunfield/s100c/crom/16fdc.pdf


But the ^@'s still refer to RDOS seeing a break signal meaning it sees a stream of data to the computer.

DoPECC Harry
June 17th, 2016, 10:50 PM
Thanks all!

Regarding rate and serial stream format, I set the 16FDC to force 300 baud and eliminate that issue. I was also not sure how it could auto-baud if there was a problem with the input stream.

Serial format of 8-N-1 seems to work - can anyone confirm this? The 16FDC doc does not actually give any guidance, which I thought was an oversight.

For flow control, good ole' HyperTerminal is set to None and I have jumpers on the plugs at each end for RTS - CTS and DSR - DTR - CD.

So I think that the output to the terminal is all good - assuming that "Cromemco RDOS 02.52 <newline>" is the full prompt.

Randy - thanks for interpreting the ^@, and this may support my current theory:

I have looked at the 16FDC input circuit, because I am always in doubt about the actual levels and currents that an "RS-232" port wants.
The 16FDC uses a 74189 line receiver and the receiver's bias pin is biased towards +12v. The data sheet this suggests that this will result in the receiver having a mark/space threshold that in in the negative voltage range.

So, the USB dongle may not be driving the line low enough, instead the 16FDC sees a permanently high input - would this look like a string of 0x00?

Does anyone know the expected levels for serial input on the 16FDC?

In the meantime I may try cutting the bias pin input, the data sheet suggests that this will change the mark/space threshold to a +1-+2v, nicely in the TTL range.

Thoughts?

Thanks again!

Randy McLaughlin
June 17th, 2016, 11:43 PM
The 75189 (1489) is a very simple inverting level converter.

With a meter and a jumper you can put -9 to -12v on and input and should get ttl high (~5v) out, +9 to +12 should get gnd.

If so the USB should be at fault, if not bad driver chip.

You can use USB to ttl serial if you pull the drivers and jumper inputs to outputs.

The driver chips are notorious for going bad.


Randy

MikeS
June 21st, 2016, 07:24 AM
The 75189 (1489) is a very simple inverting level converter.

With a meter and a jumper you can put -9 to -12v on and input and should get ttl high (~5v) out, +9 to +12 should get gnd.

If so the USB should be at fault, if not bad driver chip.

You can use USB to ttl serial if you pull the drivers and jumper inputs to outputs.

The driver chips are notorious for going bad.


RandyIf it's a revision F or later the chokes L 1, 2 and 3 are even more notorious.

With switch 3 off and switch 5 on, you're definitely showing symptoms of pin 2 of the FDC connector either floating or being above the negative threshold (or a defective line receiver IC16).

I would break out the RXD line (pin 2 of a DB25 or pin 3 if it's a DE9) at the USB converter; put a 9V battery across RXD to ground with the positive to ground.

If it stops sending ^@s then it's probably an issue with the USB adapter; if it continues then it's presumably the cable or the FDC - check for continuity between RXD and pin 7 of IC16. If it's open and it's a revision F or later FDC then it's probably an open L1; if you get continuity then it's probably IC16.

mike

DoPECC Harry
June 23rd, 2016, 04:32 AM
Thanks all, I found a MAX232 lying around and I was going to set it up to give proper levels into the Cromemco but the other suggestions are worth doing first. Mike - a nice simple method - I like!

Will report back once I've run thru all of this.

H

Randy McLaughlin
June 23rd, 2016, 01:42 PM
With old gear I have had to make do, when I do I usually mount on perf-board and make it plug into original socket.

In this case the driver (1489 equivalent) is widely available and reliable.

The main reason they fail is either static charge from terminal or plugging/unplugging when on (creating static charge).

It's an "antique" in computer terms if it can be repaired to original it will be more valuable.

It's yours and can easily be modified without causing any harm with max-232 or even just jumper inputs to outputs and use TTL but for me I would just replace the receiver driver with an original chip.

The advantage of the max-232 is the 1488 (the other 1/2 of the rs-232) requires +/-12v and the max-232 doesn't making new designs easier plus the max-232 is a transceiver so only one chip is needed not two. In this case the +/-12 is already there.


Randy

MikeS
June 23rd, 2016, 05:42 PM
Oops! Brain fart, checked the schematic and had the wrong IC :rolleyes:

The line receiver is IC17 (not 16), so that last paragraph should read:

If it stops sending ^@s then it's probably an issue with the USB adapter; if it continues then it's presumably the cable or the FDC - check for continuity between RXD and pin 1 of IC17. If it's open and it's a revision F or later FDC then it's probably an open L1; if you get continuity then it's probably IC17.

Sorry 'bout that!

m

DoPECC Harry
June 25th, 2016, 06:01 AM
Progress (of a sort)....
I made up a MAX232 level converter, and apart from a brand-new tantalum cap preferred to be a low value resistor and start smoking, all good.

Here is a capture of the RDOS signon message. Blue is RS232 connector on the 16FDC, yellow is TTL between the MAX232 and the USB-serial dongle, numbered arrows are 0volt, scale is 5v/div
- RS232 level is idle negative, swings +/- 9v, 33.4msec seems to mark 10 bit times (start + 8 bits = stop) - this all looks good
- TTL follows RS232 properly and respects convention of RS232 negative is logical 1, so converts to TTL +5v - this looks OK
- and if you unpick the first frames then you get (hex) 0D 0A 0D 0A C r Thats the start of the signon!
31812

So WTF?? Why does Hyperterminal get: yy%5%9![waYCCCCCCCCCCCCCCCC..etc..

Well, if you invert the capture above, a start bit is found one bit time later and if you decode from that start bit, the first character is 0x79 - lower case 'y' Hmmmmmm....

So is the serial dongle is reading the data stream with logical inversion?? I cannot find a setting in the driver or in HyperT or puTTY to change this. Looks like I need a 7400.....


But what about input to RDOS, that has never worked so far.
Here is a capture: Yellow is between the USB dongle and the MAX (serial data in TTL form) and blue is directly on pin 5 of the 16FDCs UART chip. So this jumps over the conversion to RS232 levels and back again.

31813

This is the first ENT that arrives and if you decode the 10-bit group it comes out as 0x0D - that seems to be OK, so why no response???

But what if there is also an inversion problem on this side?? If so, then the start bit will be sensed later and the 10-bit group is:
31814
And this will never work because no stop bit will be found - so a frame error and no valid input will be seen.


This all suggests to me that the USB-serial dongle is inverting both input and output streams. I dunno why and it does not seem to be a setting that I can find.

So I guess I will add a 7400 to my level converter box and see how that goes.

DoPECC Harry
June 25th, 2016, 06:24 AM
OK, I was thinking of a 7404 but of course a 7400 will do the job too. (and fewer wasted gates....)

Randy McLaughlin
June 25th, 2016, 05:23 PM
Rule number one - If it aint broke don't fix it.

The transmitter was working perfectly - why change it?


Randy

MikeS
June 26th, 2016, 10:35 AM
Rule number one - If it aint broke don't fix it.

The transmitter was working perfectly - why change it?


Randy

Yeah, I think you're definitely chasing a few wild geese and making this much more complicated than it is... ;-)

A couple of minutes with an ohmmeter (and a 9V battery if necessary) should tell you all you need to know to get things sorted

m

Randy McLaughlin
June 26th, 2016, 10:59 AM
If you just ignore it and replace the 1489 and the tms5501 you would have spend $10 and problem is fixed. It is most likely the 1489 but since it was displaying the sign-on message that means most all the I/O is working and just the receiver side has a problem. A new 1489 should cost $1, and the TMS5501 sells for $7.50.

99.9999% that it is one or the other.



Randy

MikeS
June 26th, 2016, 11:59 AM
If you just ignore it and replace the 1489 and the tms5501 you would have spend $10 and problem is fixed. It is most likely the 1489 but since it was displaying the sign-on message that means most all the I/O is working and just the receiver side has a problem. A new 1489 should cost $1, and the TMS5501 sells for $7.50.

99.9999% that it is one or the other.

Randy... And if it's an open L1 on a rev F board it won't cost you anything; just short it out or put a 100 Ohm resistor across it.

m

DoPECC Harry
June 27th, 2016, 05:52 AM
OK, all fixed! RDOS talking and listening!!
Thanks to everyone who has helped keep my thinking on track.

Here is the summary:
1) Everything in the Cromemco was working OK, the problem was with levels and logic inversions between "proper" RS232 and "TTL level" RS232

2) Recall that strict RS232 has voltage levels of approx -11 and +11,
- minus 11 is idle level, and is "mark" or logic 1
- plus 11 is "space" or logic 0
- plus/minus 3v range is undefined

3) OTOH "TTL RS232" is typically
- plus 5 is logic 1
- zero is logic 0

So if I plug a USB - TTL RS232 dongle into a Cromemco strict RS232 port there is POTENTIAL PARTIAL compatibility:

- for data from the Cromemco to the dongle, +11v MAY be seen as near enough to +5 and -11 MAY be regarded as nearer to zero
- to support the above interpretations, the higher level may be defined as logic 0 and the lower level as logic 1
-------------> this allows incoming serial data to be interpreted correctly and this explains why I could see the RDOS signon OK

Now for data from the dongle to the Cromemco RS232 it breaks down (hence partial compatibility)
- +5 from the dongle is greater than +3, and so should be interpreted as a "space" or logic 0
- zero from the dongle will never be regarded as a mark or logic 1, as this must be less than -3
------------> so input to the Cromemco from the dongle will always fail, looking like a stuck line - this is what I found

Solution:
First Step - Make adapter box with MAX232 level shifter
This gave proper levels for input and output, as shown on scope traces above BUT input to Cromemco was not fixed AND output was now broken!!??

Second Step - Add inverter stage to the adaapter box
The scope traces also showed that the data was logically inverted.
Recall from above that the dongle inverts logically and then note that the MAX232 do so as well. This results in wrong final logical sense, and so input and output are both invalid, and broken. With the inverter stage, both are fixed.

(Alternative Solution
Modify the 16FDC input stage to remove the -11v bias. I prefer not to do this, and the interface box is useful for other similar situations)

Thanks again everyone, it's been helpful to have you looking over my shoulder while I figured this out.


Now:
Does anyone have a hardware manual, or indeed any data at all for a Konan Enhancer Tape Interface Card???
I have this idea that I'd like to get the Cromemco to drive an HP 7970 9-track tape drive that I have........................................

Best wishes to all

Randy McLaughlin
June 27th, 2016, 07:10 AM
Gratz on the 16FDC, Dave Dunfield has a online software library and a utility to transfer them via PC serial port to 16fdc RDOS monitor (fills RAM and writes it to disk via RDOS commands).

http://www.classiccmp.org/dunfield/img/index.htm


The tape drives uses an HP IB interface, the konan controller uses an IBM interface. I know of no conversion between the two.

But the HP IB interface is a simple smart interface that could easily be handled with a couple of parallel ports:

http://www.retrocomputing.net/parts/hp/7970E/docs/07970-90919_7970HPIB_Nov82.pdf

I would consider a micro controller as an external controller maybe using a serial port so it can easily be used by either S100 or PC.

If you really want it just for the S100 get a buffered proto board and most the S100 logic is already done.


Randy

MikeS
June 27th, 2016, 09:08 AM
It just finally dawned on me that you're trying to connect a USB-TTL adapter to an RS-232 port; should have realized it with all those inverted and wrong level signals.

Another alternative solution: spend a couple of bucks on a USB<>RS232 adapter instead.

But yes, congrats on doing it the hard way, and good luck!

m