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.

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

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ęć

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

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.

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.

reset w wykonaniu VBXE..

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

Bo wszystko działa dzięki elektronom :)

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.

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

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 ;)

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

@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ć...