Czy jest co lepszego od Turbo Assembler +60k

[prezes__]

Nie jestem za bardzo na biezaco i mam pytanie do koderow i elektonikow.

Czy powstalo cos bardziej wygodnego do kodowania od zestawu Turbo Assembler +60k?

Interesuja mnie trzy opcje:
1. pisanie zrodel i odpalanie na real c64
2. pisanie i uruchamianie na emulatorze
3. hybryda, tzn. pisanie i kompilacja na PC z odpalaniem (szybkie skopiowanie zawartosci pamieci) na real c64 - nie wiem czy to wogole jest wykonalne - moze to tylko moja fantazja

Interesuja mnie tylo rozwiazania rozsadne tzn. sprawdzone i majace krotki czas kompilacji i uruchomnienia (np. przenoszenie kodu na dyskietkach = zle).
Z czego korzystacie i na co warto zwrocic uwage.

[Nitro__]

1.Nie znam sie, nie wypowiadam sie.
2.J/W
3.Bez obrazy dla fanow pisania na C64, ale oczywista sprawa, ze istnieje cos wygodniejszego. Wszystko sprawdzone praktycznie na sobie.
Mamy do dyspozycji KickAssembler\'a - to bardzo wygodny assembler, z wbudowanym wlasnym jezykiem skryptowym, dzieki ktoremu to mozemy sobie np. generowac dowolne tabelki w ulamkach sekund, importowac pliki w okreslony sposob i wiele innych rzeczy.
np:
                   

Cytat:

.var da=PI/60 .var c=0 .var s=0 sin: .for(var i=0 : i < 121 : i++) { .eval c=c+da .eval s=floor([32*sin(c)]+0.5) .if (s<0) .eval s=256+s .byte s }

Jest napisany w Javie - multiplatformowosc. Do tego dobieramy sobie dowolny edytor, ktory oczywista sprawa ma przewage nad kazdym edytorem z C64 - wysoka rozdzielczosc, kolorowania skladni, na boku konwerter liczb i mnostwo innych bajerow.
Dane w rodzaju grafika, muzyka mozemy przeniesc z komody bezproblemowo, ale sa takze na PC narzedzia do wiekszosci zdan.
Wygenerowany kod testujemy wstepnie pod VICE\'m, bez obaw - emulator jest dosyc dokladny i na 99% kod bedzie chodzil tak, jak na realnym C64, mamy do dyspozycji dobry monitor.
Po skonczeniu kodu odpalamy go pod HOXS\'em - na tym emulatorze mamy 99,9% pewnosc, ze bedzie dzialac tak jak na realnym C64.
Naprawde nie warto bawic sie z przenoszeniem co chwila kodu na C64, aby go na nim odpalic, emulatory naprawde sie rozwinely.

[Kisiel]

macroassembler na c64+ przerobka dokonana przez victora, kod wynikowy umieszczany jest w dodatkowej pamieci, zrodla sa w innym banku, macro assembler w innym, no i w zwyklej pamieci mozna uruchomic program/demo, zresetowac, wylaczyc zasilanie. Dograc z karty/napedu 80 bajtow programiku i wszystko wraca tak jak bylo przed kompilacja. NIe wiem co mozna lepiej zrobic.

[Skull]

tez mi bylo bardzo ciezko przejsc z na crossplatworme,i sie przed tym bronilem jak moglem. Jeszcze dlugi czas kobinowalem na Turbo Assembler +60k w emu Vice (zgrywajac stan emulatora  - alt+s, alt+l).

Ale w koncu zmuszony zostalem... glupia sprawa ale nawet Tasm +60k ma ograniczenie w postaci max 4096 linii kodu - jak dla mnie to bardzo malo nawet jak na pojedyncza czesc programu ..i sie przesiadlem.
Ale tez dlatego, ze compilator 64tass (Taboo-sow) opiera sie wlasnie na identycznej skladni co Tasm (+ pare bajerkow)- wiec zrodlowki mozna przenosic na zywca (jest taki programik do tego nawet TMPview).
A jako edytora uzywam Relaunch64 http://www.popelganda.de/?relaunch64
Oczywiscie trzeba poustawiac w nim wszystkie sciezki itd.
Program wynikowy pakuje jeszcze exomizerem (i raczej nic innego i szybszego nie ma). Wszystko sie dzieje przez odpowiednio zrobiony plik BAT, wiec cale swoje dzielo uruchamiam przez F6 w edytorze. Czekam zaleznosci od wydajnosci PC ok 0.5-5 sek i od razu widze efekty w emulatorze - przy okazji takiej kompilacji zawsze tez mi sie tworzy plik gotowy do przerzucenia na prawdziwe c64.

