oki, mialem teraz troche wiecej czasu i teraz napisalem troche inna implementacje tego rozkazu (wczesniej jedynie zoptymalizowalem twoj kod bez zmiany koncepcji)

jesli jest tak jak mysle, tzn ten rozkaz powoduje skopiowanie BC bajtow z HL do DE. to cos takiego powinno dzialac znacznie szybciej:

    ldx z80_b
    bne l2
; B=0 wiec kopiujemy C bajtow
    ldx z80_c
    beq end
    ldy #0
l1    lda (z80_hl),y
    sta (z80_de),y
    iny
    dex
    bne l1

    clc
    tya
    adc z80_l
    sta z80_l
    bcc *+5
    inc z80_h
    clc

    tya
    adc z80_e
    sta z80_e
    bcc *+4
    inc z80_d

    stx z80_c ; B juz jest zero!
end    rts ; koniec

; B>0 wiec kopiujemy conajmniej B*256bajtow
l2    ldy #0
l3    lda (z80_hl),y
    sta (z80_de),y
    iny
    bne l3
    inc z80_hl+1
    inc z80_de+1
    dex
    bne l3

; ok mamy juz skopiowane B*256bajtow, zostalo nam do
; skopiowania jeszcze C bajtow
    ldx z80_c
    beq end2
l4    lda (z80_hl),y
    sta (z80_de),y
    iny
    dex
    bne l4

    clc
    tya
    adc z80_l
    sta z80_l
    bcc *+5
    inc z80_h
    clc

    tya
    adc z80_e
    sta z80_e
    bcc *+4
    inc z80_d
 
    stx z80_c
end2    stx z80_b
    rts ; koniec

wzrost szybkosc polega na tym ,ze w tej wersji, fragment kodu:

        tya        
        adc z80_l
        sta z80_l
        bcc _ed_b01
        inc z80_h
        clc

_ed_b01 tya
        adc z80_e
        sta z80_e
        bcc _ed_b02
        inc z80_d
        clc

jest wykonywany tylko raz a u ciebie o ile sie nie myle bedzie wykonywany B+1 razy...

to samo tyczy sie tego fragmentu:

_ed_b02 lda z80_b
        beq _ed_b04    ; koniec
        dec z80_b
        dex
        jmp _ed_b05    ; kopiuj

ktory w mojej wersji juz nie jest potrzebny (dokladnie wiemy ile skopiowac bajtow juz na samym poczatku, wiec po co sprawdzac to, co kazdy obieg petli)

no i dla B<>0 petla kopiujaca jest o 2cykle szybsza (nie potrzebujemy tam instrukcji DEX bo wiemy, ze kopiujemy wielokrotnosc 256bajtow)

EDIT: na upartego, mozna by to przyspieszyc dla B<>0 np. tak:
petle:

l2    ldy #0
l3    lda (z80_hl),y
    sta (z80_de),y
    iny
    bne l3

mozna troszke rozpisac:

l2    ldy #0
l3    lda (z80_hl),y
    sta (z80_de),y
    iny
    lda (z80_hl),y
    sta (z80_de),y
    iny
    lda (z80_hl),y
    sta (z80_de),y
    iny
    lda (z80_hl),y
    sta (z80_de),y
    iny
    lda (z80_hl),y
    sta (z80_de),y
    iny
    lda (z80_hl),y
    sta (z80_de),y
    iny
    lda (z80_hl),y
    sta (z80_de),y
    iny
    lda (z80_hl),y
    sta (z80_de),y
    iny
    bne l3

petla nierozpisana wykonuje sie: (5+6+2+3)*256=4096cykle
petla rozpisana(8razy) wykonuje sie: (3 + (5+6+2)*8)*32=3424cykle
nalezy pamietac, ze petla musi byc rozpisana N razy, gdzie N to potega dwojki, wiedz np. jak rozpiszesz to 10razy to nie bedzie dzialac poniewaz warunek "bne" bedzie sprawdzany nie w tym miejscu co powinnien

jesli na poczatku wczasie odczytywania nazwy pliku sa czarno-biale paski, a w momecie wczytywania danych kolorowe to jest to Turbo 2002 znane takze jako Turbo 2000F.

pare miesiecy temu kopiowalem pare rzeczy wlasnie z tego turbo na grzyba przez SIO2PC. Wkladalo sie do emulowanej stacji dyskow przez SIO2PC dyskietke z kopierami turbo (byly w bazie plikow na atari area). odpalalo sie odpowiedni kopier i juz mozna bylo bezklopotu wczytywac dane zapisane w systemie KSO Turbo a potem to zapisac normalnie na ATR'a (nalezalo przy tym pamietac ,ze magnetofon turbo to bylo urzadzenie T: a nie D: )

jesli SV wypali w tym roku to oczywiscie sie pojawie ;)

dzieki wielkie za uwagi...
ciesze sie, ze gra wam przypadla do gustu ;)

z tego co widze ,to duzo osob zwrocilo uwage na zbyt wolna akceleracje ruchu - oki postaram sie to zmienic w nastepnej wersji oraz wygladzic bardziej skok...
a co do czarno-bialych przerywnikow to tez mysle ,ze Powrooz sobie poradzi ;)

jest to wersja testowa, wiedz level mial byc z zalozenia troche trudniejszy, oczywiscie w wersji finalnej, poczatkowe levele beda o wiele latwiejsze niz aktualny...
co do klopotow ze skakaniem, to jest to raczej kwestia oswojenia sie ze sterowaniem, wystarczy skakac z rozpedu a nie z miejsca ;)

