Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by playsoft

  1. The i/o pins can't be configured like the 2600/7800/A8 but I don't know if you could make use of the POT common line? This is controlled by software and is normally enabled at initialisation and never touched again. As far as I know the only reason for it to be software controllable is for trak-ball detection; if you read the POTs without enabling POT common you get different values from a joystick and a trak-ball. You usually read the joystick once per frame. You read the POTn registers and store their values in RAM. You then write to POTGO to start another POKEY POT scan. I wonder if disabling POT common for a few cycles then enabling it before writing to POTGO could be used to signal a rumble request? I don't think this would affect a standard joystick as POT common is enabled before the POKEY POT scan is started. With your USB interface, if you can trigger an interrupt on the POT common line, then when you see it go from high to low that is a rumble request.
  2. Well, I did end up giving it a quick go and it did convert easily. The only issue I had was a start up race condition. A routine at $AB47 is called which enables the VBI. Then a routine at $A701 is called which sets the vertical position of the plane. Should the VBI get in before the $A701 routine you end up with an extra image of the plane at the top of the screen. I got around this by syncing to the top of the screen before passing control to your code. It seems to play correctly, I used * & # for select and option. barn5200.bin
  3. @BIGHMW I have moved on from the 5200, so it's not for me. I would appreciate it if you would stop mentioning me whenever you ask for a 5200 port since it puts me in an awkward position. @glurk if you are interested in doing a 5200 port there is @ClausB's guide from ANALOG Computing, Transporting Atari Computer Programs to the 5200. Also @phaeron's Altirra Hardware Reference Manual. If it is something you decide to go ahead with and have any questions please feel free to PM me.
  4. What the Atarimax Ultimate SD provides is: (1) An interface to read data from files on the SD card into the ROM area. Although I used .hyb/.dat pairs in AtariBlast! and the other demos, there is no reason why you couldn't use a .bin file and read from many different files. There is one significant restriction in that you must disable the ROM before you update it. So your code must be running from 5200 RAM as must be any graphics data displayed (alternatively disable the screen). (2) An interface to write data from the ROM area to files on the SD card. For this to be of use you do need to use the .hyb format, since you need to be able to change what's in the ROM area. Being able to read and write files on the SD card gives you the ability to store high score tables, save states and say, load/save pictures with a 5200 paint program, the sort of things you can do on an A8 with a disk drive. (3) Although I don't know them, there must be interfaces for reading and traversing the directories on the SD card, since the Atarimax menu program has this functionality. (4) The hybrid format which is the Atarimax's own bank switching scheme. Hybrid files must be 512K and have the .hyb file extension. The cart area is split so that $4000..$7FFF is banked and $8000..$BFFF is fixed. There is one range of bank switch registers which allow you to select 16K banks in the $4000..$7FFF area, standard 16K bank switching functionality. There is another range of bank switch registers which allow you to select 8K banks, with $4000..$5FFF providing write access and $6000..$7FFF providing read access to that 8K bank. There are more details here: https://atariage.com/forums/topic/221479-5200-ultimate-sd-cart-hybrid-8k-write8k-read-mode/ While this effectively provides additional RAM, it's main use is for writing data to the SD card rather than porting A8 games because of the restrictions associated with it.
  5. I wouldn't! I would think if it were feasible it would have been done by now (and as a PC app rather than embedded firmware on a SD cart). You don't need the .hyb format for that. @Wrathchild has been doing this for years, converting such titles as Dropzone using the bank switching scheme from M.U.L.E. which can be produced as a physical cart or run on the Atarimax Ultimate SD (it supports the M.U.L.E. format in 64K/128K/256K/512K variants). Conversions such as these are the most difficult things to do on the 5200, requiring a lot of time and dedication. It may take many years to do the conversion and get all the bugs sorted out, so I doubt he wants to do TONS of them for you. As a non-programmer the only A8 games you can state as definitely possible to convert to the 5200 are those which run on a 16K 400/600XL. Configure Altirra as either of these 16K machines and see if the game works. If not then you need a programmer to analyse the game. Unfortunately such analysis is not simple, having to look at all aspects where the game may need RAM (screen buffers, character sets, P/M graphics, variables, self modifying code etc.) which is why such questions aren't normally answered with any authority.
  6. As Harvey mentioned, one of the A8 versions runs as a 8mbit/1024K cart. Had there been a 1024K cart for the 5200 I would have targeted that. As there wasn't, it was a choice of having less levels in a 512K cart or using the programming API in the Atarimax Ultimate SD to load the data off the SD card for each level individually. It had it's day in the sun and was enjoying it's retirement. Nothing wrong with that.
  7. I'm not sure about the 5200 version of AtariBlast! posted earlier in this thread because it only seems to be a .hyb file, it should be a .hyb and a .dat file. The final 5200 version (with the updated music) can be downloaded from: https://atariage.com/forums/topic/217200-something-new-gtiablast-5200-wip-for-ultimate-sd-cart/?do=findComment&comment=3612319 More recently there was a thread about where to obtain 5200 homebrews and conversions. I posted a .zip file of everything I'd done which included AtariBlast!: https://atariage.com/forums/topic/321728-5200-homebrew-roms-and-conversions/?do=findComment&comment=4857195 What the 5200 needs is for someone to maintain an archive list/rom pack like @Trebor does for the 7800. I also vaguely remember there being plans for an AtariAge homebrew database at some point.
  8. I've not done anything with the demo since it was originally posted, other than to include the music posted by Jaden and Synthpopalooza. I had planned to investigate what I could do for the expanding formation but ran out of time as I wanted to complete Runner Bear for the 2020 New Year Disk. After that I totally lost interest in 5200/A8 programming, it seemed to become a chore rather than a rewarding pastime. Later, Darryl got me interested in the 7800 after seeing what he had achieved with Popeye. I've enjoyed looking at different hardware and have started a couple of 7800 projects.
  9. I was. These appear to be the last A8 builds. jaden_50.xex jaden_60.xex synth.xex
  10. I did nearly everything in parallel by restricting the A8 to only using the first 16K as RAM and not using the O/S. Then it's the same with a few bits of conditional code to handle the controllers/keys differently. Scramble was released on the 5200 first because I'd spent a long time play testing/tuning parameters in NTSC to get to a point where I was reasonably happy with it. I'd not done any play testing in PAL, only sanity tests to make sure the graphics were OK and that it didn't crash. However the game felt very different under the slower PAL frame rate and I couldn't face going through all that play testing again so soon. I released the 5200 version (as it's NTSC only) and thought I would take a break and do something else, maybe return to do the PAL play testing at a later date if there was interest in an A8 version but unfortunately it didn't work out that way.
  11. The forum search function can be useful when you have problems. Search for Bug Hunt (this forum, all words) and you would have quickly found: https://atariage.com/forums/topic/125406-8-bit-conversions/?do=findComment&comment=3305738 As @SoundGammon says, the trak-ball should be connected to the second port. I don't recall ever publicly releasing the light gun version.
  12. 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.
  13. 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.
  14. 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.
  15. 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
  16. 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
  17. 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.
  18. 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.
  19. 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.
  20. 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
  21. 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.
  22. 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).
  23. 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.
  24. It does! So it's only selecting the defence option which doesn't seem to work in the prototype.
  25. 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
  • Create New...