Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
maxYMiser FM v1.67 Nowa wersja trackera.
Echa Forevera 23 Wyniki konkursów dla platformy Atari.
Atari Font Maker V1.16.14.4 Narzędzie do projektowania zestawów znaków dla Atari właśnie otrzymało aktualizację
Ruszyła strona Silly Venture 2k25SE Party place pozostaje bez zmian.
Zmarł mOdmate Zmarł mOdmate
atari.area forum » Posty przez drac030
Zapewne dlatego zapis nie jest tak szybki
Wniosek z tego płynie taki, że pierwszy lepszy TOMS jest lepszy od tego wynalazku. Chyba, że jeszcze uda się coś znaleźć, ale już mikey powyżej wątpił w możliwość wyciągnięcia ponad 57 kbps, jeśli procesor stacji jest taktowany na 1 MHz.
Aczkolwiek nie jest to cud, czego należało się spodziewać.
Program w normalu ładuje się na Twoim filmie w 9 sekund, a w turbo - w 5. Czyli 52 kbps. US *Doubler* się nazywa dlatego, że podwaja szybkość pracy stacji.
Może nie napisałem tego wystarczająco jasno, ale ja pod debuggerem sprawdzałem, jaki dzielnik jest przy szybkiej transmisji z I.S.Plate (emulowanym) ustawiony w liczniku Pokeya. Jest to $0a.
przez co przeplot staje się zbędny
Przydaje się przy zapisie.
nawet w reklamie podają prędkość x2, a x6 tylko w specyficznych warunkach
Czytałem manual. I szukałem owych "specyficznych warunków". Na razie bez skutku.
obstawiam podmieniony ROM kompa
To się posługuje protokołem US Doublera, cudów nie ma, ROM z patchem Hiasa albo SDX albo IDE+ powinny to obsłużyć. I obsługują - z indeksem 10.
Ponieważ się na tym zupełnie nie znam, tym łatwiej zatem przyjdzie mi się wypowiedzieć.
Nie mam I.S.Plate, ale Altirra to emuluje. W internecie da się znaleźć tak ROM stacji, jak i obrazy dyskietek z programami narzędziowymi. Pobawiłem się tym dzisiejszego wieczoru.
Ogólnie to działa jak podróba US Doublera: HS-index 10 ($0a), czyli 52 kbps. Odczyt leci właśnie z taką prędkością, ponieważ stacja ma buforowanie ścieżek.
Natomiast, w odróżnieniu od US Doublera i w ogóle wszystkich innych znanych mi stacji z jakimś turbo, nie znalazłem sposobu na sformatowanie dyskietki z szybkim przeplotem. Komenda formatowania z zadanym przeplotem US Doublera (f) nie działa, komenda formatowania z szybkim przeplotem XF-551 ($A1, czyli "!" w inwersie) zawiesza ten cały interes. Może istnieje jakaś specyficzna komenda tego rodzaju, ale jak dotąd jej nie znalazłem. Warp DOS 7.0 (który jest tanią przeróbką Atari DOS 2.0) też się niczym specjalnym tu nie posługuje, na polecenie "format" wydaje stacji zwykłe "!".
Obym się mylił, ale po tym, jak przez cały wieczór próbowałem się doszukać, w jaki sposób uzyskać owe mityczne 110 kbps (zakładając, że "118 kbps" oznacza w rzeczywistości HS-index 1 obliczony z jakimś niedużym błędem), zaczynam się obawiać, że zachodzi tu przypadek zupełnej pomyłki w obliczeniu szybkości transmisji.
Np. taki: bierzemy dzielnik $0A, liczymy go od 0, czyli wychodzi nam 11. W dokumentacji Pokeya wyczytujemy, że do wartości liczników należy doliczyć 4 (przegapiamy przy tym, że mamy licznik połączony, a wtedy trzeba doliczyć 7). Wychodzi nam 15. Przegapiamy też, że główny zegar trzeba podzielić przez dwa. Czyli: 1773446/15 = 118229,73 bity na sekundę. Rakieta.
W rzeczywistości zaś to jest 1773446/(10+7)/2 = 52160,17 bitów na sekundę = zwykły US Doubler.
Jak napisałem, obym się mylił :)
reloading disks is very slow
What do you mean exactly by "very slow"? Some reference below:
https://youtu.be/l7eot0MXoKQ (VBXE)
https://youtu.be/hbvAbkDCYdQ (no VBXE)
uh, i create new directory and directory MEDIA sorted correctly.. strange
Yup, that bug is not easy to trigger :)
yes, i now flash sparta dos to 4.49g and same results (i tried sorting, still same)
Hmm, it seems that even 4.49g is earlier than that fix (9 January vs 16 January).
Try this: use the SDX Imager and replace the sortdir.ovl file in 4.49g with the one attached here. Then flash the resulting ROM image and see if it helped.
I think that he means that the left panel is not sorted.
The sorting routine checks first if the directory is already physically sorted (by the same algorithm). There was a bug in it and that check sometimes returned false positives, which resulted, obviously, in a directory not being sorted.
That bug has been already fixed, I believe, almost 2 years ago. Any SDX version later than that should sort stuff properly (the sorting module is on the CAR device, not inside the Sparta Commander).
So the resolution is: update SDX to a revision later than January 2022, then report back, if the problem persists.
hmm, probadly i found a bug? dont know if is about sdx, or its about sparta commander
Confirmed. The real bug in the CAR: driver, but SC should not crash either.
It will get fixed for a next release. Thanks for the report.
No, dobra, były dwa miesiące wakacji, to teraz...
Урок третий.
To wejdźmy na wyższy poziom trudności:
Урок 2. Советский Союз, страна мира и достатка.
Саша и Алёша, два храбрых красноармейца, защищали цистерну спирта. И как-то случилось так, что она пропала. Командир спрашивает Сашу:
- Где спирт?
- Продали.
- Ну, а где деньги?
- Пропили.
Урок закончился юмором.
;)
A to nie jest tak, że u ruskich, "kto?" stosuje się do rzeczowników żywotnych, do których należy sabaka?
A акула (= rekin) nie należy?
Czy po rosyjsku nie pytamy jednak "что это", gdy nie chodzi człowieka?
Tak mi się mgliście kojarzy ze szkoły...
Profil podobno jest rosyjski, więc może być to i kalka.
Raczej ukraiński, ale pewnie jest tak samo...
No, raczej. BTW. "shark who ate" - czy to nie kalka z rosyjskiego? Jak кто это, это акула?
@mono: sęk ju, dankę, mersi boku.
Następuje nagły przeskok do wersji 0.9, ale nie pamiętam już dlaczego nie wypuszczałem 0.8.
Czy można prosić o zakomitowanie sam-Waszmość-wiesz-gdzie, a nadto zrobienie tego samego z pozostałymi playerami, gdyby były jakieś uaktualnienia od czerwca 2021?
Gratias de monte ;)
W rozdziale 23 załączonego PDF-a jest opisane, jak pisać sterowniki kernela.
@Lizard: właśnie chodzi o to, żeby zrobić forwarding z kernela SDX do tego "powszechnie znanego wejścia". Co do funkcji typu open/close/read/write/status, to nie problem. Ale co do XIO to, jak napisał mono, chyba się nie da, bo to się da zmapować tylko dla konkretnego sterownika, a nie dla wszystkich.
Szczerze powiedziawszy to nie wiem po co ten CPX jest, bo zapis $00 do PBCTL przed pętlą już powoduje zabezpieczenie stanów linii PB. Pewnie kolejna niekonsekwencja w XL OS.
No, w Rapidus OS-ie tego CPX-a nie ma i system działa :)
Zmiana trybu nie musi być wykonana rozkazem
Miałem na myśli przełączenie trybów w ramach 65C816. To przełączenie może i nie musi, ale jest realizowane rozkazem (XCE). To samo w sobie załatwia odmownie przedstawiony przez Piotrka pomysł ożenienia obu tablic rozkazów i zrobienia hybrydy.
Możliwe, że będzie hybryda tych procesorów, ale nie sprawdzałem dekoderów rozkazów i nakładania się ich, tak żeby np. zbudować 65C816 z illegalsami 6502C. Mogłoby być fajne, ale nie wiem czy możliwe.
Rozmawialiśmy już o tym i nie jest to możliwe, bo 65C816 ma wykorzystane wszystkie 256 opkodów z tablicy (ok, 255, bo 1 opkod jest zerezerwowany). Dajmy na to, opkody $xF, wszystkie nielegalne na 6502, na 65C816 są wykorzystane na tryby adresowania long abs ("długie", z 24-bitowym adresem, typu LDA $F00000).
Nawet gdyby zaryzykować rozróżnienie na tryb emulacji (z nielegalami) i natywny (bez), i tak jeden z opkodów musi być użyty do przełączenia trybu, zatem czciciele faktu, że kiedyś tam firma MOS Technology postanowiła zaoszczędzić kilka centów na krzemie per procesor i nie zrobić pełnego dekodera rozkazów, i tak będą płakać, bo ten jeden będzie działał inaczej. Poza tym nowe rozkazy - typu BRA, BRL, STZ, JSR (adr,X), TYX/TXY, PHX/PHY/PLX/PLY, BIT abs,X itp. - przydają się też, i to bardzo, w trybie emulacji. Dzięki temu, że działają zawsze, można mieć np. w systemie jedną procedurę SYSVBL działającą w obu trybach i jednocześnie korzystającą z nowych rozkazów, czyli zajmującą mniej czasu :)
Ogólnie, pomijając szczegóły, chciałbym napisać, że dla 65C816 i Atari jest całkiem dużo całkiem sprawnie działającej infrastruktury, z czego pewnie mało kto sobie zdaje sprawę. Istnieje rozszerzenie dla SpartaDOS X, które podłącza pamięć znajdującą się ponad adresem $FFFF do ogólnej mechaniki zarządzania pamięcią w SDX, a tym samym sprawia, że ta pamięć staje się widoczna dla loadera binarnego tego DOS-u. Tak samo działa obsługa błędów, symbole itp.
Można zatem, przy użyciu SDX, ładować programy bezpośrednio do wysokiej pamięci 65C816 i je uruchamiać. Działa to doskonale, póki co zostało najlepiej przetestowane z rezydentami rozszerzającymi funkcje SDX, ale zwykłe programy aplikacyjne też mogą z tego korzystać.
Jest asemblerek http://drac030.krap.pl/pl-elsa-pliki.php umiejący produkować relokowalne binaria dla SpartaDOS X, które można w ten sposób wykorzystać. Z przykrością nadmieniam, że MADS się do tego nie nadaje, bo np. nie generuje fixupów dla rozkazów typu JSL. Natomiast ELSA jak najbardziej. Pisałem w tej sprawie do tebego swego czasu, ale zostałem zignorowany - no trudno :)
W Brazylii krwawe sceny na ulicach to ponoć codzienna norma, więc co tu komentować - przecież obce kultury trzeba szanować i nie narzucać im po kołtuńsku własnych norm ;)
Natomiast znaczki Atari i koszulki Sikora są tam zapewne dużo rzadsze, więc temat potencjalnie ciekawy.
Ale OCB? Jacy nasi?
Na me oko główny bohater ma koszulkę z logo Atari, małym na lewej piersi, dużym na plecach. Podobne robił kiedyś Sikor.
... a raczej byli, o ile dobrze widzę:
Może to dla kogoś będzie nowość (ja się dowiedziałem przedwczoraj), że gość z Chile zrobił wersję TBXL, która część kodu ładowaną do głównej pamięci relokuje nad memlo.
Plus jest taki, że ?FRE(0), jak w starym TBXL pokazywał 34021, w tym nowym pokazuje odpowiednio więcej, np. u mnie 38556. Minus był taki, że trzeba było się nagimnastykować, żeby to się w ogóle uruchomiło, bo normalnie się nie ładował.
Miałem uwagi do tego stanu rzeczy, zostały uwzględnione, autor podrzucił nową wersję, która na oko działa.
W załączniku ta dzisiejsza wersja.
PS. Dely, dlaczego forum nie przyjmuje załączników z rozszerzeniem *.exe? Przecież egzek z wirusem dla Windows nie może się zaczynać od $FFFF :)
atari.area forum » Posty przez drac030
Wygenerowano w 0.143 sekund, wykonano 21 zapytań