Black Box v9

[rime.]

To blisko 180pF, mam ponownie pożyczonego oryginalnego carta (z uszkodzonym PALem). Kondensator zmierzyłem dwoma miernikami, a wynik pomiaru w nich to 200pF i 208pF.

[hobocti77x_]

W zasadzie juz wiem jak wszystko dziala, ale jest zagadka ktory D-Latch z tych nie podlaczonych odpowiada konkretnie za ktore funkcje. A spelniaja one wazne funkcje np. czy blokowac czy nie gliche lub czy odczyt DEc1 ma tylko zmienic konfiguracje czy takze odciac rejestry carta itd. W sumie ich kolejnosc nie ma znaczenia dla BlackBoxa ale mogla byc wykozystana np. do adresowania GameBox-a.
Mysle ze programator i cale oprogramowanie potrzebne do zaprojektowania i zaprogramowania GAL-a bylo w tym czasie poza zasiegiem pana Romualda i powstalo na politechnice wroclawskiej. Wiec calkiem mozliwe ze GameBox powstal aby sprzedac nadmiarowe uklady. Slyszalem ze ten GAL jest martwy ale byc moze jakas czesc jego dziala wiec mysle czy nie zaprojektowac "Laty" z drugiego GAL-a ktorego mozna by posadzic na nim aby sprawdzic czy przypadkiem nie jest tak calkiem martwy.
W kazdym razie jakby kolega @Rime mogl i chcial poswiecic troche czasu to moznaby sprobowac.

[wegi]

Wiec calkiem mozliwe ze GameBox powstal aby sprzedac nadmiarowe uklady.

Nie wiem czy dobrze rozumiem, ale Gamebox to MicroLuc, a MicroLuc to Lucjan Brzyski - człowiek i firma z Bydgoszczy (spotkałem go w wojsku, ale wtedy w ogóle nie wiedziałem nic o jego działalności na C64 - nawet nie miałem wtedy jeszcze C64), który z BB9 raczej nie miał niczego wspólnego nawet z ich "klonowaniem".

[hobocti77x_]

Wiec calkiem mozliwe ze GameBox powstal aby sprzedac nadmiarowe uklady.

Nie wiem czy dobrze rozumiem, ale Gamebox to MicroLuc, a MicroLuc to Lucjan Brzyski - człowiek i firma z Bydgoszczy (spotkałem go w wojsku, ale wtedy w ogóle nie wiedziałem nic o jego działalności na C64 - nawet nie miałem wtedy jeszcze C64), który z BB9 raczej nie miał niczego wspólnego nawet z ich "klonowaniem".

Pisalem o tym
https://static.elektroda.pl/attach/gry1_9793105.jpg
https://static.elektroda.pl/attach/gry2_1792479.jpg
https://static.elektroda.pl/attach/gry3_2181312.jpg

[wegi]

aaa - sorry bo ja myślałem o TYM

https://www.c64scene.pl/viewtopic.php?f=2&t=3761

[radius75]

Na kanale Adrian's Digital Basement, odpakowanie BB9.
https://youtu.be/De5ufcDueRU?t=3407

[rime.]

Też wczoraj to widziałem, oglądam Adriana na obu jego kanałach. Nie kryłem zdziwienia jak zobaczyłem replikę BB9. Zgaduję, że raczej będzie to jeden z pierwszych Black Box V9 na terenie US . Gregor wspominał mi, że na początku istnienia repliki pojawiło się zainteresowanie cartem u kolekcjonera z USA, i podejrzewam, że to właśnie on wręczył jedną ze sztuk Adrianowi, podczas VCF. Ponoć cart trybi też w NTSC.

[wegi]

Ponoć cart trybi też w NTSC.

To raczej zależy co nazwiemy "trybi", bo wątpię żeby chciało działać ABC turbo bez osobnej, zamierzonej implementacji dla NTSC. Kolekcjoner pewnie ma też w kolekcji wersje PAL komodorków. Dodatkowo pewnie jest potrzeba przetwornica na 50HZ żeby to chciało właściwie działać. Mogę się mylić, ale nie wydaje mi się żeby to w 100% poprawnie mogło działać w NTSC - choćby muzyczki PAL odtwarzane w 60HZ...

