551

grzybson napisał/a:

Proszę ja Ciebie, nie wpychaj kitu. Kilkadziesiąt (kilkaset) postów temu pokazałem źródłówkę, która ładowała pod ROM i program działał na kilku popularnych DOSach.

wybrane obszary :-)

grzybson napisał/a:

Na stronę zero też chyba możesz ładować, w te miejsca, których OS nie wykorzystuje.

wybrane obszary

xBIOS nie ma tu zadnych ograniczen

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

552

bo nawet, jeśli mowa o kilku procentach tych obszarów, to otrzymamy konkretną informację:

XXL napisał/a:

Wybrany obszary :-)

Kontakt: pin@usdk.pl

553 Ostatnio edytowany przez xxl (2013-01-09 17:14:20)

chcialbys ;-) zeby byc zgodnym z OS to "kulturalny" (wedlug Ciebie) program nie moze uzywac ZADNEGO obszaru RAM pod ROM bezposrednio a to dlatego ze skok do procek w rom nalezaloby wykonac przez tablice skokow ktora moze smialo prowadzic gdziekolwiek :-) wiec kopiowanie ROM do RAM jak sugeruje Grzybson jest ... niekulturalne i moze nie dzialac :D

a wiec... te kilka procent oznaczaja 1/4 pamieci RAM :D


---
poprawka bledof

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

554

1088-16k=1072k wolne, 16k to 1.47% pamieci
konsumuj

przechodze na tumiwisizm

555

acha, mam dokupic rozszerzenie pamieci?

ktore i tak nie rozwiazuje problemu i nadal nie bedzie mozna ladowac pod ROM :D

nie... dziekuje, uzyje xbiosa... za darmo

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

556

sio2sd dokupiles, różnic nie widze
twoje gry powinny byc do wklepania z poziomu basica - za darmo
inaczej oszukujesz sam siebie

przechodze na tumiwisizm

557

Candle napisał/a:

sio2sd dokupiles, różnic nie widze

nie widzisz roznicy? i dlatego to ja jestem xxl.

Candle napisał/a:

twoje gry powinny byc do wklepania z poziomu basica - za darmo

czas usera jest najdrozszy, to by bylo perfidne... porownywalne jedynie z wmawianiem komus ze rozszerzenie pamieci pozwoli bezposrednio ladowac do pamieci RAM pod ROM... http://www.atari.org.pl/forum/viewtopic … 06#p162406

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

558

czas usera?

ty jestes xxl?

ok... wracamy do suszonych żab

przechodze na tumiwisizm

559

Candle - zepnij poślady ;)-

Kontakt: pin@usdk.pl

560

sra sie zdecydowanie latwiej jesli poslady sa rozluznione, rozumisz...

przechodze na tumiwisizm

561

Candle napisał/a:

mazezam 2

Tak, w przypadku, kiedy współdzieli pamięć razem z mazezam 1. :P

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

562 Ostatnio edytowany przez grzybson (2013-01-09 18:39:38)

xxl napisał/a:

wybrane obszary :-)

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.

Poza tym xBios też ładuje we "wybrane obszary" - pod $700-$bff nie potrafi. To chyba logiczne, że żaden program nie załaduje Ci nic w obszary, których sam potrzebuje ;D

xxl napisał/a:

chcialbys ;-) zeby byc zgodnym z OS to "kulturalny" (wedlug Ciebie) program nie moze uzywac ZADNEGO obszaru RAM pod ROM bezposrednio a to dlatego ze skok do procek w rom nalezaloby wykonac przez tablice skokow ktora moze smialo prowadzic gdziekolwiek :-) wiec kopiowanie ROM do RAM jak sugeruje Grzybson jest ... niekulturalne i moze nie dzialac :D

Emm, a tu nie rozumiem co jest niekulturalne. Nawet JBW uczył w TA, że skakać należy przez tablicę, a nie bezpośrednio. W końcu po coś Atari ją do OS wrzuciło. Nawet w ramach istniejących Revision OSu lokacje się zmieniały (400/800 -> XL/XE). Jeżeli przepiszesz ROM do RAM kropka w kropkę i nie nadpiszesz tych obszarów, których podsystem IO potrzebuje - to co może się wysypać? Rozwiń swoją myśl.

grzybson/SSG^NG

563 Ostatnio edytowany przez tebe (2013-01-09 19:03:10)

Candle napisał/a:

sra sie zdecydowanie latwiej jesli poslady sa rozluznione, rozumisz...

pozycja kucna jest jedyną słuszną pozycją udowodnili to amerykańscy naukowcy :P

same poślady to nie wszystko, nawet na sraniu się nie znasz Candle :D

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

564 Ostatnio edytowany przez xxl (2013-01-09 19:13:04)

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.

grzybson napisał/a:

Poza tym xBios też ładuje we "wybrane obszary" - pod $700-$bff nie potrafi. To chyba logiczne, że żaden program nie załaduje Ci nic w obszary, których sam potrzebuje ;D

oczywiscie, dlatego xbios moze ladowac do ramu pod rom a dos nie :D w $700-$bff dos tez nie potrafi - same ograniczenia.


grzybson napisał/a:

Nawet JBW uczył w TA, że skakać należy przez tablicę, a nie bezpośrednio.

no i co z tego? acha nie zapominaj ze flagowy jego program nie zadziala na kompie pina z wymienionym ROM :D myslisz pewnie ze to wina JBW? nie :-)

grzybson napisał/a:

Jeżeli przepiszesz ROM do RAM kropka w kropkę i nie nadpiszesz tych obszarów, których podsystem IO potrzebuje - to co może się wysypać? Rozwiń swoją myśl.

