5,926 Odpowiedź przez xxl

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

> Co do CPU, z twoich słów wynika, zdaje się, że dążysz do tego, żeby zrobić z VBXE oddzielny komputer

zupelnie nie...

> Ogólnie dyskusja jest akademicka, bo jak nadmienił electron, w rdzeniu nie ma miejsca na nowe rzeczy.

i kolejny raz... nie chce dolozenie nowych funkcji do rdzenia ktory jest standardem FX i ktorego ja nie chce ruszac.

> Łatwym do przewidzenia skutkiem będzie to, że soft będzie wykorzystywał tylko to, co działa w obu rdzeniach. Albo nie będzie powstawał wcale (vide postawa tebego, ja szczerze mówiąc też już w pewnej chwili miałem dość, kiedy się okazało, że blitter zmienia się z wersji na wersję - na szczęście się ustabilizował i mi przeszło).

najprawdopodobniej nie bedzie funkcji ktore beda tak samo dzialac na tym rdzeniu (jesli powstanie) i FX. jesli programisci uzywaja FX to dlaczego mieli by przestac skoro FX jest standardem? dlatego ze xxl bedzie mial inny rdzen? myslisz ze mam taka moc? :D
skoro odnajdujesz radosc w programowaniu na FX to raczej nie jest temat dla Ciebie... szukam progrmistow, ktory chcialby uzywac tego 'zamowionego' rdzenia - sam nie przekonam electrona ale w grupie... dlatego rozpisywanie sie osob, ktore nie beda tego uzywac to tylko zaciemnianie tematu

---
ale do tego sie ustosunkuje:
> zauważ, to CPU, żeby można było uniknąć mapowania trybu do przestrzeni adresowej 6502, musiałoby być co najmniej złożoności normalnego procesora typu 6502 albo Z80. Już nie mógłby to być uproszczony procesorek pomocniczy, gdyż w takim wypadku konieczność mapowania VRAM-u do dostepu dla 6502 ciągle by zachodziła, a tu możność zmapowania jej w jednym kawałku - to zaleta.

dlaczego ograniczac mozliwosc mapowania? dlatego w pierwszym poscie napisalem tez o rozwinieciu memaca, a jesli nie mapowac tylko zalatwoc to cpu w vbxe to wystarcza 2 lub 3 tryby adresowania (zalezy jak realizowac) i 2 rejestry cpu + 1 lub 2 znaczniki procesora.

Idź do forum: Sprzęt - 8bit

5,927 Odpowiedź przez xxl

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

@mono, ciekawe, ale moim zdaniem zrodla rdzenia nie powinny byc publiczne, dlatego tez bylem i jestem przeciw jakimkolwiek zestawa devloperskim do generowania rdzeni vbxe. dlatego tez zwrocilem sie do electrona, i staram sie, i bede sie staram wszystkimi mozliwymi sposobami przekonac go do swoich racji ;-)

a uporem maniaka wracam do tego conajmniej od wersji w ktorej pojawil sie memacA w takiej postaci jak jest teraz...

powtarzam kolejny kolejny raz, nie chce zmieniac standardu ktorym jest FX. chce rdzenia 'na zlecenie' z funkcjami jak opisalem - byc moze jakiemus programiscie tez sie przyda...

obecenie jest tak, ze niektorych rzeczy nie da sie zrobic na vbxe, wiec musze niektore rzeczy upraszczac/zmieniac, a skoro juz to robie to wprowadzam modyfikacje tak, zeby gra ruszyla na standardowym atari.... i tym sposobem gry nie bedzie na vbxe... tak to niestety wyglada obecnie :/ nie stawiam sprawy na ostrzu noza bo to nigdy do niczego nie prowadzi ale z mojego punktu widzenia FX nie ma nalezytego wsparcia dla tych ktorzy chca pisac gry na vbxe.

@draco30 z tym trybem 160 i jego zaleta, ze miesci sie w pamieci ktora bezposrednio moze adresowac 6502. przedstawiasz wade vbxe jako zalete. gdyby w vbxe byl cpu z dostepem do calej pamieci vbxe to nawet bys nie pomyslal o trybie 160. co wiecej, dzieki cpu w vbxe mozna by ja zorganizowac np. tak jak jest w TMS9918 - ale znowu... to jedna z wielu, wielu mozliwosci...

Idź do forum: Sprzęt - 8bit