[hobocti77x_]

Nie naruszę chyba RODO, jeśli zdradzę, że trzeba zwrócić uwagę na opakowanie.
W każdym razie było tak, że ta osoba od razu chciała uruchomić kartę na NTSC, no i... się nie udało. Skontaktował się ze mną i doszliśmy do wniosku, że problemem jest NTSC. Tak więc umówiliśmy się na inny termin, a on przygotuje komputer w systemie PAL, bo na co dzień z takiego nie korzysta. W międzyczasie podałem mu, aby sprawdził kondensator 180pF, bo akurat wówczas udało mi się ustalić dzięki użytkownikowi elektrody, że taki był w oryginale. Zaraz po tym David jednak wstawil kondensator 200pF i potwierdził, że BB9 działa na NTSC.
@wegi Dlaczego Turbo nie miałoby działać pod NTSC? Moim zdaniem problemem mogłaby być wymiana nagrań pod różnymi systemami, ale programy nagrane i odtwarzane pod NTSC powinny raczej działać tak samo jak i pod PAL. Wczytywałyby się nieco szybciej, ale te różnice nie powinny raczej uniemożliwić pracy.
Co do muzyczek, to pewnie masz rację, tyle że BB9 raczej wspiera programowanie w BASIC, więc mówimy tu chyba raczej o dźwiękach niż o muzyce.
Więc chyba te różnice nie powinny znacząco wpływać na "normalne ucho".

[wegi]

Moim zdaniem problemem mogłaby być wymiana nagrań pod różnymi systemami, ale programy nagrane i odtwarzane pod NTSC powinny raczej działać tak samo jak i pod PAL.

Słusznie!
ABC load/save - może działać pod warunkiem że będzie wykorzystane w 2 strony na tym samym komputerze (NTSC)
Na C64 NTSC nie da się odczytać gier/programów zapisanych przez C64 PAL
.
Należy pomyśleć o akumulacji błędu:
Z pewnością zauważysz, że ABC turbo wyłącza ekran - nie dlatego żeby ładnie "mrugać" rastrami, ale po prostu żeby VIC nie kradł 40 cykli co 8mą linię. Wieki temu (dosłownie! - lata 90's) reversowałem ABC turbo i nie mogę dokładnie przytoczyć całości, ale ogólną zasadę tak:
Problem polega na zmianie prędkości nadawanych bitów - w 2 strony - przy zapisie i odczycie - w porównaniu do standardowego zapisu C64. Robi się to co raz bardziej napięte i dokładne - tak jak nieraz widzisz w demach że powinieneś używać stacji dysków "cycle exact" - maksymalnie zsynchronizowej z:

1. 1MHZ taktowanie CPU (często jest trymer 50pf koło kwarcu 16MHZ)
2. Idealną, niezakłóconą prędkością obrotową dysku 300rpm

Nota bene ten trymer staje się później źródłem problemów i zaprzestania odczytywania loaderów like AR, ponieważ jak się degraduje, to wzrasta jego pojemność. Mam takie doświadczenie (i napisane programy), które to sprawdzają w taki sposób, że synchronicznie zaczynają mierzyć różnicę "przecyklowanych" (hehe) cykli w trakcie 1 ramki na C64PAL w stosunku do tego, ile w tym czasie upłynęło cykli w drivie - z moich doświadczeń wynika, że wszystko działa prawidłowo, kiedy w stacji minie w okresie 1 ramki PAL więcej cykli niż w C64PAL . Poprawną wartość empirycznie ustaliłem na ilość 273-303 cykli. A wartość bezpieczną i najczęściej spotykaną to 296 cykli więcej w drivie jak w C64PAL.

Chodzi o to samo... Np. loader Final3 ma opcję odczytu dyskietki z C64 PAL, jak i NTSC, ale jest to zamierzone i rozpoznaje na jakim C64 działa loader. Np. AR 7.3 (Atrax) już w NTSC nie zadziała - można sprawdzić choćby na emulatorze)

Po tak długim wstępie mogę przejść do sedna:


