ReAmiga 1200 build CIA problem

[imqqmi]

Hi!

I've been working on my PAL ReAmiga 1200 build for the last couple of weeks. I've managed to get it running in so far that DiagROM runs (v1.3 21-04-2023), there's video output. I'm at part 4 of Chuckys build guide at the point of checking CIAs. But when it comes to testing the CIAs it gives a failure on the _VSYNC  part (it reads 0 ticks and should be around 98).

What I've done/tried:
- Checked for shorts more times I'd like to remember
- Swapped the CIAs but the problem doesn't move to HSYNC, the exact same problem remains and no other change can be observed as far as I know
- Used oscilloscope to check signals, 709khz clock is there, 50Hz vsync is there, levels are good, no weird distortions in the wave form, just clean digital signal.
- Tried without monitor connected, just used serial port connection
- Made sure the traces are ok and low impedance.
- Reflowed both CIAs pins
- When doing the CIA test, it reads correct number of ticks for other tests, so communication should be ok.
- CIAs are NOS
- Checked for short between _odd_cia and _even_cia, no short
- Checked _int2, there's no trigger, but I'm not sure if this is normal or not.

I've ordered more CIAs to try to solve the issue, but swapping didn't make a difference. Is there anything else I can check? Any help would be greatly appreciated!

Thanks!
Imqqmi

[Castellen]

Doesn't make a lot of sense, that fault is usually caused by a missing 50Hz VSYNC signal or defective CIA as you say.  From memory, it won't be generating any interrupts in that state, so no activity on INT2 is probably normal at that point.  You should see one strobe on INT2 when you run the interrupt tests however.

If you look at ODD_CIA (the enable line) while the CIA tests are in progress, do you see that strobing low normally?  You should see a lot of short duration active low pulses around 1uS in duration.

Do you see valid bus activity on *all* data and address lines at U7?  Should be there all of the time regardless of what else is happening.

Do the I/O tests relating to that CIA work?  i.e. Does the keyboard work and is the parallel port test successful?

[imqqmi]

Hi Castellen,

Thank you for your input!

I've probed:
- All 4 address lines > activity
- All 8 data lines > activity
- _ODD_CIA (_CS pin 25) 150Hz activity bumping up to 60+khz during tests 1us pulses pulling low confirmed
- _E has 709Khz regular signal, this is there all the time, even without tests
- _CS has 67Khz random signal
- _VSYNC has 50Hz
- _W has activity
- LED line is actively switched on/off so it's writing successfully to U7

INT2 is low on boot and only goes high when I run the CIA test and stays high no matter how many CIA/IRQ tests I run. The IRQ test has no effect on INT2.

I haven't soldered the connectors for parallel port and keyboard yet. I'm waiting for the PLCC sockets to arrive, then it's easier to swap the CIAs without de/soldering. 

[khayoz]

@imqqmi

I suggest you send a P.M./mail to Chucky and he will probably figure it out
as he did not just design the board but build a lot of these boards and
know what to look out for.

[imqqmi]

Hi Khayoz!

Thanks for the suggestion, I've mailed Chucky (I assume the member with that name is the one and same person). Hopefully he has some ideas as to what's wrong with the CIA or surrounding components.

I've managed to add a hard disk connector and boot from a CF card with Amiga Test Kit. See screenshot. It returns 10149055 (always the same number, binary 1001 1010 1101 1100 1011 1111). I was thinking maybe it didn't get the reset signal but it does. Not sure why it reads this value instead of 16. There's no discernable noise to that extent on the _VSYNC signal.

[Castellen]

Those measurements mostly look OK, and while it still sounds like a CIA fault, swapping them and not fixing it doesn't add up.  I can't remember exactly what INT2 does with the DiagROM interrupt test function.  Will have a look when I get a spare moment to set up a test machine.  Or you could do the same thing if you have another machine about, it'll work exactly the same on an A500 for example.

[imqqmi]

I've had contact with Chucky. He said that the INT2 behaviour is not as designed on the latest build of DiagRom, ie there's a bug that needs fixing as I understand it. There's no INT2 changes so that I can't measure them checks out. But this shouldn't affect the test itself though.
Chucky asked me to measure the signal on the _E signal on the pin of the IC and not the pad (as it may have a problematic soldering joint). As you can see in the attached image, the signal looks fine.

Chucky is also stumped by the problem. I've ordered 4 more CIAs and smd PLCC sockets that should arrive somewhere next week. I'll swap out the CIAs and see if that resolves the issue.
I've done more measurements and communication seems fine, I've looked at the _E, _W and _CIA_ODD chip select lines with two channels triggering on _W and _cia_odd and all seem as it should and there's no observable difference between CIA odd or even.
I haven't done any measurements with more channels, I've soldered on wires to break out the signals. I've ordered some micro probe clips to make it easier for more fault finding with 4 channels. I really feel the need for a logic analyser right now, because I can then record a few seconds and see what's going on exactly. Maybe one day
I've checked if the CS lines of odd and even are enabled at the same time for example, which wasn't the case either. I was thinking maybe two devices are active at the same time giving read errors.
I've experimented with shorted address and data pins on purpose, the machine would crash immediately so there shouldn't be any short if the machine doesn't crash. I noticed that the CIA_ODD is on different address lines compared to  CIA_EVEN, that's the only real difference that could be common between two chips being swapped. But so far I haven't found anything that could indicate a problem.

