My 1st Homebrew - Mr. Yo-Yo, WIP

[DaveM]

My original first post starts below this link.  If you're looking for the most-recent release of the game, you'll find it here:

 

Original Post:

 

Hi everyone.  I'm starting work on my first homebrew, and running into some issues, so I'm hoping someone here could assist.  I did a number of hacks quite a few years ago, I think "Fat Albert" is the most well-known, but I got away from doing those and I'm just now diving back in to try to learn how to make my own game.  I've programmed VB/VBA/.Net for quite a few years, and have done some games in those languages, but I've never learned any sort of assembly language.  I purchased Steven Hugg's book, and got about 2/3 of the way through it before my brain fried.  I thought then I'd get a start on writing the game using what I learned up to that point, then get back to the book later on.

 

So a little about my game idea, then I'll describe the problems I'm having.  I had an idea to create a game where the button controlled the movement, and the joystick controlled the firing mechanism, basically the opposite of what most Atari games are.  So the idea is that you control a Yo-Yo.  You push the button, and the yo-yo moves down.  Release the button, and he zips back up his string.  Push the joystick right and left, and he'll fire his laser gun right and left.  The object will be to descend all the way to the bottom of the screen, pick up an object, and bring it to the top of the screen.  Repeat this a certain number of times to clear the level.  Meanwhile, enemies will enter from the sides, moving horizontally (similar to Turmoil).  Some enemies will only hurt you if they hit the yo-yo itself, while others will cut your string if they pass above you, requiring you to zip back up to either blast them or get above them before they reach your string.  Occasionally bonus objects may fly in from the sides that you can collect for points or power-ups.  That's the basics of it.  Sort of a cross between Turmoil and Freeway.

 

So far, I'm able to get Mr. Yo-Yo to move down and up when you press/release the button, and I got his animation to work so he spins clockwise on the way down, and counter-clockwise on the way up.  He continues to spin if held down at the bottom of his string, and stops spinning when he reaches the top.  I also got the string to draw above the yo-yo.  All of that is the Player 0 object.  All that works fine.

 

The problem comes in when I try to add anything else.  I tried adding the playfield, and the screen started flipping.  So early in the design of the game, and I'm already blowing way past the 262 scanlines.  I've been staring at the code for hours now, trying to figure out ways to condense things, and I'm just not experienced enough yet to figure that out.  I'm hoping there's a more experienced programmer here who would take a look at my code (attached), and see where I can save a few scanlines here and there, or maybe see where I'm doing something totally wrong that could be done much more efficiently.  I'm not looking for someone to write the game for me, but I've been banging my head against the wall long enough and need some help to push me in the right direction.

 

And when and if I get the game finished, I'll be more than happy to share it with everyone here.

 

Thanks!

mr_yo_yo 0.2.1.a

Edited May 10, 2021 by DaveM

[DaveM]

Update - So I stepped away from the project for a few days to let my mind clear, then went back and looked at my notes and re-read parts of the book, and realized that my kernel was, well, not that good.  Far too many cycles.  So I took a shot at re-writing the kernel and changing a few other parts of the code.  I had some calculations in there which vertically flipped the player 0 bitmap, but that was taking up far too many cycles.  So I removed that in favor of adding extra bitmaps for the animation.  To make room for that, I removed one of my arrays, and moved that data inside my playfield graphics array, so parts of the playfield now serve multiple purposes.  Along the way, I realized that the PF0 and PF1 registers will always be the same, so no need for extra data for both, and no need to load two values - I just load the one value and write it out twice.  I re-worked some of my other calculations, trying to minimize them the best I could.  I almost made it to the proper number of scanlines, but not quite.  However, I now can get the Yo-Yo and the playfield on screen, but only by displaying them on alternating frames.  This causes significant flicker on the 8-bit workshop tool, but doesn't look too bad when I run the compiled ROM through Stella.

 

I've attached the code and ROM of what I have so far.  Any suggestions on anything further I can do to save some cycles inside my kernel so I won't have to alternate frames?

 

Thanks in advance!

mr_yo_yo 0.3.a _mr_yo_yo.0.3.bin

[+ZeroPage Homebrew]

Love the possibilities of what you've started here, great animation on the Yo-Yo and the line count is stable at 262. ? The flicker of the character and the playfield is a bit much but I'm sure you'll figure out how to draw everything on every frame instead of every alternating second frame soon enough.

 