5,928 Odpowiedź przez xxl

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

swietnie, ze wyjasniacie sobie sprawy, ktore nie sa przedmiotem tego watku. juz na poczatku pisalem, ze sprawa dotyczy vbxe w obecnej wersji.

> zrobcie cos

zrobimy.

dajcie rdzen o ktorym pisze.

Idź do forum: Sprzęt - 8bit

5,929 Odpowiedź przez xxl

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

co zmieni kolejna versja vbxe w moim przypadku? co zmieni w przypadku tych kilkudziesieciu osob ktore maja wersje obecne?

jeszcze raz powtarzam, nie chce zmieniac standardu ktorym obecnie jest rdzen fx. mowie o rdzeniu ktorego baza ewentualnie moze byc fx ale nie bede sie upieral jesli baza bedzie rdzen emulacji gtia !


---
jesli miejsca jest tak dramatycznie malo to mozna wybrac tylko to co jest faktycznie uzyteczne a bajery wylatuja, przyklad:
- tylko 3 tryby: tekstowy 80, tekstowy 40, graficzny 320, tylko 2 szerokosci obrazu
-  tylko 2 priorytety dla overlaya (nad/pod playfieldem)
- mapa atrybutow wlaczana zawsze z xdl wielkosc zawsze taka jak komorka trybu xdl (dla trybu graficznego overlaya brak mapy atrybutow)
- planarna organizacja mapy atrybutow dla pixela i tla (duzo prostrza)
- kolor0 zawsze przezroczysty dla overlaya i m.atrybutow
- usunac detekcje kolizji overlaya
itp.

dla mnie najwazniejsze jest to co napisalem w pierwszym poscie, co do reszty mozna zawsze podyskutowac...

Idź do forum: Sprzęt - 8bit

5,930 Odpowiedź przez xxl

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

kazdy glos mowiacy 'blitter musi odejsc' odbieram jak glos poparcia ;-)

nie... jako glos poparcia dlatego go odbieram, ze wlasnie ta wspolna plaszczyzna jaka jest pelna emulacja gtia jest najwazniejsza a nie widze kurczowego trzymania sie fx ;)

oczywiscie nie kwestionuje FX dla vbxe jako standard... potrzebuje czegos podobnego do tego standardu ale bardziej uzytecznego ...

@electron: jesli ten "skok w bok" bedzie mial emulacje gtia to nie sadze zebym zmienil go na rdzen fx ...

Idź do forum: Sprzęt - 8bit

5,931 Odpowiedź przez xxl

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

to ze nie ma miejsca wszyscy wiedza (ja tez ;) rozchodzi sie o to co usunac, zeby miejsce sie znalazlo...

tak, blitter w takiej formie zniknie ale pojawi sie cos bardziej uzytecznego co zreszta moze 'emulowac' rowniez blitter, pytanie czy szybkosc bedzie do zaakceptowania.

Idź do forum: Sprzęt - 8bit

5,932 Odpowiedź przez xxl

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

@drac030
owszem, to jest jasne. trzeba przedyskutowac za/przeciw, sprawdzic jaki bedzie koszt takich modyfikacji (kosztem jakich funkcji vbxe mogly by byc wprowadzone). ja zauwazylem, sa funkcje vbxe, ktore fajnie wygladaja ale na papierze, uzytecznosc maja albo ograniczona albo nie maja jej wcale - to moje zdanie, byc moze inni programisci odnajda w pomysle jak w pierwszym poscie cos co pozwoli im pchnac jakies swoje projekty na vbxe do przodu. po wtore, tak, emulowany blitter bedzie wolniejszy (o ile nie wiem, mozna sie dowiedziec) ale wzrosnie uzytecznosc takiego rozwiazania a tego nie mozna niedocenic.

@electron
karta vbxe rozpoczales pewna rewolucje... jest pewien niedosyt i trzeba to doprowadzic do konca, takie jest moje zdanie.
z tym 75% przesadziles ;-) teraz sprawdzam i tylko 66% wybralo "pomidor" :D
Tebe jak to Tebe... czeka tylko zeby wbic zebiska w nowy rdzen ;-) (*)

> cięcia musiałyby być większe

jak duze. podejrzewam, ze jestes zwolennikiem pelnego cpu, wez pod uwage ze moze nie wszystko w takim cpu jest potrzebne a funkcjonalnosc nadal bedzie zachowana.

