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.

Hej!

W wielkim skrócie... Atari OS-ROM znajduje się normalnie w lokacjach $C000-$CFFF oraz $D800-$FFFF, blok $D000-$D7FF zajmują rejestry sprzętowe oraz parę dodatkowych stron przeznaczonych dla różnych urządzeń. W przypadku Atari istnieje możliwość takiej zmiany konfiguracji MMU aby w obszarze $C000-$CFFF oraz $D800-$FFFF znalazła się pamięć RAM, a OS-ROM zostanie odłączony. Przełączenia dokonuje się za pomocą bitu #0 w PORTB. Jeżeli w tej pamięci RAM umieścisz kopię ROM, i wyłączysz ROM to będzie mógł operować na "kopii systemu operacyjnego" zawartej w RAM... przez co będziesz mógł modyfikować jego zawartość, w tym np. wygląd znaków.

Takie operacje przeprowadzały niektóre programy, szczególnie napisane w BASIC-u, aby zyskać trochę dodatkowej pamięci. Większość programów wymagających większej pamięci po prostu odłączało OS-ROM i korzystało z pamięci RAM, były też takie programy które kopiowały ROM do RAM, oraz wykonywały jego modyfikacje w celu uzyskania pewnych dodatkowych funkcjonalności.

978

(2 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

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

979

(58 odpowiedzi, napisanych Sprzęt - 8bit)

to może zamiast walczyć z różnymi x08, spróbować tego co już Simius dawno zrobił: buforowanie PHI2

ale wydaje mi się że w przypadku uno-cart może występować problem o którym wspomniał wyżej sam Simius:

Simius napisał/a:

No, chyba że pojawi się urządzenie, które wystawia swoje dane bez oglądania się na fazę PHI2 i jest na tyle szybkie, że skraca czas trzymania danych z poprzedniego cyklu.

980

(421 odpowiedzi, napisanych Fabryka - 8bit)

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

981

(69 odpowiedzi, napisanych Sprzęt - 8bit)

I added some English translation, I hope that helps also ;)

982

(69 odpowiedzi, napisanych Sprzęt - 8bit)

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:

http://seban.pigwa.net/aa/microprint/micro_print.png

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

983

(7 odpowiedzi, napisanych Sprzęt - 8bit)

spoko luz! :) wiadomo jak jest :) ja czasami tak zamotam się z pisanym tekstem że trudno mnie zrozumieć :) tylko dlatego miałem wątpliwości czy aby wszystko jasno opisałem :)

984

(58 odpowiedzi, napisanych Sprzęt - 8bit)

uicr0Bee napisał/a:

Nie chodzi mi ani o bootowalny .atr ani .xex, tylko obraz carta .bin, aby go uruchomić z Uno-Carta.

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

uicr0Bee napisał/a:

Rozumiem że z QMEGa to jest taki "fizyczny", blokowy zrzut na dyskietkę i nie można tego zrobić od razu do pliku na filesystemie?

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.

985

(58 odpowiedzi, napisanych Sprzęt - 8bit)

uicr0Bee napisał/a:

Przypomnijcie proszę jak z QMEGa zrobić dump carta na dyskietkę.

A to niestety zależy od typu cartridge, czy to jest 8K czy 16K, czy cart ma jakiś wewnętrzny przełączania banków czy też nie. W przypadku najprostszego 8K procedurę opisałem w wątku o "Test Cartridge by TOMS", wkleję to samo i tutaj:

  • przygotować stację dysków + dyskietkę lub sio2pc+AspetQT z umieszczoną dyskietką sformatowaną w formacie "SINGLE"

  • włożyć cart, uruchomić komputer, przejść do monitora QMEG / MLM (select + reset -> menu QMEG, potem klawisz RETURN, powinien się uruchomić MLM)

  • w konsoli MLM napisać: A000>1.40

  • zgrać dyskietkę do ATR, albo zgrać ATR-a z poziomu AspetQT.

  • wystawić ten ATR tutaj ;)

