joyceforum.de

Eine Frage zu den Aufzählungstype und der Art wie TRUE u. FALSE als logisches Flag erzeugt werden. Man sieht auch häufig die Zu.-Fuß-Methode:
Ich nehme mal an, daß das persönlicher Programmierstil ist. Mir würde dieser Weg auch mehr zusprechen, da der logische Zusammenhang klarer ausformuliert ist (bin halt mehr Hardware-Fritze, FALSE ist nun mal das inverse von TRUE).

Im Kapitel Strukturen bein ersten Code-Beispiel steht:
Da ist sicherlich ein "struct" zu viel. Gemeint ist sicherlich:
denn sonst würde "struct" als Struktur "Book" definiert werden, was sicherlich nicht beabsichtigt ist (wie im 2ten Code-Beispiel gezeigt).

Ich habe im 3ten Code-Beispiel zur Buch-Struktur einmal den ersten Text-String verdreifacht. Der HT-C Compiler meckert jedenfalls nicht, wenn die zuzuweisende (statische) Zeichenkette länger ist wie der dafür resevierte Speicher. Ist das generell so, das vom Compiler hier nichts kommt, obwohl er das erkennen könnte ? ist im Grunde kein Beinbruch, ist sicher besser Eingabetexte auf max. Länge zu kontrollieren, aber bei statische Sachen sollte der Compiler aufmucken (also gewissenmaßen Copy-und-Paste Fehler abfangen, denn statische Zeichenketten zählt man selten nach).

Umbau klingt so nach Großaustelle, eigentlich besteht der 'Umbau' aus 2 Adapter und dem Entfernen des PIC-Prozessors. Da ich mich so an den manuaellen RESET gewöhnt habe, ist es sinnvoll, den 2ten Umschalter jetzt zum Reset-Taster zu erklären.Da ich derzeit noch auf die bestellten Taster warte, ist auf dem Foto noch der 2xUM Schalter rechts neben dem ON/OFF-Schalter verbaut. Deatils zum Umbau sind im 7zip-Archiv enthalten. Es gibt keinen richtigen Schaltplan für das kurze Adapterkabel. An den Löt-Pins für Kupplung und Stecker stehen die Namen der farbigen Litzen, damit sollte alles erklärt sein. In den Service-Unterlagen wird sugeriert, das die Pin-Nummerierung der Pin-Header-Leiste auf dem Board des Tastatur-Prozessors der Pin-Numerierung der DIN4-Kupplung entspricht, dem ist NICHT so ! Nach Durchklingeln der Leitungen - weils partou nicht funktionieren wollte - zeigte sich schnell, das dem eben nicht so ist wie gezeichnet. Das hat mich einige Zeit gekostet, aber Schwamm drüber, jetzt läuft's ja

Die DIN4-Kupplung habe ich von "hi-fi-expert_de" (hat ev. auch die MINI-DIN6 Stecker, spart Porto),
den MINI-DIN6 Stecker gibt's bei "DO4CQ", beides auf eBay.

Ein kurzes Experiment zeigte: Locoscript tut's jetzt anstandslos. Mit der Habi-Soft PS/2-Alternative war ja kein Blumenstrauß zu gewinnen - nur hemmungsloses gepiepe etc. Das jetzt der Mausanschluß und der DB9 für den Joystick funktionslos sind, muß sicherlich nicht extra erwähnt werden. Den PIC16F628A sollte man sich wiederfindbar beiseite legen. Irgendwie spukt mir immer noch der Gedanke durch den Kopf, irgendwann das PS/2-Interface etc. neu auf zu setzen - es ist ja brauchbar, nur noch nicht ganz 'serienreif'. Dafür liegt die Priorität aber recht niedrig. Anderes, wie ein CF-Karten Interface steht bei mir ganz oben auf dem Zettel. JonB vom CPC-Wiki Forum habe ich schon kontaktiert, sobald er die PCB's hat, geht's los (...mit dem Warten auf die Post aus England).

