576 Ostatnio edytowany przez Pecus (2013-01-09 22:11:09)

A przeczytałeś to, co napisałem? ROM może być wyłączony nie ma problemu, przecież program wywołując funkcje xbiosu wstrzymuje swoje działanie i przy dobrym zaprogramowaniu xbios może sobie na chwilę ROM włączyć i przywrócić jego stan po zakończeniu transmisji, a program tego nie zauważy - dla niego ROM będzie wyłączony. Nie widzę potrzeby zostawiania wyłączonego ROMu na czas komunikacji, skoro program który tę komunikacje inicjuje i tak wtedy nie działa (oczywiście XXXL zaraz wymyśli procedurę odtwarzania muzyki umieszczoną dokładnie w obszarze ROMu i podmieniającą główne wektory przerwań - ale nawet wtedy po prostu na czas włączenia ROMu przestałaby grać ta muzyka - rozumiem że to za duże wyrzeczenie).

Dlatego pisałem wcześniej, że projekt ten (abstrahując od jego ogólnej koncepcji) idzie w głupią stronę. Ta strona to efekciarstwo godne dem (kosztem wygody użytkownika), a nie poprawa użyteczności i zgodności ze standardowym sprzętem.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

577

nie zapominaj o tym, ze ladowanie na strone zerowa bylo by kwestionowalne - wszak tak byc nie moze - hanba to

przechodze na tumiwisizm

578 Ostatnio edytowany przez Pecus (2013-01-09 22:31:46)

Dlatego pisałem wcześniej o tym, że wymagałoby to "poświęcenia" kilkunastu komórek strony zerowej i kilku strony 3.... Przynajmniej tych odpowiadających za obsługę SIO i podstawowych przerwań, za to prawdopodobnie MEMLO xbiosa byłoby o jakieś 100b niższe, użytkownicy QMEGa mieliby swoje turba, ramdyski itp., KarinMaxi by działała i inne urządzenia PBI też...

No ale te funkcjonalności nie przebiją muzyki w czasie ładowania z szybkością standardową z długimi odstępami między sektorami :)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

579

Pecus: rom ma byc wylaczony bo pod nim jest procedurka grajaca nute w trakcie wczytywania!

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

580

xxl napisał/a:
grzybson napisał/a:

Ale jednak zawsze pod ROM. A z twoich wypowiedzi wynikało, że to "exclusive feature xBios", a pod DOSem tego w ogóle się nie da. A to nie prawda.

i podtrzymuje, only xbios make it possible.
(...)
oczywiscie, dlatego xbios moze ladowac do ramu pod rom a dos nie :D

Sorry, ale już głupi się robię. DOS też może ładować bezpośrednio do ROM pod RAMu, co zostało udowodnione. Co prawda nie w każdy obszar, ale jednak to ciągle jest RAM pod ROM. Więc dlaczego ciągle umniejszasz DOSom?
xBios co najwyżej potrafi ładować w DOWOLNE (<- słowo klucz) miejsce pod ROM, to jedyna różnica.

grzybson/SSG^NG

581 Ostatnio edytowany przez Pecus (2013-01-10 01:02:48)

Jak pisałem wcześniej dowolny DOS czy loader po modyfikacji (nie więcej niż 30 bajtów) będzie ładował w DOWOLNE miejsce pod ROM (poza jednobajtowym blokiem pod adres $FFFF, którym to przypadkiem XXXL wielokrotnie dowodził wyższość jego rozwiązania ;) ).

Jednak jak widać modyfikacja taka nie była nigdy nikomu do niczego przydatna, choć jest bardzo prosta do wykonania.


A tak na marginesie a gwoli wyjaśnienia XXXL jest dla podkreślenia wielkości XXLa. Takie małe XXL to po prostu za mało, więc proszę bez skojarzeń z XXX - nie o to mi chodziło.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

582 Ostatnio edytowany przez xxl (2013-01-10 08:52:03)

