Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
VBXETERM 0.15 Nowa wersja emulatora terminala VBXETERM dodaje obsługę klawiszy strzałek oraz nowe czcionki.
Weekend z Borsuk Retro Gry TV Zapraszamy na weekendowe transmisje z udziałem gości, w tym budowę Custom Atari XL i naprawy sprzętu.
AltirraSDL Lobby Przeglądarkowy front-end dla emulatora Altirra z trybem gry wieloosobowej online od Ilmenita.
Test7800 0.8.0 Nowa wersja Test7800 wprowadza wsparcie dla większych kartridży Bankset oraz obsługę Quadtari.
Flob wkracza na Atari ST Platformówka z 8-bitowego Atari zmierza na komputery z serii ST.
atari.area forum » Posty przez drac030
Lewis, proponowałem DOCELOWO zrezygnowac z karta 8) 4.30 będzie to SDX jak najzupełniej normalna, o ile mi wiadomo, tylko z poprawkami. Jednak mając źrodło można w przyszłości pokusić się o wyjechanie z SDX dajmy na to 5.0 ładowaną z dysku i rezydującą w pamięci liniowej. ;) To miałem na myśli.
[ Dodano: 07.01.2005 03:44:04 ]
PS. Przeczytałem jeszcze raz swojego poprzedniego posta i faktycznie, przyznaję, tak wygląda, jakbym chciał to zrobić już teraz. Źle się wyraziłem. Moja kulpa.
a daloby sie powyzsze dane dorzucic do atariki? bo szczerze mowiac, ja poszukiwalem ich w inwernetu czelusciach i nie znalazlem. a wydaja sie byc pozyteczne... :)
No pewnie... ale nie dzisiaj. Zresztą, wiele do dodania nie ma, więc to co napisałem wyżej możesz sam dodać w wolnej chwili ...
pacz na LOAD, zeby dalo sie zaladowac kontent binarny pod wskazana lokacje poprosze, na ksztalt LOA z DOS II+/D.
LOAD to jest zda się polecenie wewnętrzne command.com, czy się mylę? Ponieważ ładowanie kontentu binarnego pod arbitralny adres ;) może nadpisać command.com, więc proponowałbym raczej usunięcie LOAD z command.com i zapodanie tego polecenia na urządzenie CAR: jako programu zewnętrznego, oczywiście z tym rozszerzeniem.
[ Dodano: 07.01.2005 02:00:31 ]
Proponuję na początek wywalić:
1. RPM.COM - ktoś tego używa w dobie hardysków ?
Zgadzam się, to jest nieporozumienie. W 4.22 jest też ECHO.COM, czy ma to jakąś przydatność?
2. XEP80.SYS - i tak nie działa w PALu, a w ogóle trzeba napisać lepszą wersję (drobna łatka do PALa u mnie)
Ja proponuję to w ogóle usunąć, to znaczy przenieść na dyskietkę z toolkitem. XEP jest mało popularny i w ogóle jest to urządzenie, które działa, jakby chciało a nie mogło. Szkoda miejsca, które można byłoby wykorzystać na coś bardziej przydatnego.
3. UNERASE.COM - rzadko używany i zdaje się z burakiem, no i zawsze można sobie zrobić dyskietkę ratunkową ;)
Można spróbować poprawić błąd, ale chyba nie ma powodu, żeby to rezydowało na karcie.
Ogólnie zgadzam się z Lizardem, lepiej jest zarezerwować CAR: na najniebędniejsze rzeczy.
A może w ogóle docelowo zrezygnować z karta i zaprodukować wersję ładowaną z dysku. To co jest na kartridżu można byłoby wepchnąć do pamięci powyżej adresu $FFFF.
pisal pan Lizard
Emm, nie. Lizard dokonał konwersji na HTML i pewnie obróbki redakcyjnej, ale z nagłówka mi wynika, że to jednak ja pisałem. Słusznie więc wydał mi się znajomy, bo np. "w gruncie rzeczy" to chyba tylko ja nadużywam :rolleyes: ;)
swoją drogą, to ciekawe, czy 14MHz wystarczy, na dekodowanie i odsłuch plików MP3....
Szczerze wątpię. Motorolka 68030/16 MHz sobie z tym nie radzi. Nieco większe - ale tylko nieco - szanse są przy mp2, ale chyba nawet amigowcom się nie udało osiągnąć zadowalających wyników na 68020/14 MHz - czyli na gołej 1200 - chociaż bardzo się starali.
Z drugiej strony, ja może czegoś nie wiem - bo na Falconie jest DSP, więc nikt się w to nie bawił, TT mało kto ma itd.
[ Dodano: 07.01.2005 01:35:59 ]
pod warunkiem ze Draco przewidzial Basic w nowym OS
Wmontowywać BASIC-a do ROM-u nie ma sensu, skoro go można dużo lepiej załadować z twardego dysku. Taki interpreter BASIC-a, co by miał na program 64k RAM-u - czyli cały segment - spróbuję wykonać. To znaczy on się gdzieś tam w tle stopniowo pisze, ale OS jest ważniejszy.
MVN - move next - transfer bloku, rosnąco. Rozkaz przepisuje w pamięci blok danych o długości do 64k w rosnącej kolejności adresów. Adres źródłowy określa rejestr X, adres docelowy rejestr Y, długość bloku zmniejszona o jeden znajduje się w akumulatorze. Najstarsze bajty adresów źródłowego i docelowego definiowane są przez dwa dodatkowe parametry natychmiastowe. Jest to w gruncie rzeczy jednorozkazowa pętla o następującym działaniu:Ten tekst jakoś mi wygląda znajomo. Kto go pisał?
[ Dodano: 07.01.2005 01:39:01 ]
Więc - jeśli ktoś ma możliwość załatwienia za 50-60 zeta j.w. - zamawiam 1 szt. :D:D
No właśnie, 50 złotych mozna dać, zważywszy, że to i tak jest dwuipółkrotne przebicie ceny producenta. Też bym chciał jeden.
Tia, dlatego napisałem, że to się okaże, czy jej - instrukcji MVN - uzycie będzie korzystne. Dane da się transferować szybciej, to znaczy z szybkością 9 cykli szybkich i dwóch wolnych (9 + 2*8 = 25 cykli szybkich) na dwa bajty. To daje 12,5 cykla na bajt, czyli mniej więcej 1107,8 kB/s, minus haracz, i mamy 738,6 kB/s.
Ale to tylko wtedy, jak będzie miejsce na taką dużą pętlę. W ROM-ie od PBI się ona nie zmieści, więc pozostaje tylko MVN.
Hmm, to 1971 kB/s to jest teoretyczny transfer przy założeniu, że czytamy z rejestrów z pełną szbkością CPU (14,18 MHz) i z takąż zapisujemy do pamięci, a i kod, który nam to robi, w szybkiej pamięci się znajdywa.
Wszelako, pamięć ekranu znajduje się z pierwszych 64k, gdzie zapisy będą szły ze starą szybkością 1,773 MHz.
Policzmy: instrukcja blokowa zużywa 7 cykli na przepisanie bajtu z miejsca na miejsce. Z tego są trzy cykle odczytu rozkazu (to jest pętla), jeden odczyt bajtu źrodłowego, jeden zapis bajtu docelowego i dwa cykle operacji wewnętrznej (zmniejszenie liczników, zwiększenie adresów).
Mamy tu 4 cykle odczytu, jeden zapisu i dwa wewnętrzne. Czyli - przyjąwszy zegar za 14,18 MHz - 6 cykli szybkich i jeden wolny, liczący osiem cykli szybkich. Reasumując, transfer pojedycznego bajtu z dysku do pamięci obrazu zajmie 14 cykli maszynowych szybkich.
512 bajtów pomnożyć przez 14 daje 7168 cykli maszynowych. Dodać ładowanie adresów itd., 7178 cykli maszynowych. Razy dwa, 14356 cykli na kilobajt. 14180000/14356 = 987,74 kilobajta na sekundę ... odjąć 30% na haracz dla Antica => 658,5 kB/s.
Tak w ogóle pierwszych prac nad rozgryzieniem tego, jak wewnętrznie działa SpartaDOS X, dokonał niejaki Prof!, czyli Mariusz Pietrasiuk.
Od punktu, w którym skończył, zacząłem ja i opracowałem to i owo w postaci kilku plików teksotwych z opisem tego, co mi i Profowi udało się wykumać. Lizard też tu przyłożył sporo swojej pracy.
Pliki te swego czasu dostał ode mnie MMMG i doprowadził rzecz do szczęśliwego końca - odwalając też większość czarnej roboty, trzeba zaznaczyć.
Nie byłem pewien, czy MMMG upublicznił kod biblioteki, czy tylko sam komentarz, dlatego o źrodłach biblioteki napisałem z pewną niesmiałością taką ;)
Jak już wiemy, co mamy, to można byłoby rzecz sprowadzić do postaci kompilowalnej.
65c816 ma rozkaz, który przenosi blok pamięci z miejsta A do miejsca B.
Czy użycie tego rozkazu dla całej przestrzeni adresowej będzie korzystne, to się okaże. Na pewno bardzo jest pomocny dla takiego interfejsu, jaki mamy teraz (to znaczy, zapisy i odczyty sektorów w obrębie pierwszego - -czy też jednego - segmentu 64k).
Pasiu, jakie są widoki na to 512k ROM-u? Bo jesli to kwestia paru miesięcy, to moznaby juz powoli startować z pisaniem systemu.
Hej Draco, a w takim przypadku ile zyskamy, jeśli rejestry będą taktowane na róni z pamięcią "Fast"?
3597 cykli na transfer 512 bajtów przy zegarze 14,18 MHz daje plus minus 1971 kilobajtów na sekundę.
czyli wychodzi na to, żę LBA będzie trochę szybsze niż CHS w normalnej, codziennej pracy - np. wyszukiwanie jakiegoś plikui, czy np. operacja defragmentacji ??? :rolleyes: ;)
Trochę szybsze będzie: porównaj sobie pod SysInfo odczyt "sequential" i "same block". To pierwsze to jest "best case": przeliczenie numeru sektora na CHS jest robione tylko raz na cały test. To drugie to jest "worst case": obliczenie CHS jest robione za każdym odczytem sektora.
Pożyjemy, zobaczymy :D
To nie są obliczenia dla CHS, to sa obliczenia dla samego odczytu. Ale różnicy dużej pomiędzy LBA a CHS nie będzie, bo HD BIOS przeprowadza te obliczenia tylko w sytuacji, kiedy odczyt sektorów nie jest sekwencyjny.
Źrodłówkę podeślę, jak ją znajdę.
A na jutro to ja preparuję nową releasę ROM-u, więc nie zeźrodłować swojej części nie zdążę :D Poza tym ja mam ten command.com. Jakby ktoś jeszcze miał źrodła biblioteki (banku 1 czarta) to byłaby połowa drogi.
[ Dodano: 06.01.2005 14:52:22 ]
Casper: ICD nie ma źrodeł Sparty, sprzedali przecież wszystko do FTe. Źeby znaleźć źrodła, trzeba znaleźć autora Sparty X. A tego to już chyba próbowano ...
To ciekawe ile wyciągniemy z nowego IDE KMK dostosowywanego właśnie przez Jacka Z. & Draco do potrzeb 65c816 ??? Może realtime DolbyDigital EX 7.1 @ 192 kHz :lol:
To można spróbować obliczyć. Ale niestety, dopał nie będzie taki wielki, bo I/O ma być taktowane tradycyjnie, a zapis do RAM-u w pierwszych 64k będzie wolny. Może natomiast przyspieszyć zapis, bo I/O będzie nadal wolne, ale odczyt z RAM-u będzie szybki.
Teoretycznie sam odczyt sektora 512-bajtowego powinien zajmować 3620 cykli, co daje 244,8 kilobajta na sekundę. Odjąć 30% (Antic) - 160 kilobajtów na sekundę. Oczywiście pominąłem resztę kodu handlera, dzielenia, mnożenia, potęgowania i pierwiastkowania :D jakich wymaga CHS. Osobiście będę zadowolony, jeśli odczyt przekroczy 100 kB/s.
[ Dodano: 06.01.2005 14:41:46 ]
Mała poprawka: powyższe obliczenia są w porządku - chyba - dla zegara 1,773 MHz. W przypadku 14 MHz, ponieważ instrukcja przesłania blokowego zużywa dwa cykle na operację wewnętrzną, w praktyce czas przesłania jednego bajtu będzie 5,25 cykla (5 cykli wolnych i dwa szybkie). Daje to 2728 cykli na transfer 512 bajtów, czyli 325 kilobajtów na sekundę. Odjąć czas na Antic, 217 kB/sec.
Jakbyś miał źródełka Command.coma to byłoby grejt. Możnaby dorobić polecenie RUN oraz np. możliwość odpalania baczówek bez "-". Oraz zrobić juniksa na JIL: ls, rm, pwd :D
Polecenie RUN jest, jak napisał Casper, i to pewnie nie jedno, bo ja też kiedyś coś takiego napisałem. A źrodełko command.com jest, ale nadaje się tylko do badania działania command.com, natomiast nie będzie działać. Jest to w formacie MAC/65.
Jak już z Draco ustaliłem za format daty odpowiedzialne są procedury FDOPEN i FDGETC.
Coś mi się zdaje, że one tylko wywołują procedurki ze sparta.sys do sformatowania katalogu. Bo np. ATARIDOS.SYS formatuje inaczej.
Ale w FDOPEN/FGETC to jest punkt, w który można byłoby się wpiąć z łatką.
To może zaczniemy od zdekompilowania SPARTA.SYS
Jak tylko po to, by zmienić format daty to nie wiem czy jest sens.
Nie, nie tylko po to. W ogóle docelowo dobrze byłoby mieć źrodłówkę - taką do skompilowania - całej Sparty, co pozwoliłoby na prace rozwojowe.
Tyle, że Sinclair QL miał Motorolę 68000 o ile mnie pamięć nie myli :D
A SAM-a Coupe widziałem kiedyś w sklepie w centrum Warszawy. Ale już istniał Falcon i to tę maszynę chciałem kupić.
Ale data jest chyba w formacie hamerykańskim, więc 01-14-05.
Można łatwo zmienić na bardziej cywilizowany format :D
No tak, ale reszta dat w SDX pozostanie w tym formacie, więc ustawienie jednej tylko po europejsku spowoduje zamieszanie. Teraz widać, które to miesiąc, bo jest liczba 14. Ale jeśli kiedyś jeszcze będziemy w SDX grzebać, to data może wyjść mniej oczywista.
W tym wypadku, jeśli nie da się zmienić wszystkiego, proponuję zastosować zasadę wojskową: "ch*jowo, ale jednakowo" ;)
Myślę, że przerobienie dir nie byłoby takie trudne.
To chyba trzeba byłoby zamienić miesiąc i dzień w SPARTA.SYS, bo to on zdaje się przygotowuje format katalogu? Wersję rozbudowaną z obsługą zmiennej środowiskowej SET COUNTRY = PL ;), raczej z braku miejsca trzeba by ładować w konfigu.
To może zaczniemy od zdekompilowania SPARTA.SYS? Ja kiedyś zrobiłem - w celach badawczych - źródłową wersję command.com. Ona się nie da skompilować z powrotem, ale teraz możnaby już przygotować źrodłówkę tak, żeby się dała.
Tak ogólnie, to ma ktoś sposób na w miare proste wypalenie nowej Sparty w epromie? Bo pamiętam, że Geisler mówił, że to jest jakoś pokiełbaszone tam.
U mnie na Pasiowej intSDX bez problemu - wystarczy plik rom wypalić na 27c512. Na kartridżu podrobionym przez AtaraX też jest taki eprom, więc chyba jest tak samo.
Niestety, ja mam, o ile się nie mylę, karenowski "oryginał", gdzie to nie jest takie proste. Ale to jeszcze trzeba sprawdzić.
Ja już z tym walczyłem. Zobacz se TDPL 2.0 ;). Problem tylko jak to umieścić w romie zamiast TD.COM.
Pliki są na urządzeniu CAR:, a ono zajmuje sześć banków SDX (czyli całość nie licząc banku zerowego i biblioteki w banku 1). Urządzenie CAR: ma katalog z plikami zapisany też gdzieś tam, i założę się, że jego format jest do rozgryzienia. Dalej to już banał.
No ja w ROM-ie wolnego miejsca więcej nie widzę ... chyba, żeby zrobić łatkę ładowaną przy boocie przez config.sys.
No tak, ale mówię, lepiej byłoby chyba mieć to konfigurowalne. To znaczy, zamieniać jedno z drugim opcjonalnie, jeśli juzer sobie zażyczy (np. przez odpowiedni config.sys).
Zarowno Ty Draco jak i cedyn sugerowaliscie bląd. No offence panowie, nikt nie musi znac tego hasla, wogole nie wiem o co cala dyskusja, tylko nie lubie jak mi ktos zarzuca nieznajomosc jezyka angielskiego w stopniu podstawowym
Spokojnie, ja nawet nie wiedziałem, ze to logo jest twoje :D A co do tego, że sugerowaliśmy błąd - no i mieliśmy rację, bo to JEST błąd. A że zamierzony, to już inna sprawa - niemniej z zamierzonymi błędami jest to niebezpieczeństwo, że zostaną wzięte za niezamierzone. Zwłaszcza, że wokoło - w internecie - można odnieść wrażenie, że mało kto umie w ogóle pisać po polsku, a co dopiero po angielsku.
A tak na marginesie, to po przejrzeniu stron na ten temat, do których podałeś link, nadal nie bardzo pojmuję, dlaczego takie wielkie halo zrobiono z powodu jednego, źle przetłumaczonego zdania w jakiejś gierce wypuszczonej 30 lat temu na sprzęt, którego pewnie nikt w Polsce nie widział na oczy (tj. ja nie wiem na co, ale nie na Atari chyba). Czy to akurat błędne tłumaczenie jest szczególnie śmieszne albo powinno się osobie biegłej w angielskim kojarzyć z czymś śmiesznym? Poproszę o egzegezę 8)
no na dir to się raczej nic nie poradzi, i nie wiem czy to ma sens. jeśli już to musiałoby to być konfigurowalne jakoś, w jakiej kolejności się wyświetla datę (jak na Falconie). Chyba szkoda zachodu.
Tak ogólnie, to ma ktoś sposób na w miare proste wypalenie nowej Sparty w epromie? Bo pamiętam, że Geisler mówił, że to jest jakoś pokiełbaszone tam.
Hehe. Rozumiem, że inicjały dałeś alfabetycznie. DLT Ltd. byłoby KUL.
Ale data jest chyba w formacie hamerykańskim, więc 01-14-05. A może w ogóle 01-14-2005, o ile się da. "20" można wpisać na stałe, ostatecznie poprawianie tego raz na sto lat w kodzie nie stanowi dużego problemu :D
Na czy polega bug w TD.COM? Bo ja tego program nie używam.
Co do napisu o słodkich szesnastkach to jestem za. W ogóle idiotycznym pomysłem było umieszczenie tego w ramdisk.sys ...
Cedyń, nie przejmuj się, ja też nigdy na oczy nie widziałem tego rzekomo kultowego hasła ... :mrgreen:
Ależ ja "chcę" wyświetlać menu, a ściślej chcę, żeby komputer je wyświetlał, tyle że przez E:.
Jak masz twardy dysk KMK/JZ, to numer partycji bootującej możesz ustawić FDISK-iem na przykład. Dajesz boot = D2:, bootmode "pass" i z moim ROM-em system powinien pójść z D2:, choćby to była stacja dysków (z normalnym ROM-em boot = D2 i bootmode "control" powinno dawać podobny efekt).
Ogólnie jeszcze pomyślę nad tym, bo wychodzi na to, że menu, które wbudowałem do ROM-u jest obecnie nie do użytku pod SDX.
[ Dodano: 04.01.2005 21:24:28 ]
PS. Klawiatura na PBI nie stanowi(łaby) problemu :D
[ Dodano: 05.01.2005 02:35:02 ]
PS2. Załadowałem poprawioną Spartę pod emula. To był pierwszy raz, jak zobaczyłem SDX 4.22. I widzę jeszcze jedną różnicę w stosunku do 4.20. Mianowicie zajawka, którą wyświetla command.com jest wyjątkowo jakoś paskudna.
SDX 4.20 ma coś takiego:
SpartaDOS X 4.20 2-06-89
Copyright (C) 1988 by ICD, Inc.A SDX 4.22 coś takiego:
SpartaDOS X 4.22 11-05-95
Copyright (C) 1995 by FTeNie dałoby się tego jakoś poprawić, skoro i tak już poprawiamy? Przynajmniej zlikwidować dodatkową spację pomiędzy "4.22" a datą, bo przez to górny wiersz wyłazi na prawo. A dolny wiersz można wydłuzyć przez zastąpienie tekstu "FTe" przez "FTe&Trub" :D i wrócić do formatowania znanego z 4.20.
Co wy na to?
"Sorry, but even for me an adaptation of the sap to the Neotracker is a nonsense. At least - according to the author (Edrinker :D ) using the NEO player for SAP would allow only small number of *.neo files to be played. AFAIK, the author of the topic tried to configure the Neotracker *** some two years (Abbuc CMP etc.). Would this succeed?
It would have some sense if someone could make a Winamp plugin that could separately handle the NEO format. And this has some sense, and I think that this costs less effort, because even 6502 emulation is not needed, to run the player under it. It is just a question of stuffing 8-bit samples - just like it takes place in the Atari COVOX.
Could someone translate this? I couldn't".
Here you are Pin, but I must say that the Polish text wasn't very clear: what was this about two years? I don't understand, probably due to a typo you did or so.
Wszystkie wymienione wyzej bloki programu sa ruchome, a ich aktualne adresy znajduja sie w rejestrach RAM na stronie zerowej.
No właśnie, egzaktli.
Is there source code for KMK/JZ FDISK and Disk Commander available?
No, sources for FDISK 1.40 are lost.
Pasiu, potrzebujesz jeszcze to LPOKE? Bo mam LPOKE/LPEEK. Ale na forum będę mógł wrzucić w piątek najwcześniej. No i bazuje to na Lizarda biblioteczce GETPAR, więc będzie działać tylko ze Spartą albo DOS DwaPluzDe (chodzi o linie komend).
Wytłumacz mi jeszcze, jak to w dopałce mają działać dwa procesory? Bo przecież jak będzie działał jeden, to drugi będzie musiał być zahaltowany, a więc sterowanie jednym przez drugi odpada: jak się procesorowi 6502 pozwoli ruszyć z pozycji początkowej, to jak go potem zahaltować z powrotem?
No i jak będą szły przerwania? Wszystkie do tego CPU, który akurat działa?
atari.area forum » Posty przez drac030
Wygenerowano w 0.137 sekund, wykonano 19 zapytań