Stella 2.4.2 released

[+stephena]

When I run Stella by itself and select a game, my controller setup works great, but when I double click on a BIN file and play a game that way, Stella will let me use my controller's D-pad, but the fire button always reverts to the Space Bar. It will not let me use the button I selected on my controller.

 

It's not just this version, it's been that way for months or years. It may not seem that important, but when you work on a program using a batari Basic IDE and do a test run, it's irritating to have to keep using the keyboard. I hope you can fix this problem.

 

 

Thanks.

 

[i had this problem on a Windows XP computer and now a Windows Vista computer, so it can't be blamed on Vista.]

 

I've noticed this problem also. When I double-click a rom file I notice that, in the same folder as the rom, a new empty folder is created named "State" and a file named "Stella.ini" is also created in the rom folder.

OK, while this one isn't desirable either, it's sort of intentional. The Windows version of Stella uses 'relative' pathnames for its config files. For the state file directory, the default is '.\state'. So, if you launch a ROM through Windows explorer (ie, not within Stella), it will create a state file directory and config file in that same folder. I believe z26 will do something similar with its config file.

 

Basically, launching a ROM through Windows based on its file extension is not a use case I ever really thought about, so it's no surprise there may be bugs there; I've never really tested it. I always assumed one would use the commandline in Linux or Windows, or the built-in launcher. So I need to do more testing in this area.

 

Another issue which I plan to fix is the relative pathname problem. This issue doesn't occur in Linux or OSX since they use an absolute pathname by default for all config files ($HOME/.stella/XXX). I probably should add something like that to the Windows version as well. But in the meantime, if you go into the 'Config Files' UI and set the state directory to an absolute path (perhaps C:\stella\state), it will stop creating those state dirs everywhere. Unfortunately, it will still create stella.ini in many places until I address this issue.

[+stephena]

This one is intentional. The reasoning is, if you start a ROM from the commandline (or from another launcher), Stella should act as 'run-once' application. If, however, you start it up with its internal launcher, that's what you should go back to when you exit a game.

 

Perhaps there is an issue with these differing modes; I'll look into it and let you know.

Thanks. Until then, at least I know I can use button number one. It's not perfect, but it's better than using the Space Bar.

Wait a minute ... In answering Buzbards question it occurred to me what's going on. The remappings for your gamepad are stored in stella.ini. Now, stella.ini will be located in the same folder as the executable. So, when you launch Stella by double-clicking its icon (or from the Windows program menu), it will see the stella.ini file and everything works. However, if you launch Stella by double-clicking on a ROM, and that ROM isn't in the same folder as the executable, it won't see the stella.ini file with your remappings and will instead create a new one. That's why you lose the remappings; Stella is looking at a different ini file. The solution is to use an absolute pathname for the ini file (something like C:\users\application data\stella\stella.ini). I'll fix this for the next release.

[+Random Terrain]

The solution is to use an absolute pathname for the ini file (something like C:\users\application data\stella\stella.ini). I'll fix this for the next release.

Great news! Thanks.

[+stephena]

The solution is to use an absolute pathname for the ini file (something like C:\users\application data\stella\stella.ini). I'll fix this for the next release.

Great news! Thanks.

JUst an FYI that this issue is now fixed, and will be included in the next release of Stella. The new default folder for all Stella related items for the Win32 port is 'My Documents\Stella'. Note that the folder location will differ based on what version of Windows being used, but it will always be accessible from your Windows Explorer 'Documents' link. Also note that this fixes another long-standing bug wrt administrator access; you'll no longer need to be an administrator to save your settings (since they're no longer saved in the application folder).

[+Random Terrain]

The solution is to use an absolute pathname for the ini file (something like C:\users\application data\stella\stella.ini). I'll fix this for the next release.

Great news! Thanks.

JUst an FYI that this issue is now fixed, and will be included in the next release of Stella. The new default folder for all Stella related items for the Win32 port is 'My Documents\Stella'. Note that the folder location will differ based on what version of Windows being used, but it will always be accessible from your Windows Explorer 'Documents' link. Also note that this fixes another long-standing bug wrt administrator access; you'll no longer need to be an administrator to save your settings (since they're no longer saved in the application folder).