jeżeli chodzi o ADR, to dopiszę tutaj tylko jak dokonać "ekstrakcji" właściwego 8KB kawałka z pliku ATR. Najprostsze co można zrobić to pominąć pierwsze 16 bajtów nagłówka ATR, a potem zgrać następne 8192 bajty to pliku, pomijając całą resztę pliku ATR.

Ja osobiście używam do tego xasm-a ponieważ mam go zawsze pod ręką :)

cały plik dla XASM-a wygląda tak (dump.xsm)

    opt    h-

    org    $a000
    ins    "dump.atr",$10,$2000

mając w jednym katalogu XASM-a, ten plik oraz dump.atr możemy wywołać xasm w ten sposób:

xasm dump.xsm -o cart.bin

W przypadku chęci zrzucenia carta 16KB w MLM piszemy 8000>1.80 (zamiast A000>1.40), a plik dump.xsm zmieniamy aby wyglądał tak:

    opt    h-

    org    $8000
    ins    "dump.atr",$10,$4000

Robienie dump-ów cartów z przełączanymi bankami to już trochę bardziej skomplikowany proces (bo trzeba zgrywać poszczególne banki oddzielnie w inne obszary dyskietki, a potem napisać nieco bardziej skomplikowany skrypt to ekstrakcji zawartości tego z pliku "ATR", ale to już chyba temat na trochę dłuższy wywód :)

Zrobienie wersji XEX czy przygotowanie tego aby taki ATR był boot-owalny wymaga jeszcze trochę dodatkowego kodu i jeżeli kogoś to będzie interesować to opiszę dokładniej przy jakiejś okazji.

986

(58 odpowiedzi, napisanych Sprzęt - 8bit)

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

987

(7 odpowiedzi, napisanych Sprzęt - 8bit)

Jeżeli masz QMEG-OS w jakim Atari to procedurę DUMP-a opisałem wyżej, gdyby Ci się udało to zrobić i wystawiłbyś tutaj wynikowego ATR-a, to ja przygotowałbym plik ROM/BIN oraz pewnie wersję XEX.

Jeżeli moja "instrukcja" jest nazbyt uproszczona lub niezrozumiała mogę to opisać dokładniej załączając jakieś screen-shoty, etc.

988

(13 odpowiedzi, napisanych Różne)

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 ;) ---

989

(13 odpowiedzi, napisanych Różne)

chyba potrzeba, bo jak się namaluje kolorem 125 to się robi CLS [tzn. ?#6;CHR$(125)] (ale, być może źle pamiętam)

EDIT: sprawdziłem. jednak dobrze mi się wydawało, np:

COLOR 125:PLOT 0,0

spowoduje wyczyszczenie ekranu.

990

(7 odpowiedzi, napisanych Sprzęt - 8bit)

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.

991

(22 odpowiedzi, napisanych Sprzęt - 8bit)

to chyba nie tak że nikt nie chce się podzielić... był niedawno wątek w którym wylądowało kilka rozmiarów...

http://www.atari.org.pl/forum/viewtopic … 54#p247854

chętnie podzieliłbym się wiedzą i ja... tyle że jak potrzebowałem pasków do magnetofonów, to po prostu wziąłem oryginalne ze sobą, polazłem na wolumen do jednej z tzw. "bud", i poprosiłem człowieka za ladą o dobranie odpowiedników, tłumacząc że te paski "na wzór" które mu pokazuje, są wiekowe rozciągnięte już... gość jeszcze zapytał do czego mi to potrzebne aby się upewnić że do magnetofonów, po czym pogrzebał w czeluściach swoich szuflad i dał mi paski twierdząc że te na pewno będą dobre... no i były idealne ... tyle że rozmiarów nie znam, a to dlatego iż wtedy wykazałem się totalną ignorancją i nie zapytałem o rozmiary pasków które kupiłem, a że to było parę ładnych lat temu, to niestety obawiam się że ów pawilon już nie istnieje ;/

992

(4 odpowiedzi, napisanych Software, Gry - 8bit)

Dość ciekawe podejście do tematu :) Przyznaję że nie pomyślałbym nigdy o użyciu portu równoległego i "programowej" obsłudze transmisji szeregowej przy użyciu tego portu. Nie neguję rozwiązania... skoro działa i sprawdza się to czemu nie :)

