Jump to content
Sign in to follow this  
launton

MPU4 rom cart circuit diagram

Recommended Posts

Hi

 

Can anyone point me to a circuit diagram for a MPU4 rom cart (the smallest cart preferably, but any will do) Can't seem to find one in the download section. Thanks

Share this post


Link to post
Share on other sites

Hi

 

Can anyone point me to a circuit diagram for a MPU4 rom cart (the smallest cart preferably, but any will do) Can't seem to find one in the download section. Thanks

 

Not right now, but if you still need one later on I can draw one up from a spare card. Any specific info you need or just a general schematic?

Share this post


Link to post
Share on other sites

Hi

 

Can anyone point me to a circuit diagram for a MPU4 rom cart (the smallest cart preferably, but any will do) Can't seem to find one in the download section. Thanks

 

 

The only ones that I can find are on page 35 of the mpu4 manual - showing the links on mk1 and 2 modules.

 

Dave.

Share this post


Link to post
Share on other sites

Thanks

 

Probably be better if I tell you why I've asked really. One of my mates is a complete nerd and we were discussing MPU4's and emulation but mainly hardware and rom writing. He asked me to send him the circuit diagram and some other stuff. From that he found the whole thing really interesting and is basically just nosing round how the whole thing works. How the software is written, how the hardware works etc. How is it all done? I think he's looking at it as a bit of a hobby. Anyway I've had a few emails from him (most of which I don't understand) But I'll paste them here for information. He's asked for the rom cart diagram so he can see how that portion relates to the rest. I suspect a few of you here will understand the gobbledeegook below :)

 

He also said he found an error in the MPU4 circuit diagram?

 

 

 

The characteriser seems to be a basic challenge and response system.

What it does is to write a byte of data from a code table to address $0800 and immediately reads back the byte at the same address.

This address is neither ROM or RAM as the returned value changes based on what was previously written to it so I assume characteriser is a custom logic device (PLA implementing a simple state machine?). Anyway the returned values are manipulated (the lower two bits cleared - no idea why) and compared to the next value in the code table. If there is a match then the process is repeated until the end of the table is reached. If there is a mismatch is found then the loop is exited and the "BAD CHARACTR" message displayed. Not sure what happens after that.

 

There are no other references address $0800 so this routine would seem to be the only place where the characteriser is checked though I do not know how often this routine is called.

 

The thing that is odd though is that just before the characteriser is checked bit 1 of address $6001 checked and if zero the characteriser check is bypassed. This is the case for the file I have so I wonder if the ROMs have been hacked. Presumably they would have to be unless the emulator also emulates the characteriser.

 

I am not sure if there are any other protection mechanisms used such as

 

This is from the ACTION ROM which I chose as it has <32K of program and data.

 

If you are interested in the assembly language I added my comments to the code. I've not worked with 6809s before but it's not that dissimilar to the other 8-bit micros of that era.

 

A177: F6 60 01 LDB $6001 ; Load B with value at 6001

A17A: C5 01 BITB #$01 ; test bit 1

A17C: 26 16 BNE $A194 ; if bit = 0 then branch (return)

A17E: 8E FF 30 LDX #$FF30 ; Load X with address of code table ($FF30)

A181: A6 80 LDA ,X+ ; Laod A with byte at address in X

A183: B7 08 00 STA $0800 ; write challenge to characteriser

A186: B6 08 00 LDA $0800 ; read back response

A189: 84 FC ANDA #$FC ; clear lower 2 bits of response (FC = 1111 1100)

A18B: A1 80 CMPA ,X+ ; compare to next byte in table

A18D: 26 06 BNE $A195 ; mismatch - exit loop

A18F: 8C FF B0 CMPX #$FFB0 ; has X reached end of table

A192: 26 ED BNE $A181 ; NO - get next byte

A194: 39 RTS ; YES - return from subroutine

 

A195: 30 1E LEAX -30,X

A197: 10 AE 84 LDY ,X

A19A: C6 16 LDB #$16 ; 16 = "BAD CHARACTA"

A19C: 3F SWI ; SW Interrupt to print error message?

 

Code table

0000ff30 00 00 1a 44 04 44 10 54 18 34 0f 04 13 54 1b 14 |...D.D.T.4...T..|

0000ff40 03 34 07 14 17 20 1d 74 36 04 35 60 2b 44 28 50 |.4... .t6.5`+D(P|

0000ff50 39 34 21 34 22 34 25 04 2c 50 29 10 31 20 34 44 |94!4"4%.,P).1 4D|

0000ff60 0a 54 1f 30 06 14 0e 00 1c 44 12 54 1e 00 0d 50 |.T.0.....D.T...P|

0000ff70 14 24 0a 64 19 64 15 40 06 54 0f 00 08 70 1b 14 |.$.d.d.@.T...p..|

0000ff80 1e 00 04 44 01 74 0c 14 18 34 1a 14 11 34 0b 24 |...D.t...4...4.$|

0000ff90 03 74 17 00 10 50 1d 30 0e 04 07 54 12 34 09 20 |.t...P.0...T.4. |

0000ffa0 0d 54 1f 30 16 04 05 44 13 54 1c 00 02 74 00 00 |.T.0...D.T...t..|

 

 

 

 

 

Given it's age I think there is a good chance that was actually written in Assembly Language. I guess at that time it is possible that C or Pascal could have been used but high-level languages (C and Pascal), particularly with the crude non-optimising compilers of the day, can leave signs in the machine code they output that can indicate that a the source was from a high-level language rather than hand crafted assembly language.

 

My guess is that it was written in Assembly Language which was assembled into a binary file then burnt onto the EPROM.

Edited by launton

Share this post


Link to post
Share on other sites

Ahhh, right, well. Why didnt you say so sooner. :)

 

The ROM card is very simple, bugger all to it tbh. In emulation terms there is only 1 link on the program card that matters which is link 7A/B which switches the IRQ line used from IRQ to FIRQ, and so far I have never seen the FIRQ line option used.

 

I'm at work right now, when I get home later I will do a big write-up for you.

 

Can you be more specific about what you need/want to know/do. As far as MPU4 goes, any questions just ask, I know the 6809 inside out now.

 

I would imagine that address 6000 was the "back door" to allow quick rom testing without needing to use a chr. If you want to emulate the CHR proper it can be done in 4 lines of code in VB and about 6 in C++ (you have to add the definition to the .h file)

Share this post


Link to post
Share on other sites

I suspect a few of you here will understand the gobbledeegook below :)

not there yet but do find it interesting - thanks for pasting (with comments), the more I look at it, the less foreign it seems

 

He also said he found an error in the MPU4 circuit diagram?

D16 labelled as D19 below DIL switch 2?

Share this post


Link to post
Share on other sites

Given it's age I think there is a good chance that was actually written in Assembly Language. I guess at that time it is possible that C or Pascal could have been used but high-level languages (C and Pascal), particularly with the crude non-optimising compilers of the day, can leave signs in the machine code they output that can indicate that a the source was from a high-level language rather than hand crafted assembly language.

 

My guess is that it was written in Assembly Language which was assembled into a binary file then burnt onto the EPROM.

 

There was a rumour going round that a lot of the Barcrest stuff was written in Forth. Somehow, I doubt it, as even the best Forth compiler in the world probably couldn't create code as tight and efficient as what you've just posted.

 

I'm not a 6809 expert, btw, Z80 is more my thing :)

Share this post


Link to post
Share on other sites

Thanks all

 

My mate out of interest asked me about this stuff as people seem to think the 'hobby' of older machines and their upkeep is either mad or partially interesting.

 

He just seems to like the challenge of de-compiling it all to see how it works, and he needs to know the schematics of the rom carts to complete the picture. I guess personally I'd like the idea of changing a rom to do something different and he just likes the challenge of fannying about full stop.

 

 

"He also said he found an error in the MPU4 circuit diagram?

D16 labelled as D19 below DIL switch 2?"

 

I don't know Paulgee. I'll ask him next time he emails me

Edited by launton

Share this post


Link to post
Share on other sites

Had a bit more feedback. Here's what he said about the errors Paulgee:

 

 

D16 labelled as D19 below DIL switch 2?

 

 

So it is. Not a major error though. The ones that I found are:

 

 

1) The data bus coming down from the CPU (IC1) is shown connecting the the E (clock) line and not the data bus which is the line above.

2) The outputs of IC18 (I think its IC18 but the label is not clear - anyway it's the 74LS138 to the left of IC9) used to decode the I/O memory map are labelled incorrectly. The IC numbers on the outputs are one less than they should be. E.g. The output Y1 should be labelled as "CS0 IC2" and not "CS0 IC1".

 

Finally one of the blokes said this about the writing of the software:

 

 

 

There was a rumour going round that a lot of the Barcrest stuff was written in Forth. Somehow, I doubt it, as even the best Forth compiler in the world probably couldn't create code as tight and efficient as what you've just posted.

 

 

 

 

Strange you should mention Forth. I seem to recall that it was in vogue at the time so its possible. One thing to note is that so far I've only looked at the lower level code for accessing the hardware. It's possible that these lower level routines were written in assemble language with Forth or some other higher level language used for the game logic.

As I poke around some more I might see evidence of that.

 

I'm not a 6809 expert, btw, Z80 is more my thing. This is the first time I've done any 6809. My assembly language experience was with 6502/10, some Z80, 68000, 8051 and some x86 and a little bit of ARM. It's getting on for 10 years since I've written any assembly language which is partly why I'm enjoying this so much.

 

He said he's looking forward to learning more.

Share this post


Link to post
Share on other sites

I dunno how far he's gonna delve into things but seeing as he's just said he found this:

 

LOL Just noticed that there is an error message of "NUDGE COCKUP" :-)

 

I think he might carry on :)

Share this post


Link to post
Share on other sites

Bit more:

 

I didn't do as much as I expected to last night. I checked the code for the characteriser check in the game ROM from the Cash Matrix game. The code is the same as the Action game and uses the same "back door" technique. It still looks like the check has been bypassed too so I am not sure if I am reading it wrongly.

 

I found the code that tests the RAM on start up when I was looking for the ROM checksum test.

 

I also got the emu running. It's not very stable, well at least not in a VM.

 

Also, I have a USB to serial cable so that I can try out my EPROM programmer but I need a 9 to 25 serial adaptor which I'll get tonight. I also have several unused EPROMs that we can experiment with if you fancy. I'll let you know how that goes.

 

One thing I was wondering was where can you get hold of 6809s and 6821s etc. I doubt these are in production and none of the major suppliers stock them. I'm pretty certain all of the other chips are still available though.

Share this post


Link to post
Share on other sites

Oooh, this is very interesting especially a way to bypass the chr check bit. Wonder if this would apply to the BWB mpu4 video based machines?

 

J

Share this post


Link to post
Share on other sites

Oooh, this is very interesting especially a way to bypass the chr check bit. Wonder if this would apply to the BWB mpu4 video based machines?

 

J

 

If its even remotely like the BWB Fruit based stuff, then no way.

 

That skip isnt in all Barcrest roms though.

Share this post


Link to post
Share on other sites

Had a little bit more off my mate earlier. He's like a dog with a bone :lol: Although I am enjoying reading this stuff myself a lot!

 

------------------------------

 

 

Had to use the latest version as that had the Debug screen that I need to edit the ROM and step through the program.

 

I have confirmed one thing. My initial explanation of the Characteriser check was slightly wrong due mainly to my assembly language being very rusty.

 

The comments should be follows

 

A177: F6 60 01 LDB $6001 ; Load B with value at 6001

A17A: C5 01 BITB #$01 ; AND B with 1 (see of bit 0 is set)

A17C: 26 16 BNE $A194 ; if bit = 0 (Z flag clear) then branch (return from check)

Note: this is the code from the other game but the logic is the same.

 

The upshot of this is that I was getting the sense wrong before which is why I originally thought that the characteriser check was always being bypassed when if fact it was not.

 

Anyway, I have discovered the following using the emulator:

1) The characteriser check is being run at periodically, seems to be every second or so.

2) Changing a value in the characteriser table (from the Design/Character menu) will stop the fruit machine dead and display "nn" on the 7-segment display.

3) The characteriser can be bypassed by setting the byte at address $61DF to $01 so this is a back door as expected. Obviously this can only be done in the emulator.

4) If I then reset the processor (from the debug screen) the machine does not start running and it displays "nn" on the 7-segment display. I am guessing this is because the checksum has failed due the the changed value of address $61DF.

 

My next challenge is to find the checksum code and bypass it. After that we should be able to make any changes to the code.

 

I do note that bypassing the characteriser is not really essential as we have a program card with the correct characteriser PLA on but it will give you more flexibility.

 

 

 

------------------

 

 

God you're quick at all this aren't you?

 

 

Thanks :-) Still not found the ROM checksum though. I have just found where the bit patterns for the digits displayed on the 7-segment display are stored. Not hugely important but at least that's a few more bytes that I can explain.

 

 

 

I don't have an alpha display loom or hardware.

 

 

The alphanumerics I saw on the web were 16 segment (also know as starburst) VFDs. http://www.cmjsleisure.com/spare-parts-displays-c-1_2.html?sort=3a&page=1

 

I'm very tempted to get one of these myself. What's neat about these it that the module itself includes the DC-DC converter needed to boost the 12v supply from the MPU4 to the 50-60v or so needed to drive the VFD. I've not seen any documentation for the protocol used for the serial interface for these yet - not really looked. I can always try to find it from the code in the ROM after all I do know which ICs the display is connected to an hence which addresses are used to access it.

 

(linked him to some pictures of barcrest various rom carts)

 

 

Well there is clearly more going on on two of those carts excluding the sound chip. I can't see the numbers on the chips but I am guessing that the second from the left at the bottom is the Character PLA*. I'm guessing that the 40pin to the left is either another 6821 used to control the sound chip. The other smaller ICs will probably be more address decoding logic.

 

*PLA stands for Programmable Logic Array. You can think of it as being one step up from an PROM in that you can program it such that a given set of inputs will generate a specific set of outputs. This can be done with an ROM but a PLA can also make it's output dependent on the current inputs and the previous set of inputs (or outputs). This is what the characteriser appears to do. Because its outputs are dependent on a previous state it is harder to copy.

 

 

I'm hoping that what I'll find as I dig deeper is that there are a load of low level routines to perform various functions. Eg Spin Reel, turn on/off lamp, payout coins etc. We could then build a library of these and write our own games. Okay, maybe not go that far but you get the idea :-)

Edited by launton

Share this post


Link to post
Share on other sites

Few pointers for you...

 

Find attached the datasheet for the Alpha driver, there is a table at the bottom which tells you the codes for different characters.

 

The Barcrest CHR has two parts.

 

Part 1 is the main security, it runs through once per reset and that's it.

Part 2 is a bit of awkwardness put in. They shift the lamps around if the wrong CHR is used. So if you are emulating the game for example, all the lamps will be shifted about and wont flash when they should etc. This is the bit run that runs constantly. Quite a clever addition.

MSC1937-01.pdf

Share this post


Link to post
Share on other sites

Cheers Guitar. Jonny's reading this thread now. He may join the forum but his interest is not in the machines but the code/hardware and what can be achieved with it depending on your imagination I guess. I might be asking someone for an alpha display & loom in the future. If anyone's got one the beer tokens await.

Share this post


Link to post
Share on other sites

It's all getting a bit beyond me now :headache:

 

 

before we can make any changes we have to workout how to bypass the checksum. I've not got any closer to solving that problem.

 

Warning the following gets quite technical. In summary I now know how the various DIP and other inputs are read by the software. I still need to make sense of what's being read though.

 

The challenge we have though is to work out how some piece of code relates to functions on the machine itself. Fortunately there are 'sign posts' to what the code is doing, at least where it interacts directly with the hardware. As each of the IO (PIA 6821) chips (ICs 3-8) are mapped into memory at known addresses and I can see from the circuit diagram what hardware they are connected to all I need to do is look for references to that hardware address and try to see what the code is doing.

 

As you mentioned DIP switches for setting the payout I thought I'd see how that works. This was not quite as easy as I hoped.

The DIP switches are connected to PORT A of IC8 which I know is at address $0F00. There is only one reference to this address in the code so that simplify things a bit. The hardware though is not as simple which in turn makes the software more complicated.

Although IC8_PORTA is used to read DIP switch bank 1 it is also used to read DIP switch bank 2 as well as the 32 input lines on loom Inputs1 and 2. That's 48 input lines all routed through and 8 bit port!. It does this through a common technique known as multiplexing. Essentially it activates the input lines in groups of 8 lines at a time and then samples the inputs on IC8_PORTA before moving onto the next group. This is achieved through IC23 and IC22. IC23 is a 3-to-8 line decoder meaning that it takes a three-bit input (which can represent the values 0 to 7) and sets the corresponding 8 outputs accordingly. IC22 contains 4 AND gates which are used to activate (provide a current sink) each of the 4 groups of 8 input lines on the 2 input ports. What is interesting about this is that it is not symmetrical in that the INPUT 1 port values are samples twice as often as the other inputs and DIP switches. I'm guessing some keys need to be more responsive than others - don't want customers saying "hey I pressed that button and nothing happened - i want my money back!".

 

The multiplexing sequence is as follows:

0 INPUT 1 (Lower 8 lines)

1 INPUT 1 (Upper 8 lines)

2 INPUT 2 (Lower 8 lines)

3 INPUT 2 (Upper 8 lines)

4 INPUT 1 (Lower 8 lines)

5 INPUT 2 (Upper 8 lines)

6 DIP SWITCH BANK 1

7 DIP SWITCH BANK 2

 

The software obviously needs to know where in the sequence it is at in order to make sense of the data it is reading from IC8_PORTA. It is able to do this as it is responsible for setting the three input bits to the 3-to-8 decoder.

 

The use of a retriggerable monostable multivibrator (IC24), triggered by the least significant bit of the 3 bit input to the decoder to extend the length of the enable pulse for the decoder itself is very cleaver. It took me a while to make sense of what was being done there.

 

I should also add that the outputs from the decoder are also used to multiplex the 7-segment display and the lamps but I'll leave an explanation of that for another time.

 

Anyway, once I understood what the hardware was doing I took a look at the software. I did not spend much time on this but could not see anything obvious to do with payout percentages. I did notice from the manual that payout percentages don't seem to be settable on Club machines so maybe the ROM in have in the emulator is one of them. What is a Club machine and now would it differ from a non-Club machine?

 

Still can't believe I'm spending this much time on a 22 year old piece of hardware but I'm certainly enjoying it.

Edited by launton

Share this post


Link to post
Share on other sites

Fascinating stuff, launton, tell your mate to stick at it :D

 

Any more progress with this? It was interesting while it lasted! :)

Share this post


Link to post
Share on other sites

Any more progress with this? It was interesting while it lasted! :)

 

 

I'm waiting for Guitar to remove the checksum from the rom before Jonny can continue dissecting it and the programming. I have bumped him a few times, but I won't hound anyone if they're busy. He might read this and remember. Jonny's happy to continue working it all out when he gets what he needs. We've got everything else.

Share this post


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

×