Beiträge von darkvision

    Die Bügelbefestigung für die Spacetaste ist totaler fladderkram. Hab einen Teil auf das Blech geklebt, weil das sonst überhaupt nicht halten würde. Trotzdem fällt da alles auseinander sobald man die Taste mal von der Seite anfässt.

    Sieht das so aus? (Von der RF-Seite)

    space.jpg



    Das Problem mit der Space-Taste hatte ich auch - bis ich draufgekommen bin, dass die Halterungen am MechBoard selbst verkehrt herum eingesetzt waren. Die kann man recht einfach rausnehmen und umdrehen. Dann hält die Space-Taste problemlos.

    Guter Tipp!

    Ich habe auf Ebay jemanden gefunden, der die exakt gleichen Stempeln (gleiche Machart) verschickt und habe dort gleich mehrere Sets bestellt (was man hat, hat man :thumbsup: ).

    Muss ich mal schauen, evtl. bestelle ich mir da auch ein paar Sets, damit ich ggf. die Tasten austauschen kann... Ein solcher Adapter ist mir schonmal beim ziehen der Tastenkappen abgebrochen...

    Das Problem ist, das die Dinger total verdreht sind und dadurch die Tasten krumm und schief sitzen und bei erstbester Gelegenheit auch wieder abfallen.

    Interessant... das scheinen dann ja selbstgemachte Adapter zu sein. Bei der Sammelbestellung zu den MechBoards hier im Forum wurden damals auch Adapter mitgeliefert, die haben hier bei vier aufgebauten Tastaturen alle gepasst. Abfallen tut da nichts, im Gegenteil, die bekommt man kaum mehr runter.


    Vom Entwickler des Mechboards selbst gab es ja eine STL-Datei für die Adapter... hab gerade auf dessen Website nochmal nachgeschaut. Evtl. schlechter Druck?

    Das nächste ist die Space Taste. Anstatt das ganze 3 € Teurer zu machen und links und rechts einen unbeschalteten Cherrykey zu setzen, hat man es geschafft die Bastellösung von Commodore zu "verbessern". Es ist fast unmöglich die Taste vernünftig auf das Board zu bekommen.

    Meinst Du jetzt diese Drahtbügel-Geschichte? Das ist aber bei allen Mechboards so... die haben alle nur einen Switch in der Mitte. Auch im Hucky-Board-Update gibt es nur eine Taste. Bei meinen Boards funktioniert das mit den Bügeln problemlos. Und ich arbeite ja mit der Tastatur...


    Ich vermute das auch das BlingBoard64 und die BlingBox so gemacht werden... zumindest die Adapter fallen dort weg.


    Schade das bei den RF-Mechboards es da so Probleme gibt...

    Ich kann damit aber auch nicht viel anfangen – zu grelles Blau (global änderbar?

    Zu Anfang scheint der Blickwinkel auf den Bildschirm ungünstig zu sein, oder der Monitor ist sch... hat aber nichts mit dem OS zu tun. Zum Ende hin sieht man ja eine andere Darstellung und da sehen die Farben besser aus.

    und diese ganzen Effekte, too much von allem.

    ... das gab es schon vor 10Jahren unter Linux (COMPIZ-Windowmanager). Kann man abschalten.


    Vor Jahren hab ich das auch mal getestet, manche Effekte sind ganz nice, aber mit der Zeit nervt es nur weil es einfach Zeit kostet. Kann man aber alles abschalten. Der tester war davon ja fasziniert... für mich ist das ein alter Hut und schon längst wieder aus der Mode ;)

    Es wirkt halt wie irgendwas, was ein Fan zusammengebastelt hat, ohne Sinn und Verstand, null professionell.

    Da hat jemand nur alle möglichen Effekte aktiviert. Sogar Sounds beim öffnen der Fenster. Ja, das geht auch unter Windows, aber dort nervt ja schon der StartUp-Tune das man sofort alle Sounds abschaltet. Und das sollte man da auch machen. Wenn man die Effekte wegnimmt bleibt vermutlich nichts anderes übrig als bei einer aktuellen Linux-Distro... mal abgesehen davon das ggf. der VICE-Emulator per default mitgeliefert wird (wenn auch ohne ROMs und schlechter Standard-Konfig ohne Sound).


    Das System baut hier auf MXLinux auf (wenn ich den Kommentar im Video richtig verstanden hab) und das kann man ja im virtuellen PC installieren und testen. Wenn ich mir da ein paar Screenshots von anschaue sieht das alles "Normal" aus... also ist das CommodoreOS eher "overtuned"... kann man aber sicherlich alles anpassen.

    Eigentlich ist es ja Quatsch, sich zu "wünschen" Irgendwelche Funktionen/Einstellungen zu Verlangsamen :platsch:

    Das hatte ich schon ende der 1990er Jahre für die SuperCPU berücksichtigt und sogar in MP3 eine extra Routine für Anwendungen integriert (heißt bis heute SCPU_Pause). Die Frage ist immer nur was ist noch OK und was ist dann zu langsam. Das ganze funktioniert aber nur auf realer Hardware, da die TOD-Clock dazu verwendet wird. Bei SuperCPU/TC64 läuft die noch genau, bei VICE im Warp-Modus nicht mehr. Daher funktioniert das unter VICE nicht.


    Wenn ich dann da noch ein Update rausbringen sollte, dann bitte Screenshots von den Dialogen posten, wo es evtl. zu schnell geht. Die Dateiauswahlbox zähle ich nicht unbedingt dazu, da es hier verschiedene Möglichkeiten zur Navigation gibt. Es geht also nur um Programme aus dem MP3-Release. Und auch nur in Verbindung mit SuperCPU oder TC64.

    Wäre mal interessant ob die auch Fehler in TopDesk behoben haben. Hier hatte ich ja auch mal unter GEOS65 getestet und zumindest zwei Bugs gefunden.

    OK... nach ein paar Stunden hab ich es wieder geschafft XEMU zu installieren, mit passendem ROM und JoyPort-Emu (weil zu Beginn erstmal der Joystick aktiv ist). Zumindest der C=+9-Bug ist noch vorhanden...


    Hinweis: Am PC unter Linux STRG+ALT+9 drücken... das simuliert C=+9


    Was mir auffällt: Der Mauszeiger (C=1351) bewegt sich relativ langsam... kann aber auch an XEMU liegen...


    40/80Z-Anwendungen (für C128) führen nach der Rückkehr zum DeskTop ggf. zu seltsamen Auflösungen:


    Das ist halb 40Z und halb 80Z...


    Mir reicht das schon wieder... liegt aber eher am XEMU... ich werde damit einfach nicht warm... :nixwiss:

    Mal schauen, vielleicht mache ich aus dem AVI nochmal eine Bildergalerie mit Stück für Stück Anleitung.......... :)

    Da frage ich mich:

    Wenn Du eh schon Step-by-Step das ganze vorbereitest um es als AVI zu speichern, warum schreibst Du dann nicht die einzelnen Schritte Step-by-Step herunter? Dann kannst Du dir den Upload eines riesigen Videos sparen, das sowieso nicht alle Schritte erklärt.


    Du:

    - Siehe Video


    Ich:

    - Starte VICE

    - Einstellungen aufrufen

    - Laufwerk 8: CMDHD

    - Image für Laufwerk 8: <name.dhd>

    - Laufwerk 10: CMDFD

    - Image für Laufwerk 10: <name.d4m>

    - C64-Modus

    - LOAD"BCOPY+",10

    - RUN

    - F1 bis CMD-FD <ENTIRE DEVICE>

    - F5 bsi CMD-HD

    - F7 bis "Size: 3:..." (Ziel-Partition)

    - C für COPY, RETURN zum starten


    Du meinst evtl. das Dein Video hilfreich ist... aber versuch doch einfach mal selbst an Hand Deiner Beschreibung oder dem Video das nachzustellen. Ohne Dein CMD-BASIS-Wissen...


    Dein Slogan ist ja "Ein Video sagt mehr als tausend Worte"... ich sage aber: 100 Worte helfen mehr als so manches Video...


    Ich bin jetzt hier raus, mit VICE 3.7 hab ich noch nie gearbeitet... (siehe Thread-Titel)

    Es fehlt aber das D64 mit bcopy+ ...

    Ich glaube nicht........:whistling:


    Du siehst... ich tue mich schon schwer mit den Zips... da wird es einem Entwickler nicht anders gehen. Und das Testprogramm findet sich auf einer Partition im dhd... das steht nirgendwo. Und dann muss ich das DHD auch als Target nehmen... ich hab das jetzt über try&error nachvollziehen können:

    Code
    1. x64sc -default \
    2. -drive8type 4844 \
    3. -8 "test für fd_ok.dhd" \
    4. -drive9type 4000 \
    5. -9 13056bl-3264kb-product.d4m \
    6. "test für fd_ok.dhd":bcopy+

    Dann F1 für FD=Entire Device, dann F5 für HD und F7 für Part#3, dann C für Copy. Nach RETURN bleibt der Kopiervorgang hängen...


    Die Schritte bis dahin sind aber nicht selbsterklärend. Bin mal gespannt ob der Entwickler das nachvollziehen kann wenn er selbst nicht oder nur selten mit CMD-Produkten arbeitet.

    Mal schauen, ob da mit meiner Meldung jemand was anfangen kann. Habe mein bestes gegeben, incl. Filmchen und Testdateien.....:)

    Einfacher wäre es noch Test-Images bereitzustellen mit einem D64 der CopyTools und dann die Konfiguration für VICE 1:1 anzugeben (Also welches Laufwerk ist was für ein Typ).


    Wenn ich das richtig sehe müsste der Entwickler erstmal ein HD-Image mit ForeignPartitions erstellen, dann ein FD4-Image mit Partitionen, bevor er das testen kann. Und dann muss er noch das Programm suchen was Du da verwendet hast. Das Video ist zwar Nice, aber eine Step-by-Step-Anleitung was der Entwickler machen muss um den Fehler zu reproduzieren ist hilfreicher: Im Video sieht man z.B. ja nicht welche Tasten Du drückst...


    Ansonsten muss ich sagen das ich das noch nichtmal auf realer Hardware getestet hab. Allerdings stehen FD2+HD noch auf dem Tisch... wenn man nur mehr Zeit hätte...

    Ich sollte vielleicht noch anmerken, das man dieses Problem im Basic nicht hat. Alle meine Programme nutzen die Maus und da läuft das einwandfrei.

    Das kann schon sein, evtl. hängt aber auch damit zusammen wie GEOS die Mausabfrage ausführt. Joyride "zuckelt" am C64+TC64 auch nicht.


    Das ist also kein generelles Problem von Turbo-CPUs. Ich vermute eher das GEOS selbst zu schnell abfrägt und da daher ab&zu auch "falsche" Werte interpretiert, die dann eine Bewegung vorgaukeln, auch wenn keine da ist. Dann springt der Mauszeiger hin und her. Zumindest unter GEOS64 reicht es aus den Takt temporär runterzutakten. Auf die normale Performance von GEOS hat das keine Auswirkung, das bleibt im TurboModus.


    Wäre mal interessant ob die auch Fehler in TopDesk behoben haben. Hier hatte ich ja auch mal unter GEOS65 getestet und zumindest zwei Bugs gefunden.

    Ich habe das gerade über den Freezer versucht auf 1 MHz zu stellen. Keine Verbesserung.

    Es sieht so aus als wenn GEOS neu startet. Datum und Uhrzeit sind dann auf Werkseinstellung (20.04.1988 /13:00 Uhr).

    Nach (F) dann mit F3 wieder zurück führt einen RESET aus?


    Wenn dem so ist, dann kann man das wohl nicht so einfach testen und man müsste den Maustreiber "aufbohren". Meine GEOS64-Treiber schalten dazu zu Beginn auf 1MHz runter, lesen die Maus-Bewegungs-Register aus, führen die Bewegung aus und schalten danach den Takt wieder zurück.


    Da Du ja auch ein TC64 hast: Starte doch mal ein "originales GEOS 2.0"... an meinem C64 springt der Mauszeiger auch hin und her. Wenn man dann eine RAMDisk-öffnet, ins TC64-Menü wechselt und Options/TurboSettings/Off wählt und dann zu GEOS zurückkehrt, dann ist der Mauszeiger nicht mehr so hektisch.


    Wenn das verhalten dem vom Mega65 ähnelt wäre es einen Versuch Wert dem Team den Tipp zu geben. Ob es was bringt ist was anderes...

    Ich komm von Desktop nicht ins Basic. Ich weiß das es in anderen GEOS Versionen möglich ist. Aber hier gehts anscheinend nicht, oder ich übersehe da etwas.

    Geht das nur vom BASIC aus? Man kann nicht über ein Mega65-Menü den Takt ändern? Das hab ich aus dem UserGuide kopiert:


    Das (F)REQ sieht so aus als könnte man mit F die Frequenz ändern...

    Der Mauspfeil zuckt sehr stark. Vor dem booten hat eine Rückstellung auf 1 MHz nichts gebracht.

    GEOS scheint automatisch auf 40MHz hoch zu schalten. Das Verhalten ist bei NTSC und PAL gleich.

    Die Frage war ob es sich bessert wenn man im laufenden GEOS-Betrieb auf 1MHz umschaltet.


    Beim TC64 z.B. geht das über das Menü und dort war das zittern dann weg. Ein Fix im Maustreiber unter GEOS64 hat das Problem dann vor ein paar Jahren behoben. Der gleiche Fix hat das Problem schon vor 30Jahren mit einer SuperCPU unter GEOS64 behoben...


    P.S. Das ist nur ein Verdacht, wenn das runtertakten nichts hilft ist das Problem evtl. ein anderes... dann bin ich hier raus ;)

    Bei mir verschwindet das Zittern nach zwei, drei Whisky...

    Nur zur Info: Das war eine ernstgemeinte Frage, denn mich erinnert das Verhalten an die Anfänge der SuperCPU und dem TC64 mit GEOS64, da zittert die Maus auch relativ stark. Dann wäre die Lösung relativ einfach...

    Ich kann im Turbomodus am TC64 die Größe der Partition einer Nativeramdisk nicht vernünftig einstellen. Es geht viel zu schnell.

    Gratulation! Du hast das EasterEgg-Game "Set NativeSize" gefunden ;)

    Es geht mit etwas Übung, man darf halt nicht zu lange klicken. Ich mach das am TC64 ja regelmäßig zum testen...


    Ich hab trotzdem mal etwas geändert und von GDOS64 zurückportiert:


    Das >> ist ein SingleKlick-Icon und setzt die nächste 1024K-Größe, /\ und \/ wurden etwas verlangsamt (1/10sec)...


    Ich muss das noch etwas testen, hat aber keine hohe Prio (es funktioniert ja mit etwas Übung), d.h. ich werde deswegen jetzt nicht sofort ein neues Update bereitstellen...


    Guter Punkt, das muss ich am U64 auch mal ausprobieren, würde mich nicht wundern, wenn es da genauso ist.

    Kannst Du Dir aus zwei Gründen sparen:

    1. Wird das mit 40Mhz definitiv genauso bzw. noch viel schlimmer sein...

    2. Ist das U64 mit TurboFirmware auf der schwarzen Liste, also "Not supported"... also selbst wenn es mit dem Update immer noch "schwierig" (aber nicht unmöglich) ist die korrekte Größe einzustellen, wird es für die Ultimate keinen weiteren Fix dafür geben.