Stella 4.6.5 released

[Keatah]

Info for a journal on emulators. Some emus have a heritage going back 20, 25 years already.

[+stephena]

Well, Stella was started in 1996, so it's coming up on 20 years next year.

[Thomas Jentzsch]

I wonder if the first released version can be found somewhere.

[+stephena]

That's a good question. Every release from 1.1 onwards is on Sourceforge and in the CVS/SVN repo. I wasn't involved with the project before that, and those releases were non-GPL. I think I have at least of a few of them kicking around somewhere. It might be nice to have them all available for a 20th anniversary thing ...

 

For those looking, there were releases 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 1.0b1, and 1.0.

 

EDIT: I have the source versions of all the releases mentioned above, as well as a Mac SIT archive (which I can't open). I don't have any of the binary releases, though.

[Trebor]

That's a good question. Every release from 1.1 onwards is on Sourceforge and in the CVS/SVN repo. I wasn't involved with the project before that, and those releases were non-GPL. I think I have at least of a few of them kicking around somewhere. It might be nice to have them all available for a 20th anniversary thing ...

 

For those looking, there were releases 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 1.0b1, and 1.0.

 

EDIT: I have the source versions of all the releases mentioned above, as well as a Mac SIT archive (which I can't open). I don't have any of the binary releases, though.

 

Stephen,

 

Here are the 0.7 binaries:

 

DOS: stella07.zip

Windows: stelw07a.zip

OS/2: stella-0_7-os2.zip

Mac: stella-0_7-mac.hqx

Linux: stella-0.7-linux.tar.gz

[Thomas Jentzsch]

Here is the first post from Brad regarding Stella 96.

[alex_79]

I keep a devOS modded 7800 near my PC, connected to a small 5" b/w CRT TV so that I can quickly test my programs on real hardware. The interesting thing is that when developing 2600 software using one of the ramcarts designed for 7800 you can have more than the standard 4kb addressed by the cpu and without bankswitch, because such ramcarts use the full 7800 cartridge port, therefore having access to A13,A14 and A15 in addition to R/W signals.
With the original devOS bios you can have max 24Kb in 2600 mode (using the 48K linear ramcart), but the max amount of addressable ram/rom for the 7800 in 2600 mode is 32K if the cart uses a 7800 board.
This is especially useful while developing a 4k game as you can exceed the 4k boundary before optimizing the code without bankswitch issues, as all the address space is accessible at the same time (so you can, for example, reference data tables outside the usual 4kb space). Another advantage is that the entire address space can be RAM and without the limitation of having separate write and read addresses, which again could be useful for testing purposes.
The great drawback in this configuration is that I can't use the stella debugger!

I know I'm probably the only one using this setup, but I'll ask anyway...
Could support be added in stella? Even without the hardware, the ability to run test code which uses more ROM and RAM than usually available on the VCS and without the issues of bankswitching and different write/read addresses might be interesting to other developers in testing ideas.

It would be a scheme only used for development, so no autodetection code is needed.
The memory map is very simple: 32kb of ram in 8 4kb chunks:

$1000-$1FFF
$3000-$3FFF
$5000-$5FFF
$7000-$7FFF
$9000-$9FFF
$B000-$BFFF
$D000-$DFFF
$F000-$FFFF

The ram should be randomized, then the binary image loaded at the top of the address space.
(so a 4k rom is loaded at $F000-$FFFF, a 8k one into two chunks at $D000-$DFFF and $F000-$FFFF, and so on up to 8 chunks for a 32K rom)

Probably it's easier to add support for this if the 4k chunks are considered as different banks and the 3 most significant bits of the emulated 6502/7 address bus are used to select the current one.

[+stephena]

OK, I just did a small 4.6.6 release, which addresses the 'jitter' issues mentioned above, and also fixes a bankswitching bug in the 'MDM' scheme. Now I will continue with the larger changes for 4.7

[ClassicGMR]

Hi. I just installed 4.6.6 on my Windows 10 machine. I had 3.(high number)? installed previously but figured time to update. I did and "overwrite" install then when that didn't work I did a complete uninstall/reinstall including deleting the "%appdata%\stella" information. I had no issues before updating.


The issue now is I can't configure the 2600-daptor. My 2600-daptor is listed as J5 under the Joystick Database but Stella won't let me configure using it. It "sees" it is J5 but when I try to assign the joystick it won't do it. My NES controller is listed as J0 through my SNES adapter at J4 and I can configure them fine. It also doesn't let me remove any of the joysticks in the database. "Remove" is greyed out. Not sure if this is unimplemented as yet or another symptom of the issue I have.

 

 

Is there a limitation I hit with J5 being the adapter's assignment possibly?

Edited October 13, 2015 by ClassicGMR

[+stephena]

I haven't actually tried any controllers yet under Windows 10, so there may be issues there. For now, I suggest unplugging everything else, then plug in the 2600-daptor only. Then delete "%appdata%\stella" and try again. This will at least tell if the 2600-daptor is working at all with Stella, or if it's a 'too high number' issue. There shouldn't be any limitation on the actual numbers, but then again, I've only tested with two things plugged in at the same time, so I can't really say for sure.

[ClassicGMR]

I'll give that a whirl tomorrow morning and see what I get. 2nd double shift today.

[ClassicGMR]

So I tested this today. I disconnected all of the controllers except for the 2600-daptor and booted the cabinet. I then deleted the appdata and started Stella. Still wouldn't let me configure. At that point I deleted and uninstalled everything Stella related. Downloaded a new copy of Stella-4.6.6-x64.exe and reinstalled. Same issue.

 

I found a copy of the 4.0 install program on one of my backup drives. Figured I'd give that a whirl. So I once again deleted/uninstalled everything and shut down. I reconnected all my controllers and rebooted. Installed 4.0 and it let me configure. As I configured I noticed it read "J5 X-Axis +" or similar (not in front of me atm) when I mapped it so the earlier version maps fine. It does not have the option for a Joystick database though. I assume you added that feature later.

 

All in all I have an older version working perfectly but if you want me to try something I am open to helping you test. Just let me know.

 

Windows 10 64-bit

AMD Quad Core A10-6800K at 4.1GHz

USB - original 2600-daptor (not II)

Edited October 15, 2015 by ClassicGMR

[+stephena]

To be absolutely clear, when you say you "can't configure it", do you mean you can't map any buttons to it, or it doesn't work at all? Because Stelladaptor and 2600-daptor devices are 'special', in that Stella automatically recognizes them and auto-assigns the actions. As such, you can't remap buttons/axes on these sticks. They should simply be plug-and-play, not requiring any 'configuration' at all.

 

Next thing to do (in addition to what I mentioned in the previous message) is to go to Options -> System Logs and tell me what it says for the joysticks. For me in Stella 4.6.6 and Windows 10, it says the following:

Stella 4.6.6

Features: Sound Joystick Debugger Cheats
Build 3226, using SDL 2.0.3 [x86_64]

Base directory: '~\AppData\Roaming\Stella\'
Configuration file: '~\AppData\Roaming\Stella\stella.ini'
User game properties: '~\AppData\Roaming\Stella\stella.pro'

Video system: windows
Renderer: direct3d
Max texture: 8192x8192
Flags: +vsync, +accel

Added joystick 2:
XInput Controller with: 6 axes, 15 buttons, 0 hats

Added joystick 1:
2600-daptor (emulates left joystick port)

Added joystick 0:
2600-daptor II (emulates left joystick port)

Sound enabled:
Volume: 25
Frag size: 1024
Frequency: 31400
Channels: 2 (Hardware2Mono)


Game console created:
ROM file: ~\Desktop\Good2600\River Raid (1982) (Activision) [!].zip/River Raid (1982) (Activision) [!].a26

Cart Name: River Raid (1982) (Activision) (16K)
Cart MD5: 291cc37604bc899e8e065c30153fc4b9
Controller 0: Joystick in left port
Controller 1: Joystick in right port
Display Format: NTSC*
Bankswitch Type: F6* (16K)

 

The important part here is the 2600-daptor devices (I have both versions) are detected and automatically set up. Now, I just noticed there is an error in the output message (both are listed as the left controller), but this is in the message only. When playing a game 2600-daptor II acts as left stick, and 2600-daptor I acts as right stick. I will get this error fixed for the next release.

 

Let me know what your System Log says.

[ClassicGMR]

OK now I feel really confused. I just did everything again - uninstalled every bit of Stella, disconnected all but the 2600 'daptor and rebooted. Installed 4.6.6 and it worked exactly as it should. I didn't have to configure anything. It put the 'daptor at J0.

 

I shut down and reconnected everything. Rebooted. Ran Stella and it still works fine. The system moved it to J1 but nothing wrong. I can still post my logs if you like but everything is doing what you said it should... weird.

[+stephena]

Well, that's Windows for you Seriously, though, I've seen weird issues with joysticks in Windows in other emulators and even some AAA games too.

 

Also, about the uninstall/re-install cycle, it really doesn't accomplish anything with Stella. Simply deleting the %APPDATA% stuff is the same as a new install; re-installing really doesn't do a thing.

[ClassicGMR]

Also, about the uninstall/re-install cycle, it really doesn't accomplish anything with Stella. Simply deleting the %APPDATA% stuff is the same as a new install; re-installing really doesn't do a thing.

 

I'll remember that but the tech support in me always wants to uninstall and reinstall!

[Keatah]

Regarding the standard diagnostic cartridge, why doesn't the fire button show any change in the bars?

 

 

 

[alex_79]

It's not supposed to. The bars does not indicate if the fire buttons are pressed, but rather the results of a series of tests made to verify functionaluty of the TIA input lines.

The diagram you posted refers to the test with the shorting plugs inserted in the controller ports. (the top middle area should be in green and as large as the areas below it).

The screenshot shows the correct results for the test without the shorting plugs (page 3-11 of the service manual) with the narrower top middle bar in different color (the manual says pink, but it looks more orange to me). Stella doesn't emulate the plugs, so that's the only one that it will show.

If the pattern with and/or without the shorting plugs differs from what shown in the service manual, then there's some problem with the lines.

[dualcam]

Stelladaptor & 2600-daptor paddles not working - just jumps across screen. OK in 4.6.1, so something in this release.

 

Tom

http://2600-daptor.com/

[+stephena]

OK, I'll look into it right away.

[Keatah]

Some questions about Video Pinball and Cosmic Ark. They may or may not be Stella issues at all, but rather idiosyncrasies of the Game Programs themselves.

 

On Cosmic Ark, there appears to be a slight extra 5-10ms delay when firing the left laser as opposed to the top/bottom/right ones. It's more noticeable if you set the framerate to 10FPS. Also, the right laser seems to fire 1 scanline too high sometimes. The left laser always emits from the black centerline 100% of the time as expected.

 

On Video Pinball, the collision detection doesn't seem to work correctly on the top 3 gold rollover targets. If the ball hits one of them, it always registers. Ok. Good. But if you're lucky and the trajectory of the ball crosses two or even all three of them. Only the initial one registers. It seems as if some time has to elapse first, or the ball has to hit something else first before the remaining target(s) register a rollover..

 

Hope that all made sense.

 

Here are screenshots for Cosmic Ark, firing the right laser.

 

Here are the screenshots for Video Pinball.

 

In the last shot the ball clearly passes through the bottom end of the center target and no detection is made. It proceeds to bounce off the corner of the number one "roll through thing" and takes out the leftmost target after the bounce.

 

Ahh-hah! In this second round of screenshots I caught Mr. CollisionDetection sleeping on the job!

 

Shots 4 & 5 of this second batch clearly indicate no detection. In fact you can see the ball practically square-on.

 

And this was the trajectory.

 

I know early on either Stella or Z26 or PCAE had issues with the flippers not hitting the ball and all that. Is this related in some way?

Edited October 22, 2015 by Keatah

[Thomas Jentzsch]

The right laser is displayed one row too high because of tearing. This is not an emulator problem.

[Thomas Jentzsch]

The collision problem you describe is also no emulator problem. The game uses hardware collisions. This means, only if pixels of two objects overlap during display, a collision is detected. If one object moves very fast, it can pass a small object (or parts of a larger one) between two frames. Then no collision can be detected.

 

Edit: There also seems to be another programming error. Stay tuned...

Edited October 22, 2015 by Thomas Jentzsch

[Keatah]

I vaguely thought it might be something like that. I would guess it's a similar reason for the left laser's slight delay? Perhaps because of how the beam scans left to right?

 

I have a small rig where when I press the fire button it starts a timer with a 1/1000th second resolution and lights a small LED. There is 0ms delay in the LED light because it is a direct connect to the power source and fire button. As the fire button closes contact, the LED lights. I can place the LED next to something on screen. And you can see the timer counting, the LED lighting up, thus providing reference for any delay in the system between the button and on-screen action.

 

The key part is having a camera that can do a bare minimum of 60fps or faster. You can then go frame by frame. Add up the frames, with each frame being 16.67ms. Or just look at the counter till on-screen action happens. Faster the camera, the better and easier it is to study the frames and get a more precise measurement.

 

Recently I added in a directional phototransistor with adjustable sensitivity that will stop the timer and light another LED whenever a significant change in lighting or color happens. Like when an object passes immediately under it such as a laser blast or a ship.

 

ADDED: You have to film the whole thing and then review it after. Frame by frame. But with the counter going and LED lighting up any lag is put into the spotlight. No escape!

Edited October 22, 2015 by Keatah

[Thomas Jentzsch]

The Video Pinball collision problem results from a double hit in too short time. The code skips the check for the next hit for up to 16 frames.

 

Not sure why this was implemented, maybe to debounce some other hits. But it is no emulator problem too.