> że MPU w zadaniach typowo blitterowych (przesyłanie, wypełnianie itd.) będzie dużo dużo wolniejsze od istniejącego blittera

tak, to jest jasne. moglbys powiedziec cos, oczywiscie teoretycznie o szybkosci takiego cpu?

> Decyzję czy coś robić uzależniam ostatecznie od tego, czy ktoś jeszcze wyrazi zainteresowanie i np.spiszemy umowę na 3 gry

jesli nie bedzie zainteresowania to biore to na siebie :p

@jellonek
zanim napisalbym emulacje gtia na poziomie tej electrona to dopadnie mnie kryzys wieku sredniego, kupie harleya i bede podrywal cycate 20-stki. innymi slowy moge miec juz inne priorytety ;-)

to bardzo, bardzo zly pomysl, juz raz o tym pisalem. sam devpack to zly pomysl, udostepnianie zrodla corea to tez zly pomysl i programowe przelaczanie corea to tez bardzo zly pomysl.


(*) Luz Tebe.

Idź do forum: Sprzęt - 8bit

5,933 Odpowiedź przez xxl

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

> do rejestrow sprzetowych nie zapisze ci mini cpu, midi cpu, ani nawet haj tower cpu - ka pe wu?

a gdzie napisalem ze zapisze?

wyraznie napisalem ze nie zapisze:

>(zapis do rejestrow oraz do pamieci vbxe - wiadomo, ze z poziomu np blittera nie zapiszemy rejestrow sprzetowych ale jak bedzie minicpu w rdzeniu to przynajmniej bedziemy mogli czytac co zostalo do rej.sprzetowych wpisywane)

to teraz wolniej napisze: bedzie mozna czytac to co zostalo do rejestrow sprzetowych zapisane przez 6502 a znajdzie sie jako cien w pamieci vbxe poprzez:

> oraz kontroli zapisu do pamieci vbxe gdy zaslaniana jest przez rejestry sprzetowe

jeszcze wolniej:

umozliwic konfiguracja memacA gdy czesc pamieci vbxe zaslania rejestry sprzetowe aby zapis do rejestrow sprzetowych (przez 6502) powodowal zapis rowniez do pamieci vbxe (tej zasloietej)

a to jest mozliwe.

Idź do forum: Sprzęt - 8bit

5,934 Temat przez xxl

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

witam,

temat w stylu "czego mi najbardziej brakuje", moze ktos sie jeszcze przylaczy i uda sie wywrzec odpowedni nacisk na wiadomo kogoko...

1. rozdzielenie rejestru MEMAC_CONTROL na dwa, jeden odpowiedzialny za umiejscowienie okna pamieci z dokladnoscia do jednej strony (starszy nibbel starego rejestru), a drugi do ustalenia wielkosci okna, dostepy antic i cpu (mlodszy nibbel starego), dodanie przynajmniej 2 nowe wielkosci okna $100 i $ffff oraz kontroli zapisu do pamieci vbxe gdy zaslaniana jest przez rejestry sprzetowe (zapis do rejestrow oraz do pamieci vbxe - wiadomo, ze z poziomu np blittera nie zapiszemy rejestrow sprzetowych ale jak bedzie minicpu w rdzeniu to przynajmniej bedziemy mogli czytac co zostalo do rej.sprzetowych wpisywane)

2. wprowadznie trybu tekstowego z 256 zestawem znakow przy standardowej wielkosci pixela (obecnie vbxe udostenia taki tryb z pixelem rozdzielczosci 640)

3. wprowadzenia do rdzenia mini procesora (wystarcza znaczniki NZC itd. rejestry dostepne na stronie D6/7xx, napotkanie nierozpoznawanego kodu kasuje flage BUSY... podobnie jak obecnie blitter itd. )

takie zmiany moga byc zrobione kosztem (usunieciem z obecnego rdzenia):

- blitter i caly powiazany sys.kolizji (z mini cpu mozna napisac blitter, ktory bedzie mial lepsze funkcje niz obecny - np. rysowanie odcinkow)
- z czterech definiowanych palet wystarcza dwie

i jeszcze jedno, nie chodzi o vbxe w wersji 3 lub 5, chodzi o istniejace obecnie wersje vbxe

czas wprowadzic odrobine nerwowej atmosfery na forum ;-)


