|
Joined: May 2010
Posts: 1,051
Very Senior Member
|
Very Senior Member
Joined: May 2010
Posts: 1,051 |
I posted the Funtronics Jacks info: www.seanriddle.com/cop410l.htmlI'm pretty certain about the ROM dump- I got the same data for the hundreds of dumps that I captured, but I just did the simple dump where I didn't force any instructions, so it started at a random location. Since the ROM is only 512 bytes, there's not a lot of empty space like Space Invaders and Light Fight had to help me align the dump, so it was harder to find the start. But the position I chose made the JMPs and JSRs in the code consistent.
Last edited by seanriddle; 04/07/15 06:17 AM. Reason: typo
|
|
|
|
Joined: May 2010
Posts: 1,051
Very Senior Member
|
Very Senior Member
Joined: May 2010
Posts: 1,051 |
Kevin- glad to hear you're OK. Hope you got a new car! I did check out bitsavers and the datasheet archives, but didn't see that chip or any others more similar than the HD38702. That one has a test pin, and the Armor Battle chip has a couple of pins tied to Vss that I'll play with. On the Hitachi chips you are dumping, does the chip dump ROM when you tie the test pin to Vdd or do you have to do more?
|
|
|
|
Joined: Mar 2015
Posts: 240 Likes: 3
Senior Member
|
Senior Member
Joined: Mar 2015
Posts: 240 Likes: 3 |
One or more registers might be getting initialized differently in the emulation than in the actual games, or the game might read an address to seed the random # generator and that address returns a different value in the actual games. In the same vein, the hack to make arcade Ms Pac ROMs run on a Pac Man PCB makes the normal patterns not work because the random # generator uses the ROM contents. If it was random, I could probably chalk it up to any number of things... But these patterns actually seem pre-programmed, both Pac-Man and the ghosts move _exactly_ the same way _every_ time... Unless the 'random' pattern is seeded from a CPU clock/cycle or something. Since it starts up the same way every time (from off with no memory, and you can't delay the start of the demo), that might explain it. And MESS just getting a different start for some reason. At least they both duplicate their patterns consistently. Just thought it was weird.  For actual games, you leave the system on for a random amount of time before starting... Maybe that does explain it.
|
|
|
|
Joined: Mar 2002
Posts: 1,371 Likes: 132
Very Senior Member
|
Very Senior Member
Joined: Mar 2002
Posts: 1,371 Likes: 132 |
Could you make a quick youtube vid of it for both patterns? (tag as unlisted if you don't want it to show up in your channel)
Sean: I haven't checked out COP400 yet, but I will eventually. Or maybe another dev can make a driver for it. Good thing we have the CPU core emulation already.
About that Hitachi MCU: How does the pinout compare to HMCS42C? (HD44700)
|
|
|
|
Joined: May 2010
Posts: 1,051
Very Senior Member
|
Very Senior Member
Joined: May 2010
Posts: 1,051 |
The best the games can do is create a pseudo-random sequence, which will be exactly the same on every power up since the exact same code path is taken. Input timing can be used to seed the PRNG, but if no buttons are pressed, every run will be the same.
It should be easy enough to debug the code in MESS and see how the PRNG is seeded, and that may help figure out the difference between the two.
I hacked the Robotron ROMs to always read the player 2 start and move up inputs as set, then turned on both of my games. Since there was no user input to give timing differences to the PRNG, the 2 games played identically. But the same ROM in MAME plays differently since there isn't perfect low-level emulation of the entire Williams system.
In this case, I bet they are using an uninitialized register or RAM location to seed the PRNG, and it turns out that it's always powering up the same, but MESS is initializing it to a different value.
|
|
|
|
Joined: May 2010
Posts: 1,051
Very Senior Member
|
Very Senior Member
Joined: May 2010
Posts: 1,051 |
Hap- HD44700 is very similar to HD38702, except CMOS instead of PMOS, with a max voltage of 5.5V.
The HD38133 in Armor Battle has VDD on pins 1 and 21, OSC on pin 2, button inputs on pins 4-7, LED segments on pins 9-13 and 15-16, VSS on pins 3 and 14, LED rows on Pins 18-20 and 22-24, another button on pin 26, and the piezo connected to pins 27 and 28. 17 and 25 are no-connects, and 8 is tied to VDD through a resistor. I'm guessing one of the VDDs is reset and one of the VSSs is the test pin. It uses a 9V battery with no zener, so it's PMOS.
|
|
|
|
Joined: Feb 2015
Posts: 160 Likes: 6
Senior Member
|
Senior Member
Joined: Feb 2015
Posts: 160 Likes: 6 |
Interesting note on Entex Pac-Man 2... I have two of these here, both the same chip number (A23), and in demo mode, they both do the _exact_ same thing every time. I can turn them both on at the same time, and the pac-man and ghosts will follow the same pattern, every time. There's two different patterns- one is triggered by starting demo without the VFD test, and the other is triggered by doing the VFD test.
MESS does the same thing (two patterns, triggered by with or without the VFD test), but the patterns are completely different than what I get on the actual units...
Normal game play seems to work fine, just curious why the demo patterns would be different... Guessing it could be RAM contents? MESS probably initializes RAM to all 0's. the real chips might initialize it to randomish data that could be mostly 1's. At least it does the same two patterns every time which is a good thing. That means it most likely is working correctly or nearly so. Guess it'd be easy to try loading RAM with different contents to see what happens.
|
|
|
|
Joined: Feb 2015
Posts: 160 Likes: 6
Senior Member
|
Senior Member
Joined: Feb 2015
Posts: 160 Likes: 6 |
Kevin- glad to hear you're OK. Hope you got a new car! I did check out bitsavers and the datasheet archives, but didn't see that chip or any others more similar than the HD38702. That one has a test pin, and the Armor Battle chip has a couple of pins tied to Vss that I'll play with. On the Hitachi chips you are dumping, does the chip dump ROM when you tie the test pin to Vdd or do you have to do more? yeah I did. got another CRZ. had a 2011 but got a 2014 now. Dumping them is a huuuge pain in the ass. I am honestly not sure how I figured it out. If I hadn't dumped the D552/3 parts I don't know if I would've succeeded. It involves basically creating a jump tree and following the branches in a recursive fashion to find more banks, and then following said banks and stuff. all without resetting the program counter. frankly I'm surprised it works at all, but it does. Rik had pics of the inside of "monster burger" (and there's 3 other games in this series) with a D1080 in it, which is totally undocumented too. No clue what it is, except it must be a 4 bit CPU with LCD drivers.
|
|
|
|
Joined: May 2010
Posts: 1,051
Very Senior Member
|
Very Senior Member
Joined: May 2010
Posts: 1,051 |
I posted info on the Entex Space Invader LED game with the TMS-1100: www.seanriddle.com/tms1100.html
|
|
|
|
Joined: Mar 2002
Posts: 1,371 Likes: 132
Very Senior Member
|
Very Senior Member
Joined: Mar 2002
Posts: 1,371 Likes: 132 |
Cool, I'll get on it. Is this the black 1980 version or the grey 1981 version?
|
|
|
2 members (2 invisible),
164
guests, and
0
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
Forums9
Topics9,331
Posts122,199
Members5,077
|
Most Online1,283 Dec 21st, 2022
|
|
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!
|
|
|
|