Running AIM65 code

[djrm]

Now that the AIM65 display is working I have rebuilt the AIM65 rom code to run on my MECB. The changes include I/O space address changes and patching in the SYS_IO PS2 keyboard instead of the AIM65 keyboard. The AIM65 has a bitbang serial port for TTY implemented in the 6522 this is being fed to a TTL to USB adapter and is also working. The code is loaded using xmodem from the sbcos monitor, I haven't committed it to a rom yet but when I do it should be possible to use the AIM65 language roms.

This version is built by modifying the original source code to run at address 0x2000 with monitor ram moved to 0x400 (instead of 6532 ram)
The simple keyboard input function I had already put into the sbcos rom

Code: Select all

; setup via for keyboard
PS2KB_Init       lda      #$08
               sta      Via1PCR
               lda	  Via1PRA                              
               rts                     ; done
               
PS2KB_Scan
                lda    Via1IFR         ; LOAD STATUS REGISTER
                lsr
                lsr
                BCC     kcirtn          ; RETURN IF NOTHING
                LDA     Via1PRA      ; LOAD DATA BYTE
kcirtn       RTS                         ; RETURN TO CALLER

PS2KB_Input
                JSR     PS2KB_Scan
                BCC     PS2KB_Input
                RTS
              

Pictures show,
1) AIM65 Memory command showing rset vectors

2) AIM65 Dump command showing top page of memory in serial console.

Code: Select all

  ROCKWELL AIM 65


<D>
FROM=FF00  TO=FFFF
OUT=

;18FF0078D8A2FF9AA91F8501A90085009200C600D0FAC60110F6850C92
;18FF1801ADF80349A5CDF903F010A276A9E1A849A58DF9038CF8030DD7
;18FF308EF703ADFE0349A5CDFF03F010A2BFA9FFA849A58DFF038C0EF4
;18FF48FE038EFD03ADFB0349A5CDFC03F010A2BFA9FFA849A58DFC0F7B
;18FF60038CFB038EFA03ADF50349A5CDF603F010A2BBA9E2A849A50E66
;18FF788DF6038CF5038EF403A9558D0502A9E18D0602A9698D07020B77
;18FF90A9E18D0802A92E8D0B02A9B88D0C02A9578D0902A9B88D0A0AC5
;18FFA8022000E02056E020DEE0A900A8AA18D8586CF7036CFD03400C4A
;18FFC0DA48BABD03012910D00568FA6CFA0368FA6CF40360FFFFFF0E6F
;18FFD8FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF19D7
;10FFF0FFFFFFFFFFFFFFFFFFFFBCFF00FFC0FF106E
MORE?N;00000C000C


<

I had to disable the AIM65 printing to allow the PS2 keyboard to operate.
Interesting to see the 6522 bitbang auto baud rate detection appears to be working even though this system is running at 2MHz instead of 1MHz
A bit of retro fun. I shall get the opportunity to try a real AIM65 at the weekend, David.

[djrm]

Video showing initial test: https://youtube.com/shorts/Xs-mNs-Hi5g

This uses a hacked PS/2 keyboard receiver which does not wait for successful reset acknowledge sequence to allow operation with MECB keyboard

[Editor]

Thanks for posting the video. That display looks really nice in operation. Definitely an improvement over the 6 digit 7-segment displays we had on our early evaluation boards.

And, of course, the keyboard is a major improvement on the hex keypads of old!

But, seriously, it was nice to see the keyboard in operation with something other than the CreatiVision. It looked (and sounded), really good!

I think I’m nearly there with a full bidirectional PS/2 interface, now that I’ve found an old 386 PC with a proper original PS/2 port to test and debug with!

[djrm]

I found this old VF display in my shed this week and couldn't resist trying it again. I chose to use Ben Eaters 4 bit VIA interface together with my PS2 keyboard to make this demo.

I have eventually managed to clear the bugs from my AIM65 recreation and can now run its Monitor, Assembler, and Basic. albeit with rebuilt code to run with a modified address memory map. the monitor entry addresses remain unaltered for compatibility.

Apart from having a dodgy 6532 RIOT chip, and some bugs in the re-mapping, the worst problem was the inability of the DC barrel connector to work without dropping the board voltage causing occasional resets.

My S3 emulator cant cope properly with 28c256 roms, it doesn't know the right pin for the A14 address line, I've had to patch the write enable jumper to A14 to access the bottom 16K, so although using the emulator was supposed to make code testing easier it caused an extra headache on the way...

