Ah, ach so!
Posts by Claus
-
-
CXX_ARGS = -D _POSIX -D WINDOWS -D WINDOWS64 -D WINVER=0x0A00 -D _WIN32_WINNT=0x0A00 -I $(WINDOWS_INCLUDE) -I /usr/local/include $(CXX_OPT_ARGS) $(CXX_DEBUG_ARGS) -std=c++17 -pthread
CXX_LIBS = -L /usr/local/bin -lcrypto-3-x64 -lssl-3-x64 -lws2_32 -static-libgcc -static-libstdc++
nehm ich...
Das geht? Ich sehe gar keinen Parameter, aus dem gcc schließen könnte, dass ein PE statt einem Elf-Binary erzeugt werden soll?
-
Zack, beides ist jetzt auf Bitbucket: https://bitbucket.org/ptv_claus/cc1541
-
Ob das 2.5V sein sollten weiß ich nicht, aber so grundsätzlich ist da ja eine Spannung zu erwarten, sonst würden die Potis ja nichts bewirken, oder?
-
Exzellent, so wünscht man sich Featurerequests, nur noch per Copy&Paste einbauen
! Den Output für -a noch ein wenig aufzuräumen hatte ich ohnehin auf meiner Liste fürs nächste Release 
. -
Also wenn dann formatieren (entweder mit der Originalroutine oder mit OpenCBM), die Disketten mit Fehlern aussortieren und dann neu schreiben. Wenn man auf eine zweifelhafte Diskette einfach nur neu schreibt, besteht die Gefahr dass Daten an einer Stelle landen, die fehlerhaft ist und dann ist es kaputter als vorher.
-
Moin, danke für das schnelle Lösen des Problems
! Da habe ich nie wirklich drüber nachgedacht, vielleicht sollte ich in der nächsten Version auch Großbuchstaben in den Hexstrings erlauben.
Anführungsstriche werden von der jeweiligen Shell verarbeitet, da habe ich leider keinen Einfluss drauf.
DirArt kannst Du übrigens auch automatisch extrahieren mit -a -
Beim Oktalsystem hätte man noch je einen Finger für Negativ- und Carryflag übrig
-
Ich glaube bei dem Zitat ging es nur um die Kosten eines "Runs", nicht um den Ausschuss des späteren Chips.
-
Nur wer im Dezimal-System erzogen wurde rechnet 'flugs' im Kopf rum.
Ich hatte mich auf ZeHa 's Post bezogen: wenn man 0x1000 als "viertausendsechundneunzig" aussprechen wollte, wäre das Umrechnen wohl unverzichtbar.
-
Das wäre natürlich der Knaller: hexadezimales Zahlensystem flächendeckend einführen, aber für die Aussprache muss man die Zahl im Kopf flugs in Dezimal umrechnen! Das würde zumindest die Kopfrechenfähigkeiten stetig trainieren, zu einer allgemeinen Erhöhung der mathematischen Intelligenz führen, und damit die Menschheit als Ganze einen Evolutionsschritt weiterbringen
! -
Das CBM-DOS hat aber ein großes Manko.
Es kennt keine Timestamps.
Das ist der Tod für jeden vernünftigen umgang mit Dateien in ein 'vernünftiges' OS.
Da sollte sich das eine oder andere ungenutzte Byte für im CBM-DOS Directory finden lassen, um das kompatibel nachzurüsten
Dann gibt es wieder Klagen, warum am OS vorbeikopierte Dateien alle den Zeitstempel auf 1.1.1982 0:00:00 zu stehen haben.
Wenn ich den Threadverlauf hier so anschaue, wäre das vermutlich einer der vergleichsweise weniger kontrovers diskutierten Gründe für Klagen
. -
Da sollte sich das eine oder andere ungenutzte Byte für im CBM-DOS Directory finden lassen, um das kompatibel nachzurüsten
Kompatibel zu den GEOS/CMD-Timestamps?
Entweder das (falls man sich davon etwas verspricht), oder ähnlich (eigentlich müsste man ja keine 5 Bytes dafür nehmen, 4 würden theoretisch reichen um 139 Jahre in Sekundenschritten abzudecken).
-
Solange das in CBM-DOS und FAT-formatierter SD-Karten abgebildet werden kann, gerne.
Aber bitte nicht wieder, wie bei GEOS, mit eigenem Dateisystem, das man sich von der "normalen C64-Seite" aus auf dem Datenträger zerschießen kann. Auch wenn ich mir bei den Apps zwei Welten (Legacy und NewOS) wünsche, so möchte ich das auf DOS-Ebene eigentlich nicht. Was ein neues OS aber auf seiner Speichererweiterung inkl. internem "Startlaufwerk" so treibt, kann mir, dem Kernal und CBM-DOS egal sein – das sieht eh nur das neue OS.Das CBM-DOS hat aber ein großes Manko.
Es kennt keine Timestamps.
Das ist der Tod für jeden vernünftigen umgang mit Dateien in ein 'vernünftiges' OS.
Da sollte sich das eine oder andere ungenutzte Byte für im CBM-DOS Directory finden lassen, um das kompatibel nachzurüsten
-
welchen tieferen Sinn sollte es haben einen Rotate Left-Befehl im (ursprünglichen) Design vorzusehen, aber keinen Rotate Right?
Also aus Programmierersicht sicherlich keinen. Sobald man über 8 Bit Arithmetik hinausgeht, will man eigentlich einen ROR-Befehl, und nicht die ohnehin lahme Berechnung durch 8 ROL-Befehle zum Schnarchtempo verlangsamen. Und wie sich das von androSID anhört, kann man die erforderlichen Elemente auf dem Chip von LSR wiederverwenden, das würde bedeuten dass auch die Chipkosten nicht signifikant kleiner werden, wenn man ROR weglässt (da bin ich aber weit außerhalb meiner Expertise).
-
Das Nachplappern von Fakten irgendwelcher "Faktenchecker" ist nicht "sich mit wissenschaftlichen Fakten und Theorien zu beschäftigen". Das wusste schon Kant:
Pfft, nur weil der das geschrieben hat heißt das ja noch lange nicht dass es stimmt
. -
Das Problem ist nicht die 5V Technik.Im meinem alten Sony Walkman sind meine ich nur zwei 1.5V Mignon drin und der bläst einem den Staub der Jahrhunderte aus der Ohrmuschel.
Ich meine, dass die Walkmen früher einen 12V DC/DC Konverter hatten. Heute laufen die Kopfhörerverstärker ICs mit 5V, oder womöglich sogar 3V? Auf jeden Fall sind sie alleine dadurch begrenzt im Pegel. Ok für heutige Stöpsel, aber zu knapp für insbesondere ältere Overears.
-
Gibts die auch irgendwo kompiliert ?
Ich wüsste nicht. Was ich mich aber viel eher frage: 2 Wochen später wurde halt die Versionsnummer im Headerfile auf 3.0 geändert. Der Unterschied zwischen der letzten 2.4 und der ersten 3.0 Developmentversion dürfte ansonsten eher marginal sein. Bis zum 3.0 Release war es ja dann noch eine lange Zeit. Was versprichst Du Dir von der letzten 2.4?
-
Es gibt noch ein Development Release V2.4.33, das 6 Wochen jünger ist:
-
Ne, ich denke Superingo meint, dass die Kopfhörerverstärker schwach auf der Brust sind. Die alten Portables hatten da wesentlich mehr Dampf als neue Geräte, die ja eher auf Stromsparen ausgelegt sind.
