Ich meine den "Zumbitsu 8000".
LG
McT
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.
letzter Beitrag von t0m3000 am
Ich meine den "Zumbitsu 8000".
LG
McT
Jedoch fragte ich
mich warum bei dem meisten das Bild auf dem TFT´s nicht richtig eingestellt
war?
Da kannst Du lange fragen, denn es ist einfach nicht so. Wenn Du Probleme hättest, hättest Du Dich schon lange bei mir gemeldet, so wie das andere Kunden auch tun. Und wenn dann das Problem gelöst ist, meldet sich der entsprechende Kunde nicht mehr. Deine Tchnik "ich bn nicht der Einzige der das Problem hat", ohne das Problem zu benennen, funktioniert nicht.
Softwarestand von 2010? Mag sein (ich habe das letzte Update nicht mehr im Kopf). Tatsache ist, dass es keine offenen Supportfälle gibt. Also mit Verlaub: Ändere da etwas dran, oder halte Dich zurück. Es ist jetzt über eine Woche her, dass ich hier 'reingeschaut habe, und jetzt erinnere ich mich daran, dass ich eine Supportanfrage wegen Indivision ECS zu erwarten habe. Gekommen ist die aber nicht. Ergo ist das Produkt - und speziell Dein Exemplar - aus meiner Sicht fehlerfrei.
Jens
Okay, kannst Du dann eventuell auch einen C64-Moduladapter für den Expansionsport des C65 bauen?
Nein, da die Zielgruppe zu klein ist und mir Testequipment fehlt. Ich würde das aber als Auftragsarbeit machen, wenn Du vernünftige Specs formulierst (inklusive Testverfahren), und den üblichen Tagessatz von 1900,- EUR zzgl. MWST pro Projekttag bezahlst (Hinweis für diejenigen, die "Projekttag" nicht kennen: Man schafft selten einen Projekttag in einem Arbeitstag, und die Größenordnung geht stark runter, wenn man über mehr als ein- oder zwei Projekttage redet).
Genial fände ich es ja, wenn sich endlich mal jemand trauen würde eine Demo für den C65 zu programmieren.
Hat es auf der letzten Mekka in Fallingbostel gegeben. Damals wurden die Demos vor der Compo noch auf Video aufgezeichnet, damit es während der Compo keine Überrascheungen gibt. Der C65 war aber in der Wild und konnte nicht aufgezeichnet werden, weil diese Entry sehr spät eingereicht wurde, was aufgrund von recht wenigen Entries geduldet wurde (alles frei aus dem Kopf, ist schon was her...). Ich habe auf die Schnelle Adapter gebaut, damit er an den Bigscreen angeschlossen werden konnte. Leider erinnere ich mich nicht mehr an den Namen.
Allerdings hätte man das vielleicht etwas freundlicher sagen können.
Dein Ton kam in etwa rüber wie "ich will, dass Du Rechenschaft ablegst" - und das stößt bei mir sauer auf. Du bist Betatester und hast die Hardware zu einem stark subventionierten Preis bekommen. Da bist Du nicht in der Position, Rechenschaft zu fordern. Wenn ich das falsch verstanden habe, entschuldige ich mich hiermit dafür.
Jens
Es gibt seit ein paar Jahren eine Simulation auf Transistorebene. Könnte man das nicht relativ einfach nach VHDL portieren? Damit hätte man dann die perfekte 6502-Simulation, wenn auch vielleicht etwas sperrig, falls man dort mal was ändern will.
Die kennen wir natürlich auch, sie stellt aber keine wirkliche Hilfe dar. Es gibt ein "Transcript" in einen Schaltplan, das aber unvollständig ist, und an einigen Stellen sogar fehlerhaft. Um solche Details zu verstehen, müsste man einen komplett neuen Schaltplan zeichnen. Das wäre ganz sicher aufwändiger, als ein paar Testfälle zu kreieren, mit denen man die beeinflussenden Größen ermittelt. Die sind "gefühlt" noch überschaubar:
- I-Flag befingern
- RDY-Signal steht an oder nicht
Da wir nach einer Verzögerung des IRQ-Service um einen Takt suchen, und diese Verzögerung bei Branches "immer" gemacht wird, bleibt zu untersuchen, ob ein internes Flag, welches durch einen Branch gesetzt wird, eventuell ein paar Takte stehen bleibt, wenn RDY gezogen ist. Es würde aber auch helfen, wenn jemand erklären könnte, *warum* bei Ausführung eines Branch der IRQ-Service um einen Takt verzögert wird, denn auch das haben wir noch nicht herausgefunden. Den Effekt simulieren wir natürlich, aber es muss ja einen zwingenden Grund gegeben haben, warum das 6502-Entwicklerteam damals diese Entscheidung getroffen hat. Wenn wir diesen Grund kennen (und vielleicht auch den Mechanismus), dann können wir auch erklären, warum der Mechanismus außerhalb eines Branch getriggert wird (naja, zumindest ist das der aktuelle Erklärungsansatz).
Die Simulation eines solchen Testfalles auf Transistorebene würde nur dann neue Informationen ergeben, wenn wir sehen würden, wo die Verzögerung um einen Takt getriggert wird. Dafür bräuchten wir aber einen Testfall, der auf möglichst wenige Bedingungen reduziert ist. Wenn wir den aber haben, haben wir möglicherweise zwei oderdrei Parameter, die "an oder aus" sind, was man wiederum recht einfach in den VHDL-Quelltext einfügen kann als Fallunterscheidung. Will sagen: Sobald wir auf Transistorebene simulieren können was abgeht, können wir auch ohne Ergebnis der Simulation den Bug beheben. Klassisches Henne-Ei-Problem. Aus dem Grund konzentrieren wir uns auf das Erstellen von Testfällen, was halt Zeit kostet. Da meine Mitarbeiter ganz normale Angestellte sind, die irgendwann im Laufe des Jahres auch mal ihren Jahresurlaub abfeiern müssen, gibt es hin und wieder auch Pausen in der Entwicklung.
Jens
Es gibt ein "Transcript" in einen Schaltplan, das aber unvollständig ist, und an einigen Stellen sogar fehlerhaft.
Der MOS-Orginalschaltplan zum 6502 ist auch nicht fehlerfrei...
ZitatEs würde aber auch helfen, wenn jemand erklären könnte, *warum* bei Ausführung eines Branch der IRQ-Service um einen Takt verzögert wird, denn auch das haben wir noch nicht herausgefunden.
Es gab da mal eine Erklärung zu IRQs und Branches auf einer nichtöffentlichen Mailingliste, evtl. sind Teile davon inzwischen im Visual6502-Wiki zu finden. Wenn ich mich recht entsinne entsteht die IRQ-Verzögerung bei Branches deswegen, weil die Branch-Opcodes mit einer Optimierung implementiert sind um einen Taktzyklus zu sparen. Das sorgt dafür, dass sich der T-State, in dem auf einen anliegenden Interrupt geprüft wird um einen Takt verschiebt.
Die Wiki-Seite hier scheint ganz gut zu meinen Erinnerungen zu passen.
Um mal hier die Position von MiCv2 etwas zu stärken:
Ich lege bei meinem Indivision ECS auch Wert darauf, dass der immer im 50Hz Modus läuft (640x512 interlaced als Screenmode). Das ist so mit dem config tool eingestellt (1.0 mit oder ohne Graffiti, gespeichert für PAL mode). Mein Monitor zeigt dann auch 576p als Auflösung. Nur passiert es immer mal wieder, dass nach einem Kaltstart 62Hz ausgegeben werden. Das Bild ist dann auch in der Vertikalen etwas schmaler. Da hilft nur noch mal ausschalten und wieder an, bis der Indi wieder 50Hz ausgibt. Oder als Alternative das Config Programm starten und gleich wieder auf Quit drücken. Das kann dann auch ein paar Versuche dauern. Vielleicht kann da ja doch nochmal firmwareseitig etwas verbessert werden?
Ich wünsche mir einen Adapter, mit dem man fast alle USB Joysticks am C64 betreiben kann. So ähnlich wie der Mircomyse Mouseadapter. Das wäre so richtig Geil!
Im Thread für die neuen C64 Platinen wurde geschrieben, dass die 9V AC durch eine FET-Wechselrichterschaltung erzeugt werden.
Da fällt mir dann spontan der Wunsch ein, dass man sowas doch auch für die Originalplatinen machen könnte.
Ein Kästchen mit der FET-Schaltung das an den Original C64 angeschlossen werden kann, müsste doch für recht kleines Geld machbar sein.
Dann braucht keiner mehr Angst vor den alten Elefantenfüßen zu haben.
Evtl. müsste doch auch ein 9VAC Netzteil mit Gleichrichter und 2 Widerständen funktionieren, oder?
Was ich mir noch wünschen würde wäre irgendeine Beschleunigung für CF-Karten am Amiga!
Sowas wie den IdeFix-Express, nur eben für CF-Karten, falls sowas überhaupt möglich ist...simpel und einfach für eine Karte und kompatibel mit anderen Erweiterungen wie Indivison - TrueIDE Express
Um mal hier die Position von MiCv2 etwas zu stärken:
Ich lege bei meinem Indivision ECS auch Wert darauf, dass der immer im 50Hz Modus läuft (640x512 interlaced als Screenmode). Das ist so mit dem config tool eingestellt (1.0 mit oder ohne Graffiti, gespeichert für PAL mode). Mein Monitor zeigt dann auch 576p als Auflösung. Nur passiert es immer mal wieder, dass nach einem Kaltstart 62Hz ausgegeben werden. Das Bild ist dann auch in der Vertikalen etwas schmaler. Da hilft nur noch mal ausschalten und wieder an, bis der Indi wieder 50Hz ausgibt. Oder als Alternative das Config Programm starten und gleich wieder auf Quit drücken. Das kann dann auch ein paar Versuche dauern. Vielleicht kann da ja doch nochmal firmwareseitig etwas verbessert werden?
Guten Abend,
Dankeschön das Du das geschrieben hast
Genau das ist mein Problem...
MiC
Edit: Was Wiesel mir da geschrieben hat, ist eine Beleidigung der untersten Intelligenzstufe!
Schön das er überhaupt noch was schreibt.
Edit: Was Wiesel mir da geschrieben hat, ist eine Beleidigung der untersten Intelligenzstufe!
wäre da jetzt vorsichtig! wiesel ist hier ein teil des forums - support sachen gehen über seine firma und sind dort zu benennen!!!
Und trotzdem ist er manchmal gern dabei anderen die Schuld zu geben (siehe auch WHDLoad und die ACA 500+ACA 1220 Kombination = angeblich Wepls Problem, durch WHDLoad bedingt. Was dieser aber auf Anfrage so auch nicht bestätigen konnte). Soll kein Vorwurf sein, da hier oft nur viel gelabert wird im Forum. Und zwar voll allen.
Trotzdem scheint die Indivision Konfigurationssoftware (nicht die Hardware) ja bekannte Probleme zu haben. Würde also auch nur konkrete Testfälle an den offiziellen Support schicken, hier macht das keinen Sinn.
Beschwerden über den Produktsupport oder über die Qualität bestehender Dinge bitte direkt an Wiesel an der dafür vorgesehenen Stelle.
Das ist nicht der richtige Thread für evtl. Beschwerden. Hier soll es um zukünftige Produkte gehen.
Ein Chameleon mit HDMI Ausgang wäre toll. Dann gibts auch keine Probleme mehr mit dem VGA Ausgang. Aber dafür sicher neue bei der realisierung des HDMI Signals.
Beschwerden über den Produktsupport oder über die Qualität bestehender Dinge bitte direkt an Wiesel an der dafür vorgesehenen Stelle.
Das ist nicht der richtige Thread für evtl. Beschwerden. Hier soll es um zukünftige Produkte gehen.
Zum Thema Micv2 und Wiesel:
Ich gehöre auch zu der Gruppe, die das Bild bei einer MK2 nicht richtig eingestellt bekommen haben. Und ich habe den Support kontaktiert - was darin endete, das Jens mir sinngemäß sagte, die MK2 sei darauf ausgelegt möglichst jeden Pixel in top Quali anzusteuern und nicht upzuscalen, das wurde auch so angekündigt und falls etwas anderes gewünscht, auf MK1 zurückgreifen."
Gut, der Thread hier ist irgendwie falsch, das stimmt definitiv - andererseits ist es irgendwie blöd/sinnlos, als Einzelperson mit dem Support zu streiten was gut oder schlecht, richtig oder falsch ist.
Ich war mit dem nur zu ~75% ausgenutzten Bild auch nicht zufrieden - muss aber dazusagen, das danach noch irgendein Screenmode-Update herauskam und ich all die Möglichkeiten nicht weiter verfolgt habe, das Bild vielleicht besser bzw. bildfüllender+zentrierter zu bekommen. Dazu kam das mein Amiga in höheren Auflösungen flackerte, da musste ich mich erst drum kümmern - dann Trennung, Umzug, und seitdem steht ein neuer Amiga im Schrank (der auf weitere Tests wartet).
Aber den Support kontaktieren hat mich in dem Fall nicht viel weiter gebracht.
Ich kann Dich schon verstehen, aber wenn es nicht um neue Dinge gehen soll, dann bitte in einem anderen Thread, nicht in diesem hier.
Um den Thread mal wieder zurück zu bringen zum ursprünglichen Inhalt:
Ich würde mir ein Sprach-Ausgabe-Modul mit dem SSI-263AP für den C64 wünschen,
das sowohl über den IEC-Bus, als auch RS232 (oder USB via Wandler) angesteuert werden kann.
(Eine zusätzliche MIDI-Schnittstelle könnte es evtl. auch für Retro-Musiker interessant machen!?)
Ich selbst habe an sowas schon gedoktert... aber meine Kenntnisse im entflechten von Leiterplatten
sind einfach nicht mehr ausreichend.
Ja, vielleicht könnte man ein Laptop Gehäuse verwenden, das es einfach so zu kaufen gibt.