Cool! Thanks. I'll be waiting with a worm in my mouth, oops, I mean baited, no, bated breath.

[+Nathan Strum]

I've got a feature request... now that there's a USB Interface for the AtariVox, can support for that be added to Stella? (Where Stella sends the necessary serial commands out to the USB port to drive an attached AtariVox.)

 

A brief discussion about it is going on in Chris' blog, and Richard has offered to send you an interface to help with it.

[+stephena]

I've got a feature request... now that there's a USB Interface for the AtariVox, can support for that be added to Stella? (Where Stella sends the necessary serial commands out to the USB port to drive an attached AtariVox.)

 

A brief discussion about it is going on in Chris' blog, and Richard has offered to send you an interface to help with it.

There was an attempt to add software support for an 'emulated' AtariVox to Stella, but it didn't work out. But some of the framework that was added could be useful for this hardware. I'm going to send a message in the blog you mentioned and see exactly what would be required to add this to Stella.

[+batari]

I've got a feature request... now that there's a USB Interface for the AtariVox, can support for that be added to Stella? (Where Stella sends the necessary serial commands out to the USB port to drive an attached AtariVox.)

 

A brief discussion about it is going on in Chris' blog, and Richard has offered to send you an interface to help with it.

There was an attempt to add software support for an 'emulated' AtariVox to Stella, but it didn't work out. But some of the framework that was added could be useful for this hardware. I'm going to send a message in the blog you mentioned and see exactly what would be required to add this to Stella.

What framework was added?

[+stephena]

I've got a feature request... now that there's a USB Interface for the AtariVox, can support for that be added to Stella? (Where Stella sends the necessary serial commands out to the USB port to drive an attached AtariVox.)

 

A brief discussion about it is going on in Chris' blog, and Richard has offered to send you an interface to help with it.

There was an attempt to add software support for an 'emulated' AtariVox to Stella, but it didn't work out. But some of the framework that was added could be useful for this hardware. I'm going to send a message in the blog you mentioned and see exactly what would be required to add this to Stella.

What framework was added?

Basically, two classes were added. One was named AtariVox, and was a 'controller' in Stella (in a similar fashion as a joystick, paddles, etc). So it interfaced with the emulation side, performing simulated reads and writes on the controller port pins. This code is fine, and can be reused.

 

The second class was named SpeakJet, and tried to emulate the actual SpeakJet chip in software (using the rsynth library). Initial results were somewhat encouraging, but support was abandoned due to lack of time and the fact that adding this lib to Stella would triple the executable size.

 

Anyway, the AtariVox class 'wrote' its data to controller pins. For the pins that send SpeakJet data, it just sent it to the SpeakJet class directly. The EEPROM stuff wasn't yet emulated, so nothing was done in that case. So, conceptually, things can still work the same way, except the SpeakJet class won't be doing emulation, but will send the necessary USB commands to drive the external AtariVox.

[Urchlay]

The second class was named SpeakJet, and tried to emulate the actual SpeakJet chip in software (using the rsynth library). Initial results were somewhat encouraging, but support was abandoned due to lack of time and the fact that adding this lib to Stella would triple the executable size.

 

That, and I couldn't get rsynth to sound even remotely like the Speakjet... I tried again with a different speech library (flite, "Festival Lite"), but it bloated the executable even more, and still sounded nothing like the Speakjet.

 

