Retro Fieber: Z80 oder 68000 ?

[Christian J. (Gast)]

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 ....

[Holm T. (Gast)]

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 T. (Gast)]

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

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

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 ???

[(prx) A. K. (prx)]

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."

[Holm T. (Gast)]

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

[(prx) A. K. (prx)]

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. ;-)

[Holm T. (Gast)]

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

[Georg G. (df2au)]

A. K. schrieb:
> ausgebüxten Fairchild-Leuten

Wobei Fairchild seinerseits heftige Anleihen bei Olympia Büromaschinen 
gemacht hat.

[(prx) A. K. (prx)]

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

[Christian J. (Gast)]

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.

[(prx) A. K. (prx)]

Immer noch kein Interrupt ADC => STI?

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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.....

[(prx) A. K. (prx)]

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

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Christian J. schrieb:
> Uuuups.....

Und ich bin nach wie vor sehr sicher, dass du NMI nicht offen lassen 
willst.

[Axel S. (a-za-z0-9)]

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

[Christian J. (Gast)]

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

[Holm T. (Gast)]

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

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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.

[(prx) A. K. (prx)]

Christian J. schrieb:
> Der 374 latched nämlich auf der positiven Flanke und der 138er
> erzeugt negative.

Passt so.

[Soul E. (Gast)]

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.

[Michael_ (Gast)]

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.

[Erich (Gast)]

>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

[Christian J. (Gast)]

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?

[Christian J. (Gast)]

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.....

[(prx) A. K. (prx)]

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€.

[(prx) A. K. (prx)]

Christian J. schrieb:
> Und wie geht das für Normalsterbliche?

Was er schrieb: RAM raus, ROM raus und mit Stecksockel D0-7 auf GND.

[Helmut S. (helmuts)]

>> 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.

[(prx) A. K. (prx)]

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.

[Route_66 H. (route_66)]

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.

[Erich (Gast)]

>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

[Joachim B. (jar)]

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

[Route_66 H. (route_66)]

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.

[Christian J. (Gast)]

Moin,

weiter im Text.... ich weiss jetzt wie Bits ausehen! Ja wirklich!
Sie sind BLAU! Eindeutig blau.....

Bestückung abgeschlossen, jetzt gehts ans Eingemachte.....

[Erich (Gast)]

>jetzt gehts ans Eingemachte.....
Z.B. so
http://slamyslab.blogspot.de/2013/01/z80-mini-system.html

[Christian J. (Gast)]

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.

[Christian J. (Gast)]

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.

[Joachim B. (jar)]

Christian J. schrieb:
> Da kommen wieder echte Jugendgefühle auf,

kann ich voll verstehen, irgendwo habe ich auch noch so eine Kiste.

[Christian J. (Gast)]

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.

[Thomas J. (tom16)]

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 ;-)

[Christian J. (Gast)]

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!

[Joachim B. (jar)]

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 :-)

[Christian J. (Gast)]

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...

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

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.

[Christian J. (Gast)]

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!

[Holm T. (Gast)]

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

[Elektrobrazzzler (Gast)]

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.

[Christian J. (Gast)]

Naja,

mein Arduino Brett sieht auch so aus, zum testen eben.
Wobei diese Kabel dauernd Wackelkontakt haben und absolut
nichts taugen.

[Michael_ (Gast)]

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.

[Christian J. (Gast)]

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.

[Christian J. (Gast)]

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....

[Christian J. (Gast)]

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 T. (Gast)]

..Wahnsinn!


:-|

Holm

[Christian J. (Gast)]

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!

[Holm T. (Gast)]

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

[Christian J. (Gast)]

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.

[Leo C. (rapid)]

Wenn Du sonst gar nichts findest, versuch es doch ausnahmsweise mal mit 
der mitgelieferten Doku.

[S. R. (svenska)]

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...

[Christian J. (Gast)]

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.

[Christian J. (Gast)]

Falsches File....

[Christian J. (Gast)]

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....

[Christian J. (Gast)]

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.....

[S. R. (svenska)]

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.

[Christian J. (Gast)]

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.

[Christian J. (Gast)]

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.

[Leo C. (rapid)]

> 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.

[(prx) A. K. (prx)]

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.

[Leo C. (rapid)]

Welches EPROM hast Du denn genau? In Deinem Schaltplan steht 
"EEPROM2764". Das ist wohl eine Phantasiebezeichnung.

Auf jeden Fall sind CE und OE vertauscht.

[(prx) A. K. (prx)]

