651 Odpowiedź przez drac030

(316 odpowiedzi, napisanych Zloty)

W zdaniu koniunkcja logiczna, a godzina już późna ... ;)

Idź do forum: Zloty

652 Odpowiedź przez drac030

(316 odpowiedzi, napisanych Zloty)

Skoro tu tylu specjalistów od organizowania party, to może jeden z drugim zorganizuje coś samodzielnie? Będziecie wtedy mogli do woli ustalać treść regulaminu (to przywilej organizatora, coś mu się należy w zamian za wysiłek i ryzyko) zamiast, cytuję, "włazić z butami" w to, jaki pomysł ma na to ktoś inny?

Idź do forum: Zloty

653 Odpowiedź przez drac030

(21 odpowiedzi, napisanych Software, Gry - 8bit)

A i przy okazji, mam dodatkowy postulat/prośbę: mianowicie, żeby ewentualna nowa wersja xunzipa mogła opcjonalnie odgzipować plik tgz bez jego odtarowywania.

Idź do forum: Software, Gry - 8bit

654 Odpowiedź przez drac030

(316 odpowiedzi, napisanych Zloty)

Odpowiedź chyba jest prosta: jeśli produkcja będzie zgodna z regulaminem konkursu, to zostanie do niego dopuszczona. A jeśli nie, to nie.

Idź do forum: Zloty

655 Temat przez drac030

(21 odpowiedzi, napisanych Software, Gry - 8bit)

Mam na dysku dwa pliki tar.gz:

1) os.tgz, wielkość 75525 bajtów

2) 447e4.tgz, wielkość 1588401 bajtów

Oba mają podobną strukturę wewnętrzną, tzn. archiwum tar w jednym i drugim zawiera jeden podkatalog (odpowiednio os> i 447e>), a w nim są pliki.

Plik nr 1 pod xunzipem (v. 2.1) odpakowuje się bez szemrania, natomiast przy próbie odpakowania pliku nr 2 pojawia się na ekranie coś takiego:

Inflating D2:447E>
I/O Error 135

(przy czym ten ostatni numerek może też być 133, nie obczułem na razie, od czego to zależy).

Przy listowaniu zawartości archiwum os.tgz daje ładny listing bez żadnego szemrania, natomiast listing pliku nr 2 wygląda tak:

447E> (16782325)

a po dłuższym czasie:

1 Files (16782325)

chociaż tak naprawdę w archiwum jest 13 plików, a całość z pewnością nie ma długości 16782325 (czy cokolwiek to ma znaczyć), jeno ok. 4 MB.

Błąd jakiś czy trudności obiektywne?

Idź do forum: Software, Gry - 8bit

656 Odpowiedź przez drac030

(316 odpowiedzi, napisanych Zloty)

wieczor napisał/a:

dyskusja ... bezprzedmiotowa

Jewgienij Trollowicz Bezprzedmiotow to jeden z legendarnych patronów tego Kościoła ;)

Idź do forum: Zloty

657 Odpowiedź przez drac030

(316 odpowiedzi, napisanych Zloty)

mazi napisał/a:

opcja antyatarowska

Oj, przestalibyście już. Kościół Świętych Nielegali, cholera jasna, zrodzon, bo kiedyś jakiś koncern postanowił zaoszczędzić 5 centów na krzemie.

Idź do forum: Zloty

658 Odpowiedź przez drac030

(226 odpowiedzi, napisanych Bałagan)

swinkamor12 napisał/a:

cenzuruje się tu rzeczową dyskusję

http://sjp.pwn.pl/sjp/rzeczowy;2518591.html

Idź do forum: Bałagan

659 Odpowiedź przez drac030

(79 odpowiedzi, napisanych Fabryka - 8bit)

Będzie, będzie - release zaplanowaliśmy na przyszły tydzień.

Idź do forum: Fabryka - 8bit

660 Odpowiedź przez drac030

(79 odpowiedzi, napisanych Fabryka - 8bit)

