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

djmips

Members
 View Profile  See their activity

  • Posts

    812

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by djmips

  1. djmips

    ATAN2 in 6502

    By djmips,

    Some code rolling off the heavy industries math line today.
     
    I've implemented a straighforward version of a CORDIC ATAN2 routine.
    I've taken a few shortcuts. The #'s are normalized by shifting left 4 (x16) and I've limited the iterations to 8.
     
    The accuracy is around 1 binary radian. (Binary Radians or BRADS : 0 - 255)
     
    The slowest part is the two subroutine calls to ASRN in the inner loop. The slowness is a reflection of the fact that the 6502 doesn't have a barrel shifter, and doesn't have an arithmetic shift right instruction ( and well, chokes on 16 bits a tad)
     
    I still enjoyed creating this routine but it's not the fastest. I've timed it and it takes about 2100 cycles or around 27 scanlines. It could be optimized. The main speedup would be to use shifting tables I think.
     
    I've got another ATAN2 routine planned but it only spits out I think 4 times less accuracy but should be a lot faster.
     
    This routine could also be sped up at the expense of accuracy by using fewer iterations. However, I am going to try out this other idea before I get back to this CORDIC version.
     
     

    processor 6502 seg.u zpage ORG $0080 theta ds 2 x ds 2 y ds 2 rt ds 2 i ds 1 ox ds 1 oy ds 1 HALF equ 32768 MAXL equ 8 seg rom org $f000 Start lda #<$190 sta x lda #>$190 sta x+1 lda #<0 sta y lda #>0 sta y+1 jsr atan2 jmp Start atan2 lda x+1 sta ox lda y+1 sta oy ;x * 16 asl x rol x+1 asl x rol x+1 asl x rol x+1 asl x rol x+1 ;y * 16 asl y rol y+1 asl y rol y+1 asl y rol y+1 asl y rol y+1 lda #0 sta theta sta theta+1 lda y+1 bpl .ypositive ; y = -y lda #0 sec sbc y sta y lda #0 sbc y+1 sta y+1 ; x = -x lda #0 sec sbc x sta x lda #0 sbc x+1 sta x+1 .ypositive lda x+1 bpl .xpositive ; ytemp = y ldx y ldy y+1 ; y = -x lda #0 sec sbc x sta y lda #0 sbc x+1 sta y+1 ; x = ytemp stx y sty y+1 .xpositive ;------------------ ; ldx #0 .cordicLoop stx i lda y+1 bpl .rotateNegative ;rotate positive lda x sta rt lda x+1 sta rt+1 ldx i beq .noshiftxp jsr asrn .noshiftxp ldx y ldy y+1 txa clc adc rt sta y tya adc rt+1 sta y+1 stx rt sty rt+1 ldx i beq .noshiftyp jsr asrn .noshiftyp lda x sec sbc rt sta x lda x+1 sbc rt+1 sta x+1 ldx i lda theta sec sbc atantabL,x sta theta lda theta+1 sbc atantabH,x sta theta+1 inx cpx #MAXL bcc .cordicLoop bcs .done .rotateNegative lda x sta rt lda x+1 sta rt+1 ldx i beq .noshiftxn jsr asrn .noshiftxn ldx y ldy y+1 txa sec sbc rt sta y tya sbc rt+1 sta y+1 stx rt sty rt+1 ldx i beq .noshiftyn jsr asrn .noshiftyn lda x clc adc rt sta x lda x+1 adc rt+1 sta x+1 ldx i lda theta clc adc atantabL,x sta theta lda theta+1 adc atantabH,x sta theta+1 inx cpx #MAXL bcs .done jmp .cordicLoop .done ; if original y was negative lda oy bpl .oyplus lda theta+1 clc adc #$80 sta theta+1 .oyplus ; if original x was negative lda ox bpl .oxplus lda theta+1 clc adc #$40 sta theta+1 .oxplus rts ; arithmetic shift right xtl and xth by X asrn lda rt+1 .shiftr cmp #$80 ror ror rt dex bne .shiftr sta rt+1 rts ; arithmetic shift left xtl and xth by X asln lda rt+1 .shiftl asl rt rol dex bne .shiftl sta rt+1 rts atantabL .byte <8192, <4836, <2555, <1297, <651, <326, <163, <81, <41, <20, <10, <5, <3, <1, <1 atantabH .byte >8192, >4836, >2555, >1297, >651, >326, >163, >81, >41, >20, >10, >5, >3, >1, >1 ORG $FFF8 .word 0 ; for supercharger .word 0 ; nmi vector .word Start ; start vector .word Start ; brk vector
  2. djmips
    Wow, just through sheer good fortune I got to meet in person with cd_w. Since vdub_bobby is close by, the three of of us got together last night to talk shop and have a beer. :-)
     
    cd_w on the left and vdub_bobby on the right. Chris was visiting Seattle and just happened to be doing work at my company. Through some small talk about homebrew he found out that I was there. It's a games company and he was a little surprised to find me there.
     
    I have now met in person almost every person who I've collaborated with on various 2600 projects. I almost met Tommy in Portland but in that case bad fortune somehow kept us in different areas of the show over the course of two days. Seems impossible but it happened. :-)
     

     
    Hey guys, that was a lot of fun! It may have been the beer but I agreed to help vdub_bobby with RPS and I think also vowed to help cd_w with his projects as well. :-)
     
    Cheers!
     
    - djmips -
  3. djmips

    Hello Again

    By djmips,

    Hi, everyone. Yes I have returned. I guess I wasn't gone that long after all. I took a break, everything worked out, and now I feel refreshed.
  5. djmips
    Mega Man 2600 post mortem
     
    It was cool how Mega Man 2600 blew up on the Internets.
     
    It was very fun and hearkens to a time when I thought game programmer was going to be something like rock star. I distinctly remember hero worshiping the Kitchen brothers. The benefactor of this game (iam8bit) had assured me of a modicum of notoriety and it was certainly part of the attractiveness of the project. It was a paying project though, but certainly not the 'big bucks'. It was a lot of fun and so the money wasn't so important.
     
    I also enjoyed very much the opportunity to work through the basic control and 'physics' of a game like this. I've never really done the control portion of such a game (although I've worked on it after the fact) and although it is straight forward it was nice to have worked through all the problems myself and have produced a solid result.
     
    While researching, I became quite proficient at Mega Man in a way that I'd never thought possible. Mega Man was always just a little too hard and frustrating for me. But after all the 'research', I realize that I now posses the ability to finish the game if I so desire.
     
    The research was made all the easier by the huge mountain of data available on the Internet via posted video and data related to time attacks (speed runs).
     
    I used the disassembled code from the original Mega Man to aid me in areas where sheer pondering had left me with some mental road blocks that solving them would have taken too much time.
     
    It's interesting, doing a project such as this where I was drawing upon all my capabilities, (excluding music where I had help). I had to do the disassembly, code design, coding, debugging, planning, level design, art and label art.
     
    I like the quote that paraphrased says that first states that debugging is twice as hard as coding. If you design your code as clever as you can, then by definition you will not be able to debug it.
     
    I found debugging to be the hardest part of this project as usual. I think that this is clearly where I am able to pull something like this off and where many others will fail.
     
    This project was made at the fastest speed imaginable. I thought about it for some time did a fair amount of pre production (AKA procrastinating) on the control and physics and display. When I actually went to code, I didn't have time to work on the display, I coded as fast as I could type, and I coded for many hours without lifting. It is amazing to be in that kind of zone.
     
    I was originally just playing around in Batari Basic, with prototyping the basic Mega Man control but I soon made the decision that I wouldn't have the time to re-code the work in assembler and that there would be no way I could tackle the display issues and so I went forward with making the entire game in Batari Basic with the basic kernel.
     
    The code didn't always work but I iterated and debugging was greatly assisted by the fact that I was using a personal copy of Perforce. If it wasn't for Perforce, I would have become frustrated and given up (which takes a lot for me). I don't use Perforce so much for 'source control' as for another level of 'undo'. It comes in very handy after you've been coding and adding features for several hours and then suddenly the game doesn't work anymore. If you've checked in working version frequently, you can just go back to the previous working version, or diff against the previous working version and see where your code has turned to mud.
     
    I think I have a pretty solid engine for platforming games, and on the 2600 as well! Now I can realize my dream of making Sonic.
     
    The Boss Fight (with Elec Man) was originally coded as a seperate file. I branched the code from the basic game and then I essentially duplicated the Mega Man control/physics/display code to become Elec Man. The Elec Man AI is actually controlling Elec Man via a virtual 'joystick'. This is actually a very common technique in video game (VG) programming and VG AI.
     
    After everything was stable in the boss fight, I folded the code back in. An alternative approach would have been to just combine the binaries at the command prompt, something I did with the Amiga Boing 2.0 cart. The data and code were generated seperately and combined with copy /b
     
    I did make fairly regular use of the Stella Debugger although not nearly as much as I did on LEDhead/BLiP Football. I hate to admit it but it's probably because of the use of Batari Basic which nudged me away from using esoteric bit packed data structures. Remeber the quote, if you are too clever in your coding, you will pay in the debugging.
     
    Things that I would have liked to have done better.
     
    - Full height resolution sprites - Standard kernel Batari Basic is limited to half vertical resolution on sprites. I wish I had noticed that was on the box when I bought it! I had to redraw all my basic set of sprites around this limitation! I grew to like it in the end though because the pixels are closer to square.
    - More colors on sprites, 4 color flickered sprites ( Background, ColorA+ColorB, ColorA+Background, ColorB+Background) and color changing per line
    - A better display. The Metroid Kernel was something that Bob let me look at and use (very grateful) but I didn't have time to try to design or incorporate a better display kernel.
    - Sound effects. Strange that I don't have any because usually I am very much into SFX (sometimes I do them first, before anything else!)
    - More enemies, enemies always take more time than you imagine to code.
    - Ladders. No way to display them, so I left them out.
  6. djmips
    I was recently emailing D. Debro about PSX development and It reminded me that I have a lot of homebrew development hardware.
     
    One of the systems I have is the Charmed Labs Xport. This is a very cool system and while not cheap ($200), it is affordable and you get a lot for the price. It has 4 megabytes of flash and includes a Xilinx Spartan II XC2S150 FPGA which has a claimed 150,0000 programmable gates. While a smaller FPGA, this can still be quite useful for interfacing or as a co-processor. It also has 16 MBytes of SDRAM and a high speed communications/debug port.
     
    As I was saying to Dennis, Charmed Labs has ported eCos and RedBoot . The nice thing is that you can use the inSight source level debugger with this setup.
     
    And yes, you can make games. You don't have to make Robots or even go near the FPGA or 64 pins of I/O... Probably overkill, since you can always develop using the nocash GBA emulator and/or flash carts.
     
    Actually on a shoestring budget, you could still debug (on a flash cart) using GDB/Insight. All you would need to do is include the RedBoot stub in your game and build a serial interface for your GBA. Actually the serial interface is cool in any case because you can also use it as a debug terminal to output useful messages.
     
    The really shoestring method is to make/modify a GBA link cable to connect to a PC and download your game to an unmodified stock GBA using the multiboot method. This is a built in form of game sharing and in normal use, a game is transmitted from a GBA with a ROM onto your friends GBA and you can then play a small multiplayer game with only one cart. The problem is that you probably need a DOS machine to run the xboo software because it is timing critical. The alternative, is to build an intelligent cable with an embedded CPU to handle the synchronous serial without interruption.
  7. djmips

    EPROM Burner

    By djmips,

    For sometime, I've been wanting to burn a few EPROMs but not wanting to shell out for an eraser and burner. I've got a lot of different EPROM carts for various systems like the Vectrex, Gameboy, SEGA Genesis, NES, and 2600.
     
    Just a couple of days ago, I was walking around at my work when I spotted an N64 gang cartridge programmer sitting in the corner collecting dust and it struck me dumb. Of course, we probably have an old burner lying around somewhere. After asking around, it turns out that indeed we do have a burner in a box, in a backroom gathering dust.
     
    Back in the day, we made Gameboy games, at a time when all the carts were tested on EPROM carts. I think there may be still one Gameboy project still running today but they've moved on to flash carts a long time ago.
     
    So I'm pretty excited to finally be able to burn a few carts!
     
    Now.... what should I make...
  8. djmips

    BLiP Football Source

    By djmips,

    Today, I'm posting up the source for BLiP Football.
     
    About BLiP Football. Original name: LEDhead because of being based on LEDhead by Peter Hirschberg. Was released in a small quantity in a beta version at NWCGE 2K6 1.0
     
    I had a lot of help. I was the lead programmer you could say. There is a big contribution from Peter Hirschberg who wrote the PC version LEDhead and was generous in sharing his source code. This gave me a design template and allowed me to shortcut and just focus on the 2600 implementation on the 2600. I originally used a playfield bitmap display (borrowed from bBasic) to get the game 90% up and running. I then contacted Bob Montgomery and he enthusiastically contributed the display kernel and graphics, music driver, title screen subroutines and converted the display elements in the game logic to use BCD.
     
    We swapped the code back and forth. It was a little annoying because our styles are different but it worked out OK, we had cleanly divided areas of work. For me it really helped having the source code in a Perforce server at home (free) so that I was able to more easily integrate Bob's code.
     
    I selected a tune and his brother did the title song. I did the art for the title based on a design by David Exton. Of course, I had to pound out the bugs, alone, shivering in my lonely dark garage.
     
    Bob and Tommy were very quick and I was very impressed with their work.
     
    Doing a sequel - Football II? Or other LED games?
     
    The infrastructure of the game code is already designed to handle Football II without too much difficulty, that is, there is a move up field and move down field for instance. The display code would need some work because Football II uses a 10 yard wide screen and with the extra blip for the ball in the air.
     
    On Football, I made the fire button the run button to get as authentic a feel for running as on the handheld where you would be madly tapping the <> button to go down field. On Football II it would have to be the joystick for the direction control and then the fire button to pass.
     
    I'm probably not going to work on a Football II for the time being, just to get a change of pace. But I wouldn't mind doing it later.
     
    My day job is actually making games but I'm usually the guy writing the 'display kernels' etc and this football project gave me a chance to focus more on the game side.
     
    I'd say the biggest problem I had (besides stupid bugs) was issues with random #'s which I solved after some research and help from postings to the AtariAge homebrew forums.
  9. djmips
    EDIT: the following is actually proven to be an academic exercise since I have been prompted/discovered that if 'developer support' is included in your Stella you have 'developer' command line parameters that let you set the controller left and right properties and the format <NTSC|PAL> and more...
     
     
    I find the Stella debugger useful for some of my debugging but launching it with game specific settings (like paddle controls) can be a bit of trouble.
     
    Here is my solution.
     
    In windows, I use a batch file like so.
     

    dasm apong.asm md5 -n -l -omd5.txt rom\apong.bin split -b 32 md5.txt copy prolog.txt user.pro type xaa >>user.pro type epilog.txt >>user.pro stella rom\apong.bin
     
    It assembles the file (to a folder called rom)
     
    It then generates the md5 checksum with a PD checksum tool by John Walker at fourmilab.
    It then splits the checksum out of the md5 text file using the split tool from the MingW build of the linux (unix) tools.
    It assembles the user.pro file from pre-made start and end parts
    It then launches stella with the rom
     
     
    I've included everything here in this zip. In this example the controllers are always set to paddles. In other cases, I've forced PAL video or odd # of scanlines for instance.
     
    duplicates.zip
  11. djmips
    Here it is with sound. All of the sounds are pretty much straight square waves with some envelope modulation.
     
    The interesting thing is that the missed ball sound is about a B3 for 400ms (24 frames). But it is LFO modulated (amplitude) at 120Hz. I tried 60Hz and it sounded all right, but I wanted it to be better.
     
    What I did was update the sound envelope twice per frame. Once before start of display (after Vertical Blank) and once after display (before Overscan). This isn't quite 50/50 (more like 70/30) but it actually sounds pretty good.
     
    I'm pleased that it turned out.
     
    The paddle hit is a B4 for 16.6ms (1 frames) and also has a bit of an envelope but it would require at least a 240Hz update to get it close. I chose to give it a bit of an attack but not the decay.
     
    The wall hit is a B3 but just a straightfoward square wave for 33.3ms (2 frames). There is no envelope.
     
    Well there it is. The Arcade Pong sounds, as accurate as I can make them. Don't think I ever got to play Pong in an arcade so this is as close as I'll get maybe.
     
    Next up is more gameplay improvements. This includes:
    - the ball colliding with the paddle in the different zones,
    - the various ball speeds.
    - the paddles not having the full vertical range
    - serve delays
    - game over detection
    - game start detection
    - attract mode
     
    Once this is all done, you can start mocking up your Pong cabinets, add a TV and a junior, install the paddles in the cabinet and... well maybe not.
     
    Edited to post in the source:
     
     
  12. djmips

    Arcade Pong

    By djmips,

    I already had it on my TO-DO, to work on an Arcade Pong and when vdub_bobby posted his Arcade Pong demo with the an open offer to work on it.
     
    Now, I have some time and I am putting in some work on Arcade Pong.
     
    So.. here's a new version of the Arcade Pong game.
     
    APong.asm - July 02_01 version
     
    -paddles shorter (snuck in prev changelist really)
    -net thinner
    -collision with paddles work correctly (always rebound away)
    -score digits taller (but not tall enough)
    -changed digit font to match arcade pong
    -1 period filter on paddle read (probably too slow - commented out)
    -digits are now gray (but also ball...)
    -digits are now right justified
    -move digit position to be more like arcade pong
    -removed bottom and top lines which were not in arcade pong
     
    I haven't added sound but I don't have any reference to what it should sound like.
    So far the best references for Pong was the screenshots at KLOV.
    Any additional info or comments on this version is appreciated.
     
    If you have good arcade Pong screenshots or wave files of the sound effects and where to use them, post them here.
     
    Also, I don't know how a two player paddle game can be played on a PC!?
     
    I have been testing this by downloading to the real hardware and it works quite well, the best control is when you sample the paddles at 60Hz and use a one frame averaging filter but there doesn't appear to be enough time in the kernel to test both paddles at 60Hz. Currently the kernel alternates between left and right paddles. I tried the one period averaging filter but this made the control a touch too laggy. It was nice and smooth though. I'll probably make it an option? Problem with too many configuration options is that who wants to go through a big menu system or hitting select a bunch of times just to play a game of Pong? :-)
     
    Source
    Bin
  13. djmips

    Silly young ones

    By djmips,

    My wife just sent me this link which I think is pretty funny.
     
    so cool. heh heh. Can you spot the problem?
     
    http://www.threadless.com/product/133/Game-set-match
  15. djmips

    Arcade Pong status

    By djmips,

    For the one or two of you out there that are following the Arcade Pong project. I'm here to report that I delayed releasing the finished version. It's done but I recently re-discovered the DanBoris' Tech Blog on the original Arcade Pong. I've been poring over the hardware diagrams and trying to understand how it works.
     
    I've managed to glean a few great insights into how the real Arcade Pong worked and I will apply them to the code.
     
    (I've also come away with a desire to build a Pong machine using discrete logic, but I doubt that I will ever fufill that desire.)
     
    For instance, Dan recently (Aug 10th) posted up the circuit for the serve timer (1.7 seconds). It also gives some insight into what the ball should be doing during the 1.7 seconds.
     
    So cool that Dan is doing this, I'd been insanely curious on how Pong worked and now I know (mostly).
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2023 AtariAge

×
×
  • Create New...