Leo C. schrieb:
> Auf jeden Fall sind CE und OE vertauscht.

Was hier aber keine Rolle spielt, sondern erst bei grenzwertiger 
Zugriffszeit.

[User (Gast)]

Ich sehe auf deinem Schaltplan keinen einzigen Abblockkondensator.

[(prx) A. K. (prx)]

User schrieb:
> Ich sehe auf deinem Schaltplan keinen einzigen Abblockkondensator.

Kannst Du auch nicht sehen, die sind unter den ICs mitten im Sockel. ;-)

[Leo C. (rapid)]

>> 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.

[(prx) A. K. (prx)]

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.

[Soul E. (Gast)]

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.

[Christian J. (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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 ?

[Christian J. (Gast)]

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

[Michael_ (Gast)]

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.

[Holm T. (Gast)]

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

[Christian J. (Gast)]

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.

[Leo C. (rapid)]

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"

[Michael_ (Gast)]

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.

[Christian J. (Gast)]

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.

[Leo C. (rapid)]

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".

[Leo C. (rapid)]

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.

[Leo C. (rapid)]

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. ;-)

[Joachim B. (jar)]

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

[Christian J. (Gast)]

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.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

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

[Georg G. (df2au)]

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. (Gast)]

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.

[Axel S. (a-za-z0-9)]

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.

[Christian J. (Gast)]

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.

.module crt0
.globl _main
.area _HEADER (ABS)
;; Reset vector
.org 0x0000
jp init
init:
  ld  sp,#0xffff      ;; Oder Testen, wo RAM zu ende
    call  _main    ;; Hauptprogramm aufrufen
lo:  halt                    ;; oder jp lo für Endlosschleife

;; Initialise global variables
call gsinit
call _main
ret

;; Ordering of segments for the linker.
.area _HOME
.area _CODE
.area _GSINIT
.area _GSFINAL
.area _GSINIT
gsinit::
.area _GSFINAL
ret
.area _DATA
.area _BSEG
.area _BSS
.area _HEAP

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 !

******************************************************

[Michael_ (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Axel S. (a-za-z0-9)]

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

[Georg A. (georga)]

> 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...

[Christian J. (Gast)]

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....

  ld  a,4 (ix)
  inc  a
  push  af
  ld  e,#0x01
  pop  af
  jr  00110$
00109$:
  sla  e
00110$:
  dec  a
  jr  NZ,00109$
  ld  a,d
  or  a, e
  ld  d,a
  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.

[Holm T. (Gast)]

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

[(prx) A. K. (prx)]

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.

[Leo C. (rapid)]

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.

[Christian J. (Gast)]

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.

[Michael_ (Gast)]

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.

[S. R. (svenska)]

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.

[Axel S. (a-za-z0-9)]

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

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

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

[Michael_ (Gast)]

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.

[Christian J. (Gast)]

Hallo,

heute kam sie an, die "Special Edition Retro CPU" mit Firmenaufdruck. 
NMOS und wird schön warm :-)

Gruss,
Christian

[Soul E. (Gast)]

"Retro" mit Datecode von 1999?

[(prx) A. K. (prx)]

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.

[kennt Route_66 (Gast)]

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.

[Holm T. (Gast)]

Sowas hier?

; This is the commented BASIC listing of the 
; TDL 12K Extended "Zapple" BASIC, 
; by Roger Amidon and Neil Colvin, May 1977
;
; This was produced by IDA disassembler
; and further modified for readability (macros and long symbols)
; note this is, although it looks like, not correct Z80 assembler
; to be directly fed into an assembler program - mainly because
; many symbols are too long for Z80 assemblers
; use this as reference only, rather use the HEX dump
; to produce a binary.
;
; The HEX dump has been compared with this commented file;
; while commenting, several OCR errors were corrected.
;
; The hex dump was produced from the book
; Rolf-Dieter Klein, Basic-Interpreter, Franzis Verlag M<FC>nchen, 1982;
; in German language, ISBN 3-7723-6941-3
; The book author himself mentions in the book that he published
; the hex dump because "Der Interpreter wurde urspruenglich von
; TDL (Technical Design Labs) entwickelt und ist sehr leistungsfaehig.
; Da die Firma nicht mehr existiert, soll durch den Abdruck des Listings
; dem Leser die Moeglichkeit gegeben werden, Zugang zu diesem Basic zu
; erhalten." (Seite 103) (Translation: the interpreter was developed
; originally by TDL (Technical Design Labs) and is very powerful.
; Because the company is no longer in existance, the reader is given
; the chance, by printing this listing to get access to this Basic).
;
; The work of reverse engineering and commenting was done by Holger Veit,
; 2012 - this whole work is published unter Creative Commons License
; CC-BY-SA http://creativecommons.org/licenses/by-sa/3.0/

