Jump to content

Photo

Programmer's Reference Manual


35 replies to this topic

#26 phaeron OFFLINE  

phaeron

    River Patroller

  • Topic Starter
  • 2,734 posts
  • Location:Bay Area, CA, USA

Posted Tue Mar 12, 2019 11:01 PM

Yes, the ASL stores the high bit (inverse video) into the carry, then pushed in the stack with the PHP, so the state is unknown at the SBC.

 
Right, but A bit 0 is then guaranteed to be 0 at that point and is discarded later with the ROR, so the SEC can be dropped and the SBC adjusted to SBC #$3F, or equivalently ADC #$C0 used. Did an exhaustive test of all 256 values and it seems to work fine.

 

does not change perocesor flags nor registers
 
delay6 .byte $80
delay5 .byte $80
delay4 .byte $80
delay3 .byte $04
delay2 .byte $1a

 

Thanks, but I'm avoiding including anything with illegal opcodes for now. Most of the time they are not necessary and I don't intend to encourage recreational use of them.



#27 dmsc OFFLINE  

dmsc

    Dragonstomper

  • 508 posts
  • Location:Viņa del Mar, Chile

Posted Wed Mar 13, 2019 5:18 AM

Hi!

Right, but A bit 0 is then guaranteed to be 0 at that point and is discarded later with the ROR, so the SEC can be dropped and the SBC adjusted to SBC #$3F, or equivalently ADC #$C0 used. Did an exhaustive test of all 256 values and it seems to work fine.


You are right, I missed the fact that adding one more is not important, as the last bit is then discarded!

So, now the code is une byte shorter and two cycles faster :)

#28 pirx OFFLINE  

pirx

    Moonsweeper

  • 451 posts
  • Location:Poland

Posted Thu Mar 14, 2019 2:09 AM

 ...and I don't intend to encourage recreational use of them.

Laughed my a**e off :))))



#29 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 14,493 posts
  • Location:United Kingdom

Posted Thu Mar 14, 2019 5:39 AM

Hi,

 

   One routine that I end up using in almost all my code is byte -> 2 digit hex code, I copied it from: http://atariage.com/...o-ascii-string/ - obviously it can handle word values by being called twice.

 

Cool! In the SIDE loader, I was able to replace this:

	.proc HexOut
	tax
	lda HexTable,x
	jmp PutChar
	.endp

(which required a 16 byte look up table) with this...

	.proc HexOut
	sed
	cmp #9+1
	adc #$30
	cld
	jmp PutChar
	.endp

...which is only 2 bytes longer but requires no table at all. :)



#30 Irgendwer OFFLINE  

Irgendwer

    Stargunner

  • 1,459 posts
  • Location:Germany

Posted Fri Mar 15, 2019 4:41 PM

You can do it in one cycle less, but three bytes more, using a ZP location:
                ; Bytes   Cycles
 sta zp         ; 2       3
 and #$60       ; 2       2
 asl            ; 1       2
 bmi ok         ; 2       2 3
 eor #$40       ; 2       2 0
ok:
 adc #$40       ; 2       2
 lsr            ; 1       2
 eor zp         ; 2       3

 

 

The variant from cc65 is also interesting:

        asl     a               ; shift out the inverse bit
        adc     #$c0            ; grab the inverse bit; convert ATASCII to screen code
        bpl     codeok          ; screen code ok?
        eor     #$40            ; needs correction
codeok: lsr     a               ; undo the shift
        bcc     done
        eor     #$80                ; restore the inverse bit
done:   ...

or my alternative to the above (one byte shorter but slower):

	asl     a               ; shift out the inverse bit
        adc     #$c0            ; grab the inverse bit; convert ATASCII to screen code
        bpl     codeok          ; screen code ok?
        eor     #$40            ; needs correction
codeok: tax
	lsr     a
	txa
        ror     a

Compared to the php/plp version this is one byte longer but one cycle faster (of course with the drawback that X is used), so a lot of versions to choose from...


