AIM-65 Video Output Success.

Today I did some experiments seeing if the CRTC card could coexist with the AH5050/1541 disk drive system and the AIM-65.

The CRTC card does not seem to mind the pointers and other changes applied by Daver2's INIBAS and the CRT video works well. And BASIC runs. However the SAVE and LOAD functions, supported by INIBAS fail when the CRTC card is running too.

Typically the BASIC file appears to SAVE or SAVEB ok to the disk, but on LOAD it reports 63 FILE EXISTS 00 00 , DEV= and it fails to load. So somewhere there is a conflict.

Just out of interest are you using my INIBAS 'as is' or have you modified the BASIC pointer to point to $0401?

The RM65 firmware uses some variables at $0357, $035A, $035E (and I am sure others as well). If the BASIC pointers are below $0400 you could run into trouble.

That's the first thing that comes to my mind...

Dave

daver2 said:

Just out of interest are you using my INIBAS 'as is' or have you modified the BASIC pointer to point to $0401?

The RM65 firmware uses some variables at $0357, $035A, $035E (and I am sure others as well). If the BASIC pointers are below $0400 you could run into trouble.

That's the first thing that comes to my mind...

Dave

Click to expand...

Dave,

It seems that the CRTC card doesn't mind the pointers altered in the same way INIBAS alters them and point to $0301 instead, rather than the suggestion in the CRTC manual pointing to &$401. But INIBAS does alter those 3 bytes that configure the CRTC card's setup. So what I will try next is to alter the pointers manually and run the CHRGET program instead, to avoid that conflict and see what happens.

Hugo Holden said:

Dave,

It seems that the CRTC card doesn't mind the pointers altered in the same way INIBAS alters them and point to $0301 instead, rather than the suggestion in the CRTC manual pointing to &$401. But INIBAS does alter those 3 bytes that configure the CRTC card's setup. So what I will try next is to alter the pointers manually and run the CHRGET program instead, to avoid that conflict and see what happens.

Click to expand...

I think Dave is right. The INBAS program needs to be modified for $0401 rather than $0301. The CRTC card will appear work fine with the BASIC workspace starting at $0301, until the program gets larger than a few lines and overwrites the CRTC variables which are located from $0347 to $0385.

I have no idea why the variables start at $0347 rather than, for example, $0300. Perhaps the system used to develop the code had some other tools which used the ram up through $0346? Or perhaps there are other widely used ROMs or programs that use that space?

dfnr2 said:

I think Dave is right. The INBAS program needs to be modified for $0401 rather than $0301. The CRTC card will appear work fine with the BASIC workspace starting at $0301, until the program gets larger than a few lines and overwrites the CRTC variables which are located from $0347 to $0385.

I have no idea why the variables start at $0347 rather than, for example, $0300. Perhaps the system used to develop the code had some other tools which used the ram up through $0346? Or perhaps there are other widely used ROMs or programs that use that space?

Click to expand...

Thanks,

I will try this tonight and report the results.

Wow Hugo this is really impressive. Amazing really.

Something to report, I modified the INIBAS program (the shorter version) see attached to 0401 . I hope I didn't foul that up.

And tested this INIBAS, the protocol being:

Cold start BASIC <5>, escape to AIM monitor.
Initialise AH5050 system <N>
Run INIBAS, in this case * 0270 and G/
Re-enter BASIC <6>
TYPE NEW !
and then test BASIC,

Working normally, with SAVE & LOAD working too. Suggesting this modified INIBAS is ok.

Then escape to AIM monitor, enter bytes to control the CRTC, $035A = 05 and $0357 = 02.

then run the CRTC software * 9900 and G/. the CRT display takes over. Re-enter BASIC with <6> and test BASIC.

BASIC "works" in that programs RUN & LIST normally. Programs appear to SAVE normally (see below). Attempting to LOAD a file though reports the same error I saw before, it comes up with:

63 FILE EXISTS 00 00
DEV=


Deactivating the CRTC card with CTRL-Y and returning to the AIM display, the BASIC SAVE and LOAD functions recover.

Trying to retrieve a file saved,created when the CRTC card was active, does not work. So not only is the LOAD function in some way affected with the CRTC running, the file created with a SAVE is also somehow affected with the CRTC running.

Good detective work there Hugo.

I am just wondering how they 'hooked' the CRTC functionality into the AIM-65 MONITOR. I wonder if they use the same (user) vector that the AH5050 is using 'under the hood'?

If they do, that is probably game over.

Just thinking aloud...

Dave

daver2 said:

Good detective work there Hugo.

I am just wondering how they 'hooked' the CRTC functionality into the AIM-65 MONITOR. I wonder if they use the same (user) vector that the AH5050 is using 'under the hood'?

If they do, that is probably game over.

Just thinking aloud...

Dave

Click to expand...

Hi Dave,

Well if that is the case it is no major drama.

From my point of view, the greatest improvement to the user friendliness of the AIM-65 is the CRTC video card. When it comes to program storage, I can move away from the AH5050/Commodore1541 disk drive & back to cassette tape if I have to. And at least, in the latter case, the Assembler socket then becomes free for the original AIM-65 Assembler ROM.

