Posts by Bytebreaker

Es ist leider ein Backbone Spiel, d.h. gehört zur Flut der Spiele, die mit einem Game Construction Kit gemacht sind.

Es gibt gute Backbone Titel wie "Tales of Gorluth" aber ich finde es besser wenn man lieber länger braucht und dafür in C oder Assembler programmieren lernt und die Hardware auch fordert.

Quote from VomitOnLino

Das mache ich bei meinen Kameras (mein anderes Hobby) genauso

So auch bei mir kürzlich geschehen mit einer alten Olympus OM20. Erst sah es so aus als sei sie defekt, am Ende hat ein oxydiertes Batteriefach dafür gesorgt dass der Spiegel geklemmt hat auch wenn man neue Batterien eingelegt hatte.

Nach einer Reinigung habe ich einen 2011 abgelaufenen Farbfilm verschossen und die meisten Bilder sind sogar was geworden, da es ein wenig empfindlicher Film war.

Hilfe konnte ich mir in einem deutschen Forum holen. Das ist wirklich das Tolle. Es gibt für viele "tote" Dinge sehr lebendige Gemeinschaften mit viel erhaltenem und gepflegtem Fachwissen.

Die Haptik und Vollmetallausführung alter Kameras erzeugt eine höhere Wertigkeit, auch wenn die OM20 auch damals "bloß Mittelklasse" war.

Erst mit den Smartphones hat die Wirtschaft wieder bemerkt dass sich gute Technik besser verkauft wenn sie nicht in knarziges billiges Plastik verpackt ist.

Ich habe gerade den TheC64 im Haupteinsatz und durch das Klicken der Mikroschalter des Joysticks und die Haptik der Tastatur vergesse ich dass er nicht "echt" ist. Ich vergesse auch die falsch gedruckte 0 auf der Tastatur.

Irgendwann kommt wieder ein Original C64 dran, am Besten ist doch die Rotation verschiedener Geräte an denen man sich abwechselnd freuen kann.

oobdoo :

Am Ball bleiben ist doch das Entscheidende. Irgendwann hat man es dann.

Also dieses "heiß machen und dann auf die Wartebank schieben" kenne ich sonst auch nur von Frauchen...

Bitte in diesem Thread zur gegebenen Zeit einen klaren Hinweis, wo und wie man RaimundP's Sammlungen beziehen kann, ohne dass RaimundP Ärger kriegt.

Aktuell gehe ich davon aus, es gibt keinen geeigneten Veröffentlichungsweg.

Rnd(-x) "funktioniert" prinzipiell schon. Aber eben nicht richtig und mit jeder Parametrierung. Schon allein dass man rnd an ti koppeln muss ist eigentlich blöd. Andererseits war das 1982. Was will man denn noch alles von der alten Kiste erwarten.

Bzw. eine Info hier im Thread wäre gut sobald die Cloud um eine weitere Gabe reicher ist.

Auf meinem Pi 1 läuft Openelec mit MPG Lizenz als Media Player. Es wird HDMI CEC unterstützt und viele Apps gehen noch wie z.B. YouTube.

Natürlich ist Kodi auf einem Firetv mit LAN Adapter die bessere Wahl aber wenn man noch einen HDMI Port am TV frei hat und Verwendung für einen Pi 1 sucht...

Ich habe Openelec gewählt weil es die Ressourcen des Pi 1 besser ausnutzt als andere xbmc Distributionen.

https://openelec.tv/

Hallo zusammen,

das Sonnenstandsprogramm wurde aktualisiert.

• Das Programm startet nun komplett via Autostart, keine separate load-Anweisung mehr erforderlich
• Man kann bis zu 10 Standorte speichern und es gibt eine Dateiverwaltung zum erweitern, löschen und überschreiben
• Die Ausgabe der Standorte ist stets sortiert
• Die vorgespeicherte UTC-Zeit kann man bei der Parameterangabe direkt anpassen,um direkt auf Sommerzeit/Winterzeit-Abweichung abhängig vom Datum reagieren zu können

@ Lord Sinclair:

