Jump to content

ZackAttack

Members
  • Posts

    854
  • Joined

Everything posted by ZackAttack

  1. There is certainly desire to have it running in Stella. For development purposes I hacked together a modified version of stella which builds the game as part of stella.exe and runs it that way. This is actually great for development purposes because you get all the visual studio tools like conditional breakpoints and the ability to modify variables during runtime. Obviously that's not going to work for a general solution since there would be massive security implications with shipping Atari games as windows/Linux executables. The Uno cart uses a STM32f4 MCU. If there's an open source emulator for the Cortex-M4 it would certainly be possible to add support to stella.
  2. Isn't that exactly what your code is designed to do? ;------------------------------------- ; Skip player movement if attacking (preserving player attacking animation) ; if joy0fire || _Bit0_P0_Attacking{0} then goto __Skip_Player_Movement
  3. I was actually referring to the 128 pixel gapless aspect. Had I posted to the topic I meant to reply to that would have been more obvious. There was just enough room to add support for changing the color each line. The plan is to use this for 128pixel title screens. If text is the only thing you need there's a 36 char kernel. That one's not gapless so it's only good for text. Eventually they will both find their way into the Strong-ARM framework.
  4. A common problem is page boundary crossing. If you have a branch statement that gets moved because some code is inserted before it you could end up losing a cycle if the branch target is in a different page because of the routine being relocated. Stepping through in stella debugger should let you easily see if this is the case or not.
  5. That's exactly what I was looking for. Thanks! Now I just need to port the kernel over to C.
  6. I thought I remember finding a post with a 112 or 128 pixel wide interlaced kernel, but now I can't seem to find it. Did anyone ever succeed at going wider than 96? I found some text kernels which exceeded 24 characters, but they all have gaps in them.
  7. The Collect 2 source probably has an example of how assembly does bank switching in DPC+. Did you look here?
  8. Yeah, I'm not very happy with how badly I implemented my algorithm. I thought the algorithm itself was pretty neat, but after seeing how much better the 6502 wiki solution is I didn't bother trying to fix mine up. Though, fully understanding and commenting that solution might be its own challenge What emulator where you using to test with? I was thinking that we should build a 2600 program to serve as a test harness for future challenges. I.E. for this challenge it could use the RIOT timer to track how long it takes a provided algorithm to perform all 65k possible divisions and then display a total in hex once it's done.
  9. Possible, yes. Practical, no. The two carts use completely different microcontrollers with completely different capabilities.
  10. *** UPDATE 08/18/2023 *** This project has been superseded by the newer elf format and should not be used for any new projects. I'm currently working on some comprehensive libraries for parsing assets, fixed point math, collision detection and more. C++ Libraries and examples will be posted once ready. For now, you may reference the elf tests embedded in the UCA repository here: United-Carts-of-Atari/source/ElfTests at main · Al-Nafuur/United-Carts-of-Atari · GitHub.
  11. This was a really cool challenge. I think my solution is doing something similar to what Crispy's solution does. It uses one less byte of ZP ram and only the A and X registers. I didn't test it to verify that it actually works and I have no idea if it's faster with regards to worst case and average.
  12. Looks like you're making really good progress now.
  13. You're missing indentation on lines 43,44 and 95. I'd recommend indenting more than a single space so it's easier to spot the difference between labels and code.
  14. If you click more reply options there will be an option to attach files. Uploading your .bas file will make it easier for us to help you with the errors.
  15. Sounds like you are looking for this? http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpcplus
  16. Your best bet for getting this on a cart is to program it yourself. I'm sure if you start a new topic in the bB sub forum with some screen shots and source code attached you will find all the help you need. The key here is that you need to demonstrate a reasonable level of effort on your part rather than "it didn't work, can you do it for me". That effort includes posting detailed information about what you want to accomplish, how you've tried to accomplish it and what happened when you tried.
  17. The only difference I have observed is that the movement is one pixel less than on the normal consoles (clamped to 0).
  18. Considering how little ram there is you may be better off using a indexed store to accomplish the same thing. ; Calculate which register to update wherever works best for you lda #HMM0 sta $80 ; Load X with the register in the kernel ldx $80 lda #$e0 sta 0,x ; Which register is written to is now dynamic If all you want to do is toggle between two registers you could use xor. I.E. COLUP0 ^ $01 = COLUP1 and COLUP1 ^ $01 = COLUP0
  19. You will get better responses if you post basic questions to the batari basic sub forum. RT's webpage has everything you need to get started including links to the latest tools http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#gettingstarted
  20. Try sta.w resm1. $0013 = $13 so it probably still assembles as ZP without explicitly saying otherwise with .w
  21. Thanks, if I'm reading it correctly the jr is -7 -8 -9 -10 -11 -12 -13 -14 0 0 -1 -2 -3 -4 -5 -6 instead of -8 -9 -10 -11 -12 -13 -14 -15 0 -1 -2 -3 -4 -5 -6 -7 for both 73 and 74 hmoves Correct, ends on 73. The issue only appears on my jr. On my ntsc 7800 and in stella the position matches the doc. That rom only works on my 7800. It completely crashes on the jr. Probably the harmony firmware though, both the harmony and uno cart hate this system. If I understand this correctly the 73/74 hmove should be fine for the 12 sprite kernel because all 3 copies of P0 and P1 will remain in the middle of the screen and should never overlap with the hmove clock pulses. So based on everything covered above, the detection only needs to differentiate between those two possibilities. And using a normal hmove after wsync will be correct regardless of which system it is.
  22. Well the FW is open source so anyone is welcome to add the additional robustness. There's certainly a chance that something like you described will be necessary, but we'll have to get further along with the updater development before we know if it's truly necessary or not. The ace file format makes it possible to bundle all sorts of new drivers and schemes with a game. That should greatly reduce the need to update FW.
  23. Yeah, that routine takes a varying number of lines depending on object position. Either modify the routine to always consume 2 lines or use the timer again to make the number of lines for positioning all those objects constant. You could also position some of the objects in vblank if they're not used by the score.
  24. Are you using the PositionObject subroutine on the ball after the score is drawn? That routine will take 1 or 2 scanlines depending on the position of the object, which isn't a problem during vblank if you're using the timer, but will cause problems if you're using it to position something in between display kernels.
×
×
  • Create New...