Frühmorgendlicher Stand: Alle mal probesitzen bitte. An dem Osc Ausgang des 74HCT14 liegen 2.6V an, scheint also zu oszilieren ("Owon" Oszi ist noch irgendwo zwischen China und BRD unterwegs....). Reset tut auch was es soll, sogar mit Beleuchtung. Wird langsam eng, die nächst größere Platine hätte es auch getan. Denke mal eine Handvoll LEDs drüber verteilen, die Signale anzeigen bringt es nicht, man würde nichts sehen außer Glimmen. Die blauen Kingbright die ich hier habe sind auch mit 100uA zufrieden. Inzwischen ist auch der Eprom Brenner eingetroffen. Glaube wenn ich mal den Löffel abgebe können sie bei der Testatamentsveröffentlichung ein EPROM mit meinem letzten Wunsch auslesen, stilgerecht :-) Der schwierige Teil kommt ja noch ....
Angehängte Dateien:
-
DSC08146__1600_x_1200_.jpg
260 KB
A. K. schrieb: > Zilog Z80 = 1976, MME U880 = 1980. Bisschen spät für nützliche Info von > MME zu Zilog. Abgesehen davon wars nicht lizenziert. Das lief so um 1990 und da war der Z80 noch nicht so altes Eisen wie er heute ist. > > Mit Reproduktion über geklaute Masken wärs voll kompatibel, nicht bloss > beihnahe. Ja, wenn man die Daten unverändert einfach so übernimmt, nicht wenn man sie überarbeitet und an die eigene Technologie anpaßt. Dabei verschwinden u.U auch Dreckeffekte... Gruß, Holm
Holm Tiffe schrieb: > A. K. schrieb: >> Holm Tiffe schrieb: >>> Das ist einfach nicht wahr. Sämtliche Befehle waren implementiert, auch >>> die undokumentierten. Die CPUs verhielten sich absolut identisch. >> >> Wikipedia: "Die Unterschiede beschränken sich auf spezielle Details wie >> ein nicht gesetztes CY-Flag bei dem OUTI-Befehl." und "The U880 is an >> almost identical copy of Zilog's 8-bit Z80 microprocessor. Differences >> include absence of CY flag setting in OUTI command (when L goes zero) >> and another behaviour of hidden bus register seen through undocumented >> F3 and F5 flags." >> >> Quellen werden dort leider nicht genannt. Muss folglich als unbestätigt >> gelten. Es ergibt in exakt dieser Formulierung auch keinen Sinn, denn >> laut Zilog Doku lässt OUTI das C Flag unverändert. > > Ich glaube das der Wikipedia aber nicht und halte das für Unfug. > Es wäre auch ein ziemlicher Quatsch mit Sowas bei sonst identischem > Befehlssatz einen Prozessor inkompatibel machen zu wollen, meinst Du > nicht. > > Egal. Ich werde das mal aufgreifen und bei www.robotrontechnik.de > diskutieren. Das sollte sich relativ leicht verifizieren lassen. > Ich denke eher das sich das oben beschriebene Verhalten um steinalte > Bugs in den ersten Masken gehandelt hat, auch bei Zilog. Jemand hat dann > sozusagen 2 verschiedene paar Schuhe verglichen. > > Gruß, > > Holm kaiOr vom robotrontechnik Forum hat das ausprobiert: "Hallo, habe meinen Frickel-KC85 offen auf dem Tisch (schon viel zu lange). Weiß nur nicht ob meine MC-Kenntnisse reichen um das sauber nachzuweisen: Quellcode: MODIFY 2000 21 FF FF -- LD HL,0FFFFh 01 80 01 -- LD BC,0180Ah 37 -- SCF ED A3 -- OUTI D2 00 F0 -- JP NC,0F000h 76 -- HALT go 2000 UA880D -> HALT UB880D -> HALT Z0840004PSC -> Kaltstart Z084C0010PEC -> Kaltstart SGS Z8400AB1 -> Kaltstart Lasse ich SCF weg bzw. ist zuvor CY nicht gesetzt gibts mit allen CPUs Kaltstart. Wie kann ich den anderen Unterschied mit F3 und F5 testen? MfG" Es ist tatsächlich so, das sich der U880 an die spezifizierte Funktion hält und die Zilog und SGS Teile nicht. Das heißt für mich das MME da einen Fehler gefunden und behoben hat, nicht ur den Originalchip 1:1 gecloned. Gruß, Holm
Holm Tiffe schrieb: > Ja, wenn man die Daten unverändert einfach so übernimmt, nicht wenn man > sie überarbeitet und an die eigene Technologie anpaßt. > Dabei verschwinden u.U auch Dreckeffekte... Im Wikipedia Artikel zu Mostek wird ein kleiner Spass aufgeführt, den Zilog mit Mostek angestellt haben soll. Und zwar soll Zilog denen Daten für den Chip geliefert haben, die gezielt die Ausbeute reduzieren. Vielleicht als neue Revision getarnt, als Zilog bereits eine eigene Fertigung hatte.
Holm Tiffe schrieb: > Es ist tatsächlich so, das sich der U880 an die spezifizierte Funktion > hält und die Zilog und SGS Teile nicht. Das ist ja nett. Zu den F3/F5 Flags siehe http://www.z80.info/z80sflag.htm. Die sind meist eine Kopie von Bits 3 und 5 vom Ergebnis der ALU.
Holm Tiffe schrieb: > Das lief so um 1990 und da war der Z80 noch nicht so altes Eisen wie er > heute ist. Ab 1990 dürfte es nicht mehr so einfach gewesen sein, einen unlizenzierten Nachbau zu verkaufen. Dass es zu diesem Zeitpunkt Kontakte zwischen MME (oder was daraus wurde) und Zilog gegeben hat, ist sehr gut vorstellbar.
Hallo, schon 1986 war mir durch meinen Schwager (studierte damals Elektroniktechnologie) bekannt dass der Z80 einige Bugs im Bereich der Flagbehandlung aufwies. Ebenso war bekannt das MME diese Bugs beim U880 soweit bekannt behoben hat. Ich hätte hier noch "Datenbuch. Mikrorechnerschaltkreise Kramer, Würtenberger ISBN 3-327-00633-0 01600 aus 1988 bei Bedarf kann ich gern nachschlagen was interessie. Der U880 wie auch seine Peripher ausgiebig erläutert, inclusive Timingdiagramme. Namaste Das Thema kam damals in Zusammenhang mit dem ZX Spektrum OS auf, wo einige Klimmzüge notwendig waren ebenso gab es undokumentierte Opcode welche nicht releast wurden. Soweit mir bekannt waren sie Maskenfehlern zum Opfer gefallen ???
Winfried J. schrieb: > Das Thema kam damals in Zusammenhang mit dem ZX Spektrum OS auf Passt ins Bild. Derjenige, der in der englischen Wikipedia die Information über die Unterschied einpflegte, bezeichnet sich nämlich als "ZX Spectrum programmer from Russia."
Ich habe indessen auch noch ein bisschen gegoogelt, die Russen selbst sind der Meinung das Ihre Z80 Versionen eigentlich alle U880 sind, das heißt das sie entweder mit den MME Masken und deren Technologie produziert worden, oder was ich annehme nur in Russia verkappt worden sind. Ich habe indessen mehrfach gelesen das es in der DDR Engpässe beim Verkappen gab (wo gabs die nicht?), die Jield Raten der Chips selbst waren wohl verhältnismäßig gut. Es würde mich deswegen nicht wundern, wenn fertige Wafer in die "sozialistischen Bruderstaaten" exportiert worden wären. Gruß, Holm
Georg G. schrieb: > Der MCS48 war zu seiner Zeit nicht schlecht. Der wiederum als bereits verbesserte Version der damals sehr erfolgreichen F8 Familie von Fairchild verstanden werden kann. Die im Original einen recht eigentümlichen Aufbau hat, weil Mehrchip-Lösung. Dass Intel von ein paar ausgebüxten Fairchild-Leuten gegründet wurde, war sicher reiner Zufall. ;-)
A. K. schrieb: > Holm Tiffe schrieb: >> Es ist tatsächlich so, das sich der U880 an die spezifizierte Funktion >> hält und die Zilog und SGS Teile nicht. > > Das ist ja nett. Naja, auch jeder heute erhältliche Chip hat ein Datenblatt und dann Ein Errata Sheet. Teilweise ist letzteres relativ statisch auch über Maskenversionen hinweg, z.B. bei TI MSP430Gxxxx. Wenn der Chip in Massen Produziert und verkauft wird, scheint der Leidensdruck zur Fehlerbehebung nicht mehr sehr hoch zu sein. Anmerkung: Die Russen haben jede Menge PDP11 Prozessoren gecloned, VAXen auch. Wenn man sich die Teile näher an sieht, stellt man fest das "Clone" da eigentlich das falsche Wort ist. Die Russen ahben PDP11 kompatible Prozessoren entwickelt für die es nie ein Original gab. Auc der erste VAX Mikroprozessor war ein VAX11/750 "Clone", Kenner der Materie werden realisieren das es niemals einen VAX Mikroprozessor in der 11/750 gab, das war im Original alles TTL Gemüse.. Ich habe eine russische PDP11/03 .. oder ähnlich, ein richtiges Original gibts auch da nicht. Das Teil heißt Elektronika E60, (Aus meiner Sicht ist das das Selbe wie Lehmann 60 oder Müller 60, alles bei den Russen heißt Elektronika) Das Ding hat einen QBUS mit metrischen Abmessungen und für die Teile auf der Rrozessorplatine gibts auch keine Originale. Das Ganze wurde dann in ein Gehäuse gebastelt das von außen einer 11/03 wie ein Ei dem anderen ähnelt.. komische "Clone", oder nicht? Ein Bild gibts hier, man sieht die 3 üblichen Schalter-Paddels rechts an der Front: http://www.tiffe.de/Robotron/PDP-VAX/E60/CPU-oben.jpg Die schweinchenrosa Chips links sind K565RU1A, das Equivalent zum I2107, 4Kx1 DRAMs. Die PDP11 Geschichte ging so weit, das die einen Sharp Taschenrechner gecloned haben, nur außen selbstverständlich. Im Inneren werkelt eine PDP11 CMOS CPU. gabs nie bei DEC: http://oldcomputermuseum.com/elektronika_mk85.html Ich habs probiert, eine russische 256KW Speicherplatine arbeitet mit Steckadapter auch in einer originalen 11/23. > > Zu den F3/F5 Flags siehe http://www.z80.info/z80sflag.htm. Die sind > meist eine Kopie von Bits 3 und 5 vom Ergebnis der ALU. Ich habe einen Link auf diesen Fred hier ins Robotrontechnik Forum gesetzt, Kai kann sich dann austoben.. Gruß, Holm
A. K. schrieb: > ausgebüxten Fairchild-Leuten Wobei Fairchild seinerseits heftige Anleihen bei Olympia Büromaschinen gemacht hat.
Zu den IN/OUT-String Befehlen und dem Carry Flag steht rein zufällig was auf einer Spectrum Seite. Wor sich auch zeigt, dass es nicht sonderlich geschickt ist, sowohl ein Register C als auch ein Flag C zu haben. ;-) http://www.worldofspectrum.org/faq/reference/z80reference.htm
Hallöchen, so, was kann man noch an "Retro-Ware" dazu bauen? Eine einfache Taktkontrolle habe ich in Form einer glimmenden LED, so dass ein Taktausfall direkt sichtbar wird. Einen AD Wandler auch, 4 Ports, von denen einer mit 7 Segment bestückt wird (oder Arduino 8-fach Anzeige mit MAX ....). Das Auge isst mit und ein Holzkasten mit Plexiglasplatte drüber kommt auch noch.
Holm Tiffe schrieb: > Mikroprozessor in der 11/750 gab, das war im Original alles TTL Gemüse.. Ich las mal, dass in der 750 damals brandneue programmierbare Logik drin steckt, vermutlich PALs.
Holm Tiffe schrieb: > Ein Bild gibts hier, man sieht die 3 üblichen Schalter-Paddels rechts an > der Front: > http://www.tiffe.de/Robotron/PDP-VAX/E60/CPU-oben.jpg Und was ist das da rechts? Die Hochspannungsstufe für die Anoden der Endstufenröhren? Oder das Kühlaggregat? :-) >>Immer noch kein Interrupt ADC => STI? Uuuups.....
A. K. schrieb: > Ich las mal, dass in der 750 damals brandneue programmierbare Logik drin > steckt, vermutlich PALs. Die mit den PALs war die 730. In der 750 steckten Gate Arrays. Das einzige reine S-TTL Grab war die 780: http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/EG-21731-18_VAX_Product_Sales_Guide_Apr82.pdf
Christian J. schrieb: > Und was ist das da rechts? Die Hochspannungsstufe für die Anoden der > Endstufenröhren? Oder das Kühlaggregat? :-) Linearnetzteil und Kühlpropeller, scheint mir.
Christian J. schrieb: > Uuuups..... Und ich bin nach wie vor sehr sicher, dass du NMI nicht offen lassen willst.
Christian J. schrieb: > Denke mal eine Handvoll LEDs drüber verteilen, die Signale anzeigen > bringt es nicht, man würde nichts sehen außer Glimmen. Deswegen gibt es Einzelschrittschaltungen wie die weiter oben gezeigte. > Der schwierige Teil kommt ja noch .... Hier noch ein praktischer Tip: die CPU auf einen Zwischensockel stecken, der die 8 Datenleitungen vom restlichen System abtrennt und fest auf GND legt. Die CPU liest jetzt permanent 0x00 = NOP, was dazu führt daß sie permanent immer im Kreis durch ganzen Adreßraum läuft. Mit Logikprüfstift / Oszi kann man jetzt die Adreßsignale, Chipselect etc. an den diversen Punkten der Platine prüfen. Man findet so relativ leicht Kurzschlüsse und Unterbrechungen. Und wenn man einen Logikanalysator hat oder sich mal ausleiht, kann man auch Adreßdecoder & Co prüfen. XL
Axel Schwenke schrieb: > Man findet so relativ leicht Kurzschlüsse und Unterbrechungen. Und wenn > man einen Logikanalysator hat oder sich mal ausleiht, kann man auch > Adreßdecoder & Co prüfen. > > > XL Ok, mache ich.. eine Logikanalyzer 8 kanal habe ich hier .... und den Zwischensockel baue ich mir gleich mal. By the way: Reicht die Treiberleistung von CMOS aus, um gegen einen 10k Pull Up anzukommen am NMI? Ich weiss jetzt nicht aus dem Stehgreif, in wieweit da die Spannung runterkommt, um den NMI zu "ziehen". Bis später, Christian
A. K. schrieb: > Christian J. schrieb: >> Und was ist das da rechts? Die Hochspannungsstufe für die Anoden der >> Endstufenröhren? Oder das Kühlaggregat? :-) > > Linearnetzteil und Kühlpropeller, scheint mir. Das Netzteil ist ein Sekundär-Schaltregler und dann sind da noch 4 Lüfter. Das mit den Gatearrays in der 750 ist mir bekannt und den DDR Nachbau der 11/780 (RVS K1840) kenne ich auch von innen, auch wenn es lange her ist :-) Gruß, Holm
Christian J. schrieb: > By the way: Reicht die Treiberleistung von CMOS aus, um gegen einen 10k > Pull Up anzukommen am NMI? Ach je... 74HC(T) zieht 4mA runter.
Hi, jedenfalls ist es eine Arbeit für Doofe bei der Fädeltechnik Fehlverdrahtungen zu suchen, von denen ich einige hatte wegen falscher Zählweise der Pins, zb spiegelverkehrt oder in die falsche Richtung. Ich weiss jetzt auch wieso sich "Grant" Aufkleber auf die Chips gemacht hat mit den Pins und Bezeichnungen. Denn es sind so viele durch die Adress und Datenbusse dass man da irre wird. Überschlagsweise sind es 250 Lötpins, die ich verdrahten múss. Man kann Fädeldraht im Kamm nicht zurück verfolgen und nur schwer wieder entfernen wenn da 10 Drähte drüber liegen. Dennoch ist es ordentlich und sauber. Und fasst man ihn mit der Pinzette an beschädigt man den Lack und es gibt leitende Ecken wie ich feststellen konnte beim Piepsen. Auch Draht der über abgeschnittene Pins ragt wird schnell aufgekratzt. Allerdings möchte ich icht mit normalem Draht bis zu 3 Anschlüsse auf ein Lötauge legen, das ist schon so schwer genug. Maximal 10 Leitungen derzeit, dann alles sauber durchpiepsen und auch zu den Nachbarn hin.
Weshalb ich isolierten Draht vom Typ Wrapdraht bevorzuge, ohne die Verdrahtung sonderlich zu strukturieren, statt Fädeltechnik mit Kämmen. Dünn genug um dichte Verdrahtung zu ermöglichen, aber problemlos verfolgbar und änderbar. Erste Aktion, wenn Fassung oder Verbinder drin: Unten den Pin 1 deutlich mit Stift markieren.
A. K. schrieb: > Weshalb ich isolierten Draht vom Typ Wrapdraht bevorzuge, ohne die > Verdrahtung sonderlich zu strukturieren, statt Fädeltechnik mit Kämmen. > Dünn genug um dichte Verdrahtung zu ermöglichen, aber problemlos > verfolgbar und änderbar. > > Erste Aktion, wenn Fassung oder Verbinder drin: Unten den Pin 1 deutlich > mit Stift markieren. Hi AK, kanste mal kurz nen Bick drauf werfen, ob da Clock Konflikte zu erwarten sind? Der 374 latched nämlich auf der positiven Flanke und der 138er erzeugt negative. Müsste eigentlich noch passen, wenn er den 7-Segment Wert am Ende des I/O Zyklus rein nimmt .... allerdings kann ich WR nicht mehr decodieren, d.h. sowohl Schreib als auch Lesezugriffe werden das 374 ansprechen, im RD Fall allerdings mit Nonsens. Für einen extra 74er habe ich keinen Platz mehr, der zb ein NANd mit dazu nehmen würde, um WR in den Demuxer Ausgang einzumischen.... ach so: Ich möchte nur eine 7-Segment ins I/O einmappen. Nen Port kann man zwar auch verbraten aber auch da braucht man wieder Treiber, da die 8255 zu wenig Saft liefert und der STI auch, um LED zu treiben.
Christian J. schrieb: > Der 374 latched nämlich auf der positiven Flanke und der 138er > erzeugt negative. Passt so.
Christian J. schrieb: > (...) Nur war > ihre Haltbarkeit klein, mehr als 10 Löschvorgänge mit einem normalen > Löschgerät erreichte ich auch nicht. Du musst die Dinger ausheizen, um die Ladungen komplett rauszukriegen. In den Backofen, dann auf Vollgas aufheizen (250°C oder so), 45 Minuten warten, dann Ofen aus und langsam abkühlen lassen. Bis Ende der '70er stand das auch so in den Datenblättern. Ein i1702 brauchte alle 5-10 UV-Löschgänge ein Annealing.
Axel Schwenke schrieb: > Hier noch ein praktischer Tip: die CPU auf einen Zwischensockel stecken, > der die 8 Datenleitungen vom restlichen System abtrennt und fest auf GND > legt. Die CPU liest jetzt permanent 0x00 = NOP, was dazu führt daß sie > permanent immer im Kreis durch ganzen Adreßraum läuft. > Mit Logikprüfstift / Oszi kann man jetzt die Adreßsignale, Chipselect > etc. an den diversen Punkten der Platine prüfen. Geht auch einfacher mit dem EPROM. Einfach alles auf "00" brennen. Der ist ja sowieso auf einer Fassung. Meinen hab ich sogar noch.
>Zwischensockel an CPU für NOP >Geht auch einfacher mit dem EPROM. Der Zwischensockel für die CPU ist normalerweise zu aufwendig. Der wäre auch nur dann sinnvoll, wenn irgendein Busteilnehmer aktiv auf den Bus seine Daten auflegt. Das kann man vermeiden, indem man Ram und Eproms (gesockelt!) zunächst heraus läßt. Und dafür einen Huckepack-Sockel am EPROM einsteckt, wo alle 8 Datenpins jeweils über einen 1kOhm gegen Gnd gezogen sind. Kann auf einem leeren Sockel mit gedrehten Pins einfach gemacht werden; Widerstände im Sockel unten nur einstecken; einen R an Gnd auch nur einstecken. Restliche R-Pins oben verlöten; nicht in der Nähe des Platiksockels. Der Vereinfachung mit dem "00" programmierten EPROM geht dann nicht, wenn der Adreßdecoder bereits richtig arbeitet! Dann würde das Eprom nur "NOP" liefern für seine decodierten Adressen. Man müsste dann /CE und /OE des Eproms dauerhaft auf Low legen. Gruss
soul eye schrieb: > Du musst die Dinger ausheizen, um die Ladungen komplett rauszukriegen. > In den Backofen, dann auf Vollgas aufheizen (250°C oder so), 45 Minuten > warten, dann Ofen aus und langsam abkühlen lassen. Das wären da so ca 5 Euro Strom und dafür bekam man auch schon wieder neue. Oder man packte sie beim Kuchen machen mit dabei?
Erich schrieb: > Der Vereinfachung mit dem "00" programmierten EPROM geht dann nicht, > wenn der Adreßdecoder bereits richtig arbeitet! Dann würde das Eprom nur > "NOP" liefern für seine decodierten Adressen. Man müsste dann /CE und > /OE des Eproms dauerhaft auf Low legen. Und wie geht das für Normalsterbliche? Ich meine um zu testen ob die CPU arbeiten sind doch NOPs das beste Mittel? Vom EPROM kommt nichts zurück außer Daten. Man müsste das Geklingel of den Adressleitungen sehen. Ich werde das mal testen heute am frühen Abend.....
Christian J. schrieb: >> (250°C oder so), 45 Minuten warten > Das wären da so ca 5 Euro Strom Kriegst Du deinen Strom vergoldet und im Mondschein gesammelt? 25-30ct/kWh, 2-3kW Leistung knapp 1h gibt unter 1€.
Christian J. schrieb: > Und wie geht das für Normalsterbliche? Was er schrieb: RAM raus, ROM raus und mit Stecksockel D0-7 auf GND.
>> Man müsste dann /CE und /OE des Eproms dauerhaft auf Low legen.
Damit sind dann ab dem Adressbereich des RAM sowohl das RAM als auch das
EPROM gleichzeitig auf den Datenleitungen aktiv. Das ist doch unsinnig.
Helmut S. schrieb: > Damit sind dann ab dem Adressbereich des RAM sowohl das RAM als auch das > EPROM gleichzeitig auf den Datenleitungen aktiv. Das ist doch unsinnig. Hier ging es um einen speziellen Testmodus ohne RAM.
Erich schrieb: > Der Vereinfachung mit dem "00" programmierten EPROM geht dann nicht, > wenn der Adreßdecoder bereits richtig arbeitet! Dann würde das Eprom nur > "NOP" liefern für seine decodierten Adressen. Man müsste dann /CE und > /OE des Eproms dauerhaft auf Low legen. Aber mit einem gelöschten EPROM (alles 0FFh) kann man den gesamten Speicherbereich und die Dekodierung von RAM und EPROM testen. Nach einem Befehlszugriff (M1) folgten dem Befehl 0FFh = RST 38H zwei Schreibzugriffe nacheinender über die vollen 64K. Es wird wiederholt die Returnadresse 0039h auf den Stack geschrieben.
>Aber mit einem gelöschten EPROM ...
Damit hast immer noch die Adressdekodierung dazuwischen, also kommen
"FF" nur vom Eprom.
Ausserdem lassen sich die entstehenden Zyklen nicht schön ansehen ohne
Speicherscope (und anno 1982 hatte das fast niemand).
Selbst mit dem NOP-Adapter hat man die störenden Refreshzyklen auf den
Adressen, aber das nur nebenbei.
Viele Theoretiker hier unterwegs.
Gruss
Route 66 schrieb: > Aber mit einem gelöschten EPROM (alles 0FFh) kann oder man baut sich ein NOP durch Drahtbrücken und kann dann alle Adressen am Takt erkennen...... aber egal, wenn ich Fieber hätte würde ich den Arzt bemühen, manchmal kommen mir auch so Ideen, wie z.B. meinen PC1500 mit der paralleln Schnittstelle zum apple wiederzubeleben. Aber in Blick in den relokatiblen Code mit den Asave und Aload Befehle hat mir gereicht (damals ohne Assembler in HEX auf Karopapier entworfen und eingepoked) um festzustellen das ich heute nicht mehr durchblicke. Das neu zu lernen wäre spannend aber für wen und mit welchem Nutzen ? Ich baue dann lieber an aktuelle Dinge wie word clock und lerne immer mehr über den Atmel der alles dabei hat was der Mensch so braucht. Vom Chinesen sogar billig mit Board und Schnittstelle. Ich würde 68k vor Z80 wählen oder den 6502 vor Z80, aber besser einen PC1500(A) (A besser mehr MEM oder ohne A und Mem einlöten -> die 4Mbit SRAM 512k x8 habe ich dann doch nicht mehr eingelötet) auf ebay schiessen, dann hätte ich LH5803 (?? mein Gedächnis) http://de.wikipedia.org/wiki/Sharp_PC-1500 jedenfalls eine interessante Mischung aus 6502 und Z80 Ähnlichkeit zur Z80 -> 16 bit Register und nicht clock gebundene Bus Abfrage Ähnlichkeit zum 6502 -> hat einen clock der 65xx Portbausteine syncron abfragen kann wie das mit der Clockverlängerung war bei Abfrage lahmer Bausteine war habe ich vergessen, hatte schon zwischen 1980 und 2004 keine Notwendigkeit dafür. also eine prima Mischung für beide Familien der Portbausteine, so man sie noch bekommt. jedenfalls mit einem PC1500 hat man LCD zur Ausgabe, Tastatur zur Eingabe, Daten und Adressbus frei zugänglich, kann in die freien Adress Bereiche eigene Dinge anschliessen http://www.pc1500.com/ http://pocket.free.fr/index.html
Erich schrieb: > Viele Theoretiker hier unterwegs. Ich würde an Deiner Stelle mit Vorurteilen vorsichtig sein! Die RST 38H Auswertung geht ja nach der ersten NOP Analyse den nächsten Schritt: Der Test der Ausdekodierung von RAM, ROM und Adressdekodierlogik. Dabei sind die saubere Trennung von einer Speicherleseoperationen (hier sogar Befehlslesen auf einer bekannten Adresse) und zwei Speicherschreibzyklen im gesamten Adressraum nachweisbar. Das geht auch ohne Speicheroszi.
Angehängte Dateien:
-
DSC08147__1600_x_1200_.jpg
150 KB
Moin, weiter im Text.... ich weiss jetzt wie Bits ausehen! Ja wirklich! Sie sind BLAU! Eindeutig blau..... Bestückung abgeschlossen, jetzt gehts ans Eingemachte.....
Angehängte Dateien:
-
dscf0018.jpg
640 KB
Bevor ich diesen Schrott aufbauen würde, würde ich das allies lieber in die Tonne kloppen..... da hört man es wenigstens plumpsen :-( Wobei ein Blick in den Keller reicht um festzustellen, dass Hartpapierplatinen von 1990 auch eine Art Verkokungsprozess durchmachen, von Vollmich hellbraun bis zartbitter. Bringe es bisher nicht über mich den ganzen Schrott mal zu entsorgen aus Jugendzeiten.
Angehängte Dateien:
-
DSC08148__1600_x_1200_.jpg
200 KB
Da kommen wieder echte Jugendgefühle auf, diese Dinger in den Ofen zu stecken, 20 Minuten zu warten bis zum nächsten Testlauf.... is ja voll retro! Nachdem ich die chin. Stecker abgeschnitten und durch europäische ersetzt habe, weil die alle zu kurze Stifte haben. Kein CE, kein Typenschild, nur eine Kiste mit Kabel und Uhrwerk zum Aufziehen aber für 13 Euro ok.
Christian J. schrieb: > Da kommen wieder echte Jugendgefühle auf, kann ich voll verstehen, irgendwo habe ich auch noch so eine Kiste.
Joachim B. schrieb: > Christian J. schrieb: >> Da kommen wieder echte Jugendgefühle auf, > > kann ich voll verstehen, irgendwo habe ich auch noch so eine Kiste. Habe früher Mutters Gesichtsbräuner genommen, den guten aus den 70ern.... http://www.fanie.org/infrarot/1.jpg auch ideal zum belichten von platinen, wenn man bücher drunter gelegt hat, damit er über der glasplatte zum liegen kommt. 5 minuten und dann rein in die braune suppe, die so schöne flecken in den hosen gab.
Christian J. schrieb: > Nachdem ich die chin. Stecker abgeschnitten und durch europäische > ersetzt habe, weil die alle zu kurze Stifte haben. Kein CE, kein > Typenschild, nur eine Kiste mit Kabel und Uhrwerk zum Aufziehen aber für > 13 Euro ok. Pins auf Plasik? Hm - frueher hatten wir darauf geachtet, dass die EPROM-pins beim Löschen wenigstens auf einer Metallplatte liegend - oder besser noch auf eine Metallstange gesteckt - kurzgeschlossen waren. Sicher nur Paranoia - aber da gab's auch noch den SM103 ;-)
Thomas J. schrieb: > Hm - frueher hatten wir darauf geachtet, dass die EPROM-pins beim > Löschen wenigstens auf einer Metallplatte liegend - oder besser noch auf > eine Metallstange gesteckt - kurzgeschlossen waren. Das muss das Boot abkönnen!
Angehängte Dateien:
-
IMAG0378.jpg
9,9 KB
Joachim B. schrieb: > kann ich voll verstehen, irgendwo habe ich auch noch so eine Kiste. sogar wiedergefunden, über 10 Jahre nicht mehr benutzt mit original Staub drauf..... das nächste Projekt müsste dann win Arduino Eprombrenner sein weil ich den Brenner mit der IDE Schnitte nirgends mehr anschliessen kann :-)
Joachim B. schrieb: > Joachim B. schrieb: >> kann ich voll verstehen, irgendwo habe ich auch noch so eine Kiste. > > sogar wiedergefunden, über 10 Jahre nicht mehr benutzt mit original > Staub drauf..... > > das nächste Projekt müsste dann win Arduino Eprombrenner sein weil ich > den Brenner mit der IDE Schnitte nirgends mehr anschliessen kann :-) Geht mir ähnlöich mit dem Brenner für den C64.... Centronics Schnittstelle mit Klipsen dran...
Ich habe den hier: Beitrag "[V] ISEL EPROM-Löschgerät mit Timer" Musste ihn letztens sogar wieder benutzen. Da mein letzter EPROM Brenner vor gefühlten 10 Jahren über den Jordan ging, habe ich mir schnell den hier gebaut: http://www.qsl.net/iz7ath/web/02_brew/17_eprom/english/pag03_eng.htm Braucht allerdings ne Win98 Kiste oder ähnlich, damit die Brennsoftware an den Druckerport kommt. Zum Glück steht im Schuppen noch ein alter Win98 Laptop mit LPT.
Moin, habe jetzt von ebay den "Topwin 853" Programmer bekommen, neue Software V7 mal aus China runtergeladen. Das Ding ist echt klasse! Identifiziert und prüft sogar 74er Chip. So dass ich gleich einen defekten raussortieren konnte. Kann diese 35 Euro Programmer nur empfehlen!
Hmpf, das können alte ALL07 auch und für einen gebrauchten davon habe ich aus gutem Grund mehr als 35 Euro bezahlt. Gruß, Holm
Angehängte Dateien:
-
SAB80382-auf-Steckbrett.jpg
520 KB
Christian J. schrieb: > Bevor ich diesen Schrott aufbauen würde, würde ich das allies lieber in > die Tonne kloppen..... Heheheeee, so ähnlich sieht bei mir ein Steckbrett mit einem 8048-Derivat drauf aus. Aber ich möchte die Schaltung ja nicht für ewig darauf stehen lassen, und eben nur eine Weile lang einiges testen. Ich machte mal extra ein Foto für hier zur Ansicht. Die arg langen Drähte machen überhaupt nichts aus, der Eingangstakt beträgt weit unter 1MHz. Der Quarzoszillator hat zwar 5MHz, aber ich habe mit 4040-ern runter geteilt. Die Siebensegment-Multiplexung ist etwas brutal, aber funktioniert: Spaltentreiber ULN2003, Zeilentreiber 74LS245. Alles ohne Vorwiderstände, und fluppt gut. Der 74LS245 wird etwas heiß, aber wenn er verreckt: Tonne auf, Tonne zu, neu, hab da Vorrat. 80C382 von Siemens, bestimmt gut 30 Jahre alt. Die Steine haben aber schon sehr heraus ragende Leistungsmerkmale, z.B. sind sie in CMOS, voll statisch, haben bei 1MHz 1mA Stromaufnahme bei nur 3V Betriebsspannung. Sogar ein Sleep und Wakeup gibt es. Das alles ist für die damalige Zeit eine reife Leistung. Von den für MCS-48 bestimmten Portexpandern 8243 hab ich auch noch einige. Im Grunde hat der 80C382 den 8048-Core, man hat aber vom Befehlssatz 17 Befehle entfernt, dafür 5 leistungsfähige hinzu gefügt (was mit indirekter Adressierung). Das hab ich im Tabellen gesteuerten Assembler auch so angepaßt. Das Datenblatt bekam ich mal von einem Forenuser genannt, der wußte, wie es hieß. Unter dem Bauteilnamen findet man nämlich nichts. Bis dahin war ich ahnungslos und hatte eine Stange unbekannter ICs. Komische Erfahrungen mit Pagegrenzen und Interruptverhalten machte ich auch schon. Den Stein würde ich zum Einstieg in die µC-Welt noch empfehlen, aber dann auf einem Board mit Monitor-ROM, wo man kein EPROM brennen muß. Ich spiele einfach ein wenig mit den Dingen herum. Prozessen tut so ein alter Schinken auch, was man ihm sagt. Nur nicht der schnellste eben. Konkrete Anwendungen mache ich nicht, aber mal sehen, bei der nächsten Reichelt-Bestellung könnte es für mich ein PICkit geben.
Angehängte Dateien:
-
DSC08149__1280_x_1024_.jpg
170 KB
Naja, mein Arduino Brett sieht auch so aus, zum testen eben. Wobei diese Kabel dauernd Wackelkontakt haben und absolut nichts taugen.
Christian J. schrieb: > habe jetzt von ebay den "Topwin 853" Programmer bekommen, neue Software > V7 mal aus China runtergeladen. Das Ding ist echt klasse! Identifiziert > und prüft sogar 74er Chip. So dass ich gleich einen defekten > raussortieren konnte. Kann diese 35 Euro Programmer nur empfehlen! Vorsicht! Teste den defekten 74... mal per hand durch. Mein TOP2005 mag auch nicht alle, obwohl sie in Ordnung sind.
Michael_ schrieb: > Vorsicht! Teste den defekten 74... mal per hand durch. > Mein TOP2005 mag auch nicht alle, obwohl sie in Ordnung sind. Habe ich schon bemerkt, dass er nicht alle mag, obwohl sie gelistet sind. Habe einen ganzen Setzkasten voll und manche Typen erkennt er einfach nicht, oder behauptet dass sie alle Bad sind. Gibt aber die neue Soft V7 jetzt beim Chinamann zu holen, die läuft besser als die V6. Ansonsten aber nettes Teilchen, ob PICs, SRAMs, serielle E2Proms oder AVR, er nimmt alles.
Moin, nein, das Projekt ist noch nicht "tot". Nur an einem Punkt wo ich einige Schritte zurück gehen musste. Die Idee "Fädelplatine" war Nosense, das Ganze wäre deutlich einfacher mit einem CAD Programm, Routen und dann Platine bauen lassen. Da ich einige Verdrahtungsfehler gemacht habe, die ich umständlich aus den Kämmen heraus "operieren" musste bin ich derzeit dabei anhand der Netzkliste von Eagle jede einzelne Verbindung nochmal durchzupiepsen und abzuhaken. Laut Netzliste sind es 350 Drahtverbindungungen, jede einzelne dauert etwa 3-4 Minuten die zu legen: Anschmelzen, einlöten, verlegen, abschneiden, wieder anschmelzen, einlöten. Aktuell habe ich erst ca 120 Verbindungen gelegt. Zuerst das EPROM an den Z80 und den Z80 betriebsbereit verbinden mit all seinen Leitungen über die Glue Logic zum EPROM und RAM hin. Dann wird das EPROM eingesteckt, was nur einen HALT Befehl am Ende hat und geschaut ob der erreicht wird. Danach ein leeres EPROM mit NOPs und mit Logic Analyzer über die Pins geschaut. Mühsam, mühsam....
Hi Retro-Fans! Klasse, die Z80 spielt !!! EPROM und Glue Logic verdrahtet, ein EPROM nur mit einem HALT am Ende bespielt und einen 100 khz Takt von einem Arduino auf den Clock gegeben. Da habe ich ja eine Weiche eingebaut. Nach einigen Sekunden leuchtet die HALT-LED. Ohne HALT mit nur NOPs tut sie das nicht. Mit dem Logic Analyzer klimpern auf den Adressleitungen auch die Bits herum! Klasse, ich haben nen 20 Jahre alten Z80 aus seinem Schlaf erweckt :-)
Holm Tiffe schrieb: > ..Wahnsinn! > > > :-| > > Holm Hey Mann, lass mir doch mal die Freude in unserem pfurz trockenen Job wo die meisten Verklemmten mit verbissenen Gesichtern rumrennen!
Naja, mein Gott...solche Sachen bauen die Jungs bei Robotrontechnik.de ständig, meist aber mit etwas mehr Funktionalität. Ich habe hier auch eine Z80-EMUF Platine liegen, die ich mal kurzerhand und aus "langer Weile" etwas frisiert hatte, da sind jetzt 64K RAM, 32K ROM, ne SIO und ne CTC zusätzlich drauf, inklusive Urladermimik und 6Mhz Takt. In dem Moment als das alles funktionierte habe ich das wieder beiseite gelegt.. Entschuldige also wenn mich das nicht gerade senkrecht aus dem Sessel drischt. Gruß, Holm
Hi, jetzt suche ich nur noch eine Beschriebung wie ich den SDCC einstellen muss, mit allen möglichen Header Files und Linker Optionen, damit er das tut was ich möchte. Das Netz gibgt da leider nichts her, was mit google findbar wäre. ASM wie gesagt nur sporadisch, alles weitere wird in C geschrieben.
Angehängte Dateien:
-
sdcc1.png
46 KB
Wenn Du sonst gar nichts findest, versuch es doch ausnahmsweise mal mit der mitgelieferten Doku.
Leo C. schrieb: > Wenn Du sonst gar nichts findest, versuch es doch ausnahmsweise mal mit > der mitgelieferten Doku. Das wäre ja schummeln. Ist ja nicht so, dass ich ihn nicht bereits mehrfach daraufgeschubst hätte...
Leute, das Manual habe ich natürlich! Das bringt einem aber nichts, wenn man nicht mal ein Projektverzeichnis hat, wo das alles schonmal eingestellt wurde. 1. Wie bringe ich ihm bei meine crt0.s zu benutzen und nicht die vorhande? 2. Wie bringe ich ihm bei den main code nicht auf 0x0000 zu pflastern, sondern auf 0x01000 und bei 0x0000 einen Jump drauf zu legen. 3. Wie bringe ich ihm bei die Vector Tabelle mit einzulinken und die Vektoren auf meine Routine zu legen. Ich bin nicht blöd aber sitz da bitte mal vor und versuche das alles selbst rauszufinden in einem Miniprojekt, wo einfach das Grundlegende funktionieren soll.
Hallooooooooooo............! Kann mal einer von euch Z80 Gurus einen Blick auf den Plan werfen? Ist das so richtig, was Eprom und SRAM angeht? Nachdem ich alles durchgepiepst habe ist das so miteinander verbunden und nicht anders. Denn... ein einfaches Programm mit dem SDCC, was auch "richtig" ist fährt nicht in den HALT Befehl, nachdem es vorher zwei Schleifen durchlaufen hat. Auch nicht wenn die Schleifen gelöscht wurden. Was bisher funktionierte war, dass ein leeres NOP EPROM mit einem Halt Befehl am Ende die LED leuchten liess, die am Halt Pin steckt.Aber sobald Variablen ins Spiel kommen oder der Compiler, der solche setzt, zb Stack Pointer klappt es nicht mehr. ROM : 0000 - 1fff RAM : 2000 - ffff Ich habe die Files mal angehängt, auch der Hex Code schaut ok aus im Hex Dump Monitor, die Befehle liegen da wo sie hingehören. Ratlos....
Angehängte Dateien:
-
Unbenannt.JPG
300 KB
Anbei der Hex Dump.... Vorne C3 Sprung nach 0x01000, den Startup Code ausführen, dann der CALL Main mit CD 10 01 (Call 0x0110) und dann weiter in meiner Routine. Sieht alles soweit richtig aus.....
Deine crt0.s erzeugt Interruptvektoren bei 0x00, 0x08, 0x10, 0x18 ... und lässt den Code dann ab 0x100 beginnen. Du müsstest vermutlich die ganzen Areas zu Fuß definieren. Code, um statisch initialisierte Variablen nochmal zu kopieren (vom ROM ins RAM), erzeugt der SDCC immer - mir ist kein Weg bekannt, das abzustellen. Wenn du also den Code ab 0x1000 beginnen lassen möchtest, solltest du dem Compiler das sagen. ;-) Nachtrag: Du kannst dir mal die anderen Dateien anschauen. Da steht genau drin, wie welche Codezeile in welche Assemblersequenz an welchen Adressen zusammengebaut wird und ist relativ gut lesbar. Besser als ein Hexdump auf jeden Fall.
Hi, so nachdem ich gefühlt 50 EPROMs gebrannt habe und auch den Quelltext korrigiert bin ich schlauer und nicht schlauer..... Es funktioniert...... manchmal ! D.h. es wird ja nur eine Schleife durchlaufen bevor ich die einzige Debugmöglichkeit nutze, die ich derzeit habe: HALT an LED. Und dieses "manchmal" lässt mich grad überlegen, ob ich das Platinchen zu vielen anderen in die Ecke lege. Vermutlich hat die CPU ein Timing oder ein Reset Problem. Sie startet beim Einschalten nur "manchmal" los und auch beim Druck des Reset führt die das Programm nur "manchmal" aus.... von 10 Reset Drückern sind mindestens 3 solche, wo die LED nicht nach 2s aufleuchtet. Mit der CPU von SGS arbeitet das Programm "oft aber nicht immer" Mit der CPU von ST arbeitet das Programm "fast nie". Wenn ich an die Verdrahtung da unten drunter denke kommen mit so Gedanken. Mangels Messgeräten derzeit aber schwer feststellbar. Nebenbei habe ich grad den offenen INT Pin per Pull Up an Vcc gezogen, der hing mangels Chip in Fassung in der Luft. Hätte ja sein können... PS: Die Zuverlässigkeit steigt DEUTLICH, wenn ich den Takt nicht über ein Gatter führe, sondern direkt vom OSC in die CPU einspeise auf dem 1cm kurzen Weg. Trotzdem weigert sich die CPU nach dem Kaltstart los zu laufen, es ist immer ein Reset per Hand nötig.
So, ich bin meinem Latein am Ende. Absolut unbefriedigendes Startverhalten, egal ob Kalt oder Warmstart! Testweise den Reset verlängert durch 10k und 10uf, man sieht ihn jetzt deutlich an der LED, die am Resetpin angeschlossen ist, wie er "aufblitzt" kurz nachdem Vcc da ist. Osc testweise durch 1 MHZ aufgetauscht, es wird geringfügig besser. Für die Schleife bis 40.000 braucht er dann schon stattliche 5s. Die uralte NMOS CPU läuft am besten, wird aber deutlich handwarm und zieht sich 150 mA rein. Manchmal leuchtet dei HALT LED auch sofort nach Einschalten auf. Solange das nicht 100% ig funktioniert, dass es bei jedem Reset und bei jedem Power Up immer das gleiche Resultat gibt hat es keinen Zweck das Projeklt weiter zu verfolgen. Das damals mit dem 8085 lief deutlich besser und da war die Verdrahtung deutlich chaotischer. Keine Ahnung ob 4 Mhz für Luftverdrahtung schon zu viel sind ;-( Halte ich fest: Verdrahtung scheint ok, da das programm ja ab und zu richtig abgearbeitet wird. Aber ohne Messgeräte weiss ich da auch nicht weiter.
> NMOS CPU läuft am besten, wird aber deutlich handwarm und zieht sich 150 > mA rein. Normal. Siehe Datenblatt. > Keine Ahnung ob 4 Mhz für Luftverdrahtung schon zu viel sind ;-( Für Luftverdrahtung nicht, für Fädelkämme schon. Du hast weiter oben von einem 100KHz Takt geschrieben. Wie siehts denn damit aus? Ansonsten: Scope.
Christian J. schrieb: > Das damals mit dem 8085 lief deutlich besser und da war die Verdrahtung > deutlich chaotischer. Keine Ahnung ob 4 Mhz für Luftverdrahtung schon zu > viel sind ;-( Von einem alten Mainframe hat mir jemand mal die Schote erzählt, dass sie ursprünglich die Backplane fein säuberlich geordnet verdrahtet hatten. Kabel neben Kabel. Nur Ärger. Im nächsten Anlauf haben sie den Kram dann chaotisch quergezogen, so dass das aussah wie ein Filzteppich. Nun lief er.
Welches EPROM hast Du denn genau? In Deinem Schaltplan steht "EEPROM2764". Das ist wohl eine Phantasiebezeichnung. Auf jeden Fall sind CE und OE vertauscht.
Leo C. schrieb: > Auf jeden Fall sind CE und OE vertauscht. Was hier aber keine Rolle spielt, sondern erst bei grenzwertiger Zugriffszeit.
Ich sehe auf deinem Schaltplan keinen einzigen Abblockkondensator.
User schrieb: > Ich sehe auf deinem Schaltplan keinen einzigen Abblockkondensator. Kannst Du auch nicht sehen, die sind unter den ICs mitten im Sockel. ;-)
>> Ich sehe auf deinem Schaltplan keinen einzigen Abblockkondensator. > Kannst Du auch nicht sehen, die sind unter den ICs mitten im Sockel. ;-) Auf dem Schaltplan sind nicht mal Sockel. ;-) (Gottseidank) Aber auf einem der letzten Bilder sind welche. Aber wie sie verdrahtet sind, sieht man dort auch nicht. (hint) >> Auf jeden Fall sind CE und OE vertauscht. > Was hier aber keine Rolle spielt, sondern erst bei grenzwertiger > Zugriffszeit. Grenzwertig wirds je nach CPU ab ca. 3,4 Mhz (SGS 2,5MHz CPU) oder 4 MHz (Zilog 6 MHz CPU), wenn er das 250ns EPROM genommen hat, daß in einem der Bilder zu sehen ist. Christian J. schrieb: > Die uralte NMOS CPU läuft am besten Spricht für die "Fädelkammtheorie", da die CMOS-CPUs steilere Signalflanken haben dürften.
Leo C. schrieb: > Aber auf einem der letzten Bilder sind welche. Aber wie sie verdrahtet > sind, sieht man dort auch nicht. (hint) Aber im Bild der Platine weiter oben, gewissermassen. Ausser beim EPROM im wohl zu niedrigen gedrehten Sockel sieht man da nämlich auch kaum welche. Aber im Thread hatte er erwähnt, dass er die im Plan wegliess. Bei Handverdrahtung unnötig, mache ich auch oft so. Bei den im Bild noch unbestückten Gatter-ICs sind aber wirklich keine Kerkos zu sehen. > Grenzwertig wirds je nach CPU ab ca. 3,4 Mhz (SGS 2,5MHz CPU) oder 4 MHz > (Zilog 6 MHz CPU), wenn er das 250ns EPROM genommen hat, daß in einem > der Bilder zu sehen ist. Aber nicht wenn er testweise mit 1MHz fährt und die Probleme immer noch auftreten.
Christian J. schrieb: > Das damals mit dem 8085 lief deutlich besser und da war die Verdrahtung > deutlich chaotischer. Keine Ahnung ob 4 Mhz für Luftverdrahtung schon zu > viel sind ;-( Chaotische Verdrahtung ist ok. Mit parallel geführten Leitungen in Fädelkämmen dürfte aber schon bei deutlich kleineren Frequenzen Schluss sein. Die Dinger gehören verboten -- für getaktete Schaltungen sind die völlig ungeeignet. Mach mal einen 330 Ohm - Pullup an den CLK-Pin des Z80. Der will da nahezu VDD als Highpegel sehen und zieht noch ordentlich Strom dabei. Ein HCT14 sollte das in der Theorie auch liefern können, in der Praxis reicht es aber nicht immer.
Hi, 330 Ohm Pull-Up an Clock? Und wer soll das Schwergewicht wieder runter ziehen? Natürlich sind an jedem IC Blocker, unten drunter zwischen den Pins. Teilweise auch als smd, bzw sind auch viele Winderstände smd. Mit einem 100 khz Takt vom Arduino spielt die Musik bei jedem Reset. Allerdings funktioniert der Kaltstart nicht sauber. Mit 1 Mhz kann man allerdings nebenher laufen, für 1...40000 braucht der 6s ohne Schleifeninhalt. Da es mit 1 MHZ aber auch noch Probleme gibt, die kaum weniger sind und nur bei 100khz keine werde ich erstmal die beiden vertauschten Leitungen korrigieren. Und dann mal sehen ...... tja, ohne Oszi schlecht, brauche dringend wieder eines. Das OR Gatter ist übrigens ein ACT, hatte kein HCT mehr. Und die ST 2764 Eproms sind 250ns, thats right.
Christian J. schrieb: > Das OR Gatter ist übrigens ein ACT Autsch! ACT und Fädeltechnik ist wie Formel 1 auf dem Rübenacker. Egal mit welcher Frequenz Du taktest, die Flanken bleiben mörderisch. Dann nimm lieber TTL, wenn du eins ohne A drin hast.
Hallo, also zuerst mal die beiden Leitungen korrigieren was bei Fädeltechnik abschneiden und neu legen ist. Dann dran gewöhnen dass 1-2MHZ die Grenze de Zumutbaren ist, also C64 Speed. Schade, 4 MHZ liefen schon recht flott daher. Und wenn das getan ist weiter im Teext... der SDCC ist übrigens wirklich schön, auch wenn ich mir retro-halber noch die Assembler Sprache des Z80 reinziehen werde von dem schön vergilbten Papier des Schmökers. Und ich gewöhne mich grad wieder dran, dass EPROM brennen Spass macht nach jeder Programmänderung, habe aber auch ein 2764 Flash gekauft. Sobald der Monitor läuft wird es ja einfacher... hoffe ich mal :-) Hat jemand noch eine Baudratenquarz Oszillator 1,832 Mhz rumfliegen ?
Angehängte Dateien:
-
IMG_1127.JPG
250 KB
PS: Da ist der Trümmer, der noch be mir im Keller liegt.... ein CCS-85, damals für 300 DM..... vielleicht kennt jemand noch die Art wie da "programmiert" wurde.... hicks
Christian J. schrieb: > Hat jemand noch eine Baudratenquarz Oszillator 1,832 Mhz rumfliegen ? Den schenkt dir niemand. Nimm einen mit doppelter Frequenz, die gibt es wie Sand am Meer. Und lass erst mal deine SDCC weg! Es nervt nur. Wenn erst mal dein System läuft, kannst du sie immer noch einbauen.
Du hast wiedermal Verschiedenes "besser" gewußt.. Irgend ein Eingang hängt offen herum, checke nochmals BUSRQ, NMI und INT. Bevor Du einen C-Compiler anpaßt, teste das Ding mit kleinen Assemblerprogrammen, der Z80 läßt sich an interessanten Stellen leicht anhalten in dem man die CS Leitungen von RAM oder Peripherie temporär mit dem WAIT Eingang verbindet. Man hat dann endlos Zeit Signale zu kontrollieren. Stecke Deinen Kopf in die Bücher und verstehe was der Prozessor und die Peripherie machen soll, verifiziere das auf Deiner Hardware. Kümmere Dich um den Systemclock, das der etwas speziell ist, hatte ich schon mal durchgegeben. Besorge Dir einen Assembler und schreibe ein paar kleine Programme die die Funktionsfähigkeit z.B. des RAMs im Stackbereich kontrollieren. Gruß, Holm
Lieber Holm, du hast sicher recht. An eine Art Single Step habe ich auch schon gedacht. Nur ist es eben schwierig an einem System mit Hausmitteln zu arbeiten, welches einem kein Feedback gibt und wo die Turn Around Time von der Programmänderung zur Verifikation sehr hoch ist. Das war schon damals schwer aber es gab Hilfsmittel wie Eprom Emulatoren, Entwicklungs-Bretter, Debugger Karten, Single Step Bus Karten mit LEDs drauf, zb für den S100 Bus usw. Der SDCC hat einen Assembler mit dabei, den sdaz80. Ich bin dran.... aufgeben wäre zu früh.... Es hängt übrigens kein Eingang offen herum, alles kontrolliert und ge-pull-up'd.
Christian J. schrieb: > Dann dran gewöhnen dass 1-2MHZ die Grenze de Zumutbaren ist, Stimmt nicht. Gegenbeispiele wurden schon genannt[1]. Mein altes 64180-System läuft mit einem 18,432Mhz Quarz (9,2MHz Systemtakt). Und das mit dynamischen RAMs, die ja nach mancher Meinung auch nicht mit Fädeltechnik laufen sollen. Und im gleichen Thread ist noch ein '180-System mit 7,15Mhz und mit Fädelkämmen verdrahtet! [2] > also C64 Speed. Kann man so auch nicht sagen. [1] Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" [2] Beitrag "Re: z80 system"
Christian J. schrieb: > PS: > > Da ist der Trümmer, der noch be mir im Keller liegt.... ein CCS-85, > damals für 300 DM..... vielleicht kennt jemand noch die Art wie da > "programmiert" wurde.... hicks Du mußt dich wirklich mal schlau machen. Das wird eine 8085 CPU sein. Fast der gleiche Befehlssatz wie der Z80, nur weniger. Der Z-80 ist die "Weiterentwicklung" von ZILOG.
Angehängte Dateien:
-
z80-mon.jpg
120 KB
Hallo, bevor ich bei dem Wetter mal rausgehe... es funktioniert! 1. 680 Ohm an Clock .... oh, Wunder! 3. OE un CS richtig verdrahtet !!!! 4. 3.8 Mhz Osc wieder rein. Klappt! Vermutlich wird eine der Maßnahmen das Problem beseitigt haben, vor allem vertauschte Leitungen sind Gift für ein Design, auch wenn die beiden fast zeitgleich takten. Kaltstart nicht immer..... ich verlängere den Reset schon an die Schmerzgrenze, er wird 0,5s nach Power Up jetzt ausgelöst., Schnelles Ein/Aus mag es nicht, es muss schon ein paar Sekunden der Strom weg sein. Kann sein, dass das was man heute Brownoout Reset nennt damit was zu tun hat. Der Power Up Zyklus hat ja mit einigem Aufwand bei PIC und AVR. Man kann die Z80 in einen Zustand bringen, wo sich nichts bewegt auf den Leitungen. Dann kann es ja weiter gehen..... An die Gegner des SDCC: So wie ich mich da bisher eingearbeitet habe hat er alle Features um ISR zu bearbeiten, IO Zugriffe, Vector Tabellen anlegen (als inline asm) usw. Asm werde ich mit einem Simulator mal üben am PC. Kann mir da jemand einen Assembler mit Z80 Emulator für Linux empfehlen? Am besten so wie auf dem ´Bild mit einem Debugger.
Bitte tu Dir (und uns;) einen Gefallen, und versuche die Ursache heraus zu finden! Die Verdrahtung würde ich nicht nochmal ändern, aber die Punkte 1. und 2. solltest Du einzeln und zusammen nochmal rückgängig machen, und schauen was passiert. Und bevor Du voran gallopierst, solltest Du auch den Reset richten. Es macht auf Dauer keinen Spaß, mit einem unzuverlässigen System zu "arbeiten".
Christian J. schrieb: > Kaltstart nicht immer..... ich verlängere den Reset schon an die > Schmerzgrenze, er wird 0,5s nach Power Up jetzt ausgelöst., Viel hilft hier nicht viel. Der Reset muß so lange auf low bleiben, bis die Versorgungsspannung oben ist, und der Taktoszillator stabil läuft (wenige 10ms). > Schnelles Ein/Aus mag es nicht, es muss schon ein paar Sekunden der Strom > weg sein. Die Diode ist in den Beispielen, die Du gepostet hast, nicht zum Spaß drin. Bei Dir gehört sie über R10.
Christian J. schrieb: > An die Gegner des SDCC: So wie ich mich da bisher eingearbeitet habe hat Hier hat niemand was gegen den SDCC. Einige sind nur der Meinung, daß Du die ersten Schritte zuerst machen solltest. > Kann mir da jemand einen Assembler mit Z80 Emulator für Linux empfehlen? Beim SDCC ist neuerdings einer dabei. ;-)
Leo C. schrieb: > Viel hilft hier nicht viel. Der Reset muß so lange auf low bleiben, bis > die Versorgungsspannung oben ist, und der Taktoszillator stabil läuft > (wenige 10ms). Leo C. schrieb: > Und bevor Du voran gallopierst, solltest Du auch den Reset richten. Es > macht auf Dauer keinen Spaß, mit einem unzuverlässigen System zu > "arbeiten". ich würde ja bei alten Designs einen Reset Controller nehmen TL7705 http://www.elektronik-kompendium.de/public/schaerer/bilder/u_supvi5.gif Leo C. schrieb: > Die Diode ist in den Beispielen, die Du gepostet hast, nicht zum Spaß > drin. Bei Dir gehört sie über R10. oder auf jeden Fall um den Elko schnell zu entladen Anode an +Elko Kathode an Vcc
Leo C. schrieb: > Bitte tu Dir (und uns;) einen Gefallen, und versuche die Ursache heraus > zu finden! Die Verdrahtung würde ich nicht nochmal ändern, aber die > Punkte 1. und 2. solltest Du einzeln und zusammen nochmal rückgängig > machen, und schauen was passiert. Du bist ein kleiner Scherzkeks. Ich habe den Sch.... angefangen, jetzt löffel ich ihn auch aus. Ohne spezielle Messgeräte geht das nicht. Wenigstens einen Oszi muss ich wieder bald hier haben. Es läuft schon ziemlich gut und mit einem Logiktester sehe ich ja, dass auf den Pins Musik ist aber bei 10 AuS/EIN eben nur so 7 Mal, die restlichen 3 Male sind die Pins tot, Takt liegt aber an. Reset nützt nichts! So, und das versuche bitte mal rauszufinden. Du hast keine Chance, wenn Vcc da ist, Takt auch aber auf Daten und Adressleitungen ist nichts los und NICHT mal ein Reset ändert daran was. Nur nochmal AUS/EIN und dann klappt es beim nächsten Male. In einem Industriedesign würde ich da direkt den Supporter des Distis ranholen. Da Millionen davon verbaut wurden kann es aber nicht am Chip liegen. Ansonsten klappt es aber, er prüft sein RAM derzeit rauf und runter und oper NMI Taste kann ich ihm eine Speicherstelle fälschen, so dass er dann einen Vergleichsfehler findet und in den HALT geht. Auf den print und sprintf werde ich wohl verzichten müsse´n, die 8kb ROM sind dann nämlich halb voll, wenn ich den einbinde.
vor allem sollte das RAM sicher unter Ub unter 0.5V gehen während des powerdown. Sonst wir es ein lauwarmer Reset mit bankweise gekippten Bits. Da hilft kein langer reset, sondern nur ein ausreichend langer Powerdown! der z80 macht keinen Kaltstart solange das Warmflag im Ram gesetzt ist! aber du kannst in den Warmstartvector den link auf Kaltstart setzen. ;) Wenigstens die Systemvariablen und die Vectortabelle solltest du auch bei einem Warmstart reinitialisieren, zumindest solange du nicht modifizierte Vectortabellen nutzen willst. Und dann wäre es besser die sauber zu halten und woanders zeiger zu (ver)biegen. ;) es gipt auch Resetcontroller mit welchem ei Z80 mit brownoutdetector nachgerüstet werden kann.;) http://www.mikrocontroller.net/articles/Brownout
Winfried J. schrieb: > der z80 macht keinen Kaltstart solange das Warmflag im Ram gesetzt ist! Wo hast du diese Weisheit her? Beim Z80 gibt es nur einen Reset Vektor, nämlich 0x0000. Der Rest ist Sache des Anwenders.
Winfried J. schrieb: > der z80 macht keinen Kaltstart solange das Warmflag im Ram gesetzt ist! > aber du kannst in den Warmstartvector den link auf Kaltstart setzen. ;) > > Wenigstens die Systemvariablen und die Vectortabelle solltest du auch > bei einem Warmstart reinitialisieren, zumindest solange du nicht > modifizierte Vectortabellen nutzen willst. Und dann wäre es besser die > sauber zu halten und woanders zeiger zu (ver)biegen. ;) Warmstart-Flag? Bahnhof-Flag? Systemvariablen? Vectortabelle.... liegt im ROM, nur RETI drin. Bin den ganzen Tag schon dran und weiss was los ist, auch mit Hausmitteln wie Logik-Tester ..... und das Problem ist vorerst nicht lösbar, da rundum das Problem ein schwarzer Kasten ist, eine Black-Box sozusagen :-) Den juckt auch kein Reset mehr in diesem "Zustand". Der "blinkt" richtig auf den Adressleitungen, ca 10 Hz Takt, ab und zu jedenfalls, sonst nimmt er die Füsse hoch oder runter, je nachdém.
Georg G. schrieb: > Winfried J. schrieb: >> der z80 macht keinen Kaltstart solange das Warmflag im Ram gesetzt ist! > > Wo hast du diese Weisheit her? Beim Z80 gibt es nur einen Reset Vektor, > nämlich 0x0000. Der Rest ist Sache des Anwenders. Christian J. schrieb: > Warmstart-Flag? Bahnhof-Flag? Systemvariablen? Boah, Leute. Mitdenken Ein Monitorprogramm, das nach jedem Hardware-Reset einen Kaltstart [1] macht, ist keinen Pfifferling wert. Es braucht eine wenigstens halbwegs zuverlässige Heuristik, um zu entscheiden ob ein Kaltstart oder Warmstart erforderlich ist. > Vectortabelle.... liegt im ROM, nur RETI drin. Blöde Idee <tm>. Dann brauchst du auch keine Vektortabelle. Die Tabelle muß natürlich im RAM liegen. Mit Einträgen, die ins ROM zeigen. XL [1] ein Kaltstart beinhaltet i.d.R. sowas wie komplette Löschung des RAMs. Oft auch einen kurzen Selbsttest oder einen Scan, wo denn überall RAM liegt (damit man z.B. den Stack ans Ende setzen kann). Natürlich müssen nach einem Kaltstart alle im RAM liegenden Variablen und Tabellen (beim Z80 insbesondere die Vektortabelle) initialisiert werden. [2] bei einem Warmstart versucht man, so wenig wie möglich RAM anzufassen, damit z.B. eine post mortem Analyse möglich bleibt. Einen Teil der Systemvariablen wird man aber trotzdem initialisieren wollen.
Nabend, er läuft... immmer, ohne Mucken, bei jedem Resetm, jedem Power Up .... hüstl. Ohne ins Detail zu gehen..... man hole sich neben der Hardware nicht eine zweite Fehlerquelle ins Haus.... den SDCC Compiler. Denn der hat es in sich und erzeugt fehlerhaften Code bzw wenn man nicht Dinge tut, die andere schon herausgefunden haben, die aber nicht im Manual stehen und auch nicht behoben worden sind. Spüielreien wie mit meheren Source Files arbeiten, Prototypen definieren, extern Variablen usw. sollte man erstmal lassen, da wird "noch dran gearbeitet", da der Linker damit nicht klar kommt. So muss die für den Z80 aussehen (Rohbau) und alles andere Zeugs da raus. Der Z80 braucht nicht mehr, Stackpointer setzen und loslaufen.
1 | .module crt0 |
2 | .globl _main |
3 | .area _HEADER (ABS) |
4 | ;; Reset vector |
5 | .org 0x0000 |
6 | jp init |
7 | init: |
8 | ld sp,#0xffff ;; Oder Testen, wo RAM zu ende |
9 | call _main ;; Hauptprogramm aufrufen |
10 | lo: halt ;; oder jp lo für Endlosschleife |
11 | |
12 | ;; Initialise global variables |
13 | call gsinit |
14 | call _main |
15 | ret |
16 | |
17 | ;; Ordering of segments for the linker. |
18 | .area _HOME |
19 | .area _CODE |
20 | .area _GSINIT |
21 | .area _GSFINAL |
22 | .area _GSINIT |
23 | gsinit:: |
24 | .area _GSFINAL |
25 | ret |
26 | .area _DATA |
27 | .area _BSEG |
28 | .area _BSS |
29 | .area _HEAP |
30 | |
31 | Konkret muss die ctr0.s modifiziert werden und genau deshalb spielte der auch verrückt. |
8255 tut es auch, LEDs blinken, 7 Segment kommt noch. ***************************************************** DANKE AN ALLE, DIE MIR BIS HIERHIN GEHOLFEN HABEN ! Ohne euch hätte ich das nie geschafft ! ******************************************************
Axel Schwenke schrieb: > Ein Monitorprogramm, das nach jedem Hardware-Reset einen Kaltstart [1] > macht, ist keinen Pfifferling wert. Es braucht eine wenigstens halbwegs > zuverlässige Heuristik, um zu entscheiden ob ein Kaltstart oder > Warmstart erforderlich ist. Vom Z-80 scheinst du keine Ahnung zu haben. Hardware-Reset ist Hardware-Reset! Das ist beim PC als auch beim AVR so.
Michael_ schrieb: > Das ist beim PC als auch beim AVR so. Eben dieser PC ist ein schönes Beispiel, dass auch ein ziemlich brutal wirkender Prozessor-Reset nicht ganz das sein muss, was Du dir darunter vorstellst. Da Intel keinen Weg aus dem protected mode in den real mode vorgesehen hatte, mussten Systeme, die diesen Weg dennoch benötigten, anfangs im vollen Galopp während des Normalbetriebs den Prozessor-Reset dafür verwenden: http://en.wikipedia.org/wiki/Protected_mode#Entering_and_exiting_protected_mode Der Trick besteht darin, im Monitor-Programm (oder eben dem BIOS) nicht gleich Grossputz zu machen. Sondern zu erkennen, dass im RAM sinnvoller Inhalt ist, der genutzt werden will.
Michael_ schrieb: > Axel Schwenke schrieb: >> Ein Monitorprogramm, das nach jedem Hardware-Reset einen Kaltstart [1] >> macht, ist keinen Pfifferling wert. Es braucht eine wenigstens halbwegs >> zuverlässige Heuristik, um zu entscheiden ob ein Kaltstart oder >> Warmstart erforderlich ist. > > Vom Z-80 scheinst du keine Ahnung zu haben. Hardware-Reset ist > Hardware-Reset! Und du scheinst nicht lesen zu können. Natürlich startet der Z80 nach einem Reset immer bei 0000H. Aber was er dann macht, bestimmt das Monitorprogramm. Und wie bereits dargelegt, wäre es höchst kontraproduktiv, wenn es dann immer einen Kaltstart macht. XL
> Denn der hat es in sich und erzeugt fehlerhaften Code bzw wenn man > nicht Dinge tut, die andere schon herausgefunden haben, die aber > nicht im Manual stehen und auch nicht behoben worden sind. Och und ich dachte schon, das hätte sich zu meinem sdcc-Ärger im 8051-Mode von vor 14 Jahren mal irgendwie gebessert...
Georg A. schrieb: >> Denn der hat es in sich und erzeugt fehlerhaften Code bzw wenn man >> nicht Dinge tut, die andere schon herausgefunden haben, die aber >> nicht im Manual stehen und auch nicht behoben worden sind. > > Och und ich dachte schon, das hätte sich zu meinem sdcc-Ärger im > 8051-Mode von vor 14 Jahren mal irgendwie gebessert... Naja... so ganz frisch ist die Support Homepage auch nicht mehr... hüstl 17.05.09 Added a simple keyboard driver by Manoel Andrade Added a tool source by Stephan Le Meunier for counting machine cycles (mcs51) Ich schau dem Kleinen grad die ganze Zeit beim "Bit-Schaufeln" zu, wenn die LED anzeigen wo er grad ist beim RAM umschaufeln ....echt retro sowas :-) Ok, die Programmierung ist Einheitsbrei aber bald werde ich sicherlich noch voller Entzückung das Assembler-Gestammel lernen.... was schreibt sich eigentlich schneller? foo |= (1<<nr); // 2s zum tippen... oder incl "überlegen" das hier. Gefühlt 3 Minuten....
1 | ld a,4 (ix) |
2 | inc a |
3 | push af |
4 | ld e,#0x01 |
5 | pop af |
6 | jr 00110$ |
7 | 00109$: |
8 | sla e |
9 | 00110$: |
10 | dec a |
11 | jr NZ,00109$ |
12 | ld a,d |
13 | or a, e |
14 | ld d,a |
15 | jr 00103$ |
Ein Blick auf die Stromanzeige des Netzteils lässt allerdings die Frage aufkommen, ob Batterie-Applikationen vielleicht nicht so ganz angebracht waren damals... die NMOS CPU, die seit 1985 nicht mehr benutzt wurde ist erstens sehr heiss und auch der Rest hat einen gesunden Durst, 180mA die ganze Platine.
Das ist weniger als 1 Watt Leistung und völlig Ok. > inc a > push af > ld e,#0x01 > pop af > jr 00110$ Wozu push af und pop af? Ein Z80 hat Befehle für Bitmanipulation. Gruß, Holm
Christian J. schrieb: > die NMOS CPU, die seit 1985 nicht mehr benutzt wurde ist > erstens sehr heiss und auch der Rest hat einen gesunden Durst, 180mA die > ganze Platine. Ist doch völlig ok. NMOS heisst Dauerstrom, ob sie rennt oder pennt.
Christian J. schrieb: > oder incl "überlegen" das hier. Gefühlt 3 Minuten.... Der Compiler hat dafür garantiert keine 3 Minuten gebraucht, und auch keine 2 Sekunden. Wer auf die Idee kommt, sowas zu programmieren, und kein Compiler ist, ist ja wohl mit dem Klammerbeutel gepudert. Holm Tiffe schrieb: > Wozu push af und pop af? > Ein Z80 hat Befehle für Bitmanipulation. Wahrscheinlich hat er die Optimierung nicht eingeschaltet.
push af ld e,#0x01 pop af Das verstehe ich ehrlich gesagt auch nicht..... Optimierungen sind ein, aber ich habe das Gefühl, dass er mit dynamischen Variablenb, also Overlays auch Probleme hat. Der sheint die immer static anzulegen.
Axel Schwenke schrieb: > Natürlich startet der Z80 nach einem Reset immer bei 0000H. Aber was > er dann macht, bestimmt das Monitorprogramm. Und wie bereits dargelegt, > wäre es höchst kontraproduktiv, wenn es dann immer einen Kaltstart > macht. Bei klassischen Z-80 war das nicht üblich. Da wurde alles neu initialisiert. Wenn man Flash hat, kann man leicht eine Variable ablegen, welche man beim Neustart abfragt. Damals wäre das höchstens mit einem gepufferten C-MOS-RAM gegangen. Dies war aber nicht üblich.
Hängt vom Anwendungsfall ab. Der KC85 hat beispielsweise den RAM beim Warmstart nicht neu initialisiert, damit langwierig von Kassette geladene Anwendungen erhalten blieben. Bei Editoren u.ä. konnte man selbst entscheiden, ob man den Datenbereich neu initialisiert haben wollte (BASIC, WORDPRO) oder nicht (REBASIC, REWORDPRO). Dazu braucht es keinen gepufferten CMOS SRAM, das ging auch ohne prima. Was den SDCC angeht... der ist leider ziemlich beschränkt in seinem Weltbild. Aber sonst kenne ich nur den z88dk als halbwegs aktuellen C-Compiler für Z80.
Michael_ schrieb: > Axel Schwenke schrieb: >> Natürlich startet der Z80 nach einem Reset immer bei 0000H. Aber was >> er dann macht, bestimmt das Monitorprogramm. Und wie bereits dargelegt, >> wäre es höchst kontraproduktiv, wenn es dann immer einen Kaltstart >> macht. > > Bei klassischen Z-80 war das nicht üblich. Da wurde alles neu > initialisiert. Mit Verlaub, aber das ist Unsinn. Für die hier diskutierte Geräteklasse der Eigenbau-Computer gibt es gar kein üblich. Da waren die Monitore / BIOSe handgeklöppelte Einzelanfertigungen und haben gemacht was ihr Herrchen für sinnvoll hielt, nicht was üblich war (nach wessen Maßgabe eigentlich?). Aber auch der Z9001 aka KC87 hat z.B. sein RAM nach einem Reset nicht gelöscht. U.a. damit von Kassette nachgeladene Betriebssystemerweiterungen erhalten blieben. > Wenn man Flash hat, kann man leicht eine Variable ablegen, welche man > beim Neustart abfragt. > Damals wäre das höchstens mit einem gepufferten C-MOS-RAM gegangen. Dies > war aber nicht üblich. Jo. Und genau deswegen sprach Winfried von einem Flag im RAM. Weil RAM damals das einzige war, wo man sowas ablegen konnte. Und natürlich bringt das seine eigenen Probleme mit sich. Z.B. daß so ein Flag nach dem Kaltstart auch zufällig im RAM stehen kann. Weswegen man essentielle Initialisierungen (Stack, Interrupt-Vektoren) immer machen muß. Oder daß man bei einem Reset im laufenden Betrieb irgendwie den Refresh von evtl. vorhandenem DRAM sicherstellen muß. Aber nur weil du sowas nie gesehen (wohl eher: immer übersehen) hast und dir nie Gedanken darüber machen mußtest, heißt ja nicht daß es das nicht gab oder gibt. XL
naja, ich komm halt vom ATARI mit seiner 65C02. Die hatte auch nur RESET (auf 0xFFFF) aber die Resetroutine des Original-BIOS fragte als erstes das Warmflag im RAM ab, danach entschied sie über Kalt~ oder Warmstart. Im Kaltstartfall wurde dann mal gleich die Zeropage (0x000-0x400) initialisiert. Hier fanden sich alle nötigen Variablen und Vektoren des BIOS, da dieser RAM-Bereich mit minimaler Taktzyklenzahl zu lesen und zu schreiben war. ... Ich habe dann das Bios mit meinem Modifikationen in RAM Bänke hinter dem BIOS Rom geladen und dann mit gesetztem Warmflag das ROM abgesaltet und einen Reset ausgelöst schon lief mein Bios aus dem RAM und konnte 1MB in 16kB Blöcken einblenden das war schon recht ordentlich für einen 8-Bitter. ich meine damals auch aus der ZX-Spectrumecke solches gehört zu haben und muss mich schon sehr wundern hier so abgebürstet zu werden. eigentlich wa mir nur daran gelegen auf mögliche fehlerquellen in Startroutinen hinzuweisen. Aber sollte der TO daran weiters kein Interesse haben.... Ich hab auch genug anderes zu tun. @ Axel wir sind wohl zu alt für diese Retrowelt. Da ist ein Geradeausämpfänger das Grösste. Einen DoppelSuper baut hier keiner nach, geschweige ein vernünftiges BIOS. PS meinen Monitor habe ich natürlich auch selbst erweitert und in Assembler daran rumgestrickt. mit C Habe ich erst beim 386 angefangen. Namaste
Axel Schwenke schrieb: > Mit Verlaub, aber das ist Unsinn. Für die hier diskutierte Geräteklasse > der Eigenbau-Computer gibt es gar kein üblich. Da waren die Monitore / > BIOSe handgeklöppelte Einzelanfertigungen und haben gemacht was ihr > Herrchen für sinnvoll hielt, nicht was üblich war (nach wessen Maßgabe > eigentlich?). Aber auch der Z9001 aka KC87 hat z.B. sein RAM nach einem > Reset nicht gelöscht. U.a. damit von Kassette nachgeladene > Betriebssystemerweiterungen erhalten blieben. Habs mir mal angeschaut. Reset ist eben nicht Reset. Beim obigen ist es eher ein Soft-Wiederstart. Einen richtigen kriegt man nur durch ziehen des Netzsteckers wieder hin. Oder man trägt softwaremäßig die Initialisierung ein. Übrigens wollte ich damals wissen wie es geht. Deshalb kein Z9001, sondern AC-1, LC-80, Z-1013. Letzterer mit ROM-Bank, 256K RAM, eigener Monitor (damit ist nicht der BS gemeint), TDL-Basic, Gens-Assembler usw. Alles nicht von der Stange, da mußte man schon im Gegensatz zu Z9001 o.ä. ein paar graue Zellen opfern.
Angehängte Dateien:
-
DSC08156__1280_x_1024_.jpg
110 KB
Hallo, heute kam sie an, die "Special Edition Retro CPU" mit Firmenaufdruck. NMOS und wird schön warm :-) Gruss, Christian
Axel Schwenke schrieb: > Jo. Und genau deswegen sprach Winfried von einem Flag im RAM. Weil RAM > damals das einzige war, wo man sowas ablegen konnte. Und natürlich > bringt das seine eigenen Probleme mit sich. Z.B. daß so ein Flag nach > dem Kaltstart auch zufällig im RAM stehen kann. Luxusproblem. ;-) Über solche Probleme stolpert man nämlich erst, wenn man - faul wie man trotz Retro ja doch ist - statt einer Handvoll 4116 DRAMs modernere SRAMs verwendet. Bei DRAMs konnte man sich nämlich ziemlich drauf verlassen, dass nach ausreichend langer Zeit ohne Strom ein sinnvoll gewähltes Flag im RAM nicht den Warmstart-Wert enthält. Da war kein Zufall am Werk, sondern bloss ein paar Kondensatoren. Zumindest wenn man die Möhre nicht in der Tiefkühltruhe betrieben hat. Je kälter die Umgebung desto wärmer der Start. ;-) PS: Wenn man in der Geschichte noch weiter zurück geht, also vor die Ära des Z80 und der Halbleiter-RAMs, dann wird das noch interessanter. Da brauchts zwingend eine Unterscheidung zwischen Kalt- und Warmstart per Schalter, sonst wird das nie was. Ringkernspeicher war nicht-volatil.
Michael_ schrieb: > TDL-Basic, Hallo! Leider habe ich mein handkommentiertes Disassembler-Listing irgendwo verlegt oder weggeworfen. Bevor ich noch aus dem 12K Maschinencode die restlichen Fehler gefunden hatte, war BASIC nicht mehr ganz so wichtig für mich. Es war aber erstaunlich leistungsfähig und umfangreich. Die Programmierer von von Technical Design Labs hatten eine Reihe von Tricks verwendet, um die Relokation (assemblieren für einen anderen Speicherbereich) zu erschweren. Das Reinspringen, mitten in sonst vernünftige Drei-Byte-Befehle, war so ein Trick.
Sowas hier?
1 | ; This is the commented BASIC listing of the |
2 | ; TDL 12K Extended "Zapple" BASIC, |
3 | ; by Roger Amidon and Neil Colvin, May 1977 |
4 | ; |
5 | ; This was produced by IDA disassembler |
6 | ; and further modified for readability (macros and long symbols) |
7 | ; note this is, although it looks like, not correct Z80 assembler |
8 | ; to be directly fed into an assembler program - mainly because |
9 | ; many symbols are too long for Z80 assemblers |
10 | ; use this as reference only, rather use the HEX dump |
11 | ; to produce a binary. |
12 | ; |
13 | ; The HEX dump has been compared with this commented file; |
14 | ; while commenting, several OCR errors were corrected. |
15 | ; |
16 | ; The hex dump was produced from the book |
17 | ; Rolf-Dieter Klein, Basic-Interpreter, Franzis Verlag M<FC>nchen, 1982; |
18 | ; in German language, ISBN 3-7723-6941-3 |
19 | ; The book author himself mentions in the book that he published |
20 | ; the hex dump because "Der Interpreter wurde urspruenglich von |
21 | ; TDL (Technical Design Labs) entwickelt und ist sehr leistungsfaehig. |
22 | ; Da die Firma nicht mehr existiert, soll durch den Abdruck des Listings |
23 | ; dem Leser die Moeglichkeit gegeben werden, Zugang zu diesem Basic zu |
24 | ; erhalten." (Seite 103) (Translation: the interpreter was developed |
25 | ; originally by TDL (Technical Design Labs) and is very powerful. |
26 | ; Because the company is no longer in existance, the reader is given |
27 | ; the chance, by printing this listing to get access to this Basic). |
28 | ; |
29 | ; The work of reverse engineering and commenting was done by Holger Veit, |
30 | ; 2012 - this whole work is published unter Creative Commons License |
31 | ; CC-BY-SA http://creativecommons.org/licenses/by-sa/3.0/ |
32 | |
33 | ;-------------------------------------------------------------------- |
34 | |
35 | ;**************************************************************** |
36 | ; some macro definitions for readability |
37 | CPHL_DE macro |
38 | ld a, h |
39 | sub d |
40 | jr nz, @@1 |
41 | ld a, l |
Da kann ich glaube ich helfen... http://www.tiffe.de/Robotron/Zapple-Basic/ Gruß, Holm
Holm Tiffe schrieb: > Da kann ich glaube ich helfen... > > http://www.tiffe.de/Robotron/Zapple-Basic/ > > Gruß, > > Holm und wie benutzt man diesen basic interpreter? muss man den an ein terminal anbinden? wie speichert er den quelltext usw?
Christian J. schrieb: > und wie benutzt man diesen basic interpreter? muss man den an ein > terminal anbinden? wie speichert er den quelltext usw? Doku ist doch dabei. Fernschreiber mit Lochstreifen-Stanzer/Leser waren damals gleichermassen Terminal, Drucker und Massenspeicher. Manche Bastler verwendeten auch alte Telex-Geräte mit dem eigentümlichen 5-Bit Baudot-Code, weil die hierzulande leichter zu kriegen waren als ASCII-Geräte. Das Basic arbeitete wie damals häufig über eine Sprungleiste, d.h. die Schnittstelle ist anpassbar. Das Arbeitsprinzip freilich nicht.
Ok. Dachte man könnte den Quelltext in einen Speicherberei laden und er zieht sich dann Zeile für Zeile rein. Dann müsste man nur noch die putchar Funktion anpassen und hätte eine Ausgabe.
Angehängte Dateien:
-
Basic1.png
43 KB -
BasicTDL1.png
39 KB -
BasicTDL2_1.jpg
720 KB
kennt Route_66 schrieb: > Hallo! > Leider habe ich mein handkommentiertes Disassembler-Listing irgendwo > verlegt oder weggeworfen. Bevor ich noch aus dem 12K Maschinencode die > restlichen Fehler gefunden hatte, war BASIC nicht mehr ganz so wichtig > für mich. Ja, einige Zeit später war ich stolzer Besitzer eines 286/12 mit Hercules. Ich hab aber meine Mappe wiedergefunden. Im ersten Bild ist der Anfang des Listings vom TDL. Vielleicht weiß jemand die Quelle. Wenn es rechtliche Probleme gibt, bitte löschen. Es stimmt mit dem ZAPPLE überein. Warum hieß das dann so? Über die Sprungtabelle und Änderungen des Codes hab ich es an den Z-1013 angepasst. Es lief dann prima. Die Abspeicherung hab ich dann zuletzt mit dem Header-Save von Brosig gemacht. Als Beispiel, wie mühsam es damals war, hab ich noch zwei Bilder angehängt. Per Hand analysiert und so Änderungen auch eingepflegt. Ohne Assembler! Drucken konnte ich auch schon mit einer S3004 Typenrad -Schreibmaschine. Da mußte man aber rausgehen und die Tür schließen, wenn die losgehämmert hat.
Angehängte Dateien:
-
DSC08157__1280_x_1024_.jpg
110 KB
So, auch bei mir geht es weiter, klappte auf Anhieb die Anzeige und auch die Port Ansteuerung. Geht rihtig gut mit dem SDCC wenn man sich mit putty ein Terminal zum Cubietruck Linux Rechner öffnet, wo der Z80 Code per Bash Script kompiliert wird, dann Notepad ++ für den Source über das Samba Laufwerk und den Brenner, der sich sofort jeden veränderten Code automatisch reinzieht. Der TOP853 taugt schon. Nur jetzt mit 28C64B EEPROM statt der EPROM, das nervt doch zu sehr mit dem Löschen. Gebe gerne so rund 20 Stück ab. Schon schön, wie man Hardware einfach einmappen kann, reicht ein 8-fach D-Flip Flop dazu und schon hat man eine Portweriterung. Der I/O Bus, die Select Ausgänge des Demuxers und Ints sowie die Ports werdenn noch hinten über Pfosten herausgführt, eine Erweiterungsplatine ist schon in der Planung, die noch ein bisschen mehr Spielkram drauf haben wird. Aber erstmal den STI Baustein anschliessen, die Uart und Timer zu Laufen kriegen, damit ich Interrupts habe (muss in Asm gemacht werden, der SDCC kann das nicht) und eine Kommunikation mit dem PC herstellen. Das unten stehende Programm erzeugt 468 Bytes Code. Nur printf, sprintf sollte man nicht verwenden, dann explodiert der Code regelrecht. Evtl. werde ich doch noch 16kb einplanen und das RAM ein wenig kürzen auf 48kb. Eine Leitung ändern reicht ja.
1 | #include <asm/z80/features.h> |
2 | #include <stdlib.h> |
3 | #include <stdio.h> |
4 | #include <math.h> |
5 | #include <malloc.h> |
6 | #include <string.h> |
7 | |
8 | #include "main.h" |
9 | |
10 | |
11 | const char digits[11]= {0xc0,0xf5,0xa8,0xb0,0x95,0x92,0x92,0x82,0xf4,0x80,0x90};
|
12 | |
13 | |
14 | // PIO 8255 Special I/O |
15 | __sfr __at 0x20 PIO8255_PORT_A; |
16 | __sfr __at 0x21 PIO8255_PORT_B; |
17 | __sfr __at 0x22 PIO8255_PORT_C; |
18 | __sfr __at 0x23 PIO8255_CNTRL; |
19 | |
20 | // ADC 0804 |
21 | __sfr __at 0x40 ADC0804_READ; |
22 | |
23 | // 7b Segment |
24 | __sfr __at 0x60 SEG7; |
25 | |
26 | #define MAX_RAM 40000 |
27 | uint8_t ram[MAX_RAM+1]; |
28 | |
29 | // NMI Interrupt Handler |
30 | void cv_vint(void) |
31 | {
|
32 | __asm |
33 | halt |
34 | __endasm ; |
35 | |
36 | } |
37 | |
38 | // Halte CPU an und lasse LED leuchten |
39 | void stop_cpu() |
40 | {
|
41 | __asm |
42 | halt |
43 | __endasm ; |
44 | } |
45 | |
46 | // Setze oder lösche eine LED (0..7) am Port A |
47 | // Input: Led Nr, HIGH oder LOW |
48 | void SetLed(uint8_t lednr, bool stat) |
49 | {
|
50 | uint8_t foo; |
51 | |
52 | // Read... |
53 | foo = PIO8255_PORT_A; |
54 | // Modify... |
55 | if (stat==TRUE) // LED ein = Bit LOW |
56 | foo &= ~(1<<lednr); |
57 | else |
58 | foo |= (1<<lednr); |
59 | // Write... |
60 | PIO8255_PORT_A = foo; |
61 | } |
62 | |
63 | // Zeitverzögerung |
64 | void delay(uint16_t cnt) {
|
65 | volatile uint16_t k; |
66 | for (k=0;k<cnt;k++); |
67 | } |
68 | |
69 | /* |
70 | Stelle die Peripheriebausteine ein |
71 | */ |
72 | void InitHardware() |
73 | {
|
74 | // 8255: Mode 0: Port A,B,C Output |
75 | PIO8255_CNTRL = 0x80; //Mode 0: Port A,B,C Output |
76 | PIO8255_PORT_A = 0xff; |
77 | PIO8255_PORT_B = 0; |
78 | PIO8255_PORT_C = 0; |
79 | |
80 | // 7-Segment .... |
81 | SEG7 = 0xff; |
82 | |
83 | // Interrupts der STI |
84 | |
85 | // STI Multi I/0 Uart |
86 | } |
87 | |
88 | int main() |
89 | {
|
90 | uint8_t n,i; |
91 | uint16_t k; |
92 | |
93 | InitHardware(); |
94 | |
95 | for (n=0;n<10;n++) {
|
96 | SetLed(0, HIGH); |
97 | SetLed(7, HIGH); |
98 | delay(5000); |
99 | SetLed(0, LOW); |
100 | SetLed(7, LOW); |
101 | delay(5000); |
102 | } |
103 | delay(20000); |
104 | |
105 | n = 0; |
106 | i = 0; |
107 | while (1) {
|
108 | |
109 | SEG7 = digits[i++]; |
110 | if (i>9) |
111 | i=0; |
112 | |
113 | // RAM vollschreiben |
114 | for (k=0;k<MAX_RAM;k++) {
|
115 | PIO8255_PORT_A = ~(uint8_t)k; |
116 | ram[k] = n; |
117 | } |
118 | // Ram auslesen und darstellen |
119 | for (k=0;k<MAX_RAM;k++) {
|
120 | PIO8255_PORT_A = ~ram[k]; |
121 | |
122 | } |
123 | |
124 | n++; |
125 | } |
126 | |
127 | } |
Hallo, hoffe bin hier mit meiner Anfrage nicht völlig falsch. Kennt sich jemand mit dem Elzet 80 System aus und wo man dafür noch Unterlagen findet. Würde mir gerne so ein System oder ähnlich aufbauen (nachbauen). Leider finde ich fast keine Informationen dazu und eine Anfrage beim Hersteller nach alten Unterlagen ist bis jetzt Erfolglos. Hatte zwar Steckkarten dafür in der Bucht gefunden für Preise wo man ins grübeln kommt und 2 Seiten wo auch über dieses System nach Schaltplan und Unterlagen gesucht wird. Gruß und Danke Ronny
Hallo, ich möchte nochmal zu meinem Projekt nachfragen wie es denn mit der Treiberleistung des Z80 ausschaut? Aktuell hängen am Datenbus - RAM - ROM - STI Multi I/O - ADC Konverter - 8255 PIO - 74HCT274 Latch gefühlt ist das schon recht viel. Es sollen auf einer weiteren Karte noch mehr Bausteine dazu kommen, vor allem Portexpander und ein weiterer Timer Z80 CTC Baustein Muss ich dann zb einen 74LS640 bidir. Octal Bustreiber zur Entkopplung einsetzen?
Christian J. schrieb: > ich möchte nochmal zu meinem Projekt nachfragen wie es denn mit der > Treiberleistung des Z80 ausschaut? Das Thema hatten wir oben schon abgehakt. Erinnerst du dich an das Bild der grossen Platine mit 19 ICs am Bus, aber keinem einzigen Bustreiber? Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" An den Datenbus zwischen CPU und Rest gepackt würde ein einzelner Treiber bei besagter Platine beim Lesen 18 Lasten auf 18 Lasten reduzieren ;-).
> Muss ich dann zb einen 74LS640 bidir. Octal Bustreiber zur Entkopplung > einsetzen? Ich habe bei mir zwischen Z80 und Bus zwei 74LS243 (Datenbus) und drei 74LS244 (Adress- und Steuerleitungen) gesetzt, aber wahrscheinlich ginge es auch ohne. Nachteil: DMA von hinter den Bustreibern geht damit nicht mehr, weil die Steuerleitungen nicht von der Peripherie getrieben werden können. Das kann man zwar vermeiden, ist aber nicht ganz trivial von der Logik. :-)
S. R. schrieb: > Ich habe bei mir zwischen Z80 und Bus zwei 74LS243 (Datenbus) und drei > 74LS244 (Adress- und Steuerleitungen) gesetzt Wenn das die einzigen Treiber sind, dann ist der Effekt auf den Datenbus gleich Null. Denn beim Lesen müssen Speicher und IO-Bausteine genauso viele Lasten treiben wie ohne Treiber. Solche Treiber ergeben sich ganz natürlich, wenn der Kram auf allerlei Platinen verteilt ist und in einer Backplane steckt. Dann hat jede Platine ihren eigenen Treiber zur Backplane. Ist alles auf einer Platine, dann ist ein einzelner Datenbustreiber ziemlich sinnarm. Treiber für Steuerleitungen und einen Teil der Adressleitungen können dann zwingend werden, wenn etliche TTLs dran hängen (Dekoder, Logik, ...) und die statische Last der betreffenden Leitungen zu gross wird, also der Strom. NMOS und CMOS Bausteine hingegen stellen keine statische Last dar, nur eine kapazitive. Da ist es also eine Frage des Timings, und man darf raten, ab wieviel Bausteinen die stärkeren Treiber eines 74LS244 mehr Zeit einsparen als die Durchlaufzeit dieses Bausteine an Zeit kostet. > Nachteil: DMA von hinter den Bustreibern geht damit nicht > mehr, weil die Steuerleitungen nicht von der Peripherie getrieben werden > können. Das kann man zwar vermeiden, ist aber nicht ganz trivial von der > Logik. :-) Aus der Hüfte geschossen hätte ich gesagt, /BUSAK schaltet die Treiber der CPU ab, wenn der DMA auf Seite der Peripherie platziert wird. Und wenn du den DMA Controller auf der CPU-Seite deiner Treiber platzierst, damit der DMA auch von denen profitiert, dann schaltet dessen /CS den Datenbustreiber ab und das wars. Denkfehler?
Angehängte Dateien:
Hi, danke für die Info, dachte ich mir insgeheim auch schon. Und eine Backplane gibt es ja nicht, nur eine aufsteckbare Zusatzplatine. Dann werde ich mich mal mit dem Mode 2 Ints befassen und wie ich die dem sdcc compiler beibringe, der dafür nichts an Bord hat und wie ich meine auch der schlechtest dokumentierte Compiler überhaupt ist. Glücklicherweise hat er in der crt0.s die Möglchkeit Startup Code in Asm zu hinterlegen und kann auch inline asm verarbeiten (wobei schon Fehlermeldungen kommen, wenn man eine Variable von Asm aus adressieren will, die lokal ist und nicht global, zb einen Funktionsparameter. Ich bin noch nicht über Seite 50 in dem Zaks Buch aber soweit ich das verstehe kann der Mostek STI verschiedene Ints auslösen und ist kompatibl zum Z80. Ist dieser Gedankengang richtig? Der Z80 des Z80 wird mit "IM2" auf Mode 2 gestellt, das I Register mit dem Hibyte einer Adresse geladen zb 0x0080. Da der SDCC nur ROM Code erzeugen kann muss sich, sagen wir bei 0x0080 eine Tabelle befinden, die auf gerade Sprungadressen im ROM verweist. zb .org 0x80 jp int_1 jp int_2 jp int_3 usw. Jezt frage ich mich gerade, da das Datenblatt des STI doch sehr intensv studiert werden muss, ob die zurück gelieferten Vektoren der 16 Interrupts fix sind also zb 0...15 oder ich dem STI noch beibringen muss, welche Vektoren er zurück liefert? Es liest sich so, dass er seine 16 Ints auf 4 Bits abbildet und ich die oberen selbst einstellen kann. Das Ganze müsste natürlich vorher genau ausgerechnet werden, damit die Ints auch ihr Ziel "treffen" und wie ich vermute kann der sdcc wohl nicht dazu bewegt werden Funktionen auf feste Plätze zu legen, sondern der klatscht sie alle hintereinander.
Christian J. schrieb: > gefühlt ist das schon recht viel. Praktisch aber nicht. Denn das was du heutzutage an den Bus hängst, ist alles CMOS und braucht so gut wie keine Treiberleistung, verglichen mit dem nMOS-Krempel der früher üblich war. Kritischer sind die Lastkapazitäten. Sowohl durch die Eingänge der getriebenen IC als auch durch die Verdrahtung. Das wird sich so bemerkbar machen, daß dein System oberhalb einer gewissen Taktfrequenz instabil wird. XL
Christian J. schrieb: > Ich bin noch nicht über Seite 50 in dem Zaks Buch aber soweit ich das > verstehe kann der Mostek STI verschiedene Ints auslösen und ist > kompatibl zum Z80. Ja. > erzeugen kann muss sich, sagen wir bei 0x0080 eine Tabelle befinden, die > auf gerade Sprungadressen im ROM verweist. Das ist eine Vektortabelle, 16 Bits pro Zieladresse, keine Sprungleiste. Also sinngemäss struct { void (*vec0)(void); void (*vec1)(void); void (*vec2)(void); ... void (*vec127)(void); }; > welche Vektoren er zurück liefert? Ebendies. Jeder Z80 Device, das direkt den IM2 unterstützt, enthält eine Register, das den verwendeten Vektorbereich definiert.
Axel Schwenke schrieb: > Praktisch aber nicht. Denn das was du heutzutage an den Bus hängst, ist > alles CMOS und braucht so gut wie keine Treiberleistung, verglichen mit > dem nMOS-Krempel der früher üblich war. In einem Retro Thread ist der Begriff "heutzutage" etwas unpassend und er hat folgerichtig etlichen NMOS Kram auf der Platine. Aber NMOS hat auch doch auch bloss MOS-Gates am Eingang, anders als TTLs. Unterschiedlich ist die Charakteristik der Ausgänge.
A. K. schrieb: > Das ist eine Vektortabelle, 16 Bits pro Zieladresse, keine Sprungleiste. > Also sinngemäss > struct { > void (*vec0)(void); > void (*vec1)(void); > void (*vec2)(void); > ... > void (*vec127)(void); > }; Noch schöner wäre es, wenn es möglich wäre ein .org 0x0080 vor diesen Struct zu setzen, wenn er als const definiert würde. Aber das geht leider nicht. >> welche Vektoren er zurück liefert? > > Ebendies. Jeder Z80 Device, das direkt den IM2 unterstützt, enthält eine > Register, das den verwendeten Vektorbereich definiert. Da das STI das einzige Z80 Bauteil ist böte sich demzufolge an, die frei definierbaren Bits auf 0 zu setzen. Langsam wird es interessant :-)
Christian J. schrieb: > Der Z80 des Z80 wird mit "IM2" auf Mode 2 gestellt, das I Register mit > dem Hibyte einer Adresse geladen zb 0x0080. Und schon falsch. Die Tabelle startet immer bei einem Vielfachen von 0x100. 0x0080 ist also gar nicht möglich. 0x0400 wäre möglich. Ins I-Register müßte dann eine 0x04 geschrieben werden. > Da der SDCC nur ROM Code > erzeugen kann muss sich, sagen wir bei 0x0080 eine Tabelle befinden, die > auf gerade Sprungadressen im ROM verweist. Ja. Adressen > zb > > .org 0x80 > jp int_1 > jp int_2 > jp int_3 > > usw. Nein. Das erzeugt keine Liste von Adressen (2 Byte pro Eintrag) sondern eine Liste von Sprungbefehlen. Das sind immer 3 Byte pro Eintrag: ein Byte Opcode 0xC3 und dann zwei Byte Adresse. > Das Ganze müsste natürlich vorher genau ausgerechnet werden, damit die > Ints auch ihr Ziel "treffen" und wie ich vermute kann der sdcc wohl > nicht dazu bewegt werden Funktionen auf feste Plätze zu legen, sondern > der klatscht sie alle hintereinander. Das macht man in C auch anders. Stichwort Funktionszeiger (Artikel Funktionszeiger in C). In Assembler würde man einfach die Label für die Einsprungpunkte der Funktionen referenzieren. Da C vorinitialisierte Variablen kennt, würde man für die Interrupt- Vektortabelle einfach ein Array VoidFnct[256] anlegen, mit den Adressen (= Funktionspointern) für die ISR initialisieren und das Array fest auf die gewünschte Adresse der Vektortabelle binden. Dann legt der Compiler die initialen Daten ins ROM und der Startupcode kopiert sie ins RAM. In Assembler würde man eher die Tabelle einmal löschen und dann die handvoll Einträge die man braucht händisch überschreiben.
Christian J. schrieb: > Da das STI das einzige Z80 Bauteil ist böte sich demzufolge an, die frei > definierbaren Bits auf 0 zu setzen. Wenn du die Tabelle nach 0x0080 legen willst, was durchaus geht, dann wärs besser, wenn du die Vektoren auch passend nutzt. Denn beim STI sind die IM2 Adressbits A4..A7 frei definierbar, und wenn du die alle auf 0 setzt, dann landest du beim I7 Interrupt auf 0x0000=Reset statt 0x0080.
Axel Schwenke schrieb: > Die Tabelle startet immer bei einem Vielfachen von 0x100. 0x0080 ist > also gar nicht möglich. 0x0400 wäre möglich. Ins I-Register müßte dann > eine 0x04 geschrieben werden. Doch, das geht. Er braucht ja nur 16 Stück = 32 Bytes, nicht alle 127. Also I=0 und die Vektoren bei 0x80-0x9F verwenden.
Axel Schwenke schrieb: > Praktisch aber nicht. Denn das was du heutzutage an den Bus hängst, ist > alles CMOS und braucht so gut wie keine Treiberleistung, verglichen mit > dem nMOS-Krempel der früher üblich war. Abgesehen vom CLOCK Pin sind die Lasten bei NMOS und CMOS Version der Z80 CPU exakt gleich definiert. 5pF pro Eingang, 15pF pro Ausgang (inkl. bidirektionale Pins). Das Timing spezifiziert Zilog für eine Last von 100pF, und zusätzliche 10ns pro zusätzliche 50pF Last, bis zusätzliche 100pF für Adressen/Steuerleitungen und 200pF für Datenleitungen. Wobei man aber nicht nur die Pins rechnen darf, die Verdrahtung zählt mit - Daumenregel 100pF/m, aber ob das auch auf Fädeltechnik mit dem extrem geringen Abstand benachbarter Leitungen zutrifft kann ich nicht sagen. Da ein SN74LS243 Treiber 12ns kostet ist man noch bei einer Buslast von insgesamt 150pF ohne Treiber schneller als mit.
A. K. schrieb: > Axel Schwenke schrieb: >> Die Tabelle startet immer bei einem Vielfachen von 0x100. 0x0080 ist >> also gar nicht möglich. 0x0400 wäre möglich. Ins I-Register müßte dann >> eine 0x04 geschrieben werden. > > Doch, das geht. Er braucht ja nur 16 Stück = 32 Bytes, nicht alle 127. > Also I=0 und die Vektoren bei 0x80-0x9F verwenden. Ja. Dann liegt aber nicht die Tabelle bei 0x0080, sondern nur der erste genutzte Eintrag. Kleiner aber feiner Unterschied. XL
A. K. schrieb: > Da ein SN74LS243 Treiber 12ns kostet ist man noch bei einer Buslast von > insgesamt 150pF ohne Treiber schneller als mit. Bei komplettem Treibersatz, also Adress-, Steuer- und Datenleitungen hat man diese 12ns gleich zweimal an der Backe. Bei der grossen Platine mit rund 300pF am Datenbus musste eben etwas Reserve ins Timing rein, aber man war grad noch innerhalb von Zilogs Limit.
A. K. schrieb: > Wenn du die Tabelle nach 0x0080 legen willst, was durchaus geht, dann > wärs besser, wenn du die Vektoren auch passend nutzt. Denn beim STI sind > die IM2 Adressbits A4..A7 frei definierbar, und wenn du die alle auf 0 > setzt, dann landest du beim I7 Interrupt auf 0x0000=Reset statt 0x0080. Also das kann irgendwie nicht sein, ohne mir jetzt I genau angeschaut zu haben. I gibt das MSB vor, also schonmal etwas was ICH ihm sage, also zb Tabelle bei 0x100. Das IO gibt den Rest vor, also 3 wählbare Bits und 4 für die 16 Ints. Ergo Zieladresse = I-Reg + (3 Bits vom STI) + (Interrupt Nummer) Kämpfe grad damit, bin nicht so fit in "Spezial-C", dass ich jetzt gleich die richtige Syntax für Zeiger auf Funktionen wüsste, die noch als const abgelegt sind. Klappt aber laut Hex Dump so auch. Es wird eine Tabelle erzeugt, die die Adresse der C Routinen enthält, wenn ich mir das Hex Dump anschaue. Nur muss ich wohl jeden Int, auch die die ich nicht brauche auf Routinen umlegen, damit keine Löcher entstehen.
1 | ;-------------------------------------------------------------------------- |
2 | ; crt0.s - Generic crt0.s for a Z80 |
3 | ;-------------------------------------------------------------------------- |
4 | |
5 | |
6 | .module crt0 |
7 | .globl _main |
8 | .globl _nmi_vint |
9 | .globl _int_sti_gpi_0 ; General Purpose Interrupt 0 |
10 | .globl _int_sti_gpi_1 ; General Purpose Interrupt 1 |
11 | .globl _int_sti_gpi_2 ; General Purpose Interrupt 2 |
12 | .globl _int_sti_gpi_3 ; General Purpose Interrupt 3 |
13 | |
14 | |
15 | |
16 | |
17 | .area _HEADER (ABS) |
18 | |
19 | ;/////////////////////////////////////////////////////////// |
20 | ; Reset vector bei Kaltstart |
21 | .org 0 |
22 | jp init ;; Sprung in die Init Routine |
23 | |
24 | ;/////////////////////////////////////////////////////////// |
25 | ;// Mode 1 Interrupt |
26 | .org 0x38 |
27 | reti |
28 | |
29 | ;/////////////////////////////////////////////////////////// |
30 | ; NMI Interrupt 0x66, muss mit retn abgeschlossen werden |
31 | .org 0x66 |
32 | push af |
33 | push bc |
34 | push de |
35 | push hl |
36 | push iy |
37 | push ix |
38 | call _nmi_vint ; Aufruf Handler im C Modul main.c |
39 | pop ix |
40 | pop iy |
41 | pop hl |
42 | pop de |
43 | pop bc |
44 | pop af |
45 | retn |
46 | |
47 | ;/////////////////////////////////////////////////////////// |
48 | ; Tabelle der Mode 2 Int Vektoren auf die Handler Funktionen |
49 | ;.org 0x80 |
50 | .dw _int_sti_gpi_0 |
51 | .dw _int_sti_gpi_1 |
52 | .dw _int_sti_gpi_2 |
53 | .dw _int_sti_gpi_3 |
54 | |
55 | |
56 | init: |
57 | ;; Stack an Spitze des RAM legen |
58 | ld sp,#0xffff |
59 | |
60 | ;; Globale Variablen initialisieren |
61 | call _main ;; Hauptprogramm aufrufen |
62 | halt |
63 | |
64 | ;; Ordering of segments for the linker. |
65 | .area _HOME |
66 | .area _CODE |
67 | .area _GSINIT |
68 | .area _GSFINAL |
69 | .area _GSINIT |
70 | .area _DATA |
71 | .area _BSEG |
72 | .area _BSS |
73 | .area _HEAP |
Christian J. schrieb: > Muss ich dann zb einen 74LS640 bidir. Octal Bustreiber Ich wusste doch, dass an dem was nicht stimmt... Ok, der geht im Prinzip schon. Aber ich schätze dass du bald den Spass dran verlierst, wenn du sämtliche Peripherie-Bits und IM2-Vektoren invertiert interpretieren musst. ;-)
In Mode 2, the programmer maintains a table of 16-bit starting addresses for every interrupt service routine. This table can be located anywhere in memory. When an interrupt is accepted, a 16-bit pointer must be formed to obtain the required interrupt service routine starting address from the table. The upper eight bits of this pointer is formed from the contents of the I Register. The I register must be loaded with the applicable value by the programmer, such as LD I, A. A CPU reset clears the I Register so that it is initialized to 0. The lower eight bits of the pointer must be supplied by the interrupting device. Only seven bits are required from the interrupting device, because the least-significant bit must be a 0. This process is required, because the pointer must receive two adjacent bytes to form a complete 16-bit service routine starting address; addresses must always start in even locations. Soviel zum Manual. Boah, dieses zehnmal über die Ecke indirekt indiziert denken macht mir nen Knoten ins Hirn :-( Da ich die Tabelle in der Zeropage liegen habe muss also das I Register = 0 sein.
Und bevor ich dne Text oben nicht mehr ändern kann, weil der nächste Beitrag kommt hier meine Vorstellung: I = 0x80 setzen, d.h. MSB = 0 STI Vektorregister auf 0, diese 3 Bits da drin STI löst Interrupt 3 aus und legt "0+3" auf den Bus, also 3 Z80 baut zusammen: I + "3" und landet bei 0x80 + (3 * 2Bytes) = 0x86 Bei 0x86 steht ein Doppelwort, also zb 1234 Z80 führt ein JMP 3412 aus, da zuerst Low, dann High Byte Soweit ok?
Christian J. schrieb: > Also das kann irgendwie nicht sein, ohne mir jetzt I genau angeschaut zu > haben. Herrje, immer diese Ungläubigen :-) Vektoradresse: A15..A8 = I A7..A5 = D7..D5 des PVR vom STI A4..A1 = Interrupt-Nummer A0 = 0 Wenn du auf 0x80 für den ersten Vektor kommen willst, dann muss 0b100 in D7..D5 des PVR.
Christian J. schrieb: > Z80 baut zusammen: I + "3" und landet bei 0x80 + (3 * 2Bytes) = 0x86 Bloss weil die Z80 CPU so heisst, zaubert die dir keine magischen 0x80 in die Rechnung. Dein Vektor landet auf 0x0006.
A. K. schrieb: > Bloss weil die Z80 CPU so heisst, zaubert die die keine 80 in die > Rechnung. Dein Vektor landet auf 0x0006. Ok, das konnte ich nicht mehr ändern weil du schneller warst. Die 80 müssen vom STI kommen, was ich aber nicht so dolle finde. Aber über das I Reg lassen sich ja nur 0x100er Felder abdecken und bei 8k muss man schon etwas sparsam sein zudem der Compiler noch dazu kommt, denn der darf den Code nicht plattmachen, er weiss ja nichts von dieser Tabelle, wenn ich die erst zur Laufzeit erzeuge bzw einstelle. >Bei 0x86 steht ein Doppelwort, also zb 1234 >Z80 führt ein JMP 3412 aus, da zuerst Low, dann High Byte >Soweit ok? Da ist richtig denke ich mal.
Wenn es dir um Platz geht, dann leg die Tabelle auf die unbenutzten Adressen 0x0040-0x005F und definiere PVR[7-5]=0b010 und I=0x00. Ob du das nun toll findest oder nicht. Dein Programm kann dann direkt hinter dem NMI anfangen. Wenn dir der Platz egal ist, dann nimm 0x0100-0x011F mit PVR[7-5]=0x000 und I=0x01.
Angehängte Dateien:
-
Unbenannt.JPG
62 KB
Ok, da ist noch Platz :-) Auf jeden Fall assembliert er jetzt fehlerfrei durch und auch der C Compiler mecker nicht.
1 | .module crt0 |
2 | .globl _main |
3 | .globl _nmi_vint |
4 | .globl _int_sti_gpi_0 ; General Purpose Interrupt 0 |
5 | .globl _int_sti_gpi_1 ; General Purpose Interrupt 1 |
6 | .globl _int_sti_gpi_2 ; General Purpose Interrupt 2 |
7 | .globl _int_sti_gpi_3 ; General Purpose Interrupt 3 |
8 | |
9 | ;/////////////////////////////////////////////////////////// |
10 | ; Tabelle der Mode 2 Int Vektoren auf die Handler Funktionen |
11 | |
12 | .org 0x80 |
13 | .dw _int_sti_gpi_0 |
14 | .dw _int_sti_gpi_1 |
15 | .dw _int_sti_gpi_2 |
16 | .dw _int_sti_gpi_3 |
Und später im .c File
1 | void int_sti_gpi_0(void) |
2 | {
|
3 | |
4 | } |
5 | |
6 | void int_sti_gpi_1(void) |
7 | {
|
8 | |
9 | } |
10 | void int_sti_gpi_2(void) |
11 | {
|
12 | |
13 | } |
14 | void int_sti_gpi_3(void) |
15 | {
|
16 | |
17 | } |
Muss das aber noch im De-Assembler kontrollieren. Ergibt
1 | 354 ; --------------------------------- |
2 | 355 ; Function int_sti_gpi_0 |
3 | 356 ; --------------------------------- |
4 | 0149 357 _int_sti_gpi_0_start:: |
5 | 0149 358 _int_sti_gpi_0: |
Also Adresse 0x100 + 0x149 = 0x249 und im Map steht.
1 | 00000249 _int_sti_gpi_0 main |
2 | 00000249 _int_sti_gpi_0_start main |
3 | 0000024A _int_sti_gpi_0_end main |
4 | 0000024A _int_sti_gpi_1 main |
5 | 0000024A _int_sti_gpi_1_start main |
6 | 0000024B _int_sti_gpi_1_end main |
7 | 0000024B _int_sti_gpi_2 main |
8 | 0000024B _int_sti_gpi_2_start main |
9 | 0000024C _int_sti_gpi_2_end main |
10 | 0000024C _int_sti_gpi_3 main |
11 | 0000024C _int_sti_gpi_3_start main |
12 | 0000024D _int_sti_gpi_3_end main |
Im Asm Listing aber sind es Nullen. Allerdings assembliert er erst das Startup und linked dann alles zusammen, können also auch Platzhalter sein.
1 | Sxxxx Assembler V02.00 + NoICE + SDCC mods + Flat24 (Zilog Z80 / Hitachi HD64180), page 2. |
2 | |
3 | |
4 | |
5 | 0080 57 .org 0x80 |
6 | 0080 00 00 58 .dw _int_sti_gpi_0 |
7 | 0082 00 00 59 .dw _int_sti_gpi_1 |
8 | 0084 00 00 60 .dw _int_sti_gpi_2 |
9 | 0086 00 00 61 .dw _int_sti_gpi_3 |
Das Hex File sieht dann aber so aus.... wie in dem Bild und 02C9 ist ja nicht 0249. Häh??
Hier ist die Map Tabelle... den NMI setzt er richtig auf 0x137 mit CD 37 01 aber die .dw ..... sind falsch.
1 | Area Addr Size Decimal Bytes (Attributes) |
2 | -------------------------------- ---- ---- ------- ----- ------------ |
3 | _CODE 00000100 0000018F = 399. bytes (REL,CON) |
4 | |
5 | Value Global Global Defined In Module |
6 | ----- -------------------------------- ------------------------ |
7 | 00000100 _stop_cpu main |
8 | 00000100 _stop_cpu_start main |
9 | 00000102 _copyright main |
10 | 00000102 _stop_cpu_end main |
11 | 00000127 _digits main |
12 | 00000137 _nmi_vint main |
13 | 00000137 _nmi_vint_start main |
14 | 00000139 _InitHardware main |
15 | 00000139 _InitHardware_start main |
16 | 00000139 _nmi_vint_end main |
17 | 0000014E _InitHardware_end main |
18 | 0000014E _SetDigit main |
19 | 0000014E _SetDigit_start main |
20 | 00000174 _SetDigit_end main |
21 | 00000174 _SetLed main |
22 | 00000174 _SetLed_start main |
23 | 000001BB _SetLedByte main |
24 | 000001BB _SetLedByte_start main |
25 | 000001BB _SetLed_end main |
26 | 000001CC _SetLedByte_end main |
27 | 000001CC _delay main |
28 | 000001CC _delay_start main |
29 | 000001FA _LED_Rotate main |
30 | 000001FA _LED_Rotate_start main |
31 | 000001FA _delay_end main |
32 | 00000249 _LED_Rotate_end main |
33 | 00000249 _int_sti_gpi_0 main |
34 | 00000249 _int_sti_gpi_0_start main |
35 | 0000024A _int_sti_gpi_0_end main |
36 | 0000024A _int_sti_gpi_1 main |
37 | 0000024A _int_sti_gpi_1_start main |
38 | 0000024B _int_sti_gpi_1_end main |
39 | 0000024B _int_sti_gpi_2 main |
40 | 0000024B _int_sti_gpi_2_start main |
41 | 0000024C _int_sti_gpi_2_end main |
42 | 0000024C _int_sti_gpi_3 main |
43 | 0000024C _int_sti_gpi_3_start main |
44 | 0000024D _int_sti_gpi_3_end main |
45 | 0000024D _main main |
46 | 0000024D _main_start main |
47 | 0000028F _main_end main |
Angehängte Dateien:
-
Unbenannt2.JPG
100 KB
Ok, probieren geht über studieren, man muss Klammern setzen, da es ein Vektor ist... dann steht das richtige in der Tabelle drin. ;/////////////////////////////////////////////////////////// ; Tabelle der Mode 2 Int Vektoren auf die Handler Funktionen .org 0x80 .dw (_int_sti_gpi_0) .dw _int_sti_gpi_1 .dw _int_sti_gpi_2 .dw _int_sti_gpi_3
Nachwort: So, ich habe jetzt ein komplettes Programmgerüst für den SDCC Compiler für Z80 "Minisysteme" mit Nutzung der Interrupts, die mit einigen Workarounds eingebaut wurden, da der sdcc sie nicht unterstützt bzw nur marginall, zb durch __interrupt oder __naked Pragmas, die die Coderzeugung beinflussen. D.h. wenn jemand Spass an sowas hat aber weniger Assembler programmieren will oder nur da wo es nötig ist kann er von mir dieses Gerüst haben. Ich entwickle es noch um einiges weiter, es ist natürlich nur auf den STI angepasst und nicht auf andere Bausteine aber nirgendwo im Netz finden sich Informationen, die mit google findbar sind, die beschreiben wie das zu machen ist. Ich habe da Stunden gesucht, der sdcc ist sowas von wenig vertreten und erzeugt doch guten Code wenn man auf die Veewendung von Libs verzichtet, denn ein rand() knall mal eben 2000 Bytes Code dazu, wozu weiss keiner. Kann man das hier irgendwo ablegen, wenn es fertig ist?
A. K. schrieb: > Artikel dazu bauen. Bin zu blöd ein Wiki zu bedienen, da auch kein Interesse daran. Maixmal ein Plaintext File.
Christian J. schrieb: > Bin zu blöd ein Wiki zu bedienen, da auch kein Interesse daran. Maixmal > ein Plaintext File. Von Plaintext zum Wiki-Artikel ist der Schritt u.U. nicht sehr groß. Fang doch mit dem Textfile als Artikel an, der Rest findet sich dann...
A.K. !!!!!!!!!!!!!!!!!! Hilfe..... du hast mir doch den MK3801 empfohlen und den studiere ich jetzt grad mal näher. Hallo Baudrate? Der kann doch wohl nicht nur 1:1 und 1:16? Ich brauche ujnbedingt den async Mode, da ich nur USB Umsetzer habe und möglichst die bekannten Baudraten fahren will. Das steht nichts weiter von einem Prescaler drin...... Und alles ist schon eingebaut...
A. K. schrieb: > Wenn das die einzigen Treiber sind, dann ist der Effekt auf den Datenbus > gleich Null. Denn beim Lesen müssen Speicher und IO-Bausteine genauso > viele Lasten treiben wie ohne Treiber. Ja, aber dafür müssen dann die Einsteckkarten selbst sorgen. Die Treiber sitzen auf der Hauptplatine vor den Steckplätzen (und die Chips auf der Hauptplatine werden vom Z80 selbst gestrieben). > NMOS und CMOS Bausteine hingegen stellen keine statische > Last dar, nur eine kapazitive. NMOS braucht einen konstanten Stromfluss, um low-Pegel zu halten? > Aus der Hüfte geschossen hätte ich gesagt, /BUSAK schaltet die Treiber > der CPU ab, wenn der DMA auf Seite der Peripherie platziert wird. Und > wenn du den DMA Controller auf der CPU-Seite deiner Treiber platzierst, > damit der DMA auch von denen profitiert, dann schaltet dessen /CS den > Datenbustreiber ab und das wars. Denkfehler? Klingt logisch, aber ich habe ein paar Design-Entscheidungen getroffen, die das trotzdem verhindern. Da ich keine Z80-Peripherie benutze und auch sonst alles zu Fuß erledige, sind meine Slots nur I/O-fähig (bis auf den einen, wo der Speicher drin steckt) und der einzige DMA-Master sitzt auf der Hauptplatine. Einen DMA-Controller habe ich nicht. Beim nächsten Mal denke ich an dich. ;-)
Nochmal meiner einer: Ich sehe da nur eine Rettung bei dem Mostek 3801, man ja kaum mehr einen Suporter fragen kann: Timer C oder sind kastriert, können nur Delay. Ich vermute mal, dass die einfach endlos mit dem Prescaler Takt von 0..255 rennen und dann von vorn. Capture/Compare war ja wohl nicht vorgesehen (ich vermisse schcon wieder ARM Timer... der pure Luxus). Den Ausgang einer dieser Timer dann auf 1:x Teilen und diesen Ausgang an den RC und TC der USART gleichermaßen legen, damit die mit dem reduzierten Takt rumtackert und man sich irgendwie auf 56700 Baud einigt. Das Datenblatt ist so nett und spricht diesen Mode erst gar nicht an. Also muss ich 3.686.400 Hz des System Clock runterteilen / 64 und dann taketet er mit 56700 eins weiter. Aber das heisst ja noch nicht, dass der Timer Ausgang auch 56700 liefert. Wann wird der überhaupt gesetzt? Bei Überlauf von 255 auf 0? Oder zählen die wie es beim 8253 üblich war rückwärts und werden mit einem Reload Wert vorgeladen, denn sie immer wieder reinladen bei Überlauf? Etwas antike Technik.... Au weia.... Gibt aber Leute "Bitsavers", die sogar eine App.note gegescannt haben: http://schuetz.thtec.org/mccomputer/Mostek%20-%20MK3801%20Application%20Notes.pdf "Time Constant" scheint der Reload zu sein, 3 ist minimum damit 9600 baud bei rauskommen.
Christian J. schrieb: > Ich vermute mal Wie wäre es mit lesen? In der von dir zitierten App Note steht explizit drin, inklusive ASM-Schnipsel, wie man Timer C oder D als Baudraten Generator verwendet.
S. R. schrieb: >> NMOS und CMOS Bausteine hingegen stellen keine statische >> Last dar, nur eine kapazitive. > > NMOS braucht einen konstanten Stromfluss, um low-Pegel zu halten? Ein NMOS Eingang ist das Gate eines N-MOSFETs. Dass der intern eine Stromquelle am Drain hat, statt eines P-MOSFETs wie bei CMOS, das beeinflusst nur den Stromverbrauch des Chips. Bei einem NMOS Ausgang hast du Recht. Der hat eine Stromquelle als Pullup. Bei Ausgängen ist die CMOS Version der Z80 daher auch anders spezifiziert als die NMOS-Version, wesentlich höherer Source-Strom. Aber im Tristate ist diese Stromquelle abgeschaltet (wär ja sonst kein Tristate).
Christian J. schrieb: > Also muss ich 3.686.400 Hz des System Clock runterteilen / 64 und dann > taketet er mit 56700 eins weiter. Aber das heisst ja noch nicht, dass > der Timer Ausgang auch 56700 liefert. Die UART benötigt wie üblich die 16fache Frequenz am Takteingang. Das muss einer der Timer liefern. Bei mir wars damals 9600 Baud mit Prescaler /4 und Timerwert 4. Andere Timerwerte waren 1=38400 und 2=19200. Systemtakt unbekannt, demgemäss offenbar 2,4576MHz.
Hi, ich hatte das zweite Blatt der App nicht gesehen bzw hing der Reader etwas. Also läuft die Baudratenerzeugung auf der letzten Rille bei einem Wert von 3 oder 4, Finetuning kann man da vergessen. Nochmal zurück zu den Timern. Sind die vom 8253/54 abgekupfert? Das Mostek Datenblatt ist ja absolut unzureichend. Laufen die Timer also so, dass man ins Data Register einen Wert reinschreibt und die zählen dann rückwärts bis 0, setzen den Out Pin für einen Zykus HIGH und laden sich dann wieder den Startwert aus einem Latch rein? Wie gesagt sind heutige Timer deutlich aufwendiger und komplexer und ich erinnere mich nur schwach daran was ich mit 17 mal mit dem 8253 gemacht habe. Nur mal so gefragt: Hat das verkrampfte indirekte Adressieren einiger Register einen fertigungstechnischen Grund? Oder gingen denen die Pins aus, weil man dafür einen Adressierungspin mehr gebraucht hätte? Aktuell habe ich ja noch den sdasz80 Assembler, der eine "Eigenproduktion" von einem Brian ist und sich leider nicht an gängige Konventionen der Syntax hält. Leider ist er Bestandteil des sdcc. UNd bisher weiss auch niemand wie man aus einem inline asm Teile Variablen des C Teils anspricht. Allerdings stelle ich auch grad fest dass mans ich aus denb Linux Repos eine Version 3.1.0 von 2012 installiert. Zumindest wenn man sdcc auf einem A20 (Cubietruck) mit wheezy laufen lässt. Die Sourcen gibt es ja hier: http://sdcc.sourceforge.net/snap.php#Linux
Christian J. schrieb: > Also läuft die Baudratenerzeugung auf der letzten Rille bei einem > Wert von 3 oder 4, Finetuning kann man da vergessen. Was willst du denn da tunen? Fraktionale Baudratentimer gabs erst Jahrzehnte später, in Retro gibts die nicht. 57kbd und 115kbd gab es anno STI auch noch nicht. Manch olle UARTs konnten nicht mehr als 19200. > Nochmal zurück zu den Timern. Sind die vom 8253/54 abgekupfert? Nicht dass ich wüsste. Ich habe auch nicht den Eindruck, dass die Timer des STI sonderlich komplex wären. Und auch nicht, dass Komplexitität deine Spezialität wäre. ;-) > Das Mostek Datenblatt ist ja absolut unzureichend. Sieh es als frühe Form des Umweltschutzes ;-). Datasheets standen damals in Büchern, nicht in PDFs. Dickere Bücher kosteten mehr Bäume. Betrachte es doch mal als Herausforderung, nicht als Hindernis. > Laufen die Timer also so, Probiers halt aus. > Wie gesagt sind heutige Timer deutlich aufwendiger und komplexer Du bist ganz sicher, dass du es gerne komplexer hättest? Beim SIO hast du eben deshalb die Segel gestrichen und dabei war der deutlich einfacher als Zilogs SCC ein paar Jahre drauf. Retro gibts halt nicht ohne Retro-Stil. Oder fast nicht. Damals sass man rum, mit dem was man hatte, und probierte es im Zweifel eben aus, statt sich jedes Bit per Web erklären zu lassen. > Nur mal so gefragt: Hat das verkrampfte indirekte Adressieren einiger > Register einen fertigungstechnischen Grund? Ja. 41-PIN DIP Gehäuse sind sehr selten. ;-) > Aktuell habe ich ja noch den sdasz80 Assembler, der eine > "Eigenproduktion" von einem Brian ist und sich leider nicht an gängige > Konventionen der Syntax hält. Zugegeben, ich hatte meinen eigenen Assembler und "Compiler". Wie die funktionierten wusste ich zufällig. ;-) Allerdings gehst du mit dem Zwang, sofort unbedingt SDCC statt Assembler zu verwenden, den deutlich schwereren Weg eines Zweifrontenkriegs. Zudem ist das kein Bisschen Retro.
A. K. schrieb: > Was willst du denn da tunen? Fraktionale Baudratentimer gabs erst > Jahrzehnte später, in Retro gibts die nicht. 57kbd und 115kbd gab es > anno STI auch noch nicht. Manch olle UARTs konnten nicht mehr als 19200. Ich werde mit leben .....müssen. > Probiers halt aus. Ich erinnere mich schwach, dass ich Datenbücher aus der Bibliothek holte und ansonsten alle möglichen Hersteller anrief, damit sie mir welche schicken. Weil Internet... gab es ja nicht :-( Telefonbuch und Auskunft. Und bei Firmen schonmal Müllcontainer wo man sich Bücher rausholen konnte. > ohne Retro-Stil. Oder fast nicht. Damals sass man rum, mit dem was man > hatte, und probierte es im Zweifel eben aus, statt sich jedes Bit per > Web erklären zu lassen. Das werde ich gern machen.... ich frage sie ob sie vorwärts oder rückwärts laufen :-) > Zugegeben, ich hatte meinen eigenen Assembler und "Compiler". Wie die > funktionierten wusste ich zufällig. ;-) Das ist schon das erste Problem, weil die mehr programmieren als Dokus machen. Und wie ich grad mit Schreck festelle zieht sich Debian eine andere Version runter als Mint. Aber das liegt eben auch an mir, dass ich den ganzen Kram vom PC aus in einem Terminal auf dem Cubie mache und das grad umgestellt habe. Und ein Vergleich lieferte 50 Bytes weniger Code bei 3.3.0 gegenüber 3.1.,0 und auch einige Macros funktionierten plötzlich. > Allerdings gehst du mit dem Zwang, sofort unbedingt SDCC statt Assembler > zu verwenden, den deutlich schwereren Weg eines Zweifrontenkriegs. Zudem > ist das kein Bisschen Retro. Versteh mich nicht falsch, ich lese das Zaks Buch gern und schaue mir auch die Listings mit diesem prähistorischen Gebrabbel an: ld, cpl, in, out ... (wer das den ganzen Tag macht wird sicher impotent davon) aber ein 16 Bit c=a+b tippt sich eben deutlich schneller als ld a,-2 (ix) add a, -4 (ix) ld d,a ld a,-1 (ix) adc a, -3 (ix) ld -6 (ix), d Genauso mit den EPROMs.. die hier jetzt rumliegen und so schöne Fenster haben durch die man die Bits sehen kann ..... habe 3 Flash EEPROM gekauft und finde das deutlich entspannter die zu flashen anstatt den Toaster wieder rauszuholen und 20 Minuten zu warten bzw die ganze Stange erst durchzubrenne bis die Soft läuft und dann 20 EPROMs zu je 5 Stück wieder zu löschen. Nenn es den Sieg des Menschen über die Maschinen :-)
Christian J. schrieb: > Nenn es den Sieg des Menschen über die Maschinen :-) Oder die Kapitulation des Menschen vor der ihm auf ewig unverständlich bleibenden Maschine. ;-)
Angehängte Dateien:
-
00-37-23.jpg
190 KB
Wusstest Du dass der T1000 Terminator auf ner 6510 CPU läuft und dass der Code von Steve Wosniak geschrieben wurde auf einem Apple ][ ? Der war wohl auch "Retro" :-)
Christian J. schrieb: > aber ein 16 Bit c=a+b tippt sich eben deutlich schneller als > > ld a,-2 (ix) > add a, -4 (ix) > ld d,a > ld a,-1 (ix) > adc a, -3 (ix) > ld -6 (ix), d Wer macht denn sowas? ADD HL,rr (rr=BC,DE,HL,SP) existiert. fchk
Christian J. schrieb: > Wusstest Du dass der T1000 Terminator auf ner 6510 CPU läuft und dass > der Code von Steve Wosniak geschrieben wurde auf einem Apple ][ ? Immerhin. 1-2 Jahrzehnte lang sahen interaktive Computer-Szenen meist irgendwie nach C64 aus. Wenn du bissel suchst, kannst du vielleicht auch einen 16-Bit 6502 mit 16MB Adressraum programmieren. Gabs wirklich!
A. K. schrieb: > Wenn du bissel suchst, kannst du vielleicht auch einen 16-Bit 6502 mit > 16MB Adressraum programmieren. Gabs wirklich! Seit ich im Netz Seiten fand von Leuten, die sich ihre eigenen CPUs aus Gattern und Mikrocode im EPROM aufbauten, was sie der Echtheit auch noch hätten weglassen können haut mich nichts mehr um. Sicher wird auch irgendeiner bald ne CPU aus einzelnen Transistoren zusammen löten, weil er grad geschieden wurde und seitdem zu viel Zeit hat :-) Da ich mir grad bei wikipedia einiges über das Pipelining moderner CPU durchgelesen habe und wie das mit L1 und L2 Cache zusammen wirkt kommt mir der Gedanke, dass Assembler keine Chance mehr hat, da ein Programmierer sich nun wirklich nicht für das Innenleben einer Super CPU interessieren muss um effinzienten Code zu schreiben. Das kann ein Compiler besser wenn er weiss wie die Architektur funktioniert, so dass zb Pipline Flushes vermieden werden durch geschickte bedingte Sprünge usw.
> ich hatte das zweite Blatt der App nicht gesehen bzw hing der Reader > etwas. Also läuft die Baudratenerzeugung auf der letzten Rille bei einem > Wert von 3 oder 4, Finetuning kann man da vergessen. Ein Baudratenquarz macht, dass die Baudrate exakt ist. Was willst du da noch tunen? > Aktuell habe ich ja noch den sdasz80 Assembler, der eine > "Eigenproduktion" von einem Brian ist und sich leider nicht an gängige > Konventionen der Syntax hält. Es gibt keine "gängige Konventionen der Syntax". Jeder Assembler macht das anders, und wenn du einen anderen Assembler benutzt als der Autor des Buches, dann sind gewisse Dinge halt anders. Im Gegensatz zum C-Compiler ist der Assembler aber gut dokumentiert. Zumindest habe ich mal eine passende ausreichende Doku zu dem gefunden und danach das BIOS gebaut. > Leider ist er Bestandteil des sdcc. UNd bisher weiss auch niemand wie > man aus einem inline asm Teile Variablen des C Teils anspricht. Du weißt es nicht. Alle anderen benutzen einfach den Symbolnamen, wie bei den großen Compilern auch. Möglicherweise mit Unterstrich davor.
Nicht grad Einzeltransistoren, sondern TTLs einschliesslich MSI und damit viel moderner als das ausschliesslich aus NORs gebaute Original. Aber immerhin komplett ohne Abkürzung per EPROM: http://klabs.org/history/build_agc/
S. R. schrieb: > Du weißt es nicht. Alle anderen benutzen einfach den Symbolnamen, wie > bei den großen Compilern auch. Möglicherweise mit Unterstrich davor. Das funktoniert aber leider nur bei globalen Variablen. Bei lokalen, also dynamisch erzeugten wirft er einen Fehler aus, dass er die nicht kennt. Zumindest habe ich es noch nicht mit V3.3.0 ausprobiert. Der _ dafür ist bekannt.
A. K. schrieb: > Nicht grad Einzeltransistoren, sondern TTLs einschliesslich MSI und > damit viel moderner als das ausschliesslich aus NORs gebaute Original. > Aber immerhin komplett ohne Abkürzung per EPROM: > http://klabs.org/history/build_agc/ Mal kurz quergelesen und ein pdf geöffnet. Das erfordert schon eine sehr gute Kenntnis von Computern die weit über das hinaus geht, was man so landläufig lernt. Hier ist der Weg das Ziel, denn das Ding kann ja faktisch nichts, was nicht jeder AVR heute auch kann, nur eben im Format Schrankwand. Also mit maximalem Aufwand etwas Minimales erreichen. Soll sicher so athentsich wie möglich sein. Allein die Recherchen die Spec zu bekommen dürften endlos gewesen sein. Nee, lass mal.... habe noch andere Hobbies (Börse und Daytrading), da brauche ich meinen Kopf für.
Christian J. schrieb: > da ein > Programmierer sich nun wirklich nicht für das Innenleben einer Super CPU > interessieren muss um effinzienten Code zu schreiben. Nur bedingt richtig. Gelebte Praxis aus der näheren Umgebung zeigt, dass man ohne Kenntnis der Mikroarchitektur solcher Kisten insbesondere bei Multithreading allzu leicht in einige Stolperfallen reinläuft. Das behebt sich zwar nicht durch Assembler, aber einfach C/C++/... programmieren und das Beste hoffen ist auch nix. Entsprechendes Lowlevel-Knowhow kann ein Programm ohne Änderung am grundlegenden Verfahren um ein Vielfaches beschleunigen. Und da kommt immer mal wieder eine Schweinerei dazu. Schau dir mal Haswells Transactional Memory an, wo du schon dabei bist: http://www.realworldtech.com/haswell-tm/ http://www.realworldtech.com/haswell-tm-alt/
Du, bin jetzt weg in die Sauna und noch ne Runde schwimmen im Keller-Bad. Hause ja hier in einem völlig leerstehendn Ferienheim :-) Wie gesagt freue ich mich, dass ich mit Hilfe dieses Forums und viel lesen ein Z80 System zum Laufen gekriegt habe statt wie sonst nur ein paar AVR zusammen zu pflastern oder einen Arduino, wo ja alles funktioniert. Das Boadr zählt grad munter von 0-9 und die LEDs oben wandern a la Knight Rider. Das reich erstmal. Muss noch den Mostek anschliessen, sind ja auch ca 20 Leitungen ohne die Ports, habe langsam Engpässe, da mehr als 3 Drähte in einen Lötpunkt eng werden für die Datenleitungen die ja an jedem Chip sind und die kämme sind auch schon recht voll, so dass da nichts mehr rein geht und ich quer verdrahten muss. Und danach fange ich den Monitor an denn das Ziel ist es ja Programme vom PC in die Kiste zu laden, so dass die Testzeit schneller wird. Muss mir da noch was einfallen lassen. Theorie: Monitor decodiert Intel Hex File oder alternativ zieht sich das .bin rein. Bin scheint einfacher und hex2bin habe ich ja. Wie ich das Programm vom PC da rein kriege weiss ich noch nicht. minicom? Terminal Programm? Irgendein Protokoll muss da ja auch herhalten. Und PC Programmierung habe ich lange nicht mehr gemacht, schon gar nicht unter Linux. Ein cat main.hex > /dev/tty0 wird es sicher nicht tun. Sprung ins RAM, Code muss natürlich für RAM codiert sein, also andere Einstellungen des sdcc. Bei Reset muss er wissen, dass im Ram was liegt und da rein. Bei Stromausfall ist bisher alles weg, habe keinen Pufferakku aber letzlich kann auch das ganze Board an eine Batterie dran. Der 3801 säuft sich locker 180ma rein, glaube ich dem Datenblatt, also kommen wir für das ganze Board mit NMOSs CPU auf fast 500mA und mit CMOs auf maximal 250. Derzeit ziehtes nur 60mA incl LEDs. Und dann wird das ganze irgendeine Anwendung steuern, wo ich mir noch was einfallen lassen will.
> Monitor decodiert Intel Hex File oder alternativ zieht sich das .bin > rein. Bin scheint einfacher und hex2bin habe ich ja. Intel Hex bietet dir Prüfsummen an, die du benutzen kannst, um Übertragungsfehler zu erkennen. Wenn die fehlerfrei geladen wurde, weißt du wenigstens, dass sie auch korrekt angekommen ist. > Wie ich das Programm vom PC da rein kriege weiss ich noch nicht. Das könnte vielleicht daran liegen, dass du nicht liest, was dir andere schon schrieben. Was soll's, ich wiederhole mich jetzt nicht. > Bei Reset muss er wissen, dass im Ram was liegt und da rein. Wozu? Mach in den Monitor einen "Jump to RAM"-Eintrag und gut. > Und dann wird das ganze irgendeine Anwendung steuern, wo ich mir noch > was einfallen lassen will. Eine autonome Steuerung beißt sich sehr stark mit "Anwendung wird als Hexdatei ins RAM geladen und von dort gestartet".
Angehängte Dateien:
-
8085.jpg
380 KB
Ich lese schon eine Weile mit, hab was aehnliches mit den Bausteinen oben vor und einige Bücher von Keil über den 8085 und unter anderen Der Heimcomputer 8085 hier liegen mit Plänen vom EC 8085 SBC :) Allerdings fehlen mir noch ein paar Dinge. Soll evtl. mal mit Altair Basic rennen. Intressantes Board hast du da, gibts auch Fotos von der aktuellen Verdrahtung ?
Hi, kann Bilder hier nicht einfügen unter Linux, mir fehlt ein Programm zur einfachen Größenreduzierung wie vallen jpegger. Aber die Kommunikation ist simpel, grad mal 20 Minuten zu einlesen stty raw ispeed 9600 ospeed 9600 -F /dev/ttyUSB0 stellt den USB/Rs232 konverter ein, ggf. noch einige andere Parameter. echo Hallo > /dev/ttyUSB schickt auch genau Hallo raus. und cat text.text > /dev/ttyUSB lässt auch auf meinem Raspi genau das erscheinen was in text.txt steht Easy :-) PS: Das Keil Buch (grün) habe ich auch seit ca 1986. Habe den 8085 nachgebaut damals. Habe auch nachgefragt ob sie dazu noch weitere Unterlagen haben vor allem die Firmware aber leider keine Antwort.
Angehängte Dateien:
-
DSC08161__1600_x_1200_.jpg
240 KB -
DSC08162__1600_x_1200_.jpg
320 KB
Anbei die Bilder. Oben eine Stiftleiste mit I/O Signalen zur Erweiterung. 2 Ports vom 8255 in der Wanne.
Christian J. schrieb: > kann Bilder hier nicht einfügen unter Linux, mir fehlt ein Programm zur > einfachen Größenreduzierung wie vallen jpegger. mogrify -scale xx% foo.jpg (mogrify ist Teil von imagemagick) Oder pnmscale (aus netpbm). Oder gimp. Oder ... XL
> Wie gesagt sind heutige Timer deutlich aufwendiger und komplexer Dann sieh' dir mal das Datenblatt des Am9513 an (AMD). http://www.hartetechnologies.com/manuals/AMD/AM9513.pdf >9600 Baud Es gab spezielle Baudrate Generatoren (8116, COM8116, AY5-8116), damit konnte man 16 Werte 50 Baud bis max. 19.200 einstellen. Mit Festfrequenz oder über Steckbrücken geht's auch so (http://retired.beyondlogic.org/serial/74hc4060.gif , jedoch Quarz 5,9152 MHz verwenden. Gruss
Erich schrieb: > Mit Festfrequenz oder über Steckbrücken geht's auch so > (http://retired.beyondlogic.org/serial/74hc4060.gif , jedoch Quarz > 5,9152 MHz verwenden. Ich würde 4.9152MHz verwenden. Und 57600/115200bd kann man dann vergessen.
Also im grünen Buch von Keil ist doch das Monitorprogramm/Firmware als Listening drinnen :) Sehr schön der Aufbau. Die Grösse von Bildern reduziere ich immer mit Gimp.
So fieber hatte ich auch, musste es mit hilfe von einem 68008 und einen paar 68020 heilen... und platinen :D. http://propeller.wikispaces.org/pPropQL http://propeller.wikispaces.org/pPropQL020
Erklär mir mal einer das: Mit so 16-19 schrieb ich hunderte Zeilen Asm locker auf dem Papier runter. Ummrechnungstabelle brauchte ich nicht, kannte die Hex Codes der Mnemonics auswendig. Mir 24 kannte ich jeden Interrupt des Bios, jeden Exe-Header einer Datei, wusste wie eine Fat aufgebaut ist, der TASM war mein Freund. Dann kam die dunkle (oder helle?) Zeit ab so 1996 wo ich die ersten C-Compiler bekam, Pascal lieben lernte, später kam noch Java hinzu und Pearl. Selbst die Bash verlor ihren Schrecken und es enstanden Backup Scripte und clvere kleine Programme. Aber mit 45 breche ich mir einen ab mit DIESEM SCHEISS ASSEMBLER !!!! Was interessieren mich Flags? Kann es mir nicht sch... egal sein, ob ein Carry gesetzt ist oder nicht? Wieso hat das Sch.. Ding nur 8 Bit? Meine Zahlen sind größer. Welcher Masochist hat sich das ausgedacht? Und wozu brauche ich diese verdammten ' Register im Z80? Dann fand ich diesen Satz im Internet: "Assembler ist eine Methode, Programme die zu langsam laufen so umzuschreiben, dass sie überhaupt nicht mehr laufen." Mal wieder etwas ernster: Da es keinen Sinn macht Code zu testen indem man ein Epom brennt muss ein Simulator her, damit ich sehen kann, ob er das macht was ich will. Es ist mühsam über Jahre eingefleischte Programmiertechniken zu vergessen und auf die Grundelemente runter zu brechen. Und erst dann setze ich den Code ins Monitor Programm ein. Was kann ich nehmen, um etwas komfortabel mit grafischer Oberfläche Z80 Code zu schreiben und auszutesten?
Ale schrieb: > So fieber hatte ich auch, musste es mit hilfe von einem 68008 und > einen > paar 68020 heilen... und platinen :D. > > http://propeller.wikispaces.org/pPropQL > http://propeller.wikispaces.org/pPropQL020 Sehr schöne Projekte - da sowohl der Propeller wie auch diverse 68k-Cores mittlerweile im Quellcode verfügbar sind, könnte man das ganze System sogar auf einen (recht großen) FPGA packen :-). Hast du vor, die Schaltpläne und den Code irgendwann zu veröffentlichen? -- Michael
Christian J. schrieb: > Was kann ich nehmen, um > etwas komfortabel mit grafischer Oberfläche Z80 Code zu schreiben und > auszutesten? Guckst du bei Jens Müller: http://www.jens-mueller.org/jkcemu/ Dieser wirklich gute Emulator wurde für die gängigen Klein- und Lerncomputer der DDR entwickelt und enthält auch einen Assembler. Paßt zwar nicht direkt zu deinem Hardwareaufbau, hilft aber vielleicht weiter. > "Assembler ist eine Methode, Programme die zu langsam laufen so > umzuschreiben, dass sie überhaupt nicht mehr laufen." Pah.. Gejammer von verweichlichten Hochsprachen-Pussies =8P
Christian J. schrieb: > komfortabel mit grafischer Oberfläche Z80 Code Mit dem Aufkommen der grafischen Oberflächen kam auch der Abschied vom Assembler. Insofern wirst du da kaum fündig werden. Ich wiederhole diverse frühere Statements von vielen Leuten aus diesem Thread: Nimm einen der vielen Debug Monitore. Dann lädst du dein Programm ins RAM und kannst mit Brechpunkten das Ding Stück für Stück durchgehen. Den Monitor an deine Hardware anzupassen ist eine Sache von 15 Minuten (maximal). Alternativ kannst du einen Z80 Simulator und deinen PC verwenden. Wenn es unbedingt ein Eprom Simulator sein soll, gibt es auch dafür Bauvorschläge. Mit etwas Lochraster ist das Ding an einem Abend aufgebaut.
Christian J. schrieb: > Wieso hat das Sch.. Ding nur 8 Bit? Darf ich dich dran erinnern, dass er deine Wahl war? ;-) Hättest auch eine 68000 CPU nehmen können. > Da es keinen Sinn macht Code zu testen indem man ein Epom brennt muss > ein Simulator her, damit ich sehen kann, ob er das macht was ich will. Kann helfen. Wenn du einen findest, der deine serielle Schnittstelle mit richtigem CPU Takt und den beiden zugehörigen Drähten simuliert. Denn das ist dein primäres Problem. Denn wenn diese Schnittstelle läuft, dann brauchst du nur einen winzigen Bootloader im EPROM, der ab Reset xKB am Stück direkt ins RAM läd und anspringt. Ohne Protokoll, ohne Intel-Hex, direkt binär ins RAM ab Anfangsadresse. > Was kann ich nehmen, um > etwas komfortabel mit grafischer Oberfläche Z80 Code zu schreiben und > auszutesten? Editor und Kommandozeile. Retro eben. Herrje, erst muss es Retro sein, aber dann mit allem neuzeitlichen Luxus. ;-) Aber wenn es dich unbedingt danach gelüstet, dann nimm Emacs. Damit geht das. Und der ist ausserdem selber schon gut Retro.
Icke ®. schrieb: > Pah.. Gejammer von verweichlichten Hochsprachen-Pussies =8P Und das von einem Jungspund mit grad mal 45. ;-)
Georg G. schrieb: > Den Monitor an deine Hardware anzupassen ist eine Sache von > 15 Minuten (maximal). Deine 15min oder seine? Jeder Monitor braucht eine Schnittstelle nach aussen.
Christian J. schrieb: > Da es keinen Sinn macht Code zu testen indem man ein Epom brennt muss > ein Simulator her, damit ich sehen kann, ob er das macht was ich will. Hier darf ich mich noch mal kurz einklinken und auf meinen obigen Hinweis zurückkommen. Ein Statisches RAM welches über Bankswitching auf den selben Adressraum wie das BIOSROM meines 8 Bit ATARI eingeblendet wurde (huckepack aufgelötet) und eine kleine Datenschaufel ab Page ab 0x600 erfüllte genau diesen Zweck. Mit dem Monitor aufgerufen kopierte es mir das BIOS in SRAM und konnte on flay zwischen ROM und RAM per SW umschalten. Hier nahm ich meine Modifikationen vor und testete sie. Das setzt allerdings ein Memorymanager per IOPort und Adressdecoder auf das Chipselect vorraus. Ein Absturz wurde mit einem Reset (nach Möglichkeit im "Warmstart") behoben, der Monitor im RAM auf Integrität getestet (Chekcsumme/ Biosfunktion im ROM) ansonsten neu geladen und weiter ging es. Das dauerte keine 3 Sekunden. Half das nicht war nach einem Kaltstart alles wieder im grünen Sektor, da der Kaltstart immer das ROM einblendet. Ich hoffe du verstehst jetz meinen frühen Hinweis. Der Vorteil ist, es erfordert keinen externen Simulator und kann zudem später auch als RA(O)MDisk genutzt werden. Das auf dein Problem zu portieren sollte kein wirkliches Problem sein. Namaste und viel Spaß
Christian J. schrieb: > Erklär mir mal einer das: > > Mit so 16-19 schrieb ich hunderte Zeilen Asm locker auf dem Papier > runter. Ummrechnungstabelle brauchte ich nicht, kannte die Hex Codes > der Mnemonics auswendig. ... > Aber mit 45 breche ich mir einen ab mit DIESEM SCHEISS ASSEMBLER !!!! Du bist einfach zu alt. Also nicht physiologisch, sondern geistig. Such dir ein anderes Hobby. Blumen züchten. Schnecken dressieren. Briefmarken sammeln. Was einfaches halt :P > Was interessieren mich Flags? Kann es mir nicht sch... egal sein, ob ein > Carry gesetzt ist oder nicht? Wieso hat das Sch.. Ding nur 8 Bit? Meine > Zahlen sind größer. Welcher Masochist hat sich das ausgedacht? Ich hätte eigentlich gedacht, daß man sich das 20 Jahren lang merken kann. Denn irgendwann mußt du es ja mal gewußt haben. Außerdem sind ALUs immer zu kurz - genau deswegen gibts ja Carry-Flag & Co. Und warst du das nicht, der unbedingt Retro machen wollte? > Und wozu brauche ich diese verdammten ' Register im Z80? Wenn du den zweiten Registersatz nicht brauchst, dann benutze ihn halt nicht. Andere freuen sich, daß sie ein paar extra-Register haben aber du maulst nur rum. > Dann fand ich diesen Satz im Internet: > > "Assembler ist eine Methode, Programme die zu langsam laufen so > umzuschreiben, dass sie überhaupt nicht mehr laufen." Typischer Möchtegern-Programmierer-Spruch. Wohl Generation Arduino. > Da es keinen Sinn macht Code zu testen indem man ein Epom brennt muss > ein Simulator her, damit ich sehen kann, ob er das macht was ich will. Dann mach doch. Wenn es für irgendeine Architektur viele Emulatoren gibt, dann für den Z80. XL
Axel Schwenke schrieb: > Typischer Möchtegern-Programmierer-Spruch. Wohl Generation Arduino. In dem Fall wohl Generation WINDOOF Wenn mich vor zwanzig Jahren etwas nervte dann das Einsetzen des Versteckens von Funktionen vor dem Anwender mit Ambitionen von Standardsoftwareanpssung an eigenene Bedürfnisse. Ich bin 56 aber das Grundlagenwissen aus der ASM-Zeit hilft mir bis heute. Mein Retrospielzeug heißt TFT Maximite für den ich mir gerade ein SW-Programmer für den 93C56 gebastelt habe. Zuvor habe ich allerdings schnell mal die IO~ und Touchfunktionen der MMBASICExtension debugged. Das ist für mich Urschleim genug. Und was war der Sinn des ganzen? ... ein EEPROM auf einer 20 Jahre alten Liftsteurung zu reinitialisieren leider hatte ich nicht genug Zeit, so war ich froh ein orignal EEPROM bestellen zu können (beim Hersteller). Aber backups werde ich nächstens selbt anlegen können. ;) Namaste
Axel Schwenke schrieb: > Schnecken dressieren. Davon kann ich nur abraten! Wenn du da nicht die ganze Zeit aufpasst wie ein Schießhund, dann brechen die aus. Ein winziger Moment nachlassender Aufmerksamkeit und die sind über alle Berge auf und davon, die erwischt du nie wieder. ;-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.