Rozumiem że wybór LPT był spowodowany tym że nie trzeba było żadnej dodatkowej elektroniki w postaci translatora poziomów, a wystarczało tylko i wyłącznie podłączenie tego kilkoma przewodami?

Patrząc na kod... to więcej tam "in-line" asemblera niż kodu w C, ale to jak najbardziej rozumiem, większość kodu krytycznego czasowo inaczej napisać się nie dało :)

Fajnie że udostępniłeś ten kod, miło popatrzeć na źródła z przed lat, lata '90 w czystej postaci, aż się łezka w oku kręci :)

993

(3 odpowiedzi, napisanych Sprzęt - 8bit)

Hej!

No łady okaz :) Pierwszy raz widzę na oczy "Crystal Sound II". Aby odpowiedzieć jakim softem to obsłużyć trzeba by wiedzieć pod jakim adresem lądują próbki oraz czy proces konwersji jest automatyczny, czy wymaga bardziej zaawansowanych kroków niż tylko odczyt z rejestru.

Zakładając maksymalną prostotę projektu można przyjąć że próbka ląduje w przestrzeni $D5xx i że konwersja odbywa się automatycznie (nie potrzeba dodatkowych operacji ze strony komputera). Tak działał np. "A/D converter" czy jakieś tam inne samplery które miałem w rękach.

Aby to sprawdzić możesz na szybko uruchomić prymitywny program testowy: d5smptst.xex.zip

Program odczytuje z prędkością ~15KHz lokację $D500 (tam powinna znajdować się aktualna próbka), następnie umieszcza ją w rej. głośności kanału #0 POKEY-a, dodatkowo zrobiono prosty wykres wizualizujący to co przychodzi z $D500.

Klawisz OPTION wybiera odtwarzanie dolnych 4-bitów rejestru $D500 (czarne tło, ustawienie domyślne),  klawisz SELECT przełącza od odtwarzanie górnych 4 bitów (tło robi się niebieskie). Wciśniecie OPTION+SELECT+START powoduje wyjście z programu (warm start).

ps1) jeżeli proces konwersji nie jest zautomatyzowany, lub jeżeli rejestr przechowujący próbki znajduje się w innej lokacji niż $D500, program testowy nie zadziała. Natomiast jeżeli zadziała, możesz użyć dowolnego oprogramowania dodanego np. do wcześniej wspominanego A/D Convertera. Może to być np. Digital Studio lub Micro Recorder

ps2) Crystal Sound w wersji pierwszej podpinało się po portów JOY-a, jak zbudowana była wersja CART nie wiem, mogę się jedynie domyślać patrząc na zdjęcie ;)

ps3) wywiad z jednym autorów Crystal Sound-a: Marcin Długosz

Faktycznie V2 z AOL to jest wersja 3.16 która była dołączona jako pierwszy obrazek na liście. Dzięki za informacje!

995

(3 odpowiedzi, napisanych Sprzęt - 8bit)

na 100% możesz wyjąć kość z BASIC, mam 130XE z co prawda wczesną wersją Ultimate, ale ponieważ wcześniej miałem "opodstawkowaną" tą 130XE, to mogłem wyjąć BASIC bez problemu, co też uczyniłem, wszystko działa. Swego czasu Candle wspomniał, że i tak mapuje kawałek z FLASH-a obecnego na Ultimate zamiast wbudowanego BASIC-a.

na tym carcie jest na naklejce "Atari Super System", i chyba inicjały "DS". Ciekawe czy to ten cart też pochodzi z Poznania. Swoją drogą fajny kawał historii dzięki waszym wspomnieniom udaje się tu odtworzyć! :)

