Zanim się użycie VBXE rozpowszechni na dobre, chciałbym zadać temat dzielenia się przez programy pamięcią tej karty. Przyszło mi to do głowy, bo robię ostatnie przymiarki przed napisaniem korzystającego z VBXE rezydenta i z pewnych powodów uśmiecha mi się załadowanie go w całości (tzn. kod i wszystko) do pamięci VBXE "MEMAC B". Chodzi o to, żeby w przypadku zajęcia kawałka pamięci VBXE inny program też chcący z niej korzystać, mógł uniknąć zniszczenia zajętego obszaru. Oczywiście dotyczyłoby to tylko tych programów, które po zakończeniu się wracają do DOS-u i/albo nie potrzebują całości pamięci VBXE, a tylko jakiejś części.

Wymyśliłem, żeby pierwszy program, który rezydentnie ładuje coś do VBXE, wpisywał pod adres $000000 jakąś magiczną wartość, a pod adres $000003 - pierwszy wolny adres w pamieci VBXE "nad" sobą. Następny pobierałby ten adres i sprawdzał, czy jest tam magic, jeśli nie, to wpisywał swój magic i swój wskaźnik do wolnej pamięci, a jeśli tak, to przeskakiwał następny kawałek, sprawdzał itd. w pętli aż do znalezienia wolnego miejsca albo końca RAM-u karty.

Jedyny problem to, że przy resecie trzeba byłoby te znaczniki pokasować, co oznacza kolejnego rezydenta, który to będzie robił i nie wiem, czy nie kładzie całej koncepcji.

W każdym razie alternatywa to trzymanie takiego rezydentnego programu w dwóch kopiach w pamięci, tzn. w ext RAM-ie normalnym, skąd przy każdym resecie przeładowywałoby się go do pamięci VBXE.

Szkoda, że MEMAC A bankuje się w obszarze $2000-$3FFF. Gdyby to było $4000-$5FFF (albo $6000-$7FFF), byłoby łatwiej napisać rezydenta, który ma kod w ext RAM-ie, ale np. pamięć obrazu w pamięci VBXE (wyjasniam dlaczego: bo programy sa "przyzwyczajone", że pod $4000-$7FFF bankuje się pamięć, więc istnieje tendencja do tego, żeby unikać umieszczania tam handlerów przerwań - a pod $2000-$3FFF takiego ograniczenia do tej pory nie było).

Wszystkie moje wywody dotyczą oczywiście softu, który działa pod DOS-em i korzysta z OS-u np. w celu wczytania directory itp.

KMK
? HEX$(6670358)

2

Jakoś mi się to kojarzy z MS-DOS i sterownikami *.sys :)
Czy reset kasuje zawartość RAM VXBE ?
Czy konieczny jest MAGIC a potem adres ? Nie lepiej od razu pod $00000 wpisywać adres następnej wolnej pamięci za tym co jest ładowane a za tuż za tym wskaźnikiem autor ładowanego rezydenta wpisuje jakiś magic w postaci ludzko-czytelnej. Łatwo wtedy napisać jakiś program, który wypisuje co jest załadowane na zasadzie wypisywania np. 4 lub 8 bajtów.
Pytanie jak uniknąć konieczności prowadzenia spisu MAGICów ?
Może trzeba wprowadzić jakąś tablicę wywołań standardowych funkcji typu:

$nnnnnn      - następny wolny adres
$nnnnnn+4  - adres funkcji identyfikującej
$nnnnnn+8 - itp. itd.

3 Ostatnio edytowany przez drac030 (2009-03-03 22:14:17)

BartoszP napisał/a:

Czy reset kasuje zawartość RAM VXBE ?

Nie wydaje mi się.

Czy konieczny jest MAGIC a potem adres ? Nie lepiej od razu pod $00000 wpisywać adres następnej wolnej pamięci za tym co jest ładowane a za tuż za tym wskaźnikiem autor ładowanego rezydenta wpisuje jakiś magic w postaci ludzko-czytelnej.