;--------------------------------------------------------------------

;****************************************************************
; some macro definitions for readability
CPHL_DE         macro
                ld    a, h
                sub   d
                jr    nz, @@1
                ld    a, l

Da kann ich glaube ich helfen...

http://www.tiffe.de/Robotron/Zapple-Basic/

Gruß,

Holm

[Christian J. (Gast)]

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?

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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.

[Michael_ (Gast)]

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.

[Christian J. (Gast)]

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.

#include <asm/z80/features.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
#include <malloc.h>
#include <string.h>

#include "main.h"


const char digits[11]= {0xc0,0xf5,0xa8,0xb0,0x95,0x92,0x92,0x82,0xf4,0x80,0x90};


// PIO 8255 Special I/O
__sfr __at 0x20 PIO8255_PORT_A;
__sfr __at 0x21 PIO8255_PORT_B;
__sfr __at 0x22 PIO8255_PORT_C;
__sfr __at 0x23 PIO8255_CNTRL;

// ADC 0804
__sfr __at 0x40 ADC0804_READ;

// 7b Segment
__sfr __at 0x60 SEG7;

#define MAX_RAM    40000
uint8_t ram[MAX_RAM+1];

// NMI Interrupt Handler
void cv_vint(void)
{
  __asm
     halt
  __endasm ;
  
}

// Halte CPU an und lasse LED leuchten
void stop_cpu()
{
  __asm
     halt
  __endasm ; 
}

// Setze oder lösche eine LED (0..7) am Port A
// Input: Led Nr, HIGH oder LOW
void SetLed(uint8_t lednr, bool stat)
{
  uint8_t foo;
  
  // Read...
  foo = PIO8255_PORT_A;
  // Modify...
  if (stat==TRUE)  // LED ein = Bit LOW
    foo &= ~(1<<lednr);
  else
    foo |= (1<<lednr);
  // Write...    
  PIO8255_PORT_A = foo;
}

// Zeitverzögerung 
void delay(uint16_t cnt) {
  volatile uint16_t k;
  for (k=0;k<cnt;k++);
}

/*
  Stelle die Peripheriebausteine ein
*/
void InitHardware()
{
  // 8255: Mode 0: Port A,B,C Output
  PIO8255_CNTRL  = 0x80;     //Mode 0: Port A,B,C Output
  PIO8255_PORT_A = 0xff;
  PIO8255_PORT_B = 0;
  PIO8255_PORT_C = 0;
  
  // 7-Segment ....
  SEG7 = 0xff;
    
  // Interrupts der STI
  
  // STI Multi I/0 Uart
}

int main()
{
  uint8_t n,i;
  uint16_t k;

  InitHardware();
  
  for (n=0;n<10;n++) {
    SetLed(0, HIGH); 
    SetLed(7, HIGH);
    delay(5000);
    SetLed(0, LOW); 
    SetLed(7, LOW);
    delay(5000);
  }  
  delay(20000);
  
  n = 0;
  i = 0;
  while (1) {
  
    SEG7 = digits[i++];  
    if (i>9)
      i=0;
  
    // RAM vollschreiben
    for (k=0;k<MAX_RAM;k++) {
      PIO8255_PORT_A = ~(uint8_t)k;
      ram[k] = n;  
    }  
    // Ram auslesen und darstellen
    for (k=0;k<MAX_RAM;k++) {
      PIO8255_PORT_A   = ~ram[k];
      
    }
     
    n++;
  }
 
}

[Ronny S. (phoenix-0815)]

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

[Christian J. (Gast)]

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?

[(prx) A. K. (prx)]

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 ;-).

[S. R. (svenska)]

> 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. :-)

[(prx) A. K. (prx)]

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?

[Christian J. (Gast)]

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.

[Axel S. (a-za-z0-9)]

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

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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 :-)

