Prawdę mówiąc, ja bym nawet nie wpadł na to, żeby publikować demo "ot tak". Przecież to bez sensu. Dla mnie od zawsze było oczywiste, że dema pisze się po to, żeby były wystawione w konkursie na demoparty, bo największą nagrodą jest obserwowanie reakcji publiki podczas prezentacji.
W 2021 mamy szanse na co najmniej jednego Losta i na dwa SV. Któreś z nich musi się udać, więc nie panikujmy :)

Co sugeruje, że w dziale fabryka wątki może zakładać tylko autor programu, gry lub dopałki do ST. Tak zawsze rozumiałem fabrykę, że nie jest miejscem na info, że ktoś gdzieś tam coś buduje, tylko że "hej, buduję to i to, czy to ma sens?".

Ja akurat pisałem o jednobajtowych nopach, których sekwencji nie da się przerwać. 65CE02 nie ma tych nopów. On działa zupełnie inaczej.

Bardzo fajny dokument. Nie znałem go.
Zawiłości wewnętrznej pracy procesora nie są łatwe do zrozumienia. To wymaga sporo przetrawienia. Po prostu ostatni cykl rozkazu w rozważaniach na tej stronie nie jest tym, czym myślisz, że jest. Nawet poświęcili trzy paragrafy na uzasadnienie tego. Zastosowali konwencję, że pierwszym cyklem jest cykl, w którym rejestr rozkazu ma już załadowany opcode i procesor już może go wykonywać i wykonuje go aż do ostatniego cyklu, w którym ładuje opcode następnego rozkazu. Więc przykład lda #0 w ich konwencji wygląda tak:

1. przeczytanie operandu z pamięci
2. załadowanie operandu do akumulatora ORAZ przeczytanie opcode'u następnego rozkazu.

I tutaj ostatni cykl ma w sobie ten "pipelining", jak dla wszystkich rozkazów, w których przedostatni cykl (w tej nomenklaturze) nie jest cyklem zapisu, bo jego fizycznie nie można połączyć z fetchem następnego opcode'u.

W ogóle fajna rzecz. Wg tego dokumentu przerwanie nie może wskoczyć po instrukcji skoku względnego nie przekraczającego strony. To warto byłoby sprawdzić, bo teoretycznie sekwencji

  clc
l bcc l

nie można przerwać. Nie wiedziałem tego.

@Jacques z Flimbo prace trwają - pełnowymiarowy projekt jest na tyle trudny, że czeka na ukończenie dość silnego narzędzia, które go "uciągnie".
@Mq Ale to byłoby dobre. Sensowny monitor to teraz moja największa bolączka.

Widać emulator emulatorem, a sprzęt sprzętem (tak jak na Lynksie). Ale jest już Dragonfly, to rozruszamy tę platformę, trzeba tylko trochę czasu i wysiłku.
Jeśli o mnie chodzi to chętnie wziąłbym na tapetę konsolkę z kartem, żeby to rozgryźć, ale do SV mam już grafik zajęty. Ale na drugie SV tego roku to kto wie? ;)

Chyba raczej nieskończenie wiele fps ;)

Mi się skojarzyło już w poście 27 :)

Dużo fajnych sprzętów teraz się tworzy do małego atari, a ja szukam właśnie czegoś na SIO z kartami SD, żeby operować na obrazach ATR. Najlepiej właśnie nie microsd, tylko dużymi, bo chcę wykorzystać do tego kartę FlashAir. Ciekawi mnie zatem, czy jak taki napęd otworzy plik ATR, to kiedy go zamyka, żeby było możliwe podmienienie z zewnątrz zawartości. Da się to jakoś łatwo wymusić?

@Cyprian: O Paaanie... CosmosEx to dla mnie jednak za duży kombajn jak na razie :)

@sqward: Tego nie widziałem. Zabawy z curlem wyglądają bardzo fajnie i 200 kB/s to nie tragedia. Podoba mi się. Dobra, jak dojdę do momentu kiedy coś naprawdę będę developował to zobaczę jak żonglowanie kartami wygląda w praktyce i wtedy podejmę decyzję. Póki co Atari ST + Ultrasatan to wystarczający wydatek jak na teraz.
Dzięki wszystkim za pomoc!

Nie przebrnąłem przez wszystkie opisy bo to wszystko strasznie skomplikowane jak na takiego świerzaka jak ja, więc jaki jest killer feature za który warto dać 200 zł w porównaniu do 5 razy tańszego Putnika? Mnie przy moim przypadku użycia (wgrywaniu plików, które chcę odpalić) by przekonało tylko coś w stylu mountowania kart SD sformatowanych w FAT32 (na Atari STE z TOSem 2.06 + Ultrasatan). Jeśli nic tego kalibru, to chyba nie wykorzystam jego super mocy, a tylko wydam kasę.