playsoft

You would have to learn to program first but I think anyone can do that with study and practice. A lot of us here learnt programming when we were kids, writing in Atari BASIC initially, learning 6502 assembler and including some machine language routines in our BASIC programs, then finally writing programs completely in assembler. Obviously this took a number of years and as older adults we might not learn as easily as we did when we were young and your issues may not help. But it is a path you could follow, perhaps to start with spend a year or so learning Atari BASIC with the goal of writing a simple game and see how you get on with that, whether it is something you enjoy or not.

That would be great to have on the 5200! There is @ClausB's guide from ANALOG Computing, Transporting Atari Computer Programs to the 5200 Also @phaeron's Altirra Hardware Reference Manual Good luck with the port. Edit: as it might be a good controller option for the game, there's a trakball guide here.

Having found the code above I then looked for other updates to the velocity variables, hoping to find something that was applying gravity. I found this: 8186 B9 27 DE LDA $DE27,Y 8189 85 64 STA $64 818B B9 36 DE LDA $DE36,Y 818E 85 62 STA $62 8190 B9 3B DE LDA $DE3B,Y 8193 85 63 STA $63 L81F8: 81F8 BD 8B 22 LDA $228B,X ; velocity (low) = velocity (low) + gravity (low) 81FB 18 CLC 81FC 65 64 ADC $64 81FE 9D 8B 22 STA $228B,X 8201 A9 00 LDA #$00 8203 7D A4 22 ADC $22A4,X ; velocity (high) 8206 30 10 BMI L8218 8208 C5 62 CMP $62 ; compare with max velocity 820A F0 17 BEQ L8223 820C 90 15 BCC L8223 820E A9 00 LDA #$00 ; reset velocity (low) 8210 9D 8B 22 STA $228B,X 8213 A5 62 LDA $62 ; set max velocity 8215 4C 23 82 JMP L8223 L8218: 8218 C5 63 CMP $63 ; compare with min velocity 821A B0 07 BCS L8223 821C A9 00 LDA #$00 ; reset velocity (low) 821E 9D 8B 22 STA $228B,X 8221 A5 63 LDA $63 ; set min velocity L8223: 8223 9D A4 22 STA $22A4,X ; set velocity (high) L8226: 8226 BD 8B 22 LDA $228B,X 8229 18 CLC 822A 7D 40 22 ADC $2240,X 822D 9D 40 22 STA $2240,X L8230: 8230 BD 6D 01 LDA $016D,X 8233 7D A4 22 ADC $22A4,X 8236 9D 6D 01 STA $016D,X 8239 4C 70 82 JMP L8270 Which is using the following tables: LDE27: .BYTE $0C,$14,$1E,$26,$00 ; gravity (low) LDE36: .BYTE $04,$04,$04,$04,$02 ; max velocity (high) LDE3B: .BYTE $FC,$FC,$FC,$FC,$FD ; min velocity (high) So it should also be possible to hack gravity.

The second thing I did was to see where the code reads the trigger and follow the path from there. I got to this routine which seems to be applying the flap acceleration to the velocity. I've added comments for what I think is going on: LBCBD: BCBD B5 D0 LDA $D0,X BCBF C9 08 CMP #$08 BCC1 F0 34 BEQ LBCF7 BCC3 BC 59 22 LDY $2259,X ; get flap index BCC6 38 SEC BCC7 BD 8B 22 LDA $228B,X ; velocity (low) = velocity (low) - flap acceleration (low) BCCA F9 2C DE SBC LDE2C,Y BCCD 9D 8B 22 STA $228B,X BCD0 BD A4 22 LDA $22A4,X ; velocity (high) = velocity (high) - flap acceleration (high) BCD3 F9 31 DE SBC LDE31,Y BCD6 9D A4 22 STA $22A4,X BCD9 BD 72 22 LDA $2272,X BCDC D0 03 BNE LBCE1 BCDE DE 6D 01 DEC $016D,X LBCE1: BCE1 A9 01 LDA #$01 BCE3 9D 60 23 STA $2360,X BCE6 9D 72 22 STA $2272,X BCE9 A9 00 LDA #$00 BCEB 9D 4A 01 STA $014A,X BCEE E0 02 CPX #$02 ; x < 2 indicates player BCF0 B0 05 BCS LBCF7 BCF2 A9 12 LDA #$12 ; flap sfx BCF4 4C 85 D4 JMP LD485 LBCF7: BCF7 60 RTS So it's using 2 tables for the flap acceleration: LDE2C: .BYTE $80,$00,$5A,$DC,$00 ; flap acceleration (low) LDE31: .BYTE $00,$01,$01,$01,$01 ; flap acceleration (high) It seems that the first 3 columns are for the enemies, the fourth is the player but don't know what the last column is used for. So it would seem possible to hack the code to adjust the flap power. In the attached I set the first 3 columns to a really small value which stops the enemies from flying. One interesting thing here is that during an egg level, if you just sit on a high platform and don't do much you often end up stuck on that level; everything is cleared but nothing happens other than the occasional pterry attack. This could well be a bug in the original game which doesn't normally manifest itself because things aren't dropping into the lava so much. joust_hack_test_2.a78

