Arbeitest du bei Microsoft? ![]()
Selbstbau 68k Rechner
-
Bogogil -
7. Juni 2012 um 13:40 -
Erledigt
Es gibt 386 Antworten in diesem Thema, welches 100.301 mal aufgerufen wurde. Der letzte Beitrag (
-
-
Vielen Dank Leute!
Naja, ich mach das irgendwie schon alles nebenbei, daher ist auch nicht alles so perfekt, wie es vielleicht scheint bzw sein könnte. Ich versuche dabei zwar, möglichst nah am Original zu sein, aber eine 1:1 Umsetzung wird es wohl nicht werden. Mal schauen, wie lange ich noch Lust hab, daran zu arbeiten. Meistens kommen mir recht schnell wieder neue Ideen... 
Ich arbeite bei Microsoft? Hä? Den versteh ich nicht.
Der Kiwi hat mehr als 640kb, bootet in ein paar Sekunden, hat kein MS Basic und die Entwicklung wurde bzw wird komplett unter Linux gemacht. 
Bogo
-
Echt tolle Leistung...Hut ab. Bitte bitte nicht für Microsoft arbeiten, Win7 war meine letzte Windows-Version und dabei bleibt es auch. Ich bin komplett auf Debian umgestiegen und würde dich viel lieber als Linux-Guru sehen. Du wärst perfekt um Hard- und Softwareprojekte mit Linux von 0 auf zu betreuen.
-
Ich kann auch nur sagen :
.
Ist eine tolle Leistung! -
Nochmals danke!

Du wärst perfekt um Hard- und Softwareprojekte mit Linux von 0 auf zu betreuen.
Hehe, ich glaube, eher nicht. Ich mache von allem ein bisschen, aber dafür dann nichts davon perfekt. Da würden nur alle die Hände über den Kopf zusammen schlagen, wenn sie sehen, was ich in ihrem jeweiligen Bereich abliefern würde.

Bogo
-
Ja, der Kiwi ist schon ein c

les Teil. Sowas hätte ich auch gern. Ein paar Gedanken/Fragen dazu:
Ich würde lieber einen 68000er nehmen (also richtig 16 Bit).
Der Grafikchip scheint ja recht gut zu sein. Aber der wird nur über einen 8-Bit-Flaschenhals mit der CPU verbunden. Das finde ich nicht so toll.
Ich kenne diese Problematik schon von den Grafikchip uPD7220. Es wäre schon besser, wenn die CPU auch direkt auf das VRAM zugreifen könnte.
Gerade für Demo's gibt es Effekte, die mit der CPU gemacht werden. Man müsste also zwischen der GPU und VRAM Multiplexer einfügen.
Das Problem ist dann sicher das Timing zwischen CPU und GPU. Die CPU-Zugriffe dürfen die GPU und die Bildschirmdarstellung nicht stören.
Als OS könnte ich das TOS2.06 von Atari anpassen. Das dürfte machbar sein, da ich das TOS schon auf dem Atari Jaguar zum Laufen gebracht habe. -
Hallo Dunkelwind,
danke für deine Anmerkungen. Den 68000er wird es allerdings in absehbarer Zeit im Kiwi nicht geben. Nicht, dass ich etwas dagegen hätte. Allerdings sprechen einige Aspekte dagegen. Ein durchgängiger 16 Bit Bus würde einige Änderungen im Design erfordern, welche nicht nur in erheblich mehr Platzbedarf auf der Platine enden würden. Sie ist jetzt schon recht groß (und dadurch teuer). Zudem bin ich nicht so blauäugig, dass ich glaube, das ohne Fehler im ersten Design hinzubekommen. Es würde mich in der Entwicklung um mindestens eine Iteration zurück werfen. Ich hab grad eine zweite Revision des Schaltplans in Arbeit, welche kurz davor ist, in ein neues Platinenlayout überführt zu werden. "kurz davor" = "nahezu alle Änderungen vollzogen". Den Status hat sie seit ca 6 Monaten. Es fehlt schlicht an der zur Verfügung stehenden Zeit. Oder um den Spieß umzudrehen: Es fehlt an Hilfe. Zudem geht "höher, schneller, weiter" immer noch ein Stück. Das Nächste wäre ein 68020 und DMA. Die Liste lässt sich beliebig erweitern.
Andererseits gehörte auch das damals dazu: Sich mehr Leistung zu wünschen, die man aber nicht hat. Damals lag es allerdings am geringen Budget als Schüler. Zumindest bei mir... Jedenfalls sehe ich in Limitierungen auch einen gewissen Reiz und eine Herausforderung.
Wenn ich die Gesamtleistung mit anderen Homebrew Computern vergleiche, kommt der Kiwi auch nur mit dem 68008 noch ganz passabel weg, denke ich. Das mag allerdings auch daran liegen, dass ich ursprünglich einen 8-Bitter bauen wollte und ich ihn aus der Perspektive betrachte. Für mich ist der Kiwi also eher ein aufgemotzter 8-Bitter, als ein verkappter 16-Bitter. Bin auch mehr im F64, als im A1K unterwegs...
Für Leistung nehme ich dann nenen R-Pi... 
Beim direkten CPU Zugriff auf das VRAM stimme ich dir zu. Das hab ich hier und da auch schon erwähnt. Bevor ich den Kiwi entwarf, baute ich eine Grafikkarte mit demselben VDP für einen anderen 68k Rechner. Diese Karte hatte die notwendigen Multiplexer. Allerdings hab ich sie damals nicht genutzt und beim Kiwi aus Platzgründen wieder entfernt. Mittlerweile ärgere ich mich darüber. Mit etwas Copy&Paste sind sie aber wieder da und falls ich mit ihnen die Platinengröße beibehalten kann, kommen sie mit in die Revision 2.
Danke für dein Angebot zu helfen. TOS hatte ich mir tatsächlich mal angeschaut und mich dann etwas näher mit EmuTOS beschäftigt. Das ist in der Tat eine interessante Option. Letzteres lässt sich vermutlich sogar relativ einfach schrittweise portieren, da man nicht notwendigerweise die GUI direkt mit portieren muss. Also, wenn du mit den Limitierungen leben kannst, bist du gern gesehen mitzuarbeiten.

Bogo
-
Hallo Bogogil,
Dein Projekt fasziniert mich immer wieder und ich bin schon gespannt, wie es sich mit der Zeit entwickelt. Leider habe ich von dieser Technik zu wenig Ahnung, als dass ich meine Hilfe anbieten könnte. Sollte Dein Rechner vielleicht doch irgendwann in Serienproduktion gehen, dann habe ich echtes Interesse. Bis dahin noch viel Erfolg und vor allem Spaß mit Deinem Projekt.
Gruß!
ThomBraxton -
Nochmals danke!

Hehe, ich glaube, eher nicht. Ich mache von allem ein bisschen, aber dafür dann nichts davon perfekt. Da würden nur alle die Hände über den Kopf zusammen schlagen, wenn sie sehen, was ich in ihrem jeweiligen Bereich abliefern würde.

Bogo
Hehe, so geht es mir in der Software-Entwicklung. Ich habe in so einigen Firmen gearbeitet und von allem irgendwo ein wenig gemacht und viel privat überall reingeschnuppert. Experte oder Profi bin ich in keinem Bereich, aber zum Geld verdienen hat es bis jetzt immer gereicht.Ich bewundere die Leute die ganz monoton bei einer Sache bleiben, ich kann das nicht. Genau wie ich nicht länger als 1-3 Jahre irgendwo arbeiten könnte, ich muss immer mal was anderes sehen und machen.
-
Diese Karte hatte die notwendigen Multiplexer.Hi Bogo,
kannst du mir mal den MUX-Schaltplan schicken? Bin mal gespannt, wie das gehen soll bzgl. Timing.
-
Hi Dunkelwind,
klar. Ich hoffe, man kann auf dem Bild auch etwas erkennen.
Bitte melde dich an, um diesen Anhang zu sehen.Eine Anmerkung muss ich dazu machen, wie ich grad sehe: Die Multiplexer teilen "nur" die CPU Adresse in zwei Häppchen für die VRAMs auf, welche Zeilen- und Spaltenadressen erwarten. Das Timing wird übrigens vom VDP selbst übernommen. Siehe dazu auch im Bitte melde dich an, um diesen Link zu sehen. Kapitel 13.3.7 (insbesondere Seite 93) und auf den Seiten 5 und 6 die Beschreibung der Signale *VMREQ, *VMBG und ASEL.
Auf der Grafikkarte sitzt ein GAL, welches zusätzlich zur Adressdekodierung diesen Handshake übernimmt. Wenn es eine VRAM Adresse erkennt, wird *VMREQ auf Low gezogen. Nun wartet das GAL und verlängert den Zyklus (*DTACK bleibt high) bis der VDP die VRAMS freigibt. Die Freigabe signalisiert der VDP, indem er *VMBG auf Low legt. Diese Signal enabled die Multiplexer. Ob "A" oder "B" der Multiplexer durchgeschaltet werden, steuert dann der VDP selbst über ASEL.Vorteil: Man braucht sich nicht um das Timing kümmern.
Nachteil: Es wird für jeden Zugriff ein Handshake gemacht, aber: man könnte direkt in einem Zugriff 16 Bit übertragen.Bogo
-
okay ..... wann geht das ding in serie ?
(zur not sammeln wir ein bisschen im forum 
) -
und verlängert den Zyklus (*DTACK bleibt high) bis der VDP die VRAMS freigibt.
Bogo
Wann darf die CPU ran? Nur während HBlank und / oder VBlank? Das wäre nicht so schön.
Gibt es dabei Bildstörungen?
Lohnt sich der MUX überhaupt für den 8-Bit-Datenbus des 68008? -
Dazu kann ich leider nichts sagen. Siehe auch mein vorheriges Posting:
Diese Karte hatte die notwendigen Multiplexer. Allerdings hab ich sie damals nicht genutzt und beim Kiwi aus Platzgründen wieder entfernt.
Ich fürchte, das muss einfach mal ausprobiert werden.Die Multiplexer würden sich allerdings auch bei 8 Bit lohnen. Nicht unbedigt aus Sicht der Geschwindigkeit, sondern aus dem Grund, dass man ohne sie nur indirekt auf das VRAM zugreifen kann. Hat man nun Programme, welche innerhalb einer Interrupt Service Routine und außerhalb auf das VRAM zugreifen, kann es zu Problemen führen.
Beispiel: Das Hauptprogramm möchte ins VRAM schreiben und setzt dazu nun die VRAM Adresse. Genau in diesem Moment gibt es einen IRQ und dessen Service Routine möchte nun ebenfalls aufs VRAM zugreifen. Sie setzt also ebenfalls die Adresse und schreibt bzw liest fleißig. Kehrt die Kontrolle zurück ins Hauptprogramm, hat dieses vom Verbiegen des indirekten Vektors nichts mitbekommen und schreibt bzw liest falsche Adressen.Bogo
-
Ich fürchte, das muss einfach mal ausprobiert werden.
Ja, würde ich gerne mal nachmessen.
Wo bekomme ich den V9990 und die VRAM's?
Ich habe nur ausländische Quellen gefunden, aber vielleicht hast du bessere? -
Den V9990 hab ich von Ebay und die VRAMs waren ein Restbestand bei Segor. Irgendwo im Kiwi-Forum gibt es einen Thread "Part suppliers", wo noch bessere (günstigere) Quellen aufgeführt sind. Musst du mal dort schauen. Allerdings sind die alle im Ausland.
Bogo
-
Also, wenn du mit den Limitierungen leben kannst, bist du gern gesehen mitzuarbeiten.
OK, und was kann ich konkret jetzt machen? Kiwi mit Bitte melde dich an, um diesen Link zu sehen.?
-
Jetzt grad gibt's wohl wenig, was du - zumindest auf Seiten der Software - machen kannst, so lang du keine Hardware hast. Du könntest aber demnächst (hoffentlich bald) die nächste Revision zusammen bauen. Dann könnte man direkt bei der ersten Bestellung zwei Platinen in Auftrag geben.
Mit den Jod-S11-Körnchen fütterst du besser Schlonkel.

Bogo
-
okay ..... wann geht das ding in serie ?
(zur not sammeln wir ein bisschen im forum 
)Wenn du das hier alles richtig gelesen und verstanden hättest, wüsstest du, das keine Serienfertigung geplant ist! Und nein, ich verstehe deinen ironischen Unterton...
Außerdem: da du ja ständig pleite bist, wovon möchtest du bitte spenden? :baby:
-
Jetzt lass' ihn doch

-