Jeszcze jedno mi się przypomniało ... pisałem jeszcze jakieś narzędzia do grzebania w plikach binarnych... część nie mieściła się w na raz w pamięci, więc napisałem coś co się zwało "FILE DIGGER", otwierało toto plik binarny do odczytu... potem analizowało poszczególne segmenty i pytało się co z nimi robić... zapisać na wyjście, olać... zapisać do oddzielnego pliku, etc.  przy pracy z różnymi rzeczami powstała cała masa jakichś pomniejszych narzędzi, linkerów i programów generujących pliki binarne... wszystko to korzystało z możliwości otwarcia wielu plików jednocześnie wraz z odczytywaniem kolejnych wpisów z "directory".

EDIT:

Wcześniej zanim mnie SoTe spacyfikował i mnie przestawił na QA... używałem MAC/65 i on podczas kompilacji potrafił otwierać kilka plików jednocześnie z dysku jak miał dyrektywy include w kodzie. Często robiłem tak że w ramdysku miałem jakieś biblioteki swoje, potem include na początku programu... i miałem większy bufor na swój głowny kod. MAC/65 był i tak nie do pobicia jeżeli chodzi o ilość kodu która mieściła mu się w pamieci... tokenizował to co się pisało... kompilator był ultra-szybki, ale edytor był koszmarny (jak w Atari BASIC)... do tego pliki które generował ... ojć... ich struktura była pomyłką... generował segmenty po 253 bajty...

Przez to musiałem napisać specjalnego tool-a do scalania takiej binarki aby zamiast np. czterdziestu 253-bajtowych segmentów został wygenerowany jeden ciągły :D

ps) Laoo... mega sorry za giga offtopic :)

1) RTS jak najbardziej OK, to jedyna dopuszczalna metoda wyjścia z INIT-a... mam nadzieję że nie zostawiasz po INIT nic na stosie.

2) $2000 jest jak najbardziej OK...  przy My-DOS (4.53/4) skonfigurowanym z 4-rema buforami... memlo wynosi $1FE8... więc Twój kod ładowany od $2000 jest bezpieczny.

Niech Pasiu sprawdzi jakie ma Mem-LO,   ew. jak jest powyżej $2000 niech wywoła opcję "O" z menu My-DOS, potem RETURN i dalej jak na screen-ie poniżej...

po tej operacji Mem-LO powinno wynosić $1DE8.

Hej!

Nie znałem tej metody, gdy bawiłem się w moje "fly dots", robiłem to metodą dość prymitywną i brutalną... smarowałem wszystko co się dało na ekranie graficznym... czyściłem ekran również metodą "brute force" :P ... pierwsze próby bez żadnych optymalizacji o dziwo "wyrabiały się w ramce", jednak efekt wizualny jaki osiągnąłem nie zachwycał mnie zbytnio... sprawę więc szybko porzuciłem nie mając pomysłu jak to wykorzystać... niby chciałem zrobić  z tego scroll-a... zamieniając po drodze grafikę na "fonty", ale jakoś chęci i motywacji zabrakło... wspominajac to wszystko, zajrzałem nawet do bardzo starych dyskietek z QA, które o dziwo się przeczytały... więc pozwalam sobie załączyć te wypociny... jednak darujcie zanęcanie się nade mną za "jakość" i "szybkość" tego kodu ;-) to naprawdę stary kod (z czasów Code3, czyli wczesne lata '90), do tego wszystkiego jestem prawie pewien że miałem jeszcze ten sam kod właśnie wzbogacony o scrolling (na grafice) zamiast "samych latających kropek", ale nie mogę tego znaleźć... tak czy inaczej można to napisać o wiele efektywniej, nawet wykorzystując ekran graficzny :) więc jeżeli ktoś zechce sobie zrobić z tego oldschool-owy scroll, czemu nie :]

Format QA, z użyciem "dta c' ' oraz Atari control-characters", a więc skompiluje to chyba tylko QA. A może ktoś popełnił konwerter? ;) Do obejrzenia źródeł na PC w formacie ATASCII proponuję użyć: Memopad ( http://joyfulcoder.com/memopad/ )

Tego typu "concept idea" czy inne efekty w tamtych czasach pisałem i testowałem bezpośrednio pod QA, asemblując do pamięci oraz uruchamiając z poziomu QA. W tym wypadku wystarczy zmienić OPT na %00010101 i do tego ustawić "MemHi" na $A000 i RUN na $480. Po czym wykonujemy assembly a następnie RUN... efekt uruchamia się bez problemu bezpośrednio z poziomu QA.

Na koniec pliki o których była mowa wyżej:

1) plik ATR zawierający DOS II+, QA oraz źródła i plik .OBJ dostępne tutaj: fly_dots.atr
2) źródło do wglądu (format QA, ATASCII -> na PeCe użyć MemoPad R9 do podglądu) tutaj: fly_dots.asm
3) do kompletu jak ktoś na szybko chce sobie to uruchomić pod emulatorem plik XEX tutaj: fly_dots.xex

