Das Listing oben sieht so aus, als sei dafür eine Float-Library eingebunden worden
Dann gibt es also eine? Bei CC65 nämlich nicht, was einer der größten Nachteile ist.
Es gibt 37 Antworten in diesem Thema, welches 4.978 mal aufgerufen wurde. Der letzte Beitrag (
Das Listing oben sieht so aus, als sei dafür eine Float-Library eingebunden worden
Dann gibt es also eine? Bei CC65 nämlich nicht, was einer der größten Nachteile ist.
Dann gibt es also eine? Bei CC65 nämlich nicht, was einer der größten Nachteile ist.
Sieht so aus:
Bitte melde dich an, um diesen Link zu sehen.
Im Mikrocontrollerbereich gibts deswegen manchmal die Option, eine Library mit einem nicht float-fähigen printf einzubinden.
Scheint es hier auch zu geben:
ZitatRun time library defines
-dNOLONG : no support for long in printf
-dNOFLOAT : no float in printf
mit oscar64 eröffnet sich mir jetzt die ganze CBM Welt, ohne, dass ich einen Assemblerdialekt verwenden MUSS, den ich nicht wirklich kann. Stattdessen kann ich in modernem C programmieren, und schon ziemlich geile Sachen erreichen. Ja, irgendwann stoße ich da auch an die Grenzen, aber erstmal nicht.
Sobald man timingkritische Sachen machen will, sprich anfängt Taktzyklen zu zählen, kommt man um 6502-Assembler nicht drum herum.
mit oscar64 eröffnet sich mir jetzt die ganze CBM Welt, ohne, dass ich einen Assemblerdialekt verwenden MUSS, den ich nicht wirklich kann. Stattdessen kann ich in modernem C programmieren, und schon ziemlich geile Sachen erreichen. Ja, irgendwann stoße ich da auch an die Grenzen, aber erstmal nicht.
Sobald man timingkritische Sachen machen will, sprich anfängt Taktzyklen zu zählen, kommt man um 6502-Assembler nicht drum herum.
So weit bin ich noch lange nicht.
Erstmal einfachere Sachen machen, die aber in BASIC zu umständlich oder lansgam wären. Und auf dem PET kommt man selten zu den Taktzyklen... Nur wenn man GANZ krasses Zeug macht...
Ein großer Vorteil von C ist halt, daß man ja auch jederzeit ASM benutzen kann. Üblicherweise sogar inline. Scheint Oscar auch zu können ("__asm").
Das größere Problem ist halt die extreme Ressourcenknappheit und eine CPU, die nicht wirklich für Hochsprachen gemacht wurde.
In ASM packt man halt wichtigen Variablen in die Zeropage, schreibt selbstmodifizierenden Code usw.
Wobei Oscar sogar Variablen manuell ("__zeropage") oder automatisch (-Oz bzw. -O3) in die Zeropage legen kann.
Warum legt ihr nicht einen Struct über den VIC und setzt dann einfach den entsprechenden Wert?
Bitte melde dich an, um diesen Link zu sehen.
Die Frage war ja "Wie macht man POKE53280,1?" und nicht "wie greife ich auf den VIC zu". Oder habe ich da was verpaßt?
Solche Struct-Abbildungen sind zwar in der "normalen" Mikrocontrollerwelt extrem üblich, aber da kosten sie auch in Sachen Laufzeit praktisch nichts, weil jeder normale Mikrocontroller heute diverse indirekte Adressierungsarten beherrscht.
Beim 6510/6502 wird das vermutlich schon etwas Laufzeit kosten im Vergleich zu einer absoluten Adresse.
Und Sachen wie spr0_color ... spr7_color (anstelle eines Arrays) sind halt auch nicht die Ausgeburt der Eleganz.
Solche Struct-Abbildungen sind zwar in der "normalen" Mikrocontrollerwelt extrem üblich, aber da kosten sie auch in Sachen Laufzeit praktisch nichts, weil jeder normale Mikrocontroller heute diverse indirekte Adressierungsarten beherrscht.
Normalerweise kosten die in der Mikrocontrollerwelt nichts weil der Compiler die Adressberechnung komplett wegoptimiert und einen Zugriff auf eine absolute Adresse erzeugt. Bitte melde dich an, um diesen Link zu sehen. kann das zB.
Solche Struct-Abbildungen sind zwar in der "normalen" Mikrocontrollerwelt extrem üblich, aber da kosten sie auch in Sachen Laufzeit praktisch nichts, weil jeder normale Mikrocontroller heute diverse indirekte Adressierungsarten beherrscht.
Normalerweise kosten die in der Mikrocontrollerwelt nichts weil der Compiler die Adressberechnung komplett wegoptimiert und einen Zugriff auf eine absolute Adresse erzeugt. Bitte melde dich an, um diesen Link zu sehen. kann das zB.
Ich vermute mal, das oscar64 das auch macht. In jedem Fall ist es ein echt Beeindruckend guter Compiler. Deutlich schnellerer Code als von cc65. Da kann man in der Tat eine ganze Weile rumspielen, bevor man auf Assembler zurückgreifen muss.
Also, oscar64 macht auf mich einen echt guten Eindruck. Das Kompilieren auf meiner Linux-Box läuft sauber durch, ohne zu meckern. Das hat man nicht immer. Sind auch echt viele Aspekte beachtet worden, da scheint sich jemand ziemlich viele Gedanken gemacht zu haben.
Wurde auch Zeit, daß mal ein ein neues Projekt zu dem Thema gestartet wurde, CC65 hatte ja gewisse Schwächen.
Also, ich bin beeindruckt, und werde mir mal anschauen, was damit alles gemacht werden kann.
Also, oscar64 macht auf mich einen echt guten Eindruck. Das Kompilieren auf meiner Linux-Box läuft sauber durch, ohne zu meckern. Das hat man nicht immer. Sind auch echt viele Aspekte beachtet worden, da scheint sich jemand ziemlich viele Gedanken gemacht zu haben.
Wurde auch Zeit, daß mal ein ein neues Projekt dazu gestartet wurde, CC65 hatte ja gewisse Schwächen.
Also, ich bin beeindruckt.
Und der Autor reagiert pronto. Ich habe heute schon einen Pull Request durchgewunken bekommen, der kbhit() auf PETs fixed. ![]()
Ich glaube es wurde noch nicht gepostet, aber er hat in einem anderen Github Repo auch eine Reihe an Sample Code und Tutorials erstellt:
Bitte melde dich an, um diesen Link zu sehen.
Er hat ja auch schon eine Reihe an Spielen für den 64er veröffentlicht:
Bitte melde dich an, um diesen Link zu sehen.
Ach, es steht ja sogar im GithubRepo von Post Bitte melde dich an, um diesen Link zu sehen., dass die Spiele ja mit oscar64 gebaut wurden. Das macht es ja noch cooler ![]()
Bitte melde dich an, um diesen Link zu sehen. POKE(x,y) (*((volatile char *)(x))=(y));
Besser wäre sowas hier (ungetestet):
Noch besser:
Siehe z.B. Bitte melde dich an, um diesen Link zu sehen., wieso das "do [...] while (0)" so eine gute Idee ist.
Noch besser: Code
Bitte melde dich an, um diesen Link zu sehen. poke(x,y) do { *((volatile unsigned char *)(x))=(y); } while (0)Siehe z.B. auf Stackoverflow, wieso das "do [...] while (0)" so eine gute Idee ist.
Und dann sind wir so weit, dass eine inline Funktion eine bessere Idee ist. ![]()
Und dann sind wir so weit, dass eine inline Funktion eine bessere Idee ist.
Bäh, das ist C99, also Teufelszeug. ![]()
Nun ja, das Idiom mit dem do ... while(0) sollte man aber schon kennen, wenn man auch fremde, alte Sourcen betrachten muss.
EDIT: Einmal da angekommen, würde ich doch uint16_t und uint8_t nehmen, oder nicht?
Und dann sind wir so weit, dass eine inline Funktion eine bessere Idee ist.
Bäh, das ist C99, also Teufelszeug.
Nun ja, das Idiom mit dem do ... while(0) sollte man aber schon kennen, wenn man auch fremde, alte Sourcen betrachten muss.
EDIT: Einmal da angekommen, würde ich doch uint16_t und uint8_t nehmen, oder nicht?
Ja klar, dieses Programm hier kompiliert mit Oscar64 ohne Probleme:
Statt "uint16_t" besser "uintptr_t" benutzen :-)
Ja gut, aber dann kann der Frager nicht mehr einfach so einen int hinschreiben, oder?