Nie bardzo widzę, na czym miałaby polegać różnica. I tak pierwszy trzeba sprawdzić "magic", zeby wiedzieć, czy adres jest "valid", prawda? Bo tam mogą być przypadkowe wartości, tak ogólnie.

KMK
? HEX$(6670358)

4

O ile VBXE po resecie nie wyzeruje tej pamięci...a skąd wiadomo, że MAGIC jest poprawny a nie jest to śmieć ?

5

drac030 napisał/a:

Jedyny problem to, że przy resecie trzeba byłoby te znaczniki pokasować, co oznacza kolejnego rezydenta, który to będzie robił i nie wiem, czy nie kładzie całej koncepcji.

No stąd.

KMK
? HEX$(6670358)

6 Ostatnio edytowany przez tebe (2009-03-04 01:32:18)

po resecie pamięć dodatkowa nie jest kasowana, bo OS nie "zagląda" do pamięci dodatkowej (PORTB), chyba że napisaliście jakiegoś OS-a który rekreacyjnie robi wypad do takiej pamięci i zapisuje ją wzorkami

z aktualnym rdzeniem pamięć VBXE zachowuje się jak normalna pamięć bankowana w obszar $4000..$7FFF (320KB RAMBO), jeśli chodzi o dostęp przez PORTB

jeśli macie w kompie jakieś inne rozszerzenie pamięci, np. 1MB to VBXE je wyłączy, chcecie mieć swoje 1MB, to musicie przełączyć się na inny rdzeń VBXE, taki który nie oferuje emulacji pamięci RAMBO 320KB

dostęp do całej pamięci VBXE realizowany jest przez dedykowane rejestry, pamięć VBXE można włączać w 2 obszary, $2000..$3FFF (MEMAC_A)  lub $4000..$7FFF (MEMAC_B)

jeśli będziemy beztrosko mieszali przez PORTB i MEMAC_A, MEMAC_B to możemy nadpisać pamięć

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

7 Ostatnio edytowany przez electron (2009-03-04 08:59:43)

Wymyśliłem, żeby pierwszy program, który rezydentnie ładuje coś do VBXE, wpisywał pod adres $000000 jakąś magiczną wartość, a pod adres $000003 - pierwszy wolny adres w pamieci VBXE "nad" sobą. Następny pobierałby ten adres i sprawdzał, czy jest tam magic, jeśli nie, to wpisywał swój magic i swój wskaźnik do wolnej pamięci, a jeśli tak, to przeskakiwał następny kawałek, sprawdzał itd. w pętli aż do znalezienia wolnego miejsca albo końca RAM-u karty.

Jedyny problem to, że przy resecie trzeba byłoby te znaczniki pokasować, co oznacza kolejnego rezydenta, który to będzie robił i nie wiem, czy nie kładzie całej koncepcji.

przy jakim resecie ? ciepły start ? zimny start ? opisz dokładniej.
bo mogę zrobić np. jakiś bit w rejestrach vbxe, który ma 0 po resecie (ciepłym ? zimnym ?) i jest możliwe tylko ustawienie go przez program na "1" ale programowe skasowanie byłoby niemożliwe - sam by się skasował po następnym resecie (ciepłym ? zimnym ?).

Czy to coś Ci pomoże ?

pomidor

8

drac030: Jeżeli założyć, że każdy ładowany driver będzie implementował jakąś tablicę wektorów standardowych funkcji typu inicjuj, zakończ, status w stałym miejscu pamięci to łatwo bedzie odpytać łańcuch programów o ich stan.
Jeśli zamiast układu
[MAGIC | następny wolny adres | tablica wektorów | dane i/lub program]
będziemy mieli układ
[następny wolny adres | tablica wektorów | dane i/lub program]
to nie trzeba prowadzić listy unikalnych MAGICow a i ewentualne alokowanie pamięci tylko na dane będzie łatwiejsze
bo nie trzeba dla samych danych rezerwować innego MAGICa. Wystarczy tylko zaalokować pamięć i wpiąć w łańcuch pobranych bloków.

Pojawia sie problem czy moduł może zwolnic jakąś pamięć i co wtedy zrobić aby uniknąć defragmentacji pamięci.

