Jump to content

splendidnut

+AtariAge Subscriber
  • Content Count

    501
  • Joined

  • Last visited

Community Reputation

793 Excellent

1 Follower

About splendidnut

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male
  • Location
    PA/NY Border

Recent Profile Visitors

6,778 profile views
  1. Working on it... Hopefully I can get it into a releasable state soon... At least an alpha/beta version.
  2. For reference, @Kitrinx was way more nice/civil in this discussion:
  3. (1) ALL games are always in danger of not being preserved if no one makes the effort to do so. Playability depends on preservation, which depends on people being willing to preserve them. (2) As long as there are emulators available that support emulating the hardware, there's really no need to be concerned. Those working on MiSTER have no obligation to support the hardware unless their goal is to be able to run those enhanced games. (3) Maybe. I would actually argue that one of the goals of programming is to be lazy and not work harder than you need to. In general, any kind of programming is always work regardless of the platform. (4) In Atari 2600 games, ARM based enhancements allow developers to get more out of the system... mainly, get more out of the TIA (audio/video) chip.
  4. Oh man, things are going to get crazy now! Here come the buses to run over the people...
  5. http://www.taswegian.com/WoodgrainWizard/tiki-index.php?page=Dr-Boo's-Woodgrain-Wizadry
  6. Hmmm, crap... Just checked, off by 5 pixels. Don't know why I didn't check to make sure it was centered. Fixed: Score_Code: sta WSYNC lda #0 sta COLUBK inx cpx #100 bne Score_Code sta WSYNC ldx #1 ; 2 2 stx VDELP0 ; 3 5 turn off vertical delay stx VDELP1 ; 3 8 turn off vertical delay ldx #0 ; 2 10 stx GRP0 ; 3 13 make sure player0 is off stx GRP1 ; 3 16 make sure player1 is off stx ENABL ; 3 19 make sure ball is off stx ENAM0 ; 3 22 make sure Missile1 is off stx ENAM1 ; 3 25 make sure Missile0 is off stx REFP0 ; 3 28 make sure reflect is off stx REFP1 ; 3 31 make sure reflect is off ldx #$E0 ; 2 33 ; +2 for HMP0 stx HMP0 ; 3 36 ; fine positioning for player1 stx RESP0 ; 3 39 ; player0 at X=56 = ((39 * 3) - 68)+5 +2 stx RESP1 ; 3 42 ; player1 at X=64 = ((42 * 3) - 68)+5 +1 ldx #$F0 ; 2 44 ; +1 for HMP1 stx HMP1 ; 3 47 ; fine positioning for player1 ldx #3 ; 2 49 stx NUSIZ0 ; 3 52 ; player0 - 2 copies, close stx NUSIZ1 ; 3 55 ; player1 - 2 copies, close lda ScoreColor ; 3 58 sta COLUP0 ; 3 61 sta COLUP1 ; 3 64 sta WSYNC sta HMOVE ; sets player0 X=56, player1 X=64
  7. The code in the link @Karl G provided uses "absolute,y" memory accesses; whereas, you switched them to (indirect),y accesses which take one more cycle each. You need to move the score display kernel code around a bit to compensate for this AND you'll need to adjust your positioning also. Fixed code: Score_Code: sta WSYNC lda #0 sta COLUBK inx cpx #100 bne Score_Code sta WSYNC ldx #1 ; 2 2 stx VDELP0 ; 3 5 turn off vertical delay stx VDELP1 ; 3 8 turn off vertical delay ldx #0 ; 2 10 stx GRP0 ; 3 13 make sure player0 is off stx GRP1 ; 3 16 make sure player1 is off stx ENABL ; 3 19 make sure ball is off stx ENAM0 ; 3 22 make sure Missile1 is off stx ENAM1 ; 3 25 make sure Missile0 is off stx REFP0 ; 3 28 make sure reflect is off stx REFP1 ; 3 31 make sure reflect is off ldx #0 ; 2 33 ; +0 for HMP1 stx HMP1 ; 3 36 ; fine positioning for player1 ldx #$FF ; 2 38 ; +1 for HMP0 stx RESP0 ; 3 41 ; player0 at X=60 = ((41 * 3) - 68)+5 stx RESP1 ; 3 44 ; player1 at X=69 = ((44 * 3) - 68)+5 stx HMP0 ; 3 47 ; fine positioning for player1 ldx #3 ; 2 49 ; X now 1 stx NUSIZ0 ; 3 52 ; player0 - 2 copies, close stx NUSIZ1 ; 3 55 ; player1 - 2 copies, close lda ScoreColor ; 3 58 sta COLUP0 ; 3 61 sta COLUP1 ; 3 64 sta WSYNC sta HMOVE ; sets player0 X=62, player1 X=72 ;--------------------------------- ;--- now draw score ldy #7 sty ImageHeight ; 80 - 8 - 8 - 64 ScoreLoop lda (DigitLivesTens),y ; 5 (70) sta WSYNC sta GRP0 ; 3 (3) hello0->[GRP0] lda (DigitLivesOnes),y ; 5 (8) sta GRP1 ; 3 (11) hello1->[GRP1], hello0->GRP0 lda (DigitThousands),y ; 5 (16) sta GRP0 ; 3 (19) hello2->[GRP0], hello1->GRP1 lda (DigitHundreds),y ; 5 (24) tax ; 2 (26) hello3->X lda (DigitTens),y ; 5 (31) sta Temp2 ; 3 (34) lda (DigitOnes),y ; 5 (39) hello5->A ldy Temp2 ; 3 (42) stx GRP1 ; 3 (45) hello3->[GRP1], hello2->GRP0 sty GRP0 ; 3 (48) hello4->[GRP0], hello3->GRP1 sta GRP1 ; 3 (51) hello5->[GRP1], hello4->GRP0 sta GRP0 ; 3 (54) hello5->GRP1 dec ImageHeight ; 5 (59) ldy ImageHeight ; 3 (62) bpl ScoreLoop ; 2/3 (65) sta WSYNC ; extra blank line to keep it 262 scanlines lda #0 sta NUSIZ0 sta NUSIZ1 sta COLUBK rts
  8. There's been a couple of versions of that done already: (ignore the link snapshots... clearly we live in the future where the forums are sentient and spend all their time perusing memes)
  9. Not a dumb question at all. I don't think I've ever thought of utilizing an editor's code-folding feature for assembly code. Recently, I've gotten into the habit of using macros (MAC name ... ENDM) to encapsulate chunks of code. It's an easy way to make relocatable code.
  10. I'm constantly moving DASM-based projects between Windows and Macs... and so far I haven't hit any issues with line ending characters tripping up assembly.
  11. Somewhere there's a prototype of Marble Madness using a technique similar to this. Oh, that was easy to find:
  12. I'm currently in the processing of getting things working again after playing around with different bank-switching schemes. E7 -> 3EP -> DPC+ I went down the path of creating a sprite blitter to draw the sprites into RAM buffers for display. BUT, I was having trouble finding a bank-switching scheme to easily support doing that. I found that the RAM layout in the E7 bank-switching scheme was too limited for what I wanted to do. I played around with 3EP to the point where I had everything switched over and working, but discovered that the standard Harmony doesn't have any support for it. So I after some consideration, I started switching things over to DPC+. That was a while back... I walked away for a bit, leaving it in a bad state. Just this past weekend, I got things kinda working in again. Currently, the level display is working, but the player isn't; he's upside down (easy fix)... and he can't seem to find the ground anymore. (which are all things caused by switching between banking schemes) At this point, I'll probably throw out the sprite blitter, since it will no longer needed with DPC+. I can just store the sprites in the Display Data RAM/ROM area and use the Data Fetchers. Also, adding back in the "alternating color" magic should be relatively easy now. We shall see... That's the gist of where this is at. Currently... a slow simmer.
  13. Taking a deeper look at the link I posted, it appears the modules are separated out (i.e. the TIA stuff is in a separate folder). Granted, I may be wrong, but I would think that it would still be useful and, if anything, better than starting from scratch.
  14. The CollectorVision Phoenix has an Atari 2600 FPGA implementation available on their github account: https://github.com/CollectorVision/Phoenix2600
×
×
  • Create New...