Mr Do! Appreciation PCB redesign

[myPinballs]

Couple of other things.

- Found a couple of small mistakes on the red output section of my design, so fixed these. Been trying to fathom out why the colours are slightly off and this was part of that investigation

- Found out that the published pinout on arcade-museum.com is wrong on the coin switches, so coin1 is actually pin24 and coin2 is pin25. So I need to adjust my schematics for this. Tilt is pin 12 and service and test are not used.

 

[philmurr]

More progress, got some sprites working now to, though still wrong positions (shifted up slightly) and some other mess-ups.



Also, ran the alternative test rom on the board (from @philmurr) very useful, which also runs ok now. But interestingly this rom does not complain about RAM4 (which is foreground ram). It runs successfully and goes to the input test. Confirmed all inputs work ok, inc dip switches and joystick etc. Had to add some pull-up resistors to the dip switches as I forgot those on the 1st design and was getting flickering and slow changes on the screen. Now sorted.

So I am wondering why the built in test is complaining about foreground ram (RAM4) when @philmurrs test is happy. Also I wonder if the test roms could be expanded to test the sprite rams to. I'm still unsure if the built in test checks these or not.

I've not looked in detail into how Mr Do does its RAM testing but my test ROM does quite extensive testing and tests every byte of video RAM with various patterns so its odd that one fails and one doesn't. *Update - just checked the inbuilt test and it copies various ROM contents to RAM then checks to make sure they are the same. All I could guess at would be a timing issue perhaps? It would be interesting to know what address/data it was failing on but that would need some of the original ROM modifying...

You can't do a proper test of the sprite RAM as it is write-only and the CPU can't read it.

 

[myPinballs]

I've not looked in detail into how Mr Do does its RAM testing but my test ROM does quite extensive testing and tests every byte of video RAM with various patterns so its odd that one fails and one doesn't. *Update - just checked the inbuilt test and it copies various ROM contents to RAM then checks to make sure they are the same. All I could guess at would be a timing issue perhaps? It would be interesting to know what address/data it was failing on but that would need some of the original ROM modifying...

You can't do a proper test of the sprite RAM as it is write-only and the CPU can't read it.

Thanks Phil. Yes your test rom is definitely the benchmark for checking the hardware designs etc. The weird thing about the inbuilt test is that when it fails for RAM4, its pretty quick and can't possibly have checked all the RAM3 (background addresses) in that time. Same on an original board if you short 2 address lines temporarily on the ram. I know on my board if you remove the background ram ic you get a RAM 3 error and no RAM4 error, so the original program is looking at RAM3 first at least partially.

 

[TheDaddy]

Great project !!! Nice read up as well.

Dave.

 

[myPinballs]

You can't do a proper test of the sprite RAM as it is write-only and the CPU can't read it.

Yeah I was wondering if you could do a display sprites in sequence on screen or something

 

[philmurr]

Thanks Phil. Yes your test rom is definitely the benchmark for checking the hardware designs etc. The weird thing about the inbuilt test is that when it fails for RAM4, its pretty quick and can't possibly have checked all the RAM3 (background addresses) in that time. Same on an original board if you short 2 address lines temporarily on the ram. I know on my board if you remove the background ram ic you get a RAM 3 error and no RAM4 error, so the original program is looking at RAM3 first at least partially.

Background video is 8000-87FF, foreground is 8800-8FFF but the inbuilt test treats it as one section of RAM 8000-8FFF and checks the entire block with each test pattern. What it means is (not in your case, just generally) that you could have both faulty background and foreground RAM, the memory location it fails at first first will be the RAM flagged as faulty! My test ROM tests both sections separately, background first then foreground.

You're dead right in what you say that if you remove your background RAM it will flag that first as faulty without getting as far as the foreground RAM.

Yeah I was wondering if you could do a display sprites in sequence on screen or something

I could mod it to be like my Scramble (and other) test ROMs which has sprites falling from the sky. It doesn't "test" as such but shows if they're working or not. I've just checked the source file and I actually have the sprite test code commented out from where I adapted it from another test ROM. I'll see if it can be added in without too much effort.

 

[myPinballs]

Started to populate the on board sound section, now I know all the video sections are displaying something and the i/o all works. Waiting for a few sound ics to arrive before I can test this part. I also realised today I didn't add an on board sound volume control so I need to fix that , doh!

 

[myPinballs]

Background video is 8000-87FF, foreground is 8800-8FFF but the inbuilt test treats it as one section of RAM 8000-8FFF and checks the entire block with each test pattern. What it means is (not in your case, just generally) that you could have both faulty background and foreground RAM, the memory location it fails at first first will be the RAM flagged as faulty! My test ROM tests both sections separately, background first then foreground.

You're dead right in what you say that if you remove your background RAM it will flag that first as faulty without getting as far as the foreground RAM.

Makes total sense on the ram test, so i'm thinking it must be failing on the first pattern on the foreground part, before it moves on to the 2nd pattern etc. Your way of testing the ram makes alot more sense to me!

I could mod it to be like my Scramble (and other) test ROMs which has sprites falling from the sky. It doesn't "test" as such but shows if they're working or not. I've just checked the source file and I actually have the sprite test code commented out from where I adapted it from another test ROM. I'll see if it can be added in without too much effort.

