Jump to content
Sign in to follow this  
launton

MPU4 rom cart circuit diagram

Recommended Posts

In fact its worse than that, can you post the rom you want doing again pls Launton. Sorry.

Share this post


Link to post
Share on other sites

Ha Ha yeah sure. It's ok. There's a lot of guys on here who have lives and jobs and arcades etc, and I'm a patient man.

 

Update: Rom sorted, should be able to get back into this now. Thanks Guitar!

Edited by launton

Share this post


Link to post
Share on other sites

Sorry to bump this, but if that diagram is still about, I'd be interested in it, as when looking at the MPU4 video card, I noticed that, in theory, the CHR chip is deterministic enough to be expressed as a a small number of bit manipulation equations, making it possible to reverse engineer and replace CHR chips. I'd always assumed that there was a sophisticated latching behaviour used, since different writes expect different results, but I think what might be happening is that the internal PLA logic is in fact using apparently unrelated pins as extra elements, where a certain bit set in one situation affects the next calculation.

 

Seeing if the PLA pins were piggybacked in any way on the PCB trace might solve this one way or another.

Share this post


Link to post
Share on other sites

I'm gonna ask my mate if he's done any more with this later this week, but I don't think there is a printed diagram around El Condor. Glad you bumped this though, I'll give Jonny a shout

Share this post


Link to post
Share on other sites

Sorry to bump this, but if that diagram is still about, I'd be interested in it, as when looking at the MPU4 video card, I noticed that, in theory, the CHR chip is deterministic enough to be expressed as a a small number of bit manipulation equations, making it possible to reverse engineer and replace CHR chips. I'd always assumed that there was a sophisticated latching behaviour used, since different writes expect different results, but I think what might be happening is that the internal PLA logic is in fact using apparently unrelated pins as extra elements, where a certain bit set in one situation affects the next calculation.

 

Seeing if the PLA pins were piggybacked in any way on the PCB trace might solve this one way or another.

 

Grab the datasheet for the GAL16v8 and it shows it has 8 flip-flops/latches. There are 10 inputs and 8 outputs. Only 6 bits are written/read from it, 2 outputs are fed back to 2 inputs, one input is R/W and the other is the chip select.

Share this post


Link to post
Share on other sites

I think I get you - it certainly ties in with the pinout equations I've seen (Sys80's ROM dump of MPU4 Video prototype Vegas Poker came with a fusemap for the PAL). I did wonder why the CHR code effectively threw away the lowest two bits each time, presumably with that setup they'd not be changed, but could still affect the end result.

 

Would the equation data be any use to you for MFME, as if you've got BwB Video games running, this would probably run the same way.

Share this post


Link to post
Share on other sites

Right, I know this is a old thread but have picked up on this recently as been looking into MPU4 CHR chips and this thread has been so useful!

 

So looking at the ROM code to my Hyper Viper club I have identified the query response table.

 

It's in black highlighted

 

post-7246-0-75641500-1425223748_thumb.jpg

 

you can see CHR gets sent #00 its response is seen to be #00, actually the response back is #03 and the last 2 bits are discarded so it it becomes #00

 

you can then see I send the next in the table #1A and get the response when read back of #C3 (again last 2 bits will be discarded so #C0)

 

you can see the video of the write and reads to and from the CHR chip on a REAL CHR chip and motherboard!

 

 

(I am using my fluke troubleshooter 9020 and the 6809 processor pod for it so it sees the board from the processor on  board point of view!)

 

I presume the last 2 bits that are set at ones (to produce the #3 digits) are used to feedback to the inputs of the CHR so it knows what table its on as I think there is another table hidden inside, but still to be investigated! my aim for now is just to get past the CHR query response check on REAL machines by using a similar question answer system! small steps!

 

Interesting stuff!! I too now need the circuit diagram of the CHR conections on the program carts!

 

Share this post


Link to post
Share on other sites

Entering ANY codes out of sequence completely messes up the CHR response after that, that's why 'bit bashing' the CHR chip (applying codes to the input and seeing what is on the output) is totally useless and probably the reason why these CHR chips have never been able to be reproduced!

Share this post


Link to post
Share on other sites

Great stuff Andrew, very interesting stuff, many thanks for posting.    Wonder if you can bypass or make the Chr chips for the BWB video fruit machines.   I for one would certainly be extremely interested.

 

J

Share this post


Link to post
Share on other sites

Many years later. Barcrest did use FORTH to develop the games. The system side was hand written assembler, for the multiplexor etc.

Game code was FORTH with some assembler for calculating nudges ‘/ reel wins.

it could take 10 minutes to download the games to the target system when developing only to run out of memory right near the end!!

The download would compile the FORTH at the same time.

Easy than writing pure ASM

 

 

  • Like 1

Share this post


Link to post
Share on other sites
8 minutes ago, iamtheone said:

Many years later. Barcrest did use FORTH to develop the games. The system side was hand written assembler, for the multiplexor etc.

Game code was FORTH with some assembler for calculating nudges ‘/ reel wins.

it could take 10 minutes to download the games to the target system when developing only to run out of memory right near the end!!

The download would compile the FORTH at the same time.

Easy than writing pure ASM

 

 

I'd be interested to learn more about this. Right up my street!

I'd imagine they'd moved to C/C++ by the time MPU5 was introduced?

Share this post


Link to post
Share on other sites

They did move to writing in C but kept the FORTH environment for interactive debugging.

  • Like 2

Share this post


Link to post
Share on other sites
22 minutes ago, iamtheone said:

They did move to writing in C but kept the FORTH environment for interactive debugging.

Interesting.... I take it you worked there at some point?

Share this post


Link to post
Share on other sites

Would this be useful to the work roadrunner is doing and what Andrew96 was looking into regarding the chr cracking

Share this post


Link to post
Share on other sites
Sign in to follow this  

×