• Please review our updated Terms and Rules here

AST Mini I/O II for PC and XT

Mike_Z

Veteran Member
Joined
Dec 1, 2013
Messages
1,713
Location
Near Milwaukee Wisconsin
I started to talk about this in a different thread and thought that it would be better to start a new one. I have an original IBM XT 640K machine. Recently I retired the Hard Drive for an XTIDE with a CF card. After some struggle, it seems to be working quite well. Since I have the XT open I thought that I'd attempt to repair the AST Mini I/O II I had in the machine. Long ago, it failed during a lightning storm. I would like to get the AST working again, mainly because of the clock.

First thing, I need an ISA extender board. To raise up the AST card so that I can check it out. I have been looking around on the web, but the only place I found one of these is in England. I was wondering whether or not I can find one here in the States. Any suggestions? Thanks, Mike
 
Holy Cow! You are not kidding they are expensive. I found one on eBay from England for $40. Ordered it.
I've been digging into this card and have found some items that may help, Mike
 
I thought that maybe the astclock.com file was corrupt. Recopied the file from my source, didn't work. Then downloaded a file from -0degrees, that didn't work either. I mean the computer didn't change it's behavior. So the problem must be on the AST Card. I thought of trying to decompile the astclock.com file to see how it works. I downloaded program called REKO, but could not make it work. Is there a good program to do this? Thanks, Mike
 
Bringing this over from the other thread:

The real-time clock (RTC) circuitry may be completely separate from all other functionality on the card.
From the document at [here], and from the Ricoh RP5C15 data sheet, the RTC components are:

U1: Ricoh RP5C15 chip
B1: Battery
Y1: 32.768 kHz crystal
C23: Adjustable capacitor
C??: Capacitor connected to pin 17 of the RP5C15.
E13: Jumper ("Attach for clock/calendar")

There will be some address decoding circuitry as well, to activate the /CS pin on the RP5C15 chip.
 
I thought of trying to decompile the astclock.com file to see how it works.
FYI. At [here] is an AST document that indicates that at version 4.3 of the SuperPak suite, ASTCLOCK.COM was modified to include support for the Ricoh RP5C15, and that ASTCLOCK.COM can tell the difference between the MM58167 and RP5C15 by way of the D address behaviour.
 
The past few hours, I've been proving COM1 and LPT1. My HERC card has LPT1 and it works. I configured an Everex EV-170 for LPT2 and that worked. The AST card as LPT2 failed. The printer would not even initialize on start up. Then I configured the Everex for COM1. Then using Kermit and a null plug I could type and see my typing on screen. Kermit could not even find the AST card. So, there are more problems than just the clock on the AST card. Wondering whether or not it is worth pursuing. Mike
 
The past few hours, I've been proving COM1 and LPT1. My HERC card has LPT1 and it works. I configured an Everex EV-170 for LPT2 and that worked. The AST card as LPT2 failed. The printer would not even initialize on start up. Then I configured the Everex for COM1. Then using Kermit and a null plug I could type and see my typing on screen. Kermit could not even find the AST card.
In case of interest to you, the vintage tools (DOS based) of SERTEST.EXE and PARTEST.EXE are at [here] and [here].
 
Thanks for the references. Can you tell me a little about what they do? Thanks, Mike
Back 'in the day', for a time, I worked for an area that used lots of serial ports, and had lots of failures. On the PC side of things, diagnostics would not give me enough detail as to what was wrong with the port, and so I decided to write my own, SERTEST. For example, if the internal loopback test worked, but an external loopback test failed, we could easily work out which level converter chip/s to replace. Info on 'serial loopback' is at [here].

And because we had the odd failure of parallel ports as well, I wrote PARTEST. But that was more of a confidence thing - throw a loopback plug on and if the loopback test passed, we had very good confidence that the parallel port was configured as expected, and working.
 
Back
Top