Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Jak napisać grę na Atari - cz. 8 Premiera ósmej części popularnej serii poradników Larka o tworzeniu gier na Atari już 28 lipca!
TONY - Ark of the Covenant Kontynuacja przygód Tony'ego na Atari 8-bit, bez przemocy, z naciskiem na spryt i eksplorację.
ABBUC Software Contest 2025: Zgłoszenia Sprawdź aktualną listę programów zgłoszonych do konkursu ABBUC Software Contest 2025. Termin mija 31 lipca!
Gopher2600 0.50.0 Nowa wersja emulatora Atari 2600 z usprawnieniami i nowymi funkcjami debuggera.
Steem SSE 4.2.0 już dostępny Nowa wersja emulatora Steem SSE z istotnymi usprawnieniami i nowościami
Opcje wyszukiwania (Strona 30 z 68)
Właśnie... wg mnie też tam nic nie siedzi... a powinno. I pytam właśnie co wg Was powinno tam siedzieć.
Zgodnie ze specyfikacją, użądzenie USB powinno informować hosta o poborze prądu i z tego, co wyczytałem, jeśli podłącza się wtyczkę USB tylko po to by pobrać z niej 5V powinno się także poinformować hosta, że pobiera się z tego gniazda prąd, choćby po to by scalak sterujący orientował się jaki ma pobór obsługiwanych jednocześnie gniazd. Stosuje się do tego chyba dzielnik podpięty do obu linii danych....
Nie, no to to ja wiem a nawet jest taniej ( http://www.allegro.pl/show_item.php?item=845171810 ), ale przy tej cenie to może być niezgodnie ze standardami wykonany, a ja będę się podpinał pod dwa gniazda USB w dwóch urządzeniach (będą miały wspólną masę, ale zasilacze wewnątrz maja już niezależne .... zwieraliście kiedyś wyjścia dwóch zasilaczy? :) )..... i jakoś mam obawy co do tych kabelków.
Poszukałem już w necie i dalej niewiele wiem.
A chodzi mi o to jak w środku połączone są wtyczki kabelka stosowanego czasami do podłączania przez USB urządzeń pobierających prąd większy niż 500mA (np HDD 2,5"). Są to kable, które wtyka się jednocześnie do dwóch gniazd. Z jednego bierze sygnały i zasilanie, a z drugiego ciągnie samo zasilanie.
No i teraz zagwozdka.... czy te kable pracują "na zwarciu" ??? To znaczy po prostu maja zwarte sygnały GND i VCC (5V) z obu gniazd? Jakoś osobiście puściłbym to przynajmniej przez diody (oczywiście można zakładać że oba gniazda są w jednym hoscie i i tak mają w środku zwarte zasilanie, ale jakoś nie lubię tego typu założeń). A do tego wydaje mi się, że zgodnie ze specyfikacją trzeba poinformować jakoś hosta USB o tym, że coś jest do niego podłączone (przez spolaryzowanie linii danych, albo coś w tym stylu). W związku z tym powinno być tam chyba ze 4 rezystory i 2 diody minimum....
Może ktoś z Was ma więcej wiedzy i mi pomoże... jakiś schemat czy cuś... :)
A kogo to wszystko obchodzi?
O takim właśnie taplaniu się w gównie pisałem.... choć w sumie.... jak lubicie...
Ale ten smród na (a trochę i W) człowieku pozostaje.
Hm..... Dely oddzieliłeś większe gówno od bardzo dużego gówna. Lubisz to?? :)
Czy naprawdę musimy taplać się w gównie??
Moja opinia: usunąć i czym prędzej zapomnieć....
Ja mam 30Mbit z UPC i większość testów pokazuje mi zazwyczaj ponad 30MBit :). Np. speedtest.net zazwyczaj około 50-60Mbit :)
Sprawdzałem za to transfery ze znanych mi szybkich FTPow i spokojnie wyciąga deklarowana prędkość praktycznie o każdej porze.
Modemu restartować nie muszę, ale czasem przy zmianie IP (bo jak wiadomo IP jest publiczny ale nie stały) router nie może pobrać nowego IP z DHCP, no i wtedy pomaga restart routera, ale sobie watchdoga w nim ustawiłem pingującego jakiś popularny serwer DNS i widzę ze restartuje się przeciętnie raz na 5-6 dni.
No bo ROM trzeba podnieść żeby zobaczyć ten RAM który jak wiadomo jest POD ROMem :)
Inaczej się nie da.
Tak jest w turbo XF551 i Top-Drive (tyle ze tutaj juz ACK po komendzie leci w turbo), ale w przypadku przyspieszaczy "cywilizowanych" takich jak Happy Warp czy US-Doubler, ze o Toms Multi nie wspomnę, prędkość turbo jest stosowana już przy nadawaniu komendy, więc stacja nie wie z jaką szybkością ma tę komendę odbierać, musi próbować :)
W Atariki napisane jest, że stacje te używają sygnału "CLK" do ustalenia prędkości, analizując kod Toms Multi, i US-Doublera nie zauważyłem by to robiły. Po prostu starają sie przełączać na różne prędkości, aż w końcu odbiorą komendę. A że trwa to ułamki sekund - nikt tego nie zauważa.
@mono: Hm.... to gdzie bylo 300?? :) w C64 chyba - w stacji dysków ;)
Command powinna być stanie niskim podczas nadawania całej komendy. Peryferia po odebraniu bloku odpowiadjaja nadajac ACK (czyli kod Ascii "A") i w zasadzie to jest sygnałem prawidłowego odebrania.
A co do drugiego pytania, to nie ma uzgadniania prędkości :), przynajmniej ja się z nim nie spotkałem.
Stacja rozpoznająca kilka prędkości po prostu stara się odebrać komendę ustawiając jedną z dostępnych prędkości, jeśli wystąpi błąd, to komputer i tak ponawia wysłanie komendy, a w tym czasie stacja zmienia prędkość na kolejną dostępna. Z tego, co pamiętam to prób nadania komendy przez komputer jest 12, i za którąś znich, stacja będzie miała ustawioną prędkość zgodną z komputerem. Co do innych urządzeń to prędkości są ustalone wstępnie (czyli 19200 a magnetofon 300 ;) )
No to ja dopisuje pozdrowienia z Krety :)
Ciekawe z której części Dominikany, tej ładniejszej (droższa), czy tej brzydszej :P ..... ech też mieliśmy w planach ponowny wypad w tym roku, ale jakoś nie czasowo wyszło....
Dużo rumu Bacardi i Jacka Danielsa w bezcłowym przed wylotem kup :)
Ja popełniłem błąd (średniej wielkości zakupy) i jak ceny porównałem w Europie to zdębiałem ;)
Czyli cus spsulem.... Ale to juz po urlopie jednak.
Możesz skasować to przypomnienie ;)
Proszę o przypomnienie za dwa tygodnie.
Jak wrócę z urlopu to dodam sprawdzanie QMEGa i w przypadku wykrycia go - odwrotna reakcje na wciśnięcie Shift w czasie odpalania MSDOSa... :)
To chyba zadowoli wszystkich, nie pozbawiając jednocześnie programu własnej obsługi dopalaczy.
Taką mam koncepcję.
P.-S. Przy okazji jak odpalasz MSDOSa z Shiftem, to MEMLO w spada o $100 a dalej masz obsługę trybu US (z QMEGa), w sumie więc faktycznie warto w przypadku QMEGa domyślnie przechodzić na systemowe SIO.
No dobra...... mówisz-MASZ. Działa tak jak opisałem powyżej (przynajmniej w teorii, bo znowu całkowicie nietestowane :) - możesz protestować z QMEGiem i bez).
Czyli raz jeszcze ... w przypadku wykrycia QMEGA MSDOS domyślnie przełącza się na systemowe SIO (czyli procedury QMEGa), chyba że wciśnie się Shift w czasie ładowania. W przypadku innych OSów jest odwrotnie, czyli MSDOS domyślnie stara się wykryć turbo i wybrać jedną ze swoich wewnętrznych procedur, a Shift przełącza na SIO systemowe.
Odpal MSDOS z wciśniętym Shiftem - to wyłącza wszystkie turba i przechodzi na systemowe SIO. Obsługę UltraSpeed robi Ci i tak QMEG, wiec nie zauważysz różnicy. Procedura obsługi US w programie musi całkowicie zastępować systemowe SIO, więc nie ma mowy o zachowaniu mapowania napędów z QMEGa... chyba żeby dodatkowo na starcie sprawdzać czy jest QMEG i wyłączać dopalacze wbudowane w program...
Ten problem, może nie być związany z poprawką, którą zrobiłem, a właśnie z tym, że Top-Drive bruździ.....
TUTAJ masz wersje sprzed tej ostatniej poprawki, jeśli w tym przypadku skończy się na "pierdzeniu", to czas wywalić Top-Drive definitywnie i skupić się nad normalnymi turbami ;), może przed rozpoczynającym się w środę urlopem się wyrobie. Potrzebuję tylko potwierdzenia, że mam racje.
Choć.... przestawiłeś zawartość napędów w QMEGu, a pamiętaj, ze MSDOS ma własne procedury SIO dla UltraSpeed, które "olewają" mapowanie QMEGOwe...
Tak na szybko zrobiłem poprawkę, bo ciągle nie mam czasu zabrać się za to porządnie. Uwaga nieprzetestowane zupełnie :)
Jutro powinienem mieć trochę wolnego, i może uda mi się popracować nad MSDOSem więcej ;)
Plik jest do pociągnięcia TUTAJ
drac030 napisał/a:Wystarczy chyba tylko nie zmieniać wartości komórki $0301 ;)
W przypadku tego programu trzeba ją po prostu zapamiętać, przetworzyć (tak by zmienne w programie zostały ustawione na jej podstawie), a potem odtworzyć. Choćby z tej prostej przyczyny, by oznaczenie na ekranie nie wskazywało innego napędu niż naprawdę odczytany...
Niezmienianie jest najprostsze.... ale jakieś takieś.... mało eleganckie :)
Nie miałem wczoraj czasu się za to zabrać - zabiorę się wiec dziś-jutro. Mam już prosty pomysł na te funkcjonalność.... ale.... i tu pytanie dla użytkowników tego programu.
W całym kodzie najbardziej "bruździ" mi procedura rozpoznawania turbo zgodnego z Top-Drive. W zasadzie nie da się go w sensowny sposób rozpoznawać więc stosowana jest swego rodzaju ekwilibrystyka z próbami komunikacji w tym trybie, jeśli inne turbo nie zostaje rozpoznane wcześniej. W czasie, kiedy ulepszałem ten program ambicją było obsługiwanie jak największej ilości przyspieszaczy przy jednoczesnym małym MEMLO, ale teraz zastanawiam się nad wyrzuceniem obsługi Top-Drive, bo chyba ona powoduje czasem problemy z prawidłowym rozpoznaniem turbo.
Pozostałaby natywna obsługa trybu UltraSpeed/HappyWarp oraz rozszerzeń zgodnych z HDI.
Zasadniczo MEMLO to i tak nie zmieni, ale może wyeliminowałoby problemy z rozpoznawaniem dopalacza.
Ja wiem,... w dzisiejszych czasach możnaby się obyć zupełnie bez obsługi turbo (każdy chyba ma już QMEGa), ale dzięki temu można mieć szybką transmisje przy standardowym Atari-OS.
Dobra, obacze dzis co sie da z tym zrobic.... :)
A to w BASICu jest :)
Prawie trafilem w druga armate i wywalil sie program z jakims bledem :)
Konkretnie eksplozja wypadla dokladnie na lewej krawedzi ekranu i .... ERROR AT LINE :)
Zasadniczo jest już kolejny (116) build... znajduje się w katalogu:
http://pecus.pigwa.net/pliki/Atari/scorch/
i tam będą lądowały kolejne (z założeniem, że dostępne będą tylko dwa ostatnie).
W nowym poprawione dwa drobne błędy "kosmetyczne" i dodane kolorowanie paska statusu w trakcie oddawania strzału (przyjmuje kolor czołgu).
:p
Grajcie (na ile sie da) i raportujcie błędy.
Przeciwnik komputerowy jak narazie nie ma intelygencji, nie wszystkie bronie są dostępne (ale te nie dostępne po prostu się nie wyświetlaja, a w przypadku broni defensywnych niedostępne mają zerową cenę - większość znaczy ;) bo z tych jest tylko spadochron (a w nim brak licznika pokazujacego ile spadochronow zostalo)).
Ze znanych błędów wiemy, że:
- czasem po ataku zostaje na ekranie tekst (który potem jest traktowany jak element tła - jak już opadnie) - wiemy kiedy i dlaczego tak jest... poprawimy.
- coś jest nie tak z odejmowaniem broni po strzale - tu jeszcze nie wiemy czemu - tym bardziej ze procedura jest prosta jak budowa cepa - nie ma gdzie sie mylic ;) .... i wcześniej się nie myliła, a nie pamiętamy by coś było w niej zmieniane
- po zakończeniu bitwy pozostaje na akranie ostatni czołg (a konkretnie obiekt P/M kolorujący go) - proscizna
- i jeszcze kilka innych drobiazgów :)
Znalezione posty [ 726 do 750 z 1,677 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.099 sekund, wykonano 56 zapytań