Jump to content

Recommended Posts

It'd be really cool to autodetect the control scheme in software. Maybe a routine that requires moving a pointer on the title screen to a specified area before starting the game would provide a good place to do the detection

I already have something like that prepared. In Stella it works very well, on real hardware I can only test CX80 and Amiga mouse modes.

 

The main problem is, that usually you need separate ROMs for each of the three trackball encodings. So up the 8K original size, the result would fit into 32k. For larger ROMs we would need new cart designs.

Link to comment
Share on other sites

I already have something like that prepared. In Stella it works very well, on real hardware I can only test CX80 and Amiga mouse modes.

 

The main problem is, that usually you need separate ROMs for each of the three trackball encodings. So up the 8K original size, the result would fit into 32k. For larger ROMs we would need new cart designs.

I figured you might have to have a full ROM for each method to maintain the tight performance and timing of the game rather than adding a bunch of conditional calls. Too bad about that. Is self-altering code possible in the Harmony/Melody environment? :)

 

Is your testing limitation due to not having a "CX-22" trackball?

If you're a hardware guy at all with extra time on your hands, it looks to me as though one could build an external translator to give a CX-80 a new personality. Doesn't look too difficult on the surface.

Link to comment
Share on other sites

Too bad about that. Is self-altering code possible in the Harmony/Melody environment? icon_smile.gif

Yes, but a stock 32K cart is cheaper anyway. icon_smile.gif

 

Is your testing limitation due to not having a "CX-22" trackball?

If you're a hardware guy at all with extra time on your hands, it looks to me as though one could build an external translator to give a CX-80 a new personality. Doesn't look too difficult on the surface.

I do software only. icon_smile.gif
Link to comment
Share on other sites

 

Blue also recently made a modded version of Centipede for 7800 that retains Kenfused's earlier Trak-Ball code inside of it which was first used in the previously cited 7800 Centipede-TB by Kenfused. I think him and Walter also created a 7800 Millipede version also with that code as well. Check for it in the 7800 threads.

The "Millipede" is just a graphic hack. Neat, but none of the feature differences from Centipede, really.

  • Like 1
Link to comment
Share on other sites

I figured you might have to have a full ROM for each method to maintain the tight performance and timing of the game rather than adding a bunch of conditional calls. Too bad about that. Is self-altering code possible in the Harmony/Melody environment? :)

 

Is your testing limitation due to not having a "CX-22" trackball?

If you're a hardware guy at all with extra time on your hands, it looks to me as though one could build an external translator to give a CX-80 a new personality. Doesn't look too difficult on the surface.

Self altering code is definitely possible. It's called RAM.

 

Doubly confusing that we have CX-22s that don't function as trackballs at all and CX-80s (like mine) that function like CX-22s. I know this would add complexity but it may not hurt to do do the three 8k ROMs on a 32k cartridge with a simple selection menu. For homebrews like Colony 7 that originally supported joystick, a forth option for joystick mode might be added. Obviously this joystick mode would not be an option for commercial hacks.

 

Simply select an encoding format on the boot menu screen and a version of the game appropriate for your trackball is loaded. Maybe a fully fleshed out homebrew menu could offer a "test" mode to determine your control scheme for unknown trackball. A simple crosshairs cursor on screen and press fire on the controller to swap the cursor between joystick, CX-22, CX-80, and Amiga. Maybe this test screen plus the boot menu could be worked into an 8k ROM or less. Trackballs would need to be temporarily set to JS mode to navigate the menu, or a joystick plugged into the second controller port could be used to avoid the need to unplug the controller if the P1 trackball is hard wired.

 

If the player should pick the wrong version of the ROM, just toggle the power switch or press select and reset together to reset back to the menu. 32k boards won't add much cost over 8k ROMs and it prevents costly returns to the AA store for people who mistakenly ordered the wrong cart version.

  • Like 1
Link to comment
Share on other sites

It'd be really cool to autodetect the control scheme in software. Maybe a routine that requires moving a pointer on the title screen to a specified area before starting the game would provide a good place to do the detection. It's a lot easier to say than to do. Maybe if I ever get around to writing a game that supports the trackball I'll tackle that.

 

Yeah, right...if I ever did write a game, I'd probably stick to paddles and leave the tricky stuff to the expert coders.

Paddles are a pain in the ass. Trackballs are not too bad.

 

