1

(14 odpowiedzi, napisanych Fabryka - 8bit)

Dzięki @mono
w sumie to trochę upraszcza sprawę zakresu $D5XX. Bo w tym zakresie cartridge ma totalny priorytet i w zasadzie nie ma się co przejmować tym co jest pod spodem.

2

(14 odpowiedzi, napisanych Fabryka - 8bit)

Poprawcie mnie jak piszę głupoty. Zakres $D5XX jest trzypoziomowy. Najniżej jest RAM. Nad nim jest ROM. I to wszystko przykrywa złącze cartridge. Jak carta nie ma to widzimy FF. Włączenie bitu SELFTEST powoduje migrację obszaru $D000 na $5000. Ale migracja dotyczy tylko(?) ROM. Więc w obszarze 55XX żadne FF się nie pojawią (?).

Czy w ATARI bez żadnych modyfikacji jest jakakolwiek szansa dostać się pod RAM $D5XX? Czy tutaj zawsze cart z butami siedzi.
Czy zapis na $D5XX zawsze idzie do carta, czy w zależności od PORTB jest w stanie trafić gdzieś indziej?
Jeżeli jest SELFTEST to zapis w $5000 idzie na manowce czy zapisze pod RAM "pod spodem"?

Dążę do wniosku, że jeżeli na D5XX zawsze jest widoczny cartridge to kopiowanie na żywca w emulatorze w zasadzie jest akceptowalne. Ale jeżeli magistrala przestawia się jak na semaforach to to co jest w atari800 to na pewno tego nie uwzględnia i zmiana musi być bardziej pokręcona.

3

(14 odpowiedzi, napisanych Fabryka - 8bit)

Może chodzi o to, że co prawda strona D5 zakrywa RAM, ale dla emulatora to to kopiowanie to nie jest "kopia do RAM". Tylko kopia dla kodu emulacji procka, który idzie z MEMORY_mem. No nie czaję tego...

Nie to jest coś pokręcone. To raczej wygląda jakby obsługa D5 w ogóle nie była zrobiona. Bo to, że akurat D5 się wykorzystuje do pstrykania bankami to nie jest ważne. Równie dobrze można by cały zakres A000-BFFF zrobić rejestrami a banki mieć na D5xx. CCTL to jest taki sam pin na złączu carta jak S4 czy S5.

4

(14 odpowiedzi, napisanych Fabryka - 8bit)

Na real sprzęcie zwykły ? PEEK(54528) pokazuje mi bajt z magistrali carta, więc jakbym podlutował zwykły ram to bym sobie mógł normalnie tam zapisywać. Jak jest rom to wiadomo, tylko odczyt. Więc bit PORTB (dla SelfTestu) chyba nie wpływa na D5 tylko na 50. I tu coś jest pokręcone w atari800. Bo on jakby na siłę chciał robić trik z SelfTestem.

5

(14 odpowiedzi, napisanych Fabryka - 8bit)

Jak było samo "GetByte" to D(isassembly) pokazywało kod poprawnie ale procek leciał na manowce.
Jak dodałem MEMORY_CopyFromCart to ruszył mi zarówno tester jak i inny programik co robię, który to na rzeczywistym sprzęcie też działa.
Nie mam za bardzo porównania, bo w sumie to nie spotkałem się z kombinacją, że procek wykonuje kod na stronie D5xx. A przecież nie ma ku temu żadnych przeszkód.

Ale z breakpointami to dziwna sprawa bo "b" nie działa natomiast jak dam:

bpc $D500

to wyświetla:

Breakpoint is at PC=D000

Jakie D0? Coś tu jest więcej zakręcone...

6

(14 odpowiedzi, napisanych Fabryka - 8bit)

@Fox
Dzięki! Będę się z tym próbował. Dziwne, że dwie instrukcje poszły.

Fork jest (powstał na potrzeby zabaw z JACART), ale zbytnio się tym nie chwalę bo babol z D5XX siedzi:
https://github.com/GienekP/atari800

EDIT.
DZIAŁA :)
Nie wiem czy elegancko dodałem, bo jeszcze nie czuję kodu atari800, w każdym razie wybrnąłem tak:

MEMORY_CopyFromCart(0xd500, 0xd5ff, active_cart->image + (active_cart->state & 0x3f) * 0x2000 + 0x1500);