It might be an interesting case of "third party hardware and software utilities" (like the AH5050 system from ABM) not being entirely compatible with the manufacturer (Rockwell) systems, and the variations or permutations of those.

This was one reason, when I was looking at ways to get good video out of the AIM-65, it was an inescapable conclusion, that the Rockwell CRTC board would be the way to go.

Well, getting the AH5050 working properly was a pipe dream not too long ago wasn't it?

Is the RM-65 ROM dump available online somewhere? Perhaps a bit of disassembly is required here to see what is going on...

Dave

You have to realize, the card was made to work with their industrial system and not the AIM-65. It was designed to run on a 6502 but not the BASIC or even the Forth that runs on the AIM-65. It was intended to run on the Forth that was configured to run on the development system or customer developed operating systems. The need to patch the vectors of the AIM-65 is not a surprise to me.
Dwight

Dwight Elvey said:

You have to realize, the card was made to work with their industrial system and not the AIM-65. It was designed to run on a 6502 but not the BASIC or even the Forth that runs on the AIM-65. It was intended to run on the Forth that was configured to run on the development system or customer developed operating systems. The need to patch the vectors of the AIM-65 is not a surprise to me.
Dwight

Click to expand...

Actually, it appears that this board was developed with the idea of an AIM 65 driving an RM-65 cage. The manual has very specific instructions for hooking the CRTC firmware into AIM 65 BASIC, FORTH, PL/65, the Editor/Assembler. There's even a flag, "AIM65" to control how the CRTC line-processing firmware sends the completed lines to the active AIM65 program. The manual also describes how to attach certain actions to the AIM-65 function keys.

One solution was right there in my post. All that has to be done to keep the AH5050 system working along with the CRTC card is to toggle back to the AIM-65 display before using SAVE & LOAD or the AH5050 Filer.

So from my perspective its it still possible to use the CRTC and the AH5050 simultaneously. (Going back to tape after coming so far with the AH5050,what was I thinking !)

Also, I was going to make a pcb adapter, so as to be able to select the AH5050 ROM or the Assembler ROM too.

When I started looking around for a way to get video out from the AIM-65 it was suggested I look at the S. Rines video board. What put me off that one was that the pcb was the size of the AIM-65 motherboard and it contained 131 IC's. This certainly made the Rockwell CRTC card very attractive by comparison. I could possibly have replicated that Rines pcb, but it would have been quite a task, including acquiring the IC's for it.

dfnr2 said:

Actually, it appears that this board was developed with the idea of an AIM 65 driving an RM-65 cage. The manual has very specific instructions for hooking the CRTC firmware into AIM 65 BASIC, FORTH, PL/65, the Editor/Assembler. There's even a flag, "AIM65" to control how the CRTC line-processing firmware sends the completed lines to the active AIM65 program. The manual also describes how to attach certain actions to the AIM-65 function keys.

Click to expand...

It is clear that it was made to be used with the adapter on the AIM65 but It was specifically intended for the RM65 board set. These were used for industrial uses and their development systems. The development also had ICE for various part types. The development machines all used a custom variation of FIG Forth, similar to that used on the AIM65 but with different memory and I/O fuctions and locations. I don't know if they sold Forth to be used with industrial applications that they did not write. It is an excellent development platform for bringing up new hardware. They used it as there main in-house language, because of its flexibility.
Dwight

I have more to report:

The CRTC card works perfectly with the AIM-65 and the BASIC on the AIM-65. As one might expect it would work because it was all Rockwell designed and I cannot find any incompatibility.

The problem arises trying to run the CRTC card simultaneously with the AH5050 filer (when using the Filer on its own or when BASIC hooks into the Filer for a LOAD & SAVE).

I thought that toggling away from the CRTC card with CTRL-Y and going back to the AIM-65 display would effectively "deactivate the CRTC card", but it does not, the CRTC is doing something that causes the AH5050 Filer to lock up and lock up the computer at times too where it seems to be fighting the Filer.

So the CRTC card software must be interfering in some way with what the AH5050 Filer is doing. Maybe not surprising since the developers (ABM) of the AH5050 probably didn't know what parts of the AIM-65's memory that the Rockwell CRTC board was using when used with the AIM-65.

Maybe we cannot have our cake and eat it too. I notice that the photo I originally found, that showed the RM-65 CRTC operating with a VDU and the AIM-65, showed a tape deck in the image for data storage, not a 1541 disk drive !

Maybe one solution is a chanegover switch to de-select the CRTC board, or AH5050 ROM with hardware switching to avoid a conflict. So for example while working in BASIC with the CRTC card and VDU, the AH5050 is deactivated, and reactivate the Filer and deactivate the CRTC card to use the Filer or BASIC SAVE and LOAD functions using the AIM-65 display.

It seems that the issue here is the I/O redirections that are taking place for the disk SAVE/LOAD operations, and the CRTC terminal emulation.

The AIM 65 permits I/O to be re-routed by altering predefined handler address vectors. These are normally configured to make sure that, for example, a keycode generated by the keyboard scan routine gets printed on the printer and also send to the active software (e.g., BASIC).

