Omegamatrix

James, I'm so sorry to hear about the loss of Pixel. I'm sure Pixel had a great life, great parents... from your post he sounded like quite the rascal and there are lots of great memories of him. It's hard now but there will be a time when It'll be a lot of happy thoughts and not so much pain. It'll get better. Jeff

It's neat watching this grow! You already got a few carts (Kool-Aid Man, Cosmic Corridor, and one of the Xonox Double Enders) that I never had when I had a pile of 'em too. With Tac-Scan I never knew Sega had patches or else I forgot about it.

I miss seeing threads like this, so I'm really glad to see this one develop! Gotta say it doesn't take long to get a collection started and it's always fun to replace a ratty copy with a nicer one and just looking at it all. Jawbreaker is pretty good game, and Stampede too. You need to pick up a copy of H.E.R.O. though. I'm sure you'll get one soon.

I just uploaded a bugfixed PAL60 version of Berzerk for the HSC.

Sure can, just did.

It sounds like the original kill glitch Nukey described. If you don't move a timer increments and you eventually die. His fix I put in place, which is if you move the timer is cleared. So I believe it is not an issue.

Here is a partial solution. Just search for Omega in the assembly. burger12(mod).asm M0 shares its color with P0. When firing without moving up or down the color stays the same, and is the color of the burger on that line. When moving up or down the shot is above or below the line the missile is on, and since P0 is a multicolor sprite the colors have changed. Finally it looks like in the code the color for P0 was being updated all the time, but the graphics wasn't. That works until you get to the present situation. So I put in a branch to skip the color updates when P0 is not being drawn, and set the color of P0 during VBLANK. This will not stop the colors from strobbing while moving the burger but minimize it. BTW the normal solution in this circumstance is to use the Ball, but since the playfield is being used this won't work.

I've sent them a link to the thread for the latest two issues, and I am optimistic that they will take care of the issues at some point at least for the rom downloads. I found another graphical issue in the magic transporter (bank 23). There can be slightly glitched text (or not) depending on your console. Removing 1 cycle from the delay before updating the graphics registers fixes the issue. ;bad timing (some consoles) SLEEP 6 ;6 @44 STA GRP1 ;3 @47 STX GRP0 ;3 @50 STA GRP1 ;3 @53 ;good timing SLEEP 5 ;5 @43 STA GRP1 ;3 @46 STX GRP0 ;3 @49 STA GRP1 ;3 @52

I found another bug. When you are selecting an inventory item the trucks would flash colors intermittently. I traced the error to be a dependency of the Zero flag for branching, but the problem is the value it is testing is a different bank, and the chosen bankswitching method affects the state of the zero flag. ;BANK 1, $FEE5 LDA $FB76,Y LDY $0800,X ; X=6, bankswitch back to bank 6, but this is a load instruction affecting zero flag... ;BANK 6, $FEEB RTS ; goto $FDF8 ;BANK 6, $FDF8 BEQ $FE0E ; this was meant for testing value from LDA $FB76,Y earlier AND #$07 ; if Y=0 this branch is taken and the truck color turns red, ASL ; as $F0 was cleared before and skipped for updating now. STA $F0 ; $F0 holds a value that is loaded into Y later to index what pointers to use.

I was playing tonight and came across the Bunny Bug, so I tracked it down and submitted this report to Audacity: I hope they update their emulation roms with a fix.

Thank you for doing the tribute show. I'm still pretty choked up with Nukey being gone, but now it's all about trying to keep the good things in mind when thinking of him. The tribute show helped by bringing out some of his great work and that goes a long way. Thank you also for reading some of the comments. All I can say is that Nukey deserved all of the recognition and credit, and probably a whole heck of a lot more. At the same time he never sought the recognition. He was always happy to help others and kind of keep it in the background. Nonetheless I'm sure he would have been tickled pink with the show so great job on that once again.

I've disabled the music. Frisco (No Music).bin

@SteveWright if you hadn't written that the Atari Homebrew scene would have grown like it did. It would have certainly slowed it down at the least. You book played such an important role in this! I own a copy of it and have also used the pdf of it extensively over the years. BTW, people really love Championship Soccer too. I started a project to give some original Atari games a menu screen. One of those was Championship Soccer. I hope you like it. https://atariage.com/forums/topic/300168-original-games-updated-with-menus/?do=findComment&comment=4584037 Best regards, Jeff

