A mi się wydaje że wręcz przeciwnie, wszyscy mają okazję poznać preferencje i warsztat pracy innych koderów/programistów. Co jest wielce interesującym tematem, ponieważ zawsze można się dowiedzieć czegoś ciekawego, np. poznać takie narzędzie jak ZTreeWin. Dyskusja czy to o edytorach czy o menadżerach plików jest również interesująca, ponieważ każdy może poznać inne edytory, o których istnieniu nie słyszał, a także sprawdzić jaki edytor jest wbudowany w dany menadżer plików.

Ja naprawdę polubiłem SciTe i gdy piszę coś używając XASM, to nie wyobrażam sobie lepszego edytora do tego:

A jak muszę napisać prymitywne parę linijek to wbudowany w FAR Manager, edytor również się bardzo dobrze do tego nadaje:

wieczór++ ;-)

@skrzyp: Każdy używa to czego mu wygodnie używać, i równie dobrym powodem jest "bo tak", jak i "bo przyzwyczaiłem się do tego", czy też "otrzymuję funkcjonalność jakiej oczekiwałem". Nie widzę powodów dla których musiały polecieć określenia "psu na budę", "windowsowe edytory z bazaru", etc. Na szczęści panuje wolność wyboru narzędzi i systemów operacyjnych, ale nie oczekuj że TeBe będzie robił coś bo ty tak chcesz. Jeżeli potrzebujesz, to tak jak napisałem wyżej... nie żądaj i nie wymagaj (niby z jakiego powodu? zapłaciłeś za ten soft i żądasz wsparcia od autora?), następnym razem zastanów się czy nie możesz sam dodać funkcjonalności jakiej potrzebujesz, a następnie udostępnić na zasadach Open-Source, skoro jesteś zwolennikiem tej idei. W tym wypadku ktoś zrobił już to za Ciebie i wydaje mi się że możesz być z tego powodu jedynie zadowolony.

myślę że jedynym wyjściem przy takim podejściu jest sięgnięcie na stronę naszych braci szwedów i skorzystanie z rady tam zawartej...

http://napisz.se/

;-)

Cześć,

Ze swojego własnego podwórka niejako, na gołe 65XE to mogę polecić...

Overmind oraz Bitter Reality

Na pewno są lepsze dema, jednak te na 100% zadziałają na niemodyfikowanym Atari z 64KB RAM.

ps) należy brać po uwagę to że jest to raczej old-school, tzn. lata 1994-1995 ;-)

cool! :) dzięki! :)

dzięki Azbest! Mam nadzieję że obyło się bez strat w sprzęcie.

Fajnie że Bluki wydobywa takie historie z czeluści internetu. Dzięki wielkie za to że chce Ci się o tym napisać i jeszcze podać jak na tacy wszystkie pliki łącznie z wersją PL :)

Cześć,

Niestety nie ;/ Turbo działa mniej więcej przez 0,5sek (prędkość ~350%) po czym prędkość spada do 100%, tak jakby "turbo mode" zostało wyłączone, ponowne wciskanie F12 lub włączenie turbo mode w opcjach emulatora nic nie zmienia.

EDIT:

Przełączyłem na tryb 1080p @ 60Hz ... no i niestety przy PAL scroll-e szarpią widocznie, wszystkie efekty które normalnie wykonują się "in one frame" (żargonowo "wchodzą w ramkę") wyglądają paskudnie. Ale za "turbo mode" działa... od ~450% do ponad 800% w zależności od tego co się dzieje na ekranie.

Co ciekawe w trybie 1080p @ 60Hz, po przełączeniu emu na NTSC, Turbo Mode również działa...

no człowiek uczy się całe życie... dzięki za oświecenie... 'make -j4' działa i zasówa jak trzeba :)

real    0m47.898s
user    2m23.970s
sys    0m4.950s

normalna kompilacja (one-core):

real    2m21.126s
user    1m54.630s
sys    0m3.830s

@Montezuma: a jak taki display podłączasz? Masz jakąś przejściówkę HDMI->VGA? W życiu nie podłączałęm pod RPI nic innego niż monitor FullHD przez HDMI lub po prostu TV do wyjścia TV w RPI1.

@Sim_Piko: A dlaczego się nie poleczasz? Pomogłeś i to bardzo :) dzięki za cierpliwość i wyrozumiałość :)

ps) do tej pory nie miałem pojęcia o opcji -j bo korzystałem z gotowców, tzn. serwer i środowisko do kompilacji (cross-compiler) przygotowane miałem przez ludzi którzy się na tym znają i nie wnikałem, jak widać to był poważny błąd. Dostawałem gotowego skonfigurowanego LTIB-a czy Yocto do pracy i nie musiałem martwić się o konfigurację tego wszystkiego. Dzięki wam nadrabiam zaległości :)

Hej!

Dzięki wielkie za pomoc... małymi krokami do przodu, czyli:

1) pobrałem archiwum (tarball)
2) odpaliłem autoconf (nie było pliku 'configure')
3) autoconf wygenerował sobie cośtam, po czym odpaliłem configure --target --host...
4) miłąchał, miąchał .... i mu nie wyszło...

...
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for library containing tgetent... no
configure: creating ./config.status
config.status: creating Makefile
config.status: error: cannot find input file: `config.h.in'

pewnie coś nie tak robię z autoconf-em?

EDIT: pomogło 'autoreconf -i', teraz zapuszczam make... zobaczymy :)

@Sim_Piko: zadam głupie pytanie... skąd brałeś źródła Atari800-3.1.0? Bo spróbowałem skompilować źródła z tego co podesłałeś i wychodzi na to że ./configure --target=rpi --host=arm-linux poszło bez najmniejszego problemu. Właśnie poleciał make, również bez problemu.

Ja źródła pobrałem z tej lokalizacji:

http://sourceforge.net/projects/atari80 … 800/3.1.0/

Właśnie sprawdziłem MD5 i wszystko się zgadza:

pi@raspberrypi ~/Downloads $ md5sum atari800-3.1.0.tar.gz 
354f8756a7f33cf5b7a56377d1759e41  atari800-3.1.0.tar.gz

Tyle że 'src' od Ciebie się kompiluje bez problemu, a pliki z sf.net tak jak to widać powyżej ;/