9

@tebe: tak, też czytałem instrukcję :P

@electron: zimny start od ciepłego to chyba nie bardzo da się odróżnić "z zewnątrz" komputera, tzn. nie sprawdzając flag w konwencjonalnej pamięci RAM. Przemyślę to jeszcze, nie ma co robić zbyt gwałtownych ruchów.

@bartoszp: miałem na myśli, że dla każdego programu magic będzie ten sam, tzn. np. $BABADA :) Wtedy łatwo byłoby dowolnemu programowi, który się chce tam władować, sprawdzić, gdzie jest wolne.

KMK
? HEX$(6670358)

10

A nie wystarczy trzymać tylko łańcucha wskaźników następnej wolnej pamięci. Jeśli wskaźnik wskazuje sam na siebie, to znaczy, że jest to koniec i zaraz za nim można się ładować. Pełni wtedy MAGICzną rolę sam :-).
Proponuje by reset ustawiał np. pod adresem 0 wskaźnik na wartość aktualnie dostępnej pamięci RAM czyli na jej koniec, co pozwoli na łatwą
zarządzanie pamięcią w przypadku jej rozbudowy chyba, że VBXE ma jakiś rejestr, który to raportuje.

11

No, pod warunkiem, że pierwszy wskaźnik będzie ustawiony sprzętowo, bo inaczej to nie bardzo sobie wyobrażam odróżnienie pierwszego wskaźnika od przypadkowych śmieci, które tam widać po włączeniu zasilania.

KMK
? HEX$(6670358)

12

reset w wykonaniu VBXE..

13

Tzn, najlepiej, gdyby jednak to było ustawiane na zero (pierwsze trzy bajty pamięci VBXE, that is), niż na wielkość RAM-u, wydaje mi się. Wtedy wystarczyłoby do tego dodać wielkość ładowanych danych/kodu, żeby to zawsze wskazywało wolne miejsce.

KMK
? HEX$(6670358)

14

Yes, my Master.....it's up to you jak sie to mówi nad Wisłą....

15

It is not up to me, in fact it is up to electron.

KMK
? HEX$(6670358)

16

Bo wszystko działa dzięki elektronom :)

17 Ostatnio edytowany przez electron (2009-03-04 15:28:25)

Jak pisałem - mogę dodać odczytywalny bit, który np. wartością 0 będzie mówił że był zimny start VBXE, tj:

- załączenie zasilania komputera
- ponowne wgranie rdzenia

Po jego wykryciu można będzie jednorazowo przestawić jego wartość na 1 - tym samym niezależnie od ilości resetów (ciepłych czy zimnych startów systemu - programowych lub przez klawisz RESET - nieważne) tam ciągle będzie jedynka - aż do wyłączenia zasilania kompa lub ponownego wgrania rdzenia.

Ewentualnie bit ten może być po prostu ustawialny / kasowalny ale po włączeniu zasilania i tak zawsze "0".

Zerowanie i wpisywanie czegokolwiek do RAM na drodze sprzętowej jest możliwe ale upierdliwe i zasobochłonne - a jedziemy na oparach ...

pomidor

18

electron napisał/a:

tym samym niezależnie od ilości resetów (ciepłych czy zimnych startów systemu - programowych lub przez klawisz RESET - nieważne) tam ciągle będzie jedynka

No i to właśnie nie jest dobre. Bo zimny start - nawet bez sygnału reset - ma przeładowywać od nowa cały system, a ciepły reset ma tego nie robić. Czyli tak jak pisałem, tego się nie da zrobić sprzętowo, to musi załatwiać soft, a na soft też nie zawsze można liczyć, bo np. po zimnym starcie user może zechce załadowac grę z inicjalizera. Wtedy znaczniki w pamięci VBXE zostałyby nieskasowane.

Czyli raczej się to nie da zrobić, tzn. mój rezydent będzie musiał być załadowany do pamięci dwa razy i przy każdym ciepłym resecie przepisywany do pamięci VBXE. No i chyba na tym poprzestaniemy.