Yes this would be awesome

 

[Flinnster]

Just want to say epic effort all round on this!

 

[myPinballs]

Some more progress, I have resolved 1 more sprite issue to do with the positioning and movement of the sprite characters. The bloody universal schematics were wrong again.
Still have a colour issue to solve, some noise from the sprite section to fix and a weird background issue, but progress.



The colour issue is weird as green becomes yellow and red becomes yellow when I turn up the contrast. The answer must be simple but I haven't solved it yet, and I thought I had a few times with schematic errors. And not on everything just the background stuff/red text.

The background issue seems to be drawing solid yellow where it should be transparent on the mr do logo, but the colour stripe works ok.

 

[myPinballs]

Colour Issues fixed. I cant wait for you guys to have this board as the colours are so sharp and vibrant its unreal! Better than the original I have here! Still some sprite issues to solve and a foreground problem at boot start.

Colour problem was down to a schematic error again that I had noted. resolved and thought I had updated on the real hardware, but I hadn't done all the changes only 1/3rd of them. It was basically selecting the wrong 12bit colour sets meaning yellow was getting chosen a lot lol

 

[pubjoe]

Just caught up. This is amazing.

 

[Flinnster]

It is, although I bet there's some left-side neck pain going on from looking at that monitor with the game running horizontally all this time!

 

[myPinballs]

Big Thanks to @philmurr and his awesome test rom work! New sprite test has been added to the test rom and its already helped me solve another sprite issue.

Turns out the sprites were not being drawn properly. Half of the data was fine and half was messed up and being repeated in the wrong place! (1 full sprite portion behind). This was traced to be a timing issue with using HCT chips. My old favourite issue (NOT!) LS chips needed to be used in this particular area.

Sprites looks good now, though there are still 2 other sprite issues to look at and also a foreground issue to solve.

 

[Martinmurphy30]

Brilliant work! Can't wait to see the final results!👍

 

[myPinballs]

1 more sprite issue resolved. I've cured the random static/garbage dots appearing on the sprite layer. Turns out the sprite storage ram must be the same type and speed otherwise you get this weird interference.



Now we are down the the following issues:
1) foreground ram does not test correctly and loads with garbage at boot. Running the test clears the boot garbage however
2) sprite at a fixed position (not moving) is messed up by another sprite moving either over or under it ( in the vertical plane)
3) sound is not working correctly

 

[Mc-Q]

you should have verified the schematics against an original board first.
i know how long that takes, i'v drawn entire board schematics for MAME from obscure italian pcb's.
but it's better than hunting bugs later.

the other thing, you should consider pads for smd ram in an soic package,
the ram with pins is getting harder to find and more expensive.
i often do repairs now using little chinese footprint/package convertor boards because of this.
ttl is also going the same way, even aliexpress doesnt have some stuff anymore

 

[myPinballs]

you should have verified the schematics against an original board first.
i know how long that takes, i'v drawn entire board schematics for MAME from obscure italian pcb's.
but it's better than hunting bugs later.

the other thing, you should consider pads for smd ram in an soic package,
the ram with pins is getting harder to find and more expensive.
i often do repairs now using little chinese footprint/package convertor boards because of this.
ttl is also going the same way, even aliexpress doesnt have some stuff anymore

Oh I verified the design against a real board a few times but things slip through when you are working on things this complex. The boards always go through some iteration with layout /design/features anyway so hacking up a few physical boards /revs is the best way to truely make reliable quality hardware

My company’s mantra has always been to use plate through parts and avoid smd stuff so there won’t be smd in here. The design like much of my other work aims to improve/simplify add useful features and reduce power consumption while keeping true to plate through parts.

 

[Macro]

On your foreground ram problem, it isn't the protection causing it is it ?

On the real PCB, IC U001 returns specific values dependant on what was written to screen ram before it was read.

can be removed with ... replace

049A: C0 ret nz

and

772F: 20 0C jr nz,$773D

with NOPs if that is the problem.

 

[ArcadePCB]

"My company’s mantra has always been to use plate through parts and avoid smd stuff so there won’t be smd in here. The design like much of my other work aims to improve/simplify add useful features and reduce power consumption while keeping true to plate through parts."

I absolutely agree with this. But it will become harder and harder to do so. Many parts from the past have been discontinued in DIP package in the meantime, but are still available in SO package. And because many parts companies has disapeared (means: bought by competitors), there was an acceleration in discontinuing parts during the past years. So there's often the only way to do so to look for NOS parts. SO and SOT parts can still be handled by non professional users, but many new parts often are available in very 'uncomfortable' packages only (e.g. MLF or BGA packages). This means, soldering with a soldering iron isn't possible any more because the connections are below the part.
Especailly newer operational amplifiers are not available in DIP packages any more, but they're often much better than the vintage ones (741 / LM 324 /...) so it's making sense to think about using this types for new designs. Especially when there's a single rail and low voltage only (e.g. +5V), the rail-to-rail inputs and outputs and the internal offset compensation are a big advantage.

It's a great job your doing reengineering this PCB and I know how much time it takes to do this. Congratulations.