Wymagałoby też napisania kilkunastu albo wręcz kilkudziesięciu pluginów do SC pełniących rolę modułów przeglądających. A i tak pewnie trzeba byłoby mieć do nich plik konfiguracyjny.

Teraz jest runext.cfg, a SC wykorzystuje istniejące programy, np. mona bmpview czy playery do muzyczek cmc itp. Miałby to wszystko dublować? To lekko bez sensu mi się wydaje.

@pin: Co do rotozoomera, potrzebujesz wersji podlinkowanej tu (post #5):

http://www.atari.org.pl/forum/viewtopic ... 10#p201710

Dla pewności: r3.exe, 32492 bajty, 19-01-2015 19:54

EDIT: oczywiście, że można się zapisać na betatestowanie...

Idź do forum: Fabryka - 8bit

661 Odpowiedź przez drac030

(79 odpowiedzi, napisanych Fabryka - 8bit)

Ten postulat, żeby SC pozwalał przesuwać kursor w panelu bez wciskania Control, słyszałem już parę razy. Moim zdaniem to nie będzie wygodne, ale OK, od następnej wersji w SC.INI będzie słowo kluczowe RVCTRL, danie RVCTRL=ON spowoduje, że przy naciskaniu klawiszy "-" i "=" na klawiaturze Atari klawisz Control będzie działał odwrotnie: tzn. bez Controla to będą kursory, z Controlem znaki "-" i "=".

Co do menu opcji, opcje w SC.INI są póki co cztery na krzyż, nie wiem, czy się opłaca kodować dla nich całe menu.

Skojarzenia plików, jak Pinokio napisał, moim zdaniem lepiej jest załatwić globalnie przez RUNEXT. Nie bardzo widzę, co stoi na przeszkodzie (zwłaszcza że RUNEXT działa też na Command Processor). Zresztą taka jest ogólna idea Sparta Commandera, żeby zdać się jak najbardziej na różne serwisy systemowe raczej niż je dublować.

Idź do forum: Fabryka - 8bit

662 Odpowiedź przez drac030

(79 odpowiedzi, napisanych Fabryka - 8bit)

Co do planów wydawniczych, nie tylko ode mnie to zależy. Ja osobiście wypchnąłbym już tę wersję, którą mamy, wydaje się, że jest dostatecznie przetestowana.

Co do tego, co nowego, trudno mi tak w jednym zdaniu to ogarnąć. Zmian w stosunku do 4.46 jest sporo: plik whatsnew-447.txt jest dwa razy większy niż whatsnew-446.txt. SC niestety nie jest jeszcze doprowadzony do końca, wiem, za długo to trwa, ale tak jakoś schodzi. Czy w FATFS.SYS już teraz będzie zapis, też trudno powiedzieć, w sumie nie jest to trudne, może się uda.

Idź do forum: Fabryka - 8bit

663 Odpowiedź przez drac030

(58 odpowiedzi, napisanych Bałagan)

Zapraszamy :)

Idź do forum: Bałagan

664 Odpowiedź przez drac030

(12 odpowiedzi, napisanych Programowanie - 8 bit)

Kod ASCII (w dec.) znaku pod kursorem.

Idź do forum: Programowanie - 8 bit

665 Odpowiedź przez drac030

(58 odpowiedzi, napisanych Bałagan)

as: PM.

Idź do forum: Bałagan

666 Odpowiedź przez drac030

(12 odpowiedzi, napisanych Programowanie - 8 bit)

Przeto trzeba skontaktować się z autorem. Mogę zdradzić w tajemnicy, że LIST "DPRN:" koniec końców wywołuje z ROM-u procedury obsługi drukarki te same, które woła LIST "P:".

Że LIST "DPRN" (bez dwukropka) tworzy plik na dysku, temu bym się nie dziwił.

Idź do forum: Programowanie - 8 bit

667 Odpowiedź przez drac030

(12 odpowiedzi, napisanych Programowanie - 8 bit)

OS sprawdza tylko pierwszą literę nazwy urządzenia, zatem LIST "PRN" = LIST "P:"