i znowu fantazje... gdyby, gdyby... gdyby powstal taki dos :-) to nadal nie mozna by bylo umiescic pamieci ekranu powyzej $c000, programu ANTICa tez nie, obslugi przerwan, caly czas utrzymane ograniczenia dotyczace pamieci ponizej memlo, o stronie zero juz nie mowiac - juz samo memlo prawie ze w kosmosie, niekompatybilne NOTE i POINT, brak binary load z dowolnego punktu itd. itd

Pecus napisał/a:

Jednak jak widać modyfikacja taka nie była nigdy nikomu do niczego przydatna

teraz juz wiesz dlaczego :-) probujesz rozwiazac jeden problem DOS, powstaje 10 nowych. i jeszcze to nieszczesne api ... zeby zrobic cokolwiek NAJPIERW trzeba znalezc wolny kanal komunikacji :D w swiecie bialych ludzi to jest nie do pomyslenia.
i jeszcze umiescili kanaly w stalym miejscu pamieci... eee zabierz odemnie ten szajs :D

@Grzybson w poscie 564 ma napisane dlaczego Twoj pomysl moze sprawdzic sie tylko na niektorych komputerach i to jeszcze tylko w niektorych obszarach pamieci.

http://atari.pl/hsc/ad.php?i=1.

583 Ostatnio edytowany przez tebe (2013-01-10 10:49:16)

nie chcemy małych kroczków chcemy kopa z xBios-a :D

zwróciliście uwagę na pierwszy wpis w tym przydługim wątku "mysle ze temat skierowany jest do programistow gier .... oferta" i potem wypowiadają się osoby zainteresowane wykorzystaniem tego pomysłu

kiedyś pisało się mniejsze produkcje a jak ktoś się zbytnio rozpisał i chciał wydać grę to nie było zmiłuj, tnij pan do 16K to wydamy (Montezuma Revenge/Preliminary Monty), wydawca dyktował warunki, czasy się zmieniają, produkcje są coraz większe, a wydawcami są fani którzy są autorami takich produkcji np. taki Prince Of Persia na C64 gdzie lwią część zajmują klatki animacji bohatera

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

584

@xxl
Ok. Nie neguję, że tylko w pewnych obszarach pamięci i może być to ryzykowane - ale jednak zawsze da się :D

grzybson/SSG^NG

585 Ostatnio edytowany przez Amun-Ra (2013-01-10 11:37:46)

tebe napisał/a:

nie chcemy małych kroczków chcemy kopa z xBios-a :D
kiedyś pisało się mniejsze produkcje a jak ktoś się zbytnio rozpisał i chciał wydać grę to nie było zmiłuj, tnij pan do 16K to wydamy (Montezuma Revenge/Preliminary Monty)

Czasy się zmieniają, PROM-y większe od 16KB coraz tańsze...

Atari 8-bit: 2600, 2600Jr, 7800, 400, 600XL, 800XL, 65XE, 130XE, 800XE, XEGS
Atari 16-bit: 260ST, 512ST, 512ST+, 512STE, 1040STE, 1040STF, 1040STFM, MEGA1

586 Ostatnio edytowany przez Pin (2013-01-10 13:56:04)

Najbardziej mnie rozśmieszają porównania systemu Atari do C64, które miało chyba kilkanaście standardów rozszerzeń pamięci ram i z czego żaden się nie przyjął. Mnogość rozwiązań czasami stanowi o ich bezużyteczności ;)-

@XXL - co za różnica, czy pamięć ekranu wyląduje pod romem, czy będzie w innym miejscu pamięci? - tak tylko pytam.

@XXL - o jakim MemLo w kosmosie prawisz i jakia jest wartość, którą należy traktować jako wysoką? ;)-

@XXL - na Note/Point i binary load pod SDX raczej nie narzekam ;)-

@XXL - krytykujesz system w Atari, który pomimo swoich drobnych wad mimo wszystko jest najlepszym OS na komputery 8-bitowe. Zaprezentuj nam może OS lepiej napisany, albo - mam propozycję. Weź dłuto i wydłub kość z OS'em z komputera, skoro jest aż tak bardzo nieprzydatny :P