----
UPDATE 24.05.11

malo miejsca. wieksze ciecia. zostaje tylko:

1. emulacja GTIA
2. MEMAC - punkt pierwszy powyzej
3. mini cpu - punkt trzeci powyzej

cala reszta odpowiedzialna za video nowe tryby itp. moze zostac usunieta.

----
UPDATE 31.08.11

MEMAC jako modul nie zajmuje zbyt wiele - rozszerzenie mozliwosci do punktu 2:

- dodanie nowego trybu do memaca - trybu cardridge, konfigurowana rozmiar, miejsce i typ carta - np. cardridge serwisowy
potrzebny do tego kabel fix.

przyklad uzycia: bootujemy atari z programem ktory skonfiguruje pamiec vbxe na carta serwisowego, zapisze w nim program. po tej operacji uruchamiamy dowolna gre, naciskamy kombinacje klawiszy konsoli i reset, atari wykona zimny start bez kasowania pamieci, uruchomi sie kart serwisowy, program na karcie kopiuje sie w wybrany obszar pamieci i dezaktywuje karta. w tym momencie mamy w pamieci gre i nasz program ktory moze posluzyc jako ripper.
inny przyklad: nagrywamy obraz karta z gra i zimny reset - gra sie uruchamia

a skoro potrzeba zrobic kabel fix to przy okazji:

4. kabelek podlaczony do audio in w gniezdzie carta lub sio. rejestr na stronie d6 do ktorych dostep ma mini cpu rdzenia. pozwoli generowac dzwiek bez udzialu 6502.

Idź do forum: Sprzęt - 8bit

5,935 Odpowiedź przez xxl

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

zestaw:
1. przelotka/przedluzacz eci + cart (z podlaczonym sygnalem audio in) dla karin
2. kompletny poskladany interfejs i w obudowie
3. wysylka

taki zestaw ile kosztuje?

rozumiem, ze jest to kopia karin maxi geislera? one nie mialy zadnych problemow z dzialaniem z roznymi modelami atari - tu jest tak samo?

i jeszcze jak sie ma sprawa z napedem? nie wiem czy dobrze pamietam, ze stacje 3'5 z pc lub st podlaczalo sie bezposrednio? czy moze przecinalo sie jakis kabelek w tasiemce?

Idź do forum: Sprzęt - 8bit

5,936 Odpowiedź przez xxl

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

jakis czas temu juz ta gre poprawilem do dzialania z sdx i vbxe...

http://atariarea.krap.pl/forum/viewtopi ... 30#p111430

Idź do forum: Software, Gry - 8bit

5,937 Odpowiedź przez xxl

(15 odpowiedzi, napisanych Sprawy atari.area)

no to jest juz dwoch chetnych

Idź do forum: Sprawy atari.area

5,938 Odpowiedź przez xxl

(1,653 odpowiedzi, napisanych Bałagan)

YERZMYEY/HOOY-PROGRAM napisał/a:

Chociaż niektórych gier nie da się przejść nawet z POKE'ami. Ha.


sa Poke-i i POKE-i... podeslij program w TAPie zobaczymy co sie da zrobic ;-)

Idź do forum: Bałagan

5,939 Odpowiedź przez xxl

(27 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

macgyver napisał/a:

... posiadał (w ostatnich wersjach) m.in. mapowanie rejestrów sprzętowych do RAM.

o cos takiego prosilem swojego czasu electrona, odpowiednio skonfigurowany memacA, oraz konfigurowalny rownoczesny zapis do rejestrow sprzetowych oraz pamieci vbxe ktora znajduje sie 'pod'.

Idź do forum: Kupię / Sprzedam / Zamienię Atari

5,940 Odpowiedź przez xxl

(19 odpowiedzi, napisanych Fabryka - 8bit)

nie pomoge w edycji ale klikam w lubie to.

Idź do forum: Fabryka - 8bit

5,941 Odpowiedź przez xxl

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

jest nowy test do sciagniecia: http://www.virtualdub.org/downloads/Acid800-0.8.7z

POKEY: Init timing... FAIL
Incorrect 64KHz cycle count (odd): $1D

Idź do forum: Software, Gry - 8bit

5,942 Odpowiedź przez xxl

(60 odpowiedzi, napisanych Fabryka - 8bit)

> No i tu własnie fundamentalnie błądzisz, bo DOS jest po to, żeby nie trzeba było (= żeby program użytkownika nie musiał) pamiętać, jaki jest filesystem, ani liczyć sektorów. Fakt, że niektóre DOS-y tego nie zapewniają świadczy tylko o tym, jak są prymitywne i gdzie powinny wylądować. Na szczęście Atari jest tak zrobione, że można sobie DOS wybrać.

teraz tak jest, dos to zapewnia a nie program usera. dos program dzialajacy po stronie atari zarzadzajacy filesystemem na urzadzeniu zewnetrznym :-) caly czas wlasnie o tym mowimy. caly czas wlasnie to walkujemy.