7

(14 odpowiedzi, napisanych Fabryka - 8bit)

Ma ktoś doświadczenie z emulatorem ATARI800 i działaniem kodu ze strony $D500? Coś dziwnego się dzieje.

Zrobiłem sobie carta (DCart) co udostępnia cześć banku na stronę $D5XX, tak, że mogę wykonać kod nawet gdy sam cart ma wyłączony bank. Bardzo wygodna sprawa, bo można zaszyć procedury, które są "niezniszczalne". W sensie, przełączanie banków, RAM/ROM nie rusza ich.

Zrobiłem sobie tester i na real ATARI wszystko śmiga zgodnie z planem.

No to chciałem emulator ATARI800 uzupełnić o taki cart. Dodawałem sobie już carty, więc nie jest to jakieś trudne. I niby wszystko jest OK. Jednak coś ATARI800 ma poknocone z D5XX.

Puszczam kod w monitorze. Idę krok po kroku. Jestem na stronie $06 i skaczę pod $D500. Na polecenie "D" Debuger ładnie pokazuje kod ukryty na stronie $D5. Robię jedną instrukcję, sprawdzam, drugą, sprawdzam. Wszystko OK. Robię trzecią i kod idzie w adres z czapy $5462. Jakim cudem? Nic tam niema. A pod $D500 wszystko jest OK.

Próbowałem założyć BREAKPOINTy na stronie $D5 ale też coś to nie działa. Jakby ktoś w emulatorze zrobił bypass dla tego zakresu i jest on traktowany jakoś wyjątkowo. Ale znaleźć to to nie wiem jak.

Upgrade dla ATARI800 (z nowym cartem) oraz tester poniżej. Tester jest prosty. Miga ramka, po naciśnięciu START, skacze do RAM i tam kod miga tłem, potem START i skacze do $D500 i mają migać znaki. Na real działa, na emu nie.

Widok z monitora

> g
  0  21 A=A5 X=00 Y=94 S=FF P=N-*----C PC=064D: 4C 00 D5  JMP $D500
> 
  0  24 A=A5 X=00 Y=94 S=FF P=N-*----C PC=D500: A5 14     LDA $14     ;RTCLOK+2
> d d500
D500: A5 14     LDA $14     ;RTCLOK+2
D502: 8D C5 02  STA $02C5   ;COLOR1
D505: AD 1F D0  LDA $D01F   ;CONSOL
D508: 29 01     AND #$01
D50A: D0 F4     BNE $D500
D50C: 4C 77 E4  JMP $E477   ;COLDSV
D50F: A5 14     LDA $14     ;RTCLOK+2
D511: 8D C8 02  STA $02C8   ;COLOR4
D514: AD 1F D0  LDA $D01F   ;CONSOL
D517: 29 01     AND #$01
D519: D0 F4     BNE $D50F
D51B: A9 00     LDA #$00
D51D: 8D C8 02  STA $02C8   ;COLOR4
D520: AD 1F D0  LDA $D01F   ;CONSOL
D523: 29 01     AND #$01
D525: F0 F9     BEQ $D520
D527: A2 4F     LDX #$4F
D529: BD 35 B5  LDA $B535,X
D52C: 9D 00 06  STA $0600,X
D52F: CA        DEX
D530: 10 F7     BPL $D529
D532: 4C 00 06  JMP $0600
D535: AC C6 02  LDY $02C6   ;COLOR2
D538: A9 40     LDA #$40
> g
  0  26 A=A5 X=00 Y=94 S=FF P=N-*----C PC=D502: 8D C5 02  STA $02C5   ;COLOR1
> d d500
D500: A5 14     LDA $14     ;RTCLOK+2
D502: 8D C5 02  STA $02C5   ;COLOR1
D505: AD 1F D0  LDA $D01F   ;CONSOL
D508: 29 01     AND #$01
D50A: D0 F4     BNE $D500
D50C: 4C 77 E4  JMP $E477   ;COLDSV
D50F: A5 14     LDA $14     ;RTCLOK+2
D511: 8D C8 02  STA $02C8   ;COLOR4
D514: AD 1F D0  LDA $D01F   ;CONSOL
D517: 29 01     AND #$01
D519: D0 F4     BNE $D50F
D51B: A9 00     LDA #$00
D51D: 8D C8 02  STA $02C8   ;COLOR4
D520: AD 1F D0  LDA $D01F   ;CONSOL
D523: 29 01     AND #$01
D525: F0 F9     BEQ $D520
D527: A2 4F     LDX #$4F
D529: BD 35 B5  LDA $B535,X
D52C: 9D 00 06  STA $0600,X
D52F: CA        DEX
D530: 10 F7     BPL $D529
D532: 4C 00 06  JMP $0600
D535: AC C6 02  LDY $02C6   ;COLOR2
D538: A9 40     LDA #$40
> g
  0  29 A=A5 X=00 Y=94 S=FF P=N-*----C PC=5462: 00        BRK