@TeBe - tnij Pan do 16kB - bo miało się zmieścić na CARTRIDGE o pojemności 16k wiesz dlaczego? - bo jak sądzę cena pamięci w ówczesnych czasach była dość wysoka. Chyba, że się mylę ;)-

-----------------------

Edit:

:) - @XXL - jak to się dzieje, że demo XL Digital (włącznie z 4kB wolnej i niewykorzystanej pamięci przy MemLo SDX np. $1000) potrafi wykorzystać 59kB z 64 ... bez problemu wracając do DOS? ;)- Po drobnych obliczeniach wynika z tego, że korzyść dla xBios w stosunku do SDX kształtuje się mniej więcej na poziomie 2100 Bajtów. Jest z tym oczywiście więcej zabawy (w sensie przenoszenia danych pod ROM - fakt), ale jest to osiągalne bez problemu. Ograniczenie wolności i przestrzeń: 2.1kB ;)-

Kontakt: pin@usdk.pl

587

i widzisz? komody nie trzeba rozszerzac zeby uruchomic wszystkie programy (wcale nie gorsze niz na atari) a na atari, na atari wmowili Ci ze musisz miec wiecej rozszerzen... a moze to wiecej programow potrzebujesz? :-) napisz jeszcze jakis regulamin w ktorym umiescisz ograniczenia typu ze program ma sie uruchamiac na rozszerzeniach idea pinredy :-) w efekcie programow bedzie jeszcze mniej :)


> @XXL - co za różnica, czy pamięć ekranu wyląduje pod romem, czy będzie w innym miejscu pamięci? - tak tylko pytam.

wzgledy porzadkowe, estetyczne no i wygoda. a z tym nowym dosem (mam nadzieje Pecus da rade go napisac) nie tylko pamiec ekranu nie bedzie mogla sie tam znajdowac ale i generator znakow no i oczywiscie sam program antica.


> @XXL - o jakim MemLo w kosmosie prawisz i jakia jest wartość, którą należy traktować jako wysoką?

kazda, samo pojecie memlo smierdzi. w xbios nie ma tego problemu


> @XXL - na Note/Point i binary load pod SDX raczej nie narzekam

z note/point pod dos jest zawsze problem, jesli uruchomisz ten program pod innym dosem mozesz miec powazne problemy :-)
co do binary load... moglbys mi pokazac przyklad uzycia binary load od dowolnego punktu w pliku? :D


> @XXL - krytykujesz system w Atari, .... Weź dłuto i wydłub kość z OS'em z komputera, skoro jest aż tak bardzo nieprzydatny

system atari (ogolnie nie tylko OS) ma swoje wady i zalety, jedna z wiekszych zalet jest to ze mozna OS wylaczyc i odzyskac zajmowana przez niego przestrzen - na potege wykorzystywane przez progrmistow. nie widze powodu dla ktorego mialbym cokolwiek z atari wydlubywac. jeden zapis do PORTB i masz wiecej RAM... bez rozszerzania

http://atari.pl/hsc/ad.php?i=1.

588

xxl napisał/a:

i widzisz? komody nie trzeba rozszerzac zeby uruchomic wszystkie programy (wcale nie gorsze niz na atari) a na atari, na atari wmowili Ci ze musisz miec wiecej rozszerzen...

Nie trzeba, owszem - bo komoda nie ma niczego, co przypominało by XLOS i ogólnie cały system. Dlatego w tym względzie jest to komputer zacofany. W tym względzie, zaznaczam.

Na Atari mogę lecz nie muszę mieć rozszerzeń. Te jednak istniejące są niezwykle wygodne w użyciu.

xxl napisał/a:

napisz jeszcze jakis regulamin w ktorym umiescisz ograniczenia typu ze program ma sie uruchamiac na rozszerzeniach idea pinredy :-) w efekcie programow bedzie jeszcze mniej :)

