51

(32 odpowiedzi, napisanych Programowanie - 8 bit)

tebe, właściwie, to chociaż nie spadłem głową na kibel ;) ,
to wczoraj wymyśliłem coś takiego jak protected mode dla Atari :))))))

System moglby sie "schronic" pod ROM lub w specjalnym (np. zerowym) banku.
Wystawilby tylko na zewnatrz procedure obslugi RESET.

Procedura odpalenia programu uzytkownika
- odpalasz system DOS
- "chowasz" go zostawiajac wektory (obsluga RESET, powrot z programu)
- ladujesz program
- blokujesz zmiane bankow (PBCTL, i jak jest to też jego cień)
- uruchamiasz program, ew. z mozliwoscia podpiecia do handlera XMS
- program moze sobie rzezbic po calym RAMie poza przestrzenia ROM,
  takze w zakresie aktywnego banku
- jesli program jest bardzo glodny, to wola o wiecej RAMu w XMS poprzez handler

Czyli nie chronione zostaja wektory + mikro-procki do wskakiwania pod ROM lub
bank zerowy.
 
Wprawdzie to namiastka, ale jakby sie uparl, to jest to jakas mozliwosc...
No i chyba nie ma takiego DOSu, ktorego moznaby ew. pod to spatchować.

Druga mozliwosc to wyrzucenie calego DOSa na czas uruchomienia programu na dysk (lub lepiej: RAM-dysk - taka hibernacja). Ale to już calkiem inna historia...

------
Co do potrzeby istnienia RAM-dysku, to chociaż w DOSie dużo nie robiłem, to wydaje się, że RAM-dysk  jest idealnym miejscem na tworzenie plikow tymczasowych (roboczych) w toolach, ktore przetwarzaja wiecej niz 64kB. To jedno z wielu zastosowan, ktorych pare na swiecie wymyslono dla tego ustrojstwa.

------
dely - w takim razie zostaje logiczny bank "zerowy"

52

(32 odpowiedzi, napisanych Programowanie - 8 bit)

Jak se jakieś demo walnie w którekolwiek miejsce (w banku lub poza nim) to żaden handler nie pomoże.

53

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

W csh są jeszcze:
"!n" - wywołuje n-tą komendę od początku historii
"!-n" - wywołuje n-tą komendę od końca historii

Nie wspomniałem o tym, bo jak dla mnie to już za bardzo złożone i nie używam :)

54

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

Właśnie kiedyś robiłem E: na 60 lub 80 kolumn :) Chyba w trybie graficznym (pewnie wolne by było w końcowym efekcie). Ale to dawno i nieprawda, i kod już dawno zaśmierdł (na taśmie).

Co do historii to chyba KMK ma rację - bardziej bym uderzał w kierunku procesora komend niż E:
To chyba bardziej ten poziom.

55

(134 odpowiedzi, napisanych Bałagan)

Drac030, tutaj:

http://atariki.krap.pl/index.php/1850XLD
http://www.commodore.ca/history/company … modore.htm

- 1983: mamy klon Amigi w Atari
- 1984: Tramiel robi wyjazd z Commodore
- 1984: Tramiel wykupuje pakiet kontrolny akcji Atari
- 1985: Mamy ST i Amigę na rynku, ciekawe skąd?

To oczywiście tylko spiskowa teoria, no ale...

Pewnie przed wykupieniem Atari przez Tramiela firma cienko przędła i najlepszych programistów pozwalniała. Ale to tylko moje z palca wyssane przypuszczenia. Stąd pewnie OS trochę gorszej jakości.

56

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

Do Amigi można doinstalować też bash lub csh. Nie pamiętam, ale jak muszę coś shellować to używam (...chociaż nie jestem pewien czy potrzebnie, nie znam dobrze CLI...).

57

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

Przydało by się, przydało...

Oprócz tego w pracy z DOSem przydatny jest czasami "more". Czy w Atari jest coś takiego? (+ strumienie?)

W csh są jeszcze -bardzo- przydatne funkcje historii:
"!!" - uruchamia poprzednią komendę
"!str" - uruchamia komendę z historii zaczynającą się od liter "str"

Inne to już wymagają pamiętania składni, więc nie są aż tak przydatne.

