Jump to content

playsoft

+AtariAge Subscriber
  • Content Count

    581
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by playsoft


  1. On 11/21/2019 at 9:41 AM, biobern said:

    Three very little things, maybe easy to fix:

     

    - The "time to reach point x - sorry no bonus"-interruption is about 7 seconds in the arcade, about 11 seconds at the Atari. Even longer if you reach a bonus. Too slow if you are a moon patrol speed runner IMHO. ;-) 

    - Musik resets and starts from the beginning if a "rolling rock sequence" starts. Is this an easy fix?

    - maybe demo mode could start automatically between title screens? I absolutely love arcade-like attract modes.

     

    Cheers

    Bern

     

    The Moon Patrol hacks production line has closed down for the rest of the year but there is one thing TIX wants to try that I'll look at next year. If that is possible then I will look at these too, the first one would seem possible not so sure about the others.

    • Like 1
    • Thanks 1

  2. On 11/23/2019 at 3:41 AM, sramirez2008 said:

    Wow! This version is awesome. Excellent work! I can’t stop playing it now.

     

    B53E13CE-1A20-4C4B-AB9B-8A9DC5AB8416.jpeg
     

    DF26BACC-6971-4B96-883D-07B2CD9E88FE.jpeg

    Thanks for posting the pictures.

     

    I was a bit concerned after seeing the Super Community video which had overscan and a black colour change in the display area on the right:

     

    super.jpg.29f0af0d8cc90f3112a1dc1044f299c0.jpg

     

    The amount of overscan will vary depending on the TV/monitor - yours looks about perfect!

     

    My LCD monitor is not bad, a tiny amount on the left:

     

    lcd.thumb.JPG.c97250426ebc6009feca88eddc824724.JPG

     

    My CRT monitor and LDC TV both show a bit more overscan on the left:

     

    crt.thumb.JPG.566989377ae15b6162364582154421fa.JPG

     

    tv.thumb.JPG.0948fc78f71519bc9e3a2d8912040bbc.JPG

     

    I do not see the black colour change at all.

     

    In Altirra, if I configure for extended or full overscan, then I can see the overscan on the right as expected. However I still don't see the black colour change.

     

    • Like 1

  3. On 11/21/2019 at 11:48 PM, Giles N said:

    I was mostly thinking of games like Space Harrier and in general games using a control-stick/pad and a couple of buttons in the gameplay.

     

    Could a RAM extension be built into a converter-piece looking device (like such as the one which enables 2600 games to work on the 5200), function as a true RAM together with the other hardware parts of console, with a cartridge slot on top of it?

     

    I mean, at least theoretically?

     

    Or would a modded 5200

    had to be built?

    The 2600 Cartridge Adaptor is really a complete 2600 without the RF modulator. The 2-port 5200 (and modded 4-ports) have audio and video inputs on the cartridge pin out that you can feed anything into.

     

    It would be completely pointless of course, but you could take an A8, tap off the audio and video signals at the appropriate points and connect them to the correct pins of a 5200 cartridge board. There might be a little more to it than that, but that's effectively how the 2600 adaptor was done.

     


  4. On 11/20/2019 at 5:35 AM, Giles N said:

    So, the question would be:

     

    Can operational RAM be inserted or ‘given’ to the system via a cartridge (included in the hardware of the cartridge), or would it have to be an external RAM devise inserted via another port?

    I don't think it could be done via the cartridge port. I am not a hardware guy, but my understanding is the issue is that there's no read/write line to the cartridge. The Atarimax Ultimate SD cart gets around this in it's read/write mode by having one address range for writing ($4000..$5FFF) and another address range for reading ($6000..$7FFF). Writing also suffers from indexed addressing being unreliable, I don't know if this is due to lack of a read/write line or is something specific to the Atarimax cart. Either way, I think any such scheme would only be useful for new software specifically written for it, I don't think it would be much help in porting existing A8 games.


  5. Tezz, I have no real attachment to Galaga myself, the first time I was really aware of it was from Harvey when working on AtariBlast!

     

    Last year I had a dabble with XOR bitmap mode:

     

     

    This year I spent some time trying out character mode as well as plotting the paths myself. I ran the arcade game on MAME (using a cheat) to try and work out the paths.

     

    From some of the comments that followed in that topic it is clear that Galaga is held in reverence above any other game that's ever been (or not been) ported to the A8. Because of that, and because I don't have that personal attachment, I can't shake the feeling that it's the wrong game for me. Hence I only planned to spend a limited amount of time next year to see if I could do anything acceptable for the expanding formation and then reconsider my options.

     

    I have no doubt you would do a better version than me. If you want to go forward with it, I am more than happy to call it a day (which I might be doing anyway, if I fail with the expanding formation) and you are welcome to everything I've done in case it's of use. I am currently working on a small game for the New Year Disk and I have another game in mind to start after that (which I do have a personal attachment to of sorts).

     

    • Like 5

  6. 30 minutes ago, biobern said:

    Sega pad: That's correct. And the tendency is even bigger with the Sega Arcade Power Stick or self built Arcade sticks where you fire with your index finger and jump with your middle finger. What "final release" are you talking about please?

     

    Cheers

    Bern

     

    The one coming soon!

    • Like 2
    • Thanks 1

  7. 5 hours ago, cgfatari79 said:

    I found this to be a problem too but only in the redux version. Will have to play the original again and check. 

    Both the A8 and 5200 versions I have behave like this (the 5200 uses one trigger to fire and the other to jump, but it is still coded to ignore jump while fire is held).

     

    When you check I think you will find it is present in the original, but if not please send me the image as I'd like to check if there are any other differences too.


  8. 17 hours ago, biobern said:

    I found a problem with the original Atari A8 Moon Patrol AND Moon Patrol Redux: You cannot jump while the fire button is pressed! Really, please try it yourself! When I press both buttons at the same time in front of a hole (I do it regularly in the Arcade version on my MAME cabinet), it sometimes works and sometimes it doesn't, depends on what button I press a millisecond earlier. The result: death! Maybe this behaviour could be changed somehow?

     

    Regards

    Bern

    Yes it is a feature of the original version. I never noticed it playing with an Atari joystick but found it with the Sega pad as there is more of a tendency to rest your thumb on it. I have changed it in the final release.

    • Thanks 1

  9. 8 hours ago, adam242 said:

     

    Just to be clear, when I said "I'm gonna be that guy", I was not offering or threatening to convert your game myself. I meant it jokingly, as "someone always begs for an 8-bit conversion of new 5200 software, I'll be the guy to bring up the subject".  I'd never disrespect someone's work like that, and besides, I simply don't have the skills!

     

    This is a truly incredible WIP.. something many thought impossible. Thank you for sharing it with us, and I hope to see more!

    Sorry, I didn't mean to suggest you were going to pirate it yourself!

    • Like 1

  10. 10 hours ago, adam242 said:

    This is AMAZING. Would love to see it completed and (yeah, I'm gonna be that guy) converted to the A8 computers.

     

    I build for both systems simultaneously since all you need is some conditional code to handle the differences between them. I even did this on AtariBlast! where there are some major differences given its use of the Atarimax Ultimate SD cart.

     

    It is PAL that causes me an issue. I live in a PAL country and my original A8 was PAL but I've been bitten by NTSC and PAL looks fat and slow to me now. I code for NTSC because there are less CPU cycles available per frame and consider PAL afterwards. If a game seems playable enough in PAL with a few tweaks that is fine but I'm less inclined to do more than that as it's repeating things I've already done. That would be my reason not to release, if I was not happy with how it plays in PAL. However, as I found with Scramble it just gets pirated to the A8 anyway so I might as well just release it.

    • Like 5

  11. 17 hours ago, Stephen said:

    WOW!  So I will have to eat crow and take back everything I said about Galaga not being possible (or worth converting) to the 8-bits.  This is one fine piece of soft-sprite code!

    Thanks, I think you are right about the expanding formation though. I wasn't particularly bothered about it when I started but now it has to be present in some shape or form. 

    13 hours ago, AverageSoftware said:

    Wow.  This is one of those things where I just have to try to figure out what's going on.

     

    I'm guessing the starfield is done with two missiles.  The enemies appear to all be playfield, and the player ships might be all four player objects.  I reckon the player's shots are also using the players, and the enemy shots use the other missiles.  Is that about right?

    Pretty much. The player shots are two players and the explosions are two players. The enemy shots are a single missile, the remaining missile is used for the bonus points (left side one frame, right side the next). The character software sprites are expensive in every respect (other than erasing them) so I've tried to use P/Ms for everything else.

    • Like 2

  12. I have been playing around with a Galaga clone. It's on hold for now but when I come back to it next year I will look at the expanding formation. That will be the make or break point for me, if I can do something acceptable I will go ahead with it otherwise I will move onto something else. My aim is to try and do something along the lines of the NES version since I think that is also using playfield for the formation (although it has lots of hardware sprites, too many in a row will flicker). The NES has the advantage that it has more characters available and it isn't spending huge amounts of CPU time drawing software sprites, so I won't be able to match it but hopefully I can do something in a similar vein. Attached is where I'm currently at, pressing 1 or 2 switches between single and double ship.

    test5200.bin

    • Like 18
    • Thanks 2

  13. 7 hours ago, ascrnet said:

    ah ok, I see that it is complicated. Another option that occurred to me is to leave the third button to continue playing. The idea is to use 3 buttons if possible. 😅

     

    Regards

     

    I have located the firing code and I think I can split it. I probably won't get around to trying it out until next week but I presume separate buttons for missiles and bullets is still the preferred option?

     

    Are you sure about just checking against $E4? With the Genesis controller I gave it some headroom, < $20 for release, >= $C4 for press. My reason for doing so was that it's old hardware, both the computer and the controller, so it seemed wise to give it some leeway in case it's not as accurate as it was in its youth.

     

    I noticed on GitHub you don't have Scramble where I supported the Genesis controller. It's not in the pirated version at the start of the topic but it is present in the version I released here:

     

     

    It will automatically use the Genesis C button for bombs.

     

    I wouldn't normally code for something that I don't have the hardware for, but ever since coming back to the A8 I've wanted more buttons. Ideally I'd prefer to buy something ready made but maybe I'll try putting one together as a project over Christmas.

     

    • Like 1

  14. 9 hours ago, biobern said:

    But...but.... this is like in the god given ARCADE version! I'd say you should not try to implement something completely new. Arcade is king!

    I think it's OK, JOY 2B+ owners can still play with the Genesis setting for arcade mode controls. The 3 button mode would give them a unique way of playing the game which maybe in some little way encourages use of JOY 2B+ (although I suspect it will make the game a little more difficult).


  15. 8 minutes ago, ascrnet said:

    Hi Paul,

     

    perfect, if it's not too much to ask you can add JOY 2B+ support to use 3 buttons. one for shooting forward, one up and the last for jumping.

     

    button1
    	lda STRIG0
    	bne button2
    	;......forward shot
        
    button2
    	lda PADDL0
    	cmp #$e4
    	bne button3
    	;.......shot up
        
    button3
    	lda PADDL1
    	cmp #$e4
    	bne fin_joystick
    	;......jump
        
    end_joystick
    regards

     

    I will try, although I don't know if I will be able to separate the shots. The game seems to fire up each time you press the trigger but only fires forward every other time which is a little strange.


  16. 7 hours ago, Gunstar said:

    I did have the word "mostly" in there, but these days people seem to over-look the determiner adverbs, but maybe it's still understating the changes you made, and maybe I used the adverb in the wrong spot, sorry. And yes, it has a multiplexer, I was not specific in saying one of the newer multiplexer's that are multi-color and more multiplexed P/M or software sprites on-screen at once.

    I just meant to point out something unusual on an old A8 game. I'd never have thought of Moon Patrol as using a P/M multiplexer and it wasn't until I tried to change sprite colours that I noticed. It was setting the P/M colour registers on every scanline in that area and I initially thought it was an attempt to provide multicoloured sprites (like the VCS) that had failed and the old code had been left in. Eventually it dawned on me that it was multiplexing.

    • Like 2

  17. 6 hours ago, ascrnet said:

    Hi playsoft,

    Is this project already finished or is it still being tested? I ask why I want to add it to my Joy 2B+ game repository with a small change of SEGA text by Joy 2B+ I hope it doesn't bother you.

    Regards

     

    Things are still being changed! Thanks for asking but feel free to do whatever you like with it, we are already hacking someone else's work after all. If it's a change you would like incorporated before the next release then let me know.

     

    Paul

     

    • Like 1

  18. 1 hour ago, Gunstar said:

    He's still redoing the graphics within the limits of the original program and how the original programmer used the hardware. The improvement is mostly (he had some additional help with the redux than other hacks before) the difference between whom ever did the original pixel art, and what a much better pixel artist can do within the same limits the original game imposes.

     

    What you ask, could be done, and much more, if it was a rewrite/clone/sequel from scratch. With modern development tools and far more understanding from 40 years of programmers discovering what the hardware is capable of, clever programming using multi-plexed P/M's and software sprites, and more memory (most of these were 8k and 16K cartridges originally) to do even more to the game engine, like additional parallax scrolling, DLI's for more color, extended games, etc., so much more is possible. I bet even the big-budget, big (for the time) development team classics that used more powerful computers and main-frames to develop on, Like the Lucasfilm games, for example, could even be enhanced or done better from scratch just with the new PC 8-bit development tools available that are exponentially more powerful than even what the big computers and tools Lucasfilm used back then were capable of as well as the other limitations above.

     

    The old school developers were much more limited in every way; restricted memory, far less advanced languages, editors, and ML monitors, and programming tools, deadlines, budgets, lack of 40 years of knowledge gained on what the hardware can do, so many games could be done much better today than even the P/M and background graphic hacks. This would be true for many games on many different computers and consoles today, not just the Atari, if the computers were better utilized too.

    Just to point out that the changes are not within the limits of the original program. For example, the rear mountains, near mountains and city all used to share a single character set, now they each have one of their own. That is a big factor in the improvements, as well as TIX's art.

     

    Also note the game already employs a P/M multiplexer for the enemy sprites at the top of the screen.

    • Like 2
    • Thanks 2

  19. 3 hours ago, biobern said:

    Thanks for the hack! Such a great game now! Played it in the arcades and loved it, but it was too ugly on the Atari 800 so I always ignored it until now.

     

    - Backgrounds are marvellous!

    - Title Screen is incredible!!

    - Musik: Just wow!

    - Enemies are better than before, but wouldn't it be better to draw all of them in half width? And also to draw the shoots in half width? Seems like an easy modification to me, but maybe I'm clueless.

    - Buggy is much better than before, but isn't there any possibility to go away from the quad pixel thing? Driving the buggy from the title screen would be a dream!

     

    Bern

     

     

     

    Obviously if you made the enemies single width instead of double they'd be harder to hit. Maybe that would be OK or maybe it would make the game too hard.

     

    The buggy on the title screen is single width but uses all 4 players. The buggy in the game is double (and quadruple) width using 2 players. If it were changed to use all 4 players that would present problems elsewhere.

    • Thanks 1

  20. 2 hours ago, shanti77 said:

    @playsoft I'm interested in 16K mode, it would be good if Altirra supported it.

    From the email I have from Steve, you select a 16K read bank by touching $BF80..BFBF. The whole banked area from $4000..$7FFF is then read only memory. However that address range seems like too many 16K banks unless you can map it starting at any 8K offset. I will try it out (I may not have time until after the weekend) and let you know.

     

    Edit: I looked through some of my old tests and see that it is $BF80..BF9F to select the appropriate 16K bank.

     

    I think with Altirra a game probably needs to appear using the format before it is supported. I used the 8K write/8K read mode in the 5200 version of AtariBlast! but I was also loading from the SD card. I did not even think about asking for this to be supported because of the amount of effort required for just one game.

     

    Another possibility would be to use the M.U.L.E. scheme and just put the same code in $8000..$BFFF of every 32K bank. That way when you switch banks only $4000..$7FFF changes. The question is, does Altirra support the M.U.L.E. format in bigger sizes - I will check that too.

     

    Edit #2: Altirra supports "*5200 512K cartridge (32K banks)" so assuming you can bank switch as described above this would be a way to run on Altirra. The Ultimate SD cart also supports this format (as well as it's own formats described above). 


  21. On 10/31/2019 at 9:53 AM, shanti77 said:

     

    Maybe if I had documentation for Atarimax bank switching I could try to do the conversion.

     

    If the game will run with 16K RAM then ROM space shouldn't be an issue.

     

    You have a couple of choices:

     

    (1) There is the bank switching scheme designed by Bryan for M.U.L.E. described here: 

     

     

    I can vouch for the 32K bank switching mode which is also supported by the Atarimax Ultimate SD cart. I believe Albert can make these too.

     

    Edit: the other advantage of this scheme is that it is supported in Altirra

     

    (2) You can use one of the schemes specific to the Atarimax Ultimate SD cart. I described the 8K read/write format here: 

     

     

    There is another option where you just have 16K ROM banks which is very similar, you just write to different addresses. I don't remember off-hand, but if it is something you are interested in I can look it up.


  22. On 10/28/2019 at 5:26 AM, kiwilove said:

    The program has to be designed with the 5200 in mind - for a conversion - that will enable a programmer to make both an 8-bit and a 5200 version of the same game.  To date - only one? programmer has supported both platforms - showing that it is possible to do this.

    Space Harrier wasn't designed this way - and what it managed to do, was to use all resources possible to enable a decent conversion of Space Harrier possible.

    Before this conversion was done - no one would have thought it was possible or a likely candidate for a conversion.

     

    A vague comparison would be Dropzone - which works fine on a 48K machine.  That converting this to run on the 5200 was no easy task - yet this was done.  I'm no programmer - so I can't say whether it's possible to convert Space Harrier or not?

     

    Harvey

    The key to porting any game from the A8 to the 5200 is how much RAM it needs. If a game will run on a 16K A8 then it can almost certainly be ported. If it won't then you need to analyse how much of it is code which can be placed in ROM and how much space it actually needs in RAM. If the resulting RAM requirement does not exceed 16K then it is theoretically possible but it can be very challenging technically. Moving code or variables around is tricky because you have to make sure you have changed all references to them (remember this is using disassembled code, not the original source code). You may also have self-modifying code present which you'll either need to modify or place in RAM. Wrathchild's ports of Dropzone and Mr Do! are truly exceptional.

     

    With regards to Space Harrier, my thoughts are that given it runs on the XL/XE which has 62K RAM, not on the 400/800 with 48K RAM, it's unlikely that the RAM requirement would come in under 16K. The Atarimax Ultimate SD cart offers a way of accessing more RAM but it is of very limited use. So until there is a 64K RAM expansion for the 5200 I do not think it would be possible. Note also the A8 hardware registers are nicely located together in a 2K area (hence 62K RAM and not 64K) while on the 5200 they are a little all over the place (I don't know how this would affect any such RAM expansion). Additionally the biggest 5200 cart is currently 512K ROM where Space Harrier uses a 1024K one. I think this would be less of an issue to the hardware designers on AtariAge than the RAM expansion, although the software would have to deal with 16K banks instead of 8K ones.

     

×
×
  • Create New...