Jump to content

playsoft

+AtariAge Subscriber
  • Posts

    656
  • Joined

  • Days Won

    3

Posts posted by playsoft

  1. If testing PAL mode in Altirra made no difference, check the palette with System -> Video -> Adjust Colors... Click on Preset and select default PAL. The platforms become pink, as does DK Jr's face, feet and hands and the pads at the bottom are more yellow than green. This is also what I see on my PAL 800. However I am a bit colour blind!

     

    So we could have a different version for PAL or modify the program to select the appropriate colours for the type of system it is running on.

  2. therealbountybob, on 16 Dec 2015 - 7:13 PM, said:

    Any thoughts on my question about game design using tables for movements / limits, rather than collision detections for everything? Was Popeye the same? Donkey Kong too? I suppose this method ensures the player always stays on the platform rather than moving into it to make the collision, say when jumping, and you can have areas of the screen marked as hostile but the same playfield elsewhere is ok. Has anyone seen an article on this anywhere?

     

    Making these sort of changes does not require all that much knowledge of the game, just the bits you are changing.

     

    I think Popeye uses a mixture of h/w collision and logical maps of some sort. Bottle collision (both punching and being hit by one) looked for h/w collision with the 3 playfield colours contained in the bottle characters. That restricts the rest of the playfield graphics in that they cannot contain those 3 colours together in a position where Popeye might come into contact with them all at the same time.

     

    That is why Popeye's punching was a bit hit and miss (and sometimes bottles would go through him). The change to the punch frame was not synchronized to the display all that well (hence the corruption you sometimes saw) plus the bottles are moving coarsely a character at a time. So there was always a chance you'd miss the 3 colours collision when you really shouldn't.

     

    Not using h/w collision gives you freedom to do whatever you like with the playfield graphics and also avoids situations like the above where the particular collision is not always guaranteed. On the other hand, h/w collision gives you a cheap way of doing it, particularly if you need pixel accurate collision.

     

    With Altirra you can always turn collision detection off and see what happens. You can also break into the debugger and clear screen memory then resume the game and see how it plays. This is DK with all collision detection off and screen memory cleared. Everything still seems to function correctly:

     

    post-16447-0-82064400-1450363363_thumb.png

     

    Both DK and DK Jr seem to be logical and do not use h/w collision, not that I've checked that thoroughly.

    • Like 4
  3. darryl1970, on 14 Dec 2015 - 01:45 AM, said:

    I always thought that was cool too. Actually, the Atari has registers that will offset the screen.

    Likewise, I think Atari is known for it's smooth scrolling.

    However, I think maybe Playsoft told me he tried implementing that, but there was an issue.

     

    I know the arcade version only moves the screen. It don't think all of the characters move with it, but I thought it had something to do with certain things moving.

     

    Anyway, two of my biggest issues with the game would be way more than a hack.

    1. I hate that Brutus always floats to the right side of the screen when punched. I'd love to see him bounce around the screen.

    2. Brutus has really poor AI, and he's really easy to manipulate.

    3. Popeye can't punch in the air.

     

    I think we kind of left it at the sweet spot, where it improves it while playing on the strengths that were already present.

    Playsoft made some pretty sweet changes for not decompiling the code. Pretty impressive. I had fun drawing the characters around an 80's console color and resolution limitations. It was really fun to see how 1 pixel could really change an animation.

     

    I played around with a vertical shake, since that can be done by simply adjusting the blanks at the top of the screen - but the issue was that you'd need to shift all the player/missile graphics too as bits of Olive and Popeye get mixed up and the collision detection goes off. For a horizontal scroll I think you'd need to remap screen memory for a wider playfield.

     

    I never set out to modify the game, just to put Darryl's graphics in it. If someone else wants to do more with the game then I can provide the source for my changes which hook into the original game.

    • Like 2
  4. tep392, on 12 Dec 2015 - 03:51 AM, said:

    I located the platform data in the code. The platform height is measured from the top of the screen. Smaller numbers are higher.

     

     

    I plotted those out for the first level (and think I have done it reasonably accurately):

     

    post-16447-0-91809200-1449926892_thumb.png

     

    They are compared against the top left of Jr, so you can see how he will fall once more than half of him is over the edge.

     

    Interesting that one platform is not covered at all and that others are only partially covered - perhaps something to do with where jumping is possible.

  5. In case it helps, here is the source which builds the xex before Darryl runs a program to put his graphics into it.

     

    The original character set and sprite data contained in the program is compressed. That data is still in there, I just put hooks in to write over the data after it has been decoded. The other hook I have is in the DLI in order to change that colour.

     

    The disassembly is only complete to the extent that it identifies code and data. I make sure any hook leaves the footprint the same and does not change any addresses.

     

    If you do end up making changes to this I will need to search out the colour locations again - the program Darryl has to adjust the colours writes to specific locations in the xex file.

     

    Good luck!

     

    Paul

    xex.zip

    • Like 1
  6. I was able to read the controller with the port configured as an output only for the duration of the read. I also didn't have to clock out the full 16-bits, just the 12 which are used.

     

    I connected up a normal Atari joystick and no damage was done, although I have left a warning in the software. If anyone is interested in trying this out there is a test program which reports the status of all the controller buttons. There is also a patched version of Dropzone with the controls mapped: d-pad = direction, B = fire, Y, A & X = bomb, top L & top R = cloak, Start & Select = pause .

     

    Dropzone was reading PORTA for the stick, TRIG0 for the trigger and CH for the keys. So an OS patch wouldn't have worked for the joystick/trigger but it would have worked for the keys (assuming it allows the user to specify the mapping). I was only thinking of patching games like Dropzone with keyboard controls which would be nice to have on the SNES buttons, but a patched OS would make it more general purpose.

    snes_controller.zip

  7. The timing does not seem strict at all. Below is the code I'm using. I imagine my timing isn't that accurate to begin with and if I remove the HONOR_TIMING code it seems to work just as well.

     

    My concern is suggesting or putting anything out that may harm hardware, whether it is the SNES controller or the A8. I have patched Dropzone, calling the routine below in its VBI routine (with the HONOR_TIMING code present) and I do not notice any slowdown, certainly not on the first couple of levels anyway.

      lda #$06       ; latch = high, clock = high
      sta PORTA
    
    .ifdef HONOR_TIMING
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
    .endif
    
      lda #$02       ; 2 latch = low, clock = high
      sta PORTA
    
    .ifdef HONOR_TIMING
      nop            ; 2
      nop            ; 2
    .endif
    
      ldx #$00       ; 2
      
    loop:
      nop            ; 2
      lda #$00       ; 2 clock = low
      sta PORTA
      
    .ifdef HONOR_TIMING
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
      nop            ; 2
    .endif
    
      lda PORTA
      and #$01
      sta snes_buttons,x
      
      lda #$02       ; clock = high
      sta PORTA
      
      inx            ; 2
      cpx #16        ; 2
      bcc loop       ; 3
    
    
  8. An easy one to start with would be an A8 cart which runs on a 16K machine. That way in your disassembly you need only identify what is code and what is data. You generally don't have to worry about working out what the data is, because even if it contains (RAM or ROM) addresses you can keep the footprint the same on the 5200 (as it was on the A8) and those addresses won't change.

     

    If the program uses any OS services then you will need to provide them, e.g. the count down timers seem to be used quite a lot. You can generally provide just the cut-down functionality required, e.g. typically you can replace a CIOV call to open a screen with a routine to set up the specific display required.

     

    One obscure difference is the 5200 BIOS takes slightly longer to reach a DLI routine than the A8 OS. If you see DLI glitching then you need to make the DLI routine more efficient or move the WSYNC forward a bit.

     

    As ever Altirra does an amazing job of emulating the 5200, the only place you may see differences with real h/w tends to be controller related.

     

     

  9. I have connected a SNES controller to my A8 and wondered if someone with better hardware knowledge can say if this should be OK.

    The SNES controller pinout is shown in section 4: http://www.gamefaqs.com/snes/916396-super-nintendo/faqs/5395

    I connected it to the A8 joystick port:

    SNES 1 +5v to A8 7 +5v
    SNES 4 data to A8 1 up
    SNES 2 clock to A8 2 down
    SNES 3 latch to A8 3 left
    SNES 7 Ground to A8 8 Ground

    I initially tried this with the cheapest SNES controller I could find. It worked OK but the d-pad was poor at giving a distinct direction.

    I then brought a Retro-Bit controller that I thought would be better quality which turned out to be a pack of two. The first controller worked OK, although the d-pad still wasn't great. On the second controller only a few buttons worked. I tried it on my SNES and it was the same.

    I also brought an Eaxus controller which after about 10 seconds use required opening up to reposition one of the rubber pads. However since then it's been fine and the d-pad is perfect.

    Was the non-working controller likely a dud or is it possible that hooking it up to the A8 damaged it? Admittedly my soldering is not very good, so it's possible I may have shorted some wires together when connecting up.

    Also, if you were running software driving a SNES controller with pins 2 and 3 as outputs but accidently left a normal joystick connected, is it likely to cause any damage to the joystick or computer?

     

    Thanks,

    Paul

  10. Unfortunately the 5200 is missing the PIA chip which allows the A8 to use the joystick pins as outputs. I'd guess that's why the Multijoy uses 2 joystick ports. One port is configured as an output on the A8 to signal which joystick it wants to read. The other port is used to read that joystick's values.

  11. darryl1970, on 26 Nov 2015 - 2:45 PM, said:

    After clearing the ship screen, the line to the left of Popeye's head is where the screen RAM was being written, on the "Toot!"

    attachicon.gifShipScreen.png

     

    And if you correct the screen address, you end up with a bottle here:

     

    post-16447-0-78753800-1448571403_thumb.png

     

    It is too much of a coincidence that it ends up on the correct screen row for bottles; one row higher or lower and it wouldn't move. It does use the wrong bottle character though (there's a left one and a right one) and it goes off left straight away. It may well be triggered by Bluto jumping on the see-saw as that was when it occurred last time.

     

    Suffice to say there is a bit of code in there which either didn't get updated properly when it became a 16K RAM game, or that should have been removed but was missed because it has no noticeable effect writing to unused (or missing) RAM.

    • Like 1
  12. therealbountybob, on 24 Nov 2015 - 9:51 PM, said:

    I wonder if it will now be too easy if the punching is reliable :ponder: so some new logic and why not chuck in a new screen too :-D

     

    Because I don't understand the program well enough to do that. I just used the Altirra debugger to hack into it, rather than study a disassembly listing.

     

    Cafeman, on 24 Nov 2015 - 10:31 PM, said:

    I like the 2nd stage's animated water, too bad you couldn't do that on all three stages because its a nice effect.

     

    I realize this is a hack, and adding new stages and other more aggressive changes would likely be impossible without glitches. but I was still brainstorming , wondering what else there is to work on, if you wanted to. The only thing I can think of to add would be maybe a nice animation and sound effect when you drop the bucket on Brutus' head. Right now, there is now sound effect and he just stands there stuck. If you could add even an existing sound effect to sound when you hit him w/bucket, that would be a cool addition.

     

    There should be animated water on the 3rd level too, just not on the 1st. We ended up with a choice of (1) still water, (2) bobbing up and down water, (3) left to right water and (4) combined bobbing/left to right. We preferred (1) and (4) and went with (1) in the 1st level and (4) in the others.

     

    There was a good glitch trying to modify a Sea Hag frame. Darryl noticed there was a character which should have been used in one of the Sea Hag frames but wasn't. When I modified the frame to use it, level 1 played through fine but half the screen was corrupt on level 2.

     

    Another find was the original program occasionally writing beyond the first 16K of RAM (corrupting one of the title screen frames). This turned out to be a bottle character from level 2. Probably at some point during it's development it used more than 16K RAM and screen memory was located at $6000 instead of $3000. If you adjust accordingly the stray bottle then appears on the correct character row (for bottles) by Wimpy.

     

    It looks like the first audio channel is not being used, so potentially a sound effect is possible without having to worry about what the program is doing. If I end up doing anything else to it I will see if I can find something to tell me that Bluto is trapped.

    • Like 2
  13. therealbountybob, on 07 Nov 2015 - 1:14 PM, said:

    Had a good go on 5200 port v7.Great Work guys :thumbsup: 129,410 would have beaten 3rd screen on 4th round but stupidly fell off collecting last letter!

    Looks great. Possibly with Spinach Brutus still was not hit by the arm when I punched him on 2nd screen. I need to do more punching re cans. The toot-toot between levels is a nice addition but it comes in 1 note early. Surely someone can code that round counter's 2nd digit ;)

    attachicon.gifPopeye5200v7.jpg

     

    The last note is missing from the level completion music on the A8 original - for every level - when you run in PAL. There is a PAL entry on atarimania but the image is identical to the NTSC one.

  14. Philsan, on 07 Nov 2015 - 9:13 PM, said:

    Have you considered my idea?

    "Would it be possible to expand only one of the two Popeye sprites, like Bruce Lee when it kicks?"

     

    That is how it is already done. If you look closely you can see that the blue player remains single width and the pink player goes double width.

     

    It works better for Bruce, but it's a simpler design and does not use the or colour. If you made Popeye a 2 colour sprite then Bluto would have to be too - and you can't just go 2 colour for the punch, since Bluto would change too.

    post-16447-0-00759400-1447096868_thumb.png

    • Like 3
  15. Cafeman, on 31 Oct 2015 - 8:00 PM, said:Cafeman, on 31 Oct 2015 - 8:00 PM, said:Cafeman, on 31 Oct 2015 - 8:00 PM, said:

    I don't know why, but I couldn't get any of the 5200 versions to work in A800win4.

     

     

    darryl1970, on 31 Oct 2015 - 9:18 PM, said:darryl1970, on 31 Oct 2015 - 9:18 PM, said:darryl1970, on 31 Oct 2015 - 9:18 PM, said:

    I am also having a problem getting the 5200 images to run on kat5200.

     

    Sorry, I was not clear, they are all A8 images. The _A8/_5200 designation indicates where the original code came from. The _A8 ones are modifications of the original A8 ROM. The _5200 ones are modifications of Homesoft's A8 port of the 5200 hack. They all run on an A8 and there's probably not much difference between the two versions other than that punch ball jump.

  16. I did not have any intention of changing the program other than including Darryl's graphics. We had a new double width punch image but in trying to improve it we settled on a single width image. This necessitated a change in the collision detection because there was no longer an extended arm to trigger the h/w detection.

     

    Also while testing a bottle went through me which I assumed was because of the change in graphics. So I ended up with two new routines, one for detecting if you had punched a bottle and another for being hit by a bottle. However on subsequently playing the original a bottle went through me again, so it was an existing bug. I also managed to walk through Bluto on the original too.

     

    For what it's worth here is a version 6 collection:

     

    PA6_A8.rom - A8 version, new graphics only

    PA6D_A8.xex - A8 version, new graphics/title screen/animated water, punch is double width/original collision detection

    PA6DC_A8.xex - A8 version, new graphics/title screen/animated water, punch is double width/new collision detection

    PA6SC_A8.xex - A8 version, new graphics/title screen/animated water, punch is single width/new collision detection

    PA6D_5200.xex - 5200 port, new graphics/title screen/animated water, punch is double width/original collision detection

    PA6DC_5200.xex - 5200 port, new graphics/title screen/animated water, punch is double width/new collision detection

    PA6SC_5200.xex - 5200 port, new graphics/title screen/animated water, punch is single width/new collision detection

     

    Also includes MaxFlash cart 1/8mbit combined/single images.

     

    Edit: attachment updated with a new double width punch image.

    PA6_update.zip

    • Like 4
×
×
  • Create New...