| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Drivecode
Hi guys,
finally i wanted to give drivecode a try, but the transfer is the bottleneck (and 2kb of memory sucks as well). Actually i only would push this further if transfer of two bytes is seriously faster than 154 cycles, as that is what i need to transform one vertice, what i thought of offloading to the drive. I'd love to also implement backface-culling within the drive, but that seems to be mostly impossible due to lack of memory (assumed we do more complex stuff than a cube).
So what i do so far is on c64 side:
-
lda $d012
sbc #$31
bcc +
clc
and #$07
beq -
+
lda #%00001011
sta $dd00
nop
eor #%00001000
sta $dd00
lda #$ff
eor $dd00
lsr
lsr
eor $dd00
lsr
lsr
eor $dd00
lsr
asr #$fe ;lets carry be cleared after lsr!
eor $dd00
And on 1541 side:
!align 255,0
bin2ser
!byte %1111, %0111, %1101, %0101, %1011, %0011, %1001, %0001
!byte %1110, %0110, %1100, %0100, %1010, %0010, %1000, %0000
ldx #$0f
sbx #$00
lsr
lsr
lsr
lsr
sta .y1+1 ;keep y free
lda bin2ser,x
-
ldx $1800
bpl -
sta $1800
asl
and #$0f
sta $1800
.y1 lda bin2ser
sta $1800
asl
and #$0f
sta $1800
Any idea how to get this reasonably faster? I'd also be okay if just bit 0-6 are transferred form each byte, but that does not seem to help much, as bit 6 and 7 are the last in the transfer. I also thought of doing a burst of two bytes per sync, but that did somehow not work as i get jitter into the second byte then :-(
Bitbreaker |
|
... 19 posts hidden. Click here to view all posts....
|
| |
The Human Code Machine
Registered: Sep 2005
Posts: 110 |
I wouldn't do the scrambling inside the transfer loop. Just calculate your stuff using the floppy, scramble the data, sync with the c64 and then burst all data to the c64 as fast as possible. |
| |
Fresh
Registered: Jan 2005
Posts: 101 |
Quote:
Everything saving cycles on the c64 side should be highest priority.
@THCM
I didn't quite understand immediately what you meant.
You're definetly true: there's no point in wasting cycles during the transfer in something that can easily be done beforehand.
@Bitbreaker
Maybe the problem is the fact that you need to get little pieces of data at a constant (high?) pace. It mainly depends on the data size and frequency that you're expecting on c64 side.
If you think you can do a big burst on a per-frame basis, then follow THCM advice. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Well, i could scramble the data to be transfered on the 1541 as the 1541 is ready with its calculations more than in time. I'd do things in software however, using big tables is not an option, i'd anyway need every single byte on the 1541 for my calculations. This way i could indeed save a bunch of cycles on a single transfer and also burst without long preparations.
|
| |
The Human Code Machine
Registered: Sep 2005
Posts: 110 |
Shouldn't it be possible to take over the whole 2kb of memory when using custom transfer routines? You could use the whole zeropage for selfmodifying code etc. and the complete stack. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
$100 squaretables
$100 sine/cosinetable
$100 table for perspective correction
$156 bytes for vertices (no indexes for faces yet)
$e4 bytes for the resulting data (stored in zeropage)
and then there still some code for doing the caluclations and transfer. So it'll getting tight :-) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: $100 squaretables
$100 sine/cosinetable
$100 table for perspective correction
$156 bytes for vertices (no indexes for faces yet)
$e4 bytes for the resulting data (stored in zeropage)
and then there still some code for doing the caluclations and transfer. So it'll getting tight :-)
$156 bytes for vertices for ONE object? If it's for many objects then simply upload new vertices when you switch object to save memory in the drive (to save max space, simply reset the drive to get the original transfer routines back and upload the whole shit again but with a different object).
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 500 |
Yes, for ONE object :-) As you can read in my first post: "(assumed we do more complex stuff than a cube)"
If it is all just about a cube, i would not bother at all, done that already in my last demo, and optimized that for the codebase64 example.
However i just managed to get the transformation even faster (128 cycles per vertice) so now drivecode is even gaining less compared to doing all stuff on the c64 :-) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quoting JackAssersimply reset the drive to get the original transfer routines back
That's a bad idea, since old 1541's will do a head bump on reset which is quite unhealthy + noisy and will cause a deadlock when the serial bus is accessed during that time. |
| |
tlr
Registered: Sep 2003
Posts: 1723 |
Quote: Quoting JackAssersimply reset the drive to get the original transfer routines back
That's a bad idea, since old 1541's will do a head bump on reset which is quite unhealthy + noisy and will cause a deadlock when the serial bus is accessed during that time.
Which revision is that? I can't remember that from my long board 1541 but perhaps I've stuck a non-standard ROM in there. Can't remember. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11136 |
isnt it just the 1541-II that does that crap on reset? |
| Previous - 1 | 2 | 3 - Next |