> Jak już o tym była mowa, to nie jest żaden bug, SDX nie będzie poświęcać ~40 cykli przy _każdym_ przełączeniu banków (a robi to _bardzo_ często) na zachwywanie stanu MEMAC A, skoro bez większego wysiłku (i tylko przy ładowaniu danych) może to zrobić sam program.

vbxe jest kolejnym urzadzeniem, ktore ma mozliwosc przelaczania pamieci, gdyby powstalo jakies inne rozszerzenie pamieci mogace przelaczyc swoje banki w adresie $4000 to tez napiszesz ze sdx nie bedzie go obslugiwac?
i o tym tez juz pisalismy, dos (kazdy) w takiej postaci jak na atari generuje mnostwo problemow a dzielni programisci rozwiazuja te problemy, rozwiazuja i rozwiazuja, to proces ktory nigdy sie nie skonczy. jesli zamiezasz pomysl, ktory tu dzis omawiamy sprowadzic do sterownika dla dosa zeby mozna bylo kopiowac dane to chyba jeszcze nie czas na zmiany :(

Idź do forum: Fabryka - 8bit

5,943 Odpowiedź przez xxl

(60 odpowiedzi, napisanych Fabryka - 8bit)

babcia malinka mowila z glupim sie nie nagadasz, najpierw sprowadzi cie do swojego poziomu a pozniej wygra doswiadczeniem ...


a odpowiadajac na posta:

http://i150.photobucket.com/albums/s85/Stebthefirst/TripleFacePalm.jpg

Idź do forum: Fabryka - 8bit

5,944 Odpowiedź przez xxl

(60 odpowiedzi, napisanych Fabryka - 8bit)

> Opisujesz SpartaDOS X.  Niestety, tego (zwł. obsługi ramdysku i alokacji pamięci, buforów I/O) raczej się nie zmieści w 2 KB.

sadze ze jednak moze zajac i to mniej jesli nie bedziemy operowac na filesystemie i komunikacji narzucanej przez dos

> Dodam że SDX jest tak skonstruowane, że od biedy można byłoby w ten sposób w ogóle przekierować całą obsługę dysków na zewnątrz przez taki sterownik.

i tu dotykasz funkcji ktore powinien zapewnic os, ale sdx jako nakladka na os to inny temat...

> Tylko nie ma po co, lokalny twardy dysk jest o wiele lepszy.

no wlasnie nieprawda, cala rozmowa sie wlasnie zaczyna od tego (w moim rozumieniu) obsluga filesystemu na zewnatrz a nie po stronie atari liczyc sektor xxx pozniej oblicz kolejny adres sektora, zaladuj xxx a pozniej jeszcze yyyy

> Obchodzi, jeśli ma pamięć masową, do której nie sięga wyobraźnia autora programu (e.g. całodyskowy SynFile vs stacja 720k).

nie! przykladowo siegam do bajtu yyyy otwartego pliku a nie obliczam gdzie ten bajt lezy czaly czas pamietajac jaki jest filesystem, laduje sektor i dopiero dana yyyy. !!! wracasz do punktu wyjscia a bylo juz tak dobrze

> Nie, po prostu musisz uważać, gdzie i jak ładujesz dane.

eeee, ladujac do podstawowej pamieci atari w tych adresach to sie nic nie stanie ale jesli zaladujesz do pamieci vbxe w tych adresach to zwis... w pierwszym i drugim przypadku nie ma tam programu sdx, niestety to bug do poprawy.

Idź do forum: Fabryka - 8bit

5,945 Odpowiedź przez xxl

(60 odpowiedzi, napisanych Fabryka - 8bit)

> Jakiś sterownik wprawdzie wciąż jest potrzebny, ale znacznie mniej skomplikowany

oczywiscie, sterownik taki moze zajac z 2kb ramu i moc obsluzyc rozne rodzaje nosnikow, rozne wielkosci, ramdysk, alokacje pamieci, nowe funcje (nie tylko pamiec masowa), byc odpornym na zmiane filesystemow :-) takiego sterownika nie trzeba by aktualizowac w przypadku gdy np.jakies urzadzenie bedzie mialo nowe funkcje itd.

