| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Share your 6502 tricks
So x2008 is over and for those of us not participating it's high time to break that coder's block and get hacking again. And what could be more inspiring than reading about clever 6502 routines, innovative VIC tricks, general bit-hacks, or neat algorithms and data-structures?
First off, here's a routine to generate 256-byte logarithm tables for multiplication and division. Saving some 145 bytes or so after compression, with a slight loss in precision. This is an eight-bit implementation based on the classic shift-add algorithm where you repeatedly try to factorize (x²-1)/x² factors out of a normalized number, with the factors' logarithms stored in a pre-calculated table.table = $c000 ;page aligned
seed .byte $00,$00
.byte $02,$05
.byte $0c,$1f
reduce pla
adc seed,y
sec
next pha
ldy #5
txa
sta shift+4
shift ror shift+4
sbx #$00
bcs reduce
tax
dey
bpl shift
pla
store sbc #$1f
sta table
lsr store+3
bcc store
enter dec *+4
lda #$00
sta store+3
asl a
tax
lda #$00
bcs next
; sta table ;do whatever makes most sense for log(0)
rts
Another not uncommon problem is how to do efficient IRQ loading. The limiting factor on the C64 side is the number of cycles needed for the drive to pull itself out of a tight loop and send new data in response to the C64 signaling that it wants a new bit (or bit pair.) Typically this would be done though an EOR $dd00 instruction to read some bits, immediately followed by a store to toggle ATN, after which we need to wait for the worst-case response time of the drive before the procedure can be repeated.
The trick here is to use a single RMW instruction both to receive and acknowledge the data, thus cutting down time between the load and store from four down to two cycles. The most straightforward and efficient instruction to use here is SRE but you can do fairly well without illegals even with having to pull the output from the flags. Besides, the the performance doesn't really matter as long as it can keep up with the drive.
I suggest an implementation along the following lines. That is assuming the the source data is swizzled in the appropriate way, the VIC bank is DDR controlled, and enough NOPs are inserted to compensate for whatever the drive code is doing (e.g. GCR decoding and whatnot.)toggle = $ea ;zeropage address must correspond to a harmless single-byte opcode
lda #%00010000
sta toggle
.
.
.
ldx #%00000100
loop txa
asl $dd00 ;=> %00010000 (lower ATN)
bpl *+3
eor toggle
ror
stx $dd00
asl $dd00 ;=> %00001000 (raise ATN)
bpl *+3
eor toggle
ror
asl $dd00 ;=> %00010000 (lower ATN)
bpl *+3
eor toggle
ror
stx $dd00
asl $dd00 ;=> %00001000 (raise ATN)
bpl *+3
eor toggle
ror
sta sector,y
iny
bne loop
Anyway, that's it for me. Now it's your turn to entertain us all with some code pr0n! |
|
... 2 posts hidden. Click here to view all posts....
|
| |
Scout
Registered: Dec 2002
Posts: 1568 |
Quote: Very much what JackAsser said, and...
Quote:First off, here's a routine to generate 256-byte logarithm tables for multiplication and division. for the more illiterate: why do I need that?
(Don't answer here, put it on Codebase64). ;)
Those are the exp and log tables you need for fast dividing (the 3d stuff, remember) I mentioned last week on msn.
But indeed, this belongs on Codebase64.org |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Isn't this place better suited for discussion? We can always copy/paste it to Codebase64 afterwards.
|
| |
Scout
Registered: Dec 2002
Posts: 1568 |
Quote: Isn't this place better suited for discussion? We can always copy/paste it to Codebase64 afterwards.
True dat!
I was more referring about sharing code. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Isn't this place better suited for discussion? We can always copy/paste it to Codebase64 afterwards.
No. We can always copy/paste it to Codebase64 FIRST then we can discuss it here or on the forum related to that particular article ON Codebase64. |
| |
Mace
Registered: May 2002
Posts: 1799 |
Quote:Those are the exp and log tables you need for fast dividing (the 3d stuff, remember) I mentioned last week on msn. Yeah, yeah, yeah... but I wanted to hear that from Doynax, with more explanation on how to REALLY use it. |
| |
Scout
Registered: Dec 2002
Posts: 1568 |
Quote: Quote:Those are the exp and log tables you need for fast dividing (the 3d stuff, remember) I mentioned last week on msn. Yeah, yeah, yeah... but I wanted to hear that from Doynax, with more explanation on how to REALLY use it.
Okay, I won't tell you anything anymore. *Grmbl*
;) |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@Jackasser: ...which reminds me, that there was some code/text that you were supposed to "paste" into Codebase64 quite a long time ago. Looking forward to that! ;) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
@Frantic: 'Paste'?!? WTF?!? We're talking serious shit here that can't be forced! :D |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
@Doynax: Thanks for adding it on codebase!
http://codebase64.org/doku.php?id=base:8bit_logarithm_table_gen.. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Added.
The point here is that many hacks are really only useful in very specific domains, no matter how cool they look, and many small tricks just don't fit (easily) on the code base. More than that, though, the idea is to be able to post without feeling a need comment extensively, do a lot of testing, or trying to be eloquent. Hence lowering the threshold for posting so people can submit whatever little tricks they've used in their own code without having to spend half a day on it..
Besides, I'd consider anything written in a thread like this to be in the public domain to begin with, free for someone else to post on the code base if it appears to be useful. I mean, why share it at all if you don't want anyone else to use it?
|
| Previous - 1 | 2 - Next |