Ups, mein letztes Lebenszeichen ist auch schon 7 Tage her, trotzdem kein Müßiggang: Mein Sohn will sich unbedingt für sein Mini-ITX Board per 3D-Druck ein eigenes Gehäuse bauen, ist beim 3D-CAD aber Neueinsteiger. Ihm die notwendigen Tipps per Schnellkurs zu vermitteln hält halt auf. Daneben hängt jetzt an meiner 2ten Velleman-Joyce eine Joyce Original-Tastatur. Das hat mich 2 Tage an gefrickel gekostet, da in den Serviceunterlagen die Pin-Belegung des DIN-4 Steckers nicht mit der Realität üereinstmmt, mal davon abgesehen, das die vor einem Jahr beschafften DIN-4 Kupplungen auf wundersame Weise verschwunden sind und neu beschafft werden mußten. Ich hoffe mal, das ich die Doku dazu heute abend noch fertig bekomme und ins Forum stellen kann (ansonsten im Laufe des Wochenendes). Alles Kleinkram, hält aber erstaunlich lange auf.

Ich gelobe Besserung - soweit möglich ...

>>Das können wir mal aufgreifen, wenn wir zur Dateiverarbeitung kommen.
Ja, wäre super. Dann kann man sich mit eigenen 'Verbesserungen' daran austoben.

Das Thema ließe sich richtig ausbauen. Z. B., was ist zu tun, wenn ein mehrzeiliger Kommentar eröffnet, aber nicht bis zum Ende der eröffnenden Zeile durch ein '*/' geschlossen wird und zu allem Überfluß innerhalb des Kommentares '//' am Textanfang auftreten. Das ermöglicht es, alle bisher angesprochenen Kontrollstrukturen etc. auf den Plan zu rufen. Das wird interessant werden.

Dieses Pointer-Geschäft bei C ist ein echtes Minenfeld. Im Grunde nicht kompliziert, aber man muß aufpassen, sonst platz die Bombe.

Ich habe ein ganz anderes Problem: HTC kennt die Kommentar-Einleitung mit den 2 '//' nicht. Kann man dem Preprozessor per Makro irgendwie verklickern, diese Art von Kommentar bei der Vorverarbeitung des Programms/include-Dateien einfach zu löschen ? Noch sind die Beispiele kurz, aber sobald sie länger werden ist es mühsam, diese Korrektur jedesmal von Hand zu erledigen. Weiterer Grund: Bei meiner eigenen Grafik-Bibliothek sind diese Art der Kommetare in den Files reichlich vorhanden, was die Übertragung nach HTC recht mühsam werden läßt.

>>Wie müsste ich das schreiben damit 4 ein LValue ist?
Das was Du vrsuchst ist Pointer-Arithmetik, das muß dem Compiler aber klar gemacht werden, sonst versteht er es falsch. Versuch einmal soetwas, müßte gehen: *(&a + 4) = 42;. '&a' greift auf den Inhalt von a zu, addiert 4 hinzu und benutzt das Ergebnis dann, um 42 auf die Stelle zu schreiben, auf die *a zeigt. Das ist genau das, was ich an C so liebe.

Moin Bernd,
die Assembler-Codesequenzen sind ein sehr interessanter Einblick in die Art wie die Compiler den C-Code umsetzen. Wenn ich die beiden Assembler-Ergebnisse einmal genauer betrachte, dann erscheint mir das Ergebnis, welches der sccz80 produziert, näher an den Vorgaben des C-Codes zu sein, ganz im Gegensatz zum zsdcc. Der sccz80 legt den Zeiger auf den Ausgabetext auf den Stack, gibt den Text aus und räumt anschließend durch pop bc den gesicherten Zeiger wieder ab. Dann gibt es ein LD hl,0 für das RETURN 0, ganz wie es im C-code steht. Der zsdcc lädt nach dem call _printf anscheinend ein Flag von _printf ins CPU Statusregister - eine Optimierung ?. Wie's dann weitergeht, ist wegen der Endlosschleife leider nicht zu sehen, aber diese Vorgehensweise wirkt auf mich wie ein unsauberes Vorgehen. So gesehen, würde ich mich eher für den sccz80 als Compiler entscheiden.

