1,926

(16 odpowiedzi, napisanych Różne)

Bardzo proszę o załączanie również listingu w załączniku (najlepiej .LST). Czasu niewiele więc pomoże to bardzo.

1,927

(34 odpowiedzi, napisanych Zloty)

Zamiast zawiadamiać można zsynchronizować termin party z dniem kiedy eko-file wyłączają światło. Elektrownia nie będzie się martwić co zrobić z nadwyżką prądu, my będziemy mieć aż nadto i równowaga w przyrodzie zostanie zachowana.

Można też nieco inaczej:
Najpierw F1:
1. W Emulator Configuration wyłączyć SIO patch (czasem zakłóca ładowanie z magnetofonu).
2. W Emulator Configuration wyłączyć BASIC.
3. W Emulator Configuration włączyć trzymanie START podczas BOOT.
4. W Tape Management podłączyć plik .CAS i ustawić Position na 1 (to licznik rekordów).
Potem F5 i się powinno ładować.

1,929

(77 odpowiedzi, napisanych Bałagan)

Piękna muzyka! Dzięki gepard.

1,930

(116 odpowiedzi, napisanych Bałagan)

@Sikor: SDX tak, jak i xBIOS ma swój specjalny interfejs, który daje sporo większe możliwości niż tradycyjny ATARI DOS. Jak chcesz zrezygnować z dobrodziejstw typu: kod relokowalny, TSRy, zarządzanie XRAM, symbole, itp. to możesz pisać samodzielnie wszystko. Analogii zresztą daleko nie trzeba szukać - renegaci odrzucający jakiegokolwiek DOSa (CIO) organizują sobie dysk po swojemu i korzystają z SIO pisząc programy BOOTowalne. Kardridżowcy też. Nie rozumiem co jest niewłaściwego w tym, że powstają programy korzystające z nowych fajnych funkcji, które daje oprogramowanie :/ To oczywiste, że program napisany specjalnie dla xBIOS, jak i napisany specjalnie dla SDX nie będzie działał na ATARI DOS. Zapewnienie kompatybilności wstecznej jest tak dużym krokiem wstecz, a wynikającym z odrzucenia wielu ułatwień, że po prostu szkoda się mordować. Masz pretensje, że program dla MS-Windows nie chodzi pod MS-DOSem :/?

1,931

(116 odpowiedzi, napisanych Bałagan)

Oczy wiście.

1,932

(116 odpowiedzi, napisanych Bałagan)

Wychodzi na to, że Sparta jest elitarnym systemem. Ha!

1,933

(84 odpowiedzi, napisanych Różne)

I to działająca :)

1,934

(84 odpowiedzi, napisanych Różne)

Pin napisał/a:
mazi napisał/a:

Ciekawe jak dostajesz sie do plikow (by je odegrac) w powiedzmy w czwartej setce. Bo nie wierze, ze znasz nazwy oraz formaty wszystkich plikow na pamiec.

2. Mam 400 plików posortowanych w katalogu alfabetycznie, jestem pod command processor i teraz szukamy jakiegoś pliku zaczynającego się na literę "z":

dir z*.*

Dn:>z_nazwa.ext

Muza gra.

Mazi ;) - znasz szybszą metodę?

DOSKEY.SYS

Z[TAB][RETURN]

1,935

(84 odpowiedzi, napisanych Różne)

A gdzież tam :D

1,936

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

Sugerujesz, że jest to byt pozbawiony świadomości swego istnienia?

1,937

(84 odpowiedzi, napisanych Różne)

Dla wygody i przyjemności?

1,938

(84 odpowiedzi, napisanych Różne)

Nie zna życia, kto nie pisał w Sparta DOS X.

1,939

(11 odpowiedzi, napisanych Bałagan)

I jak tu wyjść  psem na spacer...?

1,940

(46 odpowiedzi, napisanych Programowanie - 8 bit)

Piękny kawałek kodu ("Dowód jest elegancki kiedy da się go zapisać na marginesie" haha). Szacun!

Edit: Zastanawiam się czy NEWIOP nie spowoduje, że w pewnych warunkach procedura nie będzie reentrant, ale jeśli przepiszemy IRQMAIN to można go nie używać, albo zapewnić żeby była tam zawsze zawartość .A sprzed wywołania.
Podoba mi się JSR+NOP zamiast odkładania dokładnego powrotu na stos - zgrabne.