Teraz pomyślmy że dajmy na to (ZAŁÓŻMY DLA ZOBRAZOWANIA) co 63 cykle zegara odbierany jest 1 bit z taśmy w C64 PAL. Problem w tym, pomiędzy C64 PAL i NTSC te 63 cykle trwają różny okres - niewiele się różnią, ale różnią się!!!

I jeżeli PRZYKŁADOWO (bo nie pamiętam dokładnie) C64NTSC w 63 cykle "PALOWE" zrobi swoich cykli NTSC 64. Niby niewiele, jeżeli odebraliśmy 1 bit za szybko o okres 1/63 długości generowania się bitu - i tutaj właśnie do gry wkracza AKUMULACJA BŁĘDU - czyli w przypadku 1 bitu odebranie danej "za wcześnie o 1 cykl" nie powinno stanowić najmniejszego problemu, o tyle po odebraniu bitów np 128 (8 bajtów) nasz 1 cykl rozbieżności ZSUMUJE SIĘ do 128 cykli błędnego timingu odbierania danych, co już nieuchronnie musi zakończyć się katastrofą.
Gdyby ktoś chciał "oszukać system" i przyspieszyć prędkość przesuwu taśmy, wówczas jeżeli udałoby mu się dopasować do NTSC, wszystkie inne poprzednio nagrane pliki w NTSC przestaną być odczytywane.

Z tych samych powodów nie zadziałają turbo loadery dla driva - z wyjątkiem takich najprostszych jak np. loader z Final2. (FC3 zadziała, bo tak jest zaprogramowany) Szczerze mówiąc nie mam pojęcia czy BB9 obsługuje jakiś dopał dla driva.

[hobocti77x_]

Sugerowalbym te dyskusje o Abc turbo i. Actuon Replay przeniesc do innego/nowego tematu.Jest to bardzo ciekawy temat tyle ze nie bardzo dotyczy jakos szczegolnie Black Boxa a raczej problemow wszystkich systemow c64 i po prostu moglby u osoby czytajacej wzbudzic jakies zle emocje w stosunku do rozwiazania w BlackBoxie lub co jeszcze gorsze zanudzic osoby zaiteresowane BB9 na smierc. W nowym temacie chetnie sie ustosunkuje . Bo temat kolegi moze zainteresowac hardwarowcow ale dla niehardwarowcow bedzie zapewne dlugi i nudny. POZDRAWIAM

[hobocti77x_]

) Szczerze mówiąc nie mam pojęcia czy BB9 obsługuje jakiś dopał dla driva.

Odpowiem filmikiem w zalaczniku. Sorry ale nie mam stacji dyskow do c64 wiec posluzylem sie VICE. W kazdym razie zegar CPU na 100proc zgodnosci z c64
Ten sam plik najpierw wczytywany w normalu na VICE (BBv9 programowo odlaczony ) pozniej na BlackBox-ie v.9
Czy "dopal dla driva" istnieje czy nie pozostawiam kazdemu do oceny
Tu ktos nawet pisze ze turbo BBv9 jest znacznie szybsze od turbo w Final III
http://c64.com.pl/index.php/cartridge/r ... tridge=bb9
ACTION REPLAY (system fast load) 9,6 sek.
BLACK BOX V.9 10.4 sek.
FINAL III 14.5 sek.
FINAL II 25 sek.
odczyt normalny 121 sek.

[wegi]

Odpowiem filmikiem w zalaczniku. Sorry ale nie mam stacji dyskow do c64 wiec posluzylem sie VICE. W kazdym razie zegar CPU na 100proc zgodnosci z c64

ACTION REPLAY (system fast load) 9,6 sek.
BLACK BOX V.9 10.4 sek.
FINAL III 14.5 sek.
FINAL II 25 sek.
odczyt normalny 121 sek.

I teraz przełącz vice na C64NTSC model i sprawdź:

AR
BB9

Final 2 i 3

Moje proroctwo:
Finale będą działać, BB9 i AR NIE

[hobocti77x_]

