Dwight Elvey
Veteran Member
Hi All
I'm sorry I've not had a chance to reply. Monday night, I went to bed with a fever. I'd caught the latest version of Covid. I've had it once so there is nothing to the statement that once you've had it you are immune. I'd had the full series of 5 shots but didn't go back for the latest variant shot. My mistake.
I'm mostly over it now, some sniffles is all.
Anyway, the code images on the web page are correct. If you build the diagnostic, I should note that if you run the RAM test and it tells you every other RAM is bad, it is more likely that the main selects for the RAM are the problem and not necessarily one of the RAMs. That would need to be fixed, first.
I use a pattern of 10101010 and 01010101 for the RAM test so if the buss stays at 1 or 0 it will indicate alternate RAMs as failing. I didn't think about this when I wrote the instructions, please forgive me. As you may have guessed, the RAM test is like a chicken and egg problem.You can't use the RAM until you've tested it and the 6502 loves to use the RAM as pointers. This meant that the entire RAM test needed to run in the processors registers. It needed to read/write and report failures using only those registers.
If you look at the sections of the EPROM data, there are two that are mostly the code that goes into the 6530 ROMs on the KIM. It is a problem that I can only address 1K of code at a time, when the debug board is used. I still need to boot to a valid code address and have the code for the EEPROM used on my replacement modules.
This means the reset address at the end of the EPROM 1K block needs to boot to a valid debug code address. So, the 1K block that is the ROM image is complete except the boot address, that is in RAM instead. This was loaded by the previous EPROM 1K block into RAM. When I write to the EEPROM, I patch the correct boot address.
So, you can use the data in the second EPROM block,knowing that the boot address is wrong.
I hope this makes sense.It took me some time to figure the simplest way to solve the boot address issue. I could have done it one half at a time but this was less work so I did less in making the debug EPROM.
The select pins on the 6530 chips are decoded on the 6530 for two different purposes. The main CE is only for the ROM part while the other two CSs are for the 64 byte RAM and the I/O. I believe one can dump the ROM data with just CE, address and the clock. The other two CS pins are different for the -002 and -003 for their I/O and RAM functions.
Dwight
I'm sorry I've not had a chance to reply. Monday night, I went to bed with a fever. I'd caught the latest version of Covid. I've had it once so there is nothing to the statement that once you've had it you are immune. I'd had the full series of 5 shots but didn't go back for the latest variant shot. My mistake.
I'm mostly over it now, some sniffles is all.
Anyway, the code images on the web page are correct. If you build the diagnostic, I should note that if you run the RAM test and it tells you every other RAM is bad, it is more likely that the main selects for the RAM are the problem and not necessarily one of the RAMs. That would need to be fixed, first.
I use a pattern of 10101010 and 01010101 for the RAM test so if the buss stays at 1 or 0 it will indicate alternate RAMs as failing. I didn't think about this when I wrote the instructions, please forgive me. As you may have guessed, the RAM test is like a chicken and egg problem.You can't use the RAM until you've tested it and the 6502 loves to use the RAM as pointers. This meant that the entire RAM test needed to run in the processors registers. It needed to read/write and report failures using only those registers.
If you look at the sections of the EPROM data, there are two that are mostly the code that goes into the 6530 ROMs on the KIM. It is a problem that I can only address 1K of code at a time, when the debug board is used. I still need to boot to a valid code address and have the code for the EEPROM used on my replacement modules.
This means the reset address at the end of the EPROM 1K block needs to boot to a valid debug code address. So, the 1K block that is the ROM image is complete except the boot address, that is in RAM instead. This was loaded by the previous EPROM 1K block into RAM. When I write to the EEPROM, I patch the correct boot address.
So, you can use the data in the second EPROM block,knowing that the boot address is wrong.
I hope this makes sense.It took me some time to figure the simplest way to solve the boot address issue. I could have done it one half at a time but this was less work so I did less in making the debug EPROM.
The select pins on the 6530 chips are decoded on the 6530 for two different purposes. The main CE is only for the ROM part while the other two CSs are for the 64 byte RAM and the I/O. I believe one can dump the ROM data with just CE, address and the clock. The other two CS pins are different for the -002 and -003 for their I/O and RAM functions.
Dwight