The only difference is that when it reads from the TOD register the values are not as expected. It could be a localized fault within that register under a certain configuration. Also, I may have made a mistake in swapping them while thinking it was swapped but it actually wasn't. Since they are soldered to the board now swapping them is a hassle so I'll wait for the sockets to arrive.

I do have an Amiga 500, but I don't have diagrom for that. But I could take some measurements with Amiga test kit active.

I'm not sure if it's significant, but the printed text on what now is the odd cia is partially wiped off. All I did was use a cotton swab with 99% alcohol on it to clean flux off. It could be a much older IC than the other one I have, which is also printed much clearer. I bought one from ebay and the other as NOS from amibay. Maybe the ebay one was from a questionable source. The other 4 on order also come from amibay as well (same source). Maybe there's different revisions floating on the internet.

I'll let you know when the new CIAs arrive and tested on the ReAmiga build.

[Castellen]

He said that the INT2 behaviour is not as designed on the latest build of DiagRom, ie there's a bug that needs fixing as I understand it. There's no INT2 changes so that I can't measure them checks out. But this shouldn't affect the test itself though.

I've just had a quick look at DiagROM v1.3 on an A500 and I'd agree that the interrupt test doesn't appear to be working correctly.  INT2 and INT6 stay high all of the time despite the tests showing as passed, which is consistent with what you're seeing.  And I'd agree this won't affect what you're seeing with the timer issue anyway, the timer tests use polled results and don't rely on interrupts.

The most likely explanation at this point is still a bad CIA.  See how things go with a known good 8520.

[imqqmi]

Thank you for confirming Castellen!

I've fixed an issue with not being able to start workbench. Turns out I had to install workbench.library from cloanto's download section and put it in the libs folder as it seems this isn't included in my terrible fire TF1230 roms. I've extracted the roms and put it in WinUAE and could reproduce the issue.
I wanted to do a clean install of WB 3.1 but the same issue arose, the installer disk didn't boot into workbench. I've solved it by using powerpacker and compressed some large apps on the disk using my WinUAE WB setup with Directory Opus, where I've got one of the buttons defined to run ppdo, then there was enough disk space to include workbench.library as well as powerpacker.library. It got through the install for the largest part. Just an error with some locale files that I don't use anyway. There's probably a better way to do it but this is what I came up with.

Anyway, workbench seems to work fine now, added the TF1230, I've ran scenery animator and delitracker and all seems to be working great (Haven't heard the sound output as the connectors aren't soldered in yet, but the oscilloscope showed an audio signal on the opamp and the quad scopes showed waveforms). I'm not sure what would need the odd cia TOD to work. Would that be the RTC? Or maybe some games/demo's that use it?

Another issue crops up, which is something that was there for a while, the boot screen with the floppy inserting into the drive and the checkmark logo, booting into wb with the shell window visible and finally booting into workbench, the screen is really dark.
If I look at a luminance slider in Prefs, about the bottom half is dark, then the brightness smoothly increases. ie luminance 0-127 is black, 127 to 255 fades into 'full' brightness. It's so dark that the purple color of the boot screen is black.
The funny thing is that in the Scenery Animator screen the brightness is normal. I use a DB23 to scart cable bought from Amigastore.eu.

See attached image. The darkening isn't the product of a fast shutter speed of the phone camera, it's visible to the naked eye.

I'm using an ADV101 dac in the ReAmiga1200. I'm using an LM385-1.2V SOIC-8 vref. I've added the necessary resistor on the bottom layer of the PCB. I've removed the 100 ohm resistors that goes to the VGA connector as the build guide states that brightness takes a small hit when adding those in. That did help the brightness a little but not by much.
I've used this diode (MMBD7000HC-7-F mouser code) as protection diode substitute for 1N914 D231a-D233b. I've temporarily removed one pair but it had no effect on the colour. I've checked diode polarity and it measured correct with multimeter in diode mode about 0.6V voltage drop.

[Castellen]

Regarding the CIA timer, that's a hardware timer which different software might use.  I don't know exactly what software uses it specifically, your mileage might vary without this timer working as it should.

Regarding the dark video issue, it's likely to be something affecting the video DAC as you've guessed.  I'd start with checking the DC voltages on U30 pins 17, 18, 19.  I've scanned some of my service notes, attached, which includes references from a normally working machine.  Also check you have the impedance matching resistors (25 and 50 Ohm ones) correctly placed on the three RGB outputs.

Failing that, compare voltages and levels with a normally working machine and you should be able to track it down fairly quickly.

[imqqmi]

Still waiting for the CIAs and sockets to arrive. Agreed, though the ToD (time of day) module seems to be rarely used on U7 as far as I know. I will test it with a good CIA and this one with several games and applications and see if it makes a difference. I thought it might be used by music module player code for example but it seems to work.