My third attempt was to take samples from an actual Speakjet chip. Unfortunately that didn't work out, because the Speakjet has a wide range of settable parameters (pitch, speed, etc). To emulate it properly, I'd have to either take a sample of each phoneme at each possible setting (*lots* of samples), or else figure out exactly how the settings affect the sounds, and do real-time digital signal processing in Stella to do the same effects (I don't know enough about DSP programming, I was in the middle of researching it when real-life stuff intruded on my world in a major way...)

 

Anyway, the AtariVox class 'wrote' its data to controller pins. For the pins that send SpeakJet data, it just sent it to the SpeakJet class directly. The EEPROM stuff wasn't yet emulated, so nothing was done in that case. So, conceptually, things can still work the same way, except the SpeakJet class won't be doing emulation, but will send the necessary USB commands to drive the external AtariVox.

 

I've still got my Atarivox + its USB adaptor. I might take a crack at coding this... been thinking about Stella lately, maybe it's time to get back to working on it.

[+stephena]

Anyway, the AtariVox class 'wrote' its data to controller pins. For the pins that send SpeakJet data, it just sent it to the SpeakJet class directly. The EEPROM stuff wasn't yet emulated, so nothing was done in that case. So, conceptually, things can still work the same way, except the SpeakJet class won't be doing emulation, but will send the necessary USB commands to drive the external AtariVox.

 

I've still got my Atarivox + its USB adaptor. I might take a crack at coding this... been thinking about Stella lately, maybe it's time to get back to working on it.

By all means, if you now have some free time, I can use any help you can provide. Richard and Al were gracious enough to provide me with sample hardware to get this done, but more help is always appreciated (and perhaps even required when I really get into it).

 

Also, there are still a number of debugger items we need to discuss, if you have the time.

[+stephena]

I've got a feature request... now that there's a USB Interface for the AtariVox, can support for that be added to Stella? (Where Stella sends the necessary serial commands out to the USB port to drive an attached AtariVox.)

 

A brief discussion about it is going on in Chris' blog, and Richard has offered to send you an interface to help with it.

There was an attempt to add software support for an 'emulated' AtariVox to Stella, but it didn't work out. But some of the framework that was added could be useful for this hardware. I'm going to send a message in the blog you mentioned and see exactly what would be required to add this to Stella.

What framework was added?

Basically, two classes were added. One was named AtariVox, and was a 'controller' in Stella (in a similar fashion as a joystick, paddles, etc). So it interfaced with the emulation side, performing simulated reads and writes on the controller port pins. This code is fine, and can be reused.

 

The second class was named SpeakJet, and tried to emulate the actual SpeakJet chip in software (using the rsynth library). Initial results were somewhat encouraging, but support was abandoned due to lack of time and the fact that adding this lib to Stella would triple the executable size.

 

Anyway, the AtariVox class 'wrote' its data to controller pins. For the pins that send SpeakJet data, it just sent it to the SpeakJet class directly. The EEPROM stuff wasn't yet emulated, so nothing was done in that case. So, conceptually, things can still work the same way, except the SpeakJet class won't be doing emulation, but will send the necessary USB commands to drive the external AtariVox.

Now that I've read up a little more on the AVox, SpeakJet and FT232R UART, I can explain this in better terms. The framework currently in place takes care of the bit-banging part on the emulation side. Bytes are being generated correctly, as I've visually inspected them, looked them up in the SpeakJet manual, and 'see' that they would make the sounds I hear (from the emulated SpeakJet). And in Linux, Stella can already 'see' the AVox adaptor, so it should just be a matter of sending those bytes to the adaptor, which sends them to the actual AVox.

 

Ironically, Win32 and OSX support may prove more troublesome, since the required libs are closed source and can't be linked directly to Stella (due to the GPL under which Stella is released). I foresee possibly creating a 'stella-atarivox' application that communicates with Stella, but isn't linked to it. Incidentally, this is why I hate closed-source stuff; it just needlessly complicates things. Rant mode off

[Eckhard Stolberg]

Now that I've read up a little more on the AVox, SpeakJet and FT232R UART, I can explain this in better terms. The framework currently in place takes care of the bit-banging part on the emulation side. Bytes are being generated correctly, as I've visually inspected them, looked them up in the SpeakJet manual, and 'see' that they would make the sounds I hear (from the emulated SpeakJet). And in Linux, Stella can already 'see' the AVox adaptor, so it should just be a matter of sending those bytes to the adaptor, which sends them to the actual AVox.

 

Ironically, Win32 and OSX support may prove more troublesome, since the required libs are closed source and can't be linked directly to Stella (due to the GPL under which Stella is released). I foresee possibly creating a 'stella-atarivox' application that communicates with Stella, but isn't linked to it. Incidentally, this is why I hate closed-source stuff; it just needlessly complicates things. Rant mode off

Isn't the AtariVox USB adaptor basically just a simulated serial port? If so, you could comunicate with the AtariVox through the normal serial functions of the OS without the need for any closed source libraries. That way Stella would also be able to access the AtariVox through the old serial port adaptor. You might not be able to access the SaveKey part of the AtariVox that way, but maybe that should better be simulated by a 32K file anyway, so that it would work for people who don't own an AtariVox too.

 

 

Ciao, Eckhard Stolberg

[+stephena]

Now that I've read up a little more on the AVox, SpeakJet and FT232R UART, I can explain this in better terms. The framework currently in place takes care of the bit-banging part on the emulation side. Bytes are being generated correctly, as I've visually inspected them, looked them up in the SpeakJet manual, and 'see' that they would make the sounds I hear (from the emulated SpeakJet). And in Linux, Stella can already 'see' the AVox adaptor, so it should just be a matter of sending those bytes to the adaptor, which sends them to the actual AVox.

 

Ironically, Win32 and OSX support may prove more troublesome, since the required libs are closed source and can't be linked directly to Stella (due to the GPL under which Stella is released). I foresee possibly creating a 'stella-atarivox' application that communicates with Stella, but isn't linked to it. Incidentally, this is why I hate closed-source stuff; it just needlessly complicates things. Rant mode off

Isn't the AtariVox USB adaptor basically just a simulated serial port? If so, you could comunicate with the AtariVox through the normal serial functions of the OS without the need for any closed source libraries. That way Stella would also be able to access the AtariVox through the old serial port adaptor. You might not be able to access the SaveKey part of the AtariVox that way, but maybe that should better be simulated by a 32K file anyway, so that it would work for people who don't own an AtariVox too.

 

 

Ciao, Eckhard Stolberg

Yes, it all comes down to that last part (the EEPROM); that can't be accessed through the serial port at all. If we get rid of that requirement, then you're absolutely right about it just being a serial port issue. I never thought about the people who have the old serial port adaptor, but you're correct that doing it the serlal way would work for them too.

 

I'm going to move this into the original thread, and ask what people think. It would really make things easier if we could not worry about the actual EEPROM.

[+SpiceWare]

That's all it is, just a com port. I have the older AtariVox serial interface and use it with a Keyspan USB to Serial adapter plus a wall-wart to provide power.

 

Here's the source for SAVI (SpiceWare AtariVox Interface) if it'll help. It's not very fancy and only say's one thing so far, but it does talk to it from the Mac via serial routines. Nathan's tried SAVI using the newer USB interface. He had to install a driver, but I had to do the same for my Keyspan adapter.

 

Double click savi in the archive. It'll open a terminal session. Use the "o" command to open the serial port, then the "t" command to test the AtariVox.

savi.zip

Edited March 30, 2008 by SpiceWare

[supercat]

I'm going to move this into the original thread, and ask what people think. It would really make things easier if we could not worry about the actual EEPROM.

 

Emulation will be more accurate if it emulates writes to a simulated EEPROM than if it tries to write to an actual EPROM plugged into the controller port. If people want to store their wondrous achievements on a real EEPROM, it would be easiest to copy the simulated EPROM image to the real EPROM after the game, than to try to emulate it 'live'.

[+stephena]

That's all it is, just a com port. I have the older AtariVox serial interface and use it with a Keyspan USB to Serial adapter plus a wall-wart to provide power.

 

Here's the source for SAVI (SpiceWare AtariVox Interface) if it'll help. It's not very fancy and only say's one thing so far, but it does talk to it from the Mac via serial routines. Nathan's tried SAVI using the newer USB interface. He had to install a driver, but I had to do the same for my Keyspan adapter.

 

Double click savi in the archive. It'll open a terminal session. Use the "o" command to open the serial port, then the "t" command to test the AtariVox.

There more I think about it, the more I realize that coding to the AVox USB adaptor directly isn't the correct approach. Because as you say, it should work with any USB<->Serial converter you have.

[+stephena]

I'm going to move this into the original thread, and ask what people think. It would really make things easier if we could not worry about the actual EEPROM.

 

Emulation will be more accurate if it emulates writes to a simulated EEPROM than if it tries to write to an actual EPROM plugged into the controller port. If people want to store their wondrous achievements on a real EEPROM, it would be easiest to copy the simulated EPROM image to the real EPROM after the game, than to try to emulate it 'live'.

I agree, but how do we access the EEPROM to copy that image afterwords? Or are you saying not to worry about that in Stella at all, and let some 3rd-party application do it? Because that would make things easier on me as well.