[14 x 2600 + 1]

Nice to see that someone bought Jammed.

[Failed Robotron 2600 Experiment]

Excellent!

 

I must have completely missed that thread back then.

[The Way-Back Machine]

Very cool!

 

IMO this engine deserves to be turned into a finished game.

[Ghost in the Machine]

[Go Fish! Long Play]

There's some established way to make such an update without creating too much fuss, which is called "silent update".

Yup.

[Go Fish! Long Play]

I haven't checked, but does the player's fish change its brightness too?

[SpaceWar!]

I'll PM the code to you (must first check where I have it).

 

IIRC the approach is based a X and Y distance tables, which are then combined "somehow". The results looked convincing though there are heavily cheating with the math. Didn't fully understand it back then, but I was able to adapt the gravity effects for the PDP-1 version.

[SpaceWar!]

I have partially disassembled the original Atari 2600 Space War for converting it into that PDP-1 version. Interested in the code?

[Not quite dead yet]

Arson? That sucks. Any idea why?

 

BTW: Good luck at finding something!

[BTP2 demo]

Well, your code is performing (to start with):

 ldy phase1
 lda (amp1c),y
 lda (next0),y
 tay

I'm not quite clear on what you're intenting there, but I don't see how two consecutive LDA's are going to do anything useful.

I (finally ) got the code now.

 

There still might be one cycle to save, but then you had to carry Y from one line to the next one, making the code between more limited. Plus you would have to reverse the order of setting the two channels , probably that would hamper the sound. Not worth it.

[BTP2 demo]

I don't get it. Where's my error?

[BTP2 demo]

Can you show me how you'd do it without having to hold over A or Y? It seems to me that each phase value is only loaded once, and one of them gets stored, so unless a phase value is held over I see no way to eliminate a load.

Since I don't have access to your code, I have to post Distella code:

.loop:
sta	WSYNC		   ; 3
;---------------------------------------
ldy	$84			 ; 3
lda	($a4),y		 ; 5
lda	($8a),y		 ; 5
sta	$82			 ; 3	
tay					; 2
adc	($aa),y		 ; 5
sta	AUDV0		   ; 3
ldy	$86			 ; 3
lda	($9e),y		 ; 5
ldy	$88			 ; 3
adc	($98),y		 ; 5
sta	AUDV1		   ; 3
sta	WSYNC		   ; 3
;---------------------------------------
ldy	$82			 ; 3
lda	($92),y		 ; 5
lda	($8c),y		 ; 5
sta	$84			 ; 3	
tay					; 2
adc	($ac),y		 ; 5
sta	AUDV0		   ; 3
ldy	$86			 ; 3
lda	($a6),y		 ; 5
ldy	$88			 ; 3
adc	($a0),y		 ; 5
sta	AUDV1		   ; 3
sta	WSYNC		   ; 3
;---------------------------------------
ldy	$82			 ; 3
lda	($9a),y		 ; 5
ldy	$84			 ; 3
adc	($94),y		 ; 5
sta	AUDV0		   ; 3
lda	($8e),y		 ; 5
sta	$86			 ; 3	
tay					; 2
lda	($ae),y		 ; 5
ldy	$88			 ; 3
adc	($a8),y		 ; 5
sta	AUDV1		   ; 3
sta	WSYNC		   ; 3
;---------------------------------------
ldy	$82			 ; 3
lda	($a2),y		 ; 5
ldy	$84			 ; 3
adc	($9c),y		 ; 5
sta	AUDV0		   ; 3
lda	($90),y		 ; 5
sta	$88			 ; 3
tay					; 2
lda	($b0),y		 ; 5
ldy	$86			 ; 3
adc	($96),y		 ; 5
sta	AUDV1		   ; 3

You need to adapt your slightly, but as far as I can tell, that should be all.

[BTP2 demo]

I fully understand. Still you can save that cycle in each macro, making them all 45 cycles.

[BTP2 demo]

How so?

You are updating the index like this:

  lda	($8a),y	
 sta	$82		   

Then later:

  ldy	$82	
 lda	($92),y	   

If you move the first part directly before the 2nd one, you can replace ldy $82 with tay.

[BTP2 demo]

I just had a look at your (disassembled) code. It seems like you can update the index directly before using it and save 1 cycle.

[Juno Title]

Looks cool, even with banding.

 

BTW: And idea why TVs show this effect?

[BTP2 demo]

Ah, now it makes sense. I thought it had to do with music generation, but actually it's just optimizing code. That's something I understand.

[BTP2 demo]

Hm, why do you mix the values that way? Why not just a, b, c, d? And why the same ptrs for both voices in V1, but not in V0?

Uh, maybe because I oopsed? (now fixed above)

Ok, that answers my last question.

 

I understand the meaning of the pointers, but why not just a, b, c, d for all 4 voices?

[BTP2 demo]

• AUDV0 = ptr1d[i1] + ptr2c[i2]; AUDV1 = ptr3b[i3]+ptr4b[i4]; i1=ptr1s[i1];
  
• AUDV0 = ptr1a[i1] + ptr2d[i2]; AUDV1 = ptr3c[i3]+ptr4c[i4]; i2=ptr1s[i2];
  
• AUDV0 = ptr1b[i1] + ptr2a[i2]; AUDV1 = ptr3d[i3]+ptr4d[i4]; i3=ptr1s[i3];
  
• AUDV0 = ptr1c[i1] + ptr2b[i2]; AUDV1 = ptr3a[i3]+ptr4a[i4]; i4=ptr1s[i4];
  

Hm, why do you mix the values that way? Why not just a, b, c, d? And why the same ptrs for both voices in V1, but not in V0?

[Theresa Marie Schindler (Schiavo)]

I still don't get why this case is so important for you (and maybe should be for us).

[Juno Update]

For Leprechaun I ended up breaking the repositioning routine into three separate chunks. I can't recall offhand why three worked best.

Two or three chunks are useful, more usually have to much overhead for determining which chunk to select. Unless you have a table approach.

[Spit into the Wind!]

But maybe 256, 128 or even 64 bytes would be close enough?

Should work, maybe with some interpolation.

[Spit into the Wind!]

Thinking further, I think we do need 90 values unless we want to do some complicated math.

Yes, I think you are right. Calculationg a square root is probably too much. John's suggestion may help here.

 

Calculating square on the fly(!) will be also extremely hard, probably we have to cheat there too.

[Spit into the Wind!]

BTW: Since this is about spitting, air resistance becomes pretty important. I am not sure if a simple linear approach (like the one I usually use in my gravity/friction games) would look convincing and calculating squares won't be easy.

[Spit into the Wind!]

But I wonder if a one byte fraction would give enough precision to reasonably represent all angles and all possible magnitudes?

Angles yes, but for the magnitudes you will have to do some math (fixed point multiplications).