Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything 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. 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: Both DK and DK Jr seem to be logical and do not use h/w collision, not that I've checked that thoroughly.
  3. This thread started off with the Homesoft port of the 5200 hacked version. Then I started modifying the A8 original too. Then I got fed up of doing everything twice and so just did the A8 original which does not have pause as far as I know.
  4. 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.
  5. Here are the other levels with the boundaries adjusted. I've sent Darryl the changes to extend all platforms by either 1 or 2 and will see how that goes, whether there are any better left alone.
  6. I plotted those out for the first level (and think I have done it reasonably accurately): 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.
  7. First clue - it's something to do with the data written to $1036. On the first screen break and edit $1036 to $F0... that seems to extend the bottom left pad to the entire width of the screen.
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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
  13. Here's one of them, it's a single chip 16K image. cloud.bin cloud_source.zip
  14. 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.
  15. And if you correct the screen address, you end up with a bottle here: 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.
  16. 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. 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.
  17. 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.
  18. 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.
  19. The white (actually light blue) is solid. What you are seeing is just the image I think. Compare Popeye's head with the top of the heart which are both over the same background colour and look similar.
  20. Since I've been mucking about with it, I've been trying to find out who wrote Popeye for the A8/5200. According to this website http://gdri.smspower.org/wiki/index.php/Adrenalin_Entertainment it was David Johnson. Might be worth trying to get an interview?
  21. 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.
  22. 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
  • Create New...