Ja richtig erkannt. Am C64 sind das die kleinen roten Sonnen.

@ BIF:

Das was Du beschreibst kann man alles auf einer Smartwatch am Handgelenk führen, d.h. neben Sonnenverlauf auch Temperatur und Wetterbedingungen. Auch mit Vorschau für stundengenaue Vorhersage und zwar für den Ort an dem man gerade ist. Ich gucke schon lange kein normales Fernsehen mehr für Wetter & Co.

GoDot

Wenn ich das Listing aus Deinem Eintrag 9 in TSB einkopiere, sagt er "Syntax Error in 205".

Ich sehe da keinen Syntaxfehler, aber was mache ich dann falsch dass es nicht klappt?

Hallo zusammen,

auf der Apple Watch gibt es ein Ziffernblatt, auf dem man ein Sonnenstandsdiagramm sieht. Es ist nur eine X-Achse eingezeichnet als Zeitachse und Horizont und die sinusartige Linie die den Horizont schneidet, ist der Sonnenverlauf in Höhengrad. Wenn man an der Krone dreht, sieht man einen Leuchtpunkt, der sich als symbolische Sonne entlang der Höhenverlaufslinie bewegt, dazu sieht man immer auch die dazu passende Uhrzeit sowie die markanten Punkte Sonnenaufgang, Sonnenhöchststand und Sonnenuntergang.

Das fand ich so elegant und interessant dass ich dachte, das muss man doch am C64 nachprogrammieren können. Gesagt getan.

Besonders gut fand ich, dass unser 40 Jahre alter C64 exakt rechnet. Bitte vergleicht die C64 Werte mit den Werten der beiliegenen Open Office Tabellenkalkulation. Es gibt Abweichungen, aber erst in den hinteren Nachkommastellen.

Hinweise zur Open Office Kalkulation:

• Die Felder Tag, Monat und Jahr im Tab "Eingabe + Ergebnis" füllen sich automatisch mit dem Datum "heute" aus, sind aber von Hand überschreibbar
• Die Felder UTC, Breite Phi und Länge Lambda sind von Hand zu ändern.
• UTC beschreibt die Abweichung von der Greenwhich-Zeit, die bei uns auch sommer/winterzeitbedingt zu sehen ist. Für Deutschland gilt im Sommer UTC -2, im Winter UTC-1.
• Breite Phi und Länge Lamdba sind die geographischen Breiten- und Längenkoordinaten des Ortes, für den ihr den Sonnenstand bstimmen wollt. Pforzheim ist aktuell voreingestellt. Alternative Orte auf der Welt stehen im Tab "Weitere Geokoordinaten". stat die Werte zu kopieren und einzufügen kann man auch referenzieren, d.h. anstatt =Geokoordinaten.B9 im Feld Breite und =Geokoordinaten.C9 im Feld Länge für Pforzheim kann man auch =Geokoordinaten.B3 und =Geokoordinaten.C3 für Tokio nehmen.

Hinweise zur C64 Version:

• Bitte das d64 astro.64 per Drag 'n Drop in VICE ziehen, so dass ein load"*",8,1 ausgelöst wird - das muss sein, denn dann wird ein Maschinenspracheprogramm vorgeladen, dass sich später um die grafische Darstellung im Hires-Modus kümmert
• Dann mit load"sonne",8 und run starten
• Die Koordinaten sind hier von Hand einzugeben, Pforzheim ist vorausgewählt.
• Wann für die UTC-Eingabe Umstellungszeitpunkt Sommerzeit/Winterzeit ist, könnt ihr mit dem Programm "sowi" herausfinden, das mit auf dem astro.64 Image ist
• Der Wochentag wird aus der Datumsangabe heraus mitberechnet - auch separat als Programm "wota" auf dem d64 ausführbar
• Wer keine Grafik und Tabelle am Ende will sondern nur die wesentlichen Zeiten wissen will, kann das im Dialog auswählen, dann geht das Programm deutlich kürzer
• Ich bin ein großer Fan davon, den Hires Modus im Zusammenhang mit Fließkomma-Mathematik zu bedienen und finde es befriedigend, die nativen Float-Berechnungen des C64 nicht nur grafisch, sondern auch als Text in den Hires-Modus zu übertragen. Per Joystick kann man ein kleines Sonnensprite über die Verlaufslinie in vollen Stunden-Zügen bewegen und die zugehörigen Höhenwerte werden angezeigt. Ja es ist nicht wirklich schnell, weil es für Fließkommazahlen keinen Basic Compiler gibt. Aber für Effizienz und Top-Komfort haben wir dieses Hobby schließlich nicht, sondern für den den Spaß an der Freude. Emulator-User drücken einfach Alt-W in VICE.
• Ich musste tatsächlich noch ein x=fre(.) einbauen, um regelmäßig die Garbage Collection anzustoßen. Wenn man sonst ca. 240x die Sonne bewegt, fängt der String Heap an, die Bitmap zu überschreiben. Das ist nun abgeklemmt.