Jeśli będę dostarczał sprzęt na jakieś kompoty (zależnie od woli organizatora) to uproszczę regulamin do MINIMUM takiego, jakie obowiązuje np. w przypadku party C64. Minimum zasad ogólnie i podana platforma prezentacyjna z adnotacją: ma się na tym uruchomić. To będzie warunek udostępnienia przeze mnie sprzętu ;)-

W efekcie będzie mniej o jedną pracę. O Twoją pracę w takim razie - jeśli się nie potrafisz podporządkować pod ustalone zasady ;)-

@XXL - jak tankujesz paliwo na stacji, to w kasie płacisz 3pln za litr benzyny tylko dlatego, że tak właśnie uważasz? :D

XXL napisał/a:

wzgledy porzadkowe, estetyczne no i wygoda. a z tym nowym dosem (mam nadzieje Pecus da rade go napisac) nie tylko pamiec ekranu nie bedzie mogla sie tam znajdowac ale i generator znakow no i oczywiscie sam program antica.

Owszem - w tym miejscu się wyjątkowo zgadzam, co Cię zaskoczy. Używając np. Sparta DOS X nie ma co prawda pełnej swobody co do umieszczania danych w dowolny sposób w pamięci, da się jednak zrobić to w odpowiedniej kolejności z podobnym skutkiem, np. mając do dyspozycji 59kB ram przy MemLo $1000. To jak sądzę jest około 2kB mniej niż daje xBios. Tu jest prawda i są to tylko 2kB różnicy.

Co do Note/Point - fakt, pod innym dosem otrzymuję syf. Lecz ja nie zamierzam używać innego dosa, bo ten jest najlepszy :P

Do czego mi binary load z odczytem od dowolnego punktu? - bo jeśli to coś przydatnego, to może złożę zapytanie do DLT, czy by tego do Sparty nie dorobić ;)-

XXL napisał/a:

jeden zapis do PORTB i masz wiecej RAM... bez rozszerzania

Oczywiście. Pod DOS'em także. Dobrym tego przykładem jest XL Digital. Bez rozszerzenia, z dosem i z możliwością powrotu do DOS ;)-

@XXL - weź się zastanów po prostu, czy to o czym Pisał bodajże Pecuś da się zaimplementować w xBios. Nie będzie wówczas tematu przywiązania xB do SIO. Podobno temat prosty jak drut, no i wszyscy będziemy żyć długo i szczęśliwie! ;)

Kontakt: pin@usdk.pl

589 Ostatnio edytowany przez Amun-Ra (2013-01-10 14:30:40)

Pin napisał/a:

Najbardziej mnie rozśmieszają porównania systemu Atari do C64, które miało chyba kilkanaście standardów rozszerzeń pamięci ram i z czego żaden się nie przyjął. Mnogość rozwiązań czasami stanowi o ich bezużyteczności ;)-

Generalnie nie przyjął się, gdyż tak naprawdę 64KB wystarczało... :)
Stąd programów je wykorzystujących było jak na lekarstwo (GEOS, etc.).
Inną kwestią była ich cena.
No i tak naprawdę są dwa standardy rozszerzeń, czyli mniej niż na Atari.

Atari 8-bit: 2600, 2600Jr, 7800, 400, 600XL, 800XL, 65XE, 130XE, 800XE, XEGS
Atari 16-bit: 260ST, 512ST, 512ST+, 512STE, 1040STE, 1040STF, 1040STFM, MEGA1

590 Ostatnio edytowany przez Dracon (2013-01-10 14:45:30)

xxl napisał/a:
Candle napisał/a:

sio2sd dokupiles, różnic nie widze

nie widzisz roznicy? i dlatego to ja jestem xxl.

Ale na zlotach podobno preferujesz koszulki w rozmiarze (tylko) XL :P

Prawie 600 odpowiedzi, ponad 16 tysięcy wyświetleń tego wątku na forum... oraz nieprzejednana (!) postawa autora. :o
Jestem pod wrażeniem.
Narodziny xBiosa sprawiły, że odtąd świat (atarosceny) nie jest już taki sam... :)