ps1) koncepcja względnej szybkości tego efektu polegała jedynie na tym że de-facto nie tam tam żadnej procedury PLOT, a stawiania pixela odbywa się jedynie przy pomocy jednego STA. Założenie jest takie że zawsze zapalony jest tylko jeden bit w obrębie bajtu i ruch punktu odbywa się jedynie w obrębie tego bajtu, w zależności od wartości zapisywanej na ekran (ustawiony tylko jeden z bitów) zmieniamy pozycję poziomą pixela z zakresie 0..7. Ruch w pionie odbywa sie na podstawie tablic adresów. A rysowanie każdego pixela z osobna polega za zapisywaniu innego bajtu z wykorzystaniem trybu indeksowego sta (adr),y gdzie rej. Y zawiera tak naprawdę nr. bajtu (w tym wypadku również pixela). Całości dopełniają dwie pre-kalkulowane wcześniej (Turbo Basic XL) tablice sinusów, dzięki którym uzyskujemy ciekawy wizualnie kształt poruszania się pixeli. To tak w wielkim uproszczeniu.

ps2) poszukam jeszcze jakichś źródeł logo-scrolla z użyciem ring-buffer. Jak coś sensownego znajdę to zamieszczę również tutaj.

Oj... ileż to ja się RAM-u "naprzepisywałem" w początkowej fazie nauki kodowania :D ileż to czasu CPU zmarnowałem na przepisywanie tych ton bajtów we wszelakich logo-scrollach :D dopiero jak poznałem SoTe to bardzo szybko mnie uświadomił że jest inna metoda :D

Moja nauka w tamtych czasach polegała na podglądaniu jak to zrobili inni... uwierz mi... 90% produkcji z logo scroll-ami przepisuje jak tylko może gdy HSCROLL osiągnie wartość końcową :-)

Gepard, jeszcze raz dzięki za ten cały stuff! Nie wiem jak przetrwał, ale dzięki za wyłowienie tych wszystkich programów.

ps) w ostatnich linkach brakuje .pl w nazwie domeny

Dzięki Mono! Dzięki twoim narzędziom w połączeniu ze Sparta DOS X powstaje całkiem ciekawe i wygodne środowisko do pracy :)

Mimo że nie byłem na party uważam że Grey wykonał niesamowitą, niepojętą wręcz dla mnie pracę. To jest fenomenalne że udało się zebrać tak wielu ludzi, zorganizować tak duży event. Pełen szacunek z mojej strony i wielkie wyrazy uznania. Szkoda że nie miałem możliwości uczestniczyć w tym zlocie.