Can't wait to see how the game progresses once you introduce enemies and powerups! You could also introduce the possibility if the yo-yo stays at the bottom too long (avoiding enemies) it slows down and then falls off the string if you wait, just like a yo-yo would.

 

- James

[DaveM]

Thanks for the feedback James!  I'm hoping as I learn more about stuff that I'll figure out a way to avoid that flicker.  I'm sure it's possible, but I just don't know how to do it yet.  I'm still pretty early on in my learning process.

 

There will be some sort of timing mechanism added in there, forcing the player to keep moving.  I'm toying with a few different ideas, but not sure which way I want to go yet.  The one thing about staying down at the bottom though, is that you have your string going all the way to the top of the screen.  There will be enemies that can cut your string, costing you a life.  So perhaps sitting down on the bottom for a short time could trigger one of those enemies in the top lane, forcing you to move all the way back up.

 

I have a lot of ideas for this game written down, it's just a matter of how many I can cram in there.  I haven't gotten to the chapter on Bank Switching yet, so I'm sure that will help determine some of what I can and can't fit in there.

[bluswimmer]

Looking at the code, I've noticed that drawing the yoyo alone takes up almost 50 cycles. Given that the system has 76 cycles per scanline to work with, that certainly won't do. It's more than possible to draw a sprite in only 18 cycles. Here's the code for drawing a sprite that I used in Cannonhead Clash (which in turn was taken from Spiceware's Collect Tutorial). Note that y is treated as the line counter in this program, rather than x like it is in your game currently.

	lda #PLAYER_HEIGHT - 1	;2
	dcp PlayerY		;7
	bcs DoDrawPlayer	;9/10
	lda #0			;11
	.byte $2C		;15
DoDrawPlayer0:
	lda (GfxPointer),y	;15
	sta GRP0		;18

The algorithm works as follows:

• The height of the sprite minus one is loaded into the accumulator
• dcp is a special instruction that isn't usually documented. Essentially, it operates like DEC and CMP, combined into one instruction. Here it is used to determine whether or not the sprite is ready to draw yet. Here, it compares PlayerY with the height of the sprite, and then decreases PlayerY.
• If it is not ready to draw, load 0 into the accumulator. The ".byte $2C" is a trick that skips the next instruction. Essentially, the processor interprets the $2C as the beginning of an absolute BIT instruction. Since the lda instruction is two bytes in length, it is treated as part of the BIT instruction.
• If it is ready to draw, the processor utilizes indirection to find what to draw. Indirection allows the processor to find values via a memory address that is stored in RAM. The correct memory address when drawing a particular sprite is the memory address of that sprite, PLUS the PlayerY value.

Hopefully that explanation made some sense. Note that you'll need to change the PlayerY back to the way it was before the Kernel. If you have questions, feel free to ask.

[DaveM]

Thanks!  That's some good info.  I think I understand what you're doing.  I'll try implementing it the next time I work on the game, and I'll let you know how it goes.

[DaveM]

Hmmm... Can't get it to work.  I got a feeling I missed something and I'm doing something stupid.  I save the Player's Y position to the stack at the start of the kernel, and restore it at the end, and I thought I had everything set up like you had it (I even re-read the chapter on indirect addressing, which I admit, flew way over my head the first time I read it, which is why I wasn't using it originally).  But instead of the yoyo going down and up, I get this yellow mess doing up and down.  At least the flicker is gone though.  So it does cut the cycle count significantly.

 

