Wenn sysinfo vergleichbare Werte liefert, aber die Grafikausgabe arg ruckelt, könne irgendwas bzgl. GPU Config bei dem Pi4 komisch sein?
Pimiga2 auf meinem Pi400 ist alles out-of-the-box smooth und eher etwas zu schnell…
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
Wenn sysinfo vergleichbare Werte liefert, aber die Grafikausgabe arg ruckelt, könne irgendwas bzgl. GPU Config bei dem Pi4 komisch sein?
Pimiga2 auf meinem Pi400 ist alles out-of-the-box smooth und eher etwas zu schnell…
… aber gleich zwei Pi4 mit gleichem Verhalten… thermal throttle könnte ich mir auch vorstellen.
Das ist aber seltsam…
Huch ? Das konnte ich in diesem Thread nirgends lesen. Aber wenn es so ist, kann man es natürlich so machen.
Dann macht es m.E. auch keinen Sinn einen ungepimten 500er zu emulieren sondern gleich nen 1200 mit 2 MB Chipram unsw.Ich habe das in Post#21 erläutert. Da steht auch warum ich keinen A1200 emuliere. Ich kriege das, trotz aller Bemühungen, auf einem RPi4 nicht hin.
Aber ein A500+ ist für meine Zwecke schon in Ordnung.
Vielleicht mal eine für Amiga Emulation angepasste Distro probieren: Pimiga 2 oder AmiKit XE
Warum soll man da einen nutzlosen Border haben?
Um evtl. ein bisschen Chip-Ram zu sparen ?
Was egal ist, wenn das Spiel die WB zu macht oder gleich das ganze System übernimmt.
Desweiteren reden wir hier bei moderatem Overscan von 720x280 von gerade mal 4,6 KB pro Bitplane.
Beim normlen WB-Modus mit 4 Farben also von 9,2 KB.
Hier wurde schon Interlace vorgeschlagen, was bzgl. breiter Texte gar nichts bringt und mehr Chip-RAM frisst.
Man kann auch einen Text Reader benutzen, der einen eigenen Screen aufmacht, zum Beispiel in overscan monochrom. Eventuell dann noch mit einem Font der etwas schmaler und proportional ist. dann kann man den Text lesen und mach ihn wieder zu bevor das Spiel gestartet wird.
und wer meint, unbedingt das letzte Quentchen Chip-RAM Sparen zu müssen, der sollte mit allen Intuition-Ressourcen vorsichtig sein: Icons, Gadgets, Menus, Windows - fast alles braucht zusätzliches Chip.
Ich dachte die Rede ist von echtem A500 OCS. Also nix Euro72, Dblpal etc. Am Pi kann man natürlich ECS/AGA, 1-2 MB Chipram und auch RTG haben…
Ohne overscan und mit systemfont...
Mit Overscan habe ich bisher noch nicht experimentiert. Ich könnte mir vorstellen, dass da noch etwas mehr Bildschirmbreite geht. Ich glaube bis zu 724 x 283 kann man da rausholen.
Ich versuche aber immer in der Workbench möglichst alles auf den Standard-Einstellungen zu belassen weil ich nicht weiss, wie sich das sonst später auswirkt.
Was soll denn passieren? Die Spiele machen ja i.d.R. die WB zu und eigene Screens auf.
Ich habe schon früher - und heute wieder - mit dem A500 Overscan genutzt. Warum soll man da einen nutzlosen Border haben? Mit flachen LCDs macht das noch weniger Sinn als früher mit gewölbtem CRT.
man kann auch die GPU übertakten, afair sind 750 MHz ok
Ein fake A500 mini macht mich nicht so an, ein maxi schon eher. Aber ich habe mir jetzt mal „TheMouse“ bestellt - vielleicht fühlt sich ein MiST mit Tank-Mouse authentischer an - rein haptisch.
Man muss versuchen, das Positive zu sehen, oder? Nur, was genau ...?
Omikron war gar kein Atari ST BASIC. Es war ein Virus!
RetroGames Ldt.? Sind das nicht Briten?
Ist es dann nicht ihrer patriotischen Pflicht geschuldet, möglichst schnell "The Colossus - Maxi" zu bringen?
Neben Knuth hier ein echtes Rex-Zitat: „Buggy compiler optimization is the biggest evil.“
Zuetzt hatte ein Kollege mit Rekursion + Inlining bei clang/llvm extreme Probleme. Auf x64 lief es wie erwartet, auf GPU (NV Pascal über bc->ptx Backend) hat es Quatsch gemacht. Unser Compilerbauer vom Dienst meint einen Bug in den llvm low-level Optimizern des ptx Backend gefunden zu haben. Um den zu reporten müsste er aber einen minimalen Reproducer ohne realen Code von uns erstellen. Aber wie so oft: mit toy code funktioniert alles.
Um selbst zu fixen fehlen Knowhow und Zeit. So bleibt nur Workaround mit forcenoinline etc.
Semikolon kann man in C genauso leicht vergessen, wie in Pascal. Aufgrund der nahezu kontextfreien Syntex ist Pascal aber meist in der Lage, genau an der Fehlerstelle den eigentlichen Fehler zu melden, statt wie C (und schlimmer noch C++) erst Quatsch zu interpretieren und dann viele Zeilen später eine irreführende Fehlermeldung zu bringen.
Hmm? (Qt Creator mit clang-Codemodel, clang selbst würde beim Compilieren die gleiche Fehlermeldung ausspucken)
Vielleicht ist clang etwas schlauer, vielleicht ist es Glück, weil gleich dahinter ein Schüsselwort kommt...
Meine Erfahrung mit msvc und gcc ist aber eher, dass der Compiler sehr leicht verwirrte Fehlermeldungen liefern kann. Kommt natürlich auch darauf an, wie sehr der Code verwirrende Features nutzt. Aber gerade mit template metaprogramming habe ich leidergottes erleben dürfen, dass kleinste Syntaxfehler zu ellenlangen, völlig unleserlichen Fehlermeldungen führen.
Im schlimmsten Fall ist das die Art von Code, die auch Intellisense Amok laufen lässt (ich glaube bei VS2012 gab es auch mal eine Phase, wo Intellisense dann Unmengen RAM fraß und bei 2GB abschmierte).
Und klar: die Verfechter von "modern C++" werden nun einwenden, dass dies mit "Concepts" in C++20 Schnee von gestern sein wird, und wenn nicht dann in C++2x und man solle ja auch nicht ewig an einem veralteten msvc kleben, und MS hätte ja noch nie gute C++ Compiler geliefert, etc.pp.
Doch die Welt dreht sich bekanntlich nicht nur um die neusten und tollsten C++ Standards und Compiler und es gibt noch einiges an Abhängigkeiten, die Upgrades ausbremsen. Und mal ehrlich: viel scientific code ist immer noch FORTRAN 77/90 und Banken haben noch COBOL auf Mainframes laufen. Das Zeug tut was es soll und wird noch lange bleiben. Und genauso wird es noch lange "orthodox C/C++" Code geben. Und ob der wirklich schlimmer oder doch besser ist als "modern C++" darüber können Theoretiker IMHO ewig streiten. Tatsache ist: das Zeug existiert und verschwindet nicht. Und die Probleme bleiben auch und werden nur von neuen Problemen ergänzt oder überlagert.
Ich habe einen Minimig mit dem alten PIC, mit dem ARM Board für Minimig kenne ich mich nicht aus. AFAIR erlaubt das mehr virtuelle Floppies und ein HDD Image?
Alles anzeigenHallo zusammen,
ich habe hier noch meinen alten Rev 1.1 Minimig rumliegen und wollte den mal wiederbeleben. Jetzt hab ich hier im Forum schon etwas rumgesucht, werd aber aus ein paar Sachen nicht ganz schlau...
Um die Verwirrung komplett zu machen, habe ich wohl irgendwann ne SD-Karte gebraucht, so dass ich nicht mehr nachschauen kann, was ich an Files alles brauchte...
Aus der Erinnerung war das ein Core File und ein Update File für den ARM Controller...? Jetzt zu den Sachen wo ich nicht ganz schlau draus werde: Ich habe hier Foreneinträge zu einem AGA Core gefunden... Ist dieser AGA Core nur für den Mister, oder kann ich den auch auf meinem Minimig nutzen ?
Wäre schön, wenn mir jemand sagen könnte, wo ich die aktuellsten Files für den Minimig her bekommen kann und ob für mich eben dieser AGA Core nutzbar ist.
Hi Snocksman,
das erinnert mich daran, dass ich auch vor einer Weile meinen ACube Minimig wiederbeleben wollte, und es dann nach dem Urlaub ganz vergessen habe.
Hatte in diesem Thread von AW182 den Tipp bekommen, dass es bei somuch.guru noch Cores für den original Minimig gibt.
AFAIR gab es auch mal einen experimentellen AGA Core für den Minimig von einem Jakub. Glaube aber der wurde nie ge-open-sourced und das was man heute als MinimigAGA findet, sind halt die AGA-Amiga Cores für MiST/SiDi/TC64 und Mister. Es ist leider etwas verwirrend, dass die Amiga Cores für neuere Retro-FPGAs Systeme auch "Minimig" genannt werden ( wobei es historisch natürlich ok ist, weil sie eben daraus entstanden sind).
Für mich war es als Kind schon Magie, dass da ein Bild auf dem Fernseher zu srhen war, das aber eben kein Fernsehen war, sondern ein Fenster in eine imaginäre Welt. Und diese Welt kann man beeinflussen, man kann mit ihr interagieren und im Idealfall selbst erschaffen. Das hat mich eigentlich immer noch mehr gereizt, als nur damit zu „spielen“. Für mich war Computer-Grafik von Anfang an eine starke Triebfeder.
Und so sehr geflasht,wie die ersten Begegnungen mit Atari VCS, C64 und dann Amiga, haben mich dann nur noch die ersten bezahlbaren VR-Brillen vor 4-5 Jahren.
Internet und WWW fand ich z.B. 1994 ganz nett und potenziell nützlich, aber richtig umgehauen hat es mich nicht. Die schnell WeiterEntwicklung lief ja über Jahre und erst ab 2000 war es unverzichtbares Massenmedium mit iel Inhalt und Nutzen. Aber die erste smtp mail war halt auch nicht spannender, als die erste Datex-J Mail (bei mir erst ca.1992/93).
Strukturie. Proggen hätte man auch mit Basic erlernen können und wenn schon nicht Basic, warum nicht gleich in die Vollen gehen und auf C gehen.
Unvergesslich: Das Semikolon am Ende der Zeile vergessen
Semikolon kann man in C genauso leicht vergessen, wie in Pascal. Aufgrund der nahezu kontextfreien Syntex ist Pascal aber meist in der Lage, genau an der Fehlerstelle den eigentlichen Fehler zu melden, statt wie C (und schlimmer noch C++) erst Quatsch zu interpretieren und dann viele Zeilen später eine irreführende Fehlermeldung zu bringen.
Preprocessor Macros sind auch ein Antifeature. Goto ebenso.
Und die meisten BASICs waren damals viel zu primitiv, um strukturiert zu programmieren.
In Grunde sind C und Pascal austauschbar - beide von Algol 60 abgeleitet und mit vergleichbaren Features. Pascal hat halt die sauberere Syntax (ist ja eine Lehrsprache von einem Compilerbauer) und C einige hardware-nahe Features ( es sollte ja ein OS damit geschrieben werden ).
Wer mal logische Programmierung in Prolog oder was rein funktionales machen durfte, wird schon bestätigen, dass die Unterschiede zwischen C und Pascal nicht so groß sind, und es auch deutlich abstrakter geht.
Ich muss mich korrigieren: der PD Raytracer, mit dem ich ca. 1989 zuerst gespielt habe, war nicht der POV-Vorläufer DKBTrace, sondern es war DBW-Render.
Wer den probieren will, braucht auch nicht unbedingt einen Amiga (oder Emulator), denn auf github gibt es einen Windows-Port davon.
Bei uns in RLP gab es in der 10.Klasse ITG := 'Informations-technische Grundbildung'. War zwar nur - AFAIR - nur ein Halbjahr ungefähr eine Wochenstunde, aber schonmal recht brauchbar, für Leute die sonst so gar nichts mit Computern am Hut hatten.
Stoff war:
Gemacht hat das vorwiegend der Mathelehrer (den ich später im Stamm-Kurs Physik hatte). Der hat selbst viel programmiert und allen Interessierten auch im Matheunterricht kleine Programmieraufgaben gegeben.
Ich glaube es kam gut an, denn sehr viele haben dann in der 11.Klasse auch Informatik gewählt. Es gab zwar nur einen Grundkurs - und den konnte man auch fakultativ belegen - aber es war eine bunte Truppe - auch mit Leuten, die zuhause keinen Homecomputer hatten oder vorher nie was programmiert haben. Also nicht nur Freaks.
Da ging es dann mit Pascal mehr in die Tiefe und auch etwas Assembler am Schluss. Und natürlich die üblichen algorithmischen Grundlagen und Datenstrukturen.