Idea for the next version of Stella (if possible)

[Syntaxerror999]

My idea is for support for a DIY adapter to run games directly off cartridges. It could be something as complex as a USB device... Or a parallel printer port (not that many computers have them these days) theoretically is should be possible... Although how much demand for it is the big question. Input?

[olivil]

Maybe a plugin for the Retrode!

 

https://www.retrode.org

Edited August 8, 2013 by olivil

[+stephena]

This is outside the domain of Stella. The emulator itself expects a ROM file, or IOW, a block of data in a specific format. Getting that data from a real cart is essentially the job of a hardware cart-reader, which is basically how all the ROMs floating around came into existence in the first place. If someone designed that, it would be an easy enough job to write a small program that 'rips' the ROM data from the cart, and launches Stella with that data. But the hardware cart-reader itself, and the software that interfaces with it, are separate from Stella and don't really belong in the emulator at all.

[+FujiSkunk]

But the hardware cart-reader itself, and the software that interfaces with it, are separate from Stella and don't really belong in the emulator at all.

 

So sayeth the Stella maintainer. But no matter who said it, I agree.

 

Actually an adapter for the Retrode has already been designed. There aren't enough parts available for the Retrode team to sell them preassembled, but you can buy a Retrode and then create the 2600 adapter yourself. See here.

[enthusi]

I think it would be too slow to actually play a game in an emulator FROM eprom. On real hw everything happens in realtime (i.e. bankswitching) and data-fetches etc.

So adressing the EPROM and reading back from it (into the emulator) must not cause ANY delay.

[+Gemintronic]

Yeah. I think the O.P. needs to forward his idea to the Retrode dude.

 

Here are some software suggestions as an example of what Stella could be changed to do:

 

* Not defaulting to enabling the mouse so trackpads don't screw with your game.

* A wrapper mode for Stella that encapsulates a single game as an .EXE or .APK for Android.

* Capture video to .AVI

[Thomas Jentzsch]

* Not defaulting to enabling the mouse so trackpads don't screw with your game.

Can't be too much work to change the default in your setting once, or is it?

[+Gemintronic]

Can't be too much work to change the default in your setting once, or is it?

 

It is. I install Stella on many machines - some my own and some for play testers. Getting false bug reports because of this behavior is very annoying. I myself forget Stella is set up this way and I trip over it all the time.

[+stephena]

Here are some software suggestions as an example of what Stella could be changed to do:

 

* Not defaulting to enabling the mouse so trackpads don't screw with your game.

 

I plan to add an option that specifies to only use the mouse for 'analog-input' type controllers (like paddles, real mouse, etc). And it would be the default. In all honesty, I don't know who uses the mouse for joystick input anyway; I may even remove the option completely. I personally never use it, and at times it screws me up as well (and I wrote the thing).

 

* A wrapper mode for Stella that encapsulates a single game as an .EXE or .APK for Android.

 

This may not happen, as Stella is GPL2, and creating a package containing a ROM may cause issues with the copyright on the ROM and the emulator itself. This happened in the 1.2 release, where a ROM was included in the source code, and this forced the ROM to be under the GPL2 as well, which its author did not want. We had to pull the release because of this.

 

