Jump to content
IGNORED

Playaround Demo


JerryG

Recommended Posts

Thanks to Rick and his loaned dumper the Playround Demo cart that I have has been dumped. It is attached below.

 

I obtained this cart in the mid 90's. It was purchased at a flea market on East Division Street in Portland, OR during the time I lived in Beaverton, I got it from a regular vendor, not a vendor specializing in games. One day I was there to visit a regular game vendor who came up with good finds from time to time and saved them for me. I decided to look around the market and in doins so got into a conversation with an old-timer who had a stand. When I mentioned I was looking for video games he said he had an X-rated game. When I asked to see it I saw right away that it was something unusual because it was in a single ended case with a Playaround molded into it. I knew that there were no single ended Playaround carts found to date so I immediately wanted to buy the cart. The vendor told me that he originally had two different carts but that sum guy had come by earlier and bought the other one. For some reason the guy didn't want both carts so I lucked out.

 

By the way, I paid $10 for the cart, not a cheap price for a flea market cart in those days!

 

Here it is, enjoy!

 

JerryG

Playaround_Demo_Cart.bin

Link to comment
Share on other sites

Here is something interesting that should be noted, when you press reset, a new set of logos come out, but the old ones stay on the screen until the new logos come pass them by (see the screen shot). When you press reset, then toggle from Black and White to Color (or from color to black and white), the screen gets cleared.

post-12776-1245956657_thumb.png

Link to comment
Share on other sites

Here is something interesting that should be noted, when you press reset, a new set of logos come out, but the old ones stay on the screen until the new logos come pass them by (see the screen shot). When you press reset, then toggle from Black and White to Color (or from color to black and white), the screen gets cleared.

 

Take it for Playaround to find a bug in Stella!

Link to comment
Share on other sites

Here is something interesting that should be noted, when you press reset, a new set of logos come out, but the old ones stay on the screen until the new logos come pass them by (see the screen shot). When you press reset, then toggle from Black and White to Color (or from color to black and white), the screen gets cleared.

 

Take it for Playaround to find a bug in Stella!

Yes, this bug was recently reported in Q-Bert as well. It seems to be related to how Stella treats WSYNC. Since this is a TIA issue, and that part of the code is in flux right now, I've pushed the fix to the 3.0 release (which will have updated TIA code).

Link to comment
Share on other sites

Here is something interesting that should be noted, when you press reset, a new set of logos come out, but the old ones stay on the screen until the new logos come pass them by (see the screen shot). When you press reset, then toggle from Black and White to Color (or from color to black and white), the screen gets cleared.

 

Take it for Playaround to find a bug in Stella!

Yes, this bug was recently reported in Q-Bert as well. It seems to be related to how Stella treats WSYNC. Since this is a TIA issue, and that part of the code is in flux right now, I've pushed the fix to the 3.0 release (which will have updated TIA code).

 

I knew it looked too good to be true :( I can't wait for stella 3.0 BTW!

Link to comment
Share on other sites

A rough disassembly reveals that there is a checksum routine present to discourage hacks (just perform an RTS immediately to bypass...or don't bother JSR'ing there in the first place). Also, the logo is stored seperately for each position between the "positions" ;) and a huge color table at the end of rom keeps things shifting for a while. A Mystique logo is also present...but it doesn't look like the pointers to which image to use ($DC-$E3) are allowed to reach it.

Playaround_Demo.zip

Link to comment
Share on other sites

I was also doing a disassembly, but been too busy to post anything.

 

Some of the interesting things about the demo are:

 

- It uses a checksum. Very few Atari games do this. Looking at the indirect jump that follows, you notice that the origin is different. Looking at the code it seems to serve no pupose to switch origins. However a quick check with HOM3 reveals a very similar checksum routine in Bachelor Party.

- The entire ram space is preloaded in the clearing routine.

- A hidden Mystique Logo is present.

 

 

Here's my impartial disassembly. I'm going to look at Nukey's right after this. I am right in the middle of move, so I've been working on this just here and there.

 

 

Play_re_.zip

 

The Mystique logo is strange in that it is inverted, meaning the figures couldn't be displayed on lines close above it (unlike the Playaround figures)

 

 