I've tried replacing the DAC (I tried 2 others) but that didn't solve the issue. The DACs I got from Aliexpress were desoldered ones and some have other problems I discovered (but not really surprising) like a 'stripey' blue color and ghosting and changing stripes and ghosting when I touch the DAC. I have 1 NOS which seemed to produce the most stable image.

From memory Comp on pin 17 was about 2.5V with multimeter instead of 3.5V according to your annotations (thanks btw!). Not sure what could cause this aside from a bad dac. Maybe the resistor value is off, I'll need to check. It's compensation for ringing on sharp edges according to the ADV101 datasheet, and the picture, aside from that it's dark, seems clear around edges aside from the blurry 1084 RGB crt that I have.

25 and 50 ohm were checked and confirmed in the correct position and value. I've added traces of the DAC output (measured on the clamping diodes D231+ etc diodes), see attachments. With the thick bright line low in scenery animator (picture looks normal brightness) and workbench it's high (looks too dark). It's as though something is inverted between these two screens, ie black level is different or something. It's 5V pp though not 500mv, but it was measured on the dac side, not the connector. I checked the oscilloscope; probe and 'scope both are set to 10x. 5V pp would definitely a problem. I'll look into it.
I'll also try my TV and see if this isn't a cable or CRT issue. The store bought cable is filled with hotglue, it's difficult to make out the pin out. I do have some DB23 connectors from back in the day, I could solder one myself and see if that solves anything. I'll have to lookup the correct DB23 -> scart schematic for the correct resistor placement and switch pin etc.

The RGB bar test in DiagRom looks good, see attached image. The phone made the green a bit bluer than it really is. As soon as I insert a Kickstart rom (be it the original commodore part or the TF1230 with IDE drivers) the WB screen is dark. I've deleted the prefs files so it loads default values but made no difference. I've checked to see if all the RGB bits are twiddling on the dac and they are both when Scenery Animator or Amos is active and in WB, but just very dark. Could there be Kickstart differences depending on what DAC or revision chipset I have? Maybe I've got a mismatch in revisions or something?

I'll take some measurements tomorrow. Thanks again for your input Castellen!

[imqqmi]

Update on the CIA problem. I've received the sockets and swapped the CIAs and indeed the problem moves, so that's a good sign! All I need to do now is wait for the other CIAs to arrive and this part should now be working.

I haven't had time to take measurements for the DAC but as soon as I am able, I'll report back.

[Castellen]

Update on the CIA problem. I've received the sockets and swapped the CIAs and indeed the problem moves

OK, that explains the confusion then.  When you swapped the two 8520s last time, you didn't actually swap them at all, hence the fault remain unchanged.


The RGB test on that monitor looks too dark.  I'd suspect it's something to do with the specific video DAC you've sourced.  I'm not overly familiar with them as they don't usually give a lot of trouble.  But from a quick skim read of the VP101 datasheet, you might be able to fix the brightness issue by changing the scale on the output current.  i.e. Modify the value of R217.  Perhaps change 470 Ohms to 560 Ohms for a start and see what difference that makes.

Or temporarily replace R217 with a 1k potentiometer.  Vary it to see if you can find the optimum value.   After you've found that, remove the potentiometer and measure its value.  You can use a mixture of two different value resistors in parallel to get close enough to the 'perfect' value you need for R217.  If you don't know how to calculate parallel resistances (it's easy enough), there are probably online calculators for this.

I've not spent long looking at it, but see what you make of the VP101 operation:
http://lvd.nedopc.com/Amiga/VideoDACS/vp101.pdf

You'll note that the Vref output (pin 18) is from the internal 1.2V reference, it'll just need the external capacitor connected.  If the DC voltage on yours is much different from 1.2V, it might suggest something wrong with the VP101.  The A1200 main board has the option to supply Vref externally (R215, D215A), though I expect you won't want those fitted.  Maybe there are some variants of VP101 that need Vref supplied externally?  I don't know, you'd need to work it out from the datasheet.

[imqqmi]

Yeah, that's probably it, I messed up  I did mark it when swapping, but got erased when cleaning with alcohol (no I didn't drink it . I'm just glad it's now showing expected behaviour.

I use an ADV101, that one doesn't have an on board Vref, I use an LM385 1.2V external Vref.

Image looks too dark on DiagRomRGBBarsTest.jpg? The darkest shade from black is visible to the naked eye, the photo probably messes it up a little. The monitor is set to the middle of the pot range, so I could still adjust it at that point. But with WB, when I turn the brightness all the way up it's still too dark.

I'll try a trim pot of 1k as you suggest, hopefully it'll 'snap' into a good picture. I know how to calculate parallel resistance. I'll pop in a PLCC socket for the dac as well and test all the dacs I have. I'll also do the measurements on your annotated copy and see if I can confirm a few things.

[Castellen]

Image looks too dark on DiagRomRGBBarsTest.jpg?

Yes, compare the colour gradient with the attached photos from my 1084S test monitor, which shows the normal/expected brightness of the pattern.