Crimson Editor, Stella.exe, and paddles

[Fort Apocalypse]

Having trouble getting paddle emulation to work... (all paddles read as 0- can't even get first paddle to work).

 

The "argument" line in crimson editor for running stella.exe I have set to:

 

-bc Paddles -paddle 0 -grabmouse 0 -showinfo 1 -p0speed 20 $(FilePath).bin

 

Does that look right for mouse emulation? Has anyone gotten paddle emulation via mouse to work when starting stella.exe from crimson editor, and if so could you post your argument line from crimson editor tools -> preferences -> tools -> user tools?

 

Am I going to have to buy a stelladaptor and paddles to get this to work?

[SeaGtGruff]

Having trouble getting paddle emulation to work... (all paddles read as 0- can't even get first paddle to work).

 

The "argument" line in crimson editor for running stella.exe I have set to:

 

-bc Paddles -paddle 0 -grabmouse 0 -showinfo 1 -p0speed 20 $(FilePath).bin

 

Does that look right for mouse emulation? Has anyone gotten paddle emulation via mouse to work when starting stella.exe from crimson editor, and if so could you post your argument line from crimson editor tools -> preferences -> tools -> user tools?

 

Am I going to have to buy a stelladaptor and paddles to get this to work?

You don't need to buy anything or change any command line settings. Just code your game, compile it, and run it in Stella. Then, when it's running, press TAB to get the menu, and select GAME PROPERTIES. Go to the CONTROLLER tab and set the desired controller(s) to PADDLES. Then click OK and EXIT MENU. Finally, press BACKSLASH (\) and click RELOAD ROM. From now on the game will run in Stella using the paddle controller(s)-- until you change the code and recompile it, which will cause Stella to "see" the game as a different ROM (different binary image with different checksums, etc.), so you'll need to go through the process again.

 

Michael

[+stephena]

Having trouble getting paddle emulation to work... (all paddles read as 0- can't even get first paddle to work).

 

The "argument" line in crimson editor for running stella.exe I have set to:

 

-bc Paddles -paddle 0 -grabmouse 0 -showinfo 1 -p0speed 20 $(FilePath).bin

 

Does that look right for mouse emulation? Has anyone gotten paddle emulation via mouse to work when starting stella.exe from crimson editor, and if so could you post your argument line from crimson editor tools -> preferences -> tools -> user tools?

 

Am I going to have to buy a stelladaptor and paddles to get this to work?

While what SeaGtGruff said above will work, it means you'll have to manually do it every time the ROM changes (ie, when it's recompiled). However, if you're a programmer working from with a development environment, you'll probably be constantly recompiling and testing. Having to manually change the ROM properties in this case is very annoying, and is exactly why the commandline arguments were added in the first place.

 

The correct usage would just be '-bc paddles'. The '-paddle 0' isn't really needed, since it's the default. The '-p0speed' is only used when emulating paddle movement with the cursor keys (ie, digital emulation of paddle movement), so you can leave that out too.

 

If it doesn't work after that, it's either a bug in Stella (which I can't duplicate), or an error in passing parameters from your editor to Stella (Crimson Editor people would have to look into that).

 

EDIT: The advice above from SeaGtGruff will be useful once you're ready to release a completed ROM into the public. Personally, it makes more sense to me to use the commandline options when you're constantly making source code changes, and generate a properties entry once the ROM is finalized (not that doing the latter too often will hurt; it'll just generate a lot of needless properties entries that may slow down startup time of the app).

Edited September 7, 2007 by stephena

[SeaGtGruff]

While what SeaGtGruff said above will work, it means you'll have to manually do it every time the ROM changes (ie, when it's recompiled). However, if you're a programmer working from with a development environment, you'll probably be constantly recompiling and testing. Having to manually change the ROM properties in this case is very annoying, and is exactly why the commandline arguments were added in the first place.

 

The correct usage would just be '-bc paddles'.

That's an excellent point, and the command line option is good to know.

 

One thing I'd like to add is that when I'm working on a game that requires special emulator properties, I'll often set up a new "user tool" in Crimson Editor just for that game, so I don't have to change the generic "one size fits all" tool that I normally use. For example, I might have one tool that says "Run program in Stella," and another that says "Run Sudoku in Stella" (or whatever the "special" program is). Note that this isn't necessary so much anymore with the auto-detection logic, but obviously that doesn't cover controllers, just cartridge formats. But with z26 it's often necessary to specify any non-standard cartridge type with a command line switch.

 

doing the latter too often will hurt; it'll just generate a lot of needless properties entries that may slow down startup time of the app).

Yes, that's another good point.

 

Michael

[+stephena]

While what SeaGtGruff said above will work, it means you'll have to manually do it every time the ROM changes (ie, when it's recompiled). However, if you're a programmer working from with a development environment, you'll probably be constantly recompiling and testing. Having to manually change the ROM properties in this case is very annoying, and is exactly why the commandline arguments were added in the first place.

 

The correct usage would just be '-bc paddles'.

That's an excellent point, and the command line option is good to know.

This was a much requested feature a few years ago. Since I didn't personally develop ROMs with Stella, the thought never occurred to me to be able to change properties dynamically. To get around this, some people were even ingenious enough to create a script that recalculated the new ROM MD5 and rewrite a new stella.pro file, just to get the ROM to recognize the previous properties. I can see that being a PITA. I'd like to think I've learned my lesson on that one, since damn near everything in Stella is now configurable from both the commandline and UI

[Fort Apocalypse]

While what SeaGtGruff said above will work, it means you'll have to manually do it every time the ROM changes (ie, when it's recompiled). However, if you're a programmer working from with a development environment, you'll probably be constantly recompiling and testing. Having to manually change the ROM properties in this case is very annoying, and is exactly why the commandline arguments were added in the first place.

 

The correct usage would just be '-bc paddles'.

That's an excellent point, and the command line option is good to know.

This was a much requested feature a few years ago. Since I didn't personally develop ROMs with Stella, the thought never occurred to me to be able to change properties dynamically. To get around this, some people were even ingenious enough to create a script that recalculated the new ROM MD5 and rewrite a new stella.pro file, just to get the ROM to recognize the previous properties. I can see that being a PITA. I'd like to think I've learned my lesson on that one, since damn near everything in Stella is now configurable from both the commandline and UI

 

Thanks, Michael and Stephen! Will give it a try!

[Fort Apocalypse]

Unfortunately I still can't get it working.

 

I tried what Michael said and what Stephen said and all paddles always equal 0. I even tried mapping keys to the paddles, which I'd rather use since it is a 4 player game and I'd like to emulate more than one paddle at once if possible, but that didn't work either. I made sure controllers were both set to paddle in the Stella green screens and reloaded the rom also. Tried starting with -bc paddles and saw that it was set to paddles in green screen which was good, didn't work, I tried reload and didn't work.

 

Attached is the source and bin I'm having trouble with. Stella 2.3.5 and bB 1.0.

 

(note: this is the same that I just posted in the other thread about the player 3 sprite issue)

 

Thanks in advance!

 

ultindy500_0.1.basultindy500_0.1.bin

Edited September 8, 2007 by Fort Apocalypse

[SeaGtGruff]

Unfortunately I still can't get it working.

D'oh, I think I see your problem! "readpaddles" is a kernel option, but you're using the multisprite kernel, and the kernel options don't work with the multisprite kernel, just with the standard kernel.

 

Michael

[Fort Apocalypse]

Unfortunately I still can't get it working.

D'oh, I think I see your problem! "readpaddles" is a kernel option, but you're using the multisprite kernel, and the kernel options don't work with the multisprite kernel, just with the standard kernel.

 

Michael

 

Does that mean I can't use paddles with the multisprite kernel? That would suck.

[CurtisP]

Does that mean I can't use paddles with the multisprite kernel? That would suck.

 

Unfortunately it is the case. If you really want to use paddles, though, you might be able to do it with some ASM in the VBLANK routine.

 

Personally, I find the multisprite kernel to be overrated

[SeaGtGruff]

Personally, I find the multisprite kernel to be overrated

Well, consider that the standard kernel was around for a while before any nifty kernel options were added to it. The multisprite kernel hasn't been around very long yet. Eventually we may see a few nifty kernel options added to the multisprite kernel, too.

 

Michael

[Fort Apocalypse]

Unfortunately it is the case. If you really want to use paddles, though, you might be able to do it with some ASM in the VBLANK routine.

 

Could anyone provide some sample asm code that I could include within a subroutine of batari basic to do this? Unfortunately my eyes still glaze over with asm. If not, if anyone could point me in the right direction that would help.

 

In addition, it would be super awesome if it were added as the first (and only?) kernel option for multisprite in a bB 1.1 release, as not only would it allow people to more easily write 4 player racing games, but 4 player pong games with 2 balls (ball and missle), a warlords-like game (without the bricks, since there is no pfread or pfpixel in multisprite kernel), 4 player planetary defense, and you could build a new paddle-based turret controller and shoot at 6 sprites at once (by using a blinking ball and missle for the targets).

Edited September 8, 2007 by Fort Apocalypse

[CurtisP]

In addition, it would be super awesome if it were added as the first (and only?) kernel option for multisprite in a bB 1.1 release, as not only would it allow people to more easily write 4 player racing games, but 4 player pong games with 2 balls (ball and missle), a warlords-like game (without the bricks, since there is no pfread or pfpixel in multisprite kernel), 4 player planetary defense, and you could build a new paddle-based turret controller and shoot at 6 sprites at once (by using a blinking ball and missle for the targets).

 

A paddle is read by setting a bit in VSYNC, then counting down until the appropriate register is zero. It can take nearly a whole frame for this register to clear, so the register is checked by the kernel each time it draws a new scanline. It takes 10 cycles to check one hardcoded paddle and 18 cycles to check a paddle selected by the code. The largest empty space I could find is 7 cycles.

 

So, no paddle for you!