I also got a couple of real AIM65s working today which was nice, one was part of an incomplete industrial alarm system in a custom rack case. I put stock firmware into it to make it usable.

Next off I'll try and recreate a tape interface, maybe try to use one of the simulations available for the C64.
Best regards, David.

[djrm]

I've spent a while improving the AIM-65 by adding buffered serial input with flow control from a an ACIA this allows pasting in files and basic programs, here is an example from an old magazine article.

The MECB AIM-65 now has a custom bios for my devices and monitor which can be patched for either PS2 or AIM keyboards. I have a thermal serial till receipt printer which I'll try and patch in somehow.

There are lots of indirect jumps through ram to allow adding devices etc, this reminds me of my old Ohio C1P from back in the day when I first started learning about computers. The basic is almost identical too.

AIM-65 monitor source: http://retro.hansotten.nl/6502-sbc/aim- ... -software/
MS Basic source: https://www.pagetable.com/?p=46
Banner program: https://web.archive.org/web/20160611092 ... tive_2.pdf

Code: Select all

LIST

 10 REM "BANNER"
 20 REM G. BRINKMANN
 30 REM PRINTER OFF
 40 REM POKE 42001,0
 50 INPUT "TEXT";A$
 60 INPUT "TIMES";C
 70 REM PRINTER ON
 80 REM POKE 42001x128
 90 FOR D=1 TO C
 100 PRINT" ":PRINT" ":PRINT" "
 110 FOR I=1 TO LEN(A$)
 120 REM GET CHARACTER
 130 B = ASC(MID$(A$,I,1) )
 140 IF B>63THENB=B-64
 150 REM PRINTER-TAB
 160 B=B+62177
 170 FOR J = 1 TO 5
 180 REM ALL TWICE
 190 FOR N=1 TO 2
 200 REM LOAD BIT*6
 210 A=64: PRINT" ";
 220 REM 7 ROWS
 230 FOR J1=1 TO 7
 240 Z$=" "
 250 REM BIT ON?
 260 IF ( PEEK( B)ANDA) THEN Z$="#"
 270 PRINTZ$;:PRINTZ$;
 280 REM BIT-SHIFT RIGHT
 290 A = A/2
 300 NEXT J1
 310 PRINT
 320 NEXT N
 330 REM NEXT COLUMN
 340 B = B + 64
 350 NEXT J
 360 PRINT" ":PRINT" "
 370 NEXT I
 380 NEXT D
 390 GOTO 40
RUN
TEXT? MECB
TIMES? 1
 
 
 
 ##############
 ##############
           ##  
           ##  
       ####    
       ####    
           ##  
           ##  
 ##############
 ##############
 
 
 ##############
 ##############
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
 ##          ##
 ##          ##
 
 
   ##########  
   ##########  
 ##          ##
 ##          ##
 ##          ##
 ##          ##
 ##          ##
 ##          ##
   ##      ##  
   ##      ##  
 
 
 ##############
 ##############
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
 ##    ##    ##
   ####  ####  
   ####  ####  
 

[djrm]

This is a photo of a ready made cassette simulation 'Tapuino' for the Commodore C64 connected to my AIM-65 like MECB system. It seems to work remarkably well in that it can be used to save and restore basic programs and editor text files to the MicroSD card.

AT preset I need to switch between play and record functions since the AIM-65 has a single I/O line with a direction control, the TApduino has separate input and output connections. A simple demultiplexer is needed but I dont have a suitable open collector logic gate for this just now though I could probably just use a transistor anyway.

I was however hoping that I could use it to export files from the PC into the AIM-65 but that needs more work as the transfer tool would need to understand the block structure of the AIM-65 tape format. The blocking is done by the AIM-65 software during save and isn't a problem. Still its a useful addition having a software archive available when there is no local PC to host files.

I could have built one out of parts lying around here but for UKP20 i thought I'd get one ready-made in a box.
I'll probably make a video showing it in operation shortley.
Best regards, David.

[djrm]

I have been using real vintage AIM-65 computers as well as my MECB recreation to learn about the system. Over the last few weeks I found plenty of additional hardware expansion ideas. One which took my fancy is the 6545 (6845) CRT controller interface, evers since the '80s Ive wanted one of these because they allow 80 column operation. Scott Baker has updated the original Rockwell design using PLDs and moder large RAM and ROM chips to make a useful AIM-65 upgrade. I couldn't resist this and ordered the boards from JLCPCB and a set of chips to build my own. I made a frankenstein MECB implementation by bolting the CRT card to a MECB prototype card to prove the system, happily it seems to work now that I have patched the rom firmware to match my slightly non-standard memory map. I have several bare boards so I shall be building another to fit to one of the vintage AIM-65s at the local museum, this time complete with proper connectors to fit on the AIM-65 expansion bus connector with the matching adaptor from Mr Baker.

