zagon

I'm sorry to revive this thread now that Stella 3.5 has been released but as I am one of the users that are affected by the ATI/opengl/no sound bug I would like to report on my findings: First, can confirm that the bug is fixed in version 3.5 of stella. However, I expected to be able to repeat the bug in version 3.4.1 but I was unable to do so. I had to go all the way back to version 3.0 before I could repeat it. As it happens, Stella version 3.0 is the last version of Stella to use SDL.dll v1.2.13. Stella version 3.1 and later all use SDL.dll v1.2.14. As an experiment, I replaced the bundled v1.2.14 SDL.dll with the older v1.2.13 in the newer Stella releases. This made the bug reappear in all Stella versions up to and including version 3.4.1. It really looks like the cause of the whole problem was a bug in SDL that got fixed in v1.2.14.

I'll order a PAL mod as soon as they are available! From my point of view there's only downsides to RF-connctions: 1) The video quality is worse than composite-video or s-video. 2) The TV needs to be tuned the correct channel. 3) A TV only has one RF-input. If you have several RF-devices you have to swap the RF-cables. (You could use one or more RF-switchboxes but that reduces the video quality even further) 4) A RF-connection is more sensitive to interference

I see the same interference as you. I've checked your videos. Moving the RF-cable does not generate new interference, It changes the intensity of it. The interference dots goes from very noticeable to acceptable depending on how I close to the cart I arrange the RF-cable. I think that all carts radiate RF-interference to some level. Simple carts very little, the Harmony cart seems to radiate some more. For this radiation to be visible on screen then one or more links in the signal chain must be picking it up. In my setup the RF-cable itself seems to be link that is most sensitive to RF-radiation by far.

I have now tried a ferrite bead on the RF-cable too. It made no visible difference to me. However, I have succeded in reducing the interference to a completely acceptable level. The one thing that influences the level of interference I see the most is simply the arrangement of the RF-cable. I have mentioned this before in this thread but I think its worth repeating since it's such a simple thing to test. The more length of RF-cable I locate closer to the atari and cart, the more interference I see. If I arrange the cable so it just runs straight away from the atari I see almost no interference. On the other hand, if I coil it up around the cart I see *lots* of interference (obviously not a good idea). I don't think that my RF-cable is broken, I have tested with two. Monk, Philsan: Do your interference vary at all with the arrangement of your RF-cables?

In my interference-testing I have stumbled upon another issue: The Harmony cart menu screen jumps every two seconds or so and randomly hangs while navigating the file list on the SD-card. This occurs *ONLY* if the TV-switch is set to color and the Harmony cart is flashed with the PAL50 version of the menu. All other menu variants PAL60 and NTSC, color cycling or not, work as expected with the same SD-card. Also the PAL50 menu works if TV-switch is set to bw. This occurs with the 103c version of the BIOS on both of my Harmony carts. Have anyone else seen this?

After some more investigation I have detected that the arrangement of the RF-cable is important. If I straighten the RF-cable so that it doesn't have any loops I get the same interference reduction that I got from wrapping the cart in foil and grounding it. If I coil up the RF-cable the interference increase. I will Investigate some more, I have read several suggestions in this thread I haven't tried yet. Like putting an iron-bead on the RF-cable and checking the shielding of the RF-unit in the Atari. Perhaps it is just a matter of sorting out my RF-sensitive setup.

First I must say that the Harmony carts work great and I'm a happy owner. However, I see the same kind of non-random, game-specific, interference on both of my Harmony carts too. This is on a 2600jr PAL, no video-mod, connected to the TV by RF-cable. It doesn't matter if I run the NTSC, PAL or PAL60 menu versions. If I wrap the cart with foil and ground the foil to the RF-shield the interference is reduced to a great extent but still noticeable.

Would it be possible to allow aspect ratios > 100%? I have calculated the aspect ratio for PAL and it corresponds to 104% but I can't use it. For NTSC the calculated aspect ratio corresponds to 86% so it works ok. Also, would it be possible to have two different aspect ratio settings that would be used (in gl-mode) depending on the PAL/NTSC autodetection of the ROM image? Thanks for a great emulator!

Yes, its a bit strange Perhaps its triggering some kind of driver bug. However, I am using the latest available graphics driver, from may 2005, and have not noticed any other problems with it.

I'm an otherwise happy Stella user but I'd like to report a problem I'm having (and a workaround) Problem: If Stella is started with the opengl renderer then there is no sound at all. However, if Stella is started with the software renderer the sound works the way it is supposed to. Further, the sound also works with the opengl renderer if I start with the software rendener and then change to opengl renderer without restarting. Workaround: swap lines 437 and 438 in the OSystem.cxx file so that the audio is initialized before the video. The version of Stella I'm using is 2.6.1 and I'm running it on an old laptop with ATI mobility radeon 9200, Windows XP Pro.

Yes, using a version control tool really simplifies development. I use mercurial for my projects. Its powerful, lightweight and easy to set up if you use the binary packages. (available here)

Hm, it seems I have to do my homework better That's impressive, I probably can't

Those sectors, are they always read in some kind of order? If so, you could store the byte ranges in the chunks in the order they are read so that multiple sector reads could be served by just one decrunch. In other words: Is there a file-layer abstraction hiding behind those sector reads? If so, it could would be possible to take advantage of that to further improve compression result and performance. By the way, In Exomizer I now use address $2c00 for loading the sfx crunched file. Is this address safe for all kinds of dos versions? Is there some other address that is generally agreed to be safe that would be better to use?

It should be doable, but it will be a bit tricky. However, I would suggest crunching bigger chunks of data than 128 or 256 bytes in order to improve crunch result. I would also suggest using the streaming decruncher, the one with the cyclic buffer, to decrunch the chunk just far enough untill the wanted byte range is reached. However, the cyclic buffer uses some memory and the chunk size will be a tradeoff between crunch result and the time it will take to access a single byte range. It also means that there has to be a two level index structure, one to tell in which cruched chunk the wanted byte range is in, and another to tell the offset of the byte range in the decrunched chunk data.

Both are right, the original xex-file is probably 33050 and the total length of data when all xex-segments are loaded into memory from the lowest to the highest used address is 45533 bytes. yes. Another difference from zlib is how the offsets work. The offsets of Exomizer points to the 'wrong' end of the sequences, the end furthest away. But this has the advantage of supporting sequences that can encode repeating patterns of one or more bytes like this: (offset 1, length 2345) == rle sequence. (offset 4, length 16) == four byte pattern repeated 4 times. Your zlib decompress routine sounds interesting, I'll have to take a look at it.