[Axel S. (a-za-z0-9)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

A. K. schrieb:
> die IM2 Adressbits A4..A7 frei definierbar

Fix: A5..A7.

[(prx) A. K. (prx)]

Axel Schwenke schrieb:
> Vektortabelle einfach ein Array VoidFnct[256]

Sind nur 128.

[(prx) A. K. (prx)]

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.

[Axel S. (a-za-z0-9)]

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

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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.

;--------------------------------------------------------------------------
;  crt0.s - Generic crt0.s for a Z80
;--------------------------------------------------------------------------


        .module crt0
         .globl  _main
    .globl  _nmi_vint 
    .globl  _int_sti_gpi_0  ; General Purpose Interrupt 0
    .globl  _int_sti_gpi_1  ; General Purpose Interrupt 1
    .globl  _int_sti_gpi_2   ; General Purpose Interrupt 2
    .globl  _int_sti_gpi_3  ; General Purpose Interrupt 3
    
    
    

  .area  _HEADER (ABS)
  
  ;///////////////////////////////////////////////////////////
  ; Reset vector bei Kaltstart
  .org   0
  jp  init   ;; Sprung in die Init Routine

  ;///////////////////////////////////////////////////////////  
  ;// Mode 1 Interrupt
  .org 0x38
  reti

  ;///////////////////////////////////////////////////////////
  ; NMI Interrupt 0x66, muss mit retn abgeschlossen werden
  .org    0x66
    push af
  push bc
  push de
  push hl
  push iy
  push ix
  call _nmi_vint    ; Aufruf Handler im C Modul main.c
  pop ix
  pop iy
  pop hl
  pop de
  pop bc
  pop af
  retn

  ;///////////////////////////////////////////////////////////
  ; 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
  
  
init:
  ;; Stack an Spitze des RAM legen
  ld  sp,#0xffff

    ;; Globale Variablen initialisieren
    call  _main    ;; Hauptprogramm aufrufen
  halt

  ;; Ordering of segments for the linker.
  .area _HOME
  .area _CODE
  .area _GSINIT
  .area _GSFINAL
  .area _GSINIT
  .area _DATA
  .area _BSEG
  .area _BSS
  .area _HEAP

[(prx) A. K. (prx)]

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. ;-)

[Christian J. (Gast)]

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.

[Christian J. (Gast)]

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?

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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.

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

Ok,

da ist noch Platz :-)

Auf jeden Fall assembliert er jetzt fehlerfrei durch und auch der C 
Compiler mecker nicht.

        .module crt0
         .globl  _main
    .globl  _nmi_vint 
    .globl  _int_sti_gpi_0  ; General Purpose Interrupt 0
    .globl  _int_sti_gpi_1  ; General Purpose Interrupt 1
    .globl  _int_sti_gpi_2   ; General Purpose Interrupt 2
    .globl  _int_sti_gpi_3  ; General Purpose Interrupt 3

  ;///////////////////////////////////////////////////////////
  ; 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

Und später im .c File

void int_sti_gpi_0(void)
{

}

void int_sti_gpi_1(void)
{

}
void int_sti_gpi_2(void)
{

}
void int_sti_gpi_3(void)
{

}

Muss das aber noch im De-Assembler kontrollieren.

Ergibt

                            354 ;  ---------------------------------
                            355 ; Function int_sti_gpi_0
                            356 ; ---------------------------------
   0149                     357 _int_sti_gpi_0_start::
   0149                     358 _int_sti_gpi_0:

Also Adresse 0x100 + 0x149 = 0x249

und im Map steht.

 00000249  _int_sti_gpi_0                     main
           00000249  _int_sti_gpi_0_start               main
           0000024A  _int_sti_gpi_0_end                 main
           0000024A  _int_sti_gpi_1                     main
           0000024A  _int_sti_gpi_1_start               main
           0000024B  _int_sti_gpi_1_end                 main
           0000024B  _int_sti_gpi_2                     main
           0000024B  _int_sti_gpi_2_start               main
           0000024C  _int_sti_gpi_2_end                 main
           0000024C  _int_sti_gpi_3                     main
           0000024C  _int_sti_gpi_3_start               main
           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.

Sxxxx Assembler V02.00 + NoICE + SDCC mods + Flat24  (Zilog Z80 / Hitachi HD64180), page 2.



   0080                      57   .org  0x80
   0080 00 00                58   .dw _int_sti_gpi_0
   0082 00 00                59   .dw _int_sti_gpi_1
   0084 00 00                60   .dw _int_sti_gpi_2
   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??

[Christian J. (Gast)]

Hier ist die Map Tabelle... den NMI setzt er richtig auf 0x137 mit CD 37 
01
aber die

.dw .....

sind falsch.