uwaga cwiczenie: masz dwie atarki, jedna ma oryginalny rom ktory znasz, druga ma rom zmieniony. piszesz program ktory przepisuje rom do ram z nadzieja ze bedziez mogl cos zaladowac bezposrednio powyzej $c000... no i ladujesz uzywajac łze-tablicy skokow, program ten zadziala na komputerze z z romem ktory znasz ale na komputerze z romem ktorego nie znasz niekoniecznie poniewaz co prawda skoczysz przez łze-tablice skokow to ten skok moze prowadzic wlasnie w obszar ktory zamierzales wykorzystac do ladowania - nie ma zadnej gwarancji gdzie łże-tablica skokow poprowadzi - ale jak zwykle cos nie wyszlo i umiescili tablice skokow w rom :D

rozumiesz? pod rom niczego uzywajac dosa nie zaladujesz.

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

565 Ostatnio edytowany przez Pecus (2013-01-09 19:47:58)

Kpisz, czy o drogę pytasz? Modyfikacja (na oko nie więcej niż 40 bajtów kodu) dowolnego DOSa czy loadera umożliwi tę funkcjonalność, tylko jakoś przez lata nie było to nikomu potrzebne.
Wymyśliłeś sobie niepotrzebną potrzebę i teraz udowadniasz jej potrzebę....

Co więcej, jak już pisałem podobna modyfikacja xbiosa, skróci kod o jakieś 100b i przy okazji spowoduje obsługę urządzeń PBI i innych. Tyle że to nie ma sensu (bo ciągnięcie tej idei go nie ma).

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

566

poprosze o przyklad :D

... i nastalo milczenie :)

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

567 Ostatnio edytowany przez Pecus (2013-01-09 19:55:47)

Zrób obsługę KarinMaxi , bo to o czym pisze jest tak proste, że każdy, kto ma choć trochę wiedzy o Atari, wie już zapewne o co mi chodzi......

podpowiedź .....
Jaki ten xbios wspaniały robi transmisję szeregową BEZPOŚREDNIO pod ROM i nie ma bufora na zawartość sektora, więc jej po załadowaniu nie musi przepisać w odpowiednie miejsce, cudo! <sarkazm mode off> (włączać tego trybu nie muszę bo jest u mnie standardowy :P ).

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

568

i tak wygladaja dowody :D

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

569

Pecus: zdajesz sobie sprawe z tego, ze odpowiadajac xxl wydajesz sie osoba zmanipulowana przez trolla, dajaca sie osmieszyc?

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

570 Ostatnio edytowany przez Pecus (2013-01-09 20:48:21)

Tak, ale może inni czegoś ciekawego się ode mnie dowiedzą (bo od XXXL-a mogą się dowiedzieć czegoś "ciekawego inaczej").

P.-S. Nie żebym twierdził że mam jakąś wielką wiedzą do przekazania ;)

P.P.-S. XXXL jest dziwnym przypadkiem trolla - niekarmiony dokarmia się sam :)

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

571 Ostatnio edytowany przez jellonek (2013-01-09 20:49:28)

ale nicka to nie wiem po co mu przerabiasz. sam nie wiem dlaczego mnie to tak irytuje, choc i sam przekrecam czasem nicka lodzia ;)

haha, to z autodokarmianiem sie - dobre!

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

572

Tak się zastanawiam, jak to możliwe, że xbios robi transimsję bezpośrednio w miejsce docelowe prosto z pokey ? Przecież lecą sektory, są sumy kontrolne transmisji ... a jak się transmisja skaszani i suma nie zgodzi albo wystąpi inny problem to co ? Wpiszemy złe wartości w miejsce docelowe ? Matko bosko i 100 milicjantów, tego nie wolno robić moim zdaniem, nawet, jeżeli za chwilę nadpiszemy to wartościami dobrymi przy powtórzonej transmisji.

pomidor

573

Pecus napisał/a:

od XXXL-a mogą ...

jellonek napisał/a:

ale nicka to nie wiem po co mu przerabiasz.

jestem przyzwyczajony, do takich reakcji kobiet, nie krepuje mnie to, natomiast dlaczego on tak robi... nie chce wnikac. ale niech sobie mysli, nie ubedzie mnie przez to.


> Tak się zastanawiam, jak to możliwe, że xbios robi transimsję bezpośrednio w miejsce docelowe prosto z pokey ?

i po drodze jest jeszcze A - kumulator CPU fiu fiu, diabla tam bezposrednio :D

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

574 Ostatnio edytowany przez Pecus (2013-01-09 21:29:02)

electron: No właśnie nie robi (sarkazm stąd właśnie) wali standardowo do bufora w normalnym RAMie a potem przepisuje, wiec co za problem włączać ROM na czas samego wczytania sektora i przywracać jego stan ustalony przez program bezpośrednio po zakończeniu transmisji.
Potem przepisywać można gdzie się chce. Trzeba tylko zapamiętać stan ROMu i ewentualnie zabezpieczyć się przed możliwym po włączeniu na chwilę ROMu "pójściem przerwań w krzaki" - da się to spokojnie w 40b zmieścić, a wtedy procedurę SIO (minimum strona) z xbiosa się wywala i robi odwołanie przez system (co nie zmienia faktu że w dalszym ciągu idea xbiosa niezgodnego z niczym na poziomie wywołań procedur jest bez sensu).

Zaoszczędzone miejsce przeznaczamy na implementacje wywołań przez CIO i mamy dość okrojonego DOSa z możliwością bezpośredniego ładowania pod ROM i obsługą jednego filesystemu.

XXXL troluje.
Ja przekręcam - reakcja obronna organizmu przed trolami :)

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

575

Pecus było już na ten temat, dlaczego ROM ma być wyłączony, ciągle szczekasz i gonisz ten swój ogonek

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