I should start by saying that I am not interested in the bounty since it's best not to mix hobby and money plus the VS mode would be too much work. For that I think you'd pretty much need to understand all of the existing code and I've only done that once from a disassembly with 2600 Miniature Golf, which is a 2K ROM and took me a year. The first thing I noticed with the Joust ROM image is that the last 8K at $E000 is identical to the preceding 8K at $C000. It could be a 24K cart with the last 8K mirrored. This might be useful as it would provide free space for any hacks without having to increase the cart size (although that doesn't really matter as it could become a 48K cart). It's always good to have an expert player test to make sure nothing is broken. Maybe you can test the attached which is simply the Joust ROM with the last 8K blanked out (other than the 6502 vectors). Hopefully this will play exactly as the original and will mean that the last 8K is available for hacks. joust_hack_test_1.a78

I never liked using down + fire to bomb in games myself, so went for both fire and bombs with the trigger instead and supported the Genesis/Joy2B+ which is probably the best way to play.

Scramble supports a Sega Genesis or Joy2B+ controller - the second button will bomb. It's too late to make any changes to the control mechanism now.

Yes, Chop Suey was published by English Software originally. That needs a 48K A8 so whoever ported it will have put some effort into doing it. I'm not a h/w guy so can't say how feasible a memory mod is. Probably the most basic would be to have 32K RAM at $4000..BFFF which is swapped out when a cart is present. The cart would need to be able to disable itself, so that you can copy the program from the cart into RAM. It would be nice if the unused address space between the chips could also be mapped to RAM as A8 games often make OS calls that require replacement routines when ported to the 5200. With regards to Black Belt I think it depends on what's missing/wrong. If there are bugs that the original programmer couldn't fix they will be difficult for someone else to. When adding new functionality it depends on how much of the code you need to understand. When porting a game to the 5200 you don't really need to understand how it works; you are looking at what is code and what is data, what can go in ROM and what needs to go in RAM. The only occasion I put the effort in to fully understand a disassembly was when porting VCS Miniature Golf to the A8/5200/SNES. It's only a 2K ROM but I spread that out over the course of a year, although I was learning how the VCS worked at the same time.

Ninja needs a XL so probably not, although if it's just uncompressing itself into the extra memory you might be able to do something with a bank switching cart. Bruce Lee looks more promising but it would still be a lot of work. The only easy ones are those which run on an unexpanded 400 or 600XL. The CX52 joystick is really 2 paddle controllers so the code in Blowsub which reads the A8 paddles is also used to read the 5200 joystick. One thing I did in Blowsub for paddle control was to move the ship to the mid-point of the old and new positions first, so that it looked more like the ship was moving between them rather than instantly appearing at the new position. Sometimes for digital control with the CX52 I split the controller range into 9 zones, dead zone in the middle and 4 either side to give 4 different speeds depending on how far you move the joystick (try Scramble or Yars' Strike). I'm not sure it plays any better than when using a digital stick, but control with the CX52 seems smoother this way. I don't know about a new A8 Arkanoid but there is one in development for the 7800 which looks great: 7800 Arkanoid WIP

