Das mit dem Gefrierfach werde ich mal ausprobieren. Kann man die auch einschicken uzm Reaprieren? Kennt da wer einen Shop?
Posts by sparhawk
-
-
Ich habe so das Gefühl als wenn die Platte noch ein wenig zuckt. Die andere Platte ist eine SSD, die sollte man ja nicht hören. Ich höre aber immer diese typsiche Klackern wie von einer Festplatte. Das kann ja eigentlich nur die sein. Und eben dieses Merkwürdige Biepen immer wieder zwischendurch.
-
Beim Booten merke ich schon dass es nicht funktioniert, weil er bei Initialisieren recht lange braucht. Also scheint er zumindest zu glauben dass da was sein könnte, denn er versucht es halt ein paarmal. In Windows ist sie dann eben nicht vorhanden.
Was mir auch aufgefallen ist, dass ich seitdem manchmal zwischendurch so einen merkwürdigen kurzen Bieper höre wenn ich in Windows bin. Weiss nicht ob das damit zusammen hängt.
-
Kann ich das irgendwie eingrenzen um die Ursache zu ermitteln? Bin kein Elektroniker, daher sind meine Fähigkeiten begrenzt.
Gestern Abend lief sie noch. Beim Runterfahren hat es allerdings ewig lange gedauert, ich denke mal da hat sie schon was gehabt.
-
Ich habe in meinem Laptop 2 Festplatten drin. Diese schmalen Dinger die aussehen wie eine grosse Streichholzschachtel. 1TB und 2TB. Die grössere der beiden gibt keinen Mucks mehr von sich. Irgendeine Idee ob man die vielleicht wieder antreten kann oder wie man an die Daten kommen könnte?
-
Man braucht gar nicht tippen. Es ist alles komplett mausgesteuert.
Das einzige was mich nervt ist, dass ich für jeden Pixel in dem 8x8 Raster vier Pixel in meinem 16x16 Raster malen muß.
In welchem Format speicherst du das denn ab?
-
Du willst die Zeichen jetzt ernsthaft Pixel für Pixel abmalen?
Wenn du in Access einen Grafikeditor programmieren kannst, warum dann nicht eine Import-Funktion die ein Grafik-ROM einliest?
Hmm. Ziemlich verrückt, oder?
Ich glaube ich muß nochmal darüber nachdenken. Mit der Datei von Bit Shifter oder mit der Excel-Datei von andi6510 müßte sich Import-mäßig etwas anfangen lassen.
Andererseits, wenn ich das von Hand mache und jeden Tag ein Zeichen erstelle, dann habe ich 255 Tage lang Spaß.
Das kann man mit einem einfachen Programm in Null komma nichts machen. Man braucht ja nur jedes Pixel statt einmal, zweimal ausgeben.
-
Hallo. Ich suche den C64 Zeichensatz in einer goßen Darstellung, in der man jeden einzelnen Pixel erkennen kann, so wie in dem Bild. Aber für jedes Zeichen von CHR$(0) bis CHR$(255). Hintergrund ist, dass ich die Zeichen des kompletten Zeichensatzes in einen von mir erstellten Grafikeditor auf dem PC von Hand übertragen möchte. Gibt es da etwas Fertiges, das einigermassen übersichtlich ist?
Mir ist nicht ganz klar was du genau machen willst. Aber im C128 Intern S.800 ff. ist im Anhang eine vollständige Übersicht. Das kann man als PDF problemlos runterladen.
-
Mit meinem Docking komme ich nur in homeopathischen Dosen weiter. Dafür komme ich aber mit meinem C128 Projektrecht gut voran. Ich habe jetzt gestern eine Inputroutine fertiggestellt, auf der Basis des Codes den ich geschrieben habe um Tasten abzufragen. Damit habe ich jetzt ein paar flexible Funktionen mit denen ich alle Usecases abdecken kann.
Mehrere Tasten abfragen für ein Spiel, einzelne Tasten abfragen, oder auch Tastatur mit Repeatfunktion abfragen wie man sie halt für eine Bildschirmeingabe braucht. Und jetzt auch eine Inputroutine mit der man Texte eingeben kann und bei der man auch flexibel Tasten filtern kann, so dass man z.B. nur Zahlen eingeben kann, oder nur Hex oder was auch immer man genau braucht. Das Schöne daran ist, dass diese Funktionen alle systemunabhängig sind. Daher funktionieren die genauso auch auf dem C64 oder dann auch auf dem MEGA65. Wenn ich also mit dem C128 Projekt fertig bin kann (und werde) ich das dann auch auf den MEGA65 mit relativ wenig Aufwand portieren.
Die eigentliche Tastaturabfrage braucht nur minimalste Änderungen die vermutlich nur einen Parameter ändern müssen. Die anderen Funktionen bauen darauf auf und sollten dann auch ohen Änderungen funktioneren. -
Die Möglichkeit, dass compiled BASIC generell vergleichbar schnell wie handgeschriebener Assembler Code ist, ist am C64 nicht gegeben.
Auch auf keinem anderen System.
-
Compiler Hersteller prahlen seit Anbeginn der Zeit, dass ihre Compiler besseren und schnelleren Code erzeugen, als der Durchschnitt-Coder mit handgeschriebenem Assembler hinbekäme
da muss es schon ein sehr schlechter ASM Programmierer sein.
Es muss einem halt klar sein, dass ein Compiler ein generisches Tool ist. Wen ich meinen Code genau auf mein Problem zuschneiden kann dann wird das immer die schnellere Lösung sein. Deshalb kann ein generisches Tool nie besser sein als Handcoded. Wenn einem der Overhead egal ist, dann hat natürlich so ein Tool Vorteile, aber es kommt immer drauf an was man erreichen will. -
Für gute Sachen kommst nicht an Assembler vorbei.
Aber was soll ich mich beklagen, bei einem Selbstgespräch werde ich vom Gegenüber immerhin verstanden.
Tja, wenn du lieber in einer Blase lebst, kann dir das keiner verbieten. Ausserhalb musst du halt Fakten akzeptieren.
Ein C128 erscheint mir als komfortablere Entwickler-Platform für sowas wie TP4 da schon deutlich geeigneter als der C64 (C65/Mega65 sowieso).
Wenn der C128 reichen würde, warum dann nicht auch der MEGA65? Weil es da die Software nicht gibt?
-
sparhawk Muß ja nit zwangsweise Multitasking sein. Für 8-Bit System reicht auch Taskswitching.
Öhm... Das IST Multitasking.
Ich habe bei vielen Posts hier das Gefühl, dass etlichen die Hardware vom C64 eigentlich reicht, aber es am Basic hapert. Warum nicht “einfach” eine neue Programmiersprache/Betriebsystem für den Cevi ?
Der C64 ist einfach zu langsam. Für gute Sachen kommst nicht an Assembler vorbei.
-
Kein Multitasking.
Multitasking in der Form wie es auf dem Amiga gibt, geht auf dem C64 genauso.
64KB sind halt etwas knapp für mehrere tasks, aber technisch geht das problemlos. -
Ich hatte solch ein Projekt ja auch mal angefangen, hab aber auch ganz alleine recht schnell die Lust daran verloren - das kann auch passieren
Ich auch.
War ja eine nette Idee, aber wenn man bedenkt was man dafür alles braucht. Erstmal muss an die Hardware entwickeln (als Emulator). Dann hat man keinerlei Entwicklungswerkzeuge, also bräuchte man Minimum einen Assembler. Und dann müsste man natürlich die ganzen Werkzeuge implementieren. Entweder ein BASIC oder irgendeinen Compiler portieren oder ähnliches. Jedes einzelne Teilstück davon ist schon eine grosse Aufgabe für sich.Und dann stellt man sich die Frage. Für wen macht man das? Kaum jemand wird das wirklich verwenden, weil es einfach viel zu Nische ist.
-
I still hope that more computers can be sold in the next months and years - we, as Mega65 owners, need a big user base for best software supply. Maybe a MiSTer core would also help.
There will be no "big user base". Considering that there are still 700 remaining for order after the initial fans had taken their shot, I wouldn't hold my breath. Getting it on a core from some more widely distributed hardware might indeed help a little though, but you still should have no expectation of "lots of software".
-
A MEGA65 is a different computer, and you get a high-quality case and a high-quality keyboard and a disk drive.
I find this argument quite tiresome. NOBODY buys a computer because it has a high-quality keyboard or high-quality-case no matter how much it is repeated. Nobody ever bought the C64 because he thought "Oh! That's such a high-quality product it will still run in 30 years."
What do you do with a high-quality keyboard`? You type on it. Just like on a cheap one.And if the cheap one breaks, you get a replacement.
So if you want people to buy it, you can focus on the hardware power, the good BASIC or whatever, but certainly not on the quality of a single piece of it.
-
Äh, sieben Spritebewegungen gleichzeitig sind flüssig genug, und das Armageddon sind dann die einsparbaren Verzögerungsschleifen? Was für ein Jammer-Niveau ist das denn. (-;
Dass ich keine Verzögerungschleifen mehr einbauen konnte bedeutet im Umkehrschluss dass ich keine Rechnpower zur Verfügung habe um irgendwas anderes zu machen, ausser den paar Sprites herumzubewegen. Also ja, das ist durchaus ein Grund zu Jammern. Zumindest wenn man auf BASIC angewiesen wäre. War für mich auch mit ein Grund damals dass ich BASIC eigentlich nie wieder angegriffen habe weil ich es nutzlos fand.
-
Ich habe mal versucht, sowas aehnliches mit 3 oder 4 Sprites zu programmieren. Das war schon ein "Schneckenrennen". Wenn da jetzt noch Spiellogik dazu kaeme, dann gute Nacht. Also das "flotte" BASIC-Spiel fuer den C64 will ich erst noch sehen, bisher sah ich da nix was auch nur annaehernd einem simplen Arcade-Spiel nahekommt.
Ich hatte früher mal sowas wie einen Introscreen basteln wollen. Als ich aber die 7 Sprites über den Bildschirm bewegen wollte brauchte ich schon keine Verzögerungsschleife mehr so lahmarschig war das.
-
sparhawk; Vielen Dank für die ausführliche Erklärung. Habe es jetzt einigermaßen verstanden. Hoffe ich.
Ich habe gestern noch bemerkt dass sich da ein Fehler eingeschlichen hatte, weil ich das falsch verstanden hatte. Ist aber nur ein kleines Detail, das jetz tnicht wesentlich was ändert. Die Register auf $ff01-$ff04 sind Register die die Auswahl aktivieren, soweit korrekt. $ff00 ist aber ein Schreib-/Leseregister. Man kann da also das Register $D500 verändern wenn man es beschreibt (um z.B. neue Konfigurationen zu ermöglichen). Wenn man in $ff01-$ff04 schreibt, dann wird der vorbelegte Wert in $d500 kopiert und aktiviert. Also ist eigentlich nur $d500 das "echte" Register mit dem auch eine Konfiguration aktiviert wird. Das hatte ich gestern bemerkt als im ROM Listing nochmal was nachgesehen hatte.
Wie gesagt ist für die grundsätzliche Beschreibung nicht ganz so wichtig und wollte es nur der Vollständigkeit halber erwähnen falls du das ausprobieren willst. Jedenfalls kann ich dir "128 Intern" empfehlen von Data Becker, da ist das recht gut beschrieben und gibts auch als PDF zum Download.
Also wenn du einen FPGA entwickelst und dir Gedanken machst wie man Banking implementieren könnte, dann wäre das sicher eine recht gute Methode.