> d
5462: 00        BRK
5463: 00        BRK
5464: 00        BRK
5465: 00        BRK
5466: 00        BRK
5467: 00        BRK
5468: 00        BRK
5469: 00        BRK
546A: 00        BRK
546B: 00        BRK
546C: 00        BRK
546D: 00        BRK
546E: 00        BRK
546F: 00        BRK
5470: 00        BRK
5471: 00        BRK
5472: 00        BRK
5473: 00        BRK
5474: 00        BRK
5475: 00        BRK
5476: 00        BRK
5477: 00        BRK
5478: 00        BRK
5479: 00        BRK
> d d500
D500: A5 14     LDA $14     ;RTCLOK+2
D502: 8D C5 02  STA $02C5   ;COLOR1
D505: AD 1F D0  LDA $D01F   ;CONSOL
D508: 29 01     AND #$01
D50A: D0 F4     BNE $D500
D50C: 4C 77 E4  JMP $E477   ;COLDSV
D50F: A5 14     LDA $14     ;RTCLOK+2
D511: 8D C8 02  STA $02C8   ;COLOR4
D514: AD 1F D0  LDA $D01F   ;CONSOL
D517: 29 01     AND #$01
D519: D0 F4     BNE $D50F
D51B: A9 00     LDA #$00
D51D: 8D C8 02  STA $02C8   ;COLOR4
D520: AD 1F D0  LDA $D01F   ;CONSOL
D523: 29 01     AND #$01
D525: F0 F9     BEQ $D520
D527: A2 4F     LDX #$4F
D529: BD 35 B5  LDA $B535,X
D52C: 9D 00 06  STA $0600,X
D52F: CA        DEX
D530: 10 F7     BPL $D529
D532: 4C 00 06  JMP $0600
D535: AC C6 02  LDY $02C6   ;COLOR2
D538: A9 40     LDA #$40
> 

8

(1,751 odpowiedzi, napisanych Fabryka - 8bit)

Rozumiem.
Zawsze stronę D5XX mogę zrobić tak, że na początku dam sobie tablicę skoków. I w każdym "minibanku" te skoki będą identyczne. Więc przełączanie tych minibanków po D5XX nie wpłynie na powroty itp.

Bardzo ciekawy ten xBIOS :)

@xxl

Jak już jesteś na linii to mam kilka pytań związanych z xBIOSem. Nie znam go a interesuje mnie sprawa obsługi cartridgeów.
1. Czy xBIOS umiałby potraktować pamięć carta jak sektory dyskietek ale z dziurami? Czyli np. z banku 8kB tylko połowa jest na te sektory a druga połowa to coś tam.

2. Czy biblioteki xBIOS umiałby się przecisnąć przez okno $D500-$D5FF. Chodzi mi, że jakbym zrobił takiego carta co przy zapisie bankuje jak zwykły Maxflash ale przy odczycie to tam w tym zakresie pojawi się normalny kod dla CPU to czy xBIOS dało by się ogarnąć w tych 256bajtach (ten zakres też mogłyby być bankowany)? Zmierzam do tego, żeby mając cart w ogóle nie używać pamięci RAM (no może stos).

10

(37 odpowiedzi, napisanych Fabryka - 8bit)

No ale skoro wiadomo w jakiej fazie jest PHI2 względem OSC, to przecież RAS i CAS jest stały względem OSC? Jak pływa to w skutek niedoskonałości. To ja bym olał wejście PHI2 do tego "zamiennika".

Dawniej technicznie był kłopot, że zegar powiedzmy 228MHz to poza zasięgiem. Teraz względem takiego zegarka zwykłe dzielniki (liczniki) zrobią to co kiedyś wypadało na przesunięciach fazowych.