1,941

(46 odpowiedzi, napisanych Programowanie - 8 bit)

Tak, ale niestety patch spowoduje też spory wzrost opóźnień (dla DLI ok 20 cykli, dla VBLK ok 35, dla IRQ ok 25). W przypadku DLI chyba lepiej nie wprowadzać takich delayów? 7 cykli przy samym NMI patch w sumie może byłoby i akceptowalne...
Zrobiłem małą przymiarkę dla wektoryzowania przez NMIVEC i IRQVEC:

nmi:
  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3

  asl NMIST
  scc
  jmp (VDSLST)

  pha
  txa
  pha
  tya
  pha
  cld
  jmp (VVBLKI)

irq:
  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3

  asl NMIST
  scc
  jmp (VDSLST)

  cld
  smi
  jmp (VIMIRQ)

  pha
  txa
  pha
  tya
  pha
  jmp (VVBLKI)

brkopcode:
  txa
  pha
  tsx
  lda $103,x
  and #$10
  beq ?ret
  pla
  tax
  jmp (VBREAK)

?ret:
  pla
  tax
  pla
  rti

oraz dla VDLST, VVBLKI i VIMIRQ:

vdslst:
  sta NMIRES      ;4
  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3
  ...             ;-------20 cykli

vvblki:
  pla             ;4
  tay             ;2
  pla             ;4
  tax             ;2
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3
  txa             ;2
  pha             ;3
  tya             ;2
  pha             ;3
  ...             ;-------35 cykli

vimirq:
  bit NMIST       ;4
  spl             ;23
  jmp (VDSLST)    ;5 -----11 cykli

  svc             ;23
  jmp (VVBLKI)    ;5 -----14 cykli

  pha             ;3
  lda #>brkopcode ;2
  pha             ;3
  lda #<brkopcode ;2
  pha             ;3
  php             ;3
  ...             ;-------26 cykli

Na razie teoretyzuję, bo nie uruchamiałem tego. W tym przypadku IRQ w obydwu przypadkach uruchomi 2x obsługę BRK kiedy nie wejdzie mu w drogę ani NMI, ani IRQ.

Edit: 2x wywołanie BRK akurat da się obejść realizując zamiast PHP po prostu LDA #%00100100+PHA.

1,942

(46 odpowiedzi, napisanych Programowanie - 8 bit)

Przy takim zdefiniowaniu priorytetów używanie BRK mija się z celem, bo opóźnienia obsługi BRK w pesymistycznym przypadku będą rzędu 250 cykli (przejdzie cała detekcja IRQ zanim zostanie wywołana obsługa BRK). Lepiej użyć JSR/JMP i tablicy skoków. Pewnie dlatego OSowcy zrezygnowali z patchowania i zostawili PLA/RTI (co chyba najsensowniej w takim stanie rzeczy zrobić).
Pytanie dlaczego w ogóle zostawili wektor (i to dopiero w serii XL/XE) skoro wiedzieli, że to nie działa? Może planowali użyć CPU, który wszystko realizuje poprawnie? ;]
Wychodzi na to, że faktycznie sens używania BRK to tylko laboratoryjny debug.

1,943

(46 odpowiedzi, napisanych Programowanie - 8 bit)

@Fox @xxl: Dzięki.

1,944

(46 odpowiedzi, napisanych Programowanie - 8 bit)

W atariki stoi: "Wystąpienie przerwania podczas wykonywania rozkazu BRK spowoduje, że zostanie on zignorowany". Tylko co to znaczy? Czy to, że błąd leży w procedurze obsługi IRQ, czy że jest to własność processora?

1,945

(46 odpowiedzi, napisanych Programowanie - 8 bit)

NMI jest wymuszane zboczem, więc nie ma szans wejść w to samo NMI po raz drugi. Jeśli chcielibyśmy obsługiwać BRK też i na NMI, to trzeba by odłożyć na stos powrót do obsługi BRK i kontynuować NMI.
Można jeszcze skorzystać z patentów xxla na programowe wywołanie IRQ i spokojnie wyjść z NMI.