Thanks, out of them all Blowsub is my favourite. It's hard to say with Karateka. It is using mode E graphics, which is a bitmap mode and it keeps 2 screen buffers so that one is displayed while the other is drawn. This requires 12K RAM so that only leaves 4K on the 5200 for everything else. Even if that was enough RAM the A8 program is a 90K disk/128K cart so it would be quite an undertaking to try and disassemble and modify something of that size - it could well take longer than programming a new martial arts game from scratch.

It doesn't seem possible to change the defence option (you can step through them with * but it is not selected when you press the trigger).

It is still slow, taking 5 frames to do everything, so running at 12fps. I did wonder if improving the asteroid drawing routines would help but I think it splits the processing over those 5 frames so I don't think there's any easy way of speeding it up.

It does! So it's only selecting the defence option which doesn't seem to work in the prototype.

I modified the defence hack so that shields and hyperspace are activated quickly but flip over is slow (same speed as the original). asteroids_CXL4013_a.bin asteroids_CXL4013_1p_keypad.bin

You must be playing the _a version which has hacked the defence so that it operates more quickly? That then is the reason why the defence activates slowly in the original, so that the flip over is not too fast. For now you could play asteroids_CXL4013.bin if you are using flip over as this version functions as per the original; play asteroids_CXL4013_a.bin if you want the hack for fast activating shields or hyperspace. I will see if I can add another hack for it to operate differently depending on which defence is selected.

Yes. The 5200 prototype bases the thresholds (for up/down/left/right) on the range of values it's seen from the joystick. So you need to move the joystick fully up, fully down, fully left and fully right before control will function properly. This would be an odd thing to have in a commercial release without there being some sort of prompt, but this was just a prototype. Since they had the A8 source code it was probably only a few hours work for someone at Atari to put the prototype together. It may have been just to test what Asteroids would play like with a CX52.

I've not looked at the 5200 prototype in detail, but it doesn't seem possible to change the defence option (you can step through them with * but it is not selected when you press the trigger). I'm also not sure how you select fast asteroids, but I did manage to do it once.

I don't think there is anything wrong with Altirra or anything wrong with my port to the 5200 as I just tested the Asteroids.rom image from atarimania (which is what I disassembled and ported) on a 130XE via a UNO cart and it is exactly the same.

The A8 original behaves the same in Altirra. Maybe the idea is that you are supposed to release it just after it's changed direction IDK.

In this variant player 1 has keypad control: 1 = rotate left 2 = rotate right 3 = defence upper trigger = thrust lower trigger = fire Other players controlled with the joystick as before. asteroids_CXL4013_1p_keypad.bin

It's slow in the 400/800 original, by design from the looks of it.

This won't be enough to bring it up to a C- but it's a port of the (released) A8 version with the controls mapped: start = start game pause = pause/resume game * = defence option (you have to press the trigger to choose it) # = number of players/game type 8 = bounce on/off 0 = fast/slow asteroids It seems to work OK. The _a version has a couple of minor mods, disabled attract mode and sped the defence option up (it was intentionally slow, don't know why). asteroids_CXL4013.bin asteroids_CXL4013_a.bin

Interesting, I wondered if anyone would know (I googled CFE Services and Hardie but didn't get any hits).

It seems to me like the A8 original game also takes a long time to activate the shields but it does have flip over, hyperspace and no effect - where the 5200 prototype has shields regardless of the selection. Edit: Looking at the A8 original 8K cart every byte appears to be used; on the 5200 prototype it looks like there's about 1.5K free so maybe flip over and hyperspace were removed.

This is what I'd expect from the (unhacked) 5200 prototype. It allocates the dead zone based on the range of values it gets from the controllers so it won't know that range until it's seen a full up/down/left/right on the joystick. Once it's had that it's playable. It would be best to use an image dumped straight from the prototype cart but I don't imagine the controller code was modified. I am sure the first thing Atari would have tried is a simple fixed threshold. Perhaps this more sophisticated method was an attempt to improve on it that backfired and it just happens to be this prototype cart that was found. Or it's over engineering. Or all of your consoles are out. When I next set up my 5200 I will see how the unhacked prototype plays for me.