More information here:
http://retro.hansotten.nl/6502-sbc/aim-65/rm-65/
https://github.com/sbelectronics/aim65/ ... er/display

Best regards, David.

[djrm]

My AIM-65 reconstruction using MECB boards is now stable and ready for some fine tuning and improvement. The current state of play has been committed to Github ready for the next phase. The memory map of ROM and RAM now matches the original AIM-65 but the I/O devices are squeezed into a 256 byte MECB I/O space. If I open this out to the full 4k space usd by the original board then I will not have to use amended roms for the system to work. Everything seems to be working properly now so this may not be necessary. code here: Github AIM-65_MECB

[Editor]

The memory map of ROM and RAM now matches the original AIM-65 but the I/O devices are squeezed into a 256 byte MECB I/O space. If I open this out to the full 4k space usd by the original board then I will not have to use amended roms for the system to work.

This is really interesting, and has me thinking (Oops!). If my quick research is correct, I note the AIM65 allocates 4x 1K I/O spaces in the $Axxx address bank, with all 4 I/O address spaces used by onboard devices (including a 6532 RIOT that provides an extra 128 bytes of system used RAM in the I/O space).

This takes me back to the original debate I had with myself, over standardising the MECB glue logic on the ATF16V8 or the ATF22V10 PLD.

I was finally swung to go the ATF16V8 way, on the basis of avoiding the need for a less common Narrow DIP24 IC socket, and avoiding over-engineering (perhaps?), to stay true to the “Minimalist” idea of MECB.

Your AIM65 project, however, turns out to be a perfect example of why going to the ATF22V10 for the MECB glue logic standard would have been beneficial.

But, thinking this through a little further, there is actually no reason I couldn’t now extend my MECB standard definition to specify either an ATF16V8 or a ATF22V10 for the glue logic.
I could then also create a second KiCAD template, around the ATF22V10, to simplify creating a new MECB Card with either PLD choice.

With the ATF22V10, I think I’d allocate the extra 4 pins to the 3 extra address lines that are currently missing (A8 - A10), to now provide a full 8 byte fine resolution of the 64K address space allocation (instead of the current 2KB resolution). The final extra pin then being assigned as a 4th Chip Select output (so we would now have CS0 - CS3).

This would then allow a future MECB CPU Card (or existing Card upgrade to ATF22V10), to support virtually the full 64K memory map address decoding flexibility, and also allow the potential for a 4 device I/O Card (a 4 device AIM 65 specific I/O Card would be a good example).

You’d then be able to make a memory map accurate AIM 65 re-Creation.

At the moment, I believe you’d need to "hack" your existing Card(s) to maybe swap the A7 PLD input to be A10 instead, so you could achieve 1K address decoding resolution on the modified Cards (loosing half of your MECB IORQ bank to a mirror image). But this wouldn't be as friendly to other MECB users wanting to replicate your work.

Let me know your thoughts on this, as you seem to have already tipped me towards a re-think of perhaps adding the ATF22V10 as an option to my MECB Standardised Specification.

[djrm]

Hi Greg,
I had several goes at arranging the AIM-65 memory map on the MECB, initially I was expanding the MECB IORQ bank size by forcing some of the dip switch inputs. I gave up on this idea when I realised that the interface cards did not have suitable address pins input to the PLD. This is the reason I squeezed everything into a single 256 byte I/O space. Initially I had wanted to be able to include my full set of I/O cards but the AIM-65 6532 chip memory eats into 128 bytes of I/I space making the remainder of the devices a tight fit. but it works although I have had to patch the roms to match this new mapping- no great problem if the source is available, a bit more tricky if not.

I was disappointed to see that available address bus inputs to the prototype board included A15-A12 , these are not much use here and A11-A12 would have been more useful. but this had never been a problem before and probably will not be again. For sure the 22v10 would be more useful but I cant guarantee it would help. Some extra flexibility to jumpering the pld inputs instead of having to cut tracks would have useful too where I needed to give the IORQ bank more then 256 bytes.

On my present setup the ram and rom are on the additional display board, the memory sockets on the CPU board are now empty. Best regards, David.