playsoft

The hacked version is no longer bound by the 16K ROM/16K RAM limit but hacking the game from single buffer xor sprites to double buffer fully masked sprites is a bit much for me. It could probably be done by the original author though.

Thank you. It's really nice to see someone being proactive like this. They sound great and normally I'd jump at any RMT music on offer, but in this case I am up against it with both CPU cycles and memory. The RMT player usually needs 1.5K for its code and 1K for data tables plus the space for the RMT files. Your files are about 2K so that's 4.5K in total. Although you don't get to hear much of it, the demo includes most of the audio converted from 7800 Galaga (typically the sound effects that I couldn't convert, the enemy death sounds, are those which feature most prominently). Attached is a xex, you can step through the music and sound effects with the trigger. Your music is better but the whole package here comes in at 1.8K and will require less processor time to service. If it does progress further then maybe I could run things by you to see what can be improved. I probably won't get around to looking at this again until later in the year. In the meantime, if you are interested in doing some RMT music, I am currently working on something that needs some good music. Let me know and I'll send you details so you can see if it's something you'd like to do. music.xex

Hopefully this is what you are after. I made a 90K disk image in Altirra, put DOS2 on it and copied the XEX. updated.atr

If it knows that at the point of launch then it's a possibility. I have some other things I want to do, but will take a look later in the year.

They had delays of $11 for the console keys and $0B for the keyboard keys (presumably in frames) during which another key press was ignored. I don't know why they chose these values. I changed them both to $04 and gave it a quick test on both NTSC and PAL machines. It seems OK, no double presses, so see how you get on with it. In the previous update (post #171) a change was made for it to automatically cycle between the title screen and the demo. This has a side-effect of stopping it going into attract mode because I did that by pretending keys had been pressed. updated.xex

Thank you! Although it's been mentioned before I'm not sure I can take credit for anything aiding responsiveness(*). In making the aliens smaller I was able to remove some code that set the size registers, but I doubt that had much impact overall. TIX's great graphics make everything seem better but most of the positives were already there from the original team, just that they were restricted to 16K RAM so it didn't shine as much as it should have. (*) For PAL users, having the music at the correct speed, instead of playing too slowly, may make it seem so.

I was surprised to see it mentioned in yesterday's Metro newspaper over here.

The buggy on the title screen uses all 4 player graphics. You can't use them all for the buggy during the game because they are needed for other things (the bombs being dropped at you, the explosions, the rolling boulders).

I didn't do the uphill music because that looks too tricky but everything else seems OK. updated.xex

You're welcome. I hacked my Mega Drive pad for 3 buttons so I will now be supporting it in the future. One question, if I only support 2 buttons should I still label it as Joy 2B+?

So you made everyone else play the harder version! ? No level data was changed period, so it will play however the original did. You can look at it with this, a hacked version which is generated to test everything out. It still performs collision detection but it won't destroy the buggy so you can make your way through as many rounds as you like (it does cause some glitching with the buggy at times). cheat.xex

Hi Jason, Not sure I can help as it was OK on my 130XE, booted from cold with Option held and then binary loaded from DOS 2.5 via SIO2PC. It is also OK when I load it from the UNO cart. I don't know anything about mydos or mypicodos. I have a 810 which I will probably set up after Christmas for something else so I can try a real disk then, but I can't see it making any difference. Paul

Nothing in that area was changed but unless I am misunderstanding what you are saying it seems OK to me. Beat the default record: Points get added (2350 + 1900 = 4250) but not until after it prints "You have set a new record!": Play again and beat the new record: Points get added (2150 + 2900 = 5050):

There's no ship capture/release but if you haven't already found it, press 2 for dual ships.

I was able to turn my Sega Mega Drive control pad into a 3 button joystick by (1) swapping around the wires from pins 5 & 7 so that +5V is taken from pin 7 on the A8 (2) removing the 74HC157 multiplexer (3) making the appropriate jumper connections between (what were) the multiplexer inputs and outputs. Note this is an original Sega Mega Drive 3 button controller model number 1650 made in China. I also have a model number 1650-50 made in Malaysia but that is different inside, the wires would be harder (for me!) to swap and the chip is surface mount. This is what it looked like before: And after: It may not work with all the JOY 2B+ hacks because I get small values when buttons B and C are not pressed (5 and 3) and those hacks may be looking for 0. However it does work with the 2 games that I have done, Scramble and Moon Patrol Redux which support Sega and/or JOY 2B+ (since I am more forgiving with my checks). Edit: Just tried the hacked version of Defender and it works fine! As does the hacked version of Dropzone.

Yes, replace the original RMT version with the updated one as you don't need them both.

Yes, many thanks for the report ?

It's in the original RMT version by Fandal and Kjmann and seemed to cause a problem with some xex loaders (e.g. Ultimate Cart) but not others (e.g. Atarimax). I was not sure what it was trying to achieve by using BOOT. From what I remember there were at least a couple of instances of it so the simplest fix seemed to be to set BOOT to 1 by adding it to the XEX just before the run:

Hi Tezz, I am full steam on my New Year Disk submission at the moment and will be until the end of the year. After that I'll PM you with details of everything that I've done and we can see if there is any overlap in what we are doing.

You can read about the sort of things which are possible with the expansion port here: As for breaking games down in that manner, that's what I did with AtariBlast! for the Ultimate SD cart. However, it is one thing doing that for games that you wrote, because you have the source code and know how they work. Doing that for other games for which only a binary exists would be 100s of hours of work for a programmer. Just to disassemble and fully understand a relatively simple game can take many months. Even then, it may not be possible. If say a game uses a bitmap graphics mode it may need 8K RAM for the screen. If it uses double buffering, so it shows one screen while it constructs the other, then it needs 2 x 8K RAM for the display - and that is all the RAM on the 5200 used up. Even if there was some sort of internal modification available for the 5200, which gave it 48K or more RAM, you would still need programmers to port the games. This would still be a significant undertaking for old games where only the binaries exist. What it might achieve is more new A8 games being made available on the 5200.

Mark, that explains why it's not going right (98 < A4). From the Caverns of Mars 3 topic, Ken used the same thresholds in Beef Drop so you shouldn't be able to go right in that either. Ideally you should get 00 for left/up, 72 for centre and E4 for right/down. Not many old controllers will be perfect, but your values are a fair bit out. I think you might need to adjust the POT inside your 5200 console to calibrate the controllers - have you ever done that before?

Is anyone else having this issue? I have 4 x original 5200 controllers and the game works correctly with them all. Mark, I remember writing a controller test program, searched for it and found it here in post #19. You were also having the same problem with that game! I don't know if you ever ran the test program, but could you please try it and see what values you get (I've attached it again). Run the program and hold the joystick right, the first hexadecimal value is the horizontal POT and should give a value like E4. The game needs to see a value of A4 or greater in order to move right. cal.bin

Yes the screen was put into wide playfield mode in order to reduce the overscan areas. My LCD is pretty good but both my CRT and LCD TV still show some on the left. You can see mine here: There is discussion about overscan here and a possible hardware fix: In order to "fix" it in Moon Patrol you would have to drop one of the colours. At the bottom of the screen where the buggy is, the four normal playfield colours are green, yellow, light brown and dark brown. The inverse colour is white for the missiles. In order to keep the background colour black you would have to sacrifice one of the normal playfield colours; you need to keep green to blend in with the mountains/city so I guess dark brown would become black.

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.

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: 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: My CRT monitor and LDC TV both show a bit more overscan on the left: 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.