Quellen:

Für die Sonnenstandsberechnung: https://de.wikipedia.org/wiki/Sonnenstand

Für die Wochentagsberechnung: https://de.wikipedia.org/wiki/Wochentagsberechnung

Für Sonnenauf- und Untergangsberechnung: https://lexikon.astronomie.info/zeitgleichung/

Letzte Anmerkung:

Sonnenaufgang und Sonnenuntergang werden anders berechnet als die Verlaufslinie. Während die Verlaufslinie präzise berechnet ist, werden Sonnenaufgang und untergang nach einem anderen, vereinfachten Verfahren berechnet, bei dem sich Abweichungen innerhalb von 5 Minuten ergeben können. Das führt mitunter dazu, dass man Sonnenauf- und Untergänge nicht exakt bei 0 Grad stehen hat und so wird es auch in den Graphen gezeichnet. Vergleicht man mit Sonnenstandsrechnern im Internet, findet man es aber ebenso vor, dass ein Sonnenauf/untergang bei -3 Grad Höhe liegt, weil er vermutlich einen ähnlich vereinfachten Algorithmus wie ich benutzt. Anderswho habe ich -0.8 Grad Höhe gesehenen, der rechnet vermutlich anders, aber ich habe nunmal den Algorithmus dafür nicht parat und eine Mondlandung muss man ja mit meinem Programm nicht planen können.

@ oobdo:

Schick. Was benutzt Du als Programmiersprache?

Auf den ersten Blick auf den Thumbnail dachte ich tatsächlich "Ach, mal wieder Excel - wie macht er das?"

@ sparhawk:

Vielen Dank für Deine Hinweise, und ja, sowas in der Art müsste ich dann eben manuell abfragen.

Die meisten Kommandozeilen-Tools sind da entsprechend eingabetolerant, ich hatte bloß gehofft, es gibt eine Art "eingebaute" automatische Hilfe beim Abfragen von Eingaben. In Python 3 kann man mit der Casefold-Funktion beispielsweise die Groß/Kleinschreibung ignorieren und sich einfach mal so eine Art Parser-Baukasten schreiben, den man dann immer wiederverwendet - da war ich dann zu bequem, weil außer mir wahrscheinlich kein anderer dieses Tool noch nutzen wird - aber wenn man etwas aus Prinzip richtig machen will, sollte man die Mühe eigentlich noch reinstecken. Werde ich machen, so wie ich dazu komme.

Hallo zusammen,

nutzt jemand von Euch ein iPhone und hat iCloud auf einem Windows-PC installiert?

Dann dürfte aufgefallen sein, dass im "Download"-Ordner Bilddoubletten liegen, falls man am iPhone über die Bearbeiten-Funktion ein Bild am Handy zugeschnitten oder farblich verändert hat. Im iCloud-Download-Ordner im Windows liegt das originale und das bearbeitete Bild nach der Synchronisation dann nach dem Schema IMG4711.jpg und IMG4711(Edited).jpg vor (IMG4711(Bearbeitet).jpg kommt gelegentlich auch vor). Auf dem Telefon selbst liegen nur die Originale und eine Konfigurationsdatei zu jedem Original mit Modifikationseinstellungen. In geteilten iCloud-Alben sieht man dagegen (in reduzierter Qualität und unter anderen generischen Dateinamen) immer das zuletzt veränderte Bild.

