Tak całkiem teoretycznie to nie jest takie środowiska wcale potrzebne. Program napisany pod Visual Studio używający np Qt po przekompilowaniu na linuksa powinien po prostu zadziałać, o ile napisało się go oczywiście dostatecznie przenośnie, ale Qt jest frameworkiem, który dostarcza praktycznie wszystko, więc jak ktoś chce, to nie musi poza niego wychodzić.

Używam tych makr. Tutaj akurat chodzi o hint dla asemblera (deklarację) jaka jest spodziewana szerokość rejestrów w danym miejscu, tak, aby asembler mógł wygenerować błąd, jeśli obliczona przez niego szerokość będzie różna, czyli np. (w pseudokodzie):

regA 16  ;rozkaz przełączający akumulator na 16 bitów
.a8 ; deklaracja, że w tym miejscu akumulator ma rozmiar 8 bitów -> ERROR

albo

.proc Prodecura
.a16 ;deklaracja 16-bitowego akumulatora.
...
.endp

...

.a8   ;deklaracja 8-bitowego akumulatora.
jsr Procedura  ;skok do procedury z kontekstu 8-bitowego akumulatora.
                Procedura deklaruje szerokość na 16-btów -> ERROR
...

Ej. A może koledze chodzi po prostu o wgranie programu w BASICu (który ma na PC w postaci pliku tekstowego) do atari, żeby pojawił się w tam jako program (czyli LIST, RUN... te sprawy)?

O! Super! Wiedziałem TeBe, że można na Ciebie liczyć :)

Jak zrobi się opt h- (w przykładzie jest przypadkowo h+), to generowany plik jest identyczny jak z AlfAssemblera.

OK. O tym nie myślałem. Nie wiem czy stosunek trudność do zysków jest opłacalny, żeby się za to zabrać. A format COMa position-independent, którego trzeba po prostu załadować pod dowolny adres, potrzebuje przynajmniej nagłówka sygnalizującego niezależność od adresu oraz długość bloku. Czegoś takiego nie ma, bo na 6502 nie było to sensowne, a na 65c816 już tak.

Operatory < ! > wydają się sensowne. Asembler powinien tylko wypisywać warning gdy żaden operator nie jest użyty (programista oczywiście może wiedzieć o co mu chodzi, ale tutaj wg mnie lepiej być dosłownym, bo to zmniejsza okazję do błędu).

Mads ma 24 bitowe adresowanie, nie potrafi tylko ustawić adresu asemblacji na adres spoza banku zerowego. Nie potrafi tego ani dyrektywa ORG, ani .SEGDEF. Odkryłem jednak, że potrafi to blok .PROC, któremu można ustawić dowolny 24-bitowy adres. Gdy już myślałem, że jest to rozwiązanie, okazało się, że z 24-bitowego adresu nie można (albo raczej nie potrafię) wyciągnąć 16 bitowego offsetu w segmencie i taki kod się nie kompiluje:

    opt h- c+

    org $0000

    .proc test, [$010000 + *]
label    lda.w #label
    .endp

label    lda.w #label
test.asm (6) ERROR: Value out of range

O nagłówku $FBFB dobrze wiedzieć. Szukałem czegoś takiego. Sprawdziłem i działa poprzez dodanie nagłówka z dwoma 24-bitowymi adresami do każdego bloku. Aczkolwiek wydaje mi się, że adres końca wystarczyłby 16 bitowy, ale to już szczegół.

Co do asemblerów, to w grę wchodzą tylko cross-assemblery (mam już środowisko do budowania itd). Co jest w madsie, a niema tego (nie znalazłem) nigdzie indziej, to idea procedur (bloki .PROC), która po podrasowaniu bardzo dobrze może wpisywać się w schemat programowania 65c816. Blok .PROC grupuje fragment kodu w logiczną całość z lokalnymi etykietami, a przekazywanie parametrów może być zrealizowane za pomocą stosu 65c816. Np. "engine" do deklarowania parametrów procedury mógłby służyć do śledzenia zawartości stosu. Np takie procedury mogłyby być tożsame:

    .proc sum1 ( .BYTE par1,par2 )
    lda pra1
    clc
    adc par2
    rts
    .endp


    .proc sum2
    lda 2,s
    clc
    adc 1,s
    rts
    .endp

Dodatkowo procedury można byłoby wzbogacić o chociażby specyfikację stanu procesora jaki w niej obowiązuje (długość rejestrów) i asembler mógłby śledzić czy stan jest spójny pomiędzy wywołaniami (niby nie daje to żadnych gwarancji, ale pomaga przy zachowaniu konwencji, no i tak, wiem, że mechanizmy śledzenia to nic nowego :)).

Poużywałem trochę tego Debut Video Capture i jest całkiem niezły, ale dziś zauważyłem kluczową wadę: zaczął mnie informować, że expiruje za next few days :(
Myślałem, że jest płatny tylko do nagrywania, a na podgląd będzie pozwalał. Jak zgaśnie mi całkiem, to będę musiał wrócić do VirtualDuba, a szkoda.

Póki co namierzyłem tę stronę, ale sterowników z niej nie próbowałem: http://www.sabrent.com/category/tv-vide … USB-AVCPT/
Jakiś facet z forum MS polecał na Win 7 x64 konkretnie ten: http://www.sabrent.com/drivers/USB-AVCP … r_Win7.zip

Powód musi być inny, bo ja używam przez SVideo pod Win7 64bit i mam normalnie kolor.

Dzięki za odpowiedź.

Rozebrałem drugą stronę. Mam nadzieję, że po złożeniu będzie działać.

Niebieski jest już przylutowany do pinu 5 (na zdjęciu niestety nie widać tego dobrze). W konsternację wprowadziło mnie to, że czerwony jest przylutowany do 8., a nie do 9. tak jak na schematach.
Udało mi się jednak porozmawiać z Pasiem i on stwierdził, że mam wersję CTS, stąd pin 8, a kabel żółty, tak jak mówiłeś, powinien być przylutowany do pinu 2.

Poproszę kolegę z pracy, żeby zrobił mi to tak jak należy, żeby znowu się nie rozwaliło.

6502/6502C różnią się na tyle niewiele, że różnica w nielegalach powinna być wg mnie tylko na poziomie rozkazów niestabilnych, czyli zbierających śmieci z szyny. Specyfika WARów polega na utracie poczucia czasu, bo po 7 cyklu urywa im się film ;) i nie ma możliwości, żeby któryś przeszedł do następnego rozkazu. Do pamięci nigdy nic nie zapisują, kwestia tylko, czy nie modyfikują żadnych rejestrów. Symulator pokazuje, że nie, ale nie mamy pewności nieistnienia po drodze żadnych "efektów szynowych". Potrzebne byłyby albo wnikliwe testy w dziczy z podmienionym ROMem, żeby przechwycić oryginalny RESET, albo mądrzejszy symulator potrafiący wykryć niestabilności - wg mnie jest to możliwe na poziomie symulacji.

Ogólnie tylko żartuję sobie z arbitralnego podziału STABILNE / NIESTABILNE i odmowie nadania stabilnego statusu rozkazom, które u nikogo nie zrobiły nigdy nic innego, jak zaczekanie na RESET. Jestem przekonany, że da się to rozstrzygnąć za pomocą odpowiedniego symulatora (poprzez wykrycie "zapisów" na wewnętrzną szynę z kilku źródeł), ale gra nie jest warta świeczki.