591 Ostatnio edytowany przez xxl (2013-01-10 14:54:45)

Pin napisał/a:

Nie trzeba, owszem - bo komoda nie ma niczego, co przypominało by XLOS i ogólnie cały system. Dlatego w tym względzie jest to komputer zacofany. W tym względzie, zaznaczam.

prosze Cie... system operacyjny teraz ma byc usprawiedliwieniem do zakladania rozszerzen pamieci? jak wlaczam atari dla gry a nie zeby patrzec READY i system operacyjny

Pin napisał/a:

Do czego mi binary load z odczytem od dowolnego punktu?

przeczytaj pare dni temu o tym mowilem w tym watku...

Pin napisał/a:

@XXL - weź się zastanów po prostu, czy to o czym Pisał bodajże Pecuś da się zaimplementować w xBios.

caly czas myslisz jak zrobic z xbiosa program z funkcjonalnoscia i ograniczeniami dosa. ja juz nie chce sie cofac

http://atari.pl/hsc/ad.php?i=1.

592 Ostatnio edytowany przez Pin (2013-01-10 15:15:14)

.. no z tym "kilkanaście" to lekko przesadziłem. Teraz znalazłem opis 4 pomysłów (nie licząc seryjnego C128) a o mnogości rozwiązań zasłyszałem w czasie dłuższej debaty z przedstawicielem sceny C64 ;)-

Jeden z pomysłów na ram i zabawny pomysł i dyskusja na temat kontrolera IDE:

http://www.c64scene.pl/viewtopic.php?t= … bf986d2969

... i teraz dzięki Bogu, mamy 1MB portb i IDE+ :D

@Amun-Ra. Cobyśmy się dobrze zrozumieli, nie uważam że C64 to zły sprzęt, został po prostu inaczej zaprojektowany - co lepiej się spisywało w przypadku gier. Atari dla odmiany jako jedyny komputer 8-bitowy posiada pełny dyskowy system operacyjny, który powstał w tej postaci ze względu na specyficzne cechy systemu a ponieważ rozmowa po części dotyczy i tego tematu to dziwią mnie porównania w tym względzie obydwu komputerów. Każdy z nich jest po prostu innym urządzeniem.

xxl napisał/a:

caly czas myslisz jak zrobic z xbiosa program z funkcjonalnoscia i ograniczeniami dosa. ja juz nie chce sie cofac

Nie - nie myślę o tym, bo nie sądzę by xBios był mi do czegokolwiek potrzebny. Pytam po prostu, bo to o czym wspominał Pecuś ma sens i mogło się przyczynić do rozwoju Twojego projektu. Jeśli uważasz, że rozwój jest wstecznictwem to obawiam się, że żaden lekarz Ci już nie pomoże ;)-

Kontakt: pin@usdk.pl

593

Pin napisał/a:

.. no z tym "kilkanaście" to lekko przesadziłem. Teraz znalazłem opis 4 pomysłów (nie licząc seryjnego C128) a o mnogości rozwiązań zasłyszałem w czasie dłuższej debaty z przedstawicielem sceny C64 ;)-

Najpopularniejsze to REU i GeoRAM.

Pin napisał/a:

Jeden z pomysłów na ram i zabawny pomysł i dyskusja na temat kontrolera IDE:
http://www.c64scene.pl/viewtopic.php?t= … bf986d2969
... i teraz dzięki Bogu, mamy 1MB portb i IDE+ :D

