I came across a post on marpirc where Stephen Krogman recounts his visit to the Classic Gaming Expo in Las Vegas (1999) where he watched Mitchell play Pac-Man, Donkey Kong, and Burger Time on a MAME cabinet - I think it’s made by a company called Hanaho - he describes a PC/Home configuration and a stand up version.

http://www.marpirc.net/viewtopic.php...e746b9fa#p1797

In a follow-up post from John Rhodes, he describes the product as the Arcade 2000 (but upon some brief research it looks like it's more properly called an ArcadePC) - the game was played through MAME DOS 35 via Arcade@Home front end. Does anyone have familiarity with this product? I was curious if the product permitted user intervention along the lines of MAME saves states, etc.

Here's a link to Hanaho's website, November 1999:

https://web.archive.org/web/19990821...ePC/index.html

Originally Posted by NickWalker

The non-standard refresh rate of Donkey Kong is listed in Nintendo's operation manual, see the bottom of p. 17, it lists the crystal at 61.44 Hz (I don't know why I kept thinking 60.6, I guess it was in the previous thread).

There's definitely something I do not understand about how video refresh rate is wired to the game's performance. I've sought out some Donkey Kong PCB repair videos, but do not have a good understanding of how that purpose-built computer varies from more general purpose Z80-based computers.

Presumably the Z80A in Donkey Kong has a crystal in the MHz range, so the video refresh could just be counted off from that faster clock. I've seen references to that CPU clock crystal being 6 MHz. Some Z80As are rated at 4 MHz.

Here's the MAME 0.116 xml for DKONG.

Code:

    
        Donkey Kong (US set 1)
        1981
        Nintendo of America
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
        
            
        
        
            
            
            
            
        
        
            
            
            
            
        
        
            
            
            
            
            
            
            
            
        
        
            
            
        
        
    

That 60.606061 Hz shows up in the splash as well.

Edited to add:
Then again, the video signal could be produced by a mostly independent circuit, on its own clock. It would need to look at shared video memory, but that should not present a problem for the CPU if its not going to touch. If some EE has already torn one down on video, please let me know where I can see it.

The 61.44 Hz crystal is only for the video hardware and has nothing to do with the Z80, which has its own crystal.

Originally Posted by The Evener

I came across a post on marpirc where Stephen Krogman recounts his visit to the Classic Gaming Expo in Las Vegas (1999) where he watched Mitchell play Pac-Man, Donkey Kong, and Burger Time on a MAME cabinet - I think it’s made by a company called Hanaho - he describes a PC/Home configuration and a stand up version.

http://www.marpirc.net/viewtopic.php...e746b9fa#p1797

In a follow-up post from John Rhodes, he describes the product as the Arcade 2000 - the game was played through MAME DOS 35 via Arcade@Home front end. Does anyone have familiarity with this product? I was curious if the product permitted user intervention along the lines of MAME saves states, etc.

Here's all the versions of MAME 0.35, scroll down to January-July 1999. I used MAME back then and it did indeed provide save states, although they did not work perfectly in all games. That's why in my first post I suggested it might be easier to edit a video together but based on the discussions on MARP it seems people were already able to build INP files while saving/loading states.

One thing I remember in early MAME is that loading a state would often get the audio out of sync (maybe because they were still figuring out how best to implement multiple CPUs?) but if you aren't recording audio then it's not an issue.

Here's a link to an overview of the ArcadePC product, circa September 1999. Interestingly, the cabinet can be (or is) configured so the PC sits in plain site, a keyboard draw slides out from under the panel. This product would be a compelling platform since you're not playing MAME on a computer keyboard but are using arcade quality sticks and buttons.

https://aburt.com/arcadepc/

That said, it's not a huge stretch to imagine someone opting for a traditional PC configuration using the company's Hot Rod control panel:

https://web.archive.org/web/19991004...otRodJoystick/

Originally Posted by The Evener

In a follow-up post from John Rhodes, he describes the product as the Arcade 2000 (but upon some brief research it looks like it's more properly called an ArcadePC) - the game was played through MAME DOS 35 via Arcade@Home front end. Does anyone have familiarity with this product? I was curious if the product permitted user intervention along the lines of MAME saves states, etc.

If that "35" is referring to version 0.35, that would represent a fast-moving period in MAME development, there where several version 0.35s as they used a suffixing scheme for a bit before going back to a serial number. The MAME 0.35 epoch, judging from release notes, was uneventful for DKONG, with only a conversion from SAM to WAV samples. The rom set was staid throughout and two years beyond.



Sorry--can't figure out tables in BBEdit. Oh--while I'm on a tangent, does anyone know how to turn off those automatic wiki link pop-ups for words like MAME, Donkey Kong, version and people?

There are several indications that MAME 0.35 does not have state states. I know that MAME 0.53 can do that a couple of years later, but there's no talk of it in the release notes before that point. I'll see if I can get something running to confirm one way or the other.

Originally Posted by grinder2112

There are several indications that MAME 0.35 does not have state states. I know that MAME 0.53 can do that a couple of years later, but there's no talk of it in the release notes before that point. I'll see if I can get something running to confirm one way or the other.

Sorry I don't mean to side-track the discussion since Mitchell's first "public reveal" of a million point game occurred in 2004 in NYC; in this context, updates to any stock MAME version installed in 1999 wouldn't be out of the question at all.

In terms of what MAME 0.35, here's a link for reference to the creation of a MAME .35 TG version which had some anti-cheating measures built in:

http://www.marpirc.net/viewtopic.php...a881b3d1#p2663

Originally Posted by The Evener

I was curious if the product permitted user intervention along the lines of MAME saves states, etc.

The earliest canonical version of MAME that includes save states appears to be 0.37b13 aka 0.49. It's the first binary package that creates a sta folder when unpacked. It barely runs in a Windows XP emulator, but allows the creation of a *.sta file with the usual Shift-F7, then slot select key combo. 0.37b12 aka 0.48 does not unpack a sta folder, nor respond to Shift-F7 to create a *.sta file.

Edited to add: MAME DOS 0.35 does not save state with Shift-F7 or through any other means I can discover within the program or its documentation. (I forgot I had a DOSbox install with WFW 3.11 so I can get my Icebreaker on.)

Originally Posted by The Evener

Sorry I don't mean to side-track the discussion since Mitchell's first "public reveal" of a million point game occurred in 2004 in NYC; in this context, updates to any stock MAME version installed in 1999 wouldn't be out of the question at all.

No apology necessary--I don't feel side-tracked at all. The circumstances of this dispute are a confluence of varied and long-held interests, making this topic irresistible.

Originally Posted by grinder2112

The earliest canonical version of MAME that includes save states appears to be 0.37b13 aka 0.49.

Gross, I'm quoting myself. It looks like the save/load state is broken, for DKONG at least, in MAME 0.37b13 aka 0.49. It appears to be working in the very next version, MAME 0.37b14 aka 0.50 (April 7, 2001).

Why would Billy get Carlos to try and reproduce a girder finger on original arcade hardware if he really understood why the finger girder appeared in the first place?

Did he just not know, and hold out some small hope that it was possible? Was he stalling for time to create the 'evidence package'? Was he trying to create doubt and uncertainty?

I ask because ultimately it was a very bad idea that truly helped seal his fate. It really looks like the charge of the light brigade.

And then to try and get Carlos to lie in a written statement? yeesh. How do we make sense of it all when there's so much lying.