0000000011111111 - to jest jakiś bazowy zegar
0101010101010101 - to po PLL x8
0123456789ABCDEF - to jest zwykły licznik 4 bitowy
0000111111110000 - a to przesunięcie -90 stopni (od fazy4 do fazyB)
0000000000001111 - a to przesunięcie +90 stopni z wypełnieniem 25%

Ja nie wiem czy by to zwykłym GALem nie obskoczył (oprócz tego multipleksera adresów).

11

(37 odpowiedzi, napisanych Fabryka - 8bit)

Kumam. Ale taki trik. Mam FPGA z wewnętrznym PLL. Niech będzie MAX10-tka. Obok niego mam oscylator 14.XXX (osobny, nie ten ATARowski). Sygnał wpuszczam na FPGA gdzie w środku mnożę PLLką niech będzie x16. Powstaje mi wewnętrzny zegar 224,XXMHz. Następnie najprościej jak się da maszyna stanu, liczona do 16.
Dla 0 wyjścia takie i takie.
Dla 1 ... itd.
Dla 15 ..
Wtedy nie potrzeba mi CLK_IN CLK_OUT PHI2. A OSC i wszystko co FREDDIE kontroluje ma zbocza żylety. Przesunięcia fazowe załatwia mi właśnie to zliczanie do 16 (ale może być większe przecież).

Czy wtedy PHI2 będzie stały w fazie (bo rozumiem, że zbocze SALLY jakoś tam zepsuje)?

12

(37 odpowiedzi, napisanych Fabryka - 8bit)

Technicznie: Czy ktoś kiedyś wieszał się jakimś naprawdę wypasionym oscyloskopem na CLK_IN CLK_OUT PH0 i PH2?
Chodzi mi o wyłapanie niuansów, co robi takie krzywe zbocza i lekko pływające w fazie (przynajmniej u mnie to tak wyglądało na gnieździe carta).
Chodzi o tego "FREDDIEGO"?

No bo jak te Freddie padają (a ja mam też 65XE) to może trzeba by zrobić taki wypełniacz PRO na bazie konkretnego FPGA z PLLami żyleta?

Czy:
CLK_IN
CLK_OUT
OSC
FPHI0
PHI0
PHI1
PHI2
To wszystkie zegary ATARI?

13

(37 odpowiedzi, napisanych Fabryka - 8bit)

Matko. Czytam z zainteresowaniem, bo zastanawiałem się jak sobie poprawić PHI2 na złączu carta, bo tak na oko oscyloskopu to on jest w fazie nijakiej z wypełnieniem dziwacznym. Kiedyś PLLem poprawiłem fazę (na minus) CLK dla HDMI (pixelclock74MHz) lecącego drutem przez slipringa. PLLka robi to w trybie basic przy minimalnej wiedzy operatora.

No ale tutaj jakaś masakra jest, przecież te zegary latają po wszystkich układach i każdy coś w nich grzebie. To jak na końcu cart ma się dobrze wystawić na magistrali i dla CPU i ANITCa i GTIA to bez szans jest gmeranie przy tym. To cud, że to w ogóle działa :/

14

(7 odpowiedzi, napisanych Programowanie - 8 bit)

OK sprawdziłem :)
Są plusy i minusy.
Puszczenie ładowania z jednym normalnym VBLANK powoduje, że rejestry ładnie się odtwarzają i gra wczytuje się z normalną niebieską ramką (tak jak z kasety czy dyskietki). PLUS :)

Jeżeli ANTIC patrzył na A000-BFFF to przełączenie banków puszcza ANTICa w maliny :/ MINUS

Nie zawiesiło się na moich przykładach, ale to kwestia prawdopodobieństwa.
Raczej nie ma szans, żeby podczas wczytywania stabilnie utrzymać czołówkę jeżeli siedzi na A000-BFFF.

No można też tak jak zrobiłem w ATR2CAR, że wszelkie odczyty zaczynają się na końcu obrazu, wtedy bankowanie nie miga. Ale to bardzo zmniejsza transfer. Więc chyba lepiej po CRITIC wyłączyć DMA i ładować binarkę na pełnym speedzie. W końcu XEX to chcemy jak najszybciej uruchomić i czarny ekran pomiędzy fazami ładowania nie taki tragiczny.

