• Please review our updated Terms and Rules here

CDOS and TU-ART serial board drivers

E

Endersending

Experienced Member
Joined
Mar 14, 2023
Messages
119
Location
Walker, Minnesota
I have a Cromemco 4FDC controller, ZPU, and I am trying to figure out how to get Kermit working with the TU-ART board. I followed the instructions here and Kermit is running on CDOS 2.58 but trying to SET PORT in Kermit says that it is not implemented.
I have read a little about drivers but between the TUART manual and CDOS manual I see nothing about the TUART needing drivers or how to set it up with CDOS.
Do I need to build drivers as per the CDOS manual?
I have the TUART card plugged in and the serial addresses set to 20H and 80H so to not interfere with anything else on the system. I don't think CDOS knows the card is there.
Thanks for any help in advance.
 
Kermit communicates directly with the hardware so there are no drivers save for the code inside of Kermit. They apparently didn't implement SET PORT for the TU-ART overlay. I don't see the source for that overlay in the package. You might try a different communication package that has source code available for the overlays, like MEX or IMP. Then you could customize it for your base ports.
 
Endersending said:
I have a Cromemco 4FDC controller, ZPU, and I am trying to figure out how to get Kermit working with the TU-ART board. I followed the instructions here and Kermit is running on CDOS 2.58 but trying to SET PORT in Kermit says that it is not implemented.
I have read a little about drivers but between the TUART manual and CDOS manual I see nothing about the TUART needing drivers or how to set it up with CDOS.
Do I need to build drivers as per the CDOS manual?
I have the TUART card plugged in and the serial addresses set to 20H and 80H so to not interfere with anything else on the system. I don't think CDOS knows the card is there.
Thanks for any help in advance.
Click to expand...
Source files for Kermit-80 v4.11 are not easy to find - I found them using the Wayback Machine at the URL http://www.columbia.edu/kermit/ftp/archives/cpm80.zip
The TUART port settings for Kermit-80 are stated in the source file CPXSYS.ASM, and indicate the base port address is indeed 20h. I believe the SET SPEED command has been implemented.
You should be be able to test whether your TUART works by initializing it, and looking at what happens when you send/receive single bytes to and from it, using RDOS.
 
Reading the TUART manual it says that if I am running CDOS it will initialize the card for me. I have a rs232 line adapter with LEDS that show the status for the lines. RD is green apon boot and turns red as CDOS loads. It might not mean much but seems like CDOS is doing something to the card.
On an oscilloscope the TX line is held at -5 volts, and RX is floating at 0 volts.
I tried using RDOS with the command E 20, and the result is FF. its the same for 20H-2FH and 80H-8FH, other ports shows good results (not FF).
I found some assembly code I am going to try to write a program that will look at ports and registers and see if I can see the card or do some bit banging with it.
Unless someone knows how I can access the serial ports through BASIC.
Which reminds of of another question: How does CDOS handle ports? I see mention of PTR, CON, TTY, PUN. How are these set?
I still almost feel like I have to use the drivers.z80 and CDOSGEN.
I will keep messing with the card and some programming to see if I can get something to work.
 
Last edited:
Endersending said:
Reading the TUART manual it says that if I am running CDOS it will initialize the card for me. I have a rs232 line adapter with LEDS that show the status for the lines. RD is green apon boot and turns red as CDOS loads. It might not mean much but seems like CDOS is doing something to the card.
On an oscilloscope the TX line is held at -5 volts, and RX is floating at 0 volts.
I tried using RDOS with the command E 20, and the result is FF. its the same for 20H-2FH and 80H-8FH, other ports shows good results (not FF).
I found some assembly code I am going to try to write a program that will look at ports and registers and see if I can see the card or do some bit banging with it.
Unless someone knows how I can access the serial ports through BASIC.
Which reminds of of another question: How does CDOS handle ports? I see mention of PTR, CON, TTY, PUN. How are these set?
I still almost feel like I have to use the drivers.z80 and CDOSGEN.
I will keep messing with the card and some programming to see if I can get something to work.
Click to expand...
Yes, CDOS does initialize the TUART during system boot.
However, as Amardeep said above Kermit communicates directly with the TUART serial port and bypasses CDOS.

What version of BASIC for CDOS are you running. The Cromemco 16K extended BASIC manual provides a lot of help in answering your questions:
- it provides a listing of the standard I/O device port addresses
- it describes use of the INP and OUT commands you can use to send a data byte to a specific I/O port address
 
I have a few updates. The TU-ART card seems to work. I have been able to hook a terminal to it and write some text. I have found that if the tuart is serial 1 (lets say). when I connect it, the serial port on the 4FDC card seems to have problems. Minicom will start going online/offline repeatedly. This makes me think that something isn't set up right. I think it is an interrupt problem which leads to my question: On these Cromemco boards they have a 2 pin jumper for interrupt priority. the 4FDC, TU-art and a PRI board I have all has them. Should I be hooking these up? I would assume I would go 4FDC(IN)Not connected - > 4FDC(out) -> TU-ART(IN) -> TUART(out) -> PRI(IN)->pri(out) Not connected.
Could these priority pin wires missing be a problem?
THe turart board had a bodge wire on the priority pin that I removed and replaced with pins for a connector. Doing this I noticed that a trace had been damaged and now I have to fix that trace since the tu-art board freezes the machine since the trace is broke.
once I fix the trace I am going to hook up the priority wires and see if that makes a difference
 
