Juno First Boot Leg

[NivagSwerdna]

A bit short of time this evening so a quick one...


Four sockets with pin 1 and pin 16 shorted (the PCB has no traces at the top of the device positions so shouldn't interfere..



All the happy campers are back in their beds... didn't make any difference (obv pin 1 floats high) but I prefer it.

And time for questions of the audience...


I haven't looked around that area yet... but those two wires are a bit intriguing; one clearly a trace replacement... not sure about the mess at the other one.
On the bottom...

The part on the right looks like they used plumbers solder and a blow torch... probably explains the bodge wires above.
Trace also clearly cut. I will get to that part one day.

 

[NivagSwerdna]

Still trying to get some video... I really don't understand this... in fact got the Tutankhm that I recently fixed and plugged it in and I do get a picture... for the JF I just get "No Signal"

The Sync Looks good... but maybe it isn't quite good enough...

Here's Sync from the Tutankhm...



(or the part when not VBLANKing anyway)....

And compared to JF...



TBH it looks fine to me... maybe it is slightly weaker... 2.76V versus 2.96V...

... maybe it slightly wider?


10.4us wide...


Cycle time is 62.4us
16kHz feels correct... 2.76V seems adequate...

Need to think about this.

 

[NivagSwerdna]

Doing the math...



HSYNC should be around 8.6% of the Horizontal Time... suggests that mine is too wide... I'm surprised this causes problems for the monitor though as you would have thought it would just care about the falling edges... oh well sometime to investigate at least!

 

[NivagSwerdna]

Hunting HSYNC...

 

[NivagSwerdna]

So the duty cycle of HSYNC is wrong... the trace above comes from the 74LS74 in the H-section of the Konami 082 equivalent...



The chip on the far right is a triple three input NAND and is used to calculate
D=!(!64H & 32H)
Specifically Pins 3 and 4 get 32H and pin 5 gets n64H (64H having been inverted by the 74LS04 in the middle)...



I spy something wrong... it will have to wait until tomorrow though... now we're cooking!

 

[NivagSwerdna]

OK... I don't have time to replace it, domestic duties, but I do notice...


Ignore the flux (that's mine)... but note the rounded solder on the pins... this isn't original... it's been reworked...

Damm... just burnt myself on the wire i was using to clean my desoldering gun...

Anyway the device (74LS10) is now out...


As observed... pin 6 is too high.
New socket and chip tomorrow... watch this space!

 

[philmurr]

Nice troubleshooting, and good to see someone else who spends far too much time getting a near-worthless pcb working

 

[Lurch666]

The worth is the enjoyment of fixing.

 

[sukhbir]

now that’s what I call working at component level.
Amazing work

 

[Alpha1]

Hello,

No I never even tested it until I listed it for sale. Was sat in a box for 10,000 years. Just part of my clear out.

Looks like it's in the right hands to live again though!

 

[cliff_poole]

Nice troubleshooting, and good to see someone else who spends far too much time getting a near-worthless pcb working

Juno First is a great game, even a bootleg I wouldn't classify worthless. I'd never heard of it, but someone brought the PCB to a couple of the 90s UKVAC meets. After that, most of us that played it were hooked.

 

[Bods]

Juno First is a great game, even a bootleg I wouldn't classify worthless. I'd never heard of it, but someone brought the PCB to a couple of the 90s UKVAC meets. After that, most of us that played it were hooked.

I'm not even really into those type games and when I got the pcb couple of us were playing it loads, very addictive game and massively overlooked, awesome sounds too, I did have a bid on the Taitel original cab on ebay years back but was outbid, hadn't really got the space but got pcb anyway so all good

 

[NivagSwerdna]

I bought it for two reasons...
Firstly, because I am interested in making CPLD versions of Konami customs to fix my board collection and these boards show the discrete implementations.
Secondly, because I like fixing things.
I will probably sell this once it is working as I'm pretty sure I have a JF in the loft somewhere... Should dig it out really and see if it works.

 

[NivagSwerdna]

Checked and I don't have any 74LS10.... so we go on hold until EBAY satisfies the need... will be a few days...

 

[NivagSwerdna]

OK... the parts fairy visited and now I have a 74LS10...



Sync looks better... but my extron keeps saying No Signal.

A waggle of a few things and I seem to get a picture but I think there is either a dodgy connection or something marginal...

Anyway... have temporarily managed to get some output...



That's pretty good. Shows the processor running as we expected. Suggests that the Verticals are not being decoded correctly when rendering?

I wish I could get reliable video output even if it looks wrong... staring at black screens with "No Signal" is no fun at all.

But progress at last!

Time for fish and chips.

PS
My guess for tomorrow is D12 (or whatever is the equivalent)... might just remove it and socket it on the hunch.

 

[NivagSwerdna]

Buzzing out the RAM Frame Buffer Addressing...





I might be heading down the wrong route here but I suspect that the Vertical Address Bits are messed up... Working on the fact that things repeat about four times vertically I suspect 128V and 64V which come through to D13 and then D12 and then via some resistors to A5 and A6 of the dynamic RAMs.
I suspect D12 but will check D13 (and C13) first because I don't trust 74LS86s.

It looks like C13 has been changed... will need to investigate that and D13 deserves to be tested too.



Looks a bit nasty on the bottom too... Bodge wire to small cap? Odd because it has a nice trace on the top?



I still suspect D12 more but... let's whip them off...


As I half expected both of C13 and D13 test OK. But I can tidy them up a bit and get to D12 tomorrow...

 

[NivagSwerdna]

After a very hectic week or so in the real world I have a couple of hours to play with this again...
I still cannot get reliable video output so still something fundamentally wrong.
I really cannot fault SYNC so looking at the actual video output which is driven through the 74LS240 acting as a three channel DAC but gated by VDG


At first appearance VDG looks good...



i.e. it is active LOW and is High during VBLANK and also high during HBLANK. The whole thing cycles at 30 Hz and includes lots of what appear like 16kHz lines.

If you look really closely within each line you see this is 65% duty cycle.



Theoretically this should be 256 pixels out of a line of 384... 66.6% Pretty close.
Oh well... barking up the wrong red herring up the wrong tree again... Will have to ponder... I will not be defeated...

 

[NivagSwerdna]

Sadly haven't had time to spend on this recently but I did notice one thing...

I'm trying to read the Banked ROM which is selected by a Bank Select Register on SE2





SE2 is enabled at Address
map(0x8060, 0x8060).w(FUNC(junofrst_state::bankselect_w));
Now if you look closely you can see that the B4 register is enabled by SE2 and is not controlled by RW at all. I find this quite interesting as my test gadget doesn't play nicely with this and I think this is because when I write to 8060 at the end of the write the data-bus flips to input but the latch is still enabled. This is because when I write to a 6809 I make RW=1 (read), and change the Data to input fractionally before changing the address. I think this produces the wrong result.
Now that got me wondering... You really don't want the Data bus being controlled by both the CPU (via D7) and the ROM that serves address FFFF simultaneously at the end of a Write.


There's an interesting bit of the circuit... the quad input AND at 5D takes the OE from the system ROM (including A10 which serves FFFF) and produces a signal ME.
Now ME...

This is an input to the Konami-1 Custom at pin 27.... now here we don't have a Konami-1... so let's look where ME goes...

We are looking at pin 8.... goes nowhere on the top...

Goes nowhere on the bottom! So brilliant they implemented 5D but then didn't know what to do with it!
Now I assume ME is something like 'memory enable'. I would speculate it is intended to stop the devices fighting over the data bus... here it was not implemented!
I will tweak my debug gadget to change the address BEFORE changing the data bus direction on a Write!
If anyone has a schematic of a Konami-1 daughterboard that implements ME please let me know.

 

[NivagSwerdna]

So... a lot works... but READ and WRITE to the Frame Buffer 0000-7FFF definitely don't work reliably.

I wrote a loop to write to 2AAA and 2AAB alternately. (The LSb is used to select between the two sets of eight 4116s)...
The least significant 7 bits of 2AAA (ignoring the very lowest bit) are... 1010101 giving 55 and then 0101010 giving 2A for the row and column addresses.
Looking at the analyser we can see the 55s and the 2As... (and the video refresh row/column values).
The RAS and CAS look nicely 3MHz but I'm not sure about the phase... I think there should be falling edge in the 55s and a falling edge in the 2As...

Guessing I would say CAS falls too early.

 

[NivagSwerdna]

I have a Tutankham next to me so I thought it would be interesting to compare...



As I suspected the JF edges look wrong or more specifically the RAS edge looks OK but the CAS edge is far too early.

0x7F on RAS edge but the CAS edge falls before the 0x3D appears.... and then 0x7F on RAS edge but CAS before the 0x3E appears.

Looking at the Tutankham...



Here we see that RAS falls when 0x76 is valid and CAS falls when 0x5D is valid.... subsequently... 0x77 on RAS edge; 0x5D on CAS edge... now that looks correct.
PS
Had a few sparks during that... didn't notice that Tutankham has its 4116 installed upside down! Luckily nothing obvious seems broken!