Jump to content

Nukey Shay

Members
  • Content Count

    22,132
  • Joined

  • Last visited

  • Days Won

    4

Nukey Shay last won the day on July 8 2011

Nukey Shay had the most liked content!

Community Reputation

1,810 Excellent

5 Followers

About Nukey Shay

  • Rank
    Sheik Yerbouti
  • Birthday 03/27/1965

Contact / Social Media

Profile Information

  • Custom Status
    Same as the old boss
  • Gender
    Male
  • Location
    The land of Gorch
  • Interests
    Classic gaming

Recent Profile Visitors

58,589 profile views
  1. Wouldn't be difficult, if somebody wanted to. Game's very limited. Could have been a VCS game BITD, I think.
  2. Eeeeh! No. I'm only doing it because the real wizards have no interest in supporting a flaky emulator. Just a fun diversion to me (that ultimately leads to nowhere, like a lotta my hacks). It's like a game where every rule is broken.
  3. Dedicated routines are beginning to look attractive, right? Especially if there's only a few color/sprite font choices in the first place. BTW there is no limit on height so long as there is no limit to Rom. You could have an unrolled loop occupy an entire bank (or multiple banks) if necessary...and just leap to LDY# at whatever sprite size is needed.
  4. Well, then unroll the loop. There's still 3 cycles left over (or 1 cycle, if LAX is not used). The routine then fills 1 page of Rom, but who cares? Means to an end. LF51C ldy #$07 ;2 1st scanline lda (ColorPointer),y ;5 adc ScoreColor ;3 sta COLUP0 ;3 sta COLUP1 ;3 lda (Score1IconPointer),y ;5 sta GRP0 ;3 lda (Score2IconPointer),y ;5 sta GRP1 ;3 lda (Score3IconPointer),y ;5 sta GRP0 ;3 lda (Score5IconPointer),y ;5 sta temp ;3 lax (Score4IconPointer),y ;5 lda (Score6IconPointer),y ;5 ldy temp ;3 stx GRP1 ;3 sty GRP0 ;3 sta GRP1 ;3 sta GRP0 ;3 sta $2E ;3 unused cycles ldy #$06 ;2 2nd scanline lda (ColorPointer),y ;5 adc ScoreColor ;3 sta COLUP0 ;3 sta COLUP1 ;3 ...etc
  5. But that can be pre-calculated and placed into a temp Ram array, which I stated. You might need to weigh the advantages of using a generic subroutine vs. multiple routines dedicated to what is to be displayed. Rom is more plentiful than Ram.
  6. I meant for cracking. Don't know if these things even work anymore 😕
  7. The actual disk. I think I have a supplement disk someplace as well (which contains many more unprotects). Might have to mail this off if nobody has it...no hardware on my side.
  8. Well, I've got it in my hands anyway. Made '86 by Bob Gardner who did Pirate's Treasure Chest.
  9. Sorry...I didn't check the .atr Searching for Duplitech's Backup Master. I can't be the only one who has these things!
  10. Nevermind…. Found it in the Holmes archive here
  11. IIRC the "Backup Master" utility from Duplicating Technologies (Duplitech) has parameters to remove the CP on both versions of Alpha's C.O.S. I know that something like that works, because I sent my original disk to Carmel Andrews a long time ago. Never did get the box of Smarties
  12. I've had to fill the added Ram in Superchip roms with $FF's to get those to be detected by the portable. 100% reliable so far (if that was the only issue present). On the other hand, the 8k hack of Atari's Pac-Man was triggering the Superchip detection for no discernable reason! Some other concerns: VBLANK writes can cause the portable's display to be shifted downward a number of lines. This does not happen in every game...but fortunately, you can completely remove/ignore VBLANK writes for -any- game when running on the portable. Code existing on bankswitch hotspots do NOT trigger the bank...for example, the init code $FFF6: JMP Clean_Start existing in the 2nd bank of an F8 game will not flip to the first bank as the destination address is read. Such code will need to be relocated with a proper bankswitching instruction to work. Multiple reads to SWCHA (during each frame) can cause problems occasionally...try to limit that to once per frame if possible. There is a LOT of inconsistency when dealing with gfx/playfield registers, reset strobes, etc. You may need to add or remove cycles from code when artifacts show up.
  13. The problem is that the last 4 writes to the sprite registers (3 updates + dummy write) need to start in rapid succession exactly 3 cycles before the end of the 2nd sprite's image when VDEL is enabled in both sprites. The TSX instruction disrupts that flow...so it will always be 1 cycle too early or too late in one of the images. You can either live without using that bit position in the GFX data, or rewrite the routine so that the Y register is able to be saved/restored during the loop (and thus, can hold GFX data for one of the sprites in between). Worst-case, use a temp array of 8 bytes to hold pre-determined color data. BTW have you noticed that the HMOVE before the loop is hitting at cycle 61?
  14. Dang! Quoted the wrong person. Anyway, have some brie
×
×
  • Create New...