• Please review our updated Terms and Rules here

AIM-65 ACIA project

Hugo Holden

Veteran Member
Joined
Dec 23, 2015
Messages
4,806
Location
Australia
A while back I had a lot of success replicating the RM-65 video card. It has an adapter card made by Rockwell, to make it plug onto the AIM-65. One reason it worked so well is that it contains firmware designed by Rockwell , specifically for use with the AIM-65.

( I struggle more with third party computer add-ons, various incompatibilities, conflicts etc, because the third party designers didn't seem to know quite as much as the original designers about some thing or other).

I figured, well if Rockwell designed the add-on for the AIM-65, likely it will work and will be compatible.

Then I got to wondering about how to configure a good serial link to a terminal from the AIM-65, as another method of seeing the AIM's display on a VDU. Or sending data to the terminal from the AIM, or programs from the computer terminal to the AIM.

I have the AH5050 disk management system (designed by the third party ABM), that has a "serial link" of sorts on it, the AIM-65 is supposed to calculate the Baud rate. But so far I have not managed a successful link or found an easy way to use it.

I also wondered; if the adapter card I made for the RM-65 video card worked on the AIM, what other RM 65 family cards might work well on the AIM-65 ?

I came across this RM-65 family ACIA card & manual. (see photo). Rockwell, in the manual, have provided two programs to run it with the AIM-65 and mentioned to use the adapter card too. That is a good sign.

One program is an AIM-65 CRT Display Driver, the other is a Data Printer, which looks like it might take data from the terminal to the AIM printer.

( The ACIA card appears very well made to me, and has a comprehensive manual.I think its a two sided card, unlike the very complicated 4 layer video card).

It looks like I might have to make the programs in the AIM-65's editor & assembler, but I guess I could just enter the program bytes.

I wonder, has anyone else used this ACIA card with the AIM-65 computer and has any tips on it ?
 

Attachments

  • AIMACIA1.jpg
    AIMACIA1.jpg
    239.4 KB · Views: 9
  • AIMACIA2.jpg
    AIMACIA2.jpg
    237 KB · Views: 9
You can use an online assembler (try asm80.com). Despite the name, the assembler can be used for the 6502 - by selecting the appropriate CPU filename extension.

You can then download the resulting hex or binary file.

Documentation is a little sparse, but (if you want to give it a go) I can help out. I use it quite regularly. It has a simulator also.

Dave
 
I have managed as an initial experiment to get the AIM to communicate on a serial link to a modern computer running TeraTerm. ( I have not tried the ACIA board yet)

The AIM is in TTY mode.

The ABM board has an IC on it so that generates a + to -5V signal more suited to match RS-232. So I am trying that to get a serial link first, which I got running, setting the terminal for 7 bits, one stop bit and no parity. The thing is the AIM calculates the baud rate and puts bytes into two memory locations. Even though it works, the bytes stored there don't match the manual values, but if I put the manual values into those locations, it still works.

But one interesting thing, when the Terminal (my modern computer running TeraTerm) takes over the AIM-65 keyboard (in TTY mode) I cannot find a key that will act as a delete or rubout key. So that if I make a mistake typing something on the terminal keyboard controlling the AIM, I cannot undo it, unlike the delete key on the actual AIM-65 keyboard.
 
Last edited:
..to clarify, the DEL key on the AIM keyboard (when the AIM keyboard is in control) results in a backspace and a delete of what was there.

When the Terminal and its keyboard is in control, via the RS-232 hookup, neither the DEL key, or the Backspace, key does this. There must be something different about the ASCII codes.
 
Also, apart from the unable to delete anything using the Terminal, I'm trying to figure out why the stored bytes (that relate to the AIM's Baud rate calculation) in the AIM memory do not match what is in the AIM user's guide.

I have found trying to establish the serial link, that it works only to 1200 Baud and below, any faster it gives errors, not sure why, the manual suggested 9600 is ok. I tried putting delays in, didn't help. I tried entering the byte values for the higher baud rates too, but what happens is, when the link is initially established, those values get changed by the baud rate calculation, so that was of little use. Perhaps the signals are marginal being only + and - 5V peak.

