Loading ...
Sorry, an error occurred while loading the content.

Re: [TI-99/4A] Horiz scroll in bitmap mode - BUG :-(

Expand Messages
  • mark wills
    Yeah, thanks Jeff, I actually came to the same conclusion, and am now doing it byte wise. It starts on the right, and works towards the left, but again, it s
    Message 1 of 14 , Oct 1, 2006
    View Source
    • 0 Attachment
      Yeah, thanks Jeff, I actually came to the same conclusion, and am now doing it byte wise.

      It starts on the right, and works towards the left, but again, it's not right yet, it seems to scroll only the bottom line (i.e. the 8th 'scan line', or 32x1) rather than 32x8, if you see what I mean. I ran out of time. Got a house full of sick kids, and I'm off to Aberdeen today for work. Will probably have a look tonight. Here's the code so though.

      (I'm using two registers, R3 and R4 for the carry/don't carry - the appropriate register is copied to R5 which is OR'd in to the shifted value). Hope this makes sense. I removed the initialisation code, since I know it works fine (I copied from a publication anyway, except I wrote a "write same byte many times" routine.

      Here's the scroll loop, if you see anything, let me know ;-)

      Mark.

      ; put buffer on the screen

      li r7,255 ; end of buffer (32x8)-1

      dump li r0,>0000 ; vdp address
      li r1,buffer ; buffer address
      li r2,256 ; byte count
      bl @vmbw ; write to vdp

      limi 2
      limi 0

      ; scroll buffer

      clr r1 ; holds buffer contents
      li r3,>0100 ; used for ORing a carry in
      clr r4 ; used when no carry
      clr r5 ; holds new OR'd value

      li r0,buffer ; pointer to buffer

      a r7,r0 ; move to end of buffer
      li r6,32 ; counter

      scroll movb *r0,r1 ; get right byte

      sla r1,1 ; shift it
      socb r5,r1 ; OR in previous carry
      jnc nc ; there was no carry from msbit
      mov r3,r5 ; set carry for next loop
      jmp xit ; jump around next instruction

      nc mov r4,r5 ; no carry

      xit movb r1,*r0 ; put byte back
      ai r0,-8 ; move back one char in buffer

      dec r6 ; have we done a complete line of 8x8?
      jne scroll ; if not repeat
      ai r7,-32 ; SHOULD THIS BE -8?? NEED TO INVESTIGATE
      jmp dump ; else dump buffer to vdp

      aorg >b000 ; buffer @ >b000 for easier debugging!

      buffer bss 256 ; screen buffer - one character line - 32x8
      even



      ----- Original Message ----
      From: Jeff White <jhwhite@...>
      To: ti99-4a@yahoogroups.com
      Sent: Sunday, 1 October, 2006 7:37:02 AM
      Subject: Re: [TI-99/4A] Horiz scroll in bitmap mode - BUG :-(

      "mark wills" <markrobertwills@ yahoo.co. uk> wrote:
      > Hi Jeff,
      >
      > Doh! Of course! I asked the question on the board only yesterday about how
      > memory was laid out in the VDP in bitmap, and then failed to take that
      > into account when coding. Er...
      >
      > Thanks for spelling it out to me... I'll have another look at the code.
      <snip>

      BTW, Mark, I do not think that I would code the left shift as exemplified by
      the code I wrote. I was trying to fit it to your sample code, but it just
      seemed a bit too complicated. There is possibly a simpler way to do it.

      My recommendation is to do everything byte-wise, then check the msbit of the
      8th byte hence and use "AI *Rx,>0100" to shift in the first bit when set of
      the right character. This way you can step through each character one at a
      time instead of two at a time. There may be a speed advantage one way or
      the other, but certainly it is less confusing to do the same thing over and
      over, rather than alternate between two different methods of shifting a bit
      from one byte to another.

      Jeff White
      jhwhite@delphiforum s.com








      [Non-text portions of this message have been removed]
    • Jeff White
      Jeff White wrote: ... I managed to mess that up in editing. AI cannot do general addressing and requires workspace
      Message 2 of 14 , Oct 1, 2006
      View Source
      • 0 Attachment
        "Jeff White" <jhwhite@...> wrote:
        <snip>
        > My recommendation is to do everything byte-wise, then check the msbit of
        > the
        > 8th byte hence and use "AI *Rx,>0100" to shift in the first bit when set
        > of
        > the right character.
        <snip>

        I managed to mess that up in editing. AI cannot do general addressing and
        requires workspace register addressing. Thus, the following instructions
        would have made sense:

        AI Rx,>0100
        AB *Rx, @ H01

        where x is any of the 16 registers 0 through 15.

        Jeff White
        jhwhite@...
      • Jeff White
        I will comment within the code, Mark, so I can understand what you are doing. It is mainly for my benefit in identifying the problem. ... It bitmap mode there
        Message 3 of 14 , Oct 1, 2006
        View Source
        • 0 Attachment
          I will comment within the code, Mark, so I can understand what you are
          doing. It is mainly for my benefit in identifying the problem.

          "mark wills" <markrobertwills@...> wrote:
          > Yeah, thanks Jeff, I actually came to the same conclusion, and am now
          > doing it byte wise.
          >
          > It starts on the right, and works towards the left, but again, it's not
          > right yet, it seems to scroll only the bottom line (i.e. the 8th 'scan
          > line', or 32x1) rather than 32x8, if you see what I mean. I ran out of
          > time. Got a house full of sick kids, and I'm off to Aberdeen today for
          > work. Will probably have a look tonight. Here's the code so though.
          >
          > (I'm using two registers, R3 and R4 for the carry/don't carry - the
          > appropriate register is copied to R5 which is OR'd in to the shifted
          > value). Hope this makes sense. I removed the initialisation code, since I
          > know it works fine (I copied from a publication anyway, except I wrote a
          > "write same byte many times" routine.
          >
          > Here's the scroll loop, if you see anything, let me know ;-)
          >
          > Mark.
          >
          > ; put buffer on the screen
          >
          > li r7,255 ; end of buffer (32x8)-1
          >
          > dump li r0,>0000 ; vdp address
          > li r1,buffer ; buffer address
          > li r2,256 ; byte count
          > bl @vmbw ; write to vdp
          >
          > limi 2
          > limi 0
          >
          > ; scroll buffer
          >
          > clr r1 ; holds buffer contents
          > li r3,>0100 ; used for ORing a carry in
          > clr r4 ; used when no carry
          > clr r5 ; holds new OR'd value
          >
          > li r0,buffer ; pointer to buffer
          >
          > a r7,r0 ; move to end of buffer
          > li r6,32 ; counter

          It bitmap mode there are 32 characters per character line, so R6 appears to
          be a character counter.

          > scroll movb *r0,r1 ; get right byte
          >
          > sla r1,1 ; shift it
          > socb r5,r1 ; OR in previous carry
          > jnc nc ; there was no carry from msbit

          Note that both SLA and SOCB will affect the status register, but SOCB does
          not affect the carry bit set or cleared by the SLA. Had an arithmetic
          instruction such as "A R5,R1" been used instead of SOCB, then the carry bit
          would have always been cleared when the code dropped to the JNC.

          > mov r3,r5 ; set carry for next loop
          > jmp xit ; jump around next instruction
          >
          > nc mov r4,r5 ; no carry

          I would have used "CLR R5" rather than store zero in R4. CLR and SETO
          instructions do not affect status bits, but MOV does. It does not matter
          here, but had there been some reason to check status bits affected by SOCB
          after checking carry, the MOV stomps on the possibility.

          > xit movb r1,*r0 ; put byte back
          > ai r0,-8 ; move back one char in buffer

          First time through the loop the the bottom line of each character is being
          shifting left. Thus, the bytes being shifted in the buffer go in order 255,
          247, 239, etc. through 7. Next time the loop on R0 needs to start at 254.

          > dec r6 ; have we done a complete line of 8x8?
          > jne scroll ; if not repeat

          R6 is keeping track of which character is being shifted, 32 per line.

          > ai r7,-32 ; SHOULD THIS BE -8?? NEED TO
          > INVESTIGATE
          > jmp dump ; else dump buffer to vdp

          What is this doing? First time here R7 becomes 255-32, or 222. The next
          step should go to the 32nd character, 7th line, which will be at offset 254.
          Replace this with:

          DEC R7 ; next loop starts at prior buffer start less one
          byte
          CI R4,247 ; done all 8 lines?
          JNE DUMP ; no

          And if you want to continue shifting this character line, follow this by:

          JMP DUMP-4 ; goto the LI R7,255

          > aorg >b000 ; buffer @ >b000 for easier debugging!
          >
          > buffer bss 256 ; screen buffer - one character
          > line - 32x8
          > even

          Assuming I have decoded properly, the above suggestions should fix the
          problem.

          Note also that after 8 shifts left, the rightmost (32nd) character will be
          null, so shifting could start at byte offset 247, the last line of character
          31. By keeping track of when a character has been completely shifted, you
          can save some time and accelerate the scroll.

          Jeff White
          jhwhite@...
        • Jeff White
          Jeff White wrote: ... Maybe I should just stop and take that vacation. AB @ H01,*Rx is what should have been posted, where
          Message 4 of 14 , Oct 1, 2006
          View Source
          • 0 Attachment
            "Jeff White" <jhwhite@...> wrote:
            <snip>
            > AB *Rx, @ H01
            >
            > where x is any of the 16 registers 0 through 15.

            Maybe I should just stop and take that vacation.

            AB @ H01,*Rx

            is what should have been posted, where H01 refers to a byte storing the
            value 1.

            Guess I should go ahead and read the last message I posted.

            Jeff White
            jhwhite@...
          • mark wills
            Hi Jeff Your suggestion: DEC R7 ; next loop starts at prior buffer start less one byte CI R4,247 ; done all 8 lines? JNE DUMP ; no did indeed work, but it
            Message 5 of 14 , Oct 2, 2006
            View Source
            • 0 Attachment
              Hi Jeff

              Your suggestion:


              DEC R7 ; next loop starts at prior buffer start less one
              byte
              CI R4,247 ; done all 8 lines?
              JNE DUMP ; no

              did indeed work, but it looks like you meant to say R7 not R4! Anyway, I used R7 and it does indeed work.

              >Note that both SLA and SOCB will affect the status register, but SOCB does
              >not affect the carry bit set or cleared by the SLA. Had an arithmetic
              >instruction such as "A R5,R1" been used instead of SOCB, then the carry bit
              >would have always been cleared when the code dropped to the JNC.

              Exactly! I actually went to the trouble of looking this up in the ED/AS manual - Fortunately for me, SOCB doesn't hurt the C flag in the status register, so it works nicely in that respect.

              >I would have used "CLR R5" rather than store zero in R4. CLR and SETO
              >instructions do not affect status bits, but MOV does. It does not matter
              >here, but had there been some reason to check status bits affected by SOCB
              >after checking carry, the MOV stomps on the possibility.

              Ah, good suggestion, that means R4 is free for other things. Is a CLR instruction faster than a MOV instruction?

              Do you see any ways to make the code more efficient? I'm just about to go through it now and see if it can be improved. I think it's pretty tight - unfortunatley the 8 byte stagger between adjacent bytes makes things more complex... Still, scrolling up/down would be simple. (On the Sinclair ZX spectrum it quite easy to scroll horizontally, but not vertically, as the screen is arranged very differently to the TI's)

              Thanks for your help Jeff... I'm going to have a look at scrolling a third of the screen - i'm particularly interested in seeing if I can produce a routine that is comparable speed wise to Parsec, which, I understand, runs in the 256 byte 16 bit ram. As it stands, I think the routine below will fit in the 16 bit ram.

              Regards

              Mark.

              ; scroll buffer

              clr r1 ; holds buffer contents
              li r3,>0100 ; used for ORing a carry in
              clr r5 ; holds new OR'd value

              li r0,buffer ; pointer to buffer

              a r7,r0 ; move to end of buffer
              li r6,32 ; counter

              scroll movb *r0,r1 ; get right byte

              sla r1,1 ; shift it
              socb r5,r1 ; OR in previous carry
              jnc nc ; there was no carry from msbit
              mov r3,r5 ; set carry for next loop
              jmp xit ; jump around next instruction

              nc clr r5 ; no carry

              xit movb r1,*r0 ; put byte back
              ai r0,-8 ; move back one char in buffer

              dec r6 ; have we done a complete line of 8x8?
              jne scroll ; if not repeat
              dec r7 ; move up one scan line
              ci r7,247
              jne dump ; else dump buffer to vdp
              jmp dump-4




              Mark Wills, MSc MIAP
              http://www.markwills.co.uk

              ----- Original Message ----
              From: Jeff White <jhwhite@...>
              To: ti99-4a@yahoogroups.com
              Sent: Sunday, 1 October, 2006 5:12:24 PM
              Subject: Re: [TI-99/4A] Horiz scroll in bitmap mode - BUG :-(

              I will comment within the code, Mark, so I can understand what you are
              doing. It is mainly for my benefit in identifying the problem.

              "mark wills" <markrobertwills@ yahoo.co. uk> wrote:
              > Yeah, thanks Jeff, I actually came to the same conclusion, and am now
              > doing it byte wise.
              >
              > It starts on the right, and works towards the left, but again, it's not
              > right yet, it seems to scroll only the bottom line (i.e. the 8th 'scan
              > line', or 32x1) rather than 32x8, if you see what I mean. I ran out of
              > time. Got a house full of sick kids, and I'm off to Aberdeen today for
              > work. Will probably have a look tonight. Here's the code so though.
              >
              > (I'm using two registers, R3 and R4 for the carry/don't carry - the
              > appropriate register is copied to R5 which is OR'd in to the shifted
              > value). Hope this makes sense. I removed the initialisation code, since I
              > know it works fine (I copied from a publication anyway, except I wrote a
              > "write same byte many times" routine.
              >
              > Here's the scroll loop, if you see anything, let me know ;-)
              >
              > Mark.
              >
              > ; put buffer on the screen
              >
              > li r7,255 ; end of buffer (32x8)-1
              >
              > dump li r0,>0000 ; vdp address
              > li r1,buffer ; buffer address
              > li r2,256 ; byte count
              > bl @vmbw ; write to vdp
              >
              > limi 2
              > limi 0
              >
              > ; scroll buffer
              >
              > clr r1 ; holds buffer contents
              > li r3,>0100 ; used for ORing a carry in
              > clr r4 ; used when no carry
              > clr r5 ; holds new OR'd value
              >
              > li r0,buffer ; pointer to buffer
              >
              > a r7,r0 ; move to end of buffer
              > li r6,32 ; counter

              It bitmap mode there are 32 characters per character line, so R6 appears to
              be a character counter.

              > scroll movb *r0,r1 ; get right byte
              >
              > sla r1,1 ; shift it
              > socb r5,r1 ; OR in previous carry
              > jnc nc ; there was no carry from msbit

              Note that both SLA and SOCB will affect the status register, but SOCB does
              not affect the carry bit set or cleared by the SLA. Had an arithmetic
              instruction such as "A R5,R1" been used instead of SOCB, then the carry bit
              would have always been cleared when the code dropped to the JNC.

              > mov r3,r5 ; set carry for next loop
              > jmp xit ; jump around next instruction
              >
              > nc mov r4,r5 ; no carry

              I would have used "CLR R5" rather than store zero in R4. CLR and SETO
              instructions do not affect status bits, but MOV does. It does not matter
              here, but had there been some reason to check status bits affected by SOCB
              after checking carry, the MOV stomps on the possibility.

              > xit movb r1,*r0 ; put byte back
              > ai r0,-8 ; move back one char in buffer

              First time through the loop the the bottom line of each character is being
              shifting left. Thus, the bytes being shifted in the buffer go in order 255,
              247, 239, etc. through 7. Next time the loop on R0 needs to start at 254.

              > dec r6 ; have we done a complete line of 8x8?
              > jne scroll ; if not repeat

              R6 is keeping track of which character is being shifted, 32 per line.

              > ai r7,-32 ; SHOULD THIS BE -8?? NEED TO
              > INVESTIGATE
              > jmp dump ; else dump buffer to vdp

              What is this doing? First time here R7 becomes 255-32, or 222. The next
              step should go to the 32nd character, 7th line, which will be at offset 254.
              Replace this with:

              DEC R7 ; next loop starts at prior buffer start less one
              byte
              CI R4,247 ; done all 8 lines?
              JNE DUMP ; no

              And if you want to continue shifting this character line, follow this by:

              JMP DUMP-4 ; goto the LI R7,255

              > aorg >b000 ; buffer @ >b000 for easier debugging!
              >
              > buffer bss 256 ; screen buffer - one character
              > line - 32x8
              > even

              Assuming I have decoded properly, the above suggestions should fix the
              problem.

              Note also that after 8 shifts left, the rightmost (32nd) character will be
              null, so shifting could start at byte offset 247, the last line of character
              31. By keeping track of when a character has been completely shifted, you
              can save some time and accelerate the scroll.

              Jeff White
              jhwhite@delphiforum s.com








              [Non-text portions of this message have been removed]
            • Matthew Hagerty
              Hey Mark, can you post the whole listing? Or a TIDisk would be nice so I don t have to reformat the src to get it to compile. Thanks, Matthew ... Anyway, I
              Message 6 of 14 , Oct 2, 2006
              View Source
              • 0 Attachment
                Hey Mark, can you post the whole listing? Or a TIDisk would be nice
                so I don't have to reformat the src to get it to compile.

                Thanks,
                Matthew

                --- In ti99-4a@yahoogroups.com, mark wills <markrobertwills@...> wrote:
                >
                > Hi Jeff
                >
                > Your suggestion:
                >
                >
                > DEC R7 ; next loop starts at prior buffer start less one
                > byte
                > CI R4,247 ; done all 8 lines?
                > JNE DUMP ; no
                >
                > did indeed work, but it looks like you meant to say R7 not R4!
                Anyway, I used R7 and it does indeed work.
                >
                > >Note that both SLA and SOCB will affect the status register, but
                SOCB does
                > >not affect the carry bit set or cleared by the SLA. Had an
                arithmetic
                > >instruction such as "A R5,R1" been used instead of SOCB, then the
                carry bit
                > >would have always been cleared when the code dropped to the JNC.
                >
                > Exactly! I actually went to the trouble of looking this up in the
                ED/AS manual - Fortunately for me, SOCB doesn't hurt the C flag in the
                status register, so it works nicely in that respect.
                >
                > >I would have used "CLR R5" rather than store zero in R4. CLR and SETO
                > >instructions do not affect status bits, but MOV does. It does not
                matter
                > >here, but had there been some reason to check status bits affected
                by SOCB
                > >after checking carry, the MOV stomps on the possibility.
                >
                > Ah, good suggestion, that means R4 is free for other things. Is a
                CLR instruction faster than a MOV instruction?
                >
                > Do you see any ways to make the code more efficient? I'm just about
                to go through it now and see if it can be improved. I think it's
                pretty tight - unfortunatley the 8 byte stagger between adjacent bytes
                makes things more complex... Still, scrolling up/down would be simple.
                (On the Sinclair ZX spectrum it quite easy to scroll horizontally, but
                not vertically, as the screen is arranged very differently to the TI's)
                >
                > Thanks for your help Jeff... I'm going to have a look at scrolling a
                third of the screen - i'm particularly interested in seeing if I can
                produce a routine that is comparable speed wise to Parsec, which, I
                understand, runs in the 256 byte 16 bit ram. As it stands, I think the
                routine below will fit in the 16 bit ram.
                >
                > Regards
                >
                > Mark.
                >
                > ; scroll buffer
                >
                > clr r1 ; holds buffer contents
                > li r3,>0100 ; used for ORing a carry in
                > clr r5 ; holds new OR'd value
                >
                > li r0,buffer ; pointer to buffer
                >
                > a r7,r0 ; move to end of buffer
                > li r6,32 ; counter
                >
                > scroll movb *r0,r1 ; get right byte
                >
                > sla r1,1 ; shift it
                > socb r5,r1 ; OR in previous carry
                > jnc nc ; there was no carry from msbit
                > mov r3,r5 ; set carry for next loop
                > jmp xit ; jump around next instruction
                >
                > nc clr r5 ; no carry
                >
                > xit movb r1,*r0 ; put byte back
                > ai r0,-8 ; move back one char in buffer
                >
                > dec r6 ; have we done a complete line of 8x8?
                > jne scroll ; if not repeat
                > dec r7 ; move up one scan line
                > ci r7,247
                > jne dump ; else dump buffer to vdp
                > jmp dump-4
                >
                >
                >
                >
                > Mark Wills, MSc MIAP
                > http://www.markwills.co.uk
                >
                > ----- Original Message ----
                > From: Jeff White <jhwhite@...>
                > To: ti99-4a@yahoogroups.com
                > Sent: Sunday, 1 October, 2006 5:12:24 PM
                > Subject: Re: [TI-99/4A] Horiz scroll in bitmap mode - BUG :-(
                >
                > I will comment within the code, Mark, so
                I can understand what you are
                > doing. It is mainly for my benefit in identifying the problem.
                >
                > "mark wills" <markrobertwills@ yahoo.co. uk> wrote:
                > > Yeah, thanks Jeff, I actually came to the same conclusion, and am
                now
                > > doing it byte wise.
                > >
                > > It starts on the right, and works towards the left, but again,
                it's not
                > > right yet, it seems to scroll only the bottom line (i.e. the 8th
                'scan
                > > line', or 32x1) rather than 32x8, if you see what I mean. I ran
                out of
                > > time. Got a house full of sick kids, and I'm off to Aberdeen
                today for
                > > work. Will probably have a look tonight. Here's the code so though.
                > >
                > > (I'm using two registers, R3 and R4 for the carry/don't carry - the
                > > appropriate register is copied to R5 which is OR'd in to the shifted
                > > value). Hope this makes sense. I removed the initialisation code,
                since I
                > > know it works fine (I copied from a publication anyway, except I
                wrote a
                > > "write same byte many times" routine.
                > >
                > > Here's the scroll loop, if you see anything, let me know ;-)
                > >
                > > Mark.
                > >
                > > ; put buffer on the screen
                > >
                > > li r7,255 ; end of buffer (32x8)-1
                > >
                > > dump li r0,>0000 ; vdp address
                > > li r1,buffer ; buffer address
                > > li r2,256 ; byte count
                > > bl @vmbw ; write to vdp
                > >
                > > limi 2
                > > limi 0
                > >
                > > ; scroll buffer
                > >
                > > clr r1 ; holds buffer contents
                > > li r3,>0100 ; used for ORing a carry in
                > > clr r4 ; used when no carry
                > > clr r5 ; holds new OR'd value
                > >
                > > li r0,buffer ; pointer to buffer
                > >
                > > a r7,r0 ; move to end of buffer
                > > li r6,32 ; counter
                >
                > It bitmap mode there are 32 characters per character line, so R6
                appears to
                > be a character counter.
                >
                > > scroll movb *r0,r1 ; get right byte
                > >
                > > sla r1,1 ; shift it
                > > socb r5,r1 ; OR in previous carry
                > > jnc nc ; there was no carry from msbit
                >
                > Note that both SLA and SOCB will affect the status register, but
                SOCB does
                > not affect the carry bit set or cleared by the SLA. Had an arithmetic
                > instruction such as "A R5,R1" been used instead of SOCB, then the
                carry bit
                > would have always been cleared when the code dropped to the JNC.
                >
                > > mov r3,r5 ; set carry for next loop
                > > jmp xit ; jump around next instruction
                > >
                > > nc mov r4,r5 ; no carry
                >
                > I would have used "CLR R5" rather than store zero in R4. CLR and SETO
                > instructions do not affect status bits, but MOV does. It does not
                matter
                > here, but had there been some reason to check status bits affected
                by SOCB
                > after checking carry, the MOV stomps on the possibility.
                >
                > > xit movb r1,*r0 ; put byte back
                > > ai r0,-8 ; move back one char in buffer
                >
                > First time through the loop the the bottom line of each character
                is being
                > shifting left. Thus, the bytes being shifted in the buffer go in
                order 255,
                > 247, 239, etc. through 7. Next time the loop on R0 needs to start
                at 254.
                >
                > > dec r6 ; have we done a complete line
                of 8x8?
                > > jne scroll ; if not repeat
                >
                > R6 is keeping track of which character is being shifted, 32 per line.
                >
                > > ai r7,-32 ; SHOULD THIS BE -8?? NEED TO
                > > INVESTIGATE
                > > jmp dump ; else dump buffer to vdp
                >
                > What is this doing? First time here R7 becomes 255-32, or 222.
                The next
                > step should go to the 32nd character, 7th line, which will be at
                offset 254.
                > Replace this with:
                >
                > DEC R7 ; next loop starts at prior buffer start less one
                > byte
                > CI R4,247 ; done all 8 lines?
                > JNE DUMP ; no
                >
                > And if you want to continue shifting this character line, follow
                this by:
                >
                > JMP DUMP-4 ; goto the LI R7,255
                >
                > > aorg >b000 ; buffer @ >b000 for easier
                debugging!
                > >
                > > buffer bss 256 ; screen buffer - one
                character
                > > line - 32x8
                > > even
                >
                > Assuming I have decoded properly, the above suggestions should fix the
                > problem.
                >
                > Note also that after 8 shifts left, the rightmost (32nd) character
                will be
                > null, so shifting could start at byte offset 247, the last line of
                character
                > 31. By keeping track of when a character has been completely
                shifted, you
                > can save some time and accelerate the scroll.
                >
                > Jeff White
                > jhwhite@delphiforum s.com
                >
                >
                >
                >
                >
                >
                >
                >
                > [Non-text portions of this message have been removed]
                >
              • mark wills
                Hi Matthew Heres the complete source as it currently stands. Mark ; ; bit map scroll ; def START aorg a000 ; program entry point START limi 0
                Message 7 of 14 , Oct 2, 2006
                View Source
                • 0 Attachment
                  Hi Matthew

                  Heres the complete source as it currently stands.

                  Mark
                  ;
                  ; bit map scroll
                  ;

                  def START

                  aorg >a000

                  ; program entry point

                  START limi 0 ; interrupts off

                  li r0,>0700 ; screen colour
                  bl @vwtr

                  li r0,>0002 ; bitmap mode on
                  bl @vwtr

                  li r0,>0206 ; screen image table @ >1800
                  bl @vwtr

                  li r0,>03ff ; colour table @ >2000
                  bl @vwtr

                  li r0,>0403 ; pattern table @ >0000
                  bl @vwtr

                  li r0,>0536 ; sprite attribute list @ >1b00
                  bl @vwtr

                  li r0,>1b00 ; switch off sprites
                  li r1,>d000
                  bl @vsbw

                  ; initialise the screen image table

                  li r0,>1800 ; sit address
                  clr r2
                  bit1 clr r1
                  bit2 bl @vsbw
                  inc r0
                  ai r1,>0100
                  ci r1,>0000
                  jne bit2
                  inc r2
                  ci r2,3
                  jne bit1

                  ; initialise pattern descriptor table

                  clr r0
                  clr r1
                  li r2,>1800
                  bl @vwbm

                  ; initialise the colour table

                  li r0,>2000
                  li r1,>e000
                  li r2,6144
                  bl @vwbm

                  ; load buffer with known values

                  li r0,buffer ; buffer address
                  li r1,>ABCD ; value to write
                  li r2,256 ; word count
                  buf1 mov r1,*r0+ ; write a word
                  ai r1,>0101
                  dect r2 ; reduce word count
                  jne buf1

                  ; put buffer on the screen

                  li r7,255 ; end of buffer (32x8)-1

                  dump li r0,>0000 ; vdp address
                  li r1,buffer ; buffer address
                  li r2,256 ; byte count
                  bl @vmbw ; write to vdp

                  limi 2
                  limi 0

                  ; scroll buffer

                  clr r1 ; holds buffer contents
                  li r3,>0100 ; used for ORing a carry in
                  clr r5 ; holds new OR'd value

                  li r0,buffer ; pointer to buffer

                  a r7,r0 ; move to end of buffer
                  li r6,32 ; counter

                  scroll movb *r0,r1 ; get right byte

                  sla r1,1 ; shift it
                  socb r5,r1 ; OR in previous carry
                  jnc nc ; there was no carry from msbit
                  mov r3,r5 ; set carry for next loop
                  jmp xit ; jump around next instruction

                  nc clr r5 ; no carry

                  xit movb r1,*r0 ; put byte back
                  ai r0,-8 ; move back one char in buffer

                  dec r6 ; have we done a complete line of 8x8?
                  jne scroll ; if not repeat
                  dec r7 ; move up one scan line
                  ci r7,247
                  jne dump ; else dump buffer to vdp
                  jmp dump-4

                  aorg >b000 ; buffer @ >b000 for easier debugging!

                  buffer bss 256 ; screen buffer - one character line - 32x8
                  even




                  [Non-text portions of this message have been removed]
                • Matthew Hagerty
                  ... Video routines? I grabbed the ones from your Kaleidoscope but it seems vwbm is still missing... Matthew
                  Message 8 of 14 , Oct 2, 2006
                  View Source
                  • 0 Attachment
                    --- In ti99-4a@yahoogroups.com, mark wills <markrobertwills@...> wrote:
                    >
                    > Hi Matthew
                    >
                    > Heres the complete source as it currently stands.
                    >
                    > Mark

                    Video routines? I grabbed the ones from your Kaleidoscope but it
                    seems vwbm is still missing...

                    Matthew
                  • mark wills
                    sorry!! here s vwbm... ; vdp write byte many ; r0=start address, r1(msb)=byte to write, r2=count (trashed on exit) vwbm ori r0, 4000 swpb r0 movb
                    Message 9 of 14 , Oct 2, 2006
                    View Source
                    • 0 Attachment
                      sorry!!

                      here's vwbm...

                      ; vdp write byte many
                      ; r0=start address, r1(msb)=byte to write, r2=count (trashed on exit)
                      vwbm ori r0,>4000
                      swpb r0
                      movb r0,@vdpa
                      swpb r0
                      movb r0,@vdpa
                      nop
                      vwbm1 movb r1,@vdpw
                      dec r2
                      jne vwbm1
                      rt



                      Mark Wills, MSc MIAP
                      http://www.markwills.co.uk

                      ----- Original Message ----
                      From: Matthew Hagerty <matthew@...>
                      To: ti99-4a@yahoogroups.com
                      Sent: Monday, 2 October, 2006 8:01:45 PM
                      Subject: [TI-99/4A] Re: Horiz scroll in bitmap mode - WORKS!

                      --- In ti99-4a@yahoogroups .com, mark wills <markrobertwills@ ...> wrote:
                      >
                      > Hi Matthew
                      >
                      > Heres the complete source as it currently stands.
                      >
                      > Mark

                      Video routines? I grabbed the ones from your Kaleidoscope but it
                      seems vwbm is still missing...

                      Matthew








                      [Non-text portions of this message have been removed]
                    Your message has been successfully submitted and would be delivered to recipients shortly.