Edit: "ASL..." załatwia sprawę, ale nie CAŁKOWICIE, bo jak sam się zgodziłeś potrzebne jest jeszzcze STA NMIRES na DLI :/ albo zmiana ROMu z główną procedurą obsługi NMI (tak, żeby użytkownik nie musiał już robić nic z NMIRES w swoim kodzie).

Edit 2: "Wejść w to samo NMI po raz drugi" - chodzi o podtrzymanie wymuszenia na linii NMI. IRQ jest wymuszane poziomem, więc przerwanie może być odroczone - wystarczy tylko nie obsługiwać go w IRQST (lub innych). W NMI to nie wystarczy, bo po powrocie przez RTI wymuszenia już nie ma.

1,946

(46 odpowiedzi, napisanych Programowanie - 8 bit)

A co jest w F.I na stosie? Bo może warto by zrobić tak:
- jeśli I=1 to IRQ na pewno nie przerwie IRQ, więc jedynymi opcjami są NMI i BRK.
- jeśli B=0 to było BRK więc można od razu wykonać nie uruchamiając detekcji źródeł IRQ.
Widzę jeszcze jeden problem.
Załóżmy, że wykonujemy BRK i CPU wszedł w obsługę przerwania, sprawdza kolejne źródła i w tym momencie przychodzi jakieś IRQ. Zapala się flaga w IRQEN/PxCTL/PDVREG czy gdzie tam i nagle CPU zamiast zrealizować BRK zboczy nam w któreś IRQ. Obsłuży przyjęcie i nie zwracając na stan B na stosie wyjdzie z przerwania. W tym momencie jest po ptakach, bo drugi raz w przerwanie nie wejdziemy (analogicznie jest z NMI, ale to tylko dygresja) :/ Może w OS po prostu źle zrobiono detekcję i BRK powinno mieć najwyższy priorytet?

1,947

(46 odpowiedzi, napisanych Programowanie - 8 bit)

Ustawiony.

1,948

(46 odpowiedzi, napisanych Programowanie - 8 bit)

ASL ładne, ale to i tak nie załatwia całkowicie sprawy - trzeba by poprawić w ROMie procedurę NMI, bo tam nie mamy już takiego fajnego wektora VIMNMI (z NMIVEC możemy wszystko). Inaczej problem będzie z pierwszym IRQ wykonywanym po NMI.
CLD w NMI robione jest tylko dla VBLK.

1,949

(46 odpowiedzi, napisanych Programowanie - 8 bit)

CLD sobie trzeba dodać przed obsługą IRQ, bo SIO liczy np. sumę kontrolną.

Z moich testów wynika, że nie ma jak wykryć wykonania BRK kiedy wraz z nim wystąpiło jakiekolwiek przerwanie sprzętowe (nie może być jak IRQ odroczone). Chciałbym się bardzo pomylić w tej kwestii, bo podoba mi się wołanie funkcji systemowych za pomocą BRK #fn.

Jump if MInus: bmi albo jeśli za daleko to spl + jmp; analogicznie Jump if V Clear.

Edit: No i BRK wykona się przy zapalonym I.

1,950

(46 odpowiedzi, napisanych Programowanie - 8 bit)

A nie wynika to z tego, że przerwanie jest przyjmowane po zakończeniu bieżącego cyklu rozkazowego więc mając np LDA NMIST i NMI, które wystąpi po prefetchu a przed 4 cyklem rozkazu w A dostaniemy info o NMI?

Ha! (za https://atariwiki.org/wiki/Wiki.jsp?pag ... %20Listing ):

;
; NMI HANDLER
;
; DETERMINE CAUSE AND JUMP THRU VECTOR
;
PNMI:    BIT      NMIST
          BPL      PNMI1         ;SEE IF DISPLAY LIST
          JMP      (VDSLST)
PNMI1:  PHA
          LDA      NMIST
          AND      #$20          ;SEE IF RESET
          BEQ      *+5
          JMP      WARMSV        ;DO THRU WARM START JUMP
          TXA                      ;SAVE REGISTERS
          PHA
          TYA
          PHA
          STA      NMIRES        ;RESET INTERRUPT STATUS
          JMP      (VVBLKI)     ;JUMP THRU VECTOR

W XL/XE oczywiście dodano CLD  i usunięto test NMIST.5.

jmi/jvc - nie wiedziałem, że tak można :) Ale wygląda ładnie.