In any case, how this link works is that the AIM is put into the TTY mode with its switch, and the CPU manually reset with the reset button. After that you press DEL on the terminal (it appears to transmit the same code as the RUBOUT key) and the link is established and Rockwell AIM-65 and the cursor comes up on the terminal.

According to the manual page 9-31 with the 1200 Baud setting, the bytes at addresses $A417 (called CNTH30) and $A418 (called CNTL30) are 02 and FD respectively and they suggest you can enter these manually.

However, if I look at those memory locations after the link is established and working, the values there are 03 and 1A, not the 02 and FD the manual says. Not only that, the bytes 03 and 1A do not match any of the Baud rates listed in the manual.

If I use the memory modify command to change either of those bytes, the serial link immediately crashes (not unexpected).

However, if I write a short program ( see attached ), to change those bytes to 02 and FD to match the manual's suggestion, the serial link remains working on 1200 Baud.

So it appears that the byte values suggested in the manual of 02 and FD are correct for a 1200 Baud link, but the bytes that appear there as a result of the AIM-65's Baud rate calculation; of 03 and 1A also somehow work. Changing either of these bytes to any other values crashes the serial link.

Any ideas why the stored bytes don't match the user manual values, but still work ?

For the successful linkups I could get for 1200 Baud & below, I recorded the bytes, which show what the manual said they should be and what was actually there after the AIM calculated it and establised the link.
 

Attachments

  • AIMSERIAL.jpg
    AIMSERIAL.jpg
    205.9 KB · Views: 5
  • baud.jpg
    baud.jpg
    84.5 KB · Views: 5
Last edited:
I have also attached a diagram showing the Hardware connection to the AIM-65 for the serial link. To make it work and receive RS-232 signals it is required that R24 on the AIM board is changed from 1k to 3.3k.

On the issue of the character deletion problem using the Terminal, it says in the AIM manual that; "When used on a TTY, the slash character is printed with the DEL key (this is correct) to "indicate" a character deletion. But I don't see this is helpful, because the character is not actually deleted, all you get is a slash character added.
 

Attachments

  • SERhardware.jpg
    SERhardware.jpg
    209.9 KB · Views: 9
Last edited:
Hugo,

Are you sure they are added to the buffer, and not just added to the display?

Dave
Yes, I checked. The slash appears on both the the AIM display and the terminal. I have attached an example. It must be more than the buffer, because the code is interpreted as errors with the slash there.

Lets say you are typing in a program and enter a value by mistake , say a $ character, (see attached) If you try to delete the character (just as you would using the AIM keyboard. which would erase it and go back to where you were), instead when the terminal is in control, the DEL key causes the slash to be entered and you cannot fix it, or even erase the slash, for that matter.

The slash comes up on both the Terminal VDU and the AIM's own display, see attached image.

Also I have confirmed this is the case, that the operands are not interpreted correctly if the slash is present (in other words the slash is not ignored) in the character chain, so it doesn't just "signify" that a character has been deleted in the display, the slash is an actual character placed in the character chain with the operands. It gets reported as an error in the line of code with the slash in it.

Sure you can redo that line of code, but it would be better if you can delete the bad entry of any character when you are typing from the Terminal, exactly like you can with the DEL key on the AIM keyboard, when it is in control.

So it is pretty inconvenient trying to type in a program on the Terminal keyboard, if you make an error and have no proper DEL function, like you do with the native AIM keyboard. Also In this mode, the Backspace key works like the DEL, generating a slash.

One interesting thing is, if I go into BASIC on the AIM, and using the Terminal, the DEL key is of no help, but the Backspace key will go back over a character in this case, and then you can overwrite the character, which is a handy way to fix an error. But this does not work outside BASIC, writing the opcodes and operands in the AIM 65 direct programming mode, the Backspace simply gives another slash, like the DEL key does, though in Tera-Term you can select what the DEL & Backspace keys do. But that still doesn't solve the problem.
 

