Jump to content
Sign in to follow this  
DanBoris

VSS Update

Recommended Posts

I am currently working on the next release of VSS and since a number of people here use it for development I was wondering if there are any features that people would be interested in seeing.

 

Dan

Share this post


Link to post
Share on other sites

Hi, Dan.

 

Okay, as a 5200 developer, here are some thoughts from me, things I've noticed over the past half year or so.

 

1. The biggest thing is that the 3-color / 2 player overlay doesn't seem to work. I can't tell you how many nights I tried to get it to work when it was working all along! This would be a good upgrade.

 

2. Colors. I know, I have mentioned this before. The colors are not the same as the 5200's true colors are. In fact, I have noticed that VSS colors seem much, much brighter and more vibrant than the actual machine's colors. For example, Koffi's pictures are all from VSS on the dev site; however, the game doesn't look as good on the 5200. Koffi's yellow is actually too dull $18 -- but $1d or $1e is much better on the 5200. I think Atari800Win's colors seem more accurate. So, although VSS makes the games look better, it actually makes it harder for a developer since I had to change many of the colors to make the game look good on the machine itself.

 

That's all the constructive criticisms I can think off. Sound support seems good to me (I don't think Berzerk talks though). I love the 5200D.exe debug version and I use it quite a bit.

 

It would be nice if the debug version could be programmed to stop the run and enter debug whenever a certain memory address changed. Maybe its in there already, but -- in the current debug VSS, can you enter a 'break' stmt in code and have it break into debug mode when it hits it?

Share this post


Link to post
Share on other sites

I would like to see a step option in the debugger.

 