Pozostaje jeszcze sprawa AD6502 i ogromnego zamieszania jakie się w związku z tym wydarzeniem stało, i przyznam że miałem nic nie pisać bo nie mam jakby żadnego prawa do oceniania tego całego zamieszania jeżeli chodzi o demo AD6502, ale zauważyłem przez przypadek jedną rzecz, gdy oglądając to demo w momencie gdy dojdzie się do końca pierwszej strony dysku i pojawia się screen zoom-rotatorem i napisem "flip disk and start", i gdy np. nie zmienimy dyskietki (nadal zostanie w stacji strona A, co też uczyniłem przez swoją pomyłkę), demo czyta sektor 361, robi się czarny ekran i następuję totalna "zwiecha", bardzo mnie to zainteresowało i dlatego postanowiłem zajrzeć do kodu.

Wspominana część dema, tuż po wciśnięciu start wykonuje parę akcji, ale to co ważne załączam poniżej:

org $52BF

jsr $82a ; xBIOS_SET_DEFAULT_DEVICE
jmp $608 

...

org $0608

LDA $00          ; [$00] = $33
CMP $00          ; [$00] = $33
BEQ $060A        ; wait for VBL (own NMI routine do INC $00)

; back to Atari OS-ROM

SEI                    
LDA #$00
STA NMIEN        ; [$D40E]
STA DMACTL       ; [$D400]
STA IRQEN        ; [$D20E]
STA $0BEA        ; [$0BEA]
LDA #$FF
STA PORTB        ; [$D301]
LDA #$00
STA SDMCTL       ; [$022F]
LDA #$5F
STA VVBLKI       ; [$0222]
LDA #$62
STA VVBLKD       ; [$0224]
LDA #$E4
STA VVBLKI+1     ; [$0223]
STA VVBLKD+1     ; [$0225]
LDA #$40
STA NMIEN        ; [$D40E]
CLI
LDA RTCLOK+2     ; [$14] = $67
CMP RTCLOK+2     ; [$14] = $67
BEQ $0641
LDX #$06         ; > file_name
LDY #$4C         ; < file_name
JMP $0806        ; xBIOS_LOAD_FILE

...

org $64c

 dta c'ARS2PRT3   '

i teraz zaczynając analizy kodu, jak widać gdy xBIOS_LOAD_FILE się nie uda (np. nie znajdzie na dyskietce pliku o nazwie "ARS2PRT3", demo pójdzie totalnie w krzaki, powrót z xBIOS_LOAD_FILE prowadzi donikąd, (bo to powrót z JMP $806).

Wynika z tego że koder założył że nie nastąpi żaden błąd odczytu i że w stacji znajdzie się odpowiednia dyskietka. Jeżeli się nie znajduje rozumiem że xBIOS_LOAD_FILE wraca (RTS) z kodem błędu, tyle że po JMP $806 nie ma gdzie wracać i demo idzie w krzaki.

A co się stanie jeżeli w trakcie xBIOS_LOAD_FILE nastąpi jakikolwiek inny błąd (CRC, BAD sector, SIO overrun, czy framming error?).  XBIOS będzie próbował odczytu do skutku czy wróci z jakimś kodem błędu?

Przy realnym hardware jest to jak najbardziej możliwa sytuacja, nawet długość kabla czy leżący obok tel. komórkowy (EMI) czy inne urządzenie może mieć wpływ na transmisję po kablu SIO, nie mówię już o fizycznych problemach z nośnikiem.

Dlaczego o tym wszystkim pisze? Ponieważ uważam że mogło się stać coś nieprzewidzianego, nawet przy użyciu SIO2SD. I cały flame o to co się stało nie ma najmniejszego sensu.

@XTD: dzięki za fenomenalną muzę! :) Miło usłyszeć zupełnie inny styl niż obecnie panujące na scenie! :)

Hej!

A nie może być RIP? Jeżeli tak to proponuję zajrzeć do:

...\mads\examples\graphics\rip\

Co do zdjęć elektroniki... mam to na co dzień w pracy... czasami mam tego dość niestety. Nigdy nie szukałem w sieci takich materiałów... raczej będąc ciekawy co jak działa, rozbierałem wszystko na części i przyglądałem się na żywo :)

ostatnie poprawki w toku... problemy z poziomem sygnału na Line-IN zostały rozwiązane.

Wysłałem Ci e-mail przez formularz Atari Area, daj znać.