Attachments

  • delprob.jpg
    delprob.jpg
    299.5 KB · Views: 6
Just thinking aloud...

What firmware have you got fitted? I'll take a look at the monitor source code. Always the best way of finding out why something (doesn't) work...

Just out for a morning walk (since the weather is so nice today - better than the torrential rain yesterday) - so I will have a think as I walk...

Dave
 
Just thinking aloud...

What firmware have you got fitted? I'll take a look at the monitor source code. Always the best way of finding out why something (doesn't) work...

Dave
I just went back to double check it, now I am finding that the slash is not fouling up the operands. I think you are right, the slash is in the display and not the buffer ! thank you for that !

Also I checked in BASIC (see attached) the Slash is ignored as evidenced by the listing, after a couple of bad characters were deleted. I'm not sure how I got this wrong in the first place. The old PBKC problem (problem between keyboard and chair)
 

Attachments

  • Basic2.jpg
    Basic2.jpg
    74.9 KB · Views: 3
Last edited:
No problem Hugo.

I fixed your problem and I didn't even have to do anything!

Some of my colleagues used to recon that they could put a cardboard cutout of me behind them and I could still fix their bugs...

I didn't know what they were doing sometimes. I know nothing of Perl scripting for example. But asking them to talk me through their code would usually help them find their own bugs because they were using different parts of their brain - talking and hearing rather than just seeing.

I somehow remembered that from somewhere. Thank you little old neuron for firing at the correct time! Appropriate really, I am just writing some neural network code in Lisp.

Dave
 
No problem Hugo.

I fixed your problem and I didn't even have to do anything!


Dave
My brain is definitely better for hardware problems ! A friend recently called me a "Magician" for fixing some hardware. You are definitely a Magician with software/firmware and could bend a spoon with code (eat your heart out David Copperfield).
 
Exciting times on the Rockwell ACIA project.

I had no idea when I got this ACIA board how useful it would be with the AIM-65 and thank the Lord, it came with the manual.

About the only thing I don't like about the AIM-65 is the single line LED display (Actually it is physically beautiful I think) but just difficult compared to a multi-line CRT display, when it comes to using the Editor especially.

So I yearned for a multi line display. This is why I went to the end of the Earth to replicate the unobtainium RM-65 video card, to feed a composite VDU.

I had no idea that there was a different way to do it.

But I'm not talking here about the existing serial link that can be used between the AIM-65 and a Terminal. In this case the system is such that the Terminal keyboard takes over the AIM keyboard, essentially controls the AIM like a remote computer, and this system, at least with the serial interface I have, won't run over 1200 Baud and the AIM must be in the TTY mode and reset to create the serial link and calculate the Baud rate.

The Rockwell ACIA card though, is a completely different cup of tea, combined with the software Rockwell wrote specifically for the AIM-65, simply keeps the AIM running normally and it turns the Terminal into a Display unit and that is all. There are no other interactions between the AIM and the terminal and essentially, it creates a display that is the digital equivalent of the composite video card.

The ACIA card has a proper DC/DC converter that generates +/-12V for the serial link and it has no trouble at all with the 9600 Baud rate either. One byte in the program sets the Baud rate.

The photo shows some typing on the AIM, looking at memory, turning off the printer, entering an running a tiny program etc.

The software (Terminal Display program) Rockwell designed also uses the linked F1 and F2 function keys, so you can select if you want both the AIM display and the terminal display running, or just the AIM display as usual.

What a great accessory for the AIM-65 computer.

Obviously this beautiful ACIA board would be equally worthy of replicating, like I did with the RM-65 video card, but since I have this one, I will leave it to others this time.

I have attached Rockwell's display program bytes in case anyone has the ACIA card and an AIM-65 and no manual and wants to try it out.
 

Attachments

  • RM1.jpg
    RM1.jpg
    298.6 KB · Views: 11
  • RM2.jpg
    RM2.jpg
    146.9 KB · Views: 11
  • RM3.jpg
    RM3.jpg
    241.1 KB · Views: 10
Last edited:
Back
Top