Jump to content

eshu

Members
  • Content Count

    293
  • Joined

  • Last visited

Posts posted by eshu


  1. 40 minutes ago, alex_79 said:

    It works fine if you set paddles manually in current Stella (6.2).


    Anyway, there's a bug that cause the paddle to jitter badly if you enable the developer options, and in particular "Drive unused TIA pins ..."

    options.thumb.png.5ce066d2fb1660a175112a030b26812e.pngdeveloper.thumb.png.5a4afc7f0642e1d7afaef03a42dc29ce.png


    This typically indicates a missing "#" in front of a constant in the source code, and it's the case here too:

    In bank 1, address $f1d5 there's a "sbc $0f"* that was obviously intended to be "sbc #$0f". Changing the opcode at that address from $e5 to $e9 fixes the problems.

    debug1.thumb.png.48e30f7b779659d06519d4bf89df7621.pngdebug2.thumb.png.a24b7f5c9c444d82a9ddbac82d730c0c.png

     

    Note that the disassembly in the debugger actually shows "sbc $1f" at that line before the fix. I guess it has to do with the fact that $1f is a mirror of $0f (for read accesses).
    @Thomas Jentzsch (I think this part of the stella code is your area), maybe it should show the actual value in this case, as there's no read register defined at that address?
     

    Awesome thank you - I wonder if this is why it's quite so jittery on my real system, my problem is I can't get rid of my paddle jitter, so I assumed it was just that...


  2. Meanwhile the thread at TG goes on and on and on and... Mostly because the real problem is a pretty common one. It is usually waaay easier to prove something exists than to prove it does not.

     

    In this case the definite proof would either be 5.51 on real hardware proven in public OR to provide the exact values for Omnigamer's and my spread sheets. The latter could then be very easily verified by a hacked autoplay ROM.

     

    To definitely prove the opposite seems almost impossible. Yes, you can analyse the game code and built models based on that. But how can you prove that the analysis and models are 100% exact? Even for a simple game like Dragster there will always remain room for doubt.

     

    So I am pretty sure that the score can only be confirmed, but not refuted so that everyone is convinced. And the thread at TG may go on and on and on and... icon_mrgreen.gif

    Random idea - would it be possible to bruteforce every single possible input state for every frame in an accelerated emulator - seems highly parallelizable etc...


  3. I've been looking for info on music- can you please elaborate? I've found the sound maker webpage that plays sound and generates code snippets. I also tried to get VBB running, but havent figured out how to make something and then be able to play it back. Basically, looking for code that had two channels where I can do the (4) pure sounds in one and the (12) Lower Pure in the other. I can then experiment, but would like to be able to change values for note, length, volume, and how to leave spaces. If I could figure out the code part, I could assemble it and play back in an emulator.

     

    Have you looked at TIA Tracker? - http://atariage.com/forums/topic/250014-tiatracker-a-new-sound-routine-and-sequencer-application/

    • Like 1

  4. If you tell me the address I'll have a quick look in stella debugger - but I would guess VSYNC just happens to be being set there, and most TV's are ok with that - does it also get turned off at cycle 15? - It probably should be set straight after WSYNC for three scanlines

     

    i.e.

    lda #%00000010

    sta WSYNC

    sta VSYNC

    sta WSYNC

    sta WSYNC

    lda #0

    sta WSYNC

    sta VSYNC


  5. I was trying to avoid comparing to Stella as that's cheating :-)

     

    Anyway, using Stella revealed something I didn't know. I knew that immediately after a WSYNC the color clock is at 0. (I used the word 'columns' interchangeably with color clock as I'm thinking in terms of scanning across columns of pixels.) However, immediately after a VSYNC you're at color clock 15. As Battlezone sets RESP0 in the first row after a VSYNC I was off by 15 pixels. That explains explains (most of) the 130 to 146 discrepancy. Weird I hadn't noticed this in other games yet.

     

    I don't quite get what you mean by a one clock delay on wide players but maybe that explains the missing 1 from 145 to 146. (Though it might not really be missing, I wasn't counting exactly.) I'll have a peek at your code though. Thanks.

     

    Sorry about accidentally stealing your name. I did some work related to nuclear fusion a while back and really got into stellarators :-)

     

    WSYNC and VSYNC work quite differently.

     

    WSYNC waits for the horizontal blank/sync period so leaves you at cycle 0

    VSYNC is used to set a signal, but doesn't wait for anything - so STA VSYNC is just a normal 3 cycle operation from that point of view

     

    In an emulator I would expect that you would want to synchronize what you are displaying based on when bit one of VSYNC is set high


  6. I noticed you posted a lovely mockup of a Mortal Kombat game in another thread so I'm guessing you're talking about that?

     

    I'm pretty sure the setup you have there would be impossible without flicker.

     

    There are a few tricky ways to re-use sprites, but none of them give you complete control. I'm struggling to put together a good description of what you can do with the "RESP trick" but it's really not practical for moving full size sprites around etc... also I don't think it's very practical to use with double size sprites (I think maybe if you change from single width to double width at just the right time it might work? but it would be a lot of overhead).

     

    I've thought before it might be possible (but tricky) to use a similar setup to that which I used in http://atariage.com/forums/topic/195210-very-early-wip-of-something-ive-been-working-on-for-ages/for a beat-em-up - that uses a player and ball/missile for each player. You could use for instance P0 and BL for player 1 and P1 and M0 for player 2 - but you'd need to be able to change COLUP0 (The colour of P0/M0) at any given cycle and ensure that P0 and M0 were always at least 3 pixels apart......you could use double size players this way......

    • Like 1

  7. Good idea! :) made me to think in reusing the 48-pixel score routine for displaying the aardvark :) Added to TODO list.

    How about using both P1 & P0 double size and different colours like SpiceWare does for the dragon in Medieval Mayhem?? - I'm sure theres a nice post about it somewhere but I can't find it....

    • Like 1

  8. Also, that's a good upportunity to EF[sC] to 6502.ts. Are you perchance hitting NUSIZ just when the first pixel is being rendered?

     

    So the missile (M1) is also being moved - something like:

     

    0000XX

    000XX0

    00XX00

    00XX00

    000XX0

    0000XX

     

    but shown as:

     

    0000X0

    000X00

    00X000

    00X000

    000X00

    0000X0

     

    So I don't think it's an off by one pixel, but it could be off by one machine cycle......I haven't looked at the code for literally years, so I wouldn't like to promise that the old Stella TIA core had it right......I have the source code on an old HDD somewhere, so as Thomas suggests I should maybe try to build a version that works on normal Harmony at some point, if I remember correctly the bank switching etc.. was pretty tight and it wouldn't be as straightforward as you might think to change the bank switching scheme..


  9.  

    It is perhaps a very well tuned code but on a CRT TV it just flickers... yes it is smooth but it flickers.

     

    Not sure if you read the whole thread etc.. , but I thought my comment made it clear it doesn't work properly/universally - but there's at least a lead as to how a smooth scrolling playfield might be achieved. Difficult to know what you mean by flickering in this context, but the likelihood is your TV doesn't like the various butchered signals being sent out by the VCS.....


  10. Hi again :)

     

    Ok - I think this one is a regression from the old core, but I've never run the binary on a real machine - someone might be able to now with a harmony encore? it's an EFSC rom, the menu pointer is made up of a missle, and is supposed to be two pixels wide, I think NUSIZ1 should get changed just in time.....on old Stella it shows up 2 pixels wide, but just 1 on the test release.

     

    The relevant code is run out of zero page, it should be executed from about scanline 179

     

    "scanline b1" in the Stella debugger will get you there, then it's the STX NUSIZ1 run from A6

     

     

     

     

     

    long005.bin


  11. Wow - quick work!

     

    Yep - the 32 char demos etc.. all look right to me now :grin:

     

    However, I am pretty sure that I still haven't got it completely right ;) In particular:

    • The notes suggest that triggering at a specific clock may completely gobble the decode. Do you know which one? My last change just resets the decode logic.
    • Do you know whether the missiles behave similarly?

     

     

    I'm afraid I really don't know either of these - some of the more hardware oriented members might have a better idea from the schematics.....


  12. Not really sure if this should be in the 6502.ts thread or this one, but it's TIA stuff so I hope it's ok here....

     

    I thought I'd try some of the 32 character routines on 6502.ts - these are the ones that expose the issue with extra copies when using multiple RESP0/RESP1 on stella - it looks like the TIA core in 6502.ts gets that bit right - but it seems slightly off with the first copy of P0 (which is actually the second copy to the TIA as the first isn't drawn) on one of the RESP hits. DirtyHarry - a bunch of relevant binaries and pictures of the behaviour on real hardware can be found starting here: http://atariage.com/forums/topic/180632-32-character-text-display/page-2?do=findComment&comment=2280849


  13. As a sidenote: do you have an idea what's going wrong in 6502.ts? It's not the TIA, so that leaves timers, CPU timing and bank switching. I'd definitely like to find out what causes the issue and fix it.

     

    Hi DirtyHarry :)

     

    My first guess would be timers - It's using TIM64T and INTIM to judge when to leave a kernel (as well as other stuff) that it looks like it's getting stuck in........I suspect the bug is made to look worse than it really is as things go a bit mad if it doesn't leave that kernel when it's meant to..........

     

    Edit:

     

    In case it helps - I think (and it's pretty much pure guesswork) that the problem is probably occuring at:

     

    F10C: LDY INTIM

    F10F: CPY ram_C0

    F111: BEQ LF100

     

    (all in Bank 0)

     

    if INTIM is off, even by one, it will carry on this part of the kernel and bad things will happen.....


  14. Hi - great news about the TIA core upgrade ;-)

     

    I hope it's ok to pre-emptively raise an issue here that I think I've at least tried to raise with the old core before....It's difficult to tell if it will be fixed by the new core as the roms I have to hand to demonstrate the issue have other problems in 6502.ts....It's an issue with RESMP0 (/RESMP1) it's been ages since I looked at it but I suspect it relates to the the interpretation of the following passage in the Stella Programmers Guide:

     

     

    RESMP0 (RESMP1)
    These addresses are used to reset the hoiz. location of a missile to the center of it’s
    corresponding player. As long as this control bit is true (1) the missile will remain
    locked to the center of it’s player and the missile graphics will be disabled.

     

    I have a feeling that the issue is the TIA core in Stella interprets "center of it’s corresponding player" literally where it should probably be "4 pixels to the right of it's corresponding player", so that the location doesn't move for a double sized player etc... but it does in Stella - see http://atariage.com/forums/topic/223257-arkanoid-2600/page-3?do=findComment&comment=2985254for example binary.


  15. So one guy has a lost game, sits on it, and another guy recreates it from scratch. Props to nanochess for doing it.

     

    This is StarCastle level stuff here.

     

    In case anyone forgot, A veteran programmer created a Star Castle game, made a prototype, and then asked $32,000 for his "Proto." There were no takers so he sat on it. Then another programmer high in the community began development of a better Star Castle. The first guy ended up doing a kickstarter to release his game, and the second guy finished his version and released it in the AA store the following year. Both are good but the AA version plays superior, though the first game had flashing lights only available in the KS carts.

    To be fair the solidcorp / kickstarter version was using old era tech (I think 8k rom with standard bankswitching) where the AA version is DPC+ I think?

    • Like 1
×
×
  • Create New...