26

Kurcze. Ja jestem trochę zdezorientowany. W jakim korze emulowane jest RAMBO? Jak załaduje CoreFX to tez jest tam ta emulacja?

27

mysle ze synteza rambo w tym fpga zajmuje ulamek procenta jego mozliwosci i niewiele wniesie do mozliwosci dodania czegokolwiek przy jego braku, aczkolwiek pewnie wiekszosc jesli nie wszystkie atarki z vbxe maja juz takie czy inne rozszerzenie pamieci
jest sobie bo jest - sie dalo... czy vbxe mapuje pamiec pod ten, czy inny adres to zasadniczo fpga obobjetne

przechodze na tumiwisizm

28

Dostępne są już 2 albo 3 rodzaje płytek do 1MB według pomysłu Pasia (a powstaje bodajże 4), Atarek z 1MB jest już bardzo dużo, zarówno u nas w kraju jak i zagranicą... parę osób o to nieźle się zatroszczyło ;) Dlatego zgadzam się z przedmówcami lepiej wolne miejsce wykorzystać na grafike...

Ci, którzy przemawiają w imieniu Boga powinni pokazać listy uwierzytelniające. J. Tuwim

29

a ja osobiście uważam iż pomysł wykorzystania pamięci VBXE jako ext. RAM dla CPU/ANTIC to świetny pomysł. Montujesz jedynie VBXE i masz od razu ext ram + RGB out + pozostałe możliwości VBXE bez żadnego zamętu związanego z dokładaniem rozszerzenia RAM. Usunięcie tej funkcjonalności byłoby dla mnie błędem.

pozdrawiam
Seban

30

usuniecie - mysle ze tak, moglby byc to blad
ale ludzie nie zaczynaja rozszerzac swoje atari od vbxe, a nie wiem czy chcieli by sie dowiedziec, ze wlasnie przestali miec 1mb, a za to otrzymali 320k
sugeruje jedynie jakas opcje wylaczenia takiej mozliwosci, a przynajmniej sprawienia by nie kolidowala

przechodze na tumiwisizm

31

laoo/ng napisał/a:

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

Tak, w FX jest.

KMK
? HEX$(6670358)

32

To jeżeli core FX udostępnia tę samą pomięć przez MEMAC jak i przez PORTB przesłaniając potencjalne inne rozszerzenia obsługiwane przez PORTB, to wg mnie jest to pomyłka. Nie zdawałem sobie z tego sprawy, a pracuję nad pewnym projektem, który wykorzysta też trochę RAMu PORTB i jeżeli będzie to RAM VBXE to kanał. Bez rejestru wyłączającego ten ficzer się nie obejdzie...

33 Ostatnio edytowany przez electron (2009-03-09 14:39:30)

Laoo: udostępnia tę samą pamięć (bo innej nie ma :)) ale weź to pod uwagę:

- przez MEMAC i dla operacji VBXE masz pełne 512KB
- przez PORTB mapowane jest TYLKO górne 256KB (adresy 0x40000 - 0x7FFFF)

Może to rozwiązuje choć częściowo Twój problem ?

tak tak - Wy możecie gadać ale ja mam źródła ;-) ... RAMBO było mi potrzebne, bo mam 65xe z (i tylko) vbxe.
W momencie zamontowania 1MB RAMBO z rdzenia zniknie...

Może zniknie wcześniej skoro jest taka potrzeba - na razie uważałem to za plus i nie tylko ja.

Widzę to tak:

- rdzeń FX bez RAMBO (i działa zwykłe rozszerzenie) - można wtedy dodać jakieś funkcje jeszcze (ale czy jest sens ?)

- rdzeń FX z emulacją RAMBO - ale tu już nie dam rady dodać nic nowego ...

pomidor

34

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.

KMK
? HEX$(6670358)

35

electronu, lepiej popracuj nad jakims malym sdk do rdzeni, bedziemy mieli wtedy takie male falconowe dsp - nie mowie ze do dzwieku, ale koder bedzie mogl zrobic co mu zywnie podoba z rdzeniem i mozliwosci beda nieskonczone (oczywiscie taki rdzen bylby ladowany tymczasowo przez program)
to otwiera naprawde wielkie mozliwosci - warte zachodu
nawet jesli tylko garstka bedzie cos robic rdzeniowo

przechodze na tumiwisizm

36

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

KMK
? HEX$(6670358)

37

SDK jest ... nazywa się Quartus II Web Edition ;-)

pomidor

38

ACH :D
no popatrz, vbxe nie mam, a sdk mam... zapobiegliwy pewnie jestem...

przechodze na tumiwisizm