D&N MEM-CM9 problems

[MK14HAK]

Phil is this a wandering TxCLK.?? If I remember correctly, the presence of a TxCLK in the write "window" records a logic 1.
Check /replace the CAP in the TxCLK monostable.
Else did you see any 1s coming from the ACIA TXData at all ?
Does this drive write OK on the C4 ?

[nama]

Hi Mike,
Yes, this drive writes fine on the C4.
I'll try replacing the cap(s), and see if that has any effect. Just to be sure, are you talking about the cap(s) at C8 and C9?
I'll also check the ACIA TXData line again, but I couldn't see anything that looked out of place.

I've still been battling this weird RAM problem. A timely post by Jeff made me realise that I don't actually have a memory issue at $FB.
"Storing anything other than $00 in memory location $FB (zero page) transfers input from the keyboard to the ACIA at $FC00"
However the issue still persists starting $0200. Writing data starting at $0200 has various outcomes. Firstly there is some screen corruption with graphic characters appearing at the end of the instruction line and starting at $0202:

up-arrow.JPG (23.9 KiB) Viewed 13107 times

...and then the machine just freezes at around $021A. Reseting the machine and reading the bytes back show that some of the written bytes stick, but most don't. Common sense says this must be the second RAM chip in the first 2114 pair, however I've replaced both IC's with no change. Still scratching my head over the chips selects. Not sure if I'm just misunderstanding something here, but there certainly seems to be activity on /CS0 even though other /CS lines are active.

Thanks again

Phil

[nama]

Here is a video showing me toggling through the $0400 address space in the OSI monitor while probing the /CS0 and /CS1 lines.
$0400 address means that /CS1 should be enabled and the other /CS lines inactive.

http://www.neoncluster.com/temp_items/M ... OSI_CS.MOV

While I'm doing this the following is true:
/CS0: constant high pulsing
/CS1: high then pulses each time a new address is requested from OSI monitor
/CS2 thu /CS7: high

Phil

[dave]

I missed the detail that you were using the monitor.

When you're using the monitor to alter memory, then the monitor program, as it waits for and processes the keystrokes, updates video, etc., will frequently be accessing page 0 and page 1, which will cause the pulsing activity on /CS0, so the chip select behavior you describe is expected.

Also, it looks like the keyboard routine uses some bytes in page 2 ($0213-$0216), so that could explain some of the behavior.

Is the machine otherwise misbehaving, or just when you write over these locations using the monitor?

Dave

[nama]

Hi Dave, thanks for the reply.
Ok, that's great. I couldn't understand why the /CS0 line was pulsing like that.

The reason I've been thinking I have an issue is the following:
After I fixed the issue with the D&N board with replacing the 74LS27, I put the board back in and saw that I was now only getting 22783 bytes showing in basic. I should get 3xxxx (8K on 502 board + 24k on D&N board). I tried to load the memory test program to test the RAM. This program loads from address $0200. and when I loaded it the system freaked out. Hard to explain how exactly the system behaved, but the screen seemed to slow down and finally freeze, and the PC terminal received the following text:

..........0206/00 2C4
..........8243E9
..........0207/94 8
..........F
..........08976F5
..........63F8DD

Which is not like anything I've seen before, and I've used this program quite a bit in the past, however I have to admit I have not used it on the C2 in it's present config with CEGMON installed.

This is why I decided to look at the 502 board RAM as the possible culprit.
Could this be normal operation for CEGMON, and could the RAM issue be on the D&N board?

Cheers again

Phil

[nama]

Ok, memory problem fixed.
Sorry for being such an idiot.
The problem was a dead 2114 on the D&N board.

Now I get the correct memory in BASIC (31999), and I also know that my memory program (that loads at $200) does not work on this system.
I ended up finding a memory test program in BASIC to find the bad IC...took a while for the program to go through all the addresses, but once it found the bad IC, it was an easy fix.

Again, sorry for being such a fool, and thanks for pointing me in the right direction, I could have been chasing this one for days.

So after that slight shift in focus, I'm back to the disk issue.
I replaced C8 and C9 as suggested by Mike, but that doesn't seem to have changed anything as I still get the bit written to disk.

Phil

[Jeff]

Oh wow. I had almost the same issue this morning. While typing in the monitor characters and graphics were spewing all over the screen. I figured it was ram and probably page zero because it only happened when keys were pressed. Which meant the vectors stored in zero page were likely wandering. I replaced the first two ram chips and all went well again.

While I was diagnosing, I thought about re-seating the syn600 but using the monitor to display its contents and verifying them with a rom dump indicated it was fine.
I would try swapping the ram again unless of course after the first swap you experienced exactly the same behavior.

Good luck!
/Jeff

[dave]

Hi Dave, thanks for the reply.
Ok, that's great. I couldn't understand why the /CS0 line was pulsing like that.

The reason I've been thinking I have an issue is the following:
After I fixed the issue with the D&N board with replacing the 74LS27, I put the board back in and saw that I was now only getting 22783 bytes showing in basic. I should get 3xxxx (8K on 502 board + 24k on D&N board). I tried to load the memory test program to test the RAM. This program loads from address $0200. and when I loaded it the system freaked out. Hard to explain how exactly the system behaved, but the screen seemed to slow down and finally freeze, and the PC terminal received the following text:

..........0206/00 2C4
..........8243E9
..........0207/94 8
..........F
..........08976F5
..........63F8DD

Which is not like anything I've seen before, and I've used this program quite a bit in the past, however I have to admit I have not used it on the C2 in it's present config with CEGMON installed.

This is why I decided to look at the 502 board RAM as the possible culprit.
Could this be normal operation for CEGMON, and could the RAM issue be on the D&N board?

Cheers again

Phil

Hi Phil,

Hmm. I would have to take a look at the memory test program to see if it relies on some feature of the OSI ROMs that Cegmon doesn't match.

Great that you fixed the problem. The clue that it's on the D&N board is that the memory size is greater than 8K, and the BASIC memory test will stop as soon as it stops finding good RAM, so the 502 RAM must have passed the rudimentary memory check.

Regarding the write problem, how are you writing track 0? Are you using the routine from OS65D, or some other routine? If the write and read routines are using different ACIA configurations, that could conceivably cause sync errors (where the word length changes by a bit, causing the timing to be off by 10%, so that a start or stop bit rotates through the word).

Also, what happens if you try to write to, say, track 20 and then read back? Are you able to load OS65D over serial and get it to run?

Dave

[nama]

Hi Dave,
I've been using Mike's Track 0 write utility. this is the same utility that I used on the C4 to get my corrupt OS65D disk up and running.
Writing may be strange, but reading works fine, so I can actually boot from the newly resurrected floppy on the C2. As a test I have tried to duplicate the floppy, but this aways fails on the C2, but works fine on the C4 using the same drive.

I will try as you suggest, using OS65D I will write 00's to track 20 and dump the track back. I'll let you know how I get on.

Cheers

P

[MK14HAK]

Ooops, I will check the Util for bugs and mouse droppings !