Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
BigPEmu 1.12 Richard Whitehouse wydał BigPEmu 1.12
FujiNET firmware v1.3.0 Nowa wersja oprogramowania do interfejsu sieciowego FujiNET. Tym razem z obsługą TCP!
hatari 2.5.0 Od dwóch dni dostępna jest najnowsza (2.5.0) wersja Hatari.
Grawitacja 2024 Czas na kolejną edycję 8 bitowego GameJamu.
Tenebra na Atari ST/STE Wersja gry na duże atari.
Strony Poprzednia 1 2 3 4 5 6 7 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Problem dotyczy wyłącznie 65c816 OSa i APE w szybkich trybach transmisji podczas bootowania. Jak pisałem Atari810 pracuje bez problemów - może ma inne (lepsze?) procedury SIO niż APE.
Z innym OSem (QMEG) APE działa u mnie bez problemu w trybie 3x.
Draco, a u Ciebie przy transmisji 1x jest ok?
Zdaje się, że Draco nie ma ani SIO2PC, ani tym bardziej PAE z powodu niekompatybilności aplikacji z systemem. :mrgreen:
U mnie APE nie chce działać pod SDX w szybkiem transmisji.
[ Dodano: 25.01.2005 00:52:05 ]
A tak się ma +1 do statsów na AA i Mistrza offtopicu. :mrgreen:
Ok, znalazłem. Takie rzeczy prawie zawsze są nie tam, gdzie się szuka. W każdym razie to nie to, o czym pisałem powyżej, wpływ zamiany rozkazów miejscami musi być przypadkowy, chociaż dziwne, że w ogóle jest jakiś.
Przy okazji stwierdzam z rozczarowaniem, że aż trzy programy umieszczone w ROM-ie od TOMS 720 nie działają. To jest: ramdysk 260xe (w pliku autorun.sys), programik włączający BASIC, oraz ... TOMS COPY autorstwa Our 5oft. We wszystkich trzech przypadkach nielegalne skoki do systemu.
Działa natomiast program STIBM do kopiowania plików na dyskietki od peceta, i to nawet w szybkiej transmisji.
Zrodla TOMS COPY mam tu gdzies pod reka, wiec z tym jednym programem problema nie bedzie (a na pewno Pirx zgodzi sie na przekazanie ogolowi ;) ).
A to dobrze :D Próbowałem walczyć z tym programem, ale bez większego sukcesu - albo się wiesza albo działa w normalnej transmisji. Czy TOMS Copy ma własne procedury szeregowe? Bo coś mi tak to wygląda ...
O ile mi się wydaje z działania, to TOMS Copy sam sobie dobiera przeplot, z jakim czyta/zapisuje dane (na pewno nie robi tego po kolei). Dzięki temu zapis po sformatowaniu dysku w normal jest tak samo szybki, jak po sformatowaniu w turbo - mam rację?
Swoją drogą, to chyba najlepszy kopier dyskowy (chociaż trochę brzydki). Może przy okazji ktoś dołoży mu wykorzystanie większej ilość ext ramu?
[ Dodano: Sty 24, 2005 15:58:00 ]
A tak się ma -1 do upływu dni i wieczną młodość. :mrgreen:
Hm, no tak. Przeplot. Zdaje się, że TOMS Copy z tego powodu nie będzie działał tak dobrze z inną stacją, jak z TOMS-em - albo może będzie działał dobrze tylko z tymi stacjami, które mają taką samą prędkość transmisji, jak TOMS (czyli szośteczka, 68 kbps), natomiast w pozostałych przypadkach transmisja będzie kulawa.
[ Dodano: 25.01.2005 16:28:21 ]
PS. Albo wcale nie będzie działał, bo coś mi się kojarzy, że próbowałem odpalić TOMS Copy na jakiejś innej stacji, a on się wypiął. Ale to pewnie tylko taki bajer, żeby nie ułatwiać tym, co nie mają stacji TOMS ;)
Przede wszystkim, chyba TOMS Copy działa tylko w turbo. Toms turbo, oczywiście. Szkoda, fajnie byłoby sztuczkę z doborem przeplotu dostosować do innych prędkości tramsmisji.
[ Dodano: Sty 24, 2005 22:28:00 ]
A tak się ma -1 do upływu dni i wieczną młodość. :mrgreen:
W ROM-ie Ca2001 z TOMS Multi też jest TOMS Copy (być może ta sama wersja co w stacjach z TOMS Turbo) i działa, a z XF-551 już nie działa.
[ Dodano: 25.01.2005 23:26:48 ]
A tak się ma +1 do statsów na AA i Mistrza offtopicu. :mrgreen:
TOMS Copy OUR 5OFtu faktycznie ustala przeplot, chyba nawet wysyla programy do stacji, ale zakonczmy dywagacja i sciagajmy. Format MAC65 oczywiscie i pisane to bylo na maluchu wiec troche uproszczone komentowanie widze. Na grzybie miejsca wiecej jest....
Mam nadzieje ze mnie Pawel nie zlinczuje ;)
Przede wszystkim, chyba TOMS Copy działa tylko w turbo. Toms turbo, oczywiście. Szkoda, fajnie byłoby sztuczkę z doborem przeplotu dostosować do innych prędkości tramsmisji.
TOMS Turbo to jest zwykły Top Drive, z dokładnie tym samym programem wczytywanym w obszar stosu. To nie jest problem, problem jest w tym, że nigdzie w TOMS Copy nie widzę skoku do SIO. Może po obejrzeniu źrodła się wyjaśni ... (źrodło i tak muszę przenieść na Atari, bo pod pecetem nie mam MAC/65).
Pecus nie przesadzaj już z tym miejscem, na Atarynce jest miejsce na 10x takie programy ;)
Na PC nie masz MAC65 ale masz OMC65. Podepnij sobie pod jakis edytor dla programistow, zrob kolorowanie kodu i juz ;)
Bo to zrodlo jest w zwyklym grzybianym pliku tekstowym zgodnym z formatem ENTER#D:file,A (bez numerow linii) w MAC65 (juz przewalone z atarynki po prostu).
No ale jeśli program i tak muszę przerzucić na Atari, żeby sprawdzić, czy działa (bo do peceta TOMS-a nie podepnę), to chyba wygodniej jest go obrabiać i kompilować od razu na Atari, nieprawdaż? ;)
[ Dodano: 26.01.2005 20:25:29 ]
Trub: jak byś widział możliwość zrobienia w command.com czegoś takiego, że jak wpisujemy nazwę programu, dajmy na to:
D3:>TB[RETURN]
a ten program występuje na dysku (wzdłuż ścieżki) jako TB.EXE, to automatycznie wczytywany jest przez X? (w odróżnieniu od *.COM, wtedy bez).
Pomysł z EXE prosty, ale genialny :D
Ale jest problem, bo command.com wyszukiwanie i uruchamianie pliku zostawia kernelowi. W ostateczności command będzie rozpoznawać po rozszerzeniu exe, czyli "cośtam.exe" - wtedy automatycznie odpali X-a.
Na razie udało mi się ułatwić życie w ten sposób, że zamiast "X cośtam", można "!cośtam" ;)
Problem dotyczy wyłącznie 65c816 OSa i APE w szybkich trybach transmisji podczas bootowania.
Sprawdź teraz (http://drac030.krap.pl)
O! nowa wersja OSa.
Przy okazji Draco, zdaje się że XDIR też na sztywno ustawia DUNIT na 1. Masz może źródła do tej binarki ?
A z programami EXE będzie tak, że trzeba wpisać pełną nazwę z rozszerzeniem. Wtedy odpali się z X. W ten sam sposób będzie można powiązać inne rozszerzenia z programami, które czytają parametry. Np. SI.REL automatycznie uruchomi się z EXEC ;), TXT z jakimś edytorem itp.
Z ostatniej chwili: właśnie testuję działający BASIC ON przy 1MB RAMu! Będzie w nowej wersji SDX.
O! nowa wersja OSa.
Ano, SIO powinno działać lepiej.
Przy okazji Draco, zdaje się że XDIR też na sztywno ustawia DUNIT na 1. Masz może źródła do tej binarki ?
Źródeł nie mam, Prof! się nimi nie podzielił, a potem spececiał i źrodła przepadły. Ale nie powiem, żeby ta wersja, którą mam na stronie, ustawiała D1: na sztywno ;)
A z programami EXE będzie tak, że trzeba wpisać pełną nazwę z rozszerzeniem. Wtedy odpali się z X. W ten sam sposób będzie można powiązać inne rozszerzenia z programami, które czytają parametry. Np. SI.REL automatycznie uruchomi się z EXEC ;), TXT z jakimś edytorem itp.
Czy to jest jakoś konfigurowalne, tj. do danego rozszerzenia przypisujemy program, który otwiera pliki danego typu?
Będzie konfigurowalne :D
Ale na razie do testów programy i rozszerzenia są wpisane na sztywno.
[ Dodano: 2005-01-28 23:15:39 ]
To ja mam chyba jakąś inną wersję XDIRa. Spróbuję z tą na Twojej stronce.
No, masz po prostu wersję XDIR-a niespaczowaną ;)
Do przetestowania jest beta sterownika RUNEXT.SYS umożliwiającego skojarzenie rozszerzeń plików z programami, za pomocą których pliki te są uruchamiane. Wystarczy wpisać nazwę pliku i rozszerzenie, na tej podstawie będzie uruchomiony odpowiedni program. Sterownik będzie zawarty w SDX 4.30, ale już teraz mozna go testować.
Dołączony przykładowy plik konfiguracyjny RUNEXT.CFG zawiera następujące wpisy:
EXE, XEX - uruchamiane z X.COM (zgodnie z proponowanym standardem programy EXE wymagają X-a, a COM nie),
ARC, ZIP - wyświetlanie zawartości archiwum,
TXT, DOC - uruchamiane z edytorem,
REL - uruchamiane z EXEC (jak w SI 2.08b, ściśle tajne: Draco wypuści je dopiero w kwietniu, patrz daty plików :twisted:),
FAS - asemblacja.Opis struktury pliku konfiguracyjnego w nim samym (to plik tekstowy). Można dopisywać swoje wywołania. Programy muszą oczywiście przyjmować argumenty z linii poleceń.
Domyślnie RUNEXT.SYS szuka pliku konfiguracyjnego na kartridżu SDX 4.30, dlatego póki co trzeba uruchomić go podając inny, np.: DEVICE = A:RUNEXT.SYS RUNEXT.CFG, ten ostatni powinien być na dysku A:.
Trzeba też zainstalować nową wersję COMMAND.COM (też będzie w 4.30) za pomocą polecenia SET COMSPEC=D1:COM430.COM. Plik COM430.COM jest w .arcu. COM430.COM będzie co chwila wczytywany, dlatego najlepiej mieć szybki dysk lub przekopiować go do ramdysku. Plik COM430.COM też nie jest ostateczną wersją, dlatego o zmianach napiszę kiedyś ;)
RUNEXT.SYS zajmuje zwykle tylko 44b pamięci podstawowej, całą resztę i konfigurację próbuje umieścić w rozszerzonej.
Po zainstalowaniu sterownika polecenie "RUNEXT" podaje aktywne skojarzenia. Poprzedzenie nazwy pliku znakiem # zapobiega rozpoznawaniu rozszerzenia (np. "#plik.exe" będzie uruchomiony bez X).
Uwaga: w środku nie ma doca, musi wystarczyć to co napisałem. Czekam na uwagi, np. jakie programy nie działają.
Na razie to, co testowałem, działa. Bardzo fajne.
Ale jest jeden problem. Mianowicie, zdefiniowany w cfg loader do określonego typu plików sam jest traktowany jak COM i nie można tego zmienić. Przykład: program si.rel ładowany jest przez exec.com. W efekcie ładowany jest bez "pośrednictwa" X.COM, ale w razie gdyby tego potrzebował, to przemianowanie loadera na exec.exe i zmiana w pliku cfg nie pomaga, rozszerzenie *.exe w loaderze jest ignorowane (traktowane jak *.com).
Chyba, że coś przeoczyłem?
Nie myślałem o tym, ale rozwiązanie jest możliwe za pomocą wpisu w CFG typu:
REL,X.COM,EXEC.COM %
(zakładając, że EXEC wymaga wyłączenia SDX)
Loader podany po rozszerzeniu zawsze będzie traktowany jako COM.
Przy okazji: w nowej wersji COM430.COM można też uruchamiać exeki poprzedzając nazwę wykrzyknikiem, np. !plik.com uruchomi program jako exe ;)
Tak, tak to działa.
Ale odkryłem, że coś jest jednak nie tak. Zainstalowałem to wszystko (łącznie z com430.com) na SpartaDOS X 4.20. Żeby nie wklepywać długich nazw programów, już od dawna mam porobione bacze, które mi uruchamiają najczęściej używane programy. Np. -[Return] odpala mi MAE, -U UmonXL, -tb Turbo BASIC XL, -cl CleanUp, -dr DiskRX i tak dalej.
Teraz przerobiłem kilka z nich na "nowy" system (tj. np. plik ".bat" zawiera nie "x b:>mae>mae", ale "b:>mae>mae.exe" itd.).
Otóż po kilku - pięciu-sześciu - uruchomienach programów w ten sposób, w systemie robi się kaszana. Objawy są różne, od zwykłego zwisu, do sieki na ekranie albo pokazania tamże filmu dokumentalnego pt. "Niemy Murzyn w ciemnej piwnicy" ;) Albo np. CleanUp wyświetla komunikat, że wystąpił disk error numer 0 (słownie: zero) przy odczycie sektora numer $FF20, wielkość katalogu jest nieprawidłowa i czy nadpisać 8O Słowem, wszystko wariuje.
Mgliście pamiętam, że SpartaDOS ma coś w rodzaju wewnętrznego stosu używanego do przechowywania parametrów niektórych funkcji czy coś takiego, i jak kiedyś doprowadziłem do przepełnienia tego, to efekty były zbliżone.
Ee, pewnie raczej jakieś zwykłe nadpisanie pamięci. Czy tak się dzieje tylko wtedy gdy używasz baczów? A plik CFG zmieniałeś?
A swoją drogą najwyższy czas żebyś sobie apgrejdował Spartę na 4.30 :D
PS. Czy istnieje coś takiego jak CDROM.SYS do KMK/JŻ IDE?
CDROM.SYS: podobno istnieje, ale ja nie widziałem tego na oczy 8O
Co do wariowania, wygląda to jednak na błąd w SpartaDOS X 4.20, a ściślej w X.COM. Jak na czystym DOS-ie (bez żadnych nakładek) zrobię X CLEANUP F: pięć razy z rzędu, to za szóstym razem następuje zwis. Ale z drugiej strony te piękne raporty ("Disk error #0 reading sector $FF20, directory length is incorrect, OK to rewrite?") występują tylko w obecności RUNEXT.SYS.
Muszę parę dni podziałać na DOS-ie z twoim rozszerzeniem, to się zobaczy, czy jest gorzej, czy tak samo. Na razie wygląda to tak, że uruchomienie 6 razy pod rząd TEGO SAMEGO programu (?) wiesza system.
Upgrade do SpartaDOS X 4.30 zrobiłbym bardzo chętnie, ale nie wiem jak. Mam "oryginał", co to go Karen montował, czyli zawartość epromu jest pokiełbaszona i nie bardzo się da to zaprogramować prostym zrzutem danych tak jak je widać w pamięci.
Strony Poprzednia 1 2 3 4 5 6 7 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.097 sekund, wykonano 15 zapytań ]