58

(19 odpowiedzi, napisanych Bałagan)

Czyli tak jak mowilem - w Allegro wiele nie zyskałeś. Jedyne co zostaje to dający pewną satysfakcję negatyw... :)

59

(32 odpowiedzi, napisanych Programowanie - 8 bit)

Why not? Ja już ledwo zipie, ale jeśli dla nikogo ten temat nie będzie wystarczająco atrakcyjny to na pewno sam się tym zajme. Temat mi chodzi po głowie od czasu mojej reaktywacji w środowisku Atari. Jak widać z kodu epi temat nie jest czymś złożonym. Zresztą chodzi o interfejs do banków, nie o RAM-dysk czy nowy DOS. Piszę tutaj głównie po to żeby zdobyć więcej info i zobaczyć czy kogoś poza mną to jeszcze interesuje.

60

(32 odpowiedzi, napisanych Programowanie - 8 bit)

Super, dzięki epi! Właśnie takie kawałki (kodu) szukałem.

61

(44 odpowiedzi, napisanych Programowanie - 8 bit)

Większość algorytmów, które znalazłem operuje na zakresie E+/-38. Myślę, że marudzicie.
Do każdej operacji zapisuje algorytm. Myślę, że pierwsza wersja będzie tak jak jest, w następnych będzie można dodać wersję double lub oprzeć się o standardowe formaty float-a.

Co do znaku w bicie a nie w bajcie, to jest to bardzo rozsądne zapotrzebowanie jeśli chodzi o zajętość pamięci, ale wymaga pakowania / rozpakowywania float-a przed i po użyciu, przez co na pewno zwolni całą bibliotekę. Myślę, że na razie poprzestanę na dodaniu funkcji fpack, funpack pakujących do formatu bez extra bajtu znakowego - do zapisania na dysku lub w pamięci.

62

(32 odpowiedzi, napisanych Programowanie - 8 bit)