FiNAL bedzie dzialac bo ma mniejsza predkosc i jest to chyba maksymalna predkosc jaka moze dzialac rownolegle na maszynach NTSC i PAL. Dalsze zwiekszanie predkosci jest mozliwe ale tylko oddzielnie dla obu sytemow.
Stacja dyskow i c64 to dwa niezalezne komputery i aby sie zsynchronizowac potrzebuja troche czasu. W kazdym razie z tego wynika ze BBv9 znacznie blizej jesli idzie o predkosc do AR niz do Final-a. Pewnie mozna to poprawic zmieniajac nieco parametry w BBv9, podobnie jest z AR ktory ma rozne pliki bin w wersjach dla NTSC i PAL (pod NTSC jest nieco wolniejsze turbo).
Ale raczej niczego tu nie zmieni krecenie trymerem.

[wegi]

Ale raczej niczego tu nie zmieni krecenie trymerem.

Błąd - ZMIENI

Final 2 ma prosty loader, przysyłany jest jeden bajt 2bitowo - to działa na PAL i NTSC. Final 3 ma 2 opcje ładowania w PAL i NTSC dlatego działa w NTSC.
Poza AR w wersji NTSC
zarówno AR w wersji PAL, jak i BB9 na 99% kręcenie trymerem złapałoby synchronizację i by ruszyły - 99% daję że by zadziałało, jeżeli się zwolni clock driva

edit:
Ale (chyba) w wypadku NTSC trzeba byłoby przyspieszyć clock driva - to już raczej klops, bo o tyle się nie da przyspieszyć co zwolnić

Czyli inaczej - AR w wersji NTSC można zapuścić na PAL jeżeli zwolni się clock driva - to by zadziałało

[hobocti77x_]

Czyli inaczej - AR w wersji NTSC można zapuścić na PAL jeżeli zwolni się clock driva - to by zadziałało

Nie da sie bo AR w wersji NTSC na maszynie PAL od razu ja zawiesza.
I moze dlatego BlackBox v9 jest ciut wolniejszy

[wegi]

Ten nie zawiesza :p

AR_NTSC.jpg (93.02 KiB) Przejrzano 998 razy

Action_Replay_V5.0_5.0_1988_NTSC.crt.zip

(24.11 KiB) Pobrany 40 razy

BB wolniejszy... nie ma znaczenia. To tylko kwestia załadowania dir czy coś, ale nie żeby ktoś starał się nie zawieszać C64NTSC

AR5_NTSC.jpg (84.17 KiB) Przejrzano 998 razy

edit:

BB9 wolniejszy, bo np AR ma swoje fast M-W czyli własną procedurą 2 bitową wysyła do stacji 3 bloki kodu. A BB9 robi systemowe M-W - i o to jest wolniejszy.

[hobocti77x_]

Mam przyjemnosc przedstawic efek ostanich kilku nieprzespanych nocy
https://www.youtube.com/watch?v=AyzxcSkpQXk
Jednym slowem mam juz wszystkie klocki czas zlozyc to do kupy

[wegi]

Ciekawy loader czytający z przeplotem 2 (0.4 sec na track) o 33% szybciej od AR.
Tyle że 1 obrót dyskietki (0.2 sec) traci na scaning linek, żeby sprawdzić czy sektor należy do pliku i w jakiej kolejności. Tym samym zrównując się z AR (0.6 sec/track), a nawet szybciej, bo wczytuje tylko sektory należące do pliku a nie całą ścieżkę.

Zadziała chyba tylko w stacji nr 8 (wg wstępnych badań)
ALE... zadziała jeżeli na serial porcie są inne urządzenia (nie używa ATN do synchronizacji)

Coś podobnego napisał kiedyś Olivier Stiller (MOST ACCES II+), ale niezupełnie to samo...
Wykorzystano illegal opcode SAX (0x8f)

Loader nie wyłoży się kiedy rozjeżdża się prędkość obrotowa dyskietki (w szczególności gdy przyspiesza), bo nie dekoduje częściowo GCR w trakcie odczytu.
No i loader zwolni w porównaniu do AR, bo nie odczytuje w całości ścieżki 18 żeby przeszukiwać katalog. Robi to za pomocą systemowego OPEN i w przypadku ponad 136 pliku w directory przeszukiwanie trwa z 5-6 sekund

Chyba w wolnym czasie mu się przyjrzę i dam jakiś raport

[hobocti77x_]

Chętnie zapoznam się z wynikami badań.