> I wtedy koniec z możliwością wyboru DOS-a, użytkownik jest skazany na coś w rodzaju tego, co mamy na C-64 albo ST

co usera obchodzi jak skladowane sa dane? z punktu widzenia sterownika d: nic sie nie zmieni nawet jak zmienimy filesystem. interesuje nas kompatybilnosc na poziomie danych.

> Moim zdaniem ideałem jest mieć jedno i drugie,

zachowawcze podejscie, laczac metody poglebia sie wady pierwszego i radykalnie zmnniejszajac funkcjonalnosc drugiego.
chyba ze to ma byc forma przejsciowa przed ostrym cieciem - czas na dostosowanie oprogramowania.

> standardowe memlo w okolicach $1000, czyli zajmuje 2,5 KB głównego RAM-u - plus oczywiście 1 bank ext

czyli 2,5 + 16kb
daleko szukac, to tez jest wada, zalozmy ze konfiguruje memacA na $4000 i przeprowadzam ladowanie do pamieci VBXE... oooopsss, sparta sie zawiesila :( potrzebna aktualizacja dosa czyli wymiana albo przeflashowanie kostki, dos (w starym rozumieniu) powinien sprawdzac rozszerzenie pamieci vbxe.
 
w przypadku o ktorym wyzej rozmawiamy takich niespodzianek wogole by nie bylo.

> Głównym ograniczeniem DOS2DOS jest spory narzut "komunikacji służbowej".
> Czyli DOS-a nie da się tak znowu prosto pozbyć, nawet jeśli się go statycznie wkompiluje do programu.
 
nie jestem przekonany, wydaje mi sie za to ze wlasnieu 'ogladanie sie' na dosa generuje naddatki kodu.

ostatnio wlasnie sie zastanawialem zeby przejsc na pisanie programow 'calodyskowych' gdzie sterownik moze zajac 1kb, mozemy komunikowac sie z pamiecia masowa, pozbywamy sie co prawda filesystemu ale zyskamy np alokacje pamieci... tylko ze to tez nie jest idealne i w przypadku gdy powyzszy pomysl wypali traci racje bytu.
dlatego trzymam kciuki mocniej bo mam nadzieje bedzie to rewolucyjna zmiana.

Idź do forum: Fabryka - 8bit

5,946 Odpowiedź przez xxl

(60 odpowiedzi, napisanych Fabryka - 8bit)

> ale to nie jest krytycyzm dla Draca, tylko zapedow XXL'a
> idealna platforma dla XXL'a to C128D z ULA

http://i61.photobucket.com/albums/h50/Szeszkin/1275389857_naked-gun-facepalm.gif

> Idea dosa jest dobra, bo oprócz tego, że pożera pamięc, każdy może sobie zrobić dosa bez szeregu ograniczeń.

w dosie siedzi diabel. mozesz sobie zrobic dosa z cala masa ograniczen, od czasu do czasu krzyknac f**k yea mam sektor 512b! problem rozwiazany!... co i tak nic nie zmienia bo problem jest nadal a dodatkowo pojawiaja sie jeszcze 3 kolejne :D

> Czyli poprostu chcesz, żeby dos był w stacji

nie, sterownik d: jest sterownikiem pamieci (program na atari), czesc odpowiedzialna za sama obsluge filesystemu musi spoczywac na urzadzeniu czyli jesli to ma byc ramdysk to nadal atari :-) ale juz bez tych narzutow ktore teraz stwarza dos, jesli to ma byc dysk pc to ... no? pc.

Idź do forum: Fabryka - 8bit

5,947 Odpowiedź przez xxl

(60 odpowiedzi, napisanych Fabryka - 8bit)