Yeah I think they did a lot of work together. Galaxian Expanded and WoW too. Here are some of my favorites. I don't know if they are the latest roms: Bottomless Pitfall! (Pitfall! Hack) (2004) (Kurt Howe).bin Hack 'Em - Hangly Man (16K) (Pesco Hack) (2006) (Kurt Howe).bin Monkey_Test.bin Space Invaders Deluxe (8K) (Space Invaders Hack) (2005) (Kurt Howe).bin WoW16k.bin Jr. Pac-Man Throttle (Jr. Pac-Man Hack) (2005) (Kurt Howe).bin WoW I think is an older Version an older version I think. Check KevinMOS3's thread for new roms, and the Galaxian rom. Monkey Test is built off a previous Jungle King hack, but the stuff added is great. I love Jr. Pac-Man Throttle. Makes that game so much more playable.

I want to say this. There are people on these forums you always hope to meet one day. Nukey was at the top of this list. His hack threads were always interesting and kept you coming back for more. I really enjoyed reading them. I'm glad to see people here are universally recognizing how generous, helpful, and friendly he was. That shined right through his spirit. I can also add that he had a great sense of humor and well, a little bit of magic. There was always something different with Nukey's hacks. You just knew it was going to be great. They captured and translated the arcade spirit so well. You knew that he must have spent a lot of time in the arcades playing these games, loving these games. Nukey was the Hack Master. There is no other, and there never shall be again. God rest your soul Nukey. We know you are with the big Pac-Man in the sky now.

Oh my God. I am literally shaking here reading this. This is an unimaginable loss. R.I.P Kurt. You will forever be missed.

I agree with Cafeman. The trophy is meant to signify you've earned the patch. The display in the game is clearly counting the days as the day you start on. I believe the intent was to make it to day five, and trophy appearing = patch. I understand what you mean as though of completing it in terms of effort though (by day six it it would be five full days of time and effort), but I am pretty confident Larry made the trophy appearing deliberate to signify earning a patch. That seems pretty fundamental. They would have had a lot of angry kids otherwise. Yes the wording is a little weird, and a better wording would have been: "Do you have the drive, the stamina, the grit to endure this race to day 5 or more? If so, an on-screen racing trophy will pop up before your very eyes and you will be awarded a patch damn you."

The picture is outstanding. Kong never looked so good!

@rbairos determine which kernel is the problem (left or right). It can be fixed by swapping the early loads of X or Y. For example if the right hand kernel is the issue than try this: MAC RIGHT_KERNEL ; {graphics index}, {shading value}, {background} SLEEP 3 ; 3 lda #GRP1a_R{1} ; 2 sta GRP1 ; 3 VDELed @76 ;--------------------------------------- ; - 0a - 1a - 0b - 1b - 0c sta HMOVE ; 3 @03 +8 pixel lda #0 ; 2 undefined ; ldx #GRP0c_R{1} ; 2 ldx #{3} ; 2 CHANGED sta AUDV0 ; 3 @10 ldy #COL0c_R - {2} ; 2 lda #COL1a_R - {2} ; 2 sta COLUP1 ; 3 lda #GRP0a_R{1} ; 2 sta GRP0 ; 3 lda #COL0a_R - {2} ; 2 sta COLUP0 ; 3 lda #GRP1b_R{1} ; 2 sta GRP1 ; 3 VDELed ; lda #{3} ; 2 ; sta COLUBK ; 3 stx COLUBK ; 3 CHANGED ldx #GRP0c_R{1} ; 2 CHANGED lda #COL0b_R - {2} ; 2 sta COLUP0 ; 3 @42! end of GRP0a display lda #GRP0b_R{1} ; 2 sta GRP0 ; 3 @47! end of GRP1a display lda #COL1b_R - {2} ; 2 sta COLUP1 ; 3 @52 stx GRP0 ; 3 @55 sty COLUP0 ; 3 @58 <=@60 lda #$0 ; 2 sta COLUBK ; 3 @63 sta HMCLR ; 3 @66 ENDM