15

(7 odpowiedzi, napisanych Programowanie - 8 bit)

Może być też problem. Chodzi o DL pod bankami carta.

Procedura wygląda tak:
1. Włącza się cart, odkładam na stos DL kolory itd. Czyli to co zmieniam. (Niektóre XEXy zakładają, że edytor jest skonfigurowany więc trzeba im to odtworzyć przed ucurhomieniem)
2. Ustawiam DL na carta bo tam jest menu itp.
3. "Operator" wybiera grę
4. Biorę ze stosu oryginalne DL itd. Ale wyłączam DMA (!)
5. [Błąd] od razu włączam CRITIC - a to powoduje, że te cienie (oryginalne odtworzone z procedury boot) nie zdążą się przepisać więc w tle są te co pokazują na carta (ale jeszcze tragedii nie ma)
6. Jeżeli XEX idzie w jednym bloku to dociągnie na tym wyłączonym DMA (wtedy nie ma problemu)
7. Gdy wykryję koniec pliku to wyłączam CRITIC ustawiam TRIG3 i skaczę do RUNAD (i super)
8. Gdy wykryję INITAD to robię tak. Wyłączam CRITIC ustawiam TRIG wyłączam CARTA i przekazuję skok do INITAD. Jak procedura wraca włączam CRITIC i jadę dalej [Błąd bo jak proceudrka coś ruszała przy DL jakieś czołówki to ten CRITIC jest fatalny]
A najgorszy przypadek, jak procedura INIAD włączy DMA, ANTIC patrzy na DL na adresy na carcie lub pod cartem (najcześciej :/), ale przecież podczas wczytywania ja przełączam banki. No to jak podmienię BANK na który patrzy ANTIC to czort wie gdzie on potem trafi z adresami, wskaźnikami do pamięci itd. Zawsze przed zawieszeniem obraz przez chwilę migał.

Roboczy loader w załączniku (na razie tyle mam). A,B,C.. wybiera grę. Dowolny klawisz losuję nam grę (tego chyba nie ma nikt). Co ciekawe loader z MaxflashStudio nie potrafi załadować Hacker.xex. Nie wnikałem dlaczego, u mnie to łyka. Dobrze idą mi gry co idą partiami (Szpiedzy oraz Scorch). Może dlatego, że zabieram tylko 21 bajtów z pamięci RAM (tam gdzie stos, ale na jego końcu więc kompresory lecą OK).

Loader będzie dla MAXFLASH (na tym na razie bazuję bo najtrudniejsze), S-XEGS i RAMCART. Program jest uruchamiany z konsoli (skompilowanej na... wszystko co ma gcc) a menu pobiera z pliku TXT (tak przyszłościowo, żeby własne zestawy robić przez serwer www ;) )

16

(7 odpowiedzi, napisanych Programowanie - 8 bit)

@Bober
Racja. I mało tego sam sobie to sprowokowałem. Cart startuje mi z A000-BFFF. Tam sobie ustawiam jakąś DL itp. I teraz robię następujący błąd. Ponieważ ATARI OS nie lubi jak się włącza i wyłącza carta. Po prostu traktuje to jako "wykryto cartridge" i chce robić reset. To ja robię taki trik:

lda #01
sta CRITIC

Takie coś załatwia, że podczas każdego VBLANK nie sprawdzana jest różnica między TRIG3 i GINTLK. Generalnie super sprawa, bo mam więcej wolnych cykli i szybciej się ładują dane z carta. I w ogóle mogę pstrykać na RD5...
ALE
CRITIC też wyłącza jakieś odświeżania rejestrów sprzętowych względem ich cieni. To też powoduje, że ANTIC ma coś tam nie ustawiane i jak przed CRITIC był na $Axxx i wczytywany XEX coś tam namiesza i robi śmietnik to ANTIC powoli wędruje w stronę $D5xx. Jak ją tylko dotknie to masakra. O tym czy doczłapie się do tego adresy decyduje jak długo to trwa i jaki śmietnik był. No i na małych XEX wszystko działało. Ale jak XEX był długi i jeszcze jak miał dużo tych bloków DOSowych FFFF to nagle cyk... i jakiś dziwny bank włączony. :/