Area                                    Addr        Size        Decimal Bytes (Attributes)
--------------------------------        ----        ----        ------- ----- ------------
_CODE                               00000100    0000018F =         399. bytes (REL,CON)

      Value  Global                              Global Defined In Module
      -----  --------------------------------   ------------------------
           00000100  _stop_cpu                          main
           00000100  _stop_cpu_start                    main
           00000102  _copyright                         main
           00000102  _stop_cpu_end                      main
           00000127  _digits                            main
           00000137  _nmi_vint                          main
           00000137  _nmi_vint_start                    main
           00000139  _InitHardware                      main
           00000139  _InitHardware_start                main
           00000139  _nmi_vint_end                      main
           0000014E  _InitHardware_end                  main
           0000014E  _SetDigit                          main
           0000014E  _SetDigit_start                    main
           00000174  _SetDigit_end                      main
           00000174  _SetLed                            main
           00000174  _SetLed_start                      main
           000001BB  _SetLedByte                        main
           000001BB  _SetLedByte_start                  main
           000001BB  _SetLed_end                        main
           000001CC  _SetLedByte_end                    main
           000001CC  _delay                             main
           000001CC  _delay_start                       main
           000001FA  _LED_Rotate                        main
           000001FA  _LED_Rotate_start                  main
           000001FA  _delay_end                         main
           00000249  _LED_Rotate_end                    main
           00000249  _int_sti_gpi_0                     main
           00000249  _int_sti_gpi_0_start               main
           0000024A  _int_sti_gpi_0_end                 main
           0000024A  _int_sti_gpi_1                     main
           0000024A  _int_sti_gpi_1_start               main
           0000024B  _int_sti_gpi_1_end                 main
           0000024B  _int_sti_gpi_2                     main
           0000024B  _int_sti_gpi_2_start               main
           0000024C  _int_sti_gpi_2_end                 main
           0000024C  _int_sti_gpi_3                     main
           0000024C  _int_sti_gpi_3_start               main
           0000024D  _int_sti_gpi_3_end                 main
           0000024D  _main                              main
           0000024D  _main_start                        main
           0000028F  _main_end                          main

[Christian J. (Gast)]

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

[Christian J. (Gast)]

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?

[(prx) A. K. (prx)]

Artikel dazu bauen.

[Christian J. (Gast)]

A. K. schrieb:
> Artikel dazu bauen.

Bin zu blöd ein Wiki zu bedienen, da auch kein Interesse daran. Maixmal 
ein Plaintext File.

[Frank (Gast)]

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...

[Christian J. (Gast)]

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...

[S. R. (svenska)]

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. ;-)

[Christian J. (Gast)]

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.

[Georg G. (df2au)]

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.

[(prx) A. K. (prx)]

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).

[S. R. (svenska)]

Achso, das wusste ich nicht. Danke für die Aufklärung.

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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

[(prx) A. K. (prx)]

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.

[Christian J. (Gast)]

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 :-)

[(prx) A. K. (prx)]

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. ;-)

[Christian J. (Gast)]

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" :-)

[Frank K. (fchk)]

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

[(prx) A. K. (prx)]

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!

[Christian J. (Gast)]

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.

[S. R. (svenska)]

> 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.

[(prx) A. K. (prx)]

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/

[Christian J. (Gast)]

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.

[Christian J. (Gast)]

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.

[(prx) A. K. (prx)]

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/

[Christian J. (Gast)]

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.

[S. R. (svenska)]

> 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".

[Matthias I. (matze5)]

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 ?

[Christian J. (Gast)]

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.

[Christian J. (Gast)]

Anbei die Bilder.

Oben eine Stiftleiste mit I/O Signalen zur Erweiterung. 2 Ports vom 8255 
in der Wanne.

[Axel S. (a-za-z0-9)]

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

[Erich (Gast)]

> 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

[(prx) A. K. (prx)]

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.

[Matthias I. (matze5)]

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.

[Ale (Gast)]

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

[Christian J. (Gast)]

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?

[Michael Engel (Gast)]

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

[Icke ®. (49636b65)]

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

[Georg G. (df2au)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

Icke ®. schrieb:
> Pah.. Gejammer von verweichlichten Hochsprachen-Pussies =8P

Und das von einem Jungspund mit grad mal 45. ;-)

[(prx) A. K. (prx)]

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.

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

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ß

[Axel S. (a-za-z0-9)]

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

[Winfried J. (Firma: Nisch-Aufzüge) (winne)]

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

[Konrad S. (maybee)]

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. ;-)