Mich interessieren aber die veränderten Bilder in hoher Qualität aus dem Download-Ordner. Ich brauche die Originale nicht. Wenn man nun eine Foto-Safari hinter sich hat, kann es viele solcher Doubletten geben, bei denen man die Originale nicht haben will (ich bin so jemand, ich bearbeite fast jedes Foto sofort im iPhone, um nicht hinterher an einem Rechner sitzen zu müssen um da nochmal jedes Bild anzulangen).

Um die unbenötigten Originale nicht mühsam von Hand aus dem Download-Ordner löschen zu müssen, habe ich ein Python-Skript geschrieben und mit py2exe in eine Win32-Exe umgewandelt, die auch unter einem 64Bit Windows 10 ausführbar ist.

So installiert und benutzt man das Programm:

1.) Die Zip-Datei in einen eigenen Ordner entpacken - da ist die Exe drin, eine Python-Bibliothek und eine .ini-Datei

2.) Die .ini-Datei öffnet man mit einem Texteditor und schreibt da den Pfad rein wo das iCloud-Downloadverzeichnis sich befindet. In der betreffenden Zeile muss worrtwörtlich

path = Pfad

stehen, d.h. nicht "path= Pfad" oder "path =pfad", ich fange solche Eingabevarianten nicht ab.

Auch auskommentieren ist nutzlos, wenn man mehrere optionale Pfade in der .ini-Datei führen will, darf der String "path = " nicht in der Zeile vorkommen.

Ich nehme einfach "# Pfad". Da kann anstelle des Hashes aber alles mögliche andere stehen, nur eben kein "path = " String.