Za diabła nie idzie tego wyłapać. W emu breakpointy na procka nic nie dają, bo tu ANTIC ładuje się na magistralę i chce czytać.

Natomiast okazuje się, że trzeba zrobić bardzo prosty trik

lda #$01
sta CRITIC
lda #$00
sta DMACTL

czyli dla aktywowanych operacji krytycznych czasowo, dla bezpieczeństwa wyłączyć ANTICa. Żeby nie trafił przez przypadek na odczyt D5XX gdzie standard maxflash szaleje.

I po operacjach czytania na carcie

lda TRIG3
sta GINTLK
lda #$00
sta CRITIC

I ładnie pojawia się obraz wtedy kiedy trzeba, nawet jak XEXy mają jakieś czołówki w czasie ładowania to wszystko śmiga. Wyłączenie CRITIC powoduje, że już VBLANK ładnie pilnuje ANTICa. A że TRIG3 i GINTLK jest identyczne to nie ma reakcji na pstrykanie cartem.

No taki niuans :)

Edit
@Fox
W ogóle przed wczytywaniem XEXa wyłączyłem DMA. Ale niektóre gry po kilku blokach włączają sobie czołówkę. Potem ja czytając dalej znowu włączam CRITIC i za random-czas klapa.

17

(7 odpowiedzi, napisanych Programowanie - 8 bit)

Zawiesiłem się na następującym problemie. Robiąc loader wczytujący różne XEXy z carta w standardzie Maxflash wyszło mi takie coś, że czasami ni stąd ni z owąd przełącza mi się bank w carcie. Pozakładałem "milion" breakpointów w EMU i wszystko OK. Ale... Niektóre gry (ZORRO) składają się z wielu bloków tych DOSowych i podczas wczytywania ustawiają jakieś śmieci na DL. Zwykle podczas wczytywania to nie przeszkadza, że tam jakieś cudaki po ekranie latają.

No ale wygląda na to, że przy ANTICu ustawionym na pałę, może się zdarzyć taka sytuacja, że sięgnie on szyną aż do D5XX. A tam maxflash nawet na READ przełączy bank. No masakra jakaś. Czy to w ogóle możliwe, żeby ANTIC z jakąś randomowy listą hulał po całej przestrzeni? Da się go jakoś przytemperować?

18

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

Tak w Decathlonie jest jakiś algorytm całkujący... Zmiana stanu joya podbija, a brak powoduje opadanie siły, więc pewnie da się pobudzać go trochę wolniej. W każdym razie co ramkę sprawdza stan joya. Żeby słupek siły był zablokowany na maks to musi być co ramkę zmiana (i to robi ten hack w przykładzie, zmienia BEQ na BNE sprawdzające czy w nowej ramce była zmiana). Bez tego słupek tylko pulsuje do maksa, co łatwo sprawdzić włączając emu na mniejszym speedzie.

19

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

To jest ciekawe, że kiedyś graliśmy i na 20ms a teraz jest super jak jest 80ms a jeszcze jak dojdą jakieś chmury to czasem po 200ms jest delay. Ale też zaobserwowałem, że odpalenie ATARI młodemu pokoleniu daje jakąś dodatkową frajdę właśnie z tego pixelperfect i tych 20ms. Po prostu błysk, dym i "zabity". Bezwzględnie, bezlitości, bez dyskusji.

No ja czyściłem tego na zdjęciu joya. Tak mu się robi co jakieś kilka lat (bo ma już 35). Mikrostyk (ta blaszka w środku) pokrywa się jakimś nalotem no i robią się takie dziwne opóźnienia. Może to jest to?

W sumie mógłbym wymienić na nowy styk, no ale skoro da się naprawić. Joy ma jeden tylko przycisk, toporny że aż ręka boli. Swoją drogą kolega w owym czasie miał lutownicę kupioną w sklepie identyczną jak rączka tego joya :) Dlatego obstawiam, że mikrostyk też jest bez jakiejś filozofii i pasuje od "Żuka".

Natomiast w mechanizmie mikrostyku to ten ruch nie jest taki idealnie prostopadło-równoległy. Więc przy nalocie pierwsze dotknięcie może mieć faktycznie jeszcze dużą rezystancję. Dopiero jak się "wwierci" to łapie.

... robię ten "oscyloskop" :)

