New game, I Ran (endless runner)

[New game, I Ran (endless runner)]

Greate improvement compared to the Doremi version. I really love the jump sound effect.

[Local Hero!]

I tried your game and the idea is really cool, but needs some debuging. I tried clone and I was pretty sure what will be the problems.  Only the leftmost missile does damage and the clones are going out through the wall.

I think this is a disadvantege, because I get damage for sure, even if it's smaller than normal because one of the clones will be shot for sure.  

[Homebrew Development Platform]

5 hours ago, Mr SQL said:

Many amazing games can be developed with the kit you posted - 4K is alot of fun in BASIC or Assembly

Mostly I use up 32K of ROM because the music I do takes a lot of space.  But my Fortari2600 plans will support only 4-32K carts (with the option of SARA), 64K is really a bit overdoing it.

The biggest advantage of 4K games is you can't create buggy jumps while bankswitching.

[Homebrew Development Platform]

13 hours ago, vcsrocks said:

Thanks.  That already starts narrowing it down 🙂

 

When you say FE (64K) do you mean Activision FE?  Do you use F4 also with SARA?

 

Cheers.

Sorry, I wrote it wrong, it's called EF bankswitching.  And with the superchip RAM added, it should be called EFSC.
The other, F4, is the common 32K Atari bankswitching method by Atari Inc., with no SARA added.

[Homebrew Development Platform]

46 minutes ago, vcsrocks said:

Which bankswitching do you normally use?

I used two of them, the F4 (32K Atari bankswitching) and the FE (64K) with SARA support. I tried to narrow things so Sebastian does not need to create too many type of boards.

[Homebrew Development Platform]