I originally suggested autodetection with a start up screen telling the user to spin a track ball in a certain direction. I could not implement my own idea for the reasons Thomas said, plus cycles were way too tight to look up different tables. It was way easier to make separate roms. In some games it might work out to autodetection, but Millipede and SW Arcade no.

Link to comment
Share on other sites

Yes, there's such a thing as self-altering code if the code is loaded into RAM. I was merely pointing out that one program image to handle all encoding methods might be possible with self-altering code if the programmer were willing to constrain the environment to that available in the Harmony/Melody cartridge. He wasn't and I didn't really expect him to be.

 

If there's no automatic detection of the controller's protocol, the controller itself could not be used to make the necessary selection.

The only thing that would reliably work would be the fire button.

The menuing system could automatically alternate through the choices and have the user press the fire button when the right one is indicated.

Maybe a short tap could be used to alternate through the choices and a longer press would select the chosen option.

 

I lean heavily in favor of autodetection if the space and cycles are available. Would be more elegant (and impressive to certain nerdy types...like me). :)

 

[Edit: typos and formatting]

Edited by BigO
Link to comment
Share on other sites

Paddles are a pain in the ass. Trackballs are not too bad.

 

I originally suggested autodetection with a start up screen telling the user to spin a track ball in a certain direction. I could not implement my own idea for the reasons Thomas said, plus cycles were way too tight to look up different tables. It was way easier to make separate roms. In some games it might work out to autodetection, but Millipede and SW Arcade no.

I suppose with respect to having to initiate an event then keep checking for it to terminate, paddles would be a pain. But, I've implemented that same scheme on a microcontroller to read a pot position and it wasn't bad. Though, I am not burdened with the constraints of having to spit all of those scan lines out in an exact amount of time so that would make it several orders of magnitude more complex.

 

Based on one experience reading a trackball with a PIC, you have to be really careful to be sure you don't miss any transitions. That's why I thought trackball would be tougher in the 2600 world.

 

Would you really have to roll the ball in a specified direction to autodetect? Without actually having to prove it, I can speculate that polling the port at a fast enough rate would allow you to detect specific patterns. If it were just a matter of detecting CX-22 (decoded) vs CX-80 (raw Gray), you might be able to figure it out. Not sure about that scheme that dumps Gray code, but puts the bits in a different place...

 

With the CX-22 flavor, the telltale would be that (for one axis) one bit changed values more than once while the other bit didn't change. Direction stays static while the clock bit goes through several cycles. This would happen with a very small movement of the ball. Whether or not you could poll those ports that intently while maintaining some sort of image on the screen, I don't know.

 

Just rambling thoughts by a guy who won't actually try to code any of this. That's how I maintain bug free code. :)

 

I will be interested in seeing Thomas' implementation.

Edited by BigO
Link to comment
Share on other sites

Just wanted to drop in and say thanks for the three awesome conversions. I hadn't even heard of this work until last week, just before I got to play them on a 2600 dedicated to Trak-Ball games, courtesy of Albert at the Houston Arcade Expo. Centipede and Millipede were already great conversions but now they are even better, while Reactor is an almost-entirely different, yet much more enjoyable game!

 

I don't think the programming and hacking wizards on this forum will ever cease to amaze.

  • Like 2
Link to comment
Share on other sites

 

If there's no automatic detection of the controller's protocol, the controller itself could not be used to make the necessary selection.

The only thing that would reliably work would be the fire button.

[Edit: typos and formatting]

There is a switch on the CX-22 and CX-80 trackballs to make it emulate a Joystick. Despite this, for some reason, I find it nearly impossible to navigate the Harmony menu in this mode, however to just to select one of three menu items with the trackball in JS mode, hit FIRE, and switch back to TB mode to play the game would be doable. I think only the Amiga mouse would require actual hot swapping to plug in a joystick. The issue with "only the fire button can be used" is also easily remedied by using the console SELECT switch to highlight menu items and RESET to start game. Maybe joystick inputs could even be ignored by the selection menu to prevent malfunction when using trackballs.

 

As much as I would love to buy the Centipede and Millipede hacks in the AA store, Albert would be wise to look into doing a 3-in-1 menu for use with these hacks so that people who order the wrong cart don't need to return it for various reasons, such as a CX-80 behaving as CX-22 like mine. Also would be great for collectors with more than one trackball or mouse device.

  • Like 1