EDIT
Decathlon sprawdza co 20ms. Założyłem breakpoint na odczycie PORTA i co odczyt przyrasta na tablicy czasu o 0,02s. Czyli maksa można nabić machając 25Hz. No to dzisiejsze pady wymiękają :)

EDIT2
Nie mogłem się powstrzymać i zrobiłem turbohacka dla Decathlona. Nawet z tym 110 przez płotki nie jest łatwe :)

20

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

@Mq
Dobrze piszesz. Takie coś da niezłą regularność detekcji. Bo raczej szybciej niż linia to programy nie wykrywają zmian.

Taki coś mi przyszło do głowy, że jak jest program ANTICa i np. co linie ma LMS z przerwaniem DLI to w zasadzie można mieć przygotowane wcześniej te kombinacje naciśnięcia przycisków i kierunków w postaci grafik. I teraz co linię sprawdzam port i ustawiam adres następnej linii na tą odpowiednią grafikę.
Powstanie taki obraz działania styków. W zasadzie można się trigować jak oscyloskop, czyli od pierwszego skoku do 239 linii i stop. Powiedzmy, ileś do tyłu i będzie wykres jakości działania przycisku.
Aż to sprawdzę, czy taki numer przejdzie :)

21

(5 odpowiedzi, napisanych Programowanie - 8 bit)

Dzięki!

22

(5 odpowiedzi, napisanych Programowanie - 8 bit)

Poszukuję 1024 bajtów z polskimi fontami. Taki gotowy 1kB do wklejenia w MADS do programiku co robię (wieloplatformowego). Robię taką wybieraczkę do cartów jak "MaxFlashStudio", ale żeby i inne standardy cartów łyknęło. No i chciałbym, żeby polskie tytuły były PO POLSKU :) Od strony PC bazuje na UTF-8. Wszystko sobie przekodowałem no ale lenistwo odrzuca mnie od pikselowania fontów. A całkiem możliwe, że ktoś to już zrobił :)

23

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

Jak masz omomierz taki z epoki (analogowy) do dwie szpile i do kabelka joya. Zobaczysz po wskazówce czy zanim nie złapie to nie lata w te i nazad. Bo jeszcze może być tak, że "gra" sprawdza joya w jakiś tam czasach a u Ciebie zanim zaskoczy styk to "podzwoni" przez chwilę. Wtedy powstaje randomowy delay. U mnie takie kwiatki się robiły i ostatecznie rozebrałem i joya i mikrostyk (na te sprężynki) i czyściłem. Bo mój joy ma tylko jeden przycisk bo to epokowe polskie dzieło :)

EDIT:
A jak często odświeża ATARI port? Tam da radę szybciej niż 50Hz? Bo przyszedł mi taki pomysł, żeby zrobić tester na zasadzie "waterfall". Raczej by pokazało czy styki utraciły na kontakcie.

24

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

This is a standard 16kB cartridge. It can be easily converted to XEGS-128kB (S-XEGS).

25

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

Tak, logika musi być dość złożona, gdy chcę, żeby $D5xx było jakimś ostatnim bankiem pamięci flash. Wtedy trzeba błyskiem przestawić adresy. Podobny trik robi S-XEGS, gdy pojawia się nS5 to ma włączyć ostatni bank.

Natomiast jak przestrzeń może się pokrywać, to już jest banał.

Teraz carty zgodne z maxflashem mają:
nCE = nS5
Robię trik:
nCE = ( nS5 AND nCCTL )

i wtedy "chyba" A000-BFFF widzi cały bank a $D5XX widzi tylko $B500-$B5FF? Tego drugiego nie jestem pewien :/

Generalnie to próbuję wybrnąć z problemu konwersji ATR do CAR, gdzie muszę gdzieś dać kod obsługi carta. Niestety ale programy nie stosując żadnych zasad i latają po całej pamięci włącznie ze stosem. Jak to jest krótki kod na kilka bajtów to gdzieś wciśnie. Ale jakby był dłuższy (np. zapisy itp) to kłopot. A zakres $D500-$D5FF nie są w stanie zepsuć bo to jest już sprawa sprzętowa.
Natomiast bez sensu byłoby lutować ekstra pamięć na obsługę $D500-$D5FF. Więc kombinuje jakby tu jedną kostką pokryć dwa zakresy gdzie tylko jeden z nich jest wyłączany.