;	normal
;
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX
;	XX  XXX  XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX
;	XX X X X XXXXXXXXXXX	 XXXXXXXXXXXXXXXXXXXXX
;	XX X X X XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX
;	XX XX XX XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXX
;	XX XX XX XXXXXXXXXXXXX XX XXXXXXXXXXXXXXXXXXXX
;	XX XX XX XX XX XX   XX XXXXXX   XX XX XXX  XXX
;	XX XXXXX XX XX XX XXXX XX XX XX XX XX XX XX XX
;	XX XXXXX XX XX XX   XX XX XX XX XX XX XX	XX
;	XX XXXXX XX XX XXXX XX XX XX XX XX XX XX XXXXX
;	XX XXXXX XX XX XXXX XX XX XX   XXX XX XX XXXXX
;	XX XXXXX XX XX XX   XX XX XXXX XXXX  XXXX  XXX
;	XXXXXXXXXXXX   XXXXXXXXXXXXXXX XXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXX XXXXXXXXXXXXXXXX XXXXXXXXXXXXXX
;	XXXXXXXXXXXXX XXXXXXXXXXXXXXXXX XXXXXXXXXXXXXX
;	XXXXXXXXXXXXX XXXXXXXXXXXXXXXXXX	XXXXXXXXXX
;	XXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXX	XXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXX	 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;	XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
;


;	inverted
;
;
;
;
;
;
;
;
;
;						  X
;						  X
;	  XX   XX			 X
;	  X X X X		   XXXXX
;	  X X X X			 X
;	  X  X  X			 X
;	  X  X  X			 X  X
;	  X  X  X  X  X  XXX  X	  XXX  X  X   XX
;	  X	 X  X  X  X	X  X  X  X  X  X  X  X
;	  X	 X  X  X  XXX  X  X  X  X  X  X  XXXX
;	  X	 X  X  X	X  X  X  X  X  X  X  X
;	  X	 X  X  X	X  X  X  XXX   X  X  X
;	  X	 X  X  X  XXX  X  X	X	XX	XX
;				XXX			   X
;				  X				X
;				 X				 X
;				 X				  XXXX
;				X
;	   XXXX	 X
;		   XXXXX
;

Link to comment
Share on other sites

That Mystique logo is unknown to me.

 

Could this be the oldest Mystique logo?

Rom, this is a very tall logo, it probably wasn't used in a regular game.

 

 

Perhaps Mystique used this demo as well to promote their first games before they switched to PlayAround?

Ding, ding, ding goes the bell!

 

 

But more analysis of the rom is needed. Strange things are happening in there, like the Ball being enabled (but never used), and collisions checked between the missiles and playfield (which are also not used).

Link to comment
Share on other sites

I agree....it's almost as if a very vague skeleton of a kernel was cut into ribbons and used to display the images. If a game were in the process of being made, I guess it would have served as the demo as well. Maybe look for similarities between this and the rest of their programs. Kind of a longshot, I know. But why would you need a checksum routine for a demo?? Maybe to verify that the method works? But surely, earlier games already proved that...unless...

Link to comment
Share on other sites

I doubt that it was a specific game or concept...maybe a "sketchpad" of sorts to verify that the subroutines work as intended? Is it possible that parts of this demo predates the rest of their stuff?

 

BTW the "playaround" logos displayed are all using their own GFX bitmaps. There's room for a couple more as well, but the pointers look like they are only given a range of 0-7 (the 4 images and the 4 logos). Every image is using it's own dedicated routine to display. Oddly, the "Mystique" logo is the only one that is set to use indirect addressing (i.e. a generic routine, that is set up to display ONLY that image). It doesn't look like it is ever called tho. When fetched from ram $DC-E3 @$F105, the Y register would need to be a value of 8 to show the Mystique logo.

 

The main reason that is odd is because that same generic routine could have been used to display all of the other images very easily (just reload the vectors, since the pointers are already known)...saving all of that romspace ate up by dedicated loops.

 

Weird.

Link to comment
Share on other sites

But why would you need a checksum routine for a demo?? Maybe to verify that the method works? But surely, earlier games already proved that...unless...

Maybe they had a cheap eprom programmer that didn't verify the eproms.

 

Verifying the EPROMs is a completely different subject, the checksum routine was present in the Mystique/Playaround games so the game would crash if any byte was changed.

Link to comment
Share on other sites

A checksum routine is pretty easy to defang. I've done it myself, and I'm no great shakes at assembly. So I thought there might be an alternate reason.

 

This checksum causes a blank screen and bad rolling if it fails. I just thought it might be a way to flag a partial bad burn that might otherwise have subtle effects, saving the programmer from tearing his hair out over a bug that isn't there.

 

...But if it's known for sure that the purpose of the checksum is anti-tamper, then nevermind. :)

Edited by RevEng
Link to comment
Share on other sites

A checksum routine is pretty easy to defang. I've done it myself, and I'm no great shakes at assembly. So I thought there might be an alternate reason.

 

This checksum causes a blank screen and bad rolling if it fails. I just thought it might be a way to flag a partial bad burn that might otherwise have subtle effects, saving the programmer from tearing his hair out over a bug that isn't there.

 

...But if it's known for sure that the purpose of the checksum is anti-tamper, then nevermind. :)

 

I see what you mean now, the checksum was probably calculated before programming the EPROMs though.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...