Nie lubie irca :( Nigdy nie doszedłem jak go uruchomić, nawet wewnątrz UT2004 :D

W takim razie już wiadomo jak to połączyć z DOSem. Będzie trzeba zrobić taki okrojony I/O handler. Trzeba by spisać dokładne API. Spróbuje to zrobić w wolnej chwili (chyba że ktoś mnie ubiegnie).

Oczywiście, że literka musi być nieużywana:
- http://atariki.krap.pl/index.php/Lista_ … C3%B3w_CIO

Na wypadek, gdyby ktoś chciał się tym zająć, kilka linków:

Przykładowe handlery:
- http://tajemnice.atari8.info/10_93/10_9 … ndler.html
- http://www.strotmann.de/twiki/bin/view/ … MemHandler
- http://www.strotmann.de/twiki/bin/view/ … ariHandler
- http://tajemnice.atari8.info/3_92/3_92_handlera.html

Z tego co zrozumiałem, IOCB ma z tym jakiś związek, więc tu jest jakieś wprowadzenie:
- http://atariarchives.planetmirror.com/mmm/iocbs.php

Tu jest coś o bankowaniu w 130XE:
- http://atariarchives.planetmirror.com/m … ndix16.php

A tu o splitowaniu programu w cc65
- http://www.cc65.org/mailarchive/2004-08/4361.html

Tu o procesie RESET i MEMLO:
- http://evilbill.org/Atari/8-Bit/dere/chapt8.html
- http://atariarea.krap.pl/forum/viewtopic.php?pid=38456

Proponuje, aby sterownik miał możliwość przekazywania nieznanych komend do następnego w łańcuchu handlera wybranej literki. Na razie nie wiem jak to zrobić. Inne handlery które można pod to podłączyć to np. handler informujący o konfiguracji sprzętowej (procek, model Atari, wesja OS i wszystko co chcemy uniezależnić od adresów).

Oczywistym następnym etapem po napisaniu takiego bank-handlera będzie implementacja kompatybilnego RAM-dysku. Później możnaby zająć się cc65, żeby był jakiś w tym support.

Pytania:
- czy banki 130XE są zgodne ze wspomnianym "XMS"?
- z tego co wyczytałem, jeśli miałbym XMS to jest szansa tak zaalokować pamięć, żeby Antic nie korzystał z tej samej przestrzeni co 6502. Jak to zrobić?

63

(32 odpowiedzi, napisanych Programowanie - 8 bit)

Właśnie właśnie. Stałe adresy są fe. Możnaby spróbować coś takiego jak w BIOS - jedno przerwanie (a tutaj pewnie jeden wektor) + x funkcji określonych zawartością rejestrów + parametry w RAM zaadresowane rejestrami lub zawartością stosu.

Przy takim rozwiązaniu potrzebne byłyby na stałe dwa bajty. To chyba nie dużo?

Tak sobie gdybam, bo właśnie tego nie wiem - jak to połączyć z DOSem?

64

(32 odpowiedzi, napisanych Programowanie - 8 bit)

TeBe coś kiedyś pisał, że chciałby móc prosto korzystać z całej pamięci w Atari.
W tutorialu cc65 też coś o tym wspomniał.

W związku z tym, że program testowy doszedł mi w cc65 do 14kB i chociaż mam 320kB (RAM-cart) to i tak nie mogę odpalić Numena proponuje zrobić coś takiego:

Sterownik typu EMM386, ładowany w DOS w jakimś autostarcie, maksymalnie niezależny od rodzaju i wersji DOSa, pozwalający na allokację pamięci RAM-carta lub XMS w sposób uniwersalny - niezależnie od posiadanego sprzętu.

Główne funkcje:
- allokacja n banków (wynik: lista - nr banku, adres)
- zwolnienie listy banków (nr banku; nr banku)
- aktywacja / dezaktywacja banku
- informacja o aktywnym nr banku
- możliwość zablokowania przełączenia banku
- informowanie o dostępnej ilości banków (wszystkich / wolnych) i ich rozmiarze
- informowanie o rozpoznanym typie rozszerzenia (może być ciąg znaków + kod)

Allokowane bloki powinny przechowywać informację o tym, że są zaalokowane na trwale lub tymczasowo (np. dla RAM-dysków). Dzięki temu po wyłączeniu kompa RAM-cart nadal miałby poprzydzielaną pamięć - ale tylko dla RAM-dysków lub programów zapisujących coś na stałe.

Kiedyś pisałem sterownik do lepszego E: ale już zapomniałem jak się to robi. Poza tym nie wiem, czy taka informacja była by przydatna w tym projekcie.

Pytania:
- czy coś takiego już istnieje?
- od czego zacząć zgłębianie Atari, żeby coś takiego zrobić (chodzi bardziej o integrację z DOSem, przełączenie banku to chyba banał)

Zenon dystrybuuje kilka DOSów zrobionych specjalnie dla RAM-carta. Czy ktoś wie na czym polegała trudność zrobienia uniwersalnego sterownika do M: ładowanego osobno pod DOSem?
Przecież jest coś takiego jak RAM-CART Handler - TA 10/93, (http://tajemnice.atari8.info/10_93/10_93.html) - więc chyba jest to do zrobienia?

-----
Miłym dodatkiem byłaby obsługa RAMu pod ROMem jako dodatkowego banku.

-----
Odpowiedzi na pytanie: po co?
- żeby móc pisać uniwersalne programy wykrzystujące całą dostępną pamięć
- żeby móc uruchomić RAM-dysk i program wykorzystujący XMS jednocześnie
- żeby nie przerabiać wszystkich po kolei DOSów tylko po to, żeby obsługiwać nowe
  rozszerzenie pamięci

-----
Założenia dodatkowe
- soft powinien móc obsłużyć kilka rozszerzeń na raz
- musi być możliwa współpraca z programami nie korzystającymi z tego
- obsługa do 256 banków

65

(53 odpowiedzi, napisanych Fabryka - 8bit)

Zajrzałem - stosuje "-O". Happy now?

66

(53 odpowiedzi, napisanych Fabryka - 8bit)

Fox napisał/a:
piotrv napisał/a:

667 bajtów - najprostszy program który zrobiłem - czekanie na wciśnięcie klawisza

Sporo zajmuje właśnie ten crt0, który m.in. pobiera linię poleceń z różnych DOSów (w tym tak archaicznych jak DOS XL). Źródło tego (w pliku .s) jest w źródłach cc65.

Ten program był bez wywoływania czegokolwiek - działał na jakimś poke / peek. Ale pewnie i tak coś niecoś z crt się tam wemsknęło.

Fox napisał/a:
piotrv napisał/a:

Wynika z tego że moja prosta funkcja zajeła jakieś 300 bajtów

A kompilowałeś z opcją -O (optymalizacja) ?

Nie wnikałem. Możliwe że nie.

67

(134 odpowiedzi, napisanych Bałagan)

Kod w Terminatorze prawdopodobnie pochodzi z Apple'a. Odwołuje się do VTOC-a ale to raczej termin niż jakaś czysto atarowska właściwość. Natomiast wywołuje procedurę AUXMOVE, której nie znalazłem w połączeniu z Atari, a jest w Apple'u. Do tego na listingach pojawia się termin "Key Perfect".

Tu jest link do listingu z filmu (szukaj JMP AUXMOVE):
  http://lamp.a2central.com/The_Lamp/Text … MP0407.ASC

A tu opis Key Perfect:
  http://www.nibblemagazine.com/nibble_disks.htm

Wszystko zweryfikowane z filmem przeze mnie.

68

(44 odpowiedzi, napisanych Programowanie - 8 bit)

Nie można walczyć z naturą...

Tzn. że 6502 wykorzystuje inny porządek niż 65C816?
Ja na poziomie słowa używam tego co jest w cc65 - więc pewnie natywnego dla 6502.

69

(19 odpowiedzi, napisanych Bałagan)

Ja miałem na allegro dwie przewałki. Ale to już zahaczało o policję. 
Generalnie takiemu nieuczciwemu "lajtowo" - czyli tak jak w tym przypadku - dużo nie zrobisz.
Allegro może co najwyżej go pouczyć.
Za to negatyw trochę go naprostuje. Jest od cholery takich ściemniaczy na aukcjach - po co ich oszczędzać?

Oczywiście propozycja kupna za 1zł jest jak najbardziej na miejscu - tak dla zabawy możesz takiego maila mu wysłać. Ale wiadomo jaka będzie reakcja...

70

(19 odpowiedzi, napisanych Bałagan)

Wystaw mu negatyw i się nawet nie zastanawiaj. A, że na pewno on ci się zrewanżuje to  kopie listu wyślesz do Allegro i ci jego komentarz pewnie bez problemu usuną.

71

(44 odpowiedzi, napisanych Programowanie - 8 bit)

Aktualnie nie rozdrabniam mantysy niżej niż unsigned int, czyli o ile nie stosujesz 32-bitowego procesora to nie będzie problemu.

Co do wydajności, to mam nadzieje, że bardziej skomplikowane operacje wykażą przewagę formatu binarnego. Trochę dziwne, że dodawanie jest tyle razy wolniejsze - ale to pewnie narzut języka to powoduje.

----
Zresztą nawet gdyby się uprzeć i z niewiadomych mi powodów chcieć zrobić mantysę:

man-16-lo | man-16-hi

zamiast aktualnej:

man-16-hi | man-16-lo

to jest to zmiana polegająca na wymianie dwóch elementów struktury - więc jakies 5s pracy wprawnego programisty.

72

(44 odpowiedzi, napisanych Programowanie - 8 bit)

Hihi, tu jest właśnie cały trick. Atari przechowuje wszystko w BCD, ja binarnie. W związku z tym mogę jako tako liczyć w C - patrz mnożenie - niby C a porównywalne z ASM. Jak się to przerobi na ASM, powinno być ze dwa razy szybsze. Na pewno da się coś jeszcze wycisnąć w C - ostatnia przeróbka fmul dała 3x przyspieszenie.

Nie wiem jak były liczone wyniki FASTCHIP na Atariki - jakby ktoś mógł zweryfikować czy z ANTICiem czy bez to byłoby super.

Mój format to float - czyli pojedyncza precyzja. Ale jeśli będzie to C to łatwo będzie dodać obsługę double (dwa razy większa mantysa + większa cecha). Aktualnie nie robie double, bo będzie to po prostu na pewno wolniejsze.

Dlaczego 38? bo 2^128 =ok. E+-38

Wersja double na PC ma zakres ok. E+-308

73

(44 odpowiedzi, napisanych Programowanie - 8 bit)

tebe - nie mówiłbyś tak, gdybyś widział ten mój algorytm na FP->ASCII...
za małą głowę mam, żeby to od razu robić w ASM.
natomiast nie wykluczam, że później znajdzie się ktoś kto będzie miał na tyle dużo samozaparcia, aby to przerobić. Operacje są dość proste - ale jest ich cholernie dużo (jak na ten temat), poza tym pewnie samo C robi spory narzut w wydajności i pamięciożerności. Na razie chodzi mi o to, żeby móc normalnie coś zrobić w tym C - bez float-a się nie obędzie.

aktualna (nie-)wydajność (ANTIC on, emulator ON):

fadd     -  370.0 ops/s (FC - 4880)
fsub     -  370.0 ops/s (FC - 4650)
fmult    -  119.0 ops/s (FC -  380)
fdiv     -   75.1 ops/s (FC -  256)
flog2    -   60.2 ops/s
flog10   -   31.5 ops/s
flogn    -   21.4 ops/s
fsqrt    -   13.5 ops/s
fcbrt    -    3.8 ops/s
fexp     -    1.7 ops/s // (!)

fmult2   - 1666.0 ops/s (FC -  380?) ( z = a * 2 )
fmult2ip - 5000.0 ops/s (FC -  380?) ( a = a * 2 )
fmult10  -  200.0 ops/s (FC -  380?) ( z = a * 10 )
fmult10ip-  208.0 ops/s (FC -  380?) ( a = a * 10 )
fdiv2    - 1666.0 ops/s (FC -  256?) ( z = a / 2 )
fdiv2ip  - 6000.0 ops/s (FC -  256?) ( a = a / 2 )

-----
2006-01-17 Wyniki poprawione z 185 na 333 dla +-
2006-01-18 Dodane fdiv
2006-01-25 Optymalizacja i poprawiony benchmark (przedtem fałszywe wyniki dla mult, div)
2006-01-31 Więcej funkcji, fexp -musi- być poprawiony
2006-02-04 Przyspieszone mult, add, sub, sqrt, cbrt

74

(44 odpowiedzi, napisanych Programowanie - 8 bit)

Czepiaj się - po to napisałem.

Ale gdyby wsadzić znak do wykładnika to już by był za mały zakres - aktualnie już jest mały: E+/38
Zwykle znak wsadzają do mantysy - ale to jest dobre dla kompów, które mają za dużo wolnego czasu. Więc ułatwiam sobie trochę sprawę.

Zrobiłem już +-, wydajność nie jest rewelacyjna, ale za to czyste C. Być może da się to jeszcze zoptymalizować w C, a może trzeba będzie na końcu to przerobić na ASM.

Aktualnie wydajność dodawania i odejmowania to ok. 185 operacji / s (FASTCHIP: 4880/s) - test na emulatorze z aktywnym ANTIC-iem.

Jeśli starczy mi siły i będzie zainteresowanie, to dorobienie wersji double w C będzie już o wiele prostsze.

Niestety testowy EXEC rośnie w tempie zastraszającym... Na razie 9.7kB (!)

75

(134 odpowiedzi, napisanych Bałagan)

Skoro i tak ten wątek ma już 3 strony...

Atari ST vs Amiga - c.d.
Mi tam bardziej (pod względem hobbystycznym) od ST pasuje Amiga. Jeśli chodzi o gry to bez dwóch zdań. Grafika ładniejsza. Ale ST mało widziałem, parę razy tylko grałem, więc: Amiga jest łatwiejsza do rozbudowy. Do dzisiaj działają firmy, które sprzedają mnóstwo kart rozszerzeń do Amisi. HDD, RAM, full akcesoriów. Że o Allegro nie wspomnę. Ten rynek po prostu ze 4-5 razy silniej żyje (porównajcie sobie ilości aukcji).

Do A600 podłączyłem sobie HDD praktycznie za jednym zamachem. Wystarczyło byle jakie HDD 2,5" + nowszy ROM + parę drutów. A HDD w ST? 20MB? Ze świeczką szukać. To już Atari 8-bit ma chyba lepsze możliwości pod tym względem.