I have Sebastian Kotek for designing the boards (he's mostly familiar with the 5200 and 7800) and Jerzy (Retronics, mostly Atari 8bit computer and PC line) for publishing the games. they are both from Poland. The real problem is that Jerzy does not want to use used plastic shells for games, the others are mostly easy to be produced. My last information is that he ordered the mold from China, but the production was held because of the COVID-19 story.

[Abyss of Chernobyl (Atari 2600 homebrew)]

Here is the new hw recording: 

 

[Abyss of Chernobyl (Atari 2600 homebrew)]

Added manual and latest bins.

Abyss0.81PAL.bas.bin

Abyss0.81NTSC.bas.bin

[Abyss of Chernobyl (Atari 2600 homebrew)]

Just finished the overlay.

[Abyss of Chernobyl (Atari 2600 homebrew)]

Box art is ready, manual and overlay is yet to be done.

[Abyss of Chernobyl (Atari 2600 homebrew)]

10 hours ago, Thomas Jentzsch said:

Well, Al has been doing his "mass production" based on used carts for years.  

This was what I told him as well.

[Abyss of Chernobyl (Atari 2600 homebrew)]

On 2/16/2020 at 7:11 AM, EdgeOfPortal said:

Probably to preserve original 2600 cartridges if I had to guess. Doesn’t want to use another game.

Nope. He thinks that it's not perfect for mass production (I found someone with 200 pieces of Combat in Germany, he could help, the earliest cartridges were the best in quality). So he went to chinese possiblities, from US, it would be too expensive.

[Abyss of Chernobyl (Atari 2600 homebrew)]

 

 

You can handle and blow up the reactor, use boron to kill fire, go underwater and turn the gears, kill the animals in the surroundings and get rid of the graphite on the roof, all in one game.
Gonna do the manual soon. If you can help with debugging, I will be very thankful.

Abyss0.79NTSC.bas.bin

[Abyss of Chernobyl (Atari 2600 homebrew)]

6 hours ago, Thomas Jentzsch said:

There are some places which you can ask to do the release for you. E.g. AtariAge, Packrat Video Games, Good Deal Games...

 

They all have their own criteria which games they release and which not. So do not give up if someone says no to your request.

I have Jerzy (Retronics) from Poland to help, but everything happens so slow, just because, you can't get new shells for the cartridges here easily and he don't want to use used ones.

[Abyss of Chernobyl (Atari 2600 homebrew)]

 

Now the speed of water turbines and the performance of the reactor changes the temperature, which causes the water to boil, and that will fasten the incrasing performance, which, at 30 000, detonates the reactor. Over 6 000, you can't shut down the reactor and the reactor with the usual way. TODO: AZ-5N

[Abyss of Chernobyl (Atari 2600 homebrew)]

On 2/13/2020 at 1:11 AM, EdgeOfPortal said:

This is really interesting. Always love a Chernobyl based game. Will it be getting a physical release?

I have 8 games already waiting physicial release, unfortunately, I don't have the money to do it myself.

[Abyss of Chernobyl (Atari 2600 homebrew)]

 

What you can do right now: -Turn the reactor of and reach the bottom of performance (30 MW) or make it reach the top of performance, depending on the number of rods -Turn on stabilizer of water flow speed or let it reach top speed. -Make rods go up or down. TODO: Add temperature change and add bubbles to hot water.

[Fixing 6sprite colored kernel delay?]

7 minutes ago, Nukey Shay said:

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

 

 

Okay, but this is way too space wasting and fixes the height to 8. t 

[Fixing 6sprite colored kernel delay?]

1 minute ago, Nukey Shay said:

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.

There are not enough cycles to load sprite variable, store in temp array and then save it one point.

[Fixing 6sprite colored kernel delay?]

On 1/26/2020 at 10:07 AM, Nukey Shay said:

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?

If I rewrite it to reuse the Y, I have to drop the cycle loading the ColorPointer (which loads the shading) and adding the base color to it. And that's something I don't want to do.
The problem is, that I don't have much cycles to change, there was only 2 for placing with nop or +256 (.w) so I don't have much if I want to keep it universal, so you can load everything into pointers and enter this loop, so this can became a score, indicator, healthbar, inventory, single picture, etc.

I also tried to change the position of HMOVE, HMP0 and HMP1, also tried with VDELs (0,0), (0,1), (1,0), (1,1), if I can do something, but it was always really off.

The only solution I found was using some "magic tricks" (fixing the lost bit with ball and m0, then overlap 2 missiles with the pf) I read about in bB's title kernel and using them with a 2line kernel.

[Abyss of Chernobyl (Atari 2600 homebrew)]

First look at the reactior level. And no, you won't have to use any controllers, just the switches on the console.

[Fixing 6sprite colored kernel delay?]

Okay, it seems like the only way to proper do this is like in the 48p kernel in title screen kernel, you will lose the 0 bit in every case in the first sprite because you have to erase that bit first with the ball.

[Fixing 6sprite colored kernel delay?]

It seems like it just makes it corrupted at other places. Sometimes I feel like TIA only handles cycles at his own will, and saving to a variable costs more, while loading costs nothing.

[Fixing 6sprite colored kernel delay?]

8 hours ago, KK/Altair said:

This trick is VERY useful on the VCS to get 1-cycle NOPs.

Seems like useful. Hope I can get it somehow work, I tried many variations this morning, but eeeeeeeeh.

[Fixing 6sprite colored kernel delay?]

Hi guys, I made a six-sprite kernel with 6 pointers and added a pointer for changing the luma of the color.
 

	dim Score1IconPointer = c
	dim Score2IconPointer = e
	dim Score3IconPointer = g
	dim Score4IconPointer = i
	dim Score5IconPointer = k
	dim Score6IconPointer = m
	dim ColorPointer = o
	dim ScoreColor= q


	ScoreColor= $14
	asm
title_eat_overscan2
	clc
	lda INTIM
	bmi title_eat_overscan2

title_do_vertical_sync2
	lda #2
	sta WSYNC ;one line with VSYNC
	sta VSYNC ;enable VSYNC
	sta WSYNC ;one line with VSYNC
	sta WSYNC ;one line with VSYNC
	lda #0
	sta WSYNC ;one line with VSYNC
	sta VSYNC ;turn off VSYNC

        ;lda #42+128
	ifnconst vblank_time
 	lda #42+128
 	else
 	lda #vblank_time+128
 	endif

	sta TIM64T
title_vblank_loop2
	lda INTIM
	bmi title_vblank_loop2
	lda #0
	sta WSYNC
	sta VBLANK
	sta ENAM0
	sta ENAM1
	sta ENABL
	lda #230
        	sta TIM64T

SelectDone
	


   	LDA	#<Lock
   	STA	Score1IconPointer
   	LDA	#>Lock
   	STA	Score1IconPointer+1

   	LDA	#<Term
   	STA	Score2IconPointer
   	LDA	#>Term
   	STA	Score2IconPointer+1

   	LDA	#<Vent
   	STA	Score3IconPointer
   	LDA	#>Vent
   	STA	Score3IconPointer+1

   	LDA	#<UP
   	STA	Score4IconPointer
   	LDA	#>UP
   	STA	Score4IconPointer+1


   	LDA	#<DOWN
   	STA	Score5IconPointer
   	LDA	#>DOWN
   	STA	Score5IconPointer+1

   	LDA	#<AZ5
   	STA	Score6IconPointer
   	LDA	#>AZ5
   	STA	Score6IconPointer+1

   	LDA	#<Colors
   	STA	ColorPointer
   	LDA	#>Colors
   	STA	ColorPointer+1

 	
	LDA 	#$03			; 2 
	STA 	NUSIZ0			; 3
	STA 	NUSIZ1			; 3
	STA 	HMCLR
	sta 	WSYNC			; 3
         	tsx				; 2
	stx 	temp3			; 3

	sleep 	25
         
	LDY 	#7			; 2
	STY	VDELP0			; 3
	STY 	VDELP1			; 3
	STA 	RESP0			; 3
	
	STA 	RESP1			; 3
	lda 	#$60			; 2
	sta 	HMP0			; 3
	lda	#$70			; 2
	sta 	HMP1			; 3
	sleep 	4
	STA 	HMOVE 			; 3


	
	
	


DisplayLoop

 	lda 	(ColorPointer),y		; 5
	adc 	ScoreColor		; 3
	sta 	COLUP0			; 3
	sta 	COLUP1			; 3
	lax	(Score1IconPointer),y 	; 5
	lda 	(Score2IconPointer),y 	; 5
	stx 	GRP0 			; 3
	
	sta 	GRP1 			; 3

	
	lda 	(Score3IconPointer),y	; 5
	
	
	sta 	GRP0 			; 3
	lax 	(Score5IconPointer),y 	; 5
	txs				; 2
	lax 	(Score4IconPointer),y	; 5
	
	lda 	(Score6IconPointer),y 	; 5
	
	
	stx 	GRP1 			; 3
	tsx				; 2
	
	stx 	GRP0
	sta	GRP1 			; 3
	stx 	GRP0
			
	
	dey				; 3
	nop
	bpl	DisplayLoop 		; 2

	iny 
 	sty 	GRP0
 	sty 	GRP1 
 	sty 	NUSIZ0 
 	sty 	NUSIZ1 
 	sty 	COLUP0
	sty	COLUP1


	ldx 	temp3
	txs

 	sta 	WSYNC  


PFWAIT2
        lda INTIM 
        bne PFWAIT2

end


	goto OVERSCAN2

	asm
	
Lock
	.byte	#%00111100
	.byte	#%01011010
	.byte	#%01011010
	.byte	#%01000010
	.byte	#%01111110
	.byte	#%00100100
	.byte	#%00100100
	.byte	#%00011000

Term
	.byte	#%01000000
	.byte	#%10100011
	.byte	#%01000100 
	.byte	#%11100100
	.byte	#%11100100
	.byte	#%10101011
	.byte	#%10100000
	.byte	#%01000000

Vent
	.byte	#%00000100
	.byte	#%00001100
	.byte	#%11111100
	.byte	#%01100100
	.byte	#%00100110
	.byte	#%00111111
	.byte	#%00110000
	.byte	#%00100000

DOWN
	.byte	#%00111100
	.byte	#%01000010
	.byte	#%10011001
	.byte	#%00111100
	.byte	#%01111110
	.byte	#%00011000
	.byte	#%00011000
	.byte	#%00011000

UP
	.byte	#%00111100
	.byte	#%01000010
	.byte	#%10011001
	.byte	#%00011000
	.byte	#%00011000
	.byte	#%01111110
	.byte	#%00111100
	.byte	#%00011000

AZ5
	.byte	#%00000110
	.byte	#%00000001
	.byte	#%01110111
	.byte	#%00000100
	.byte	#%10111111
	.byte	#%11101000
	.byte	#%10100100
	.byte	#%01011100

Nothing
	.byte	#%00000000
	.byte	#%00000000
	.byte	#%00000000
	.byte	#%00000000
	.byte	#%00000000
	.byte	#%00000000
	.byte	#%00000000
	.byte	#%00000000


Colors
	 .byte #$02
	 .byte #$04
	 .byte #$06
	 .byte #$08
	 .byte #$08
	 .byte #$06
	 .byte #$04
	 .byte #$02

	
ScoreColors
	.byte #$02
	.byte #$04
	.byte #$06
	.byte #$08
	.byte #$08
	.byte #$06
	.byte #$04
	.byte #$02




.OVERSCAN2
	;lda #35+128 

 	ifnconst overscan_time
 	lda #35+128
 	else
 	lda #overscan_time+128-3-1
 	endif


	sta TIM64T
	lda #%11000010
	sta WSYNC
	sta VBLANK
	jmp title_eat_overscan2
end

I don't want to remove the pointers because I want to use it for universal puproses (six digit score, picture, inventory, status screen, etc.) and make it a little colored. I even tried it without the colors, where I can fine tune with "nop"-s, but I couldn't get any better results.

Typically, these are the two best version I can get by changing the sleep macros and the position of the single "nop" in the loop. One version is where the last bit of sprite one becomes the third sprite's last bit (it is saved too soon) or the first bit of sprite 6 becomes the first bit of sprite 4 (sta happens too late).

Can you help me a little? It's based on the method how bB kernel creates the score.

testshit.bas.bin