Link to comment
Share on other sites

As much as I would love to buy the Centipede and Millipede hacks in the AA store, Albert would be wise to look into doing a 3-in-1 menu for use with these hacks so that people who order the wrong cart don't need to return it for various reasons, such as a CX-80 behaving as CX-22 like mine. Also would be great for collectors with more than one trackball or mouse device.

Yes, this is something I've already spoken to Thomas about, well before these new Trak-Ball hacks appeared (wanted to do that for Missile Command).

 

..Al

  • Like 1
Link to comment
Share on other sites

Would you really have to roll the ball in a specified direction to autodetect? Without actually having to prove it, I can speculate that polling the port at a fast enough rate would allow you to detect specific patterns. If it were just a matter of detecting CX-22 (decoded) vs CX-80 (raw Gray), you might be able to figure it out. Not sure about that scheme that dumps Gray code, but puts the bits in a different place...

Here is my original idea:

 

 

 

It would also be nice to start with a screen that says "Spin Trackball Left" at power-on. Then capture which states the trackball goes through and decide which trackball profile to use, and start the game. It would be easy to avoid any wrong detections by waiting for multiple confirmations before locking in the profile.

It's simple to do. I arbitrarily chose a direction.

 

 

It won't work for Millipede though. Not enough rom space left. Some other games might be candidates.

Link to comment
Share on other sites

Whoo-hoo, just scored 88082 pts in Millipede TB. New personal record!!! :grin:

 

EDIT: What's the dealio? Am I regressing? I start on 30000, score 88000 points and it lets me restart at 60000. I make it to 73000 and it makes me start at 45000. Then I screw up and game over at 50-something and it won't let me start past 30000. I want another whack at 60000... :???:

 

EDIT2: Just made 88099, besting my personal "best" by 17 points! :P

 

EDIT3: Holy Freakking Cow! Six digits! 129,706 points! :o (starting score of 60000)

post-33189-0-46492100-1447908813_thumb.jpg

Link to comment
Share on other sites

Glad you're having fun with Millipede. :) I never played it before converting it. I really got was amazed how crazy the action gets. The original programmer did a great job IMHO to squeeze all of that in. It was really tough to find enough free cycles...

 

 

 

I'm hoping someday someone will post some high scores using a ST Mouse or Amiga Mouse. I don't know if Millipede will start freezing up with those roms at really high scores (~160,000 points).

Link to comment
Share on other sites

I find it nearly impossible to navigate the Harmony menu in this mode, however to just to select one of three menu items with the trackball in JS mode, hit FIRE, and switch back to TB mode to play the game would be doable. I think only the Amiga mouse would require actual hot swapping to plug in a joystick.

You can use the console switches (SELECT and RESET) for navigation too.
Link to comment
Share on other sites

EDIT: What's the dealio? Am I regressing? I start on 30000, score 88000 points and it lets me restart at 60000. I make it to 73000 and it makes me start at 45000. Then I screw up and game over at 50-something and it won't let me start past 30000. I want another whack at 60000... :???:

I just re-read this. The original game does this also, and I think it's to help the player beat their score. It uses your last score to decide where to start so it won't allow you another whack at 60000 if you died before that on your last score. I think it works fine like it is. :)

Link to comment
Share on other sites

I will be interested in seeing Thomas' implementation.

At the moment the code is pretty simple:

 

I am polling all three models in parallel and calculate positions from that. Then I count how far each position has moved away from start (horizontally and vertically). The first model which exceeds a minimum distance in both directions wins. For that distance I found 20-30 pixel to be sufficient, so you don't have to move the track ball a lot for detection.

 

For now, this works on an all blank screen, only the background color changes when the right model is detected. Then you can press fire and the correct version of MCTB starts. Pretty cool. :)

 

For doing that during a title screen I have to optimize the polling a bit.

  • Like 1
Link to comment
Share on other sites

Glad you're having fun with Millipede. :) I never played it before converting it. I really got was amazed how crazy the action gets. The original programmer did a great job IMHO to squeeze all of that in. It was really tough to find enough free cycles...

 

 

 

I'm hoping someday someone will post some high scores using a ST Mouse or Amiga Mouse. I don't know if Millipede will start freezing up with those roms at really high scores (~160,000 points).

 

I'd be afraid these games would eventually destroy the buttons on both the ST and Amiga mice. :)

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...