letzter Beitrag von spacer am
Hallo, guten Tag.
Ich möchte jetzt ein Grafikbild einlesen in dem Speicher vom VDC (16kb)
Ich starte die einlese.com von D: und möchte jetzt die Grafikbytes (bild1.bin) von Laufwerk B: einlesen.
Wie teile ich das dem fopen bitte mit ?
fin=fopen("bild1.bin", "rb");
Danke.
Gruss
Ich habe keine Ahnung was VDC ist, aber
fin=fopen("b:bild1.bin", "rb");
geht nicht?
Man kann am C128 keine Dateien direkt in den VDC-Speicher laden.
Das VDC-RAM ist außerhalb des normalen Adressbereichs des Rechners.
Der Austausch von Daten mit dem VDC-Chip funktioniert nur über die beiden Speicherstellen $D600 und $D601.
... und in diesem Buch ab Seite 169:
fin=fopen("b:bild1.bin", "rb");
Sicher, daß das unter Aztech C für CP/M 80 funktioniert?
Alternativ die BIOS Funktion SELDSK aufrufen?
Sicher, daß das unter Aztech C für CP/M 80 funktioniert?
Keine Ahnung. Das ist aber Sache des Betriebssystems. Der C-Compiler sollte den Dateinamen einfach nur durchreichen.
Irgendwie funktioniert es nicht so mit dem Speicherbereich.
Ich habe den VDC auf 64kb geschaltet beim VICE.
Wenn ich die Taste "B" drücke kommen einpaar Pixel in den ersten 16KB-Speicher bei : "fin = fopen("bild1.bin","rb");"
und bewegen sich auch etwas, kann sie auch nicht überschreiben, kommen immer wieder bis ich wieder schließe mit "fclose (fin);".
Wenn ich auf die 2. 16kb schalte vom VDC, erscheinen sie nicht.
Irgendwo ist dort eine Störung.
GRuss
PS: Warum kommt hier meine Texteinrückung immer durcheinander im Forum ?
Man kann die Daten nur über die Speicherstellen $D600 und $D601. durchreichen.
Das funktioniert bei mir einwandfrei bei meinem Beispielen.
GRuss
Ich habe den VDC auf 64kb geschaltet beim VICE.
Man muß auch das 64K-Flag im Kontrollregister setzen. Siehe 128 intern, CXEQU (vom CP/M-BIOS-Sorcecode), C64 Wiki...
Der C-Compiler sollte den Dateinamen einfach nur durchreichen.
Gute Idee, wenn die Dateifunktionen nur FCBs unterstützen, die man bitte selbst befüllen darf. Die meisten Tools haben zwar das bekannte a:datei.ext Format verwendet, aber es gab auch deutliche Abweichungen. Filename-parsing war jedenfalls noch sehr marginal... das kam erst mit den Unix-Dateifunktionen von MS-DOS 2.0, und bei CP/M sogar erst mit DOS-PLUS alias DR-DOS, das eigentlich ein Multitasking-CP/M 86 mit DOS-Interface-Layer war.
Ich zeichne jetzt das BIN-Bild über einen Buffer in den VDC-Speicher und nicht mehr direkt aus dem File.
Das funktioniert ohne die Störung des VDC-Speicher.
Zum Bild :
Ich zeichne ein BMP-BIld 640x200 in sw und wandle es dann mit meinem Purebasic-Programm in eine Binärdatei.
Danke.
Gruss
Toll!
Das.könntest Du als kleine Grafik Lib veröffentlichen?
Tipp: paar Sachen kann man bisserl kürzer schreiben. Z.B.
for(g= 0; g < 16000; ) {
vdcmemwr(g++,*BufPtr++);
}
Tipp: paar Sachen kann man bisserl kürzer schreiben. Z.B.
for(g= 0; g < 16000; ) {
vdcmemwr(g++,*BufPtr++);
}
Typische C Unart. 
Ist deutlich schlechter lesbar und bringt keinen Geschwindigkeitsgewinn.
Sollte man sich nicht angewöhnen.
Typische C Unart.
Sollte man sich nicht angewöhnen.
Mit der schlechteren Lesbarkeit stimme ich Dir absolut zu.
Aber bringt es wirklich keinen Performance-Unterschied?
Ich war immer der Meinung, wenn man "kleiner als" vs. "kleiner-gleich als" bzw. "grösser als" vs. "grösser-gleich als" bei Ersterem nur EINE Vergleichsoperation vs. ZWEI Vergleiche durchgeführt werden - egal welche Programmiersprache man nimmt.
Insofern würde ich erwarten dass <= und >= langsamer sind als < und >.
Insofern würde ich erwarten dass <= und >= langsamer sind als < und >.
Ok, das mit dem <= war mir nicht aufgefallen. Bei Schleifen, die 0 beginnen, schreibe ich auch immer < Count, weil Count dann die Anzahl der Durchläufe bzw. Elemente repräsentiert.
Keine Ahnung, ob <= grundsätzlich langsamer ist. Wenn ich wirklich zeitkritische Dinge programmiere, dann messe ich das nach. Kann ja auch Compiler-spezifisch sein.
Wenn 6502 oder Z80 Code erzeugt wird, kann man auch mal in den generierten Assemblercode reinschauen.
Nope, wenn man es auf Assemblerebene betrachtet.
> : BPL +BNE
>=: BCS
< : BCC
<=:BMI
= : BEQ
<>:BNE
Alles ausm Kopf und ich bitte um Verzeihung wenn da was hakt, aber wenn ich es recht entsinne ist es in der Tat so dass der Vergleich auf Größer der einzige ist der zwei Vergleiche Benötigt, da hier gecheckt werden muss ob das Ergebnis nicht negativ ist und dann noch ob es ungleich null ist.
Das gilt natürlich nur für 65xx, andere Architekturen mögen andere Befehle haben, und lässt sich einfach umgehen indem man auf < prüft mit vertauschten Argumenten.
Das gilt natürlich nur für 65xx, andere Architekturen mögen andere Befehle haben, und lässt sich einfach umgehen indem man auf < prüft mit vertauschten Argumenten.
Das hängt natürlich davon ab, welchen Wert man gerade im Akku hat. Vertauschen kann ziemlich aufwändig sein.
Ich glaube aber nicht, dass ein C-Compiler für 8-Bitter das so gut optimiert (wenn er überhaupt was optimiert).
Aber ich glaube, wir schweifen ab... 
Nö, es hängt nicht vom Wert im Akku ab. Du weisst doch in dem Moment wo du den Code schreibst ob Du auf größer oder kleiner prüfen willst.
Und statt eines if a>b fügst Du in deinen Code dann halt ein if b<a ein und schwupp hast du eine Vergleichsoperation eingespart.
Der Code selbst ist ja unabhängig vom Wert der Später im Register steht.
Es muss einem halt nur beim Schreiben des Codes bewusst sein dass ein < einem > vorzuziehen ist.
Nö, es hängt nicht vom Wert im Akku ab.
Doch, doch. Wie der Compiler bei der Codegeneration die Register des Prozessors belegt, ist unabhängig davon, welchen Hochsprachencode Du schreibst. Ob da steht "if a > b" oder "if b < a", ist für den Compiler egal, denn solange die Erzeugung der Vergleichswerte vollständig bekannt ist - was bei einfachen Variablen oder Konstanten selbstverständlich gegeben ist - vertauscht er die Werte, wie er will und eben auch in Abhängigkeit davon, welchen der beiden Werte er bereits in einem Register vorliegen hat.
Zwar ist es richtig, daß man bei den 8-Bittern einige Vergleiche aus 2 Sprüngen zusammenbasteln muß, viel wichtiger bei Zählschleifen ist jedoch, daß der Zähler vorzeichenlos (unsigned) sein sollte. Bei einem echten Vergleich zweier vorzeichenbehafteter Zahlen muß unbedingt auch das Overflow-Flag (V) mitbetrachtet werden, sonst kann es zu falschen Ergebnissen kommen. Anders als z. B. der 68000 (BLE, BGT usw.) verfügen weder 6502 noch Z80 über vorzeichenbehaftete Vergleichssprünge, so daß man zusätzlich einen Test auf V mittels BVC/BVS bzw. JP PO/PE vornehmen muß.
Zuletzt ist es natürlich auch noch wichtig, daß der Zähler nach Möglichkeit nicht mehr als 8 Bit groß sein sollte, damit er direkt in ein Register geladen und verglichen werden kann. Folglich nimmt man nach Möglichkeit für Zählschleifen am besten unsigned char.
Nö, es hängt nicht vom Wert im Akku ab. Du weisst doch in dem Moment wo du den Code schreibst ob Du auf größer oder kleiner prüfen willst.
Ich meinte nicht, welchen Wert der Akku hat, sondern ob sich vor dem Vergleich a oder b im Akku befindet.
Darauf hat man natürlich nur bei direkter Assemblerprogrammierung Einfluss (und es ging ja oben um Vergleiche in Assembler).
In C hat man darauf keine Einfluss.
> : BPL +BNE
>=: BCS
< : BCC
<=:BMI
Es geht auch:
> : BCC
<= : BCS
wenn man die Subtraktion rumdreht. (...und besonders ätzend für Bilinguisten: bei Z80 und Konsorten ist das Carry-Flag bei Subtraktionen invertiert im Vergleich zum 6502, aus dem BCS wird also ein jr nc...)
