DRAM 128K system has stopped working

[CheshireNoir]

Thanks Ewan!
I've checked my stockpile and I don't have anything similar. I'll have to drop in on Jaycar on the weekend I guess :-)
I gather that it's OK to substitute an Electrolytic in this case? This should do? https://www.jaycar.com.au/680nf-50vdc-lo...r/p/RL6412

Cheers!

Chesh

[someone]

Someone's connection to the site is a bit wobbly and has been losing posts.

Your video and photos show that your machine is booting up from ROM from Power up by the presence of a video image with a valid string message.

Only a power up event should negate /RESET, there should be nothing to assert it.
/NMI is generated as a very short pulse from a keyboard reset/release event.
These are done as not to corrupt the current DRAM contents by missing any refresh cycles.

The Memory Test ROM relies upon a fully working CHAR RAM.  If it is not fully working it may screw up!

[Ernest]

Have you tried powering up while holding down the "G" key this should initiate the MEM test for the 128K DRAM board? AS the TEST ROM is capable of testing various different systems.
Alternately doing the same when RESETing.

Ernest

[CheshireNoir]

Thanks Ernest and someone.
I'll try holding down G on Thursday when I have some time to work on it. (Tonight was silly videogames and tomorrow I'm going to hang out at the local Maker's space)

someone, are you suspecting CHARRAM may be the issue? The system isn't booting to any of those strings by default. I get a "no video synch" state. They only appear after I press RESET. Once they appear, the system doesn't do any more and the graphics seem to flicker like crazy.

Hopefully on Thursday I'll also have that capacitor I need.

Cheers and thanks for everyone helping here. BTW, this is the same power supply as before. I understand the 'bee can be sensitive to power supply changes?

Chesh

[Ernest]

The flickering will be because the video RAM is being written too while it is displaying rather than during retrace. 
It is possible you have several issues here.
1) not reseting automatically at power up.
2) not accessing the video memory correctly.
3) not initialising the 6545 correctly.
4) timing signal lost somewhere.
5) or any combination of the above.

What version/revision Mainboard is this Coreboard sitting on?

Ernest

[someone]

someone, are you suspecting CHARRAM may be the issue? The system isn't booting to any of those strings by default. I get a "no video synch" state. They only appear after I press RESET. Once they appear, the system doesn't do any more and the graphics seem to flicker like crazy.

Just stipulating that this particular Memory Test is reliant upon working CHAR RAM and is a possible cause until discounted.

Some signs of life is a good thing!
The CPU is able to configure the CRTC & write some strings correctly.
However the preceding clear screen seems to have failed.
(Note: The continual flickering on the screen is probably due to the CPU continuously accessing the Video memory).

Just for you info the screen should look like this:
   

Your photos indicate that the CLS clear screen routine is probably writing corrupted bytes writing '(' [0x28] instead of ' ' [0x20] for the LDIR being used to do so.
i.e unwantedly setting bit 3.

So you'll need to find its root cause.
Here's some information that may help you:
As a part of the CLS routine, the ROM writes a space character to the CHAR RAM at beginning of (left corner) of the CHAR RAM and then performs an LDIR to fill the remainder of the screen. It appears the initial LDI read from the CHAR RAM is reading back a 0x28 instead of 0x20 thus filling the screen with the wrong value from that point onwards.

Assuming that CHAR RAM writes are working correctly and the LDIR is commencing at the correct source address, it could be the CPU reading from CHAR RAM may be problematic.
It's possible the CHAR RAM is fine (because the strings are being displayed correctly) but the associated data transceiver (IC11) has a broken bit 3.
This could also explain why the microbee goes haywire because the Test ROM uses the CHAR RAM as its stack storage space and is reading some wrong values (with bit 3 being set).

Tracking down the source of the unwanted value would be a good start.
Writing your own temporary Test Case ROM is a viable option because it requires no modifications to your Bee.
If you do so, try to use code that doesn't rely upon the stack or other stored variables.
This is the beauty of the Z80 over the 6502 because it doesn't need working RAM to operate.

As for the initial POJ, you'll have to sort that out too. At least you've got your keyboard reset working to execute the ROM program.

[CheshireNoir]

Whoah! Many answers!
Thanks again someone and Ernest. I was planning on working on this tomorrow night but I'm working on it tonight to see if I can get ahead.
Ernest, the base board is marked 1248-4-02W. I have not yet checked what (if any) mods have been done to this, other than the conversion I did to DRAM.
someone, I probed around IC11 and l can see it properly inverting on pins. I even plugged in the second probe on my scope to check. (Pin 1 High, Pin 3 Floating, Pin 5 data, Pin 8 High, Pin 10 High, Pin 12 data)
I'll start thinking about how to code up a test. I had an idea how to do the mem test, but I'm not sure for the test you're proposing.

I've just got a new handpiece for my desoldering station, so I'm ready to desolder chips and test them apart from the main unit if needed.

Cheers!


Chesh

[Ernest]

I would have thought that as the "Universal RAM Test for microbee v2.12" is displayed correctly that would show IC 11 as functioning correctly.
I would think that IC14 would be a more likely candidate.

Not sure why you chose to check pins 5 & 12, 15 is the associated pin with 5, maybe a typo?

I guess if you wrote a walking bit test program to test the CHAR RAM you could quickly confirm if the hypothesis of a problem with bit3 is correct.

Ernest

[CheshireNoir]

:-)
I just tried all the inputs and outputs, (Pin 3 is NC as far as I can tell from my reading of the schematics, thus floating) but only listed the inputs as the outputs are just inverted.

Yeah, I don't know what I'm doing :-D

Chesh

[someone]

:-)
I just tried all the inputs and outputs, (Pin 3 is NC as far as I can tell from my reading of the schematics, thus floating) but only listed the inputs as the outputs are just inverted.

Yeah, I don't know what I'm doing :-D

Chesh

The suspect data bit 3 is on pin 5 (according to the 1248 schematic).
To see if the data bit transceiver bit is working correctly you'll need to compare both sides of the transceiver simultaneously when transceiver is enabled and the direction pin is set for reading.  There should be no inversions of the signals - the should match.

I would have thought that as the "Universal RAM Test for microbee v2.12" is displayed correctly that would show IC 11 as functioning correctly.
I would think that IC14 would be a more likely candidate.

IC11 is the transceiver between the CHAR RAM and system bus.  The schematic has its bus connector slanted backwards giving a false impression of the source of the signal.
IC14 is the transceiver between the FONTROM & PCG RAM to the system bus.

From the photo and videos IC11 seems to be working for writing but may be broken for reading.


As for writing a test ROM, it's pretty easy.
In this case , just use the beginning CRTC init routine followed by whatever test you want.
Keep your first test very simple and specific at first even if it is just a confidence test to see if you've written the ROM correctly.
Even just getting the CRTC initialised correctly is a great first attempt.
Usually, to learn, someone would init the PIO and turn a connected LED on or off.
In this case we know the CRTC initialisation is working so we can adventure a little further.

If you can, write the code so there is no reliance upon any RAM/STACK whatsoever. There's enough CPU registers to do that.
It's recommend to terminate the test code with a JR 0FEH to terminate the test program in a perpetual loop.