Tak poza tym, emulator?

Idź do forum: Programowanie - 8 bit

668 Odpowiedź przez drac030

(58 odpowiedzi, napisanych Bałagan)

seban napisał/a:

@draco: a "mowie nienawiści" to pogadamy jakoś na żywo, tak będzie rozsądniej.

Tylko kiedy? Na sztabach ani zlotach się nie zjawiasz.

Idź do forum: Bałagan

669 Odpowiedź przez drac030

(12 odpowiedzi, napisanych Programowanie - 8 bit)

Nie potwierdzam.

Spod TBXL:

DIR "DCAR:*.*"

Ewentualnie:

10 DIM A$(64)
15 OPEN #1,6,128,"DCAR:*.*"
20 DO
25     INPUT #1;A$:? A$
30 LOOP

Idź do forum: Programowanie - 8 bit

670 Odpowiedź przez drac030

(58 odpowiedzi, napisanych Bałagan)

Seban, ochłoń, trochę dystansu do świata nikomu nie zaszkodziło. Nie wiem, jak jest gdzie indziej, ale w tym wątku to Ty się nakręcasz, "mowa nienawiści" itd., to nie ma sensu.

Idź do forum: Bałagan

671 Odpowiedź przez drac030

(220 odpowiedzi, napisanych Sprzęt - 8bit)

Pin napisał/a:

Domniemam więc, że IDE+ ma totalną kontrolę nad własnym slotem carta

No, raczej. Z tego względu kiedyś proponowałem to http://www.atari.org.pl/forum/viewtopic.php?id=4736

Idź do forum: Sprzęt - 8bit

672 Odpowiedź przez drac030

(30 odpowiedzi, napisanych Bałagan)

Jeśli na liście dialogowej często występowały słowa "schneller, schneller", to mógł to być film o II wojnie światowej ... ;)

Idź do forum: Bałagan

673 Odpowiedź przez drac030

(20 odpowiedzi, napisanych Programowanie - 8 bit)

Programem w TBXL (działającym pod DOS-em).

Idź do forum: Programowanie - 8 bit

674 Odpowiedź przez drac030

(20 odpowiedzi, napisanych Programowanie - 8 bit)

Ok, zmierzyłem jeszcze raz:

1) seek z pozycji 0 na pozycję 16777215: 2,1 sek.
2) seek z pozycji 16777215 na pozycję 0: 3,36 sek.
3) odczyt 16777215 bajtów (porcjami po 8k): 4 min. 16,26 sek.

Sprzęt: Atari 65XE (6502/1,77 MHz/320k RAM), IDE+, SDX 4.47, partycja 32 MB w formacie Sparty.

Idź do forum: Programowanie - 8 bit

675 Odpowiedź przez drac030

(20 odpowiedzi, napisanych Programowanie - 8 bit)

Kiedyś to mierzyłem, seek (czyli "point") przez całą długość pliku o wielkości 16 MB na twardym dysku trwa oidp ok. 5 sekund. Odczyt tego samego pliku trwa ok. 3 minut.

Robisz błędne założenie, że "Sparta przelatuje od pierwszego bajtu do żądanego" - wcale nie. Przesunięcie następuje od bieżącej pozycji w pliku i DOS nie czyta przy tym danych pliku, a tylko jego mapę. Mało tego: nawet w formacie AtariDOS przesunięcie nie powinno wymagać przejazdu do początku, pod warunkiem, że przesuwamy się w kierunku końca pliku. Wszelkie próby cofnięcia się (na pliku zapisanym na dysku w formacie AtariDOS) spowodują taki efekt, jak mówisz.

Zasadnicza różnica polega na formacie dysku: w formacie SpartaDOS seek/tell działa optymalnie (niezależnie od kierunku przesunięcia), a w formacie AtariDOS - nie (i to wynika z natury tego ostatniego, jak wyżej powiedziano, żeby to obejść, trzeba indeksować pliki).

Idź do forum: Programowanie - 8 bit