playsoft

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.

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.

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

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.

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. 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.

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

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.

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).

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.

Yes, it would!

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.

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

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.

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.

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).

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.

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.

I once hooked one of these up http://www.hobbytronics.co.uk/usb-host-joystick to the joystick port and was initially ecstatic... until I looked at how long it took to read! I optimised to the point of breaking the i2c protocol (ignoring the occasional bad read) but still it was taking a good third of a frame to read everything.

I think the issue with the 7800 controllers is that they operate in one of two modes; single (both buttons appear to be the standard trigger) or double button (both buttons are independent). However to put it into double button mode you need to provide power to one of the other pins, which is not an output pin on the A8. So to get it working in double button mode on the A8 you would need to modify the cable, so that +5V goes to that pin.

I tried Air Strike II from that collection with a Genesis controller and that works (B fires, C bombs). So I'd guess games that work with a Genesis controller would work with that one. Have you tried it?

Thanks, I had already modified the keyboard code to change the keys for Continue and Demo, so it was easiest for me to hook into that. I haven't changed the keys on the 5200 but hopefully I can do something similar there. Pressing J on the title screen will step through: JOYSTICK = Atari joystick GENESIS = Genesis controller, C will jump but up won't MIX = will work with either controller, up will jump as will C on a Genesis controller really this is the Genesis controller again, but both C and up will jump The settings apply to both ports during a two player game. This also includes tjlazers text layout and a minor bug fix where the stack was filling up. Moon Patrol redux (revision3).xex

The arcade machine has jump and fire buttons: To get a taste of what using a button to jump is like you can play the (standard) 5200 version and decide whether you think it would work. To me it feels really awkward, on Altirra and real hardware too. Maybe the layout of the Genesis controller would make it better, I don't know. So for the 5200 I do intend to release a version where moving the joystick up jumps as it feels so much better (not sure what to do with the existing jump button, leave it as jump or make it fire too... perhaps make 3 x 5200 versions to cover all combinations).

Yes!

Updated with the second option. Moon Patrol redux (revision2).xex

I'm not keen on the first one, second is OK though. If anyone has any more layouts they'd like to see then please post the text as you want to see it so I can just paste it in. ;012345678901234567890123456789012345678901234567 scrcode " START: NEW GAME " scrcode " SELECT: 1 PLAYER C: CONTINUE " scrcode " OPTION: BEGINNER D: DEMO "