XXL done excellent work with xBIOS and other programs. Better to stick with programming discussion. Know how tough it is dealing with people who believe they are better than you. I tried xBIOS with something a few years ago. Could not figure out how to make it work.

Odkąd Facebook mówił. Ktoś z tych grup Atari? Zawsze dzieje się coś ciekawego.
Powinniśmy być najbardziej zaniepokojeni, gdy znani ludzie przez długi czas milczą.
Jestem pewien, że ci ludzie uważają, że to, co robili, było słuszne z ich punktu widzenia.
Niektóre są nadal udostępniane społeczności Atari. Niektórzy zniknęli.
Facet z „RPG Games” ma nieprzyjemne nastawienie. Próbowałem z nim porozmawiać przez Messengera. Powiedział mi, że Centron3D jest skończony, ale nie wyda go, dopóki nie otrzyma przeprosin od Alberta. Jakieś sześć lat temu.
Rensoup wykonał kawał dobrej roboty z portem „Prince of Persia”, nie wiedząc, dlaczego udaje mu się na inne kłopoty.
Peteym5 wydaje się robić rzeczy z FASTBASIC, CC65, MADPASCAL. Udostępnia kod źródłowy. Blokuje pełny język asemblera. Z błędami w grze i prezentacją, na pewno problemem nie jest Video61?
Kolejną przerażającą osobą był Laird's Lair. Od kilku lat milczy.

Wysyłam Ci Prywatną Wiadomość ze zdjęciami tego, co jest o Tobie opublikowane na Facebooku.
Nie jesteś jedyną osobą, która ma problem z tym facetem.

Możesz być XXL, Jesteśmy z XXXI.
Dowiedzieliśmy się, co się dzieje z jego strony konta w mediach społecznościowych, która mówi o tobie.
Pamiętaj, że masz po swojej stronie ludzi, przeciwko którym stanął.
Kilka razy użyliśmy nazwisk z Twojego kraju.
Czasami łobuz na szkolnym dziedzińcu mówi o pożarze, ale wpada w szał i płacze, gdy ogień powraca.

Inflate and Deflate wykonuje dobrą robotę przy kompresowaniu danych na Atari. XXL wykonał dobrą robotę. Coś ciekawego dzieje się ostatnio przy użyciu tego kodu?

Have not been here in awhile. I did manage to speed up inflate times by reducing some of the JSR calls and placing a MACRO that does the some job. But it does take up slight larger space. I believe I removed getByte, GetBit, etc. Used Assembler Options with a flag depending how much I wanted to speed up things. For small chunks it does not make much of a difference. But If I want to compress a large game onto a 16K ROM, that deflates to 25K RAM. It shaves a few seconds off.

   SPEEDUP_1 = 1
     :
     :
    IFT SPEEDUP_1 = 0       
            jsr getBit         
    ELI SPEEDUP_1 = 1
          lsr getBit_buffer 
          bne no_get_next_input_byte
          jsr Get_Next_Input_Byte
no_get_next_input_byte
 
    ELI  SPEEDUP_1 = 2
          lsr getBit_buffer
          bne no_next_byte_for_get_bit
         
          pha
          lda    (inputPointer),y
          inc    inputPointer + 0
          bne   ip_l1
          inc   inputPointer + 1
ip_l1                       
          sec
          ror    @
          sta    getBit_buffer
          pla
no_next_byte_for_get_bit
    EIF

Hej, cieszę się, że tu jesteście z przyjaciółmi. Używałem tego pompowania wielokrotnie z programowaniem. Pracowałem z niektórymi optymalizacjami, aby przyspieszyć napompowanie dużymi fragmentami pamięci.
To właśnie próbowałem i wydaje się zmniejszać czas nadmuchiwania.

getWord
    jsr    getByte
    tax
; Read 8 bits
getByte    ; Using this version of get byte + get next input byte is a huge speed up.
    lda    #$80
getBits_loop   
    lsr    getBit_buffer 
    bne no_get_next_input_byte
    jsr Get_Next_Input_Byte
no_get_next_input_byte 
    ror    @
    bcc    getBits_loop
    rts

; Read one bit, return in the C flag
Get_Next_Input_Byte
    pha
    lda    (inputPointer),y
    inw    inputPointer
    sec
    ror    @
    sta    getBit_buffer
    pla
    rts

Gdzie jest etykieta „fetchCode_nextBit” dodaj:

fetchCode_nextBit
    lsr    getBit_buffer 
    bne GetBit_End_Fetch
    jsr Get_Next_Input_Byte
GetBit_End_Fetch