:) - nie wiem, czy ma to jakiekolwiek znaczenie.

@Sikor - Sparta bez problemów przeprowadza komunikację z KMD i niczego ręcznie nie trzeba "inputować"

Co oznacza, że nic nie zmienia? Zamieniłeś flopki A na B i B na A i dalej z B jest ten sam problem? Czy po zamianie problem dotyczy stacji A?

Łoł .... szczękę pozbierałem właśnie z podłogi ... ;)

Kiedy Evie będzie dostępnym hardware?

Sprawa numer dwa, to widzę że w stosunku do wcześniejszego prototypu ostateczna wersja Rapidusa jest znacznie szybsza ;)

dziękuję, bo zyskam tym sposobem kilkadziesiąt demek, które już na dysku czekają zgrane ;)

:) - Wiesz co, nie mam Evie, więc nie słyszę co z dźwiękiem (brak AY), ale odpaliłem chyba z 15 dem newschool'owych i każde z nich raz, że działa a dwa - nie widać, by coś działo się nie tak ;)

Efekty dość sprawnie działają a czy działają wolniej to mi już YerzmYeY powie jak to zobaczy ;)

Mam za to cały katalog demek oldschool w którym to większość przy uruchomieniu wypluwa komunikat, że nie jest to plik pod ZX 48k.

Co do runext, to rację miał Mono - zbyt długa ścieżka, choć na oko to nie miała jak przekroczyć 63 znaków. Przeniosłem plik z emulatorem do pierwszego podkatalogu po głównym i skojarzenia działają bez najmniejszego problemu.

@Mono - ooo, to może faktycznie być kwestia zbyt długiej ścieżki. Wyłożyłem się na tym już kilkukrotnie i zawsze o tym zapominam ;)

@Draco - mogę tam wpisać inną wartość, tylko muszę wrócić do domu ;) - wyniki testu wieczorem.

Wczoraj pograłem sobie jeszcze z godzinkę, przyznam - emulator zacny. Jak by jeszcze miał możliwość obsługi *.TAP, to by było zajebiście ;)- (choć opcja Save sna, też by się przydała)

Jak by nie było, to przyznać trzeba że jest to pierwszy dość poważny i używalny soft dla Rapidusa, no i przy okazji dla VBXE. Wow ;)

po załadowaniu pacza:

$FF0080=$EF
$FF0081=$20

dalej runext mi nie robi mimo, iż wg. tego co widzę wszystko powinno być ok.

EDIT:

Ten parametr /M to miał powodować, że emulator ma omijać pierwszy bank fast ramu. No to nadmieniam, że w związku z niepotrzebnie ładowaną poprawką wychodzi na to, że pierwsze 512k mam ok ;)-

Ok - ide w kimono, ciąg dalszy zapewne jutro ;)

wnioskuję, że ten spreparowany Pasiowy plik, który ładuje do FPGA jest owym paczem. Ok, spróbuję załadować to, co mam na fleszu w Rapidusie. Moment.

EDIT:

Pomogło. Działa zawsze.

Pytanie pomocnicze: Program siedzi w:

B:>PROGRAMS>ZX_SPEC

Jak powinien wyglądać zapis do runext dla np. pliku Z80? Oszaleje zaraz ;). Skojarzenie uruchamia mi emulator, ale nie podaje nazwy pliku jako parametr, więc emulator wstaje sam i niczego nie ładuje.

Jeśli zrobię to z palca, to na tym etapie mam 100/100 ;)

Pomogło. Uruchomiłem 3 program i wstał bez problemu. Joy też jak pisałem działa - po odłączeniu SIDE2 ;)

EDIT:

Jeszcze coś muszę sprawdzić ;)- coś to jest, a czasem nie jest :D

Haaaaaa!! ;) - Odpaliło ;)

Po jednokrotnym uruchomieniu w/w procki w MultiBasic'u emulator wstał ;)

EDIT:

.. no i w kolorze widzę, że emulator działa znacznie szybciej ;)

EDIT2:

No i coś poszło nie tak o tyle, że tylko jeden raz zadziałał ten patent. Ponowne uruchomienie emulatora generuje komunikat o braku możliwości alokacji fast ramu. (tzn wykrył 383kB np.)

Ale i tak sukces, że na tej wersji karty cokolwiek zadziałało ;)

EDIT3: :)

-------------

wykasowałem co napisałem, bo zauważyłem że program w MBI poprawnie mi działa, jeśli uruchamiam go z interpretera, a źle działa w przypadku uruchomienia poprzez Runext. Zapewne coś porypałem w RUNEXT.CFG. Linijka dla Multibasic wygląda tak:

MBI,CAR:X.COM,B:>FAST>MBI.EXE,-B,%

Taki zapis jest ok?

-------------------

Doszedłem do takiego stadium, że mogę uruchomić cokolwiek w tej wersji na VBXE, lecz muszę po każdorazowym uruchomieniu emulatora wyłączać komputer.

A sekwencja startowa jest dłuuuga w tym przypadku. Odpalenie kompa, załadowanie rdzenia dla Rapidusa, przełączenie w '816, odpalenie "programu" pod MBI, wyjście do systemu i odpalenie emulatora ;)

Pamiętam, że prawiłeś jakoby pierwsze 512k fast ramu 816 działało normalnie a dalej, to już maliny są ;)