rallyrabbit
-
Posts
82 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by rallyrabbit
-
-
Nothing like playing your own game and finding a bug 5 years later.
Needless to say, going to work this and and release a new version.
It appears that if you are on screen when an abduction happens that you will explode no matter what happens. No good. I'll have to get a fix out for that. Not sure if anyone cares, but, its a matter of pride at this point.
-
1
-
-
Hi all,
Not sure how useful this is but I'll post it anyway. I kept switching computers through the year and found the tools I needed for hacking and developing were not as easy to install as possible. So, I created an installer for them that I hope to keep up to date as new tools come out. You can download it from github:
https://github.com/rallyrabbit/AtariTools-Installer
Essentially I put dasm, splitfile, stella, distella, hackomatic in it. Happy to add others that people seem to need or want.
I also have it set up the path automatically in Windows and the uninstaller removes it all.
It's not rocket science, but it does save me some time and thought there might be interest.
If anything else is missing, happy to add those in too. Jus thought this might be a way to help people with the toolsets.
-
4
-
-
Hi all,
Not sure how useful this is but I'll post it anyway. I kept switching computers through the year and found the tools I needed for hacking and developing were not as easy to install as possible. So, I created an installer for them that I hope to keep up to date as new tools come out. You can download it from github:
https://github.com/rallyrabbit/AtariTools-Installer
Essentially I put dasm, splitfile, stella, distella, hackomatic in it. Happy to add others that people seem to need or want.
I also have it set up the path automatically in Windows and the uninstaller removes it all.
It's not rocket science, but it does save me some time and thought there might be interest.
-
2
-
1
-
-
11 minutes ago, SpiceWare said:
The documentation is in the header file DPCplus.h that's available in the Harmony DPC+ programming topic, such as this section which defines the 8 Data Fetcher registers. Refer to DPCplus.asm for code examples.
;---------------------------------------- ; Data Fetcher ;---------------------------------------- ; There are 8 Data Fetchers which are used to access data stored in the Display ; Data bank. Before using, you must point the Data Fetcher at the data to read ; via DFxLOW and DFxHI. After each read the Data Fetcher will update to point ; to the next byte of data to return. ; ; psuedo code* to point Data Fetcher 1 to the color data ; lda #<(ColorDataPosition - HowFarDownScreen) ; sta DF1LOW ; lda #>(ColorDataPosition - HowFarDownScreen) ; sta DF1HI ; .... ; then in the kernel read the Data Fetcher and update the color, takes 7 cycles ; LDA DF1DATA ; STA COLUP0 ; ; * see DPCplus.asm for actual code ;---------------------------------------- DF0DATA DS 1 ; $08 DF1DATA DS 1 ; $09 DF2DATA DS 1 ; $0A DF3DATA DS 1 ; $0B DF4DATA DS 1 ; $0C DF5DATA DS 1 ; $0D DF6DATA DS 1 ; $0E DF7DATA DS 1 ; $0F
If you're planning to use pure 6507 code then DPC+ is what you should use.If you're planning to take advantage of C code running on the ARM processor then CDFJ is the way to go. CDFJ cannot be used with pure 6507 code as most of the data streams can only be configured by the ARM.
Thanks sir!
I've been reading up on your stuff for the past hour so. Simply amazing so far!!!! I have a lot of reading to do to figure this out.
-
1
-
-
7 hours ago, JetSetIlly said:
DPC is defined in a US patent.
https://patents.google.com/patent/US4644495A/en
And for DPC+ I found these links very helpful but nothing as far as I know, nothing formal as a patent.
https://atariage.com/forums/topic/163495-harmony-dpc-programming
DPC+ with ARM
https://atariage.com/forums/blogs/entry/11712-dpc-arm-development/?tab=comments#comment-27116
Ask a vague question and get any answer that comes
that's on me!
Let me rephrase. Is there more formalized documentation on how to use the DPC/DPC+ feature set? I've read all the concepts on the original DPC, which sounds fairly straight forward if not a bit cryptic due to how it works. It's more a case of, as a coder, what specifics do I use to utilize this, recommended best practices, etc. However, your links lead me over to the Harmony/Melody club on AtariAge which I didn't know existed and that has a ton of stuff for me to go through. So shame on me for not finding that on me own!
-
I feel silly asking this, I assumed I could find some information on DPC (and potentially how Pitfall II is written) or DPC+... but I'm not finding any specific information on than sporadic notes... is there nothing more .... formalized?
-
It's going to take a while but i hope to take it, make the display slightly better, colors are little better, add some sound effects and maybe the test between stages like the arcade game had. The original was really good, but when some enhancements especially with the new boards, could really help to get a cleaned up game going on.
This was one of my favorite forgotten games.
-
2
-
1
-
-
Hi all,
Think I might try another hack to see if I can make one of my favorites a better game. This time the Atari 2600 Parker Brothers Gyruss.
Question for anyone here is, before I go disassemble it, has anyone seen a disassembled copy maybe with some comments. I'd rather not start out be reinventing the wheel the someone may have already started.
-
3
-
-
Thanks gents. There's an interesting 8-bit game called Atom Smasher (not like the 2600), concept is cool. I haven't seen a 2600 version of it. Now that I think about it, I might be able to take asteroids as a base and start gutting it. But even then, it's going to be massive.
-
Been reading up the Atari 8-bit a little. I see a lot of games have been ported up to the 8-bit, just curious if its possible to port 8-bit games to the 2600. Looking at things, my gut says maybe but extremely difficult (almost like a rewrite). But curious for the expert opinions here.
-
Version 20 update.
Fixed some routines based on the suggestion above.
Fixed the smart bomb use.
-
On 8/17/2019 at 3:49 PM, Nukey Shay said:
$FFDF...you didn't force STA PF2 to use absolute addressing (STA.w PF2) to consume the remaining unused cycle in the revised city kernel. This is where the skew originates.
There are some other issues in here as well.
LF457: CPY _ramA1 ;3 BCS LF407 ;2 ****Go back to LF407 until the whole play ; area is complete...... LDA (_ram9D_objectGfxVector),Y ;5 STA GRP0 ;3 BNE LF407 ;2
The last line is incorrect...it should be branching to LF40A (to the argument of the BIT opcode). Speaking of which, this:
LF404: LDA #$FF ;2 Color of Enemy shots ; .byte $2C ;4 ao why is this line needed? LF407: BIT $9FB1 ;4
...is just confusing. What the program is really supposed to be doing is this:
LF407: LDA #$FF ;2 Color of Enemy -shots- .byte $2C ;4 skip next 2 bytes LF40A: LDA ($9F),Y ;5 load color of -enemy-
...or rather
LF407: LDA #$FF ;2 Color of Enemy -shots- .byte $2C ;4 skip next 2 bytes LF40A: LDA (_ram9F_objectColorVector),Y ;5 load color of -enemy-
Notice what is happening there? Not only is it more readable, but it would also avoid a glitch in the program if you changed the address of
_ram9F_objectColorVector some time in the future. (aside from getting back the missing tag LF40A to begin with). There is no LF404 in the program either, that tag was unnecessary.
I need some time to weed through this...suffice it to say that when you see a BIT instruction in a program, double-check if it's argument is concealing an instruction itself. BIT is often used to skip bytes.
My apologies. So you basically, you attached the bin files with a fix. So, I used distella to extract and diff against my code to see where you made the changes. Those were the lines that distella output for sections that you changed. My label names have no all been cleaned up for sure. As I have added a removed lots of code, I haven't rampantly changed the labels to match up with the actual addresses yet. I was going to clean this up when I finally stopped coding. I think I get what is going on here vs what distella output, and only the absolute store to PF2 I think I confused something else you recommended earlier as well. So I maintained my loss of cycle here.
Yes, the trails of objects are gone in the city, but I am still seeing the humans migrate around their locations corresponding to a building.
On a side note, I did fix the smart bombs as well.
-
13 hours ago, Nukey Shay said:
You put it back at cycle 1 again ? This has the effect of shifting the humanoids on the surface by 3 pixels (noticeable when moving, the humanoids kind of wobble into place when slowing down). Watch the humanoid close to the ship when you press reset for an example.
But I cannot see the trails you mention in Stella when using the newer city kernel (which removes the flicker from the player ship). That problem should only crop up if the city kernel was not 76 cycles total (or if HMCLR is somehow being skipped). PM the source if you need help tracking the bug down.
I've got nothing to hide in the source. This is kind of a group effort at this point. Here's the code. I am working on the smartbomb routine now, so bombs may not be 100% in this.
-
For the smart bomb fix, I think I can use a pseudo fire button debounce from the value setup in 0xAC. When the bomb goes off, it sets up a countdown in this value. As long as this is non-zero, I should be able to use it to block another bomb from firing.
-
On 8/15/2019 at 7:38 PM, Nukey Shay said:
HMOVE in the city kernel wasn't corrected...it was still @ cycle 1. Fixed here.
BTW you need to correct the smart bomb routine. As it is, the program does not check for the button being held across frames (so you can drain all your bombs in 1 press if you aren't quick). A dirty fix would be to skip 3 of 4, or 7 of 8 frames to provide a delay. A better fix is to set a flag when the button is pressed to check on the next frame if it was already pressed.
I get what you're saying. Essentially in your routine you have edited lines LF402 to LF407 for kicking off the City Kernel. And it loads the current city position into index X before jumping into the kernel. And the city kernel is updated. I can say, every time I add in this code, the people on the group start having trails. So, either there's another piece I'm missing or this doesn't work in my source. I'm going to jump over to the smart bomb problem in the meantime.
-
23 hours ago, Nukey Shay said:
HMOVE in the city kernel wasn't corrected...it was still @ cycle 1. Fixed here.
BTW you need to correct the smart bomb routine. As it is, the program does not check for the button being held across frames (so you can drain all your bombs in 1 press if you aren't quick). A dirty fix would be to skip 3 of 4, or 7 of 8 frames to provide a delay. A better fix is to set a flag when the button is pressed to check on the next frame if it was already pressed.
I'm going to be honest, disassembling this, I do not understand the line in your routine that is:
BEQ LFFE9
where LFFE9 is
LFFE9 = $FFE9
But FFE9 looks like its in between instructions.....
-
v19 release candidate.
Adjusted some sounds (enemy shots and person abduction). Made some adjustments we talked about above. Things look better.
-
17 hours ago, Nukey Shay said:
Why were these 4 lines removed? This is the source of the issue, I think.
LDA read+$4D,X ;4 ORA rF1 ;3 STA write+$4D,X ;5 BNE LD90B ;2 always branch? LD8E7:
Yeah it looks like it. That ay be a victim of an unlocked computer + kids ? thanks. Back to final testing.
-
Well pretty quick I've found another radar bug when a lander picks up a person it starts messing up. So will have to sort that now
the fun never stops!
-
The last version of the game (I guess is v18). Testing now but thing this may be close to being the last spin.
-
On 8/9/2019 at 9:58 PM, Nukey Shay said:
Must be hitting HMOVE a cycle late. Check the debugger that branches executing beforehand are not crossing pages (they will be flagged with ! in Stella's code window).
I think I was off by a cycle somehow (too short) before the branch and throwing off the rest of the loop while decrementing Y.
-
Well, I am almost done. I decided to keep with the simple city. I had to scale back what I Was doing on the radar to maintain the scanline behavior. But now I have another Y index glitch in the city kernel (my code with your change from 7/23). Seems that making the radar work on the proper scanlines has screwed up the solution you came up with for the Index Y checks. Now I either crash when planet is destroyed or have trails on the people waiting to be abducted.
-
So I've been doing some comparisons.
Radar:
Stargate: Scanline 61 to 77
Defender Arcade: 61 to 77
Your build: 61 to 79
Your build of my defender city: 60 to 78 (though I know the problem here on why it starts too early)
My port without your radar code: 61 to 79
My port with you radar code include: 61 to 79
So, I think somewhere, I am 2 scanlines too long, so I'm trying to figure that out now.
Also, do you know which part of the code launches the baiters when the wave takes too long?
-
On 7/19/2019 at 10:15 PM, Nukey Shay said:
You should not WSYNC before you draw the horizontal line below the scanner, this bumps the total to 263.
A time check can be done after the 2nd WSYNC to waste some cycles and store the result to $F0 temporarily. This cuts down the time leading to the city jump later (providing the necessary cycles to use the updated city kernel).
Also, enough space for the full city is obtained by moving the code below $F5C3 to the areas currently being used for the city gfx.
Demo:
defcity.asm 290.95 kB · 3 downloads temp.bin 8 kB · 4 downloads
OK, I think I need some more newbie explanation here. The game seems to run fine with the code I have.... I am not sure i understand the problem I am causing.
I merged in the radar bit that you changed, it does work, but, my scanlines still all lined up....
that's on me!
the fun never stops!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Defender II Hack Attempt - Trying to find 2 portions of code
in Atari 2600 Programming
Posted
Found the culprit bad BNE call. Updated it.
DefenderCity+ v21.bin