Say you are at location $4006 and there is a loop (I'm using your 52hello.s as an example). I would like to tell the debugger to execute the loop but stop at location $4014. That way I don't have to keep pressing the step key until the loop is over. Using this example you're looking at 255 key presses. It really gets ugly when you clear 3 pages of RAM

 

Also support for 8K and 16K ROMS would be a nice to have.

Share this post


Link to post
Share on other sites

For Cafeman:

 

1. Multi-color Overlapping players. This was my first priority in the new version and I already have it working great. Does anyone know how this effects missiles?

 

2. Colors. The color palette is a major problem. I setup an 800XL next to my PC and compared the colors are you are right they don't match. The real colors seems to get brighter faster then the emu, and the at luminance 15 they are almost all white on the real hardware. My problem is tweaking them manually would be a nightmare so I need to find a formula to calculate the whole palette.

 

Debugger: I look into adding a break when a certain address is changed.

 

For Debro:

The debugger can already do what you ask. Just type R 4014 and it will start executing until it gets to address $4014. VSS .80 already support 8K and 16K ROMS.

 

Dan

Share this post


Link to post
Share on other sites

Concerning missiles and the overlap colors -- I can't say much, but in the latest version of koffi, the raindrop missiles (1 and 3) do have a certain transparency when they fall overtop the player2 lightning bolt, for what that's worth.

 

Play koffi thru atari800win and you'll see it -- does that give you any info?

 

Concerning colors -- the biggest thing you need to do is not so much the luminence but the incorrect hues -- make it so that blues don't appear purple, etc. I have *no* idea how you would do that.

Share this post


Link to post
Share on other sites

Hi

 

Just a few minor things I've noticed..

 

The emulators seem to handle held keystrokes incorrectly. The problem is that contrary to documentation, SKSTAT doesn't work as expected. If you want to check it out, use my 5200 DEBUG52 program (burn & run on the real thing).

 

Something is weird with the music. Jum's emu music is similar.. so maybe its the music library being used, I dunno. Atari800 seems to play most everything correctly tho.

 

calamari

 

[ 04-02-2002: Message edited by: calamari ]

Share this post


Link to post
Share on other sites

You mean to tell me I had been stepping through loops for no reason , talk about a waste of time.

 

As for supporting 16K images, I compiled an image that was 16K and VSS doesn't run it. If I do a 32K image then VSS runs it fine. I did this for VSS .80 am I missing something? This of course is not that big of a deal since I could compile a 32K image with no trouble. The bigger of my wants already is present (the r option in the debugger )

Share this post


Link to post
Share on other sites

quote
I am currently working on the next release of VSS

 

YES!!!!

 

quote
 Play koffi thru atari800win and you'll see it -- does that give you any info?

 

&

 

quote
 Atari800 seems to play most everything correctly tho.

 

 

I am hoping(wishing) for two things...

 

1. Mr. Do's Castle running correctly. I believe I mentioned this to you before, Dan; when you were inquiring about the Mr. Do's Castle ROM dump (Whether it's good or not). The 'good' rom dump (Cowering's Tools) runs without a hitch on Atari 800 Win Plus 2.7 (or/and), 3.0. The source is also available for download/reference.

 

2. Win32 native support with full screen hardware stretch (ala MAME/MESS).

 

-Trebor

Share this post


Link to post
Share on other sites

Well now, Calamari jogged my memory -- on both Atari800win and VSS, if you hold a keypad button, it only registers one touch. On the actual machine, it registers one touch per frame -- auto-fire !

 

Is this an SKSTAT issue? I'm not sure myself, but I'll need to put in some code to handle it because changing options and other things via keypad happens far to quickly to control, and as mentioned the emu's don't act in the same manner as the real 5200.

Share this post


Link to post
Share on other sites

Cafeman,

 

I've developed a 5200 keypad debounce routine. Check the archives in this programming section. No need to reinvent the wheel.. errr keypad

 

calamari

Share this post


Link to post
Share on other sites

Here is a quote from my "Atari 5200 keypad repeat fix... SUCCESS !!!" thread in this forum, when the whole situation was fresh in my mind:

 

"On the real 5200, SKSTAT doesn't act like it does on the emulator (take a look at DEBUG52, and view address $E80F.. see how it is $FF then stays $FB while a key is pressed? Not so on the 5200, it is mostly $FF with an occasional $FB). So, we can't use SKSTAT to tell us when the key is no longer held."

 

calamari

 

[ 04-02-2002: Message edited by: calamari ]

Share this post


Link to post
Share on other sites

Yes, I thought you had posted something and I intend to look at all the recent programming forum threads soon ... I haven't been online much or had time to work out everything I had wanted to. Thanks, I'll use the info there soon.

Share this post


Link to post
Share on other sites

This actually makes sense. The POKEY chip was designed for scanning a full size keyboard (64 keys). Since the 5200 only has 16 keys on the keypad, only 4 of the 6 outputs of the Pokey scan counter are hooked up. The result of this is that any keypress should actually return 4 different scan codes, which to the POKEY appears as iff 4 different keys where pressed at the same time. This would explain the behavior of the "last key still pressed" bit on SKSTAT.

 

Now, according to the tech reg for the POKEY chip, if debounce is enabled (SKCTL bit 0) and more the one key is pressed at the same time, both key codes are thrown away. If this is all true that would mean that if you turned the debounce on, on the 5200 you would never get a valid keycode back. Can anyone confirm this?

 

Dan

 

quote:

Originally posted by calamari:

 

"On the real 5200, SKSTAT doesn't act like it does on the emulator (take a look at DEBUG52, and view address $E80F.. see how it is $FF then stays $FB while a key is pressed? Not so on the 5200, it is mostly $FF with an occasional $FB). So, we can't use SKSTAT to tell us when the key is no longer held."

 

calamari

 

[ 04-02-2002: Message edited by: calamari ]

Share this post


Link to post
Share on other sites

Confirmed.. you can't type anything with debounce set. I thought the 5200 was freezing up.. but I guess not

 

calamari

Share this post


Link to post
Share on other sites

quote:

Originally posted by Dan Boris:

1. Multi-color Overlapping players. This was my first priority in the new version and I already have it working great. Does anyone know how this effects missiles?

 


 

Dan,

the missiles overlap the same way as the players when bit 5 of PRIOR is on. In fact,you can think of them as just an extension of the player that shares the same colour register, EXCEPT when you use bit 4 on PRIOR, which gives all the missiles a separate colour - They don't seem to do an OR overlap then.

EG bit 5 on. M0 (or P0) over M1 (or P1) have overlap colours.

Hope this helps.

Regards

Share this post


Link to post
Share on other sites

Cool! Now that I know how it's supposed to behave, I just have to figure out how to implement that in the emulator.

 

Dan

Share this post


Link to post
Share on other sites

Dan, another thing peculiar to VSS that I will attempt to describe:

 

I had some lengthy code in my deferred VBLANK routine. Actually, it was the routine which move and animated Pyro, a fairly big software sprite. When I moved the JSR's to Vblank deferred, I noticed no difference in execution, so I kept them there.

 

Anyway, I kept noticing on the actual 5200, and noticeable on Atari800win too, that the screen was slightly flashing and other graphical oddities now & then -- it was this code. I assume I was not getting out of Vblank quickly enough and it messed up my DLI calls with their associated color register changes. I moved the code back out of Vblank -- and the graphical oddities cleared up on Atari800win (i haven't burned a new ROM yet but I bet its the same on the 5200).

 

Again -- VSS didn't seem to notice I was exceeding VBlank time. I'm making a number of assumptions in my conclusions here but it all makes sense to me.

Share this post


Link to post
Share on other sites

I forgot to mention this one. I have noticed if you pop the stack into the wrong registers, VSS doesn't seem to mind.

 

For instance, if I write a DLI that pushes X, Y, and the accumulator to the stack (in that order). Then when the DLI is done pop it in the order Y, X, accumulator VSS will run the program as if there was no problem. Of course the real console will give you strange results.

 

I hope it's not too late to mention that.

Share this post


Link to post
Share on other sites

You aren't the first person to mention this, and I have to say this is strange. Which version of VSS do you see this problem in? I have check the push and pull instructions and they work fine. There must be more to this problem.

 

Dan

 

[ 04-21-2002: Message edited by: Dan Boris ]

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...