2,201

(220 odpowiedzi, napisanych Sprzęt - 8bit)

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

2,202

(220 odpowiedzi, napisanych Sprzęt - 8bit)

Jako że liczba i lokalizacja działających Warpów (sztuk 1) i F7 (sztuk pierwotnie 2, obecnie 1) jest dokładnie znana, raczej nie mogłeś widzieć w akcji żadnej z tych dopalek ani tym bardziej stwierdzić ich stabilności (bądź niestabilności). Osobiście mogę tylko powiedzieć, że w poprawnie wykonanych egzemplarzach obydwu dopałek żadnych niestabilności nie stwierdza się.

Co do dalszej części: Ok, czyli dodatkowy procesor pisze do pamięci, kiedy jest ona niewidoczna dla Antica, po czym staje się widoczna, ale wtedy procesor nie może do niej pisać. Synchronizacja tego pewnie będzie spoczywać na głównym 6502 atarki, który będzie dodatkowego proca haltował i uruchamiał stosownie do potrzeb. Stwierdzenie, kiedy pamięć jest widoczna dla Antica a kiedy nie, spocznie na jego programie? Bo jakoś nie widzę jak to można zrobić sprzętowo. Czyli dodatkowy procek będzie działał od złapanego stanu VCOUNT sygnalizującego początek dolnej ramki do stanu sygnalizującego koniec górnej ramki?

Fascynujący i jakże naturalny, zaprojektowany przez producenta sposób rozbudowy komputera.

2,203

(220 odpowiedzi, napisanych Sprzęt - 8bit)

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

Jak już wspominałem, piękno tego rozwiązania polega na tym, że możemy pamięć Antic'a ulokować pod przełączanym obszarem CART'a.

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?

2,204

(17 odpowiedzi, napisanych Programowanie - 16/32bit)

Lepiej kup sobie książkę B. W. Kernighan, D. M. Ritchie "Język ANSI C" albo starsza wersję "Język C". Nie ma lepszego podręcznika, a autorzy są twórcami języka C oidp.

2,205

(44 odpowiedzi, napisanych Sprzęt - 8bit)

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

2,206

(220 odpowiedzi, napisanych Sprzęt - 8bit)

tebe napisał/a:

aktualne dopalacze WARP i F7 miewały problemy ze stabilnością działania

Skądże znowu.

Kart ma ograniczenia wynikające z jego natury. Szybki procesor szybko policzy np. tablicę sinusów czy obrót obiektu w przestrzeni, ale to "normalna" dopałka w rodzaju Warpa czy F7 też zrobi. Za to procek na karcie, nie mając DMA, nie będzie mógł wykorzystać swojej szybkości do np. zapisu danych na ekran, a to z kolei "normalny" dopał w rodzaju F7 czy Warpa, przy programie uruchomionym w faście, może jak najbardziej. Czyli w tym drugim wypadku mamy wszystkie zalety tego pierwszego, ale bez wad. Osoby kręcące nosem na ingerencję do środka komputera, założę się, mają oczywiście gołe 130XE, albo rozszerzenia pamięci na zewnętrznych modułach :P

2,207

(220 odpowiedzi, napisanych Sprzęt - 8bit)

macgyver napisał/a:

Osobiście jestem zwolennikiem wstawienia nowego procka w natywną przestrzeń adresową 6502 (ukłon w stronę 65816), niż domontowywaniem cartridgea z dodatkowym prockiem.

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

2,208

(37 odpowiedzi, napisanych Software, Gry - 8bit)

Nawet jeśli, to jakiś standardowy rdzeń FX się i tak przyda.

2,209

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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.

2,210

(37 odpowiedzi, napisanych Software, Gry - 8bit)

laoo/ng napisał/a:

Jak załaduje CoreFX to tez jest tam ta emulacja?

Tak, w FX jest.

2,211

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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

2,212

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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

2,213

(17 odpowiedzi, napisanych Programowanie - 16/32bit)

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

2,214

(17 odpowiedzi, napisanych Programowanie - 16/32bit)

project file jest dla linkera, więc on ci owszem dołączy funkcję Cconin() pod warunkiem, że wcześniej zdołasz skompilować źródło. A skoro nie masz definicji tej funkcji, to niby jak ma się to udać.

Pewnie musisz dodać coś w rodzaju #include <tos.h>

2,215

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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.

2,216

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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

2,217

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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.

2,218

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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.

2,219

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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

2,220

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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.

2,221

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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.

2,222

(37 odpowiedzi, napisanych Software, Gry - 8bit)

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.

2,223

(9 odpowiedzi, napisanych Software, Gry - 8bit)

MWK napisał/a:

Postanowiłem założyć nowy temat o tej wspaniałej grze z uwagi na to, iż jeszcze takiego tematu nie ma

To może zrób opis w Atariki (z uwagi że jeszcze takiego hasła tam nie ma)?

2,224

(60 odpowiedzi, napisanych Programowanie - 8 bit)

Pewnie będzie, dzięki, nie zauważyłem tego :)

2,225

(60 odpowiedzi, napisanych Programowanie - 8 bit)

frebzda.