Jump to content

DEBRO

Members
  • Content Count

    1,958
  • Joined

  • Days Won

    1

DEBRO last won the day on March 21 2010

DEBRO had the most liked content!

Community Reputation

257 Excellent

1 Follower

About DEBRO

  • Rank
    Stargunner

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA
  • Interests
    Atari game programming

Recent Profile Visitors

20,846 profile views
  1. Do you have a demo of the XM working with a CC2 built in high score and POKEY? Also, is there a way for a developer to know the XM is present?
  2. Hi David, As Thomas once told me...just ask There are a number of talented developers on this board that will be willing to help you. How tied are you to your 2LK? I haven't looked too deeply in the code or implementation but based on other games with similar models...we should be able to get this in a 1LK and without the flicker.
  3. Hi David, I'm glad to see you were able to understand and get the bankswitching working but why for this game? There is so much room left in the 4K ROM and opportunities to optimize to claim more space.
  4. Hi David, I assembled your code and yes...now you're safe. The sprite data starts 164 (i.e. A4h) bytes within the page. I see your kernel starts with 163. I hadn't spent a lot of time with this to know exactly where your sprites need to reside within a page but for now...A4h is safe. I'd suggest using constants for this and other values. Trust me, it will help you as you progress in your development. It is a whole lot easier changing a value in your constant section than it is hunting down every where you use it to adjust the value. As an example... ;=============================================================================== ; U S E R - C O N S T A N T S ;=============================================================================== ROM_BASE = $F000 STACK_POINTER = $FF H_KERNEL = 163 Also, as I watched James play your game, I'd suggest using fractional positioning for your sprites. It will help with sprites moving too fast because you'll have more control over their speed. Your PAL50 customers will thank you for it as well. It would help so their game is not 17% slower than the NTSC or PAL60 players. @Andrew Davie and @Thomas Jentzsch helped me with this when I was working on Climber 5. I was adjusting my sprite position the same as you are. This caused my climber to overshoot ladders. Andrew and Thomas came to the rescue. Here is Andrew's explanation on [stella]. In this method you would use 2 bytes for the sprites position. One (the low byte) would be the fraction or decimal portion. This is the portion you would manipulate (+/-). The result of this manipulation would affect the carry flag. You would then adjust the high byte based on the carry. This would be the sprite's horizontal position on the screen.
  5. Hi there, I saw your game on James' show last night. This looks to be a fun and interesting concept. Also congratulations on your first 2600 ASM homebrew! I remember the feeling I had figuring out a 1LK for Climber5. I may be missing something here but the references to Thomas' .skipDraw routine seem to be missing the need to control where in the ROM the sprite data resides. To use .skipDraw properly (as I remember it) you have to ensure your sprite data starts at least the height of the kernel bytes within a page. I know that doesn't read well...sorry. Let's say your kernel is 160 scan lines high (i.e. A0h). That would mean your sprite data would have to start at $xxA0 on a page. You also want to ensure your data doesn't cross a page boundary so you don't end up with an extra cycle when you're looking for a constant cycle kernel. This starting address could be manipulated if you know the limitations of your sprite. For instance, in Pacman4K, my kernel height is 166 (i.e. A6h). The first 4 scan lines are for drawing the playfield so no sprites would be in that area. Knowing that; it should be safe for my sprite definition to start at A2h or anywhere below A2h within the page. Keep up the great work. I'll be watching this progress as I can.
  6. Hi there, I've seen interleaved graphics in the E.T. disassembly. I didn't use a MACRO to have those look better in the listing. The most I gathered from Bob Whitehead's "pattern" is his reuse of code. Here in Football he used XOR more than most. I've seen this in his other games too. The sound data is interleaved too. Using the same bytes he produced music for touchdowns, interceptions, and safety.
  7. Hi there, Attached is my first attempt at reverse engineering a game by Bob Whitehead. Bob Whitehead is credited for creating the six digit display kernel as well as the venetian blinds technique. I've read most don't consider this a proper football game and consider it a bad VCS game. Keep in mind this was released in 1979...before the Intellivision released their NFL Football game. Also, this was done when ROM cost was more expensive. He produced what I consider to be a good representation of the game in 2K of ROM and using 108 bytes of RAM. I remember playing this game with a neighbor that had it and we enjoyed every minute. This listing includes the NTSC version and the PAL50 version that was present on the 32 in 1 cart. The PAL50 version only changed the frame timings for vertical blanking and overscan. All the colors stayed the same as the NTSC version so the colors don't look correct for PAL50. I assume this wasn't a game played in a PAL region being this is considered American Football. I want to thank @Andrew Davie for the INTERLEAVED_GRAPHICS macro in this listing. The graphics for the play indicator are interleaved and the graphics for the offensive indicator are interleaved. This macro was used or created to hopefully allow you to see the true graphics for these sprites. football.zip
  8. Hi there, I saw the demo on ZeroPageHomebrew's Twitch channel. Very impressive as usual. How would these graphics work on for PAL50 refresh? Would the screen refresh too slow to give the same effect of NTSC or PAL60?
  9. Hi Andrew, Thanks! This works perfectly and looks nicer in the text file. I think this would make it easier if anyone would then want to modify the graphics later as well. This is what Homerun would look like... ScoreBoardFonts ITERATION SET 1 REPEAT 5 SPRITE ITERATION, $07, $05, $05, $05, $07 ; |.....XXX| $F700 ; |.....X.X| $F70F ; |.....X.X| $F71E ; |.....X.X| $F72D ; |.....XXX| $F73C SPRITE ITERATION, $22, $22, $22, $22, $22 ; |..X...X.| $F701 ; |..X...X.| $F710 ; |..X...X.| $F71F ; |..X...X.| $F72E ; |..X...X.| $F73D SPRITE ITERATION, $77, $44, $77, $11, $77 ; |.XXX.XXX| $F702 ; |.X...X..| $F711 ; |.XXX.XXX| $F720 ; |...X...X| $F72F ; |.XXX.XXX| $F73E SPRITE ITERATION, $77, $11, $33, $11, $77 ; |.XXX.XXX| $F703 ; |...X...X| $F712 ; |..XX..XX| $F721 ; |...X...X| $F730 ; |.XXX.XXX| $F73F SPRITE ITERATION, $11, $11, $77, $55, $55 ; |...X...X| $F704 ; |...X...X| $F713 ; |.XXX.XXX| $F722 ; |.X.X.X.X| $F731 ; |.X.X.X.X| $F740 SPRITE ITERATION, $77, $11, $77, $44, $77 ; |.XXX.XXX| $F705 ; |...X...X| $F714 ; |.XXX.XXX| $F723 ; |.X...X..| $F732 ; |.XXX.XXX| $F741 SPRITE ITERATION, $77, $55, $77, $44, $77 ; |.XXX.XXX| $F706 ; |.X.X.X.X| $F715 ; |.XXX.XXX| $F724 ; |.X...X..| $F733 ; |.XXX.XXX| $F742 SPRITE ITERATION, $11, $11, $11, $11, $77 ; |...X...X| $F707 ; |...X...X| $F716 ; |...X...X| $F725 ; |...X...X| $F734 ; |.XXX.XXX| $F743 SPRITE ITERATION, $77, $55, $77, $55, $77 ; |.XXX.XXX| $F708 ; |.X.X.X.X| $F717 ; |.XXX.XXX| $F726 ; |.X.X.X.X| $F735 ; |.XXX.XXX| $F744 SPRITE ITERATION, $77, $11, $77, $55, $77 ; |.XXX.XXX| $F709 ; |...X...X| $F718 ; |.XXX.XXX| $F727 ; |.X.X.X.X| $F736 ; |.XXX.XXX| $F745 SPRITE ITERATION, $00, $00, $00, $00, $00 ; |........| $F70A ; |........| $F719 ; |........| $F728 ; |........| $F737 ; |........| $F746 SPRITE ITERATION, $FF, $99, $FF, $AA, $EE ; |XXXXXXXX| $F70B ; |X..XX..X| $F71A ; |XXXXXXXX| $F729 ; |X.X.X.X.| $F738 ; |XXX.XXX.| $F747 SPRITE ITERATION, $EE, $44, $44, $EE, $00 ; |XXX.XXX.| $F70C ; |.X...X..| $F71B ; |.X...X..| $F72A ; |XXX.XXX.| $F739 ; |........| $F748 SPRITE ITERATION, $EE, $AA, $AA, $EE, $00 ; |XXX.XXX.| $F70D ; |X.X.X.X.| $F71C ; |X.X.X.X.| $F72B ; |XXX.XXX.| $F73A ; |........| $F749 SPRITE ITERATION, $FF, $11, $FF, $88, $FF ; |XXXXXXXX| $F70E ; |...X...X| $F71D ; |XXXXXXXX| $F72C ; |X...X...| $F73B ; |XXXXXXXX| $F74A ITERATION SET ITERATION + 1 REPEND
  10. Hi there, I know the title mentions the 7800 and I posted this in the 2600 programming forum but this has to do with the 2600. I've been looking at Bob Whitehead's games lately. I started with reverse engineering Football at the start of the football season. My home team isn't doing so hot this season so I've had a lot of free time to look into this. I'm practically done but I'm proofreading it to try to make sure it's correct. This would be the first time I've looked at Bob Whitehead's work so I've also looked at other works to get an idea of his structure and patterns. Looking at his other work, I've come to Homerun and Boxing. Both of these store the sprites separated by n-number of bytes. As an example he would start the number fonts with the top of the zero sprite. Then the next byte would be the top of the one sprite. The next would would be the top of the two sprite...and so on. It's sort of similar to how the 7800 sprites are separated by pages. To make things look nice in the disassembly, I thought it would be nice to create a MACRO that could take the values grouped together in the text file but separate them when the file was assembled. My first attempt was to do... ScoreBoardFonts CHARACTER_SET $07, ; |.....XXX| $05, ; |.....X.X| $05, ; |.....X.X| $05, ; |.....X.X| $07 ; |.....XXX| DASM didn't like this because it looked at the hex values as literals and complained they weren't defined. Then I went with... ScoreBoardFonts CHARACTER_SET 7, 5, 5, 5, 7 ; |.....XXX| ; |.....X.X| ; |.....X.X| ; |.....X.X| ; |.....XXX| DASM accepts this but my MACRO is having issues. I was hoping to use a REPEAT loop to produce these values. It appears DASM doesn't let you reference a label as an argument. Also, DASM is having an issue with separating the bytes. I'm getting the "Origin Reverse-indexed" error. I thought I'd post my MACRO here and see if anyone had any ideas. One problem I foresee is the ORG at the end. It was to set to next byte however when the character set is done, the code needs to proceed to the next ROM location. MAC CHARACTER_SET .ITERATION SET 0 .ORIGIN SET . REPEAT 5 ORG .ORIGIN + (15 * .ITERATION) .ITERATION SET .ITERATION + 1 .byte {.ITERATION} REPEND ORG .ORIGIN + 1 ENDM
  11. Hi Matt, Sorry for the late response. Yes, I have confirmed this is a bug. I traced it a while ago. I don't remember exactly where it occurs. I would have to trace it again to know exactly.
  12. Hi there, Though this may not be a popular title, I was interested in how they stored the word library and then just finished labeling the entire thing. I was surprised to learn this was done by Alan Miller. The code is similar to his style but I was surprised to find so many optimization opportunities. It's as if the game was started by another engineer and he finished it or may be vise versa. Then again, maybe since it fits nicely within 4K there was no need to return and take the time to optimize. The game uses all of the available 128 bytes of RAM so there are no JSR/RTS used. The library is changed slightly in NTSC and PAL versions as well. For the Third Grade vocabulary COLOR for NTSC is COLOUR for PAL for obvious reasons. For the Sixth Grade vocabulary GLAMOR for NTSC is replaced with GLASS for PAL. For the Ninth Grade vocabulary OMELET for NTSC is replaced with OBLIGE for PAL. For the High School vocabulary JALOPY for NTSC is replaced with JUMBLE. If you are interested in hacking this game you can change values directly in this source and assemble your binary or you can use the Atari 2600 Hangman Editor to easily change graphics or the entire word library. Hangman.zip
  13. Hi there, Thanks. So they only changed the timer values for VBLANK and OVERSCAN to accommodate for the 314 scan lines for PAL50.
  14. Hi there, Is there an official PAL50 version of Atari's Football? Maybe they decided the 15Hz NTSC flicker was going to be too bad on a PAL50 display (i.e. 12.5Hz flicker)?
  15. Hi there, Here's another one from David Crane. Pretty much follows his normal code framework and pattern. laser_blast.zip
×
×
  • Create New...