KMK
? HEX$(6670358)

19

tebe napisał/a:

jeśli macie w kompie jakieś inne rozszerzenie pamięci, np. 1MB to VBXE je wyłączy, chcecie mieć swoje 1MB, to musicie przełączyć się na inny rdzeń VBXE, taki który nie oferuje emulacji pamięci RAMBO 320KB

... i to mnie martwi. Jest jakiś alternatywny rdzeń nieunieszkodliwiający rozszerzenia RAM??

Kontakt: pin@usdk.pl

20

Ma być. I jeszcze taki ze 192k zachowujący zgodność ze 130XE.

KMK
? HEX$(6670358)

21

jesli mozna wtracic swoje 3 grosze do dyskusji, to wolalbym rdzen bez zabawy w rambo, bo tak samo jak vbxe mapuje swoja pamiec jako extram, tak moje rozszerzenie to robi - przez sygnal !extset
fajnie, ze !extsel jest typu OC, ale daje to tyle, ze w pewnym momencie zapis i odczyt idzie do dwoch kostek pamieci na raz - do jednej w moim rozszerzeniu, a drugiej w vbxe
czy bedzie w zwiazku z tym jakis problem - nie wiem, prawdopodobnie nie, ale wolalbym sie nie przekonac ze jednak bedzie
chce tez zauwazyc ze na zachodzie jest wiecej rozszerzen opartych na pamieciach statycznych (pomijam rozwiazania silowe z polska) i tez moga sie pojawic problemy
czy w rdzeniu zmiesci sie jakas zapisywalna flaga zeby wlaczyc/wylaczyc pana rambo z wietnamu?
wtedy wlaczanie moglo by odbywac sie przez soft:
sprawdz czy jest extram, jesli jest - fajnie, jesli nie:
sprawdz czy jest vbxe, jesli jest - wlacz extram, jesli nie - coz :)
pamiec tego rozszerzenia jesli jest taka potrzeba moze byc podtrzymywana bateryjnie

przechodze na tumiwisizm

22 Ostatnio edytowany przez tebe (2009-03-07 15:12:11)

pewnie rezygnując całkowicie z emulacji Rambo Electron zyskał by miejsce w rdzeniu na inny kod, sama emulacja Rambo jest pewnie efektem "ubocznym" możliwości VBXE mapowania swojej pamięci w RAM Atarki

w sumie można pogodzić się z całkowitą rezygnacją z emulacji jakichkolwiek rozszerzeń pamięci przez VBXE i skupienie możliwości VBXE tylko na grafice, pamięć rozszerzyć to nie problem

rozumiem Electrona że mając takie możliwości nie sposób im się oprzeć :)

p.s.
Candle kiedy sklonujesz VBXE ;)

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

23

tebe: prace trwaja we wspolpracy i pod nadzorem electrona
mysle ze z koncem marca bedziemy juz cos mieli
troche mam duzo na glowie ostatnimi czasy, wrecz sie ciesze ze jestem bezrobotny, bo nie wiem jak bym wyrobil z 8h etatem na karku

przechodze na tumiwisizm

24

@tebe: tia, też uważam, że emulacja rozszerzenia pamięci przez VBXE to troche overkill, zwłaszcza jeśli brakuje miejsca w FPGA (oraz zwłaszcza że to RAMBO, czyli rozszerzenie nie najdoskonalsze z możliwych). Ale ja mam 130XE, pamięci wewnętrznej komputera wystarczy do moich potrzeb, natomiast posiadacze gołego 65XE pewno by VBXE z RAMBO chcieli mieć...

KMK
? HEX$(6670358)

25

Hmm, jesli ruszy produkcja VBXE na wieksza skale, z tego co wiem na razie sa 22 sztuki? A Atarek z rozszerzonym ramem jest na pewno wiecej wiec jednak moze miejsce w VBXE zostawic na grafike  a ext ram osobno bo jednak wiekszosc osob go juz ma.

Dwa korce ziemniaków, gęsich jajek kopa, żeby móc to połknąć, tęgiego trza chłopa. GG3456993