RichCini
Veteran Member
Hey, Mike! I just downloaded the Pascal stuff and I'll post them hopefully sometime this weekend. I also have the AIM-65 DOS ROM in my shop (no hardware, though). I'll add the docs for it as well.
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Rockwell AIM 65 (R6500)
- Thread starter billdeg
- Start date
Hey, Mike! I just downloaded the Pascal stuff and I'll post them hopefully sometime this weekend. I also have the AIM-65 DOS ROM in my shop (no hardware, though). I'll add the docs for it as well.
orgwood
Member
Ok, I was able to get the 6502 "shim board" project breadboarded and working yesterday after working out a few kinks. Here are a couple of shots of it and the thermal paper readout!
As I stated before, this expands the AIM RAM to 32KBs and plugs into the 6502 socket with the CPU then plugged into it. I found you can leave the RAM on the AIM but there's always a risk there will be a conflict writing and reading from two locations even if they are addressed and timed appropriately. I pulled the RAM from the AIM to make sure it was really reading from the memory chip only! The upside down black chip is a 7400 that provides the timing for the SRAM R/W using 2 of its gates. I had a smaller version installed but it came from a suspect board and was defective so I replaced it with its big brother. The PC board version will use the smaller one. My next project is to test a prototype with the language ROMs, BASIC, FORTH, PL/65, and hopefully PASCAL installed on a single Flash ROM bank selectable by 4 jumpers and decoded to avoid the A000H I/O block. As stated elsewhere, when running PASCAL, the 4000H block must be available so I won't have the 32KB SRAM shim board installed but will only be using the 4K RAM on the AIM. I'll leave the disabling of the top half of it for the next project.
As I stated before, this expands the AIM RAM to 32KBs and plugs into the 6502 socket with the CPU then plugged into it. I found you can leave the RAM on the AIM but there's always a risk there will be a conflict writing and reading from two locations even if they are addressed and timed appropriately. I pulled the RAM from the AIM to make sure it was really reading from the memory chip only! The upside down black chip is a 7400 that provides the timing for the SRAM R/W using 2 of its gates. I had a smaller version installed but it came from a suspect board and was defective so I replaced it with its big brother. The PC board version will use the smaller one. My next project is to test a prototype with the language ROMs, BASIC, FORTH, PL/65, and hopefully PASCAL installed on a single Flash ROM bank selectable by 4 jumpers and decoded to avoid the A000H I/O block. As stated elsewhere, when running PASCAL, the 4000H block must be available so I won't have the 32KB SRAM shim board installed but will only be using the 4K RAM on the AIM. I'll leave the disabling of the top half of it for the next project.
jackrubin
Veteran Member
Nice!
orgwood pointed me to the thread.
Thoughts:
It seems like this shares a lot of similarities with the Universal 6502 RAM/ROM Expansion PCB, which Nicolas Welte asked me to produce last year. I was planning on cost reducing it and making it a bit smaller (premounted SMT components). I also like the config idea of the PETVet, in the other thread. In anticipation of producing some type of 6502 daughtercard, I order 1000 of the DIP40 IC headers one would use to make such a card.
I'd be happy to help.
Jim
Thoughts:
It seems like this shares a lot of similarities with the Universal 6502 RAM/ROM Expansion PCB, which Nicolas Welte asked me to produce last year. I was planning on cost reducing it and making it a bit smaller (premounted SMT components). I also like the config idea of the PETVet, in the other thread. In anticipation of producing some type of 6502 daughtercard, I order 1000 of the DIP40 IC headers one would use to make such a card.
I'd be happy to help.
Jim
orgwood
Member
Any help is most welcomed...I had seen the Universal 6502 RAM/ROM Expansion PCB while googling around. I was initially turned away because it uses a GAL that I have little experience with and because the footprint extends significantly beyond the 6502 socket. With the smaller chips available today, I was hoping to slip an adapter card beneath the existing CPU to achieve expansion while raising the height slightly...I know this muddies up assembly but by making the project into 2 boards, one for SRAM and one for Flash/EEROM using TSOP chips, the increase in height would be minimal and one could choose the memory map needed before installation into a specific machine. I could see this being used to expand several vintage 6502 platforms while making it a design choice for today's hobbyists.
Here are the details that I outlined in an private email to other members:
I wanted to let you know that I finally had time today to finish up my breadboard of the 32KB SRAM design. After a few false starts because I was using chips from defective burnt up CD ROM drive boards and wasn't sure if they were good or not, I finally got a combo of the two chips to work so now my AIM SRAM expansion design is tested and working. I'll get some photos of it and post them on the Vintage computer web site under the AIM-65 thread.
I'm beginning to think this "shim board" could have uses in other 6502 projects, vintage or current so I'm trying to keep it generic enough to adapt. Any comments or uses?
I've decided to split this into 3 phases, the first of which is completed...as I stated on the discussion board, the next phase will be a Flash ROM with the 4 languages loaded into it and bank selectable with jumpers with the A000H I/O block disabled for the AIM I/O. Any outside help with that design would be appreciated.
Once that phase is complete, I'll only need to find a way to disable the 4000H block on the SRAM and that can probably be done with the 2 remaining NAND gates in the 7400 chip...another jumper I know, but at least it can be done that way. Sticking the PASCAL code down into the SRAM space muddies up the thing quite a bit so I might start out with just working in the top 32KB area. Having PASCAL resident is what drove me to this project so I have to make that a priority.
I keep wondering why the 6502 has an N/C pin that could have been used for the RAM R/W timing so you wouldn't always have to add a timing gate chip. Does anyone know if that pin has a function?
I've also considered making 2 shim boards that stack together, one for SRAM and one for Flash...that would allow a good deal more real estate for decoding, jumpers, etc, and allow the PC boards to possibly be two layer instead of multi-layer and that certainly would decrease cost. I'll let you know as I make more progress.
Dave
Here are the details that I outlined in an private email to other members:
I wanted to let you know that I finally had time today to finish up my breadboard of the 32KB SRAM design. After a few false starts because I was using chips from defective burnt up CD ROM drive boards and wasn't sure if they were good or not, I finally got a combo of the two chips to work so now my AIM SRAM expansion design is tested and working. I'll get some photos of it and post them on the Vintage computer web site under the AIM-65 thread.
I'm beginning to think this "shim board" could have uses in other 6502 projects, vintage or current so I'm trying to keep it generic enough to adapt. Any comments or uses?
I've decided to split this into 3 phases, the first of which is completed...as I stated on the discussion board, the next phase will be a Flash ROM with the 4 languages loaded into it and bank selectable with jumpers with the A000H I/O block disabled for the AIM I/O. Any outside help with that design would be appreciated.
Once that phase is complete, I'll only need to find a way to disable the 4000H block on the SRAM and that can probably be done with the 2 remaining NAND gates in the 7400 chip...another jumper I know, but at least it can be done that way. Sticking the PASCAL code down into the SRAM space muddies up the thing quite a bit so I might start out with just working in the top 32KB area. Having PASCAL resident is what drove me to this project so I have to make that a priority.
I keep wondering why the 6502 has an N/C pin that could have been used for the RAM R/W timing so you wouldn't always have to add a timing gate chip. Does anyone know if that pin has a function?
I've also considered making 2 shim boards that stack together, one for SRAM and one for Flash...that would allow a good deal more real estate for decoding, jumpers, etc, and allow the PC boards to possibly be two layer instead of multi-layer and that certainly would decrease cost. I'll let you know as I make more progress.
Dave
Last edited:
I'm happy to do the PCB design. I agree GALs are a pain, but they are getting to be a required item.
With a TSOP or VSOP FLASH for the ROM (128kB), and TSOP32 for the SRAM, I think you can get a PCB designed that would have no larger a footprint than a DIP40. It might be a four layer board, but there's lots of SMT space in a DIP40 footprint.
I have the 40pin machine pin headers and sockets, if kits are desired. I'm trying to think of a way to generalize the addressing, so as to allow as many people to configure the unit to their demands/machines.
JIm
With a TSOP or VSOP FLASH for the ROM (128kB), and TSOP32 for the SRAM, I think you can get a PCB designed that would have no larger a footprint than a DIP40. It might be a four layer board, but there's lots of SMT space in a DIP40 footprint.
I have the 40pin machine pin headers and sockets, if kits are desired. I'm trying to think of a way to generalize the addressing, so as to allow as many people to configure the unit to their demands/machines.
JIm
orgwood
Member
I'll deal with the specifics of the AIM initially and then we can see how the general scheme works...I was "dreaming" early this morning that basically we are proposing an AVR with only RAM/ROM with the 6502 footprint...do any of them have the 6502 core or can emulate it? Next to that happening, the 6502 CPU only has 2 variants I think - 6502 and 65C02 the last one having extended instructions and using a couple more pins than the original, speeds are not considered variants in this discussion since we're proposing that the original CPU be re-inserted into the adapter.
The AIM-65 needs only the $A000 block removed from active use by either RAM or ROM for its I/O decoding. I can look at the KIM and SYM memory map to see what their expansion maps look like. That makes a 4KB block granularity necessary on the AIM. The design for this can be accomplished using a 4 line to 16 decoder or possibly a simple 7400 device SMD. I really like your approach to the 23XX adapter in terms of jumper/pad options for configuration...I could see that approach working here instead of using a GAL. My reasoning leads me to conclude that if you can make and sell a bare bones adapter board for $1.50 and a populated board for $10.00, then making separate boards for RAM and ROM expansion would be preferable to making a complicated uC/RS232 intelligent adapter that requires more software use than should be intended for these being used as trainers... IMHO that is! There are a few instances where the $8000 and $9000 block would need to be disabled because of expansion boards that use those as their hardware squatting and the notable PASCAL ROMs that use the $4000-$7FFF space but the 4K granularity works there too if, as you suggest, the mapping can be made into the three choices of RAM/ROM/expansion using 4K granularity.
Rich Chin reminded me that using 32 pin jedec compatible devices and "wasting" their extra capability is not a serious cost consideration like it was in the past! So if these are employed for the 2 board designs, then possibly only one board would need to be produced for both types depending upon how it is populated and the mapping would be the same for each type depending upon the desired enabled blocks within the 64KB addressing...one would have the RAM device and the other would have the ROM device. The reason I push for 2 separate boards is that some users may only want to expand the RAM on their machine and leave the ROM part alone...I could definitely see that on A/K/S machines but like I said, I'd have to check their respective maps.
Bumping up the height of the CPU from the main board doesn't appear to be a problem on any of the machines I'm thinking of...do you have any direct knowledge where an increase in height would be a major obstacle?
Also, the PET discussions might be a good place to put this to generate feedback as there are a lot of participants.
DaveC2
The AIM-65 needs only the $A000 block removed from active use by either RAM or ROM for its I/O decoding. I can look at the KIM and SYM memory map to see what their expansion maps look like. That makes a 4KB block granularity necessary on the AIM. The design for this can be accomplished using a 4 line to 16 decoder or possibly a simple 7400 device SMD. I really like your approach to the 23XX adapter in terms of jumper/pad options for configuration...I could see that approach working here instead of using a GAL. My reasoning leads me to conclude that if you can make and sell a bare bones adapter board for $1.50 and a populated board for $10.00, then making separate boards for RAM and ROM expansion would be preferable to making a complicated uC/RS232 intelligent adapter that requires more software use than should be intended for these being used as trainers... IMHO that is! There are a few instances where the $8000 and $9000 block would need to be disabled because of expansion boards that use those as their hardware squatting and the notable PASCAL ROMs that use the $4000-$7FFF space but the 4K granularity works there too if, as you suggest, the mapping can be made into the three choices of RAM/ROM/expansion using 4K granularity.
Rich Chin reminded me that using 32 pin jedec compatible devices and "wasting" their extra capability is not a serious cost consideration like it was in the past! So if these are employed for the 2 board designs, then possibly only one board would need to be produced for both types depending upon how it is populated and the mapping would be the same for each type depending upon the desired enabled blocks within the 64KB addressing...one would have the RAM device and the other would have the ROM device. The reason I push for 2 separate boards is that some users may only want to expand the RAM on their machine and leave the ROM part alone...I could definitely see that on A/K/S machines but like I said, I'd have to check their respective maps.
Bumping up the height of the CPU from the main board doesn't appear to be a problem on any of the machines I'm thinking of...do you have any direct knowledge where an increase in height would be a major obstacle?
Also, the PET discussions might be a good place to put this to generate feedback as there are a lot of participants.
DaveC2
MikeS
Veteran Member
On the other hand, I was more interested in alternate ROM images of the different languages; I like the idea of being able to map any 4K block to RAM, ROM, or nothing (i.e. external), but how are you thinking of selecting different ROM images in those blocks?
Without in any way taking anything away from this project, for anyone who only wants to play with the AIM's BASIC, Forth, PL/65 and Pascal languages like I did, that's fairly easy to do right now using one or two of Jim's 23xx adapters; for anyone who didn't read the discussion in the Pascal thread that sort of got this ball rolling, here it is; see post #17 for the multi-ROM mod:
http://www.vintage-computer.com/vcforum/showthread.php?22210-aim65-pascal-roms/page2
Here's the 32K ROM image containing all four language ROMs:
View attachment AIMROMS.ZIP
FWIW, here's the rear of my AIM65, showing the DIP switch that selects one of the four languages:
It also shows the RS-232 cable connecting the AIM to a PC; that's how I dealt with the Pascal ROMs in $4000-$7FFF in my 40K AIM65, by downloading the images into RAM. If you wanted to use Pascal on a 4K AIM you'd need either a ROM mapped to that area (perhaps using another of Jim's adapters and a couple of jumpers) or a RAM expander of some kind; I've used battery-backed NVRAM remapped in one of the ROM sockets as either RAM or ROM.
If anyone has the RAM and wants to load the low part of Pascal via RS-232 from a PC, here's the AIM/MOS-compatible image file:
View attachment PASC_RAM.ZIP
All this just to say that some of the AIM65 uses for the board(s) being discussed are fairly easily possible now, but certainly not as neatly and flexible.
Definitely a worth while project! Nice to see some interest in the AIM65; any chance you could include me in your off-list discussions?
FYI, an AIM has expanded RAM in $8000-$9FFF but the PETs have their video memory at $8000, the PET's I/O is at $E800-$EFFF instead of the AIM's $A000, and the various PET ROMs are at $9000-$FFFF; sounds like you'd have all that covered. In one of my PETs I've also combined the 14 ROMs that make up versions one and two of the BASIC/firmware into one EPROM, again using one of Jim's adapters; great little gizmo but certainly not as versatile as this project promises to be.
river
Member
Hi,
Yes, I know this is an old thread, but as I am new here it is new to me
I have a few AIM65s. I poached a couple of the LED displays from one to get the other 2 going. I am looking at replacing the LEDs (DL1416 - which are nigh impossible to get now) with 16 segment LEDs, being driven by a Atmel or Microchip device, but that is something that will need to wait.
I made a wire-wrap expansion for one of the AIMs, which gives me 40K of RAM (32K and an 8K static ram chips) and I sliced up the A000 area to provide 8 x 128 byte areas, and added a 6520, 8255, 6840 and 6551, as well as the standard user VIA. I put the whole thing into a rather agricultural home-made box, with all the interface pins along one edge and I stuck down a large breadboard on the top. This makes development and interfacing much easier and quicker. Currently finishing off the hardware design for an EPROM burner which will allow me to burn EPROMS from 2704 to 27128. It's not a pretty thing, but very functional. I got a couple more mods I want to do to the unit, and some software to develop and I'll be a happy chappy with this AIM unit.
I can supply pics and any schematics for it, if required.
regards
river
Yes, I know this is an old thread, but as I am new here it is new to me
I have a few AIM65s. I poached a couple of the LED displays from one to get the other 2 going. I am looking at replacing the LEDs (DL1416 - which are nigh impossible to get now) with 16 segment LEDs, being driven by a Atmel or Microchip device, but that is something that will need to wait.
I made a wire-wrap expansion for one of the AIMs, which gives me 40K of RAM (32K and an 8K static ram chips) and I sliced up the A000 area to provide 8 x 128 byte areas, and added a 6520, 8255, 6840 and 6551, as well as the standard user VIA. I put the whole thing into a rather agricultural home-made box, with all the interface pins along one edge and I stuck down a large breadboard on the top. This makes development and interfacing much easier and quicker. Currently finishing off the hardware design for an EPROM burner which will allow me to burn EPROMS from 2704 to 27128. It's not a pretty thing, but very functional. I got a couple more mods I want to do to the unit, and some software to develop and I'll be a happy chappy with this AIM unit.
I can supply pics and any schematics for it, if required.
regards
river
orgwood
Member
Hi,
Yes, I know this is an old thread, but as I am new here it is new to me
I have a few AIM65s. I poached a couple of the LED displays from one to get the other 2 going. I am looking at replacing the LEDs (DL1416 - which are nigh impossible to get now) with 16 segment LEDs, being driven by a Atmel or Microchip device, but that is something that will need to wait.
I made a wire-wrap expansion for one of the AIMs, which gives me 40K of RAM (32K and an 8K static ram chips) and I sliced up the A000 area to provide 8 x 128 byte areas, and added a 6520, 8255, 6840 and 6551, as well as the standard user VIA. I put the whole thing into a rather agricultural home-made box, with all the interface pins along one edge and I stuck down a large breadboard on the top. This makes development and interfacing much easier and quicker. Currently finishing off the hardware design for an EPROM burner which will allow me to burn EPROMS from 2704 to 27128. It's not a pretty thing, but very functional. I got a couple more mods I want to do to the unit, and some software to develop and I'll be a happy chappy with this AIM unit.
I can supply pics and any schematics for it, if required.
regards
river
DL-1416s are still showing up on eBay and I have several I'd sell you for $15ea. But if you want to do that programming work, etc. go ahead. I would like your help in making the AIM-65 "see" PS2 keyboards as its own since those are the only component I can't get or even find replacement switches or keycaps for.
I also have several older Cubit EPROM boards that I am modifying to hold the 16KBs of Pascal in the 4000-7FFFH block.
Your 32KB + 8KB expansion is one that Dynatem did when they made the last change to the AIM and they provided for the 8000 & 9000 block to be either SRAM or EPROM.
I don't know of what value that range of EPROM chips would be for you but it wouldn't do much for the AIM unless you provide bank switching too.
Dave
river
Member
Hi,
The EPROMS are for other systems I have and am thinking of building. I have a ProLog M900 but it only has the module for the 2716. I also have a MicroProfessor MPF-1P with the EPROM burner attachment, which works fine (better nnow that I wrote an Intel hex File loader) but it's range of devices is somewhat limited, and it seemed like a good project to test out my modded AIM65. Thank you for the offer on the DL1416 devices. I will check how many I need and may take you up on that offer.
In regards to using a PS/2 keyboard... are you thinking of making changes to the actual AIM ROMS and subsequent hardware mods so the AIM does all the work, or are you looking for a solution which will not require these mods (ie an AVR or PIC doing the work and providing scan codes back to the AIM)?
regards
river
The EPROMS are for other systems I have and am thinking of building. I have a ProLog M900 but it only has the module for the 2716. I also have a MicroProfessor MPF-1P with the EPROM burner attachment, which works fine (better nnow that I wrote an Intel hex File loader) but it's range of devices is somewhat limited, and it seemed like a good project to test out my modded AIM65. Thank you for the offer on the DL1416 devices. I will check how many I need and may take you up on that offer.
In regards to using a PS/2 keyboard... are you thinking of making changes to the actual AIM ROMS and subsequent hardware mods so the AIM does all the work, or are you looking for a solution which will not require these mods (ie an AVR or PIC doing the work and providing scan codes back to the AIM)?
regards
river
orgwood
Member
Daryl Richter already liked my timeout idea and modded his ATMEL PS2 converter so I could see if it would work as the hardware interface but I'm short of time...I would need an EPROM 2764, I think 8KB x 8, programmed to act as a translator to take the AVR codes and convert them to the scan codes expected by the AIM...I've seen that done before and it would allow for other keys to be added to programs written to execute on the AIM "IF" the monitor keyboard routine was either re-written or bypassed by the application program and a substitute one written to handle the extra codes.
I have a ROMMAX+ that I'm using to program my vintage EPROMs and I use an AIM programmer to make my 2532s for the AIM.
I also have 4 or 5 of those Cubit 2716 ROM boards that I intend to populate and make them into 2716/2532 programmers for the AIMs I'm selling and also provide the 16KB Pascal block 4-7FFFH block.
Where do you live? I live in White Bear Lake MN and you can find me at www.originalwoodworks.com or orgwood@iaxs.net
Peace,
Dave
river
Member
I live in Sydney "The Jewel of the Pacific"
But next time I'm over in the good old US of A, I may just visit. I like to consume wine, play around with old processors, listen to vinyl LPs, fix/restore old audio equipment, restore and modify old cars.... and raconteur over many things. :D
The AVR option is viable, but as the scan code is generated by the AIM software it will need to match what values the AIM has sent/received to/from the 6520 that interfaces to the keyboard, or re-write some of the AIM keyboard inmput routines.
But next time I'm over in the good old US of A, I may just visit. I like to consume wine, play around with old processors, listen to vinyl LPs, fix/restore old audio equipment, restore and modify old cars.... and raconteur over many things. :D
The AVR option is viable, but as the scan code is generated by the AIM software it will need to match what values the AIM has sent/received to/from the 6520 that interfaces to the keyboard, or re-write some of the AIM keyboard inmput routines.
orgwood
Member
I live in Sydney "The Jewel of the Pacific"
But next time I'm over in the good old US of A, I may just visit. I like to consume wine, play around with old processors, listen to vinyl LPs, fix/restore old audio equipment, restore and modify old cars.... and raconteur over many things. :D
The AVR option is viable, but as the scan code is generated by the AIM software it will need to match what values the AIM has sent/received to/from the 6520 that interfaces to the keyboard, or re-write some of the AIM keyboard inmput routines.
Actually, that's what the EPROM does...also, it's the 6532 that does the keyboard interface. I believe the EPROM is actually larger than 8KB x 8...more like 8 bits larger in addressing space. It take the AVR 8 bit output and combines it with the 8 AIM scan bits and outputs the proper scan code to the 6532 input lines to "make" the AIM see a keystroke. But I needed it to time out because Daryl had his provide handshaking with the host that the value was received and the AIM monitor doesn't provide for that. He programmed some chips for me with that provision.
raconteur - now that's a word I've not seen before but I can probably guess at it's meaning.
I have given up the wine and cars but know my way around tube audio devices having grown up with 6V6s and 12AU7/12AT7s and various others but god help me with those OZ4s - I nearly died holding onto the output leads when I plugged the vibrator transformer into 120VAC mains.
daver2
10k Member
Just a thought (thinking about a new keyboard interface). Why not use something like an Atmel ATF1504 or ATF1508 CPLD to implement the keyboard interface and then interface that to a micro controller with the PS/2 bit in it?
The AIM65 keyboard consists of 54 keys arranged in an 8x8 matrix (=64 keys maximum). The interface to the Z33 RIOT is 8 outputs and 8 inputs (giving us the 64 key matrix). The CPLD could implement latches for the 'keys' and the appropriate logic to provide the correct row outputs for the scan column inputs. A separate parallel interface [consisting of say six bits (=64 combination) to address each internal latch, 1 data line (to specify latch on or off) and 1 strobe line] would provide the interface to the micro controller. A separate RESET line may be required to guarantee that the latches are all deselected on a reset (but this would happen on a power start anyway).
A total of 8+8+8 = 24 logic lines (ignoring the reset) would be required for this - well within the capability of the current Atmel CPLDs. One of their larger devices will be require to achieve the desired number of internal 'virtual' latches - however, this requirement could be reduced - as only a few 'keys' should be pressed at any one time! The shift and control keys would be separate latches - but the expectation is that the other keys will be depressed one at a time in reality... This would reduce the number of internal CPLD latches required - and hence reduce the cost of the solution.
The CPLD would take care of the AIM65 specific key polling interface and a separate micro controller (or even another CPLD implementing its own keyboard scanning algorithm for a separate key matrix) would take care of the details of the external keyboard interface.
Just a thought to throw into the ring...
Dave
The AIM65 keyboard consists of 54 keys arranged in an 8x8 matrix (=64 keys maximum). The interface to the Z33 RIOT is 8 outputs and 8 inputs (giving us the 64 key matrix). The CPLD could implement latches for the 'keys' and the appropriate logic to provide the correct row outputs for the scan column inputs. A separate parallel interface [consisting of say six bits (=64 combination) to address each internal latch, 1 data line (to specify latch on or off) and 1 strobe line] would provide the interface to the micro controller. A separate RESET line may be required to guarantee that the latches are all deselected on a reset (but this would happen on a power start anyway).
A total of 8+8+8 = 24 logic lines (ignoring the reset) would be required for this - well within the capability of the current Atmel CPLDs. One of their larger devices will be require to achieve the desired number of internal 'virtual' latches - however, this requirement could be reduced - as only a few 'keys' should be pressed at any one time! The shift and control keys would be separate latches - but the expectation is that the other keys will be depressed one at a time in reality... This would reduce the number of internal CPLD latches required - and hence reduce the cost of the solution.
The CPLD would take care of the AIM65 specific key polling interface and a separate micro controller (or even another CPLD implementing its own keyboard scanning algorithm for a separate key matrix) would take care of the details of the external keyboard interface.
Just a thought to throw into the ring...
Dave