nareszcie krok w dobrym kierunku. cos co userzy komputera 'z okreslonego obozu' maja od zawsze (standardowa funkcjonalnosc) teraz okazuje sie byc wlasciwe tez dla atari.
czas najwyzszy przestac powielac opinie dzialu marketingu atari sprzed 30 lat jaki to atari os jest 'przemyslany', jest wiele do zmiany i ta zmiana jest jedna z wazniejszych. tylko jak zwykle, zmiana ewolucyjna czyli nakladka na nakladke, dobra idea a stare ramy. to musi byc zmiana rewolucyjna.

problemem malych komputerkow (jednym z wielu) jest dostepna pamiec:

1. pamiec operacyjna (dla procesora) - bardzo deficytowa a zwlaszcza na atari
2. pamiec masowa (trwala, dyskietki,dyski,sd,cd itd) ale rowniez ramdysk

w zastanej rzeczywistosci zeby wykonywac operacje na pamieci masowej trzeba do operacyjnej zaladowac program 'dos'  (urzadzenie d:) przez co tracimy okolo 8kb :D i tu potwierdza sie ze programisci atari to byly niezli jajcarze. jajcarze magicy, bo przekonali userow, ze tak ma byc i to jest dobre. w.mnie idea takiego dosa jest zla bo oprocz tego ze pozera pamiec operacyjna to naklada szereg ograniczen z ktorymi programisci walcza do dzis np. ilosc wpisow w katalogu, wielkosc pliku, kompatybilnosc itd. itd. itd. sterownik d: powinien umozliwiac operowanie na pamieci np:
wymioana danych:
- zaladuj dane z pamieci masowej do operacyjnej
- duplikuj dane w pamieci masowej itd. ale ciezar obslugi np filesystemu musi spoczywac na urzadzeniu do ktorego pamiec nalezy - w tym wypadku urzedzeniu zewnetrznym
ale rowniez np. mapowanie pamieci:
- np.alokuj 4x$1000 bloki pamieci masowej i mapuj na $C000 pamieci operacyjnej

z tymi zasadami wlasciwie zgodne mogly by byc urzadzenia takie jak ca2001 i ldw2000 z dodatkowa pamiecia, karin maxi, kmk/idea, sio2sd ale nie xf551 albo 1050

mozna to rozszerzyc na sio2pc a wtedy mozliwe bylo by rowniez oprocz powyzszych takze operowanie na bazach danych z poziomu atari albo obslugi sieci - bez koniecznosci ladowania jakis fikusnych dodatkowych sterownikow dla atari:)

zalety w stosunku do znanych na atari dosow:
1. brak ograniczen co do wielkosci pliku
2. brak ograniczen co do dlugosci nazw plikow
3. brak ograniczen co do wielkosci np. dyskow
4. niskie memlo nie do osiagniecia przez zaden dos
5. nowe mozliwosci :-)

dlatego trzymam kciuki bo byc moze przerodzi sie to w cos lepszego niz tylko nakladke na sparte do kopiowania plikow.

to mowilem ja, jarzabek waclaw.

---
to chyba moj najdluzszy post. uronilem lezke

Idź do forum: Fabryka - 8bit

5,948 Odpowiedź przez xxl

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

dokumentacja mowi o poprawie stabilnosci przy podnoszeniu wersji 1.2 na 1.22 obawiam sie ze to moze byc cos z atarka nie tak, zrob test acid800

http://www.atariage.com/forums/index.ph ... 434b9a0473

moze gdzie tu jest odpowiedz.

---
znalazlem starego posta czego te zmiany dotyczyly:

"Mnie i kilku innym osobom zdarzyły się problemy typu mrugający obraz, kaszana na PMG itp. Problem polega na zbyt opóźnionym przechwytywaniu danych z szyny po opadającym zboczu PHI2 - w efekcie w niektórych komputerach np. po rozgrzaniu sprzętu występowały zapisy błędnych wartości do rejestrów emulowanego GTIA czy też rdzenia FX albo VRAM. Problem poprawiłem przez synchronizację z PHI0 zamiast PHI2. PHI0 wyprzedza PHI2 mniej więcej o 40-50ns."

Idź do forum: Sprzęt - 8bit

5,949 Odpowiedź przez xxl

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

na 1.2 dziala na 1.24 kiszka a co jest z 1.22 ? sprawdzales?

Idź do forum: Sprzęt - 8bit

5,950 Temat przez xxl

(2 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

golasa, ma ktos na sprzedaz?

Idź do forum: Kupię / Sprzedam / Zamienię Atari