[Buy Me A Coffee!]

It's bootlicker.party

[Star Wars: The Last Jedi -- Addressing the Backlash]

I absolutely loved The Last Jedi. I really, really enjoyed it.

[The YouTube Subpocalypse for Small Channels]

I quit YouTube a year ago.

 

The endless chasing of subscribers and the resulting mediocre content made me hate the place.

 

I want to create a better video sharing platform...

[2018 has come]

Happy New Year!!

[Christmas 2017 - It's over]

Merry Christmas! I love reading your blog.

[Coming Back to My Home Town for Christmas]

Oh no, I flew 4000km, and then drove another 400km!

[7800 Not Doing So Good]

Hmmm... I think it may be possible to repair it!

[Half a screen, onward.]

Looks great!

[Guerrilla Game #5.3 -- The Final Puzzle Piece]

Yeah! I did notice that! You're totally right.

 

Thanks man!!

[The 7800 Being Technically Superior]

Yeah, you're right.

[Guerilla Game #5.1]

I would love to!

[Presents]

I don't even think SMS controllers are that good, are they?

[The 7800 Being Technically Superior]

Yeah I found this link from the wikipedia page:

https://sites.google.com/site/atari7800wiki/7800-compared-to-the-nes

It says all the same things as you - the 7800 is frequently caught up in spending much more time than the NES rendering the display.

 

There's also some issues with outputting the image due to the way the analogue video is clocked. Apparently there is potential for artifacting with the 7800.

 

The memory is also unified in the 7800. The article I linked argues this presents some disadvantages compared to the NES with it's dedicated video RAM.

 

Anyway, you're right, really. They're just radically different architectures.

[Guerrilla Game #4]

Still thinking out loud.

 

Spend a lot of time in my kernel counting lines, counting twice as fast for the Playfield, and half as fast for the Sprites.

 

FlipDraw doesn't require a line counter...

[Guerrilla Game #4]

Here is cd-w's version of a multi-coloured DoDraw:

   lda #SPRITEHEIGHT
   dcp SpriteEnd
   bcs DoDraw
   SLEEP 9
   lda #0
   beq EndDraw
DoDraw
   lda (SpriteColorPtr),Y
   sta COLUP0
   lda (SpriteDataPtr),Y
EndDraw
   sta GRP0

Here is a version I came up with, which I think takes less time, even though it forces you do load the player's colour:

   lda #SPRITEHEIGHT        ; 2  2
   dcp SpriteEnd            ; 5  7
   bcs DoDraw               ; 2  9 (3 10)
   lda #0                   ; 2 11
   .byte $2C                ; 4 15
DoDraw                      ;  (10)
   lda (SpriteDataPtr),Y    ; 5 15
   tax                      ; 2 17
   lda (SpriteColorPtr),Y   ; 5 22
   sta COLUP0               ; 3 25
   stx GRP0                 ; 3 28

Nope. It's longer. This one takes up 28 cycles whereas cd-w's takes 26.

 

I really am in the presence of masters.

[My teacher ate 2,600 lemons.]

Looks great!

[Eating]

Looks great!

[A real game.]

The game looks great!

 

Hope your Mum does okay!

[Fooling around with assembly]

Yo! I know we don't know each other, but I'm here to talk if you want to!

[Fooling around with assembly part 3]

I hope your Mum is okay

[Disassembly of Commando #2]

Thanks a lot! I'm really glad I made this blog post - it got someone to give me help!

 

I never thought of using the Stella Debugger! I haven't been making guesses, I've just been going through the kernel and trying to guess what each of the variables are for based on what the program is doing. I've found a variable which counts from 0-37, i've found the horizontal positioning routine for the Player1 graphics.

 

I've been trying to track down where each of the variables that set the graphics in the kernel come from. There seems to be an elaborate set of code that does this:

    lda    ram_97,X              ; 4	- Make A = ram_97,X again	<- Here is ram_97 again
    and    #$07                  ; 2	- Mask off #00000111 again
    sta    ram_D7                ; 3	- Then store in ram_D7 (then next variable on from D6)
    asl                          ; 2	- Arithmetic shift left in A(multiply by 2)
    adc    ram_D7                ; 3	- Then add another ram_D7 in A (multiply by 3)
    adc    #$02                  ; 2	- Then add #2
    tay                          ; 2	- Transfer A to Y

then this subroutine:

    lda    ram_97,X              ; 4	- Make A = ram_97,X

    lsr                          ; 2	- Divide by 2
    lsr                          ; 2	- Divide by 4
    lsr                          ; 2	- Divide by 8
    lsr                          ; 2	- Divide by 16
    lsr                          ; 2	- Divide by 32
    eor    #$FF                  ; 2	- Flip all the bits
    clc                          ; 2	- Clear carry
    adc    #$20                  ; 2	- Add 32 to A
    rts                          ; 6

    sec                          ; 2	- Set Carry
    sbc    #$17                  ; 2	- Subtract 23+1
    sta    ram_D7                ; 3	- Store in ram_D7
    lda    (ram_DB),Y            ; 5	- A = (ram_DB),Y - where Y was the result of (3*A)+2		<-here is ram_DB again
    sec                          ; 2	- Set Carry
    sbc    ram_D7                ; 3	- Subtract (ram_D7)+1
    sta    ram_A1,X              ; 4	- Store in ram_A1,X
    iny                          ; 2	- INC Y

Then in the kernel, ram_A1,X is transferred into ram_DD, which is then used to set GRP1.

Very confusing... I am trying to figure out what this is doing...

[Intellivision Colors - Food Coloring Style]

This is great! I didn't realise the Intellivision only that 16 colours!

 

Kinda makes me appreciate the 2600, with its 128...

 

But anyway this makes me want to play the Intellivision!