A gdyby pomyśleć wraz TMP nad mega Subcartem, który na Spartanie6 ogarnie jeszcze dodatkowo rdzeń fx VBXE? Spartan powinien z zapasem ogarnąć to co robi Altera. Hipotetycznie. Mógłby wyprowadzić kolejne złącze na obudowie z sygnałem RGB i byłoby przepotężne combo plug and play...

taaa... a z Atari używałoby jedynie prądu... bo przecież można by do carta podpiąć dzisiejszą klawiaturę na USB, a do tego też joya, czy pada na USB.

Chyba jednak nie.

Ja? Nie mam i nie widzę potrzeby posiadania :)

@Simius
Wczoraj na swojej konfiguracji (stock 600XL + Antonia2) sprawdziłem jeszcze Barbariana z DCarta, którego mam od Piguły i zachowanie jest identyczne jak przy uruchamianiu .car z SIDE3, czyli te poziome zakłócenia w trakcie rozgrywki.

Testowałem różne gry i znalazłem też problem z Prince of Persia: jeżeli od razu się nie skipnie spacją intra z obracającym się logo Atari, to po chwili się specyficznie wiesza: pojawiają się u góry drobne śmieci i nie da się go już pominąć. Szybkie przerwanie intra pozwala uruchomić właściwą grę.
Sprawdziłem wersje SIC i MaxFlash, dostępne np. tutaj:
https://atarionline.pl/v01/index.php?ct ... 50968fca30
Dziś jeszcze sprawdzę odpalając atr.

Powyższe oczywiście testowane w podstawowym scenariuszu: (Atari OS, CPU speed = stock, wyłączona pamięć 65816, RAM: 130XE lub 1088KB, bez znaczenia).

Aaa... Jak tak to jasna sprawa, szczęście, że da się to w porę skipnąć i uruchomić grę. Myślałem, że z illegal opcodes to tylko sarkazm w intrze ;-)

Tu jest taka sytuacja, że z SIDE3 w Barbarianie są same śmieci zamiast postaci (jak w SubCart), jeśli nie włączysz "hard emulation" (domyślnie wyłączone) w opcjach loadera SIDE3.
Wtedy na stocku będziesz mieć już normalnie, a na Antonii 2 pozostają już "tylko" te poziome glitche w trakcie rozgrywki, które widać już uruchamiając opcję "demo". No ale jak sprawdziłem, one występują na A2 uruchamiając z prawdziwego DCarta, więc SIDE3 tu już nie jest niczemu winne.

Od AI:

Wydaje mi się, a w każdym razie mam taką nadzieję, że złapałem przyczynę problemu z Barbarianem. Na górze stokowe SALLY, na dole IP-core 65C816. NMI przychodzi podczas wykonywania ostatniego cyklu rozkazu foregroundu, krótko po wystąpieniu IRQ. SALLY od razu obsługuje NMI, 65C816 bierze się najpierw za obsługę IRQ, którą dopiero po operacjach na stosie, pobraniu wektora i kodu pierwszego rozkazu przerywa dla obsługi NMI. Opóźnia to obsługę NMI (tu: DLI) o jakieś osiem cykli.

Próby szybkiego rozwiązania problemu przy pomocy AI nie powiodły się. Dwie kolejne propozycje Gemini, mimo, że sama diagnoza była poprawna, okazały się katastrofalne w skutkach. Muszę, niestety, sam.

Póki co, to tylko diagnoza i niekoniecznie źródło rzeczywistego problemu. Dopiero po doprowadzeniu do poprawnej obsługi NMI okaże się, czy to cos pomogło.

Fizycznego nie badałem analizatorem, bo zakłóceń w grze nie zauważyłem.

Fajny przesąd.

Może to najpierw sprawdź, zanim napiszesz.

Prawda jest taka, że w trybie emulacji 6502 takie INC NMIEN zadziała dokładnie tak samo jak na 6502.

A pecet ma Intela 8088, 4,77 MHz.

Przeczytaj jeszcze raz, co napisałem powyżej. A potem jeszcze raz i tak do skutku.

PS. I lepszym przykładem jest INC IRQEN.

wszyscy Cię kochamy Drac030, nie jesteś sam :)

Zrobiłem szybki test na moim flagowym 130XE z Rapidusem w najwolniejszym ustawieniu z '816, tj Sweet16 (zdjęcia poniżej).
Zero gliczy w Barbarianie w trybie demo z odtwarzaniem sampli.
Na Atari Age ktoś zasiał dezinformację, być może ustawił szybszy tryb, albo ładując .car z SIDE3 nie włączył HARD EMULATION.