Edited by Irgendwer, Fri Mar 15, 2019 4:46 PM.


#31 dmsc OFFLINE  

dmsc

    Dragonstomper

  • 508 posts
  • Location:Viņa del Mar, Chile

Posted Fri Mar 15, 2019 9:36 PM

Hi!
 

The variant from cc65 is also interesting:

        asl     a               ; shift out the inverse bit
        adc     #$c0            ; grab the inverse bit; convert ATASCII to screen code
        bpl     codeok          ; screen code ok?
        eor     #$40            ; needs correction
codeok: lsr     a               ; undo the shift
        bcc     done
        eor     #$80                ; restore the inverse bit
done:   ...


That is the fastest yet, at 12 to 14 cycles, but I suggest the following that returns with the carry always cleared:

        asl     a
        adc     #$c0
        bpl     codeok
        eor     #$40
codeok: lsr     a
        bcc     done
        adc     #$7F
done:

or my alternative to the above (one byte shorter but slower):

	asl     a               ; shift out the inverse bit
        adc     #$c0            ; grab the inverse bit; convert ATASCII to screen code
        bpl     codeok          ; screen code ok?
        eor     #$40            ; needs correction
codeok: tax
	lsr     a
	txa
        ror     a
Compared to the php/plp version this is one byte longer but one cycle faster (of course with the drawback that X is used), so a lot of versions to choose from...


If you are using the X register, you can do faster:
        tax            ; 1  2
        asl            ; 1  2
        sbc #$3F       ; 2  2
        bpl ok         ; 2  2 3
        eor #$40       ; 2  2 0
ok:     cpx #128       ; 2  2
        ror            ; 1  2


#32 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 14,493 posts
  • Location:United Kingdom

Posted Sat Mar 16, 2019 2:45 AM

These solutions are almost as efficient as my preferred solution where it's possible: reordering the font data so that ASCII = internal. Unfortunately this method is useless if you a) want to use the resident font or b) want to share the display with anything else (TD Line, etc).



#33 Stephen OFFLINE  

Stephen

    Quadrunner

  • 7,584 posts
  • A8 Gear Head
  • Location:No longer in Crakron, Ohio

Posted Sat Mar 16, 2019 9:24 AM

These solutions are almost as efficient as my preferred solution where it's possible: reordering the font data so that ASCII = internal. Unfortunately this method is useless if you a) want to use the resident font or b) want to share the display with anything else (TD Line, etc).

Does anybody know why the font was arranged this way?  Probably to save a few transistors in ANTIC and have the extra colours in the low res text modes?



#34 dmsc OFFLINE  

dmsc

    Dragonstomper

  • 508 posts
  • Location:Viņa del Mar, Chile

Posted Sat Mar 16, 2019 10:14 AM

Hi!
 

Does anybody know why the font was arranged this way?  Probably to save a few transistors in ANTIC and have the extra colours in the low res text modes?


My guess, to make the useful characters - numbers and upper case letters, ASCII from $20 to $5F - available in antic modes 6 and 7 (the 64 character modes).

But of course, if they had put lowercase into $40 to $5f and control chars into $60 to $7f, the code to transform ATASCII to screen would be shorter and faster :P

#35 _The Doctor__ OFFLINE  

_The Doctor__

    Flux Capacitor Master Craftsman

  • 6,703 posts
  • Location:10-0-11-00:02

Posted Sat Mar 16, 2019 1:11 PM

dmsc..  you could make the changes and share with Facaui could add it to one of his specials!



#36 E474 OFFLINE  

E474

    Chopper Commander

  • 210 posts

Posted Sat Apr 6, 2019 3:01 AM

Hi,

I wrote asking about adding a chapter on different programming environments a while back, but I think that would probably just end up duplicating the info in http://atariwiki.orgso it's probably better not to do so.

I wonder if it's worth listing other resources available, e.g. atarimania, atariwiki, atari8, pigwa, atariage, etc., or pointing to a list of these, just as a useful list of resources for people getting back in to the 8-bit scene?




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users