I am assuming that BASIC save/load use vectors to intercept the read/write process to be able to PRINT or LIST to a parallel printer or serial port, or to SAVE/LOAD from cassette, serial port, or disk by pointing to the correct handlers.

The CRTC intercepts these I/O vectors as well, to be able to make sure that listings are properly displayed on the screen rather than the LCD, to route keyboard input through the terminal emulator before sending to the AIM-65 software (BASIC). The I/O vectoring is a bit complicated, since the keyboard input and the print/list output all go through the terminal emulator (so that print CHR$(1) will clear the scren, just like typing CTRL-A).

I wonder if there's some interaction between the CRTC and disk I/O vector configuration that is causing issues. Normally, there would be an operating system that would take care of routing all the I/O on the fly, instead of manually dropping to the monitor (or POKING addresses) to re-route the I/O. Perhaps a routine could be loaded in the unused portions of page 2 and 3 that could get called by the SAVE vector, which configures the disk settings, does the SAVE, reconfigures for CRTC, and returns. Or something similar.

Unfortunately, I'm unable to dig into this at the moment.

I think, if a disk system is set up, then the best would be to remove the ROMs, replace with RAM, and reassemble disk versions of BASIC, FORTH, etc. and create a minimal little I/O handler (a minimal OS) to make sure all the I/O works nicely together.

I found a solution that works (a hardware one, typical me)

This was the sequence:

# Start AIM-65
# Cold start BASIC <5>, enter Memory size 4000, width 72
# Escape to monitor
# Initialise filer <N>
# Run INIBAS ...the short version with the values at $0400 set to 00 00 00
# Warm start BASIC <6>
# Type NEW , this makes sure all the pointers are correct and they also suit the CRTC card.
# escape to monitor.
# Initialise CRTC card $035A = 05, $0357 = 02, $035E = 48.
# * 9900, and G/ starts CRTC card, it takes over the display.
# <6> warm start BASIC , everything working fine.
# Finish creating a BASIC program (much easier with the CRTC display than AIM display) when done;
# CTRL-Y return to AIM-65 LED display
# escape to monitor again
# Disable CRTC Card, it this case just remove clock select jumper on the CRTC card to kill the clock (there will be a better method)
# re-initialise the Filer <N> to ensure nothing got corrupted, though not 100% sure if this is required.
# re-enter BASIC
# SAVE the BASIC program, and LOAD, all works normally.

So it is just a matter of making sure when the Filer functions are required the presence of the CRTC does not upset the apple cart. My thinking is a hardware switch to make sure they both cannot be running at the same time.

The setup I think needs a switch to select: Assembler ROM or AH5050 ROM (both in an adapter on socket Z24) and that same switch could be used to inhibit the CRTC card, in the case where the AH5050 ROM is selected to avoid the conflict. I just need to think up a more elegant way of disabling the CRTC card, any suggestions ?

The new operating sequence would be (with one toggle switch)

Toggle switch selects AH5050 ROM (and inhibits CRTC card)
Start AIM 65
cold start BASIC <5>
escape to monitor
Initialize AH5050 Filer
run INIBAS
warm start BASIC, type NEW (required to correct pointers at $0075 & $ 0076)
escape to monitor again
Select Assembler ROM with switch (AH5050 ROM now disabled and CRTC card enabled) with toggle switch.
Initialise CRTC card $035A = 05, $0357 = 02, $035E = 48.
# * 9900, and G/ starts CRTC card, it takes over the display.
Re-enter BASIC <6>

Make BASIC programs, with CRTC display.

To SAVE and LOAD:
CTRL-Y return to AIM display
Escape to monitor
Select AH5050 ROM with switch (also it disables the CRTC, doesn't matter as now using AIM display)
Initialise Filer <N>
re enter BASIC <6>
SAVE and LOAD BASIC programs to disk.

I can probably automate most of your start-up procedure except for the final "<6> warm start BASIC"...

I am just wondering whether there are some interrupts involved here rather than I/O vectoring? I wonder if the video card requires a periodic interrupt to enter the ROM code, and it is this that is stealing time from a time-critical piece of code within the AH5050 firmware?

Dave

daver2 said:

I can probably automate most of your start-up procedure except for the final "<6> warm start BASIC"...

I am just wondering whether there are some interrupts involved here rather than I/O vectoring? I wonder if the video card requires a periodic interrupt to enter the ROM code, and it is this that is stealing time from a time-critical piece of code within the AH5050 firmware?

Dave

Click to expand...

I did notice an interesting effect, when the CRTC card and the AH5050 Flier were running together. When the Filer was started with the F1 key, the string of characters displayed were being weirdly modulated with some rectangles, like a miniature 4 block checkerboard, that was changing with time. Maybe that was the periodic interrupt where it was interfering with the AH5050 activities.

Hmm, I think we are on to something here...

Perhaps the AH5050 firmware requires some disable/enable interrupt instructions around some time-critical pieces of code that read/write from/to the disk interface?

Dave