[The Story of Stay Frosty 2, Part 5]

Do you know a good way to get the assembler to label the ZProutineROM routine once

its loaded into RAM? For example, if you had lda #%10011001 somewhere in ZPRoutineRAM,

and wanted to change it on the fly to lda #%11111111 could you:

 

lda #%11111111

sta MySpecialRAMLabel+1 ;(the operand portion of that load)

 

I think this could be figured out manually, but while writing, it would be great if a labelled location could be figured by the assembler.

[DPC+ ARM Development]

Thanks.. What's ARM assembly?

[DPC+ ARM Development]

Looking into this again.. I've been learning Unix and Linux in my job and I have Ubuntu on VirtualBox here at home so that will be a little easier. But the C- its still a requirement? How much would I have to learn? Is there a resource you recommend?

[Main Menu]

I'm surprised that while loading the graphics addresses into RAM, you are not able to set up a subroutine. You have a separate routine written for SpeedGraphic, FireballGraphic, CatchGraphic, etc even though they are nearly identical other than the starting address. I'm about to do the same thing so I was curious if there was a way to call a subroutine.

[CollectMini source code]

Ah... so .wx is forcing a 16 bit address, not a 16 bit word.. And in this case, the page will be zero, your just specifying it to waste time.. Thanks!

[CollectMini source code]

Good Morning!

 

sta.wx HMP0,X ; 5 19 -

 

 

(.wx)- Is this storing a 16 bit word into an 8 bit register? Is this indexing the accumulator?

[DPC+ ARM Development]

Nah- I'm not familiar with C. I'd like to be, though. Same for Linux.

 

I saw Draconian on YouTube and was blown away so I thought I'd look into the DPC+.

 

But given what you've told me, I should probably complete at least one functioning 2K game first, before looking into it again. That will give you more time to finish as well

 

Thanks!

[DPC+ ARM Development]

Hmm I'm tempted to try this but it may get me off track. Do you think this helps the novice Stella programmer by adding capability and flexibility? Or do the added complications just make it too difficult?

[step 7 - draw the playfield]

Interesting- so assume this is to avoid having to cross a page boundary which can cause timing issues- right?

[step 10 - "Random Numbers"]

Ahh.. I think I only had (have, really) a grasp of the two bit tap (The Wikipedia example). So it looks like from the description you gave, once the LSFR is seeded, any seed will produce all sorts of cycle lengths all chained together one after another. Correct?

[step 10 - "Random Numbers"]

Hi!

 

Two things.. I'm amazed that the LSFR will always go through 255 or 65,535 cycles without repeating. I would think that at least some seed values would cause that to change...

 

Secondly a question. What is the reason the CollectBox routine switches to decimal mode? Does it have to do with displaying the score? I could see masking the left or right nibble to get the offset for 10s or 1s digit graphics. Is that it?

[step 9 - Game Variations]

Ah.. OK.. Does it make the game variation roll over to zero? 00000100 would become 00000000?

[Step 3 - Score & Timer display]

After compiling, I see messages- bytes until the end of the cartridge and bytes until HumanGFX. What's the relevance of bytes until the graphics?

[step 9 - Game Variations]

Hi!

 

This section was pretty easy to follow, though I did have one minor question; Why is the first mask necessary? I would think the game variation would already be accurate and could just be stored in 'Variation'.

[step 8 - Select and Reset support]

Oh OK.. So that timer number will stay relatively stable on the screen. I imagined it just rolling through at 60 cycles. Makes sense. And the S flag is just another name for the N flag- didn't know that. I enjoyed going to the magazine site.. I used to buy Compute's Gazette all the time in high school and type the Commodore 64 programs in.

[step 8 - Select and Reset support]

Interesting. I'm surprised that the Stella debugger doesn't just display timer values by default.

 

I can get why D7 could be linked with plus and minus, but how D6 translates to an overflow is beyond me. Sounds like something that just needs to be memorized, but not understood!

[step 8 - Select and Reset support]

Hi.. Is there any reason that D6 and D7 are easy to test with the BIT command? Or are they all easy, but were just happen to be looking for 6 & 7 here?

 

Also, are you grouping particular routines in either overscan or vertical blank? In other words, is there an advantage to placing certain logic in either one or the other, or are you maybe following some convention?

 

Thanks!

[step 7 - draw the playfield]

Thanks.. I've been playing with the code and adding to it (I hope that's appropriate) and I keep seeing that "bytes before DigitGfx" getting smaller and smaller each time I compile it.

[step 7 - draw the playfield]

Hello..

 

I have a general question about this game.. Why is it 2K? Are there more advantages to that other than using less file space? Also, to make this a 4K game, do you simply need to change ORG $F800 to ORG $F000 or is there more to it?

[step 6 - Spec Change]

This is interesting:

sta COLUP0-1,x ; and set it

 

It never occurred to me that you could cycle through registers like that but it makes sense since they are simply memory locations that happen to be next to each other, I assume..

 

And here, since these are performed consecutively, we're sharing the carry bit among each of the PF fields- right?

 

DecrementTimer:

lsr TimerPF+5 ; PF2 right side, reversed bits so shift right

rol TimerPF+4 ; PF1 right side, normal bits so shift left

ror TimerPF+3 ; PF0 right side, reversed bits so shift right

lda TimerPF+3 ; only upper nybble used, so we need to put bit 3 into C

lsr

lsr

lsr

lsr

ror TimerPF+2 ; PF2 left side, reversed bits so shift right

rol TimerPF+1 ; PF1 left side, normal bits so shift left

ror TimerPF ; PF0 left side, reversed bits so shift right rts

 

And, eventually, zeros will be fed into the fields one by one due to the initial LSR- correct?:

[Time for another scan]

129 broadcast channels? I felt good about receiving 18 or so here in Richmond. I can't believe there are so many..

[Step 5 - automate Vertical Delay]

OK Thanks! Got it.

[Step 5 - automate Vertical Delay]

Wait.. maybe 19 is close enough since TIA will put the position into the center of the 15 cycle course position anyway?. Is that right?

[Step 5 - automate Vertical Delay]

I had no idea EOR would do that. Unbelievable. I went through each possible move on page 41 and it checks out! I've known for a while what EOR does, but never could figure out what use it could be for anything...

 

And I forgot about the Horizontal Blank... So I assume we are using up 22 cycles in the subsequent code then, not 19 until the RESP0- right?

[Step 5 - automate Vertical Delay]

I was typing this up before your later posts...

 

Thanks for the debugger guidance- I knew pretty much none of that. I don't think I ever even noticed the left window.. And its especially nice to see the labels in the assembly code on the right instead of the random labels it would have generated itself. And the break is cool..

So, if I have this straight,

This little loop immediately follows a WSYNC which can only place a player at 15 color clock increments from the WSYNC. Even though we are outside of the kernal, there is no harm in doing this now.

The divide loop is making those 15 color clock jumps.

EOR is switching the right three bits- 0's to ones, and 1s to zeros... I'm still not sure why...Are we converting this remainder to two's compliment negative? I know that TIA's direction of the x-axis is backwards.

Then they are moved into the correct position HMP0 for an eventual HMOVE to happen later.

But..
By the time we RESPO, isn't our course position timing off? Didn't we use like 19 more cycles to get to it?