Krap ma Warpa zrobionego przez samego Pasia, o ile mi wiadomo, i przyczyną niedziałania są zrypane GAL-e. Dokładnie Pasiu ponoć, po zrobieniu Warpa laoo, zgubił pliki do programowania GAL-i i nie udało mu się ich odtworzyć. Jasne, że nie wiem tego na pewno, więc jest miejsce dla sprostowań.

W każdym razie nie ma fizycznych powodów, dla ktorych Warp miałby działać źle z powodu innych rozszerzeń. Jesli działa źle, to, dokładnie tak samo jak kaźde inne źle dzialające rozszerzenie, z powodu, że jest zj*bany przez montera.

Jeśli Pasiu ma pomysł na naprawienie Warpa, to ładne parę osób czeka z niecierpliwością.

@Marek Konopka: pinek nie ma w komputerze ani Warpa ani F7.

A, że tak zapytam z głębi mojej (powszechnie chyba znanej) niewiedzy na ten temat: od kiedy to na złączu carta jest sygnał HALT, żeby zapobiec konfliktowi pomiędzy zapisem danej do pamięci ekranu przez dodatkowy procesor a żądaniem dostępu do tejże pamięci przez Antic?

mirko: załatw sobie VBXE, ono ma wyjście RGB, to chyba idealny monitor. Jak nie chcesz, to tanio odkupię :P

Niektórzy widać tak kochają bankowanie pamięci, że bez tego "to już nie jest Atari" :P No i nie, sorry, tylko nie kolejny typ rozszerzenia RAM-u, jak to ma być kart, to niech nim zostanie...

Ja bym głosował za usunięciem RAMBO z rdzenia FX. Ma to swoje zalety, ale ma i wady, np. jeśli program zechce użyć całej pamięci VBXE, wtedy cokolwiek jest załadowane do rozszerzenia komputera - np. DOS - zostanie zniszczone. Na pierwszy rzut oka fakt, że komputer i VBXE mają pewien obszar pamięci wspólny, wygląda atrakcyjnie, ale chyba w ogólnym rozrachunku ma to więcej wad niż zalet.

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

Tia, bo to jest funkcja GEMDOS-u, a nie biblioteczna, więc by custom jest z dużej litery (tak samo Fopen() vs fopen() itd.)

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.

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.

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

Nie wydaje mi się.

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.