I've made a whole bunch of 8 bit unsigned integer division routines. I've posted them in my blog, and on Nesdev. https://atariage.com/forums/blogs/entry/10805-unsigned-integer-division-routines/ For divide by 3 this is what I came up with: ;Divide by 3 ;18 bytes, 30 cycles sta temp lsr adc #21 lsr adc temp ror lsr adc temp ror lsr adc temp ror lsr It's good for all values 0-255.

Thats good Thomas! I hadn't seen the actual kernel until now, and yes the solution is quite obvious. BTW, if the spare cycles are not used then 5 more bytes could be saved between the two kernels. Just set the stack pointer to 0 and use TSX, with STX COLUPF or STX COLUBK. With X=0, the sleeps can be eliminated to make use STA ZP,X taking 4 cycles. ; set SP to 0 instead of $FF ; enter the kernels with X=0 MAC LEFT_KERNEL ; {graphics index}, {shading value}, {background} ; SLEEP 2 ; 2 ; lda #GRP1a_L{1} ; 2 ; sta HMOVE ; 3 @73 -8 pixel lda #GRP1a_L{1} ; 2 @69 sta HMOVE,X ; 4 @73 -8 pixel sta GRP1 ; 3 VDELed ;--------------------------------------- ; 0a - 1a - 0b - 1b - 0c - lda #COL1a_L - {2} ; 2 sta COLUP1 ; 3 lda #0 ; 2 undefined sta AUDV0 ; 3 @10 ldx #GRP0c_L{1} ; 2 ldy #COL0c_L - {2} ; 2 lda #GRP0a_L{1} ; 2 sta GRP0 ; 3 lda #COL0a_L - {2} ; 2 sta COLUP0 ; 3 lda #GRP1b_L{1} ; 2 sta GRP1 ; 3 VDELed lda #{3} ; 2 sta COLUPF ; 3 lda #COL0b_L - {2} ; 2 sta COLUP0 ; 3 @39! end of GRP0a display lda #GRP0b_L{1} ; 2 sta GRP0 ; 3 @44! end of GRP1a display lda #COL1b_L - {2} ; 2 sta COLUP1 ; 3 @49 stx GRP0 ; 3 @52 sty COLUP0 ; 3 @55 <=@57 ; lda #0 ; 2 ; sta COLUPF ; 3 @60 tsx ; 2 X=0 stx COLUPF ; 3 @60 lda #$80 ; 2 ; sta HMP0 ; 3 ; sta HMP1 ; 3 @68 sta HMP0,X ; 4 sta HMP1,X ; 4 @70 ENDM MAC RIGHT_KERNEL ; {graphics index}, {shading value}, {background} ; SLEEP 3 ; 3 ; lda #GRP1a_R{1} ; 2 ; sta GRP1 ; 3 VDELed @76 lda #GRP1a_R{1} ; 2 @72 sta GRP1,X ; 4 @76 VDELed @76, X=0 and write takes 4 cycles not 3 ;--------------------------------------- ; - 0a - 1a - 0b - 1b - 0c sta HMOVE ; 3 @03 +8 pixel lda #0 ; 2 undefined ldx #GRP0c_R{1} ; 2 sta AUDV0 ; 3 @10 ldy #COL0c_R - {2} ; 2 lda #COL1a_R - {2} ; 2 sta COLUP1 ; 3 lda #GRP0a_R{1} ; 2 sta GRP0 ; 3 lda #COL0a_R - {2} ; 2 sta COLUP0 ; 3 lda #GRP1b_R{1} ; 2 sta GRP1 ; 3 VDELed lda #{3} ; 2 sta COLUBK ; 3 lda #COL0b_R - {2} ; 2 sta COLUP0 ; 3 @42! end of GRP0a display lda #GRP0b_R{1} ; 2 sta GRP0 ; 3 @47! end of GRP1a display lda #COL1b_R - {2} ; 2 sta COLUP1 ; 3 @52 stx GRP0 ; 3 @55 sty COLUP0 ; 3 @58 <=@60 ; lda #$0 ; 2 ; sta COLUBK ; 3 @63 tsx ; 2 X=0 stx COLUBK ; 3 @60 ; sta HMCLR ; 3 @66 sta HMCLR,X ; 4 @67 ENDM

Enabling VBLANK will turn the beam off. Enabling VSYNC is what causes it to return to the top.

Have you considered enabling VBLANK to hide the left and right side distortion? That's how we did it in the Parrot Kernel thread.

Original power supply.