Dzięki WIELKIE że chce Ci się tym walczyć! :) świetny pomysł ze złożeniem zdjęcia i projektu! :)

Hi!

I of course I have read Your first post... and I probably understand why You do not include those materials from mega-hz in Your post. I also, have some doubts about license, and maybe some copyrights, because this is mega-hz materials, and I don't asked him for permission, but those files is placed in public place (on his website) so I assumed this not violates his rights (I've included an information from where those files are taken, and the credits are also given), so I finally decided to post those materials from mega-hz web site here, for those reasons:

• we talking about those topic here, so I think it's worth to include all materials here, so the other community members will not have to search for those on the internet.

• for archiving of those materials (as a backup of materials from mega-hz website)

• to keep all the information about this memory expansion in this topic, so the other members of forum can comment, or maybe add some more information. I think it is good idea to share all the knowledge and materials from the past, this is our hobby, this is also pure fun! And this is important for historical reasons and educational purposes.

... and of course I think even with those simple photos and included "Handbuch" it is possible to reverse-engineer and fully reconstruct the schematics... we have two sides of original PCB (those with (c) 1986 CompyShop), so we don't need to have "uncensored" version of mega-hz PCB. Ask Toriman, he probably confirm my words ;)

But I can't help at this moment :( Currently I have other duties to do... if nobody from our community can't help in near future... I will do it, but this can took some time.

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.