Ich weiß nicht ob es eine Art "Standardystem" gibt, das einem das Parsen erleichtert. Auch Case-insensitives Parsen kennt Python 2.7 nicht (Version 3 aber schon, aber damit arbeite ich (noch) nicht.

3. Zieht die Exe mit der rechten Maustaste auf den Desktop, lasst sie da fallen und wählt "Verknüpfung erstellen".

Ich habe mir dann noch ein schönes Icon aus der Standard-Bibliothek für die Verknüpfung ausgesucht (rechte Maustaste auf die Verknüpfung -> Eigenschaften -> Anderes Symbol)

Beim Doppelklick geht ein Konsolenfenster auf und gibt Aktivitätsmeldungen aus. Gelöschte Dateien gehen in den Papierkorb, so dass sie wiederherstellbar sind. Achtung: ab dem Zielort wird rekursiv gelöscht, d.h. auch in allen Unterverzeichnis-Strukturen.

Also wer mag, gerne runterladen und auch benutzen.

Danke für die interessanten Beiträge.

Ich habe schon wieder einen Flüchtigkeitsfehler drin gehabt. In Posting #6 passt zwar der Wert n=100, aber in der Formel drüber steht noch 2,64 statt 2,61. Klar rechnet er den Geburtstag von Dierch-Jentz dann falsch.

Jetzt passt es. Den Code packe ich gelegentlich in das von Jeek optimierte Format.

Da ich Beitrag #5 nicht mehr editieren kann, ersatzweise ein Hinweis:

In Zeile 67 hat sich ein Bug eingeschlichen, es heißt nicht

67 z=val(yt$):n=1000:gosub 100

sondern

67 z=val(yt$):n=100:gosub 100

n muss 100 sein, sonst kann ich nicht auf 1901 oder 1801 abfragen. Klappen tut so nur 2001.

Ich habe aktuell keine Möglichkeit, ein PRG zu generieren, ich poste den korrekten Quellcode hier als Text.

Hallo zusammen!

Vielen Dank für das interessante Feedback und Jeeks Optimierung (ja, eigentlich weiß ich ja, was DATAs sind.. ).

Beim systematischen Testen von Daten fiel mir auf, dass mit der bestehenden Formel Wochentage um genau 3 verschoben sind (z.B. Donnerstag statt Montag), wenn das betreffende Jahr "rundes Jahrhundert + 1" ist und der angegebende Monat Januar oder Februar ist. Also, 1.1.2001, 15.2.1801, solche Werte. Ab 1.3. ist die Welt wieder in Ordnung, auch bei solchen Jahren.

Im Wikipedia-Artikel habe ich mich nach der intitalen Formel

gerichtet und nach empirischen Tests am C64 aus der 2,6 eine 2,61 gemacht, für den Modulo ein eigenes Unterprogramm beigesteuert (es ist eigentlich von Mike, nicht von mir) und in Ermangelung einer Gaußklammer (Floor)-Funktion einfach INT(wert) benutzt, da negative Werte, die man z.B. von -2,4 nach -3 "runden" muss, nie vorkommen.

Im Wikipedia wird zum Programmieren aber ein abgewandelter Algorithmus in der Sprache des Programms LabView empfohlen, der wahrscheinlich das von mir gefundene Problem schon behoben hat:

Ich wollte aber beim ursprünglichen Konzept bleiben und habe einen Workaround geschrieben. Sind also Daten betroffen wie 1901, 2001, etc. und der Monat ist Jan oder Feb, wird dies nun korrigiert. Wenn man das Programm austrickst und dreistellige Jahreszahlen einfach mit einer führenden Null erzwingt (z.B. 0901), dann weicht bei 0901, 0801 und Jan oder Feb als Monat der Wochentag systematisch um 4 statt um 3 Tage ab. Da hab ich jetzt nix mehr dran gemacht, obwohl es möglich wäre. Ich könnte theoretisch auch Wochentage vor dem Jahr Null berücksichtigen, aber eigentlich hat mich sowas interessiert wie "an welchem Wochentag ist dieses Jahr Weihnachten", "an welchem Wochentag hat meine Frau Geburtstag" oder auch "an welchem Wochentag fiel die Berliner Mauer". Das Jahr 1000 als vierstellige Grenze reicht mir.

Bitte findet anbei die gefixte Version mit Quellcode als Text. Wenn ich Zeit finde, baue ich die Änderung in Jeeks Code ein, bzw. wir versuchen es mal parallel und schauen, was hinterher schöner aussieht.

Dierch-Jentz

Vielen Dank für Deine Einsendung. Leider funktioniert das Programm nicht richtig. Ich habe die Daten 01.01.2001 und 31.01.2020 abgefragt und sie waren beide falsch. Wahrscheinlich funktionieren aber die 1980er und 1990er Jahre problemlos.

P.S.:

Das Zeitumstellungsprogramm funktioniert soweit ich überblicken kann immer richtig, da der hier gefixte Sonderfall bei der Zeitumstellungsberechnung nie eintritt. Betroffen sind davon ja die Monate März und Oktober, Januar und Februar kommen darin nicht vor, daher kommt es auch bei Jahren wie 2001, 1901, zu richtigen Werten.

Hallo zusammen,

ich habe mich in den letzten Tagen mit dem Thema Wochentagsberechnung und Terminberechnung für die Sommerzeit/Winterzeit-Zeitumstellung und der Umsetzung in V2 BASIC beschäftigt.

Grundlage ist der Algorithmus von Georg Gläser wie in Wikipedia beschrieben: https://de.wikipedia.org/wiki/Wochentagsberechnung

Kurioserweise musste ich den in der Formel enthaltenen Faktor 2,6 auf 2,61 ändern, damit V2 BASIC nicht bei manchen Monaten und Jahren Rechenfehler macht.

Für die Terminberechnung der Zeitumstellung frage ich beginnend ab Monatsende die Monate März und Oktober rückwärts zählend ab bis der erste (bzw. monatsletzte) Sonntag erreicht ist.

Ich habe den leisen Verdacht, der eine oder andere Forumleser hat noch viel kürzere, straffere und schnellere Programme zum Thema beizusteuern.

Weitere Beiträge oder auch Verbesserungsvorschläge zur bestehenden Lösung sind herzlich willkommen.