So I'm sure I messed something up.  Once that's corrected, then there's the question about how to add the yoyo string.  It was also part of the Player0 object, and it should extend from the top of the yoyo (Player's Y position + Player height) up to the top of the playfield (#PStVPos).  Unsure how that would fit in with this setup.

mr_yo_yo 0.3.1.a

[bluswimmer]

Well, there's a few things to note here.

 

At the beginning of your program, the Pointer setup looks like this....

lda #<YoYoGfx
sta GfxPointer
lda #>YoYoGfx
sta GfxPointer+1  

When it should look more like this....

lda #<(YoYoGfx)
sta GfxPointer
lda #>(YoYoGfx)
sta GfxPointer+1  

The parentheses are actually pretty important here, since it tells the compiler that you're loading the memory address of YoYoGfx, rather than the value located at YoYoGfx.

 

Also, lda (GfxPointer),x is NOT a valid instruction. Confusingly enough, you HAVE to use lda (GfxPointer),y.

 

As for the string, you could probably use one of the missiles to display it, and turn off the missile once the yoyo starts to get drawn.

[+splendidnut]

12 hours ago, bluswimmer said:

Well, there's a few things to note here.

 

At the beginning of your program, the Pointer setup looks like this....

lda #<YoYoGfx
sta GfxPointer
lda #>YoYoGfx
sta GfxPointer+1  

When it should look more like this....

lda #<(YoYoGfx)
sta GfxPointer
lda #>(YoYoGfx)
sta GfxPointer+1  

The parentheses are actually pretty important here, since it tells the compiler that you're loading the memory address of YoYoGfx, rather than the value located at YoYoGfx.

 

 

That is not quite correct.  The parenthesis make no difference due to the use of the # symbol which triggers immediate mode.

 

LDA #<YoYoGfx  will load the low address byte of YoYoGfx into the accumulator

LDA #>YoYoGfx  will load the high address byte of YoYoGfx into the accumulator

 

[bluswimmer]

9 hours ago, splendidnut said:

 

That is not quite correct.  The parenthesis make no difference due to the use of the # symbol which triggers immediate mode.

 

LDA #<YoYoGfx  will load the low address byte of YoYoGfx into the accumulator

LDA #>YoYoGfx  will load the high address byte of YoYoGfx into the accumulator

 

Ah, my mistake. Thanks for the correction.

[DaveM]

OK, getting closer, I think.  It's still moving in the opposite direction it should, and it's a garbled yellow mess, but at least it's now aligned properly.  I changed the x to y in that one line. I have a feeling though that I'm not loading in the proper value into Y, but honestly, I just really don't know.

 

I definitely want to learn this, and I'm determined to complete this game, but for some reason, I just can't wrap my head around this part of it at this point.

mr_yo_yo 0.3.1.a

[bluswimmer]

1 hour ago, DaveM said:

OK, getting closer, I think.  It's still moving in the opposite direction it should, and it's a garbled yellow mess, but at least it's now aligned properly.  I changed the x to y in that one line. I have a feeling though that I'm not loading in the proper value into Y, but honestly, I just really don't know. 

 

I definitely want to learn this, and I'm determined to complete this game, but for some reason, I just can't wrap my head around this part of it at this point. 

mr_yo_yo 0.3.1.a 11.64 kB · 1 download

I am so sorry, I completely forgot one detail!

 

the lda should look like
lda #<(YoYoGfx - ARENA_HEIGHT)
lda #>(YoYoGfx - ARENA_HEIGHT)

 

I honestly can't believe I didn't catch this one sooner. ARENA_HEIGHT how tall the play area is.

[DaveM]

Still not quite working.  I can see that it's bringing in parts of the yo-yo bitmap, but it's still missing something.

mr_yo_yo 0.3.1.a

[bluswimmer]

Well, there's a few things to keep in mind. Currently, you're only changing the address of GfxPointer at the start of the game, when it should be done once every frame. Additionally, you aren't adding the Player's Y value to the GfxPointer. Also, I'd probably swap the purposes of the X and Y registers in your kernel- Y is supposed to be the line counter in the draw routine, but it's currently serving as the Playfield Pointer.

[DaveM]

4 hours ago, bluswimmer said:

Well, there's a few things to keep in mind. Currently, you're only changing the address of GfxPointer at the start of the game, when it should be done once every frame. Additionally, you aren't adding the Player's Y value to the GfxPointer. Also, I'd probably swap the purposes of the X and Y registers in your kernel- Y is supposed to be the line counter in the draw routine, but it's currently serving as the Playfield Pointer.

OK, I've swapped X and Y like you suggested.  I've moved the GfxPointer address change to the start of each frame.  So when you say I should add the Y value, would it look like this?

 

        lda #<(YoYoGfx - ArenaHt + PVrtPos) 
        sta GfxPointer
        lda #>(YoYoGfx - ArenaHt + PVrtPos) 
        sta GfxPointer+1

 

I think one of the issues I'm having is that none of the samples in the book I'm working with refresh that at the start of each frame.  They all have it set right at the start, and there's usually no animation involved.  So not only am I just a couple weeks' into learning it, but it's quite tough to find a good example to work off of.  

 

I really do appreciate your help and patience on this! 

mr_yo_yo 0.3.1.a

[bluswimmer]

No, not quite- you're technically adding the memory address of PVrtPos instead of its actual value. To properly add them together, you'll need to do something like this:

        lda #<(YoYoGfx - ArenaHt)
        clc
        adc PVrtPos
        sta GfxPointer
        lda #>(YoYoGfx - ArenaHt) 
        adc #0
        sta GfxPointer+1 

Essentially, I'm just adding an 8-bit number to a 16-bit number. If PVrtPos and the first part of the Pointer go over 255, the carry flag is set, allowing it to be added to the second part of the pointer.

[DaveM]

9 hours ago, bluswimmer said:

No, not quite- you're technically adding the memory address of PVrtPos instead of its actual value. To properly add them together, you'll need to do something like this:

        lda #<(YoYoGfx - ArenaHt)
        clc
        adc PVrtPos
        sta GfxPointer
        lda #>(YoYoGfx - ArenaHt) 
        adc #0
        sta GfxPointer+1 

Essentially, I'm just adding an 8-bit number to a 16-bit number. If PVrtPos and the first part of the Pointer go over 255, the carry flag is set, allowing it to be added to the second part of the pointer.

Oh yes, of course.  I should've figured that one out.

 

For the most part, I got it working now.  So this got it working:
 

Quote

 

        lda #<(YoYoGfx - ArenaHt) 
        clc
        adc PVrtPos
        adc PAniPtr
        sta GfxPointer
        lda #>(YoYoGfx - ArenaHt) 
        adc #0
        sta GfxPointer+1
        sec

 

For some reason, without that last SEC instruction, the yoyo jumps a few pixels over to the right.  I'm guessing the CLC messed with some bit of logic later on in the code. 

 

The yoyo was still running in reverse, so I just flipped the vertical max and min positions, and changed a few things around with the button logic, and got it to work.

 

So it's now sitting at 66 cycles.  As I tried adding the yoyo's string back in there, I blew past the limit again.  I could move setting COLUP0 out of there and to the start of the frame, which would save me 5 cycles, but I don't think that's enough in the long run.  I also have plans later on that might involve him changing colors on a line-by-line basis (although something tells me I might have to lose that idea).

 

I'm spending 34 cycles setting up the playfield.  Any tips on cutting that down further?

 

mr_yo_yo 0.3.1.a _mr_yo_yo.0.3.1.bin

[bluswimmer]

Looking at your code, I believe you can move this part to the end of the scanline.

tya
and #%11111100	; Creates Playfield Ptr
tax		; Playfield Ptr -> YX

This way, you can load values from the playfield array and then store them directly into the PF registers at the beginning of the next scanline, rather than placing them in Temp in the middle of the line and loading those values at the beginning of the next line. I was able to save about 14 cycles doing this.

[+splendidnut]

6 hours ago, DaveM said:

For some reason, without that last SEC instruction, the yoyo jumps a few pixels over to the right.  I'm guessing the CLC messed with some bit of logic later on in the code. 

 

I'm spending 34 cycles setting up the playfield.  Any tips on cutting that down further?

 

I'm guessing that last SEC instruction helps realigns the SetHorizPos subroutine to make sure it's branch instruction doesn't cross a page boundary.  That would cost an extra cycle causing the player misalignment that you are seeing.  Either add an align instruction (align 256) or move that subroutine to the beginning of the code (before your Start: label).

 

To cut down on cycles for setting up the playfield:

 - get rid of the use of temp variables (Temp0, Temp2) they aren't really needed as long as you update each individual PFx register befores its use.

 - try to avoid recalculating X every scanline (6 cycles) -- tricky and probably not worth the cycles saved.

 

Also, it helps if you put your cycle counts in the code comments... examples can be found here:

https://www.randomterrain.com/atari-2600-memories-guide-to-cycle-counting.html

 

Edited September 23, 2019 by splendidnut
Added some missing bits for clarification purposes

[DaveM]

15 hours ago, bluswimmer said:

Looking at your code, I believe you can move this part to the end of the scanline.

 

15 hours ago, splendidnut said:

To cut down on cycles for setting up the playfield:

 - get rid of the use of temp variables (Temp0, Temp2) they aren't really needed as long as you update each individual PFx register befores its use.

 - try to avoid recalculating X every scanline (6 cycles) -- tricky and probably not worth the cycles saved.

Great suggestions all around.  Some of these occurred to me almost the moment after I shut my computer down for the night.  Always seems to happen like that.

 

15 hours ago, splendidnut said:

Also, it helps if you put your cycle counts in the code comments...

Gotcha.  The next time I start whining about cycle counts, I will do so.  But since I'm not whining now, you'll just have to take my word that I got everything working, string and all, at a good 58 cycles.  

 

I ended up completely re-writing (a few times) how the playfield is drawn.  I gave up on my clever little logic trick, and just created a couple large arrays, and pulled from them.  I couldn't quite get rid of all the Temp variables, but I got rid of one.  I ran out of registers.  I tried pushing one value to the stack, but things just didn't quite work right, and after fiddling with it for an hour, I gave up and stuck a Temp variable in there.

 

As for getting the yoyo's string to work, I ended up using the ball object.  I figured I'd save a few cycles by just having it go all the way to the top of the screen, that way I don't need to calculate a starting point.  Because of this, I removed the upper "cage" area of the playfield (I'm thinking I may have the yoyo roll on and off at the start/end of each level, but we'll see if I have room for that later). I had to re-work the player draw routine a bit though.  I enable the ball at the start of each frame, but I had to disable it when the player object starts drawing.  So I had to get rid of that clever .byte $2C instruction and replace it with a jump:

 

Quote

DrawYoYo        
    lda #PlrHt-1
    dcp PVrtPos        
        bcs SetP0Gfx
    lda #0
        ;.byte $2C
        jmp P0GfxReg
SetP0Gfx
    lda #0
        sta ENABL
    lda (GfxPointer),y
        
P0GfxReg        
        sta GRP0

Even with that, I'm still sitting at 58 cycles, so I'm happy, at least for now.

 

Unfortunately, something's come up that's going to require my full attention for the next week or two, so I have to put the game on hold for just a bit.  When I get back to it, I think the next step will be adding the scoreboard.  That's the next chapter in the book for me, so I'll go through that thoroughly and play around with the sample code before trying to add it to the game.  I've got the bitmaps for my numbers all laid out, so at least that's done.

 

Thanks again for the help, and I'll see you all soon.

mr_yo_yo 0.3.2.a mr_yo_yo.0.3.2.bin

[DaveM]

Dangit, I told myself I had to set this aside for a week or so, but I just had to tinker.  Naturally, I had a couple ideas after I turned off my computer last night, so I had to log on today and try them.  

19 hours ago, DaveM said:

I couldn't quite get rid of all the Temp variables, but I got rid of one.  I ran out of registers.

Actually, no, I didn't.  I think I tried using X for something at some point during my re-write last night, and when I took that out, I left the Temp variable in there.  Looking at it again today, the X register isn't used at the end of the loop.  So now, the Temp variable is gone, and the timing analysis tool on the 8-bit workshop IDE says I'm now at 52 cycles.  I'm going with what that thing says on these cycle counts:

Quote

 

ldy #192              
LVScan                 
    sta WSYNC        ; [2-52] +3 
    sta PF2             ; [0] +3
    stx PF0             ; [3] +3
    stx PF1             ; [6] +3
    lda #PDefClr     ; [9] +2
    sta COLUP0      ; [11] +3     

DrawYoYo        
    lda #PlrHt-1     ; [14] +2
    dcp PVrtPos      ; [16] +5       
    bcs SetP0Gfx    ; [21] +2
    lda #0             ; [23] +2
       
    jmp P0GfxReg  ; [25-24] +3
SetP0Gfx
    lda #0             ; [24] +2
    sta ENABL        ; [26-25] +3
    lda (GfxPointer),y    ;[29-28] +5
        
P0GfxReg        
    sta GRP0         ; [28-34]  +3
    
PlayfieldCalcs   
    ldx PlayfieldArray,y    ;[31-37]  +4
    lda PlayfieldArray2,y   ;[35-42] +4
            
NextScanline    
    dey                    ;[39-47] +2
    bne LVScan         ;[41-49] +2

 

Something tells me I may need more room down the road to get everything else in there, but I'm good with where it is right now.  I was able to get the game to exactly where I wanted it to be at this point, and learned a ton in the process. 

mr_yo_yo 0.3.3.a

[DaveM]

After a short time off, I'm back at it.  I've moved the play area higher up on the screen to make room for the scoreboard.  I've also fixed it so Mr. Yo-Yo will always return to his default bitmap when resting at the top of his string.  The sideways and diagonal views of him are ok while he's spinning, but I thought they looked a bit awkward while he was resting.  I've also added space for the timer bar, which I'll implement later, and added a 6-digit scoreboard.  Currently, it's just incrementing with every frame, just so I could test it out.  I've made a few other minor changes here and there, trying to optimize things a bit, and removing pieces of code that I'm no longer using.

 

The issue I'm having at this point is trying to position the scoreboard.  I pretty much used the code straight from the example in Steven Hugg's book:

Quote

 

; Scoreboard
    lda #PDefClr
        sta COLUP0
        sta COLUP1
        lda #THREE_COPIES
        sta NUSIZ0
        sta NUSIZ1
       
        sta WSYNC
        SLEEP 26    ; I'd like to set this to 36?
        sta RESP0
        sta RESP1
        lda #$10
        sta HMP1
        sta WSYNC
        sta HMOVE
        sta HMCLR
        lda #1
        sta VDELP0
        sta VDELP1

        jsr GetDigitPtrs    ; get pointers
        jsr DrawDigits        ; draw digits

 

He uses the SLEEP command to position the score horizontally.  But as I try to change that value, things get buggy.  Setting it to 36 would seem to center it, but this causes it to repeat the tens and ones digits three times each.  The score just looks awkward where it is now.  How would I get it centered?

 

The other thing I have to figure out is, I also want to display lives remaining and have a progress bar, but I seem to be running out of room.  But that's just something I'll have to figure out later.  I may shrink the play area a bit more to open up some room on the bottom, or perhaps I could figure out some other way to indicate that information.  For example, show lives remaining on the scoreboard at the start of the turn only, and indicate progress audibly by using notes of ascending pitch, rather than a progress bar.

mr_yo_yo 0.4.a mr_yo_yo.0.4.bin

[Omegamatrix]

You shouldn't strobe HMCLR immediately after HMOVE. You should leave the HMxx and RESxx registers alone after HMOVE for a certain amount of cycles. I forget how many exactly but it was  ~ 24 or so. 

 

Now there are times that you don't do that for trickery, but for normal positioning you leave them alone.

 

Also, if you are using a 48 pixel display routine then you also have to adjust when you update GRP0 and GRP1 inside of it.

[DaveM]

Thanks for the suggestions with the scoreboard.  Once I get this next part working, I'll tinker with that stuff and see if I can get it to work.

 

Trying to get the enemies to display now, and I can't get them to appear.  Are you still there bluswimmer?

 

So I'm setting up my pointer like this:

Quote

        lda #<(EnemyGfx - ArenaHt)
        clc
        adc LaneVPos        ; Enemy Vertical Position
        adc LaneEnemy        ; Enemy Type
        adc LaneAni        ; Animation Counter
        sta EnemyPointer
        lda >#(EnemyGfx - ArenaHt)
        adc #0
        sta EnemyPointer+1

For testing purposes, LaneVPos is 23, LaneEnemy is 8, and LaneAni is 0 or 8.  What I'd like it to do is display the bitmap starting at position 8 (the LaneEnemy variable), or 16 (when added to the LaneAni variable) of the EnemyGfx Array.

 

The draw routine looks like this:

Quote

DrawEnemies
        lda #EnemyHt-1
        dcp LaneVPos
        bcs DoDrawEnemy
        lda #0
        .byte $2c
DoDrawEnemy
        lda (EnemyPointer),y
        sta GRP1

With this added into my display kernel, I'm still only sitting at 65 cycles, so that's not quite a concern yet.
 

I've set the color and horizontal position ok.  When I comment out the adc LaneEnemy line from the pointer setup, I get a red bar moving across the screen, which I think it's grabbing from the playfield graphics, but I can't figure out exactly where.

 

So I suspect that my problem is with the pointer setup, but I can't figure out how to fix that.  I'll keep playing with it, but any help is appreciated.

 

Thanks in advance!

mr_yo_yo 0.5.a

[DaveM]

3 hours ago, DaveM said:

LaneVPos is 23

Whoops... I meant 35.  It's 23 in hex.