The priority chain is definitely needed for Cromix but doubtful for CDOS. However, you should fix the trace and connect them appropriately. One of the boards...I don't remember which...had the pin ordering reversed compared to all the others. So check the manuals/markings and don't guess on that.
 
I think the TUART is working. I can hook a terminal up, use kermit and connect to linux getty, but after logging all the text displays in one character at the bottom of the screen like no control characters are working. I think this is a software problem. I found a modem program I am going to try to compile and see if that works better.

Another piece to the puzzle is the PRI printer board. When I plug it in, the system doesn't respond. I can't examine memory or deposit from the panel. Its like a bad chip is freezing up the data or address bus some nothing can move. I have been looking for a schematic for that board but all I have found is the user manual.
I will post more info as I get more stuff working
 
Do you have the earlier PRI (about half the board area populated and no priority pins) or the later one (most of board covered with parts and has the priority chain connector)?
 
Endersending said:
I think the TUART is working. I can hook a terminal up, use kermit and connect to linux getty, but after logging all the text displays in one character at the bottom of the screen like no control characters are working. I think this is a software problem. I found a modem program I am going to try to compile and see if that works better.

Another piece to the puzzle is the PRI printer board. When I plug it in, the system doesn't respond. I can't examine memory or deposit from the panel. Its like a bad chip is freezing up the data or address bus some nothing can move. I have been looking for a schematic for that board but all I have found is the user manual.
I will post more info as I get more stuff working
Click to expand...
It sounds like Kermit is expecting to work with a specific type of terminal and its screen control codes - possibly the Cromemco 3102 ?

Which version of the PRI board are you using - the first version which had only half the board populated with ICs or the second version with the entire board populated with ICs?
 
I have tried kermit SET TERMINAL tv52, regular, dumb - nothing seems to make a difference. I will look into the emulation and maybe I can get linux to mimic a 3102.

Most of the board is populated so I am going to assume the later version with the priority pin. The board looks to be in perfect shape - looks brand new almost
PRI_scaled.jpg
 

Attachments

  • 2024-01-10_151909.jpg
    2024-01-10_151909.jpg
    1.8 MB · Views: 2
But beware, there are limitations...

Devices are only tested statically - meaning that they can pass the testing and fail in use.

Equally, they can fail the testing (some logic testers do not cover all use cases adequately) but still actually work.

Dave
 
Endersending said:
I found IC8, 74LS33 that was bad. I have it on order. I will let you know what happens after I test it
Click to expand...
According to the "Theory of Operation" section of the PRI board's manual, one section of IC8 (four NOR gates with open collector outputs) drives the S100 interrupt signal line 73. While you are waiting for a new IC, you could just lift the IC8 pin that drives S100 bus signal 73. With the S100 INT* signal not being pulled low presumably by the defective 74LS33 you should at least be able to plug the PRI board into the bus and the system should run - though you may not be able to make the PRI board itself run properly.
 
The chip was not bad. The tl866 tester said it failed, but so did the other 2 chips I ordered.
I tried a brute force method and removed all ICs from sockets on the PRI board. still locks up the front panel.
Which makes me think. Even after pulling all the chips it still makes the front panel unresponsive(I can stop,reset and start - that's it)
Does this board not support using a front panel? I would assume with no chips the board is essential not hooked to anything. Just power.
I have no idea where to go from here. I feel like the board is ok but can't work with the front panel.
Any other suggestions or advice would be great
 
Endersending said:
The chip was not bad. The tl866 tester said it failed, but so did the other 2 chips I ordered.
I tried a brute force method and removed all ICs from sockets on the PRI board. still locks up the front panel.
Which makes me think. Even after pulling all the chips it still makes the front panel unresponsive(I can stop,reset and start - that's it)
Does this board not support using a front panel? I would assume with no chips the board is essential not hooked to anything. Just power.
I have no idea where to go from here. I feel like the board is ok but can't work with the front panel.
Any other suggestions or advice would be great
Click to expand...
Many late-model S100 boards (including those made by Cromemco) are designed to ground S100 lines 20 and 70. When installed in an IMSAI, having these signals grounded will stop the front panel from working.
Start by checking whether one or both of pins 20 and 70 are grounded on the PRI board. If so what most people will do is wrap a piece of insulating tape over pins 20 and 70, made easier by the fact these two pins are opposite each other on the front and rear of the board.
 
Last edited:
IMG_20240117_013903119.jpg
I will check and post my findings.
EDIT: Attached is a picture of the active parts of my back plane which probably has nothing to do with it. When you said s-100 boards I was thinking the back plane, but now I believe you are saying [Expansion] boards like the PRI, TUART, etc..
In other news I have learned some things about goofy .doc formatting that looks awesome when printed with Wordstar.
I have learned that not all assemblers work for everything and like most s-100 / CP/M stuff there is no standard.
I am trying to find a serial terminal like kermit or imp or mex to do file transfers.
I spent a day just trying to get UNARC patched and working with CDOS, and now I can unarchive CPMUG ARK files!!
Huge learning curve to these computers
 
Last edited:
>>> The chip was not bad. The tl866 tester said it failed, but so did the other 2 chips I ordered.

A perfect demonstration of my statement in post #14...

I was also posting about S-100 pins 20 and 70 only last week (I think) on a completely unrelated thread to this one... Also a non operarational front panel... However, it turned out not to be this in the end - but it was still a point to check nonetheless.

Dave
 
You must log in or register to reply here.
Back
Top