Straszna rzeźba. :) Z oficjalnych produktów - przede wszystkim CMD HD (http://www.cmdweb.de/)
wykonane przez firmę, która stworzyła SuperCPU (takie połączenie DracOS-a i (no ok, trzeciego rodzaju ;-) rozszerzenia
pamięci).

Pin napisał/a:

@Amun-Ra. Cobyśmy się dobrze zrozumieli, nie uważam że C64 to zły sprzęt, został po prostu inaczej zaprojektowany - co lepiej się spisywało w przypadku gier. Atari dla odmiany jako jedyny komputer 8-bitowy posiada pełny dyskowy system operacyjny, który powstał w tej postaci ze względu na specyficzne cechy systemu a ponieważ rozmowa po części dotyczy i tego tematu to dziwią mnie porównania w tym względzie obydwu komputerów. Każdy z nich jest po prostu innym urządzeniem.

Każdy komputer ma swoje plusy i minusy. Niezaprzeczalnym minusem C64 jest brak porównywalnego z Atari DOS-u
oraz błąd w MOS 6522 (VIA) który spowodował, że trzeba było potwierdzać transmisję bit po bicie (gdyby nie to, nie
nie trzeba by było wstrzykiwać kodu do pamięci stacji dysków).

Atari 8-bit: 2600, 2600Jr, 7800, 400, 600XL, 800XL, 65XE, 130XE, 800XE, XEGS
Atari 16-bit: 260ST, 512ST, 512ST+, 512STE, 1040STE, 1040STF, 1040STFM, MEGA1

594

Amun-Ra napisał/a:

SuperCPU

A czy nie jest to rozwiązanie oparte o 65c816 taktowane w okolicach 20Mhz? ;)-

"CMD's Super CPU Accelerator came after this, and could house up to 16 MB of direct, CPU-addressable RAM. Unfortunately, there was no on-board or disk-based RAM disk functionality offered, nor could any existing software make use of the directly-addressable nature of the RAM. The exception is that drivers were included with the unit to explicitly allow GEOS to use that RAM as a replacement for swap space, or as a regular 'disk' drive, as well as to make use of the acceleration offered by the unit."

Zajebista rzecz do C64.

Kontakt: pin@usdk.pl

595 Ostatnio edytowany przez Amun-Ra (2013-01-10 15:54:03)

Pin napisał/a:
Amun-Ra napisał/a:

SuperCPU

A czy nie jest to rozwiązanie oparte o 65c816 taktowane w okolicach 20Mhz? ;)-

Tak, to to, nawet kilka rzeczy na to wyszło... ;-) Flagowa produkcja to gra Metal Dust -
- http://www.youtube.com/watch?v=xBTnvWbhERY, http://www.youtube.com/watch?v=Ie79hicxteg

Osobiście takich dodatków nie uważam - wg mnie wszystko co zwiększa możliwości komputera powyżej oferowanych
standardowo (z wyj. rozszerzenia pamięci i oczywistości typu dostęp do danych via karta SD) robi z maszyny coś innego
(czyli właśnie 65816, VBXE (chyba, że dodawałoby tylko np. RGB), DualSidy, DualPokeye, MapRAM itd.). Ale to moja opinia. :)

Atari 8-bit: 2600, 2600Jr, 7800, 400, 600XL, 800XL, 65XE, 130XE, 800XE, XEGS
Atari 16-bit: 260ST, 512ST, 512ST+, 512STE, 1040STE, 1040STF, 1040STFM, MEGA1

596 Ostatnio edytowany przez Jacques (2013-01-10 15:58:02)

VBXE może dodawać tylko RGB, zależy jakiego rdzenia używasz i od oprogramowania, które wczytujesz ;)

597

Osobiście założyłem VBXE przede wszystkim dla obrazu RGB. No i ostatni rdzeń emulacji GTIA jest już całkiem niezły - wszystkie tryby interlace zachowują kolory ;)-

Kontakt: pin@usdk.pl

598

Bo pewnie dostałeś 1.26 do beta-testów, Mądralo :P Ja mam nadal 1.24 ;)

599

Nie - 1.2x to FX, a emuGTIA to np.: gtiav1.05a. I o ten ostatni rdzeń chodzi właśnie. Dobra - to temat na inny dział. eot z vbxe.

Kontakt: pin@usdk.pl

600

No tak, tak, miałem na myśli paczkę gdzie jest 1.24a, a emu GTIA ma faktycznie inną numerację ;) ok, koniec EOT, sorry xxl.