Co do "zepsutych" rozszerzeń pamięci .... patrząc na niektóre konstrukcje z tamtych czasów to ja czasami się zastanawiam jakim cudem to w ogóle działało. Niektóre konstrukcje są naprawdę wykonane z przysłowiowego *.ówna i patyczków.

997

(42 odpowiedzi, napisanych Programowanie - 8 bit)

Jakby ktoś chciał się bawić w dalszą walkę z Action!, to proszę:

BYTE RTC=$14
BYTE VCOUNT=$D40B
BYTE DMA=$22F

PROC VBL()
BYTE V 
V=RTC
WHILE(V=RTC) DO OD
RETURN

PROC MAIN()
CARD SCR,VCN
BYTE FRM

GRAPHICS(24) DMA=0 VBL() RTC=0
SCR=PEEKC($58)
SETBLOCK(SCR,$1E00,$FF)
ZERO(SCR,$1E00)
VCN=VCOUNT FRM=RTC
GRAPHICS(0)
PRINTF("%E %U FRAMES %U LINES",FRM,VCN*2)

5 ramek, 38 linii rastra. aby było szybciej to już chyba tylko wstawki ASM :) bo te procedury biblioteczne SETBLOCK czy ZERO nie są jakieś super optymalne ;)

@FUJI... dzięki WIELKIE za sprawdzenie tego! zatem wygląda to jednak na kolejny klon DDR-owskiego Turbo6000.

999

(42 odpowiedzi, napisanych Programowanie - 8 bit)

tzn. tak... nie wiem jak wygląda kod TDC-a, nawet nie wiem gdzie go szukać... więc napisałem swój... (używałem action v3.6
)

BYTE RTC=$14
BYTE VCOUNT=$D40B
BYTE SDMCTL=$22F
PROC MAIN()
CARD SCR,VCN
BYTE FRM
GRAPHICS(24) RTC=0
SCR=PEEKC(88)
SETBLOCK(SCR,$1E00,$FF)
ZERO(SCR,$1E00)
VCN=VCOUNT FRM=RTC
GRAPHICS(0)
PRINTF("%E %U FRAMES",FRM)
PRINTF("%E %U LINES",VCN*2)

i wyszło mi:

http://seban.pigwa.net/drop/act_fill01.png

jak się wyłączy ekran, wychodzi:

http://seban.pigwa.net/drop/act_fill02.png

gdy zrobię tak jak piszesz, tzn. zeruję RTCLOCK przez wywołaniem GR.24, czyli:

http://seban.pigwa.net/drop/act_fill03.png

to wychodzi:

http://seban.pigwa.net/drop/act_fill04.png

ale gdy zastosuje się sztuczkę PIN-a z GR.56 (nie czyścimy pamięci ekranu) to wynik spada do:

http://seban.pigwa.net/drop/act_fill05.png

UPDATE: Porównywanie TBXL i Action! jest trochę bez sensu, ponieważ TBXL działa na liczbach FP (zmienno-przecinkowych) a Action! tylko i wyłącznie na całkowitych. W dodatku Action! to kompilator, a TBXL jest właściwie interpreterem, piszę właściwie bo po wpisaniu linii następuje tokenizacja, przekształcenie wyrażeń arytmetycznych, ot taka wstępna kompilacja i optymalizacja w locie. Gdyby nie wbudowane w TBXL funkcje MOVE moglibyśmy jedynie sobie zerować/wypełniać te 8KB pamięci przez ładny kawałek czasu używając np. FOR...NEXT i POKE. Trwałoby to naprawdę jakiś koszmarny kawał czasu.

1,000

(42 odpowiedzi, napisanych Programowanie - 8 bit)

z włączonym ekranem 8 ramek, 134 linie. TBXL zabija to że wszystko właściwie dzieje się na liczbach FP. Ja i tak się dziwię ze z tyloma wywołaniami procedur z pakietu FP wychodzi wolniej tylko o dwie ramki jedną ramkę. (przy włączonym ekranie).