600D replica problem (test 6)

[Mark]

I was curious to see what would happen without a system ROM installed.
Without any ROM to set the data lines, the 6502 would probably read the high order address byte as data, (I call this a "NULL Read").
The reset vector would indicate the starting address as $FFFF and the instruction the 6502 would read is $FF, an invalid instruction. However $FF is one of the "undocumented" opcodes known as "ISB" a dual increment and subtract with carry Absolute,X 3-byte instruction.
So the 3 byte instruction fetch would wrap and read data from $00 and $01, random uninitialized RAM, add 'X' and read data from the address it was pointing to and perform the INC and SBC and write to that address, then continue executing from RAM location 2 and so on with who knows what?
(How the undocumented opcodes function depend on which version of 6502 is running...)

So some zero page accesses would be expected right after RESET without a ROM. Afterwards it depends on what in located in RAM. Executing any of the "HLT" instructions would stop bus access ($02,$12,$22,$32,$42,$52,$62,$72,$92,$B2,$D2,$F2) locking up the processor.

[andrewh]

You've mainly lost me there. However, I have worked out how to set triggers on my scope, so I have more information.

Powering on (or pressing BREAK) produces some cycles on the address and data lines. I see a 0V pulse on the ACIA on pin 9 and it goes back to 4V. On the RAM, I see 3 pulses on pin 8 and 1 on pin 10. Does this suggest the problem lies in U16-23?

[Mark]

Good news you can track signal activity! Yes, it could be problems with chip select logic. But there should be much more activity....

What system ROM data/image are you using?
Can you post the contents and/or verify it is what you think it is?
The behavior you are seeing doesn't match what I think the ROM should be doing.

If it's easy for you to program, perhaps we could come up with something that can test the system a little more thoroughly without needing RAM

Re: previous message -- It's just what the CPU would do without a ROM installed, wrap to zero page & start executing random instructions & accessing random memory locations. Not all of the 256 possible instructions on a 6502 are intentional, some are side effects of the way the 6502 was designed & perform weird combinations of other instructions. Some were used in later versions of 6502 to perform useful things.

[andrewh]

The ROMs came from https://github.com/jefftranter/6502/tre ... board/roms. I have just swapped, reprogrammed and verified CHARGEN and SYN600 with no effect, so I know they are both good. It's easy for me to program ROMs.

[Mark]

I have created an assembly file for the SYN600 that will compile with A65 to the same binary as the active area in the original ROM with a minor change. It changes the order of the screen clear and ACIA reset, so it should erase the screen before relying on stack. Other than that it should work identically to the original SYN600 in a C1P except for one change.

In the unused space at the start of the ROM ($F800-$FBFF) I began writing test routines. For now, I'm just testing page 0 and 1 of RAM with a very simple test, but it could be expanded to any number of tests. If a failure is detected, it will fill the screen with a BAD RAM message in a continuous loop. It doesn't rely on having working memory so you should see something even if no memory is installed.

So the trick is, in this version the SYN600 NMI vector is relocated to $F800. Thus to enter the test you need to bring pin 6 of the 6502 low to trigger an NMI. If the test passes, you should end up in the ROM monitor. It doesn't exit from the interrupt, as it is just for debugging at this point. By entering the ROM monitor on success it will bypass the need for BASIC ROMS to be installed.

I've included the syn600 source & my changes along with a test.bin ROM file to try. To make this I just ran "a65 -b file.asm" on each asm part, then used "copy /b synmds.bin + syn600b.bin test.bin" to create the ROM image.
You could change the reset vector at the end of the SYN600 to $f800 to run the ram test on reset before returning to $FF00 to run normal reset if you wish. The RAM test should be safely nondestructive.

Good Luck,
-Mark

[andrewh]

Your ROM produced the attached screenshot. This is a different set of random characters to before. Shorting pin 6 to ground had no effect.

It has many many years since I wrote assembler so I think my attempt to change the reset vector was wrong. However, it appeared to go into some kind of loop, so it seems to be doing something.

Apologies for my ignorance on this update!

[Mark]

Progress!
The screen clear writes $20 to the screen. The screen is mostly displaying $28. It looks like the data line D3 is not making it to video ram (U25?). The other characters displayed also seem to have D3 set. Check pins 12,14 6502 side and pin 13 U25 (8T28) which goes to pin 11 U39 (2114) video side and the CHAR GEN (A6/ pin2?).
It looks like U74 is used for color RAM U77 which also connects to the D0-D3 data bus may not be needed to be installed for now.

The screen fill indicates the CPU can read the ROM contents correctly.

If you swap the 8T28 U24 & U25 does it change? Or U39 & U40?

To set the reset vector change $FF to $F8 in the binary test.bin at $07FD (3 bytes from the end). Or use a ~470 ohm resistor to connect 6502 NMI (pin 6) to GND (pin1) to trigger NMI -- if the processor hasn't locked up. It will just cause a jump to $F800 which tests the 1st two pages of memory & jumps to the ROM monitor on success.

[andrewh]

No change if I swap U24/25 or U39/40. 470 ohms between pin 6 and ground still has no effect. U74 is not installed.

I'll have to leave it until tomorrow to continue. Just to be clear, what am I checking for on those pins?

[Mark]

Oh, so the problem is why when writing $20 to video RAM is it displaying $28 instead? Data line D3 is either written high instead of low to video RAM, or video circuit is reading $20 as $28 (D3 high) when displaying characters. (The signal could be open and just floating high or it could be shorted to something or driver could be bad or RAM bad (swapping buffer & RAM chips without effect would discount the last two possibilities.) The pins listed all involve D3.
The fact that the system seems to crash after the subroutine call to initialize ACIA probably means that reading or writing to system memory is bad too. (The return from subroutine call needs a working stack @ $01xx to return to the ROM to continue execution.)
The 6502 seems to be able to read the ROM okay since it fills the display, which is good.

[Mark]

I've update the test routines in the empty space of the SNY600 ROM
It now does a screen clear, tests low RAM (pages 0 & 1) displaying the address of the error encountered,
then it displays the full character set from $00 to $FF
then enters a keyboard matrix display routine where it will light a square when a key is pressed
You can exit to ROM Monitor with CTRL+C
Hopefully the screen information isn't lost in overscan...

This is all done in ROM without using any RAM at all (except display memory for screen updates).
Basically anything that would use storage or loops is unwound making for inefficient code.

Further improvements could use the ACIA, change screen width, provide more information on RAM failure...

The test.bin version I'm including has the RESET vector replaced with an entry to the test routine at $F800.
To Run normal system reset code, enter the ROM monitor & type '.FF00G'
Change the last 'F8' in the test.bin binary file to FF to restore normal reset.

The lite square in the keyboard test is the capslock key. Then other keys are pressed & finally enter CTRL+C to exit.

Test Screen

C1diag.gif (3.77 KiB) Viewed 1552 times