PM overlay o ktorym wspomnial XXL raczej ciezko bedzie tutaj uzyc - sprajty raczej zawsze beda wykorzystane jak nie na przeciwnika to na bonus... jedyne czego teraz zaluje to to, ze troche nie pomyslalem, i nie zwrocilem uwagi Powroozowi ,zeby ograniczyl wysokosc sprajtow do 16pixeli, wtedy mozna by bylo rozmiescic bezklopotu 2razy wiecej sprajtow na ekranie i PM overlay byl by wtedy bardzo uzyteczny...

jesli chodzi o termin ukonczenia gry, to mysle ,ze niewczesniej niz za 4-5miesiecy... teraz wiekszy priorytet dla nas ma nowe demo, ktore mamy zamiar wystawic na Forever 2k7, aktualnie jeszcze zaczelismy myslec nad jeszcze jednym demem na Silly Venture (o ile bedzie)...

1. ok 12-13 lat
2. Bajtek (glownie Atari Basic)
  Asemblera 6502 nauczylem sie z Commodorowskiego Maga: http://www.ffd2.com/fridge/chacking/ oraz z ksiazki "programowanie processora 6502" - autor nieznany bo nie mam okladki 8-)
3. asm6502, asmx86, c/c++, pascal/delphi, php
4. aktualnie nie (jeszcze studiuje)
5. Bloodshed Dev-C++ dla programow w C/C++, wbudowany Notatnik do reszty (asm/php/html), jesli chodzi o kompilatory 6502 to mads/xasm

hmm ale odczytanie wielkosci plikow przez katalog dyskietki tez nie jest pewne, bo rozne dosy inaczej "sformatuja" dane wyjsciowe: np. w MyDos wygladaja one tak: "  DOS45678SYS 037", a w SDX wyjscie bedzie wygladalo tak: "DOS45678 SYS   4736" co juz jest problemem, nie wspominajac juz o tym ,ze w pierwszym przypadku mamy dlugosc podana w sektorach a w drugim dlugosc podana w bajtach...

jak juz Fox wspomnial jedyna pewna metoda chyba bedzie odczyt pliku w calosci...
szkoda bo mialem nadzieje ,ze w czasie wykonwyania operacji OPEN, jest pobierana dlugosc pliku i gdzies zapisywana...

jeszcze jedno lamerskie pytanie ;)

powiedzmy ,ze chce wczytac caly plik, robie cos takiego:

    ldx #$10
    lda #7
    sta iccmd,x
    lda #0
    sta icbufa,x
    lda #$80
    sta icbufa+1,x
    lda #$ff
    sta icbufl,x
    lda #$ff
    sta icbufl+1,x
    jsr ciomain

po tym jest wszystko pieknie, pod $8000-$xxxx mam wczytany caly plik, tylko skad mam wiedziec ile zostalo wczytane bajtow? ;)
wczytywanie pliku bajt-po-bajcie (icbufl=0) daloby mi prawidlowa odpowiedz, ale to raczej bardzo kiespki sposob ze wzgledu na szybkosc...

tak sie przy okazji zapytam ;)
Solo z jaka czestotliwoscia mniej wiecej sa probkowane te sample, ktorych uzyles w "pmix.sap" i "new_ps1.sap"?
bo na sapplayerze nie widac zbytnio - pokazuje IRQFREQ ~50-200hz a w momecie grania sampla pewnie jest duuuzo wiekszy ;)
bo tak sie zastanawiam czy przy czestotliwosci ~1500Hz sample by wogole brzmialy? bo jesli tak to mozna by bylo bez zadnego obciazenia procka grac je z taka czestotliwoscia w demach :)

http://www.c64hq.com
http://www.gamebase64.com
http://www.lemon64.com

twh just run those demos on emulator and turn stereo mode on in it. if u hear sound in only one speaker then that demo don't support stereo, otherwise it do ;)

mam pytanie: jak podpunkt drugi regulaminu ma sie do przerywan np. DL? sa dozwolone czy nie?

manta.univ.gda.pl/~pwisnie/rotate.zip

tu jest przyklad, ktory obraca dowolna ilosc punktow - dla uproszczenia nie ma tam dzielenia przez 128 oraz jest obliczana tylko wspolrzedna X:
x'=M1*vx +  M2*vy + M3*vz

dane sa takie:
M1=$32 M2=$7e M3=$55
vertexnum=1
vx[0]=$01ab vy[0]=$0564 vz[0]=$ff72

M1*vx=$005366
M2*vy=$02a738
M3*vz=$ffd0da

cos zle oblicza M3*vz - wychodzi $fed0da a powinno byc $ffd0da...
zmienilem takze procedure mnozenia tak aby nie korzystala z rejestru X, ktory jest uzywany jako licznik aktualnego wierzcholka...

nie jest to oczywiscie na maxa zopytmalizowane, jak wroce wieczorem to sie jeszcze pobawie ;)

PS: nie wiem czemu, ale najnowszy MADS zle to kompiluje - aktualny przyklad sie wysypuje, dlatego radze go kompilowac starsza wersja (ta dolaczona do archiwum)

o kurde sorki Eru, pomylilo mi sie, oczywiscie chodzilo mi o Twoj pomysl ;)