• Please review our updated Terms and Rules here

AIM 65/40 repair

4 Volts is fine.

Start the switch playing. This tests each switch and the associated input pin of Z60.

I assume the JBSE link is open?

Dave
 
Sorry for the late reply, I'm gone for the weekend.

Z17's pin 6 showed the desired behaviour with the suggested setup (and some contact cleaner in the switches) and yes, JBSE needs to be opened for this.

I will report back with the Z60 results once I'm back!
 
Back to troubleshooting: all inputs of Z60 look ok, as well as its output. Pin 5 is at 3.5V HIGH but it still works.

EDIT: I didn't like the look of Z75 on the scope and I already had a two failed 54S133F, so I went ahead and replaced it, now the ROM CS looks better.

I now went back to the previous setup (where all the RAM is selected and the ROMs aren't).

Are we going to further check the RAM control signals?
 
Last edited:
I am not proposing to do anything more with the RAM control signals just yet. We will come back to them in due time. I just want to checkout the basic TTL decoding logic first to maximise the use of the NOP generator in one go.

I am not sure what Z75 has to do with the ROM CS though... Is what you are saying that replacing Z75 has made the two (2) /CS lines on the ROMs that were a bit low (voltage levels on the $Axxx and $Bxxx ROMs) now much better?

We are now going to move over to Z75 (and the surrounding logic anyhow)...

If you look at the inputs to Z75, you will observe that the /RAMCS and each of the /ROM chip selects feed into Z75.

Set the ROM and RAM select switches all to OPEN, and check that the inputs to Z75 on pins 7 down to 5 (in the graphic below) are all HIGH.

1747641570134.png

Put your oscilloscope probe 1 on Z61 pin 17 ($Fxxx). This line should be normally HIGH and pulsing LOW as we have seen previously. We will use this as our trigger.

Use your oscilloscope probe 2 to look at Z44 pins 9, 10 and 11 in turn. You should observe mainly HIGH signals but pulsing LOW. The LOW activity should be within the period of time that the channel 1 signal is LOW.

Put your oscilloscope probe 2 on Z45 pin 6. This signal should be normally LOW and pulse HIGH during the channel 1 window. This signal is called DISROM. Part of the $Fxxxx ROM is disabled to allow access to the I/O devices. We are checking that this logic is working correctly.

If you now move oscilloscope probe 2 over to Z80 pin 8 you should observe that this signal should go LOW when the $Fxxx ROM is selected, but go HIGH when the ROM should be disabled to allow CPU access to the I/O ports.

If this looks OK, we can check out Z75 next.

Dave
 
Last edited:
I will post the next bit of our journey, because I have a whole day of meetings to attend...

Oscilloscope channel 2 on Z75 pin 9.

With all of the ROM and RAM selection switches OFF (open).

You should observe Z75 pin 9 as LOW but pulsing to HIGH occasionally (as the ROM is disabled).

Switch each ROM selection switch ON and note that an extra pulse appears on Z75 pin 9. Turn the switch OFF again.

Do the same with the RAM selection switches one at a time (ON and then OFF).

You should observe some extra Z75 pin 9 activity when each ROM or RAM selection switch is turned ON.

Finally, move probe 2 to Z46 pin 8. This should be the same activity as Z75 pin 9 - but 'modulated' with the /PHI2 clock - i.e. for Z46 pin 8 to be LOW, Z75 pin 9 has to be LOW coincident with the /PHI2 clock being LOW.

Check Z69 pin 4 for a permanent HIGH. The NOP generator should be reading only, so we can't check this signal (yet), but we can confirm that it should be a the correct static level...

We then move on to the I/O device chip selects and Z79 next...

Dave
 
The I/O device chip select pins are quite simple.

Check for activity on the following pins:

Z62 pin 24. Mainly LOW, pulsing HIGH.

Z1 pin 24. Mainly LOW, pulsing HIGH.

Z2 pin 3. Mainly HIGH, pulsing LOW.

Z5 pin 23. Manly HIGH, pulsing LOW.

Sorry, there is a lot here, so I will let you catch up with the readings...

Dave
 
Thanks Dave, I came as far as here:

daver2 said:
am not sure what Z75 has to do with the ROM CS though... Is what you are saying that replacing Z75 has made the two (2) /CS lines on the ROMs that were a bit low (voltage levels on the $Axxx and $Bxxx ROMs) now much better?
Click to expand...
Yes, that is correct
daver2 said:
Put your oscilloscope probe 1 on Z61 pin 17 ($Fxxx). This line should be normally HIGH and pulsing LOW as we have seen previously. We will use this as our trigger.

Use your oscilloscope probe 2 to look at Z44 pins 9, 10 and 11 in turn. You should observe mainly HIGH signals but pulsing LOW. The LOW activity should be within the period of time that the channel 1 signal is LOW.
Click to expand...
The LOW activity is a small blip and the end of the low going pulse on CH1, for Z44 pins 9-11 (the dotted line is for CH2 0V)
20250519_133458.jpg

daver2 said:
Put your oscilloscope probe 2 on Z45 pin 6. This signal should be normally LOW and pulse HIGH during the channel 1 window. This signal is called DISROM. Part of the $Fxxxx ROM is disabled to allow access to the I/O devices. We are checking that this logic is working correctly.
Click to expand...
This is a small blip too but inverted

daver2 said:
If you now move oscilloscope probe 2 over to Z80 pin 8 you should observe that this signal should go LOW when the $Fxxx ROM is selected, but go HIGH when the ROM should be disabled to allow CPU access to the I/O ports.
Click to expand...
Looks like, it is the same width as the address decoder pulse (or assume the blip at the end is in order, I can't see the difference because its at the end)

Let me know if I can already proceed with the rest and the situation on Z44 9-11 is as desired
 
Yes, please proceed.

The resolution will be quite difficult given your oscilloscope.

There may be something we can do with the oscilloscope timebase settings to improve things - but the fact that there is a small 'blip' of the correct sense round about where I would expect it to be gives me hope that the logic is doing what it is supposed to...

Dave
 
Alright, if you're telling me that the IO select is happening at the end of the address range then I think it looks good (including the tests in #106 and #107).

I can see the signals but some of them are nearly impossible to take a good picture of (unless I darken the room, setup a tripod etc.)
 
The I/O ROM is selected from $F000 to $FFFF. The I/O is located at:

1747659823610.png

So pretty much from $FF80 upwards (but NOT overlapping the reset, NMI, SWI vectors that are right at the top of memory).

EDIT: There is an error in the last bit of the text above. The latter reference to 'Y5' should be 'Y6'.

The address $FFEx and $FFFx (effectively the unused Y7 output from Z44) are allocated to the I/O ROM itself - and are used by the 6502 CPU to access the restart vectors.

Dave
 
Last edited:
daver2 said:
The I/O device chip select pins are quite simple.

Check for activity on the following pins:

Z62 pin 24. Mainly LOW, pulsing HIGH.

Z1 pin 24. Mainly LOW, pulsing HIGH.

Z2 pin 3. Mainly HIGH, pulsing LOW.

Z5 pin 23. Manly HIGH, pulsing LOW.

Sorry, there is a lot here, so I will let you catch up with the readings...

Dave
Click to expand...
Hi Dave, this checks out, as do the signals on the previous post. Except:
daver2 said:
Finally, move probe 2 to Z46 pin 8. This should be the same activity as Z75 pin 9 - but 'modulated' with the /PHI2 clock - i.e. for Z46 pin 8 to be LOW, Z75 pin 9 has to be LOW coincident with the /PHI2 clock being LOW.
Click to expand...
20250609_140651.jpg

Lower trace is Z75 pin 9 (coincides with /PHI2), upper trace is Z46 pin 8. It doesn't go low as the others do, it just has this very short pulse

This is with all switches ON - it should look the same on all pins, right?
 
I think what your oscilloscope trace is showing is correct. The logic state I described is (I think) correct - it is just the inverse of how I thought things were working...

Z46/8 goes LOW to enable the bus driver (Z11).

However, Z11 drives the data bus from an external source, so must be DISABLED (Z46/8 set HIGH) when the CPU wishes to read from on-board devices - such as the ROM, RAM and I/O devices - basically any access to an on-board resource.

When /PHI2 goes HIGH (Z46/10) this will set the output (Z46/8) HIGH and disables the bus driver (Z11).

Likewise, when Z75/9 goes HIGH (i.e. any of the inputs to Z75 goes LOW) this will also set the output (Z46/8) HIGH and also disables the bus driver (Z11).

I can, therefore, see that Z46/8 will only go LOW when no on-board RAM, ROM or I/O device is being accessed - i.e. a fairly narrow low pulse (which is what you are observing).

I think this is correct.

I will check it again tomorrow and see if it still makes sense to me :)!

Dave
 
I assume you have now done everything in posts #105, #106 and #107? Yes?

I am just debating the next step.

I am thinking about a simple test program (to replace Z73 at address $Fxxxx) to send a message out of the ACIA serial port to say hello.

If we can get this to work, we can see if we can get the serial port to echo characters (receive and transmit).

From there, we could start to add functionality to test the RAM, ROM, display, etc.

If we can't get the simple program to work - perhaps it might help us in further debugging?

What do you think?

EDIT: I have written a 'first cut' of some source that initialises the ACIA, outputs a text message, enters a loop to echo any character entered via the ACIA receiver back to the ACIA transmitter.

Dave
 
Last edited:
Great idea.. I think the RAM control circuit is still defective, at least I wasn't able to write to it and the DOx lines are floating.

All the checks from #105-107 have been done to the best of my knowledge (note here: the RAM selection switches, especially 6 through B are still a bit oxidized)

Something that executes from ROM and tries to make the machine communicate sounds like a good way to make sure at least that part is working.

I know *very little* 6502 assembly, but would probably need some help or study the book how to program the serial port

I was also thinking of getting one of these, to have some sort of logic analyzer https://github.com/gusmanb/logicanalyzer
 
You must log in or register to reply here.
Back
Top