Szkoda.
Zadanie: dokonać rotacji w lewo bloku "len" danych zaczynającego się we "from"; wynik umieścić w "to"

0: to+len=0                                      ;clear bit shifted into end of buffer (1 if bit should be set)

1: mode=0, and=$00, xor=$7f, src=xxx, dst=to     ;fill buf with $7f
2: mode=1, and=$80, xor=$00, src=from, dst=to    ;copy $80 to buf when source value has highest bit set
3: mode=2, and=$00, xor=$81, src=xxx, dst=to     ;buffer contains shifted out bits shifted into lowest bits
4: mode=2, and=$ff, xor=$00, src=from, dst=to+1  ;add
5: mode=2, and=$ff, xor=$00, src=from, dst=to+1  ;add

Wynik operacji znajduje się w "to"+1.
"from" nie jest modyfikowany.
"to" powinien mieć rozmiar o 1 bajt większy niż "from".

Jeśli dobrze liczę VBXE będzie realizować rol pojedynczego bajtu w 7/8 cykli (czy można by prosić o diagramy dla operacji blittera tak, żeby można było sobie precyzyjnie policzyć czasochłonność blitów).

Edit: styl

Pięknie gra.

A jakie ma znaczenie czy dodatki robi firma macierzysta (która nota bene nie istnieje, bo zbankrutowała) czy firmy trzecie? Cały pece opiera się na działalności firm trzecich. Kto kupuje IBMa?

Otóż to. Co prawda Atari Inc i Atari Corp już nie ma, ale sprzęt żyje, a więc się też i rozwija dzięki inicjatywie prywatnej. Właśnie montuje się rozwojowe wersje procesora do maszyny, projektuje rozszerzenia (pamięci, grafiki, dźwięku, urządzenia io), więc jeśli ktoś chce żeby jego programy działały na 8086 z magnetofonem, to jego sprawa.

Patologika.

Jakże się myliłem. Czy mógłbyś podesłać te atry? Sprawdzę co się dzieje.

Edit: Kompatybilność na poziomie wpisów w katalogu jest zachowana - inne nieco jest vtoc, no i linki 16-bitowe w sektorach (to moje usprawiedliwienie :P, ale fakt jest faktem - Franny nie pokazuje wpisów).

Duże dyski MyDOS zakładają nieco inny system plików niekompatybilny z AtariDOS. MyDOSa obsługuje mój ataridosfs i xedisk, Franny tego niestety nie potrafi :/

Zasysamy tak:

$ cvs -d:pserver:anonymous@atari8.cvs.sourceforge.net:/cvsroot/atari8 login
$ cvs -z3 -d:pserver:anonymous@atari8.cvs.sourceforge.net:/cvsroot/atari8 co -P franny

Przy logowaniu podajemy puste hasło. Kod franny znajdzie się w podkatalogu franny.
To wszystko opisane jest o tu.

Edit: A pacza to już standardowo:

$ patch -p0 <franny-20140107-sdx2x512bps.diff

Dodałem support dla:
- 512b sektorów .ATR,
- wersja 2.1 SpartaFS,
- atrybut A w listingu.
Paczowałem wersję z CVS z dnia 7 I 2014 (jak sama nazwa pacza wskazuje).
To szybka poprawka i może nie najlepsza, ale jak na razie zachowuje się poprawnie :) więc jakby komuś się przydało to proszę bardzo.

Edit: Atrybut.

W programach relokowalnych dla SDX potrzeba czasem znać indeks bloku (w pliku), w którym znajduje się obiekt (procedura, dane).
Czy w związku z tym można by mieć możliwość np. nazywania bloków za pomocą etykiety:

kod1: blk reloc main
  ...
kod2: blk reloc extended
  ...

dzięki temu mógłbym sobie adresować tablicę EXTENDED+3 w taki sposób:

  lda EXTENDED+3+kod1
  jsr JEXT_ON
  ...
  jsr JEXT_OFF

  lda EXTENDED+3+kod2
  jsr JEXT_ON
  ...
  jsr JEXT_OFF

co gwarantowało by mi dostęp do odpowiedniego bloku pamięci.

Problematyczne jest też wykorzystanie blk empty, ponieważ rzadko zachodzi potrzeba rezerwacji pojedynczego bufora, jako osobnego bloku pamięci (tym bardziej, że loader ogranicza ilość bloków relokowalnych), a bardzo często pojedynczy blok empty dzielony jest na kilka różnych buforów lub zmiennych. Czy można by dodać taką konstrukcję:

  blk empty main/extended/$xx
dane1: .ds 20
dane2: .ds 30
adres: .ds 2

która generowałaby odpowiedni blok empty (pojedynczy). W połączeniu z nazywaniem bloków blk pozwalałoby to na ładny dostęp do pamięci w programach dla SDX.

Edit: Oczywiście nie upieram się przy etykiecie - może to być nazwa bloku deklarowana np:

blk empty main/extended/$xx nazwa
blk reloc main/extended/$xx nazwa

czy jak by tam było wygodnie.