To me, this also seems outside the scope of Stella. You can easily get packages for Windows (and probably other OS'es) that basically decompress when double-clicked. There's no reason why such a package couldn't include both Stella and the ROM, and when decompressed, automatically launch the emulator and the ROM. But that's as close as the ROM can get to Stella; I can't integrate it into the source in any way. Aside from GPL issues, there are also general copyright issues to consider. Emulation development and distribution is generally allowed and legal; mixing copyrighted ROMs into it may not be legal, and it's not something I want to find out.

 

* Capture video to .AVI

 

This is on the TODO list for some time, and I would like to get to it eventually. Finding time to do it is another matter. If someone could research the possibilities that exist for GPL2-compatible code to do this, it would be greatly appreciated (and greatly increase the chances that it would be added to Stella).

[+stephena]

I think it would be too slow to actually play a game in an emulator FROM eprom. On real hw everything happens in realtime (i.e. bankswitching) and data-fetches etc.

So adressing the EPROM and reading back from it (into the emulator) must not cause ANY delay.

 

Yep, that's why I view it as outside Stella. You have to get the data (reliably and quickly) from the cart, and then pass it to Stella. The first part is someone elses job

[cak]

What would be great (though I think I read that it was already planned?) is the ability to record/playback game input "movies", similar to other emulators like FCEUX. Bizhawk already does this, but it's a multi-system emulator and has certain issues (for instance, does not emulate Pitfall II DPC), so having Stella do this would be beneficial to speedrunning and TAS-ing communities.

Edited August 9, 2013 by cak

[Thomas Jentzsch]

Why don't you use something like Bandicam?

[cak]

I use Hypercam for screen capture, but that's not what I'm talking about. I'm talking about recording keyboard/joystick button presses.

Edited August 9, 2013 by cak

[+stephena]

What would be great (though I think I read that it was already planned?) is the ability to record/playback game input "movies", similar to other emulators like FCEUX. Bizhawk already does this, but it's a multi-system emulator and has certain issues (for instance, does not emulate Pitfall II DPC), so having Stella do this would be beneficial to speedrunning and TAS-ing communities.

 

Yes, it's on the TODO list, and has been for some time. I actually played with this a little, and created an initial implementation. It's currently commented out in the code (so you can't test it), but it did work. There are several issues to solve, and a UI to create for it, etc. But the biggest problem, again, is finding time to work on it.

[Jan Hermanns]

VICE has a nice feature I would love to see in Stella.

 

There you can feed the debugger a label file, which is very convenient when debugging. Would be great if you could specify the label file as a command line parameter.

Edited August 10, 2013 by Jan Hermanns

[Thomas Jentzsch]

Stella already uses DASM's symbol file for debugging.

[Jan Hermanns]

Stella already uses DASM's symbol file for debugging.

 

Could you please elaborate on this?

How exactly do I get stella to show my labels?

[Thomas Jentzsch]

Tell DASM to create a symbol file. The name has to be identical to the binary created, except for the extension which has to be ".sym"

 

So if your file is test.bin use: -stest.sym

[Jan Hermanns]

Tell DASM to create a symbol file. The name has to be identical to the binary created, except for the extension which has to be ".sym"

 

So if your file is test.bin use: -stest.sym

 

Works like a charm :-)

 

Thank you so much!

[+SvOlli]

While we are on it: I'd like to have another debug color, to see where WSYNC is triggered, so I can see how much time is left on each line.

 

Either that you see a small dot there, or all colors go a bit darker from there.

[karokoenig]

Way off-topic probably, but... how do you guys play paddle games on Stella? Is there a way to wire original atari paddles to my laptop? Atari-USB adapter or something?

[yllawwally]

There is a bug, in version 3.7.2.0, where one of the memory labels is incorrect. I noticed in Tumulus. I have a constant called C_KERNAL_HEIGHT, it has a value of 182. Memory location B6 is misnamed as C_KERNAL_HEIGHT. It should be named E4_Health. In the symbol file it appears to be correct. I would upload the symbol file, but apparently I'm not permitted to upload this kind of file, file ext doesn't matter.

Edited August 13, 2013 by yllawwally

[+stephena]

There is a bug, in version 3.7.2.0, where one of the memory labels is incorrect. I noticed in Tumulus. I have a constant called C_KERNAL_HEIGHT, it has a value of 182. Memory location B6 is misnamed as C_KERNAL_HEIGHT. It should be named E4_Health. In the symbol file it appears to be correct. I would upload the symbol file, but apparently I'm not permitted to upload this kind of file, file ext doesn't matter.

 

Please include both the ROM, the source (if possible) and the symbol file in a ZIP file, and attach it here, or PM me directly. The ZIP format is allowed here as an attachment.

 

Also, try running the latest version of Stella (3.9) and see if the problem still exists.

[yllawwally]

It does exactly the same thing in version 3.9. If I change the C_KERNAL_HEIGHT to 181, memory location B5(181 decimal) will be misnamed instead. I'll PM the zip to you.

[+SpiceWare]

Way off-topic probably, but... how do you guys play paddle games on Stella? Is there a way to wire original atari paddles to my laptop? Atari-USB adapter or something?

 

http://home.comcast.net/~tjhafner/2600-daptor.htm