Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store

ZackAttack

Members
 View Profile  See their activity

  • Posts

    857

  • Joined

 Content Type 

Everything posted by ZackAttack

  1. ZackAttack
    I haven't heard anything other than what was posted in this thread. If you're getting a lot of dpc failure reports with the current version it would probably be worth moving to the latest. Otherwise I'd probably just stick with what you've been using and direct anyone with dpc issues to the experimental version. Some time in the near future I plan on making another build available that will address a very rare problem with JRs and another issue that appears to be related to the startup speed of the cart.
  2. ZackAttack
    Can't you just use a melody/harmony or unocart? Either one can be flashed as a standalone cart and they both should support whichever bank scheme you want to use.
  3. ZackAttack
    Off the top of my head without testing or optimizing I think something like this would work: ; pet movement code lda PetX clc adc PetVX sta PetX cmp #LEFTBOUNDRY bcc ReversePetDirection ; PetX < 20 cmp #RIGHTBOUNDRY bcs ReversePetDirection ; PetX > 144 jmp SkipReversePetDirection ; 20 < PetX && PetX < 144 ReversePetDirection: lda PetVX eor #$ff clc ; must clear carry because it's set or cleared depending on which boundary violation got us here adc #1 sta PetVX ; TODO This would be a good place to toggle the reflection flag if Pet has a directional sprite SkipReversePetDirection Regarding your solution, I think the first adc #0 should actually be adc #1 since the carry flag would need to be cleared to take that code path. If you find that the pet is speeding up each time it crosses the screen twice, that's why. Personally I'd probably just clc before every adc operation until you have a need to start optimizing. Even then you'll probably find better places to start optimizing (low hanging fruit). Hope that helps. -Zack
  4. ZackAttack
    Still feels wrong to me. If your position is 155 you are greater than 20 and branch past the reversedirection code as well as the second check for the right-boundary condition. In a higher level language I think you've created this: if(x < 20) { if(x > 144) { ReverseDirection(); } } But what you really want is this: if((x < 20) || (x > 144)) ReverseDirection(); Or with the logic inverted: if(!(20 < x && x < 144)) ReverseDirection();
  5. ZackAttack
    Second adc PetVX should be adc #0 since carry is set and you need to add 1? Also, shouldn't the reverse direction only be skipped when PetX is greater than left AND less than right?
  6. ZackAttack
    So one issue is that you modified the PosObject Routine: sta HMBL ; 5 19 - store fine tuning of X ;sta.wx HMBL ; 5 19 - store fine tuning of X That sta is only 3 cycles, so the strobe happens 6 pixels early now. Regarding HMCLR, you only need to use that if you need to prevent objects from moving during extra HMOVEs. If you're always calling PosObject for every object and only strobing HMOVE once you don't need to bother with clearing. DON"T FORGET not to strobe HMCLR immediately after a HMOVE. You need to wait at least 23 cycles, but most just hit an extra WSYNC before HMCLR. I think this was one of the problems in the first version you posted. Another issue that you may run into deals with the "bcs DivideLoop88" in the PosObject routine. If that portion of the routine happens to span multiple pages it will cause the branch to take an extra cycle and completely mess up all positioning. It's unlikely to happen since it's only a few bytes of code, but it has happened to me before. Either use ALIGN or put it at $1000 to be sure that doesn't happen.
  7. ZackAttack
    The initial release did not support 512K, but DirtyHairy added a 512K implementation of 3E and 3F schemes and I added ACE, a new ARM based scheme which gives full access to the hardware. If you order the UnoCart today you can definitely get it with the firmware that supports those specs.
  8. ZackAttack
    Yes, there are plans for a SD-less board to be used for stand alone games. There's at least 2 UnoCart specific games in active development that I'm aware of. Btw, those specs are wrong. It has 512KB of flash and 192KB of SRAM and is clocked at 168MHz. (Some lucky customers got a free upgrade to 1MB of flash, but it's best to advertise 512KB for compatibility reasons) I took a photo of my cart that was purchased from MacRorie. All I have is my phone camera though, so I'm not sure this is any better.
  9. ZackAttack
    The DPC changes for Pitfall 2 is the only thing different in this version. If PF2 is already working I would stick with what you have for now.
  10. ZackAttack
    The Uno is newer and is based on a much stronger ARM chip than the Encore. Games that use the ARM chip in the Encore could be ported to the Uno fairly easily since it has more performance. There are games in development for the Uno which are too large to be ported back to the Encore without some significant effort and in some cases it may just not be possible. The one exception is bus-stuffing. This has been demonstrated to work on the Encore. It may or may not work on the Uno. No one has tested it yet. Though the only fully working demo I'm aware of is the raycasting demo I posted a while back and I only call it fully working because no one has reported any glitches to me with the most recent version. The Uno will probably handle bus-stuffing as well as the Encore once someone adds support for it, but until that happens it's a big unknown.
  11. ZackAttack
    Here's another attempt at making DPC work on all systems. Beta disclaimer still applies. 20181009-UnoCart-2600-Firmware.zip
  12. ZackAttack
    Ok. Thanks for the video. I assume the upgrade and downgrade went fine then? I was hoping we could get away with moving some of the audio processing, but it looks like those modulus operations are just too slow regardless. This will require a better understanding of DPC before I can optimize further, but I'll keep working at it until we can find a solution that works for everyone.
  13. ZackAttack
    See http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#bitwise_simplified The & is the bitwise AND operator 6 is %00000110 in binary which is the mask you would need for bits 1 and 2. So _left_right & 6 is basically giving you a value that is only dependent on _left_right{1} and _left_right{2}. Then we compare that value with 6 to verify that both bits 1 and 2 are set. In the second case you only car about bit 0 everywhere so it's possible to just bitwise AND them all together and then the result will only be 1 if all 3 values had bit 0 set. I assume both examples will be smaller and faster because they should reduce the amount of compare/branch pairs needed to implement the same logic.
  14. ZackAttack
    We have identified another bottleneck in the DPC emulation which would cause stability issues on some systems. Here is a beta version of the firmware which should address the issue. I'm including the elf and bin of the firmware for anyone who wishes to program the firmware directly via ST-Link. If you have the 2018-06-30 version of the firmware which includes ACE file support you can simply run the FirmwareUpdater.bin and it will reflash the firmware for you. Keep in mind this is a beta and has only been tested on a single Atari so far. Though it is very unlikely to fail, I can't guarantee this will work for everyone. If power is lost during the update or some other failure occurs you may have to program the firmware via ST-Link in order to recover the cart back to a useable state. I'm also including a copy of the updater with the 2018-06-30 firmware so the firmware updater can be tested easier. The 2018-10-05 version will show a 1 next to R. Edwards, while the 2018-06-30 will just show "By R. Edwards". All feedback is appreciated. To update via SD simply copy 2018-10-05-FirmwareUpdater.bin to the SD card and run it from the UnoCart-2600 menu. Once you run it you must not power off the system until the "Update Complete" screen is displayed. The whole process should take less than a minute. 2018-10-05-UnoCart-2600-Frimware.zip
  15. ZackAttack
    Edited syntax above. Better?
  16. ZackAttack
    I'm not very familiar with bB, but I think replacing this if _left_right{1} && _left_right{2} then with if (_left_right & 6) = 6 then may be faster. Also I think you could replace if _left_right{0} && (rand&1) then gosub __branch with if _left_right & rand & 1 then gosub __branch Of course you would probably want to verify the cycle counts with stella to confirm which way is faster. *Edit: Fixed syntax for equal comparison
  17. ZackAttack
    Awesome premier last night! You've really nailed it with this sequel. One suggestion I would make is for the laser room. It might feel more natural if the lasers slow down and then speed back up when changing direction. I.E. move 1/4 speed when in the left 10%, 1/2 speed in the next 15% and full speed the rest of the time. I think this would really look nice on the vertical moving beams. There also appears to be a slight glitch where the direction changes? It looks like the beam may skip a few pixels during the direction change.
  18. ZackAttack
    You may want to have a registration period and a minimum participation threshold.
  19. ZackAttack
    That's pretty much what I was getting at. Regarding the line spacing I was thinking you'd just skip ever 2nd line, then 2/3 lines, then 3/4 lines etc. Which is why having 3 pixel resolution, aka more lines, would potentially be helpful. Drawing the lines with COLUBK also makes it cheaper to fade the color as the lines go further away since either way you're setting COLUBK.
  20. ZackAttack
    It would look more 3D if you space the lines more as they get closer to you. That may be easier to accomplish if you draw the lines with COLUBK instead of PF since you can get a 3 pixel resolution instead of 4.
  21. ZackAttack
    The paddle has much less area than the ball. It might make the collision detection easier and faster if you draw the pong-ball with P0 and the paddle with P1
  22. ZackAttack
    Do you have time to enable/disable m0 on each line? If you don't draw it then it won't cover p1.
  23. ZackAttack
    If you're going to pad it you might as well go for a full 2K. That way you can be sure it will run on harmony, uno, and any other programmable carts. I tested yours and mine with uno and 7800 on a crt tv. Both of the demos appeared as they do in Stella. Maybe use DIP switches instead so it can be reprogrammed. As amusing and tempting as this is, it might be more practical to take everyone's demos and combine them with a menu program into a single cart. It could be a collection of demos and games that can be played with the cartridge removed since these will all fit in RIOT RAM.
  24. ZackAttack
    This is the best I could come up with in one sitting. It's more of a 2 step process since the TIA is initialized each frame. Zack's 32 byte demo - padded.bin Zack's 32 byte demo.bin
  25. ZackAttack
    I really like how you made this game take up the full screen width despite the DPC+ playfield being limited in width. It would cool if you could choose between kayak or bike and support 2 player VS mode.
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...