Aus rein verständnisstechnischer Sicht, würde ich trotzdem die 'while (true) {....} Schleife bevorzugen, Je früher ersichtlich wird, was beabsichtigt ist, umso besser. C hat ohnehin einen gewissen Hang zum 'Abküfi' ... ('Abküfi' => Abkürzungsfimmel)

Off-Topic: Ich versuche mich mit den Beispielen, wenn möglich, auf drei Systemen: PC, Multicomp und die Joyce. Aber jedesmal, wenn die Joyce dran ist, habe ich das Gefühl, mir sitzt Prinz Walium gegenüber. Geht es nur mir oder Euch auch so ? Wie hat man das 'Damals' nur ausgehalten. Da scheint sich doch eine Zeitenwende abgespielt zu haben...

Moin Bernd,
hier müßtest Du nachbessern:
z wird nicht mit '0' sondern '3' initialisiert.

Eine Frage zu den Endlosschleifen: Hier wäre vermutlich der Eindeutigkeit wegen die Variante 2 oder 3 zu bevorzugen, da durch das 'true' sofort ersichtlich ist, das es hier endlos im Kreis zugehen wird. Bei der for-Schleife wäre das nur aus der besonderen Schreibweise ersichtlich, also in Kenntnis dieser Sonderform. Es könnte aber auch ein Copy-und-Paste Fehler sein, wenn an einem größeren Programm gearbeitet wird.

Ich habe mir hier den Programmierkurs insofern etwas erweitert, als ich versuche, das ganze remote auf der Joyce zu erledigen. Also den Kurs auf dem PC lesen und die Beispiele verfolgen. Diese sollen dann remote auf die Joyce gehen (per DEVICE die Seriele parallel zu Tastatur und dem Bildschirm). Tippen per Tastatur ist da das Einfachste. Bei Copy-und-Paste hakt es jedoch noch etwas mit der Übertragung. Ich verwende den TE als Editor (z. Zt. habe ich keinen anderen auf der Joyce). Der TE zickt leider etwas, die Zeichen kommen ihm wohl zu schnell und das Ergebnis entspricht dann nicht unbedingt dem gewünschten. Hier kommt der Lerneffekt ins Spiel, in Form des Korrekturlesens. Läßt man einmal die Betriebsprobleme außer acht, die mit dem Kurs eigentlich nichts zu tun haben - aber den Lernstoff deutlich auflockern , ist der Kurs sehr interessant und macht Spaß. Der Umfang der Beispiele ist genau richtig, das Tempo mit neuen Lektionen auch.

Die 'fertigen' Beispiele übersetzt mir dann mit HI-Tech C, welches ich wegen der Paketgröße von >720k auf zwei Disketten-Images verteilen mußte. Nachdem auch noch die Hürde mit dem Auffinden der Include-Dateien auf Laufwerk B: gelöst ist, funktioniert alles ganz prima. Der Compiler wollte doch ganz gern wissen, das er ebenfalls auf B: suchen soll. Das Regelt der zusätzliche Parameter '-I 0:B:' beim Compiler-Aufruf. Das Lesen des vielfach unterschätzten Handbuches hilft doch enorm

Die Leiden mit den deutschen Sonderzeichen:


Hab' ich wohl vergessen in der PROFILE.SUB zu ändern.
Aber davon einmal abgesehen läuft's gut...
Was mit der ersten Stelle hinterm Komma los ist, verstehe ich noch nicht ganz, aber schon interessant.
Ändert man Zeile 11 in einaus.c auf printf("\nDie Flaeche betraegt: %2.4e\n", flaeche); wird die erste Stelle hinterm Komma eine Zahl. Da spinnt wohl printf() der Vers. 2.3 etwas. Ist wohl doch zu bleeding edge...