Help: loop this?

Here you can ask questions or provide insights about how to use efficiently 6502 assembly code on the Oric.
Post Reply
User avatar
Symoon
Archivist
Posts: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Help: loop this?

Post by Symoon » Sat Aug 26, 2017 7:45 am

Hi assembler wizards ;)

Today's question is: is there a way to optimize in size the following small code? (cycles don't matter).
Goal of the code: invert bit 7 of two distinct bytes (to invert their video display on screen)

Code: Select all

A9 80	  LDA #$80
4D BB BF  EOR $BFBB
8D BB BF  STA $BFBB
A9 80	  LDA #$80
4D DC BF  EOR $BFDC
8D DC BF  STA $BFDC
As instructions are really similar, I've tried many loops or other ways of coding it, but at best I get the exact same amount of bytes (and a much more complicated code ;) ).
Note: JSR forbidden, except to use ROM1.1 calls (I need the routine to be easily moved anywhere in RAM)
Thanks!

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Help: loop this?

Post by Dbug » Mon Aug 28, 2017 6:46 pm

I don't see many ways, maybe by playing with the carry flag and using ROL/ROR directly on the values, but obviously it means you have perfect control on what was there so it does not get transformed in horrible attributes that break the display :)

Without the rest of the code, it's kind of difficult to know what can be done :)

User avatar
Symoon
Archivist
Posts: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Help: loop this?

Post by Symoon » Mon Aug 28, 2017 9:40 pm

Actually, that was the very beginning of the code of my progress bar. It displays the boundaries before the progress bar begins to run.

I was hoping to earn 1 or 2 bytes to keep it as small as possible, it felt strange to have to use 20 bytes to invert 2 bits.
But gave up, asking because I was wondering if there was some magic trick I might not be aware of (I'm stil not very clever in assembler optimization ;) )

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Help: loop this?

Post by Dbug » Tue Aug 29, 2017 7:21 am

So I assume the XOR is there so the progress bar does not impact whatever was displayed there before the loading?

User avatar
Symoon
Archivist
Posts: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Help: loop this?

Post by Symoon » Tue Aug 29, 2017 9:12 am

Dbug wrote:
Tue Aug 29, 2017 7:21 am
So I assume the XOR is there so the progress bar does not impact whatever was displayed there before the loading?
Exactly.
I could use another "look" but I wanted a first version that would be as "universal" as possible (slow or fast, redefined chars or not, hires or text, letting a screen pre-loaded visible).
It will only be messy in case of TEXT screen loading (and of course not universal at all on ROM 1.0)

User avatar
Dbug
Site Admin
Posts: 2366
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Help: loop this?

Post by Dbug » Tue Aug 29, 2017 10:20 am

What about just copying the entire content of the line to a temporary buffer (say, the stack), and then restore it later?
Something like that:

Code: Select all

  ; Save to stack
  ldx #39
loop_push
  lda $bfb8,x
  pha 
  ; Possibly change the content of the buffer here, like force to spaces, or BLUE paper
  ; lda #16+4
  ; sta $bfb8,x
  dex
  bcc loop_push

  ; Do whatever with the 40 characters at the bottom

  ; Restore from stack
  ldx #39
loop_pop
  pla
  sta $bfb8,x
  dex
  bcc loop_pop

User avatar
Symoon
Archivist
Posts: 1169
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France
Contact:

Re: Help: loop this?

Post by Symoon » Tue Aug 29, 2017 9:38 pm

I thought about doing this but it won't work if a screen is being loaded over the progress bar. You'd then restore the previous screen state over the new ;)
So I just save a single byte (the one flashing). It has the other advantage of using less memory and let me load the progress bar program in the stack (page 1).

There's nothing too wrong anyway, if a screen loads over the progress bar as it is now, I think it will just delete the already-reversed progress bar, and then the progress bar would carry on inverting the newly-loaded bytes.
That should look a bit strange on the single-saved byte, but that being said, if it's only a text or hires screen loading, the progress bar isn't very useful as one can already see the data loading...

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests