gwoli ścisłości... w trybie Hi-Res w przypadku 8-bit Atari litery zawsze mają kolor tła na którym się znajdują... w standardowych warunkach nie uzyskasz białych, czerwonych czy innych liter w kolorze odmiennym niż ma tło... masz wpływ tylko i wyłącznie na ich jasność. A że domyślnie tło masz "niebieskie" to i litery będą miały ten odcień jak zmienisz na zielone to i litery staną się zielone, tak ma być.

Jak już będziesz miał klawiaturę to spróbuj sobie napisać z poziomu BASIC-a np:

POKE 710,196

albo

SETCOLOR 2,12,4

standardowe "niebieskie" tło i litery z o jasności 10, przyjmują odcień tła (0x94):

po zmianie tła na odcień "zieleni" (0xC4) litetry o jasności 10, przyjmują również jego odcień:

Standardowy format zapisu danych używany w przypadku Atari to właściwie transmisja szeregowa plus modulacja częstotliwościowa (FSK)... taki format zapis danych jest bardzo wrażliwy na wszelakie odchyłki od prędkości narzuconej przez prędkość odbioru danych narzuconą przez Baud Rate Generator (BRG)... co prawda procedury obsługujące jak i format danych zostały niby przystosowane do kompensacji odchyłek, np. pomiar aktualnej prędkości danych na podstawie bajtów transmitowanych na początku każdego nagłówka rekordu, a potem korekcję prędkości BRG... do kompletu podział na krótkie rekordy danych... jednak jak pokazał praktyka przy mizernej jakości magnetofonów wszystkie te pomysły były niewystarczające... dodatkowo demodulator FSK zastosowany w przypadku standardowych magnetofonów Atari nie jest szczytem możliwości rozwiązań technicznych dostępnych w tamtym okresie (znowu cięcie kosztów) .... a to powoduje że niewielkie już zniekształcenie sygnału zapisanego na taśmie powoduje przekłamanie w odczycie transmitowanych danych.

Systemy turbo stosują nieco inną zasadę zapisu... nazwaną "modulacją szerokości impulsu" (ang. PWM - Pulse Width Modulation) i można się spierać że to koniec końców dość podobne do FSK, ale założenia teoretycznie i realizacja sprzętowa inna, np. w przypadku odczytu nie mamy tutaj sprzętowego dekodera który decyduje czy to do niego wchodzi na wejściu jest aktualnie transmitowaną "1" czy też "0". Wszystkie systemy turbo swoją konstrukcją sprowadzają się do jednego... do zrealizowania wzmacniacza o dużym wzmocnieniu który będzie mógł przetworzyć zapisany na taśmie sygnał postać zero-jedynkową... potem ten strumień danych jest już przetwarzany "programowo" ... decyzję o tym czy przychodzące impulsy traktować jakoś 0 czy 1 podejmuje kawałek programu mierząc czas trwania poszczególnych impulsów... tutaj oczywiście programista miał pełną dowolność co do wyboru metody kodowania poszczególnych stanów, a także co bardzo ważne... miał dużą swobodę co do wyboru tolerancji długości impulsów... z mojego doświadczenia z systemem Turbo 2000, wynika że autor rozwiązania przyjął bardzo dużą tolerancję systemu na odchyłki dotyczące długości czasu poszczególnych impulsów określających "0", "1" czy sygnał pilotujący.

Moje XC12 w pewnym okresie zaliczyło przysłowiową glebę, przez co skrzywieniu uległa ośka do której dociskana jest taśma, efekt był taki że następowała ogromna nieliniowość przesuwu taśmy, oczywiście zapis i odczyt w "standardzie" okazał się niemożliwy... natomiast odczyt/zapis w przypadku turbo 2000 nadal przebiegał bez problemów, nawet pomimo wyraźnie słyszalnego (i widocznego) nierównomiernego przesuwu taśmy.

Ponieważ na warsztacie mam teraz trochę magnetofonów od kolegi uicr0Bee i zacząłem walkę z innymi systemami turbo, to mogę powiedzieć że systemy turbo która zakładają mniejsze tolerancje i oczekują wyższej liniowości przesuwu taśmy, czy też oczekują wyższego pasma które można zapisać na taśmie dany magnetofon są również bardzo kapryśne i wczytanie części programów staje się nie lada wyczynem, a szczególnie tych które były zapisane dawno, dawno temu. Czy to Blizzard, czy to TurboROM nie wypadają już tak różowo jeżeli chodzi o stabilność pracy. Magnetofon musi być naprawdę w dobrym stanie aby te systemy działały sprawnie i bezproblemowo.

No i do tego wszystkiego błąd w OS-ROM, o którym napisano już wyżej. Czy zatem standard FSK jest gorszy od PWM? Trudno mi to oceniać, ale uważam że doskonałym przykładem że FSK może być równie skuteczne był system Turbo 2600. Ten system pokazuje że dało się skonstruować stabilnie działający demodulator FSK, oraz napisać całkiem poprawnie działające procedury odczytu i zapisu. System ten niestety nie przyjął się, a złożyło się pewnie na to kilka faktów... całe oprogramowanie siedziało pod OS-ROM, w już w tamtych czasach gdy promowano to rozwiązanie w "Radiokomputerze"... duża część oprogramowania ładowała się również w ten obszar, uniemożliwiając poprawną pracę tychże programów z systemem. Nie wiem czemu autorzy rozwiązania nie zaproponowali czegoś w rodzaju loaderów, czy mini Kasetowego Systemu Operacyjnego ładowanego na dół pamięci. Wydaje mi się ze autorzy systemu bardzo chcieli w tamtym czasie chronić swoją "własność intelektualną" i chronili dostęp do informacji o działaniu ich systemu i ograniczali wszelaką wiedze o nim, co przyczyniło się do jego upadku. Interfejs do tegoż systemu były ponoć dostępne w "składnicy harcerskiej" w Warszawie, jednak nie udało mi się nigdy takiego interface kupić. Używając magnetofonu szpulowego M2404S i zew. interfejsu udało mi się natomiast bez problemu uzyskiwać prędkości transmisji na poziomie 1300bd. (przy przesuwie taśmy 19,05cm/s)

to no nie tak że "nikt"... ja jestem bardzo mało reprezentatywną "grupą" reprezentującą to zjawisko :) zapewne jestem jakimś wyjątkiem :P wiesz mogłem siedzieć wtedy długo pod kamieniem... albo "wyginałem" jak dinozaury ;-)

wyłączenie "SIO patch" pomoże tylko wtedy gdy ładujesz to np. z załączonego wyżej pliku ATR (dlatego pozwoliłem sobie go dołączyć), jeżeli wrzucisz (drag&drop, boot image, etc.) plik .XEX do emulatora zostanie on załadowany błyskawicznie, niezależenie od stanu "SIO Patach", przynajmniej u mnie się to tak zachowuje pod Altirra.

Nie miałem zbyt dużo czasu, ale udało mi się wyrwać chwilę z dostępnej puli aby przygotować przykład. Przykład składa się z dwóch kawałków, jeden to kod w asemblerze który potem jest wykorzystany w programie w Atari BASIC, kod w asemblerze wygląda tak:

; simple ROM-RAM routine
; 
; done by Seban @ 2019.05.05, Public Domain
;
; this code is relocatable, can be run from any address
; and it's ready for call from Atari Basic USR function

        opt     h-      ; disable any headers

ptr     equ $cb         ; zero page pointer
osrom   equ $c000       ; OS-ROM address
    
        org     $600    ; default adress of code
    
start   pla             ; call from BASIC, so remove one byte from stack (# of parameters)

        ldy #$00        ; set lo-byte of pointer to zero, also zero the Y reg.
        sty ptr+0
        lda >osrom      ; set hi-byte of pointer to OS-ROM location
        sta ptr+1
    
        lda #$01        ; set the bit #0 of portB to ensure that OS-ROM is enabled
        ora $d301
        sta $d301
    
        sei             ; disable IRQ
        inc $d40e       ; disable NMI
    
l0      lda (ptr),y     ; load ROM location into A reg.
        dec $d301       ; disable ROM
        sta (ptr),y     ; store A reg. into RAM under ROM
        inc $d301       ; enable ROM
        iny             ; next byte on page
        bne l0          ; loop until page end
    
        inc ptr+1       ; next page

        lda ptr+1       
        cmp #$d0        ; check if we are at $D000 
        bne l1          ; branch when page is not $D0xx
        lda #$d8        ; ok, we are at $D0xx we must move to $D8xx (skip the I/O area)
        sta ptr+1

l1      ora #$00        ; end of address space?
        bne l0          ; nope, do the loop!

        dec $d301       ; disable ROM
        lsr $d40e       ; enable NMI
        cli             ; enable IRQ
        rts             ; return to BASIC

do kompletu program w Atari BASIC wykorzystujący powyższą procedurę, ten przykład w BASIC, aby był czytelniejszy powyższą procedurę trzyma w liniach DATA, i po załadowaniu jej na 6 stronę, wywołuje ją funkcję X=USR(1536). Ale nic nie stoi na przeszkodzi aby powyższą procedurę umieścić w ciągu znakowym i wywołać ją bezpośrednio za pomocą X=USR(ADR(".....")), ale nie ma co ględzić oto prymitywny przykład w Atari BASIC:

10 GRAPHICS 0
11 ? "WAIT...":GOSUB 100
12 ? "MOVING...":X=USR(1536)
13 ? "ROM MOVED TO RAM."
14 ? :? "PRESS ANY KEY TO RUN EXAMPLE OF USE"
15 OPEN #1,4,0,"K:":GET #1,K:CLOSE #1
16 POKE 752,1:? CHR$(125):POKE 764,255
17 FOR I=0 TO 7:POKE 57344+I,PEEK(53770):NEXT I:IF PEEK(764)=255 THEN 17
18 FOR I=0 TO 7:POKE 57344+I,0:NEXT I
19 POKE 752,0:? CHR$(125);"DONE.":POKE 764,255
99 END 
100 REM - ROM-RAM MACHINE CODE DATA -
101 DATA 104,160,0,132,203,169,192,133,204,169,1,13,1,211,141,1
102 DATA 211,120,238,14,212,177,203,206,1,211,145,203,238,1,211,200
103 DATA 208,243,230,204,165,204,201,208,208,4,169,216,133,204,9,0
104 DATA 208,227,206,1,211,78,14,212,88,96
105 RESTORE 100:AD=1536:TRAP 107
106 READ B:POKE AD,B:AD=AD+1:GOTO 106
107 RETURN 

Program po uruchomieniu przepisuje ROM do RAM a potem w pętli modyfikuje wygląd znaku "space" (zapisuje je losowymi wartościami). Należy zauważyć że zawartość generatora jest modyfikowana w oryginalnym jego miejscu ($E000, 57344). Co pokazuje że operujemy już na pamięci RAM dostępnej w tym miejscu po uruchomieniu procedury w kodzie maszynowym.

biorę! daj nr konta do wpłaty! czy możliwa wysyłka paczkomatem (inpost)?

Wielki szacunek dla wszystkich panowie! Czekam z niecierpliwością aż będę mógł podziwiać waszą pracę! :)

Hi!

I extracted the archive using lha (from "lhasa" package under Debian Linux), then I used a simple Turbo Basic program to load *.GR8 file:

10 GRAPHICS 24
11 POKE 709,0:POKE 710,15:POKE 712,15
12 OPEN #1,4,0,"D:MICPRINT.GR8"
13 BGET #1,DPEEK(88),7680
14 CLOSE #1
99 GOTO 99

then You have:

The "DOC" file inside the archive is plain TEXT file but the "end of line" markers is in 8-bit Atari format, so you can convert it to PC by changing every $9B to CR/LF bytes. The file is in polish language and contains some additional info for schematic (part types, some assembly instructions).

OK, here You have some kind of translation with some additional explanations:

                      Micro Print
                      -----------
                    
The archive contains:

 MICPRINT.GR8 - schematic of micro-print interface
 MICPRINT.DOC - this file
 MICPRINT.EPR - data file contains EPROM content
 
Bill of materials needed for build microprint interface:

1 pcs) 8048 or 8049 microcontroller
1 pcs) 2764 EPROM
1 pcs) 3.58MHz Quartz Crystal or Ceramic resonator
1 pcs) 2N2222 transistor
2 pcs) 33pF ceramic capacitors
1 pcs) 1uF/10V electrolytic capacitor
1 pcs) 22uF/10V electrolytic capacitor
1 pcs) 100nF ceramic capacitor (or 33nF)
3 pcs) sockets for IC's (optional)
1 pcs) Centronics AMPHENOL connector
1 pcs) Atari SIO plug
1 pcs) Housing
1 pcs) 10 kohm resistor

Some additional info to the interface schematic:

- in the centronics AMPHENOL connector connect pins from 19 to 30 and connect
  it to the GND. The connector have numbers of each pin, so it should not be
  a problem with location of correct pins.
 
The same is about the Atari SIO plug, this is standard serial peripheral Atari plug.
 
Atari Serial Plug - view from connection side:

    2             12
      o o o o o o
     o o o o o o o
    1             13
 
 - to the pins 2 & 3 of microcontroller (MCU) connect 33pF capacitors
 
 - to the pin 4 of MCU connect a 1uF capacitor
 
 - the to the wires that deliver power to the MCU (+5V, GND) add the power
   filtering capacitors: 22uF and 100nF (or 33nF). Remember that capacitors
   are not present on the schematic.
   
 - the Quartz Crystal must be 3.58MHz (ceramic resonator is recommended)
 
 - The 2764 EPROM must be programmed with "MICPRINT.EPR" file. The EPROM
   can be also 27128 or 27256 type, but the content must be properly prepared.
   That means that the contents of the file must be replicated the appropriate
   number of times, or additional and unused address lines must remain connected
   to GND.
    
 - in the original version pin #2 of MCU is connected through 10kohm resistor
   to the +5V power rail.
   
The whole thing was created with Tadeusz's help (thank you!)

                                                    Zenon/DIAL
                                                    5.08.2000

no to procedura którą opisałem na końcu generuje taki czysty plik BIN/ROM który można odpalić z uno-cart.

No niestety MLM wbudowany w QMEG nie ma w sobie DOS-a ani procedur które by obsługiwały fizycznie jakikolwiek zapis na filesystemie, ponieważ MLM jest bardzo mały (o ile pamiętam siedzi w miejscu gdzie normalnie siedzi SELF-TEST)... to zaimplementowano w nim tylko zapis/odczyt sektorów na dyskietkę, można wybrać adres startowy oraz ilość sektorów do zapisu. Dlatego właśnie wspominane "A000>1.40" zapisze dane z pamięci od adresu $A000 w postaci 64 sektorów począwszy od sektora nr. 1

Składania zapisu wygląda tak:

address>start_sector.#_of_sectors

Składnia polecenia odczytu wygląda tak:

address<start_sector.#_of_sectors

gdzie:

address -> adres bloku pamięci na którym operujemy(hex)
start_sector -> sektor początkowy (hex)
#_of_secotrs -> liczba sektorów do zapisu/odczytu (hex)

a co do SOPHIA to wygodzi na to że nie trafia ona z odczytem sprite-ów w cykle w którym te dane się pojawiają (są wystawiana przez ANTIC w konkretnym czasie i miejscu na magistrali danych). Widać UNO-Cart jakoś wpływa na magistralę i to powoduje takie efekty. Może też być tak że UNO Cart coś psuje na magistrali na tyle że GTIA sobie radzi, a logika zawarta w SOPHIA głupieje, ale to autor rozwiązania powinien się wypowiedzieć bo ja mogę nie mieć racji, ponieważ tylko zgaduje.

@Sikor... ale to wygląda tak jakby było już ustawione 4:3 (dobra proporcja piksela, oraz spora boczna ramka)

dobra, dorzucam coś o siebie...

1 REM PRIMA APRILIS 2019
2 REM BY SIKOR, Seban/Slt,

100 REM - part by Seban
101 POKE 53768,1:POKE 53760,252:POKE 53762,255: POKE 53761,175:POKE 53763,175
102 GOSUB 1000
103 FOR I=0 TO 7: FOR J=0 TO 19:POKE 20,0
104 IF PEEK(20)<(J/4) THEN 104
105 POKE 560,PEEK(1536+J):POKE 561,PEEK(1568+J):POKE 708,PEEK(1600+J)
106 POKE 53760,200+J*2:POKE 53762,201+J*2
107 NEXT J:NEXT I:POKE 53761,0:POKE 53763,0:POKE 53768,0:POKE 106,160

200 REM - part by Sikor
201 GRAPHICS 31:C=1
202 FOR I=O TO 79 STEP 2:COLOR C:C=C+1:IF C>3 THEN C=1
203 PLOT 40+I,90+I:DRAWTO 80+I,90-I
204 PLOT 80-I,90-I:DRAWTO 40+I,90+I
205 FOR P=0 TO 20:NEXT P
206 NEXT I
207 GOTO 202

1000 REM - Routines for Seban's part -
1001 REM - RENDER ANIMATION -
1002 SX=0.5:SY=0.5
1003 FOR J=0 TO 9:POKE 106,160-8*J
1004 GRAPHICS 5+16:COLOR 1
1005 POKE 1536+J,PEEK(560):POKE 1536+32+J,PEEK(561)
1006 POKE 1536+19-J,PEEK(560):POKE 1536+32+19-J,PEEK(561)
1007 GOSUB 1100
1008 SX=SX+0.2:SY=SY+0.2
1009 POKE 1536+64+J,4+J:POKE 1536+64+19-J,4+J
1010 NEXT J
1011 RETURN
1100 REM - RENDER PHASE -
1101 RESTORE 2000
1102 READ CMD: IF CMD<0 THEN RETURN
1103 READ X,Y
1104 XE=40+X*SX
1105 YE=24-Y*SY
1106 IF CMD=0 THEN PLOT XE,YE
1107 IF CMD=1 THEN DRAWTO XE,YE
1108 GOTO 1102
2000 REM - VECTOR DATA -
2001 DATA 0,-15,-3,1,-12,3,1,-9,-3,0,-13.5,-1,1,-10.1,-1
2002 DATA 0,-6,-3,1,-6,3,0,-8,3,1,-4,3
2003 DATA 0,-3,-3,1,0,3,1,3,-3,0,-1.9,-1,1,2.1,-1
2004 DATA 0,5,-3,1,5,3,1,9,1,1,5,-1,1,9,-3
2005 DATA 0,11,-3,1,15,-3,0,11,3,1,15,3,0,13,3,1,13,-3
2006 DATA -1
2007 REM --- end of routines needed for Seban's part ;) ---

Wygląda na zwykły standardowy 8KB cart, można go pewnie zgrać z poziomu QMEG o ile nie ma ustawionego bitu "diagnostyczny". Jeżeli Select+RESET pozwala wejść do menu QMEG a potem przejść do MLM to można go zgrać tak:

1) przygotować stację dysków + dyskietkę lub sio2pc+AspetQT z umieszczoną dyskietką sformatowaną w formacie "SINGLE"
2) włożyć cart, uruchomić komputer, przejść do monitora QMEG / MLM (select + reset -> menu QMEG, potem klawisz RETURN, powinien się uruchomić MLM)
3) w konsoli MLM napisać: A000>1.40
4) zgrać dyskietkę do ATR, albo zgrać ATR-a z poziomu AspetQT.
5) wystawić ten ATR tutaj ;)

jeżeli chodzi o LED-y, to wygląda na to że sterowane poprzez zapis pod $D5xx, można przetestować pod QMEG/MLM, pisząc:

D500;FF
D500;AA
D500;FE
D500;7F
D500;00

pierwszy zapis powinien wyłączyć wszystkie diody
drugi zapis spowoduje że co druga będzie zapalona/zgaszona
trzeci zapis włączy jedną z LED-ów (pewnie którąś skrajną)
czwarty zapis włączy jedną z LED-ów (skrajną po przeciwnej stronie niż wyżej)
piąty zapis powinien włączy wszystkie LED-y.

Obawiam się że cała diagnostyka jest tylko i wyłącznie "programowa", nie ma w carcie nic więcej poza rej. sterującym LED-ami, (zatrzaskiwanym sygnałem ~CCTL) oraz EPROM mapowanym w obszar $A000-$BFFF.