Chyba latwiej juz sie nie da.

[Nitro__]

Zapomnialem dodac, ze na PC bez problemow mozna zlozyc trackmo, odpowiedni program, skrypt i ladnie tworzona jest dyskietka za kazdym razem, gdy assemblujemy konkretne zrodla.

[viper__]

Jak bawilem sie jeszcze relunchem to pamietam ze mial pare dosc powaznych wtop np:
- zawsze przed kompilacja trzeba bylo zapisac kod bo inaczej bral stary
- czasem mieszaly mu sie sciezki pomimo poprawnego ustawienia sciezek do kompilatorow

[Skull]

viper to chyba oczywiste, ze trzeba zapisac zmiany w pliku w ktorym sie cos modyfikuje - skad ma sie program domyslic ze zmiany ma zatwierdzic czy nie.
Przed uruchomieniem ctrl+s i uruchamiasz - przeciez tak dziala kazdy kompilator na PC.
No moglby ew. zapytac czy chcesz zapisac zmiany przed kompilacja.

Sciezki, no to tak jak wszedzie - ale jak juz sie uporasz to dzialaja jak zyleta.

Relauncher ma sporo wad, ale akurat te, to nie wina programu.

[V-12/Tropyx]

                   

Nitro napisal:

Zapomnialem dodac, ze na PC bez problemow mozna zlozyc trackmo, odpowiedni program, skrypt i ladnie tworzona jest dyskietka za kazdym razem, gdy assemblujemy konkretne zrodla.

Mowi to ten, kto skladal demo 2x

A tak na serio, ja nie wyobrazam sobie kodowania bez +60K. Szalenie wygodna sprawa. Kod sobie siedzi w rozszerzeniu a ja w miedzyczasie moge sobie cos innego odpalic, jakies demko czy senda a potem wrocic bez problemu do kodowania. A C64 jest stabilniejsze, niz PC i nie ryzykuje tego, ze mi szlag trafi zrodlowke, jak mi sie cos zawiesi hehe Poza tym sam wykonuje kopie zapasowe kodu i niemalze nigdy z nich nie korzystam.

[Izaak Berenbaum__]

                   

V-12 napisal:

A C64 jest stabilniejsze, niz PC

   zmien peceta

[Kisiel]

v-12 ja nawet nie musze zgrywac bo pamiec na baterie

[V-12/Tropyx]

                   

kisiel napisal:

v-12 ja nawet nie musze zgrywac bo pamiec na baterie

Tez dobra rzecz, niczym Ram Cart sprzedawany kiedys przez BIW .

[Raf]

                   

V-12 napisal:

Nitro napisal: Zapomnialem dodac, ze na PC bez problemow mozna zlozyc trackmo, odpowiedni program, skrypt i ladnie tworzona jest dyskietka za kazdym razem, gdy assemblujemy konkretne zrodla. Mowi to ten, kto skladal demo 2x A tak na serio, ja nie wyobrazam sobie kodowania bez +60K. Szalenie wygodna sprawa. Kod sobie siedzi w rozszerzeniu a ja w miedzyczasie moge sobie cos innego odpalic, jakies demko czy senda a potem wrocic bez problemu do kodowania. A C64 jest stabilniejsze, niz PC i nie ryzykuje tego, ze mi szlag trafi zrodlowke, jak mi sie cos zawiesi hehe Poza tym sam wykonuje kopie zapasowe kodu i niemalze nigdy z nich nie korzystam.

w obecnych czasach kodowanie na c64 ma sens tylko wtedy gdy musisz cos z dokladnoscia do cyklu tworzyc (synchronizacja VIC-CPU etc), matematyczne rzeczy robi sie o wiele wygodniej na PC (chocby symulacja krokowa na 6502sim) tym bardziej ze przy takich sprawach czysto matematycznych nie mozna winy zwalic na emulator zle emulujacy triki w VIC etc.

Nie oszukujmy sie - wiekszosc ostatnio wydanych dobrych dem to efekt crossasmu.

wiem ze ilosc moich wydanych produkcji moze podwazac to co pisze (Zaatakowales o to Nitro bynajmniej :p ), ale jak cos sobie dlube to zaczynam od prototypowania na PC w C przy uzyciu jakiejs biblioteki graficznej (np Allegro albo SDL) i dopiero jak osiagne jakis zadowalajacy efekt to staram sie to stabelaryzowac/zoptymalizowac i recznie potem przepisac w ASM (algorytm Bresenhama tak implementowalem - z sukcesem).

[V-12/Tropyx]

Nie chce wchodzic w polemike, na czym sie lepiej koduje, bo to czesto jest efekt pewnego rodzaju przyzwyczajenia, a nie tylko okreslonych mozliwosci sprzetu i/lub oprogramowania. Dla mnie tworzenie na C64 niesie za soba pewnego rodzaju klimat i mile przezycie i o to przede wszystkim chodzi .

[Nitro__]

                   

Cytat:

Mowi to ten, kto skladal demo 2x Very Happy

Kiedy po raz pierwszy konczylem demo na party jedna czesc byla niegotowa i calosc nie byla polinkowana. Bylem cholernie zaspany i zmeczony(przed piatkiem kodowalem do 4\'tej w nocy, o 6\'stej pobudka na pociag) wiec po pierwsze napisalem o wiele za dlugie scrolle w porownaniu do efektownosci efektow Po drugie nie przetestowalem dema pod Hoxs\'em ani pod realnym C64, ktorych na party bylo pod dostatkiem, takze efekt zniechecenia, po prostu juz mialem tego dema dosc.
Na riverwash sytuacja powtarza sie, dzien przed party zachcialo mi sie demo skrocic, fixnac timing oraz dodac nieskonczona galerie, znowu kodowanie do poznej nocy. Przybylem na party, popilem, zero checi na skonczenie dema. Kiedy polozylem sie, z zamiarem wyspania sie cos kolo 23 znowu spelzlo na niczym. O drugiej w nocy silentriot i Niemiec-topy urzadzili mi zajebista pobudke metalem z najwyzszej polki, trzezwienie kontynuowalem pijac stawiane piwa. Cos pod poludnie zabralem sie za konczenie dema, majac zerowa wiedze na temat irq loadingu oraz brak niektorych narzedzi. Starczy tego tlumaczenia, bedzie cos dla potomnych

                   

Cytat:

w obecnych czasach kodowanie na c64 ma sens tylko wtedy gdy musisz cos z dokladnoscia do cyklu tworzyc (synchronizacja VIC-CPU etc),

Nawet tutaj juz C64 nie trzeba, emulki naprawde to wszystko juz obsluguja, wskazcie mi jedno demo Crest, ktore zle chodzi na Hoxs\'ie.

                   

Cytat:

matematyczne rzeczy robi sie o wiele wygodniej na PC (chocby symulacja krokowa na 6502sim) tym bardziej ze przy takich sprawach czysto matematycznych nie mozna winy zwalic na emulator zle emulujacy triki w VIC etc. Nie oszukujmy sie - wiekszosc ostatnio wydanych dobrych dem to efekt crossasmu. wiem ze ilosc moich wydanych produkcji moze podwazac to co pisze (Zaatakowales o to Nitro bynajmniej :p ), ale jak cos sobie dlube to zaczynam od prototypowania na PC w C przy uzyciu jakiejs biblioteki graficznej (np Allegro albo SDL) i dopiero jak osiagne jakis zadowalajacy efekt to staram sie to stabelaryzowac/zoptymalizowac i recznie potem przepisac w ASM (algorytm Bresenhama tak implementowalem - z sukcesem).

W 100% popieram
P.S. Ten post nie ma na celu rozpoczynanie jakis wojenek...

[Izaak Berenbaum__]

                   

V-12 napisal:

Nie chce wchodzic w polemike, na czym sie lepiej koduje, bo to czesto jest efekt pewnego rodzaju przyzwyczajenia, a nie tylko okreslonych mozliwosci sprzetu i/lub oprogramowania. Dla mnie tworzenie na C64 niesie za soba pewnego rodzaju klimat i mile przezycie i o to przede wszystkim chodzi .

i tu sie zgodze,czesto przyzwyczajenia odgrywaja wieksza role niz realne mozliwosci czy prostota. czesto bardziej nameczymy sie korzystajac z prostszego i wygodniejszego na dluzsza mete ale nowego oprogramowania niz bardziej skomplikowanego ale dobrze opanowanego.

mysle jednak ze obiektywnie patrzac na problem mozna pokusic sie o stwierdzenie ze cross developing ma spora przewage. piszac obiektywnie mam na mysli punkt widzenia osoby ktora nie miala wczesniej stycznosci z zadna forma tworzenia kodu w 6510- taka po porownaniu obu sposobow raczej zdecyduje sie na cross dev,nawet jesli wychowala sie na komputerach 8bitowych.