A. K. schrieb: > Korrektur: > reset: ld bc, 0xFFFF ;64KB > ld hp, 0x0001 ;von Quelle > ld de, 0x0001 ;nach Ziel > ldir ;kopieren > out (flipflop),a ;FF umschalten > jp startup ;absoluter Sprung nach 0xExxx > startup: ..hier fängt dein bisheriger Startup Code an.. Unvollständig korrigiert! Das Doppelregister heißt HL. Bei der ersten Variante habe ich noch an einen Tippfehler geglaubt.
Route 66 schrieb: > Das Doppelregister heißt HL. Touché ;-) > Bei der ersten Variante habe ich noch an > einen Tippfehler geglaubt. War es auch. Ich schreib den Kram ja nicht komplett neu, bloss um ein paar Werte zu korrigieren.
Interessant....
1 | //////////////////////////////////////////////// |
2 | // ISR: Uart TX Sendepuffer ist leer |
3 | // putchar()füllt ihn wieder |
4 | // |
5 | // Veränderte globale Variablen: |
6 | // tx.bytes_to_send, tx.rd_ptr |
7 | |
8 | void int_sti_transmit_buffer_empty(void) __interrupt |
9 | {
|
10 | // Sind noch Zeichen im TX Buffer? |
11 | if (tx.bytes_to_send > 0) { // ja.....
|
12 | STI_UDR = tx.buf[tx.rd_ptr]; // Byte einschreiben |
13 | tx.rd_ptr = (tx.rd_ptr +1) & tx.mask; // Read Pointer rollen |
14 | tx.f_idle = false; |
15 | tx.bytes_to_send--; |
16 | } |
17 | else {
|
18 | // nein, letztes Zeichen ging grad raus |
19 | tx.f_idle = true; |
20 | } |
21 | |
22 | if (tx.rd_ptr>(BUF_SIZE+5)) {
|
23 | __asm |
24 | halt |
25 | __endasm; |
26 | } |
27 | |
28 | EI; |
29 | } |
Der HJALT dürgfte eigentlich nie erreicht werden. Hämmert man aber ordentlich auf den Tasten und lässt ihn viel Test ausgeben zb im DUMP Mode, so stürzt er sich doch in den HALT. Obwohl das die einzige Stelle ist wo diese Variable verändert wird..... Faszinierend.....
öhm Christian, programmierrter Absturz? "ASM halt" hält och wohl den Z80 an? wie soll es dann weitergehen? Hier wäre es doch wohl sinnvoller die aufrufenden Schicht rechtzeitig per Busy-flag darüber in Kenntnis zu setzen, dass sie den TX-Puffer nicht weiter befüllen sollte, bevor der Puffer nicht wieder genügend Kapazität aufweist. Idealerweise ist der Puffer etwas größer als der gröste Block, so kann man den Puffer auch blockweise füllen und warten bis das Busy-Flag wieder gelöcht wurde wenn der block draußen ist und muss nicht vor jedem Byte das Busyflag testen. Werden nur einzelne Bytes oder strings variabler länge übertrragen, so bleibt einem das allerdings nicht erspart. Für eine Blockweise Übertragung könnte man aber auch be leerem Puffer den Puffezeiger verbiegen und die Blocklänge angeben. So muss man nur das Busyflag setzen und nach der Übertragung selbiges zurücksetzen. Vorteil, du hast Kontrolle über den Speicher, der Puffer kann für die Einzelzeichen übertragung klein gehalten werden. und ein TX-bufferoverflow wird sicher vermieden. Achja und schneller gehts auch. ;)
Winfried J. schrieb: > wie soll es dann weitergehen? Soll es doch überhaupt nicht. Das ist der Exit für "dies hätte eigentlich nicht passieren dürfen". Das ist das Äquivalent zum assert() Makro, bei dem es im Fehlerfall auch nicht weitergeht.
Ich stehe etwas vor dem Unerklärlichen.... so ein Verhalten habe ich noch nie erlebt....... egal wie man es dreht..... er "spinnt". Lege ich das Datensegment schoen weit weg ist die Welt wieder in Ordung..... aber nicht über den Code, dann dreht er durch.
Christian J. schrieb: > Ich stehe etwas vor dem Unerklärlichen.... so ein Verhalten habe ich > noch nie erlebt....... egal wie man es dreht..... er "spinnt". Das ist normal. Der typische Zustand bei einem hartnäckigen Fehler. Nach der Erleuchtung bessert sich das wieder.
Hat mal jemand eine JTAG Schnittstelle für mich? Und einen Spource Level Debugger? Und wenn es geht auch bitte eine MMU mit Speicherschutz?
Das letzte Mal in diesen Zustand der Verzweifelung brachte mich der Cubietruck. Ewig Abstürze, 30 Minuten, dann wieder und dann immer öfter. Bis ich nach 3 Tagen Suchen mal die FEX durchging, das ist die Konfiguration für die CPU, die sie sich reinzieht und entdcekte dass CAS und RAS Time viel zu kurz sind, weil der Chinese da eine zu schwache Brille auf hatte. Und dann lief es, bis heute, seit 3 Monaten ohne Reset durch....
Hall0 Christian, Du wolltest Retro deine Weihnachtsmannwunschliste hast du vor geraumer Zeit... aber wir wollen ja nicht in ofenen Wunden rumstochern. Hat mal jemand Salz und Pfeffer? ich sollte noch ein bischen nachwürzen. jetzt nach dem ich mit meiner MMU eigentlich fast durch war kam heute ein Päckchen von segor mit darin 2 Stück 62C8128 (128KByte SRAM 70ns)darin. Juhu ich fang vor dem löten noch mal an zu zeichnenen das spart mir gefühlte 100 leitungen mit ebenso gefühlten 300 lötstellen und jede Menge Platz auf der Platine eue Konfiguration 2*8KB EEPROM und 2 *128 KB RAM Der gesparte Plat wird genutz die beim externen Speicher am UB8830D (4*2KB) nichtnutzbare RAM-Adressen 0-7FFF umzumappen dort könnten dann Puffer und Parameter zur Speicherverwaltung hin. Namaste
:
Bearbeitet durch User
@ Christian o.T. In meiner Lehrzeit ab 1977 haben wir Elektriker über die Blechkloper gelacht. Wenn die ihren ersten Versuch wieder begannen auseinderzureißen haben wir das Werkzeug ausgepackt, die 1-2 h davor haben wir mit nachdenken und diskutieren verbracht. Wir waren dann meist um 15 Uhr fertig und haben die Doppelkopfkarten ausgepackt, während die Blechklopper sich ranhalten musten ihren 3. Versuch bis Feierabend fertig zu bekommen. So ging das das gesammte erste Lehrjahr. Über welchen Berufsstand dürfen wir heute schmunzeln? Aber ich bewundere deine Ausdauer und Hartnäckigkeit. Namaste
:
Bearbeitet durch User
Christian J. schrieb: > und entdcekte dass CAS > und RAS Time viel zu kurz sind, weil der Chinese da eine zu schwache > Brille auf hatte. ne der hatte es eilig wie du ;) Mist schon wieder steckt mein Finger drin. Schnelllll wech hier.
:
Bearbeitet durch User
Was zur Hölle hat diese Routine damit zu tun dass das Programm entgleist und sich selbst zerstört? Kommentiere ich die aus vorne läuft es wieder.... Ich dreh noch ab.... !!!!! Sch.... Z80 ! Ähm.... schöner Z80 :-)
1 | // Einstellungen für SPI |
2 | void init_spi() |
3 | {
|
4 | CLI; |
5 | // Interrupts ausschalten (Figure 8, MK3801 Manual, ind. IERB Register) |
6 | STI_PVR = MODE2_VECTOR | STI_IERB; |
7 | STI_IDR = STI_IDR & ~( (1<<1) | (1<<2) | (1<<3) | (1<<6) | (1<<7) ); |
8 | |
9 | // Data Direction einstellen (Figure 14, MK3801 Manual) |
10 | STI_PVR = MODE2_VECTOR | STI_DDR; |
11 | STI_IDR = STI_IDR | SDO | SCLK | SS; // 1 = SDO, SCLK, SS = Outputs |
12 | STI_IDR = STI_IDR & ~(SDI | WAIT); // 0 = SDI, WAIT = Inputs |
13 | |
14 | // Vektor zurückschreiben |
15 | STI_PVR = MODE2_VECTOR; |
16 | |
17 | // Voreinstellungen |
18 | STI_GPIP = STI_GPIP | SCLK; // Clock = HIGH |
19 | STI_GPIP = STI_GPIP | SS; // SS = HIGH |
20 | STI_GPIP = STI_GPIP & ~SDO; // SDO = 0 |
21 | EI; |
22 | } |
tja, cli... unterbindet deine rx tx IRQs erst nach ei (sei) kann es weitergehen nestet loop ?
Kann es sein, dass du mit dem abschliessenden EI deine geistige Gesundheit riskierst? Weil der Code die Interrupts zu diesem Zeitpunkt lieber noch nicht einschalten sollte?
:
Bearbeitet durch User
A. K. schrieb: > Kann es sein, dass du mit dem abschliessenden EI deine geistige > Gesundheit riskierst? Die Ints sind da schon an, alle..... die Tabellen initialisiert, der Vektor steht, Z80 Im2 ist gesetzt usw.....
nach halt erwarte die ZPU einen Interupt! ist dieser gesperrt durch cli cli+halt = end of work darum vor halt interupts erlauben ! hat mir gerade das Schlaue buch verrraten
Du, das hat damit nichts zu tun...... halt schaltet eine LED ein, wollte nur wissen wo der Code entgleist..... ohne gescheiten Debugger mit Breakpoints ist das eine Sache nach der Nadel im Heuhaufen. Eines habe ich schon gefunden: Hardware IO Zugriffe in einer ISR sollten unterbleiben, wenn der IO Port auch im Hauptprogramm öfter benuzt wird. UNd dieser MK3801 ist heimtükisch..... der hat indirekte register und wenn dir da ein INT zwischenhaut während gerade die beiden Befehle abgearbeitet werden, dann kann es sein dass der INT ins Nivana geht. STI_PVR muss immer auf 0x40 stehen, sonst zischt jeder INT irgendwo hin. Dummerweise braucht man STI_PVR auch für jede Adressierung, so dass ich 0x40 sicherheitshalber immeer wieder reinschreibe, auch wenn es zu viel sein sollte.
Hallo intressanter Thread. Ich habe jetzt nicht alles durchgelesen, ist schon etwas viel :-) mich würde eines interessieren. Wenn man so einen 68000er single board computer hat. Wie soll man da die Software drauf bringen, und vielleicht sogar debuggen können? Klar, der GCC kann Code für den 68k erzeugen, aber wie weiter? Ich hätte nämlich hier noch ein paar 68332 und zwei 68020. Könnte man auch mal wieder was machen damit (wäre eine interessante Nutzung der Festtage). Gruss Tobias
Tobias Plüss schrieb: > (wäre eine interessante Nutzung der > Festtage). Wohl eher eine des nächsten frühjahres.... habe 2 68000 hier in keramik, die sind noch deutlich komplexer als nur ein z80.
Ich sitze hier nur vor der Glaskugel und fange Fetzen auf, der Zusammenhang konnte ja durchaus gegeben sein. Ausschließen kannst nur du das. Wenn die LED dir ein Halt signalisiert bist du ja informiert. Aber wenn du vor Halt die Interrupts wieder erlaubst da ja, eh nichts anderes bearbeitet werden kann, so kannst du auch mit einem tx interupt halt wieder aufheben. wenn das Schubsregister der sio wieder leer ist. Trotzdem würde ich noch mal über eib Busy_Flag für die SIOTX nachdenken;) Halt von dauerhaft ine einer Pufferroutine zu benutzen ist keine Notbremse sondern ein Strick zum (dran) aufhängen kommt sowas in den Verkauf brauchst du weder einen neuen Verkäufer noch einen guten Anwalt. Es genügt der nächste Baum. SIl 3 o.k. aber was ist mit der Ausfallsicherheit?
Tobias Plüss schrieb: > Wie soll man da die Software drauf bringen, > und vielleicht sogar debuggen können? Genauso wie hier im Thread bei seiner Z80. Bootloader schreiben, der ein Programm von de Seriellen ins RAM läd und ausführt. Rest folgt dann. Debuggen: Triviales Ausgabemedium z.B. wie hier per LED-Anzeige.
Sodele, Das Problem scheint gelöst. Alles wieder zurück, 2 Ringpuffer usw. Ursache scheinen INT Konflikte gewesen zu sein, denn ein Codeumbau mit weniger Routinen und nur noch ganz wenig EI und CLI brachte dann das Ergebnis. Genau weiss ich es nicht aber manchmal hilft es etwas anders zu machen. Allerdings habe ich hier auch kein Vollduplex und das merkt man eben, bin das anders gewohnt. 680000 ist nicht mein Ding, eher ein Industrieprozessor, der zu viel drumherum braucht und wo es zu wenig für gibt.....
Hmm als triviales Ausgabemedium könnte man den UART nutzen, habe noch MC68681 hier, im violetten Keramikgehäuse mit Goldbeinen. Könnte man dafür verwenden :-)
Ja Ja diese Ressourcenprotzerei macht schlechte Gewohnheiten. Aber bescheidene Ressourcen erfordern Sparsamkeit und Disziplin. Und der Mangel an gewohnten Tools macht demütig. ;)
der 68000 ist einfacher zu handeln als ein Z80 dünkt mir so, der Proz ist zwar "komplexer" aber er ist regelmäßiger. Die Sache mit gcc auf MC68000 habe ich doch gerade erst gemacht (siehe Gcc-Thread). An einem 68681 im lila Gehäuse hätte ich Interesse, ich habe lila MC68010 auf den beiden KatCe Boards stecken...bräcuhte ich dann noch MC68230 in Keramik..vergeßt es.. Gruß, Holm
Hallo Holm einen violetten 68681 im Tausch gegen einen keramischen 68000? oder einen lila 68010? :-)
Christian J. schrieb: > Und einen Spource Level Debugger? Such Dir ein Stück Hardware, welches von Sigrok unterstützt wird. Und dann startest Du den Z80-Protokoll-Dekoder: http://sigrok.org/wiki/Protocol_decoder:Z80 Feine Sache, das! Jens
Angehängte Dateien:
-
DSC08185__1600_x_1200_.jpg
240 KB
Tobias Plüss schrieb: > Hallo Holm > > einen violetten 68681 im Tausch gegen einen keramischen 68000? oder > einen lila 68010? :-) Nana....... violett? Also meiner hier, das ist ein Prachtbursche :-) Nen richtiger Frauenschwarm :-) Echt ADO, mit der Goldkante. Für den 68000 würdee ich ein uCLinux aufsetzen, sehr kleines Board mit wenig Chips aber es funktioniert: http://www.bigmessowires.com/2014/11/17/68-katy-68000-linux-on-a-solderless-breadboard/
Angehängte Dateien:
A. K. schrieb: > Tobias Plüss schrieb: >> Wie soll man da die Software drauf bringen, >> und vielleicht sogar debuggen können? Hi, vielllicht erstmal überlegen, was du willst und vor allem wieviel zeit dabei draufgehen soll? Basteln abends und Frauchen beglücken geht selten zusammen. Wobei sich bei mir das Thema eh nicht stellt als Single :-) Echter Computer? Video, Audio, Keyboard, Speicher, Maus? ==> 1-2 Jahre Aufwand ohne Vorlagen Noch ein CP/M Abklatsch, der x.te? Oder sowas hier, was einfach nur zum Programmieren da ist? LEDs, Timer, eine Anzeige, SD Karten-Interface, ein paar TTL's zum Schalten und Takten? Terminal statt Monitor und Keyboard. Wahnsinnig intelligente Anwendungen wie 4 Gewinnt gegen sich selbst, Game of Life für 80x40 Display oder er berechnet eben primzahlen...kommt zwar nicht weit aber egal. Ich bin seit gut 2 1/2 Monaten dran von Null an und habe noch ein Extension Board dazu gebaut und inzwischen 3/4 verkabelt aber noch kein Programm für. Musst du wissen, der 68000 ist sicherlichn die bessere "C-Maschine". Ausrüstung: - Universal EPROMMER, ca 69 Euro und Löscher - EPROM und RAMS - Linux als Programmiersystem und Terminal (nix Windoofs!) - USB/RS232 Adapter für 2 Euro aus der Bucht und das übliche Lötgeraffels....
Last entry für heute: Ich habe die Ursache für das "seltsame Verhalten" gefunden. Da wird niemand drauf kommen und auch ich wäre es wohl nie, wenn ich nicht Holms Wundertüte mit den U880's ausprobiert hätte ..... Die NMOS CPU mit dem "schönsten Aufdruck in gelb" war im Ar.... ! Irgendwie spramng die so 1min nach warmwerden munter im Programmspeicher umher. Mit den U880 und den anderen NMOS und CMOS spielt es wieder einwandfrei. Arrrrrgghhhhhh !
ha! Das war damals nichts außergewönliches meist war ein Bonddraht abgerissen lag aber noch am Ship an. Wurde es dann wärmer ..... Übigens habe ich später soetwas bei LED wiedergesehen welche eigentlich nicht für den Blinkbetrieb gedacht waren.
Angehängte Dateien:
-
KatCe-1.jpg
110 KB
@Tobias: Nee lass ma, ich lasse die Dinger in ihrer natürlichen Umgebung.. Gruß, Holm
Holm Tiffe schrieb: > @Tobias: Nee lass ma, ich lasse die Dinger in ihrer natürlichen > Umgebung.. Trotzdem würde ioch bei den Eproms mal die Jalousien runterlasssen, damit die Sonne nicht so rein scheint. Und auch mal Staub wischen auf den Fluren....
Mach Dir keine Gedanken, der Inhalt da ist eh nur temporär. Mehr als der Debug-Monitor FBUG ist da nicht drauf, übrigens in C geschrieben, von Motorola vor Jahrzehnten. Gruß, Holm
Hey Holm, woher hast du den FBUG? liegt der als Source vor? ich wär da interessiert.
Guck mal hier: http://www.tiffe.de/Robotron/Motorola/fbug das ist ein Arbeitsstand von vor 3 Monaten oder so :) Woher ich den habe? Keine Ahnung, früher mal ftp.funet.fi oder so... Die Anpassung für die Vektorbasisregister-Geschichte und Trap Stackframe für den 68010 habe ich da vor Jahren schon mal eingebaut, 68010 war zwar vorgesehen aber noch nicht fertig. Danach ging mit dem gcc kein Coff mehr und ich habe nochmal umgebaut. am gcc/ld ist da sicherlich noch viel Arbeit, aber der Kram funzt erst mal. Den letzten Stand müßte ich aber auch erst hoch laden, üb den Stand auf dem Server lief mal eine Problemdiskussion in diesem Forum, Abteilung gcc.. Gruß, Holm
Jadoch kenne ich, ist aber nur noch ein blasser Schatten seiner selbst. Den Finnen müssen da mal massenhaft Maschen runter gefallen sein. Gruß, Holm
Erinnerte mich an 1995 als das Internet noch von der gebildeten Schicht bevölkert war, es keine 10.000 Webseiten weltweit gab, das Usenet was noch keine Müllhalde war und einen anon.penet.fi mit dem man nette Sachen machen konnte.
Hi, weiss einer, wie man für einen Zufallszahlengenerator "zufällige" neue Startwerte erzeugen kann? Mist, ein Computer macht ja taktgenau jedesmal das Gleiche :-( Habe mir schon überlegt einen schnelllaufenden Timer anfangs auszulesen aber der Auslesewert ist auch immer der gleiche obwohl der mit 3,9 Mhz rennt.... wie der Rest eben auch, Takt für Takt :-(
Beim Z80 kannst das R-Register auslesen. Wenn das allerdings immer zur gleichen Zeit nach dem Reset erfolgt, bringt das auch nichts.
Jens schrieb: > Beim Z80 kannst das R-Register auslesen Rennt das automatisch los, bzw ist das eine Art Zaehler?
Christian J. schrieb: > Rennt das automatisch los, bzw ist das eine Art Zaehler? Ja. Zählt M1-Zyklen.
Yep, kommen immer andere Werte.... und da ich das Programm per Hand starte nie der gleiche zu Anfang :-) Nach Reset aber sind es immer die gleichen, Wert für Wert, nur dass der Rechner nich weiss, wann ich "start" eingebe hilft hier.
1 | for (k=0;k<20;k++) {
|
2 | __asm |
3 | ld a,r |
4 | ld (_rreg),a |
5 | __endasm; |
6 | addstr(" "); addint(rreg);
|
7 | } |
8 | press_return(); |
Christian J. schrieb: > weiss einer, wie man für einen Zufallszahlengenerator "zufällige" neue > Startwerte erzeugen kann? In dem Du beim Reset einen Zähler startest und beim ersten Tastendruck oder RS-232-Empfang ausliest. Ausgehend von der Annahme, dass Tastatur bzw Terminal von einem Menschen bedient werden, ist diese Zeitspanne nicht deterministisch. Heimcomputer haben hierzu die VSyncs gezählt.
Ja, danke! Schade, dass der Z80 nicht ein wenig fixer ist denn sonst würde diese Simulation hier deutlich flüssiger laufen. Und da ist schon vieles im Code optimiert worden..... jedenfalls ganz nett wie es "lebt" beim Game of Life :-) https://www.youtube.com/watch?v=0t41d-4tkYQ&feature=youtu.be
Moin und Frohe Weihnachten! Weiss jemand ob eine "normale" Z80 CPU (die 6mhz Varianten habe ich nicht) und vor allem der Mk3801-04 4.9 Mhz aushalten? Die 9600 baud sind einfach zu langsam und auch die CPU könnte etwas flotter unterwegs sein. Der Mk3801-06 ist kaum zu kriegen und wenn dann nur sehr teuer für über 25 Euro. Wenn mit 3.68Mhz 9600 sind sind, müssten mit 4.9Mhz 14.400 baud möglich sein. Schon nett... aber wird man etwas gaga wenn man da zu lange drauf schaut, was sich da so alles "entwickelt", trotz winziger Auflösung im Vergleich zu heutigen Computern, die das in Echtzeit simulieren. https://www.youtube.com/watch?v=R_dAzB3HNLg
Ich habe jetzt keine Lust mich durch das Datenblatt des STI durchzugraben (weil ich ja auch keinen besitze) aber eine SIo konnte relativ problemlos auch 19200 Baud (mit einem CTC Kanal als Baudratengenerator). Ich kann mir nur schwer vorstellen das 9600 die Grenze für die STI sein soll.. Probiere einfach aus was die 4Mhz Chips noch können, die werden nicht gleich kaputt gehen wenn Du sie übertaktest, Deine Programme werden einfach abstürzen. Ich denke aber schon das 5Mhz möglich sind, sicher aber nicht mit jedem IC. Gruß, Holm
Holm Tiffe schrieb: > Ich habe jetzt keine Lust mich durch das Datenblatt des STI > durchzugraben 4 Mhz..... natürlich schon nachgeschaut bevor ich hier was schreibe. Nicht ganz billig der kram, daher bevor ich den bestelle mal kurz gefragt. 9600 sind die Grenze (/16 und /4 Teiler leider davor), das steht auch in der App Note von Mostek drin. Mit dme -06er gehen 19200 bei 6 Mhz Baudratenquarz.
Holm Tiffe schrieb: > Ich kann mir nur schwer vorstellen das 9600 die > Grenze für die STI sein soll.. Er hat ein Problem mit der Baudratenerzeugung aus dem Systemtakt.
Angehängte Dateien:
Wobei sich die Frage stellt ob man die /1 irgendwie aktivieren kann.... trotz "/16 only" Fussnote. Der Chip ist eh etwas "anders", schon die Sync Betriebsmodi sind anders als alles was ich je gesehen habe, mit Sync Bytes usw.
Die Sync-Modi werden nicht anders sein als die in der SIO auch (SDLC,HDLC,BiSync) nur Du mit mit der SPI gängiger Micros sicherlich völlig Anderes gewohnt. Die Sync-Protokolle gehören zur "frühen" Netzwerktechnik.. Holm
Holm Tiffe schrieb: > Die Sync-Modi werden nicht anders sein als die in der SIO auch > (SDLC,HDLC,BiSync) nur Du mit mit der SPI gängiger Micros sicherlich > völlig Anderes gewohnt. Bin da grad dran, habe noch einen App Note von Mostek aufgetrieben, einen Design Guide für alle Chipse von denen.....
Ich werde irre! 57600 laufen !!! Ich habe die Rev H Chip und bei der scheinen die den /1 Mode in Ordnung gebracht zu haben! Die App Note wo behauptet wurde das ginge nicht war veraltet...... ganz neue Geschwindigkeitsdimensionen, das Bild ist einfach sofort "da" und kriecht nicht mehr aus dem Bildschirm :-)
Interessant. USART asynchron mit /1 und dennoch Taktsynchronisation per Startbit? Das wär ne ziemliche Innovation. Mal sehen ob sich die Freude hält, denn der /16 Teiler ist für die Synchronisation bei Rx essentiell. Du also jetzt keine Taktsynchronisation mehr. Bei Tx macht die der PC, daher ist diese Richtung kein Problem. Bei Rx ist es Glücksache, also davon abhängig ob der Takt der PC-UART zufällig innerhalb deines Bitframes liegt oder an dessen Grenze. Wenn du jetzt also gelegentlich Ärger mit der Tastatur oder mit dem Bootloader hast... Poste doch bitte mal die komplette STI Config für 57600.
:
Bearbeitet durch User
Moment..... ich bin noch dran, da der Upload von Intel Hex nicht mehr läuft, der verschluckt sich jetzt ..... Da die Sync weg ist steht ja auch in der App Note von Mostek drin, die funktioniert nur bei 1/16. Ich melde mich sobald ich mehr weiss.... 38400 wären rechnerisch auch noch möglich.....
Christian J. schrieb: > Moment..... ich bin noch dran, da der Upload von Intel Hex nicht mehr > läuft, der verschluckt sich jetzt ..... Q.E.D. ;-) > Ich melde mich sobald ich mehr weiss.... Da kann ich dir helfen: Du brauchst nun eine externe Logik, die den STI Receiver mit einem synchronisierten Takt versieht.
Nein, es gibt Ärger mit der Eingabe... auch beim Tippen immer wieder mal
"Murks". IHX8 Upload läuft nicht mehr, Checksum Fehler kommen immer mit
rein..... also runter auf 38400 gehen, da dürfte der Frame vielleicht
etwas besser passen.
// STI konfigurieren für Uart Ausgabe
STI_UCR = 0x08; // = 10001000 UART Control Register
8N1, DIV16
STI_RSR = 0x01; // RX Status - Enable RX
STI_TSR = 0x05; // TX Status - TX High, TX enabled
// Timer D...
STI_PVR = STI_TDDR; // Zeiger PVR auf Timer D Data
STI_IDR = 0x02; // Timer D Zeitkonstante
STI_PVR = STI_TCDCR; // Zeiger auf Timer C,D Control Register
STI_IDR = 0x8B; // Timer D DIV 16, C = Stop
Dein STI sampelt bei /1 das Rx Signal an zufälliger Stelle. Mal klappt das, weil innerhalb vom Bitframe, mal nicht. Weshalb das auch bei 300bd zwar statistisch besser wird, aber das grundlegende Problem nicht beseitigt.
:
Bearbeitet durch User
Alternative wäre 9600/57600 im Umschaltbetrieb aber leider macht das Terminal sowas nicht mit.... Klar, der macht nur 1 Sampel statt 16 wie vorher und wenn der nicht mittig sitzt, dann schiesst er daneben.....
Was du wirklich brauchst ist ein extern zugeführter Baudratentakt an den RC/TC Pins des STI. Ein Takt, der exakt das 16fache der gewünschten Baudrate darstellt. Bei Systemtakt/2 kriegst du 115kbd und bist etwas jenseits der Auslegung des STI, bei Systemtakt/4 57kbd. Fliegenden '74 versuchen.
:
Bearbeitet durch User
A. K. schrieb: > Was du wirklich brauchst ist ein extern zugeführter Baudratentakt an den > RC/TC Pins des STI. Schon mal die Platine angeschaut? Da geht nix mehr und ein Zusatzboard möchte ich nicht, damit sie läuft, auch wenn das machbar wäre..... derzeit sind TC/RC an den Timer angeschlossen. Was für einen Takt würdest du den vorschlagen an diesen Pins? Ich gehe von 19200 mallangsam hoch derzeit..... etwas aufwendig das ewig zu brennen und die Umschalterei im Terminal....
Christian J. schrieb: > Schon mal die Platine angeschaut? Deshalb schrieb ich ja auch "fliegend". Notfalls nimmst du die SMD-Version und versteckst das Teil unter dem STI Sockel, damit es echt aussieht. ;)
:
Bearbeitet durch User
Christian J. schrieb: > Was für einen Takt würdest du den vorschlagen an diesen Pins? Das hängt davon ab, welche Baudrate du gerne hättest und ob du bereit bist, den STI auf den RC/TC Leitungen versuchsweise zu übertakten. Aber eigentlich hatte ich das vorhin schon geschrieben. Lesen.
Da steht 4 Mhz und 3.6Mhz habe ich. Und das mit dem Übertakten ginge auch, wenn gleich die ganze Platine mit 5.9 bestückt würde, dann wäre der STI extrem, überdreht.
Mit Übertakten war der /16 Baudratenteiler des STI gemeint. Der ist beim
-04 auf ca. 1MHz begrenzt, bei 115k landest du aber bei 1,8MHz.
Also: Systemtakt/2 = 1,8MHz => 115kbd
Systemtakt/4 = 0,9MHz => 57600bd
74HC74 als Teiler an den Systemtakt, Ausgang davon an RC/TC vom STI.
:
Bearbeitet durch User
Nix zu machen, selbst bei 19200 trifft er es nicht in die Mitte. War ja auch klar, da das Ganze sich auf jedem Baudbereich auswirkt, dürfte bei 300 auch nicht anders sein. 57600 taugen also nur zur Ausgabe über TX aber mit RX bin ich derzeit an die 9600 gefesselt.
A. K. schrieb: > Mit Übertakten war der /16 Baudratenteiler des STI gemeint. Der ist beim > -04 auf ca. 1MHz begrenzt, bei 115k landest du aber bei 1,8MHz. Es würden schon 57600 reichen. Ich habe auf der Erweiterungsplatine einen Osc drauf und einen 4020 Takteiler, der sich sogar einstellen lässt über einen Multiplexer. Allerdings wäre dann das hauptboard an diese Platine gebunden. Ergo ginghe es nur einen smd Oscillator unter die Platine zu frickeln und einen smd 4020 oder ...74 dazu. Unter dem IC witzlos, da keine Verbindung nach unten und unten drunter ist es verdammt eng.... Ich Depperl! Wozu habe ich denn einen 3.6864Mhz auf der Platine und noch 4024 Binärteiler in der Kiste womit 0,921600 Mhz erzeugbar sind? Dann läuft es auf jeden Fall synchron zum Systemtakt.
Angehängte Dateien:
-
DSC08188__1024_x_768_.jpg
49 KB -
DSC08189__1024_x_768_.jpg
63 KB
Bin ja mal gesspannt ob der A.K. (wie heisst er eigentlich mit Vornamnen) Recht hat.... die 900khz sind da.... auch wenn das IC nur noch 4 Füsse hat und der Rest abgesägt wurde mangels Platz. Erster Test: Ausgabe funktioniert mit ext. Clock aber IHX8 Decodierung kommt eindeutig nicht mehr hinter, 56700 sind zu schnell für den Code.
Christian J. schrieb: > 56700 sind zu schnell für den Code Dann bau eine Flusssteuerung ein. Entweder XON/XOFF-Protokoll (braucht keine Hardwareänderung) oder RTS/CTS. Jens
Jens schrieb: > Dann bau eine Flusssteuerung ein. > Entweder XON/XOFF-Protokoll (braucht keine Hardwareänderung) oder > RTS/CTS. Dann holst du dir aber die ganzen probleme damit rein, dass XOFF auch zeit zum Senden braucht und in der Zeit der winzige, nur 1 Byte große RX Puffer schon übergelaufen ist. Noch ne Baustelle aufmachen .. RTS(CTS hat nur der echte SIO (Hallo Holm....!) und der STI nicht, auch mein 2 Euro Usart/USB Interface nicht. Nee, ich habe schon die Lösung: Den Systemtakt hochn auf 4.915200 Mhz und daraus einen /2 /16 Takt ableiten, der dann 38400 Baud ergibt. Linux kennt kein 28.800 was ich derzeit noch haben könnte, weil das kein Standard ist. Also zwei Fliegen mit einer Klappe, die Kiste schneller machen und gleichzeitig die Baudrate auf 38.4 hoch, was absolut machbar sein müsste. Und wenn nicht kann der 4024 an dem Q2 Pin auch noch 19200 draus machen. Habe bloss den Osc verbummelt den ich mal hatte und musste grad einen neuen beim großen C bestellen für 10€ inkls Versandkosten.
Christian J. schrieb: > Dann holst du dir aber die ganzen probleme damit rein, dass XOFF auch > zeit zum Senden braucht und in der Zeit der winzige, nur 1 Byte große RX > Puffer schon übergelaufen ist. Immer halblang, du bist nicht der Erste, der sowas implementiert. Wichtig ist nur, dass der Receiver-Interrupt deutlich schneller ist als ein Byte dauert (*). Wenn die Interrupts priorisiert verschachtelbar sind (bei Z80 IM2 kein Problem), dann reicht das als Randbedingung aus. Musst ja den XOFF nicht erst senden, wenn der Puffer im RAM krachend voll ist. Beispiel für XON/XOFF gibts übrigens schon in diesem Thread. Zwar für SIO, aber am Prinzip ändert das nichts. *: Hier könnte C v. Assembler eine kleine Rolle spielen. Ich hatte im Rx-Interrupt zudem den zweiten Registersatz genutzt. > Noch ne Baustelle aufmachen .. RTS(CTS > hat nur der echte SIO Herrje! Das sind auch beim SIO letztlich nur 2 per Programm zu behandelnde Pins, denn einen Handshake-Automatismus hat auch der SIO nicht eingebaut.
:
Bearbeitet durch User
Alternativ: Gibt es beim stty Kommando irgendeine Möglichkeit nach dem Senden eines zeichens eine Pause ein zu stellen? Die Man Page ist erschlagend, verstehe nur die Hälfte was die UART alles kann aber sowas wäre genau das richtige, denn Laden ist ja nur einmal, danach sendet er ja meistens. >>Wichtig ist nur, dass der Receiver-Interrupt deutlich schneller ist als >>ein Byte dauert (*). habs mir angeschaut, was nach dem CRC Fehler im Speicher ist .... der RX Buffer fliegt über "voll" nach 128 Bytes. Das kriegt der Decoder nicht weg geschaufelt. Gerechnet bleiben für jedes Byte nur ca 600 Taktzyklen übrig, wenn 1 Byte 0,13ms braucht. Nicht machbar ohne "Bremse". => CPU schneller takten, anderer Quarz, auf 38400 gehen .... schätze mal 2. Januar sind die bestellten Teile da.
Du kannst ja XOFF schicken, wenn eine Zeile übertragen wurde und erstmal ausgewertet werden muss. Danach geht es mit XON weiter... Christian J. schrieb: > Gibt es beim stty Kommando irgendeine Möglichkeit nach dem Senden eines > zeichens eine Pause ein zu stellen? Bei stty ist mir nichts bekannt. Screen kennt den Befehl slowpaste
1 | <ctrl> a : readbuf <filename> |
2 | <ctrl> a : slowpaste 30 |
3 | <ctrl> a ] |
Oder man verwendet pv zum Verschicken:
1 | pv -qL 10 < intel.hex > /dev/ttyS0 |
Jens
Die Pausen zwischen den Zeichen gibts wohl nicht, Bei FreeBSD jedenfalls nicht, bei Linux weiß ich das nicht so genau. Ich habe mal mit einem alten Epromer gekämpft der bis 80386/25 noch arbeitete, bei allem schnelleren nicht mehr. Das Programm dafür war ein GWBasic Programm und auf dem Epromer werkelte eine 8048 CPU die ja keine serielle Schnittstelle hat (in Software implementiert). Das Ding ist bei schnelleren Rechnern nicht mehr dazu gekommen überhaupt mit RTS Anhalten zu rufen, der Müll wurde einfach über den Haufen geschoben. Da hätte ich mir solche Pausen gewünscht.. Der Promer war wohl mal von Conrad, Design by Auerswald... Gruß, Holm
Jens schrieb: >> Gibt es beim stty Kommando irgendeine Möglichkeit nach dem Senden eines >> zeichens eine Pause ein zu stellen? > Bei stty ist mir nichts bekannt. Im Manual gibts bei ein paar Steuerzeichen irgendwas mit Delays. Wahrscheinlich aus Unix, weil manche Teletypes der 70er nicht fix genug waren. Ich fürchte bloss, dass man dafür im Sourcecode von Linux graben muss, um rauszukriegen ob das überhaupt noch real existiert und was das genau bedeutet.
:
Bearbeitet durch User
Jens schrieb: > Du kannst ja XOFF schicken, wenn eine Zeile übertragen wurde und erstmal > ausgewertet werden muss. Danach geht es mit XON weiter... Hi, bevor ich jetzt die Kiste aus mache, weil ich mich 3 Tage damit befasst habe (vor meinem Umzugh in 2 Wochen, wo dann Ende ist) habe ich XON/XOFF eben ausprobiert. Buffer > 70% dann sende 0x13 Buffer < 30% dann sende 0x11 stty 57600 raw ixon ixoff ..... (natürlich gegeneinander verriegelt, d.h. ein XON wird nur gesendet wenn vorher ein XOFF da war und umgekehrt. Leider mit wenig Erfolg, da der PC da drauf nicht reagiert hat, den Buffer weiter voll schoss (rote LED), während ide gelbe LED am USB/RS232 Adapter zeigte, dass der Z80 dauernd mit XOFF "um Hilfe rief". Bzw auch nicht klar ist ob das Terminal nicht selbst diese Einstellung überschreibt oder nicht. Idealerweise hat man ei fertiges ZMODEM oder XMODEM auf dem Z80 und die passende Hardware dazu (echte SIO....), ich lade ja mit cat ....> /dev..... Der stty Befehl ist extrem mächtig und ein "RTFM" nützt da nichts, wenn man nicht grundlegende Kenntnisse der seriellen Datenübertragung hat. automatisches RTS/CTS ist die zuverlässigste, da Echtzeit. Die PrimeCell UART beim ARM hat die auch und die funktioniert auch, wie ich weiss, weil ich die mal benutzt habe. Ich mach erstmal Feierabend bis der 4.9 Mhz Osc ankommt, der über den 4024 Teiler, der ja schon drauf ist die 38400 ermöglicht und danach hat das schöne Leben "endlich mal Zeit für sich selbst zu haben" auch ein Ende, da ich die Bude hier einpacken muss. Danke auf jeden Fall all jenen, die hier so unermüdlich mit Rat und Tat da waren! Vielleicht kommt ja irgendwann mal der Nächste, der Z80 selbst bauen will und auch die Hartnäckigkeit hat da wirklich dran zu bleiben. Ein selbstgebauter "Computer", den man verfädelt hat, hat im Gegensatz zu den "funktioniert-alles" Arduinos und fertigen "Luxus-Software-Development" Microcontrollern ein gewisses Suchtpotential....
@A.K. Falls Du noch damit was machst... weiss ja nicht.: Die /1 Stufe beim MK3801 funktoniert nur beim Senden und einzelnen Tastendrücken. Ganz selten war da mal ein Murks Zeichen dabei. Sobald aber ein Datenstrom kommt entgleist die Sync nach kurzer zeit und man sieht nur noch Müll als Echo. Keine Ahnung wieso Mostek das überhaupt implementiert hat, wenn sie Sart und Stop Bit eh nicht mehr auswerten und darauf synchronisieren können. Die Mk3801-06 wollen sich einige wohl vergolden lassen.... http://www.ebay.co.uk/itm/MK3801N6-Integrated-Circuit-/400360957688?ssPageName=ADME:X:BOCOR:GB:1123
Christian J. schrieb: > Falls Du noch damit was machst... Das Ding steht seit 20 Jahren irgendwo in einem Keller rum. Schaltplan veschollen. ;-) > Die /1 Stufe beim MK3801 funktoniert nur beim Senden und einzelnen > Tastendrücken. Ganz selten war da mal ein Murks Zeichen dabei. Sobald > aber ein Datenstrom kommt entgleist die Sync nach kurzer zeit und man > sieht nur noch Müll als Echo. Jau. Exakt das hatte ich dir oben auch geweissagt. ;-) Beitrag "Re: Retro Fieber: Z80 oder 68000 ?" > Keine Ahnung wieso Mostek das überhaupt > implementiert hat, wenn sie Sart und Stop Bit eh nicht mehr auswerten > und darauf synchronisieren können. Das Startbit wird offenbar ausgewertet, aber eben nur als Startbit, nicht mehr zur Bitsynchronisation. Deshalb funktioniert ein einzelnen Bytes mit einer gewissen Wahrscheinlichkeit. Aber wenn genug Bytes zusammenkommen schlägt ebendiese Wahrscheinlichkeit dir ein Schnippchen. Sinn ergibt das nur in Zusammenhang mit externer Bitsynchronisation. Also wenn du beispielsweise einen Manchester-Codec extern anflanschst, der den Receiver-Takt aus dem Empfangssignal ableitet.
:
Bearbeitet durch User
Angehängte Dateien:
-
Unbenannt.JPG
26 KB
A. K. schrieb: > Sinn ergibt das nur in Zusammenhang mit externer Bitsynchronisation. > Also wenn du beispielsweise einen Manchester-Codec extern anflanschst. Ich hätte es auch gleich "richtig" machen können und eine Z80 SIO verwenden und dazu noch eine ROM Umschaltung auf 64klb RAM...... allerdings sind alle Fallstricke immerhin selbst "erarbeitet" worden bzw "erlitten" .... bzw. stelle ich mir die Frage ob ich so belassen soll oder noch eine V2.0 bauen soll auf Platine. CP/M interessiert mich ehrlich gesagt nicht, weil das eh nur ein Spielzeug ist ("Oh, schön......CP/M läuft.... und was mach ich damit jetzt?"). Fürs "Programmieren" reicht es ja und die SD karte kriege ich auch noch ans Laufen, bevor die 16kb Monitor voll sind. Und irgendeine Anwendung, wo irgendwas schaltet und sich bewegt wird sich auch noch finden lassen. Etwas mit Elektromagneten und Flipper Kugeln schwirrt mir da im Kopf herum.... habe mal ein Demo Modell gebaut vor 10 Jahren auf Plexiglasplatte wo sich eine Solarzelle nach der Sonne mit bewegte mit Steppermotor. 2 grüne LED in Hülsen als Sensor (Blöd nur, dass die Sonne die offene Technik recht schnell ausgebleicht hat.) Sieht jedenfalls lustig aus, was sich da alles so "bildet".... nur fehlt mir noch ein Abruch Kriterium für endgültige Muster bzw "Blinker", dass er dann neu startet.
Christian J. schrieb: > Ich hätte es auch gleich "richtig" machen können und eine Z80 SIO > verwenden und dazu noch eine ROM Umschaltung auf 64klb RAM...... ;-) > schön......CP/M läuft.... und was mach ich damit jetzt?"). Und das ist jetzt anders? Ein Bekannter war mal über einen recht guten gebrauchten Joystick gestolpert. Passend für den ollen Flugsimulator. Da hat er dann etwas dran rumgebaut, nach und nach mehr und mehr, bis irgendwann ein Cockpit fertig wird, mit Instrumententafel, Schaltern und allem Gedöns. Sowas ist genau so lange interessant bis es fertig ist, plus maximal ein paar Wochen. Dann sieht es knorke raus, steht unbenutzt rum und die Frau hält einen für komplett bescheuert. ;-)
:
Bearbeitet durch User
Angehängte Dateien:
-
IMG_0020.JPG
88 KB -
IMG_0020.JPG
330 KB
A. K. schrieb: > Da hat er dann etwas > dran rumgebaut, nach und nach mehr und mehr, bis irgendwann ein Cockpit > fertig wird, mit Instrumententafel, Schaltern und allem Gedöns. Sowas > ist genau so lange interessant bis es fertig ist, plus maximal ein paar > Wochen. Hmmm...... meine Modelleisenbahn..... mein selbst restaurierter Fiat X1/9 ....... kommt mir sehr bekannt vor.... alss der nach 1 Jahr fertig war genau 1/2 Jahr gefahren und dann verkauft..... total unbequeme Klapperkiste.....ewig rappelte was...... aber das Basteln war schön :-) Hat mich auch wohl meine Ehe damals "gekostet" :-)
Angehängte Dateien:
PS: Ich habe da schon ein "nächstes Projekt" im Auge..... wozu 5V wenn man auch 50 MegaVolt haben kann :-) https://www.youtube.com/watch?v=3FpjcOWwiI4
Holm Tiffe schrieb: > Die Pausen zwischen den Zeichen gibts wohl nicht, Bei FreeBSD jedenfalls > nicht, bei Linux weiß ich das nicht so genau. > > Ich habe mal mit einem alten Epromer gekämpft der bis 80386/25 noch > arbeitete, bei allem schnelleren nicht mehr. Das Programm dafür war ein > GWBasic Programm und auf dem Epromer werkelte eine 8048 CPU die ja keine > serielle Schnittstelle hat (in Software implementiert). Das Ding ist bei > schnelleren Rechnern nicht mehr dazu gekommen überhaupt mit RTS Anhalten > zu rufen, der Müll wurde einfach über den Haufen geschoben. Da hätte ich > mir solche Pausen gewünscht.. > > Der Promer war wohl mal von Conrad, Design by Auerswald... > > Gruß, > > Holm Das Problem habe ich gelöst in dem ich 2 Druckerports mit EP/PP verwendet habe und meinen Prommer Transistor, Relais Jumper selbst gestrickt und die SW in in Qbasic(ver. 1-7.1) geschrieben hatte (letere viel leider einem Systemabsturz zum Opfer) aber am MAXimite bekomme ich die sicher wieder zum laufen. ;) So ein universeller Basic-Zwerg mit genügend Ports ist recht vielseitig zu verwenden. Neue Anforderung---> neues Programm-gleiche HW Basis.
Christian J. schrieb: > Hat mich auch wohl meine Ehe damals "gekostet" :-) Dazu brauchte ich nicht mal 4 Räder. Das habe ich mit allein Programmiersessions am Atari auch so geschafft. Ein Hobby ist für eine Frau wie Fremdgehen die eine nimmt es hin, die andere nicht da ist ein Motorrad besser, falls sie gern selbst eines fährt. Namaste
Winfried J. schrieb: > Dazu brauchte ich nicht mal 4 Räder. Es waren zeitweise 20 Räder...... 2.8l Ford Capri, 2 x Scirocco II, 1 Fiat X1/9, 1 x 2.0 Ford Taunus Ghia
Christian J. schrieb: > Winfried J. schrieb: >> Dazu brauchte ich nicht mal 4 Räder. > > Es waren zeitweise 20 Räder...... 2.8l Ford Capri, 2 x Scirocco II, 1 > Fiat X1/9, 1 x 2.0 Ford Taunus Ghia Ein Auto wolltest Du wohl nicht.. Gruß, Holm
Angehängte Dateien:
-
home.jpg
60 KB
Holm Tiffe schrieb: > Ein Auto wolltest Du wohl nicht.. Doch, das hier war der Geilste...... schade dass ich ihn verkaufen musste :-( 16l/100km und "Schwarze Umweltplakette" hatten was
@Holm:
Ich fühle mich bei Asm als wenn ich auf Eiern gehe, jedes Bisschen test
kompilieren und Fehlermeldungen anschauen bei diesem ASXXXXX Assembler,
wo nicht mal eine .define Anweidung funktioniert, ohne einen Fehler zuu
erzeugen. Anleitung habe ich aber irgendwie macht er was anderes als da
steht.
Ausprobieren geht auch nicht da ich keinen Simulator habe bzw nicht
weiss wie ich den Code, der als 1 Hex File da liegt da testen soll.
Ich müsste entweder die eigene Adresse herausfinden, wo der Programmcode
grad ist oder eben einen Schreibtest machen, ob er im Eprom oder Ram
ist. Beim 6502 ging es, dass man die aktuelle PC (Program Counter)
Adresse mit einem Befehl heraus fand, zb wäre die 0x00(00) für die
Zeropage.
Geht das mit dem Z80 Asm auch eleganter als mein Werk da unten?
testvar .db 0x00
; Sind wir grad im RAM oder EPROM? => Schreibtest ausführen
ld a,#0xAF
ld (rwtest),a ; 0x55->Testvariable
ld a,(rwtest) ; Testvariable -> A
cp #0xAF ; Schreiben erfolgreich?
jp Z, init2 ; =Z, wir sind im RAM, dann überspringe
; Wir sind im EPROM, dann pruefe, ob ein Programm im RAM liegt
ld a, (ram_prog) ; Lade Start des RAM 0x4000
cp #0xC3 ; vergleiche mit "C3" = JP Befehl
jp Z, ram_prog ; Ja, dann springe direkt ins Ram hinein
Noch zum SDCC: Die Option --max-allocs-per-node 200000 erzeugt zwar 20
Minuten Compilerlauf aber aus 13kb Code schafft er dann locker 12kb zu
machen, der erzeugte Code sieht absolut "optimal" aus. Dank Leo, wusste
ich vorher nicht, dass man eine Release Version erzeugen kann, auch wenn
es 20 Mionuten dauert.....
call l1
l1: pop af ;A = high(PC)
cp a,...
:
Bearbeitet durch User
A. K. schrieb: > call l1 > l1: pop af ;A = high(PC) > cp a,... Oh weh..... alle das war mal "da" vor 25 Jahren und muss nun wieder neu erlernt werden...... Warum .define SYMBOL nicht geht weisst du sicher auch nicht? Also auch das nicht. .ifdef SYMBOL lalala..... .endif
Christian J. schrieb: > Warum .define SYMBOL nicht geht weisst du sicher auch nicht? Kaum, da ich nie in deinem Assembler programmiert habe. > alle das war mal "da" vor 25 Jahren und muss nun wieder neu > erlernt werden...... Ist ein Kniff, den man bei heutigen CPUs der besseren Sorte auch keinesfalls anwenden sollte, weil bösartig bremsend.
:
Bearbeitet durch User
Christian J. schrieb: > Ich fühle mich bei Asm als wenn ich auf Eiern gehe, jedes Bisschen test > kompilieren und Fehlermeldungen anschauen bei diesem ASXXXXX Assembler, Also wenn ich mir das Bild ansehe, dann gehts wohl kaum noch einfacher: http://www.heise.de/download/z80-simulator-ide-1119083.html
:
Bearbeitet durch User
Nochmal zur "ROM Ausblendung" Habe da in "C" länger drüber nachgedacht, wie man das bewerkstelligen kann, weil es in Asm ja deutlichn einfacher ist, man nicht den sdcc drüber sitzen hat, der einem die Labels auf die kompilierte Adresse anpasst usw. Es ginge echt nur so: 1. Ur Lader (auf C000 kompiliert) und als adressloses BIN abgelegt. 2. Direkt die ersten Behle sind ..... LDIR mit der er sich selbst "hoch" kopiert, zb nach C000. 3. Sprung nach "oben" hinter Kopierroutine 4. ROM unten abschalten 5. Monitor starten 6 User Programm nach unten laden 7 Sprung ins User Programm Diese Kopierroutine muss notfalls als Einzelbytes abgelegt werden, da jeder "Bezug" oberhalb des eigenen Segment ein ungültiger Bezug für den Compiler ist. Anders geht es nicht.....
A. K. schrieb: > Also wenn ich mir das Bild ansehe, dann gehts wohl kaum noch einfacher: > http://www.heise.de/download/z80-simulator-ide-1119083.html Kenn ich schon. Läuft nach 7 Tagen ab und ist eingeschränkt.
Christian J. schrieb: > A. K. schrieb: > >> call l1 >> l1: pop af ;A = high(PC) >> cp a,... > Damit bekommt man raus ob der Stackpointer auf RAM zeigt. > Oh weh..... alle das war mal "da" vor 25 Jahren und muss nun wieder neu > erlernt werden...... > > Warum .define SYMBOL nicht geht weisst du sicher auch nicht? > > Also auch das nicht. > > .ifdef SYMBOL > > lalala..... > > .endif Naja Moment, die Assembler haben unterschiedliche Dialekte, gerade für solche Pseudoops. Ich weiß jetzt nicht was Dein ASXXXXX genau ist, ist das der Frankenstein-Assebmler? Wenn ja, dann gehen da Definistionen über EQU und das Festlegen von Bytes mit DB oder DS. IMHO kann der aber auch bedingte Assemblierung. A.1.1 Standard_Pseudo_Operation_Mnemonics End END File Inclusion INCL INCLUDE If IF Else ELSE End If ENDI Equate EQU Set SETEQU Org ORG Reserve Memory RESERVE RMB Define Byte Data BYTE DB FCB Define Word Data DW FDB WORD Define String Data FCC STRING Define Character Set Translation CHARSET Define Character Value CHARDEF CHD Use Character Translation CHARUSE Ich habe den SDCC mit seinem Assembler bisher nie benutzt. Das letzte war wohl dieser WLA-DX oder wie der heißt, der kann zwar Macros ist aber mit seiner Linkerei sehr "speziell".. Gruß, Holm
Christian J. schrieb: > Kenn ich schon. Läuft nach 7 Tagen ab und ist eingeschränkt. Ja. Kostet mörderische 25€.
Ich weiss nicht ob der das was der sdcc ausspuckt auch als Eingabe nimmt. Oft muss ja ja nur 1 Modul testen und nicht das ganze Programm. Müsste ich mal ausprobieren. Die Oberfläche ist nicht ganz so einfach weil man sehr viele Fenster hat, die "irgendwie" miteinander in Verbindung stehen.
Christian J. schrieb: > Anders geht es nicht..... Nicht nur ich frag mich manchmal, ob du ab und zu auch liest, was andere Leute schreiben. Weils schon recht interessant wirkt, wenn du als deine Erkenntnis präsentierst, was schon Äonen vorher hier geschrieben stand.
Christian J. schrieb: > Ich weiss nicht ob der das was der sdcc ausspuckt auch als Eingabe > nimmt. Das war grad eher als Anregung für etwas Übung mit Assembler-Befehlen gemeint. Nicht für komplette SDCC Programme. Bisschen Assembler geht darin recht elegant. Tief reingesehen habe ich auch nicht, nur grad mal ein paar Assembler Befehle ausprobiert. Die zig anderen Emulatoren habe ich mir auch nicht angesehen.
:
Bearbeitet durch User
A. K. schrieb: > Weils schon recht interessant wirkt, wenn du als deine > Erkenntnis präsentierst, was schon Äonen vorher hier geschrieben stand. Wieso, du wolltest doch den unter sich slebst kopieren und das macht eh keinen Sinn weil man da ja noch mal kopieren muss, damit Userprog nach 0x0000 kommt.
Christian J. schrieb: > Wieso, du wolltest doch den unter sich slebst kopieren Das war eine Variante. Wie das genau abzulaufen hat hängt davon ab, ob das RAM in der Startphase überhaupt irgendwo lesbar ist. Notwendig ist das nämlich nicht und man erspart sich so die Adressabhängigkeit der ROM/RAM Ansteuerung. Ohne Adressdekoder kann man 64KB über sich selbst kopieren, umschalten und dann nach oben springen. Oder erst nach oben springen und dann umschalten, das ist egal. Mit Adressdekoder kann man 8KB nach oben kopieren, dorthin springen und dann umschalten. Der Unterschied besteht in den für die Adressdekodierung nötigen Gattern. Die sich vielleicht anderweitig besser nutzen lassen.
:
Bearbeitet durch User
Christian J. schrieb: > Holm Tiffe schrieb: >> Ein Auto wolltest Du wohl nicht.. > > Doch, das hier war der Geilste...... schade dass ich ihn verkaufen > musste :-( 16l/100km und "Schwarze Umweltplakette" hatten was lechz ja für den würde ich auch .......,öhm such ich noch ;)
Holm Tiffe schrieb: > Damit bekommt man raus ob der Stackpointer auf RAM zeigt. Stackpointer ist ROM ist so ne Sache... Damit bekommt man mit vielen Takten raus, wo man grad unterwegs ist in der Speicherlandschaft..... Rücksprungadresse auf Stack, zurück nach A und F(lag) register, A ist 0x00 bei der Zeropage. Schon eingebaut, spielt.
@A.K. 4.9 Mhz Quarz kam heute an von Conrad: Riesenkarton und drin eine winzige Sachtel mit dem Quarz Oscillator. Eingelötet, Timer ab, Takt direkt drauf. 38400 eingestellt. 5 Minuten Arbeit. Spielte sofort, endlich Speed auf dem Schirm und eine spürbare fixere CPU :-) Codeänderung: keine. IHX8 Upload lief ohne Veränderungen, auch wenn er jede empfangene Zeile mit einem "." quittiert damit man auf dem Schirm etwas sieht. Supi :-)
:-))) Habe Kontakt zu Dr. Kieser bekommen (90% Autor Kieser/Meder "Mikorprozessortechnik"), er schreibt dass er sich gern an diese Zeit im FW Erfurt erinnert und ich könne auch gern Fragen zur U880 usw. stellen.
Hallo liebe RETROs,,, ganz kurz zu mir: hatte eigentlich die Bank durch, Sinclair ZX81, ORIC1, KWS-SAM68k, c´t EPAC 68008 - dazu hab ich auch ein eigenes Board in Eagle mal gemacht; allerdings Doppel-Euro und um einen Lattice ISP1032 erweitert, da wollte ich die GALs reinpacken und das Ding dann Schritt für Schritt verkleinern. Dann bin ich auf XILINX aufmerksam geworden, FPGAs mit Million-Gattern --> Software CPU gleich rein; siehe c´t Hacks Mini-Asteroids; die haben da einen 6502 bzw. kompletten C64 reingeschossen mit Video sogar. Alternativ mal was sau-einfaches: (noch mehr Retro) aber läuft... Eine 8085CPU mit PIO dazu, in der sind 256Byte RAM mit drin, dazu noch ein EPROM für den Code -- absolut easy. geht halt nur in ASM, aber für (fast nix) ist das OK und eben mal schnell auf Lochraster gestrickt. Noch ein Tipp (Retro): ZMD --> Zentrum Mikroelektronik Dresden Die bauen / bauten NV-SRAMS - ganz geckig, ohne Batterie mit einem Flash-Spiegel parallel. Ein 10uF Tantal als Stützkondensator reicht denen, beim Power-Fail das SRAM 1:1 ins Flash zu übertragen und beim Power-wieder-da das ganze umgekehrt. Aüßerlich ist das ein 6232..62256 SRAM rsp. deren DALLAS-Eqivalente. Ganz geckig an ZMD - hatte mir sehr imponiert!!! Die bauen, weil es ohnehin egal ist, eine 8080CPU mit auf den Wafer dazu - gratis - sozusagen. Muss ich auch mal reingoogeln demnächst... Bin auch am (wieder)Neustart mit dem Kram und auf der Suche nach simpel. Andreas Seck, Krämergasse 16, 35083 Wetter Ernst gemeinte Briefe herzlichst willkommen. Ich beantworte diese dann gerne und garantiert! Besser als im Netz zu versumpfen und sich tot zu suchen. Gruß A.S. 10.01.15
Hallo, auch wenn der Thread in der Versenkung gelandet ist .... mein kleines System wächst munter weiter und V2.0 ist in Planung. V2 soll auf einer Platine entstehen und nicht mit Fädeltechnik und einiges mehr bieten, zb einen Bus auf Messerleiste. Das wirft einige Fragen auf: 1. Ab wann muss ich Bustreiber wie den 74HCT245 (bi-direktional) und 74HCT244 (unidirectional) für Adress und Datenleitungen verwenden? Und mit welcher Leitung des Z80 bzw. externer Logik wird der Tri-State Zustand aktiviert? (Bisher habe ich am Datenbus 7 Bausteine hängen und er bricht immer noch nicht zusammen.) 2. Welches Bussystem ist das bekannteste? Wie läuft da die Sache mit den I/O Bausteinen? Chip Select Bausteine braucht man ja sicher immer noch. 3. Monitor / Tastatur: Ich plane ein Video Interface mit ein (Monochrom, 80x40 reicht aus, Pixell Grafik?) und einen Tastatur Adapter. Gibt es da was Fertiges? Sollte einfach nur funktionieren. CP/M ist nicht ausgeschlossen, daher muss mein V2 Board dafür schon vorbreitet sein. (Bank Switching, XT Interface, ROM Ausblendung usw.)
>auch wenn der Thread in der Versenkung gelandet ist Ja, das liegt u.a. auch daran, daß du dich bisher sehr bemüht hast, alle sinnvollen Ratschläge mäanderförmig zu umschiffen und dich möglichst viel auf inkompatiblen Nebenschauplätzen auszutoben. >einige Fragen 1. Habe nur praktische Antwort, die nicht "berechnet" ist: Intern auf der Platine keine Treiber am Adress-, Daten- oder Control-Bus. Jedoch (Bus-) Treiber auf allen Signalen die nach extern zur Steckerleiste gehen. Für die komplette des Bussteuerung bei voller DMA-Fähigkeit brauchte der Datenbustreiber mit seiner Richtungssteuerung 7 Produkttherme eines damaligen PALs. Nicht trivial. 2. In Deutschland war das wohl mal der ECB-Bus http://de.wikipedia.org/wiki/Europe_Card_Bus Freilich braucht man Chip-Selects; es muss ja eine Dekodierung geben. Und man hat i.d.R. auf jeder I/O Karte einstellbare Grundadresse für die dort befindliche Peripherie, also deren I/O-mapping. 3. Viele Möglichkeiten. Einfach und kompliziert. Einfach ist Textmode mit 6845. Komplexer ist z.B. Terminal-Nachbildung auf separater Europakarte, teils mit eigener CPU (komplettes Subsystem). Oder NEC7220, wem das zu einfach ist. Tastaturinterface keine einheitliche Norm, da es IBM-PC und dessen Tastaturschnittstelle (DIN- oder PS/2 MiniDIN Stecker) noch nicht gab. Wäre aber wohl inzwischen sinnvollste (wennauch nicht "retro") Möglichkeit. Gruss
Erich schrieb: >>auch wenn der Thread in der Versenkung gelandet ist > Ja, das liegt u.a. auch daran, daß du dich bisher sehr bemüht hast, alle > sinnvollen Ratschläge mäanderförmig zu umschiffen und dich möglichst > viel auf inkompatiblen Nebenschauplätzen auszutoben. Tja, der ROM/RAM Switch, der fehlt wirklich und die Baudrate von 38400 ist auch nur durch einen Trick entstanden. Aber da hat allein der A.K. schuld :-) Mit seinem MK3801 tip, dem Stromfresser mit den 8 Bit Krücken-Timern. stichel > Jedoch (Bus-) Treiber auf allen Signalen die nach extern zur > Steckerleiste gehen. Also kriegt jede Karte ihre eigene Entkopplung? Macht ganz schömn Chips, wenn man mal die Steuerleitungen mit dazu zählt. > Für die komplette des Bussteuerung bei voller DMA-Fähigkeit brauchte DMA lassen wir mal ..... ist mir zu kompliziert und nur für größere Systeme mit Massenspeichern und GraKa. > Datenbustreiber mit seiner Richtungssteuerung 7 Produkttherme eines > damaligen PALs. Nicht trivial. Mal ne dumme Frage: Gibt es eine Software, die einem das Gattergrab berechnet, wenn man zb Min und Max Term als Eingabe gibt? Ich erinnere mich schwach an sowas vor 20 Jahren, nannte sich Karnaugh Diagram zur Optimierung von Logik. Alledings fehlte ich da wohl in der Vorlesung. > In Deutschland war das wohl mal der ECB-Bus USA: S100? Ok. > Und man hat i.d.R. auf jeder I/O Karte einstellbare Grundadresse für die > dort befindliche Peripherie, also deren I/O-mapping. Ok. Gebongt. > Einfach und kompliziert. Einfach ist Textmode mit 6845. > Komplexer ist z.B. Terminal-Nachbildung auf separater Europakarte, teils > mit eigener CPU (komplettes Subsystem). Sollte auf jeden Fall VT102 oder besser sein. Kompletter Interpretation des Vt100 Standards. Sowas wie hier zb. Sehr schön. http://www.klichs.de/files/projekt-2.htm
Christian J. schrieb: > 3. Monitor / Tastatur: Ich plane ein Video Interface mit ein (Monochrom, > 80x40 reicht aus, Pixell Grafik?) und einen Tastatur Adapter. Gibt es da > was Fertiges? Sollte einfach nur funktionieren. Beitrag "VT100-Terminal (VGA+PS2)"
Joe G. schrieb: > Beitrag "VT100-Terminal (VGA+PS2)" Muss "Propeller" programmiert werden? (Kann ich nicht). Und kann ich Platine bei Dir kaufen?
Der Propeller wird über die USB Schnittstelle auf der Platine „programmiert“. Das geht mit den zugehörigen Software von Parallax. Die Platinenversion mit einem kleinen Hardwarefehler (Signalquellenumschaltung) gibt es umsonst gegen Erstattung des Portos. Die korrigierte Version braucht noch ein paar Tage. Die Software sowie die Doku gibt’s hier: http://www.mikrocontroller.net/svnbrowser/avr-cp-m/trunk/VT100/docs/?sortdir=down
Angehängte Dateien:
-
DSC08225__1280_x_1024_.jpg
220 KB -
DSC08234__1280_x_1024_.jpg
200 KB
Hi, ok, ich melde mich dann. Sollte zu schaffen sein. Für den es interessiert, anbei meine kleine Z80 Fabrik, die noch um eine Karte links ergänzt wird, wo Relais und Eingänge Platz finden. Nett warm die ganze Geschichte :-)
Hallo, > 1. Ab wann muss ich Bustreiber wie den 74HCT245 (bi-direktional) und > 74HCT244 (unidirectional) für Adress und Datenleitungen verwenden? Normalerweise, wenn du viele Bausteine und/oder lange Kabel dran hängen hast (parasitäre Kapazitäten). Ohne DMA musst du in CPU-Peripherie-Richtung die Steuer- und Adressleitungen, sowie die Datenleitungen bei Schreibzugriffen treiben, und in Peripherie-CPU-Richtung die Datenleitungen bei Lesezugriffen. Das hält sich in Grenzen. > Und mit welcher Leitung des Z80 bzw. externer Logik wird der Tri-State > Zustand aktiviert? (Bisher habe ich am Datenbus 7 Bausteine hängen und > er bricht immer noch nicht zusammen.) Wenn du /BUSREQ auf low legst, legt der Z80 /BUSACK auf low und geht in Tristate. Aber der tut dann überhaupt nichts mehr, bis du das wieder sein lässt... > 2. Welches Bussystem ist das bekannteste? Wie läuft da die Sache mit den > I/O Bausteinen? Chip Select Bausteine braucht man ja sicher immer noch. Denk' dir was eigenes aus, so schwer ist das nicht. Ansonsten kannst du dir mein System als Beispiel nehmen. ;-)
1 | Beachte: |
2 | - Slot 0 ist bei mir speziell, weil der /BUSREQ und so hat. ;-) |
3 | - Slot 1 hat /MREQ und /RFSH, weil dort der Speicher steckt, |
4 | alle anderen sind dort nicht verdrahtet. |
5 | - /INT und /SEL (Chip-Select) werden zentral dekodiert |
6 | und jeweils als eigene Leitung auf "ihren" Slot geführt. |
7 | - DMA fehlt. |
8 | - "daneben stecken" schadet nicht, weil neben Vcc und GND |
9 | nichts angeschlossen ist (außer auf Slot 1) |
10 | |
11 | Das Pinout (eine Reihe, 36 Pins) der Slots ist wie folgt: |
12 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |
13 | | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | |
14 | | Vcc |/MREQ|/RFSH| GND | n/c | n/c | /RES|/WAIT| /SEL| /INT| /RD | /WR | |
15 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |
16 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
17 | | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | |
18 | | D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | |
19 | +-----+-----+-----+-----+-----+-----+-----+-----+ |
20 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |
21 | | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | |
22 | | A0 | A1 | A2 | A3 | A4 | A5 | A6 | A7 | A8 | A9 | A10 | A11 | A12 | A13 | A14 | A15 | |
23 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ |
> 3. Monitor / Tastatur: Ich plane ein Video Interface mit ein (Monochrom, > 80x40 reicht aus, Pixell Grafik?) und einen Tastatur Adapter. Für "echtes Retro" kannst du eine Tastaturmatrix an Schieberegister klemmen und VGA als Gattergrab implementieren, das ist machbar. Für "soll funktionieren" baust du dir am besten ein Terminal als separates Projekt und schließt das seriell an dein System an. Für Text nimmst du VT100, farbig mit VT220. Monochrome Vektorgrafik gibt's mit Tek40xx. Für Pixelgrafik ist mir kein Standard bekannt. Als Kompromiss kannst du Tastatur und VGA auch in einen Mikrocontroller stecken, die du an dein Bussystem anschließt. Es gibt PICs mit Slave-Bus-Interface, leider keine AVRs. Alle Versuche, PS/2 und VGA mit einem AVR zu machen, sind gescheitert - ein 32-Bitter sollte das aber schaffen. Ob ein AVR 80x40 kann, weiß ich nicht. Gruß, Svenska
Hi, für die VGA Darstellung gibt es mehrere Lösungen: Hier mit einem AVR, was zu gehen scheint: http://searle.hostei.com/grant/MonitorKeyboard/index.html Dann noch das hier dargestellte Board mit Propeller, was mich sehr interessiert und wenn man es ganz einfacha haben will kauft man sich für 20 Euro einen 14z Bildschirm (habe ich schon), klebt dahinter einen Raspberry Pi, der nur minicom einstellt und hochfährt und schließt an dessen USB Interface dann den Z80 mit FTDI Adapter an. Leider kein RTS/CTS, denn PC Adapter damit sind sehr selten. Ich habe einen, auch mit DTR etc aber noch nicht ausprobiert. Ohne RTS/CTS veschluckt er sich doch manchmal bei 56700 baud. Mit Tri-State meinte ich, dass die Bustreiber einen Enable haben, der irgendwie angeschlossen werden muss. Die CPU lässt ja die Adressleitungen nicht immer aktiv. Bei BUSREQ nimmt sie die hoch, sicherlich auch bei internen Vorgängen wenn grad kein Fetch anliegt. Ich weiss nicht ob da was rausgeführt ist (M1?), das man nutzen kann. Dein Bus sieht ja auch nicht anders aus als eben alle Pins rausführen :-) Dazu noch ein paar Select Leitungen, 8 habe ich. Das verpasst allen externen Karten dann eine fixe Adresse. Man sucht sich nur aus welchen SEL sie kriegen. Keyboard macht ja nur Sinn bei CP/M, da scheine ich wohl nicht drum herum zu kommen..... bzw kann ich da auch gleuch bei N8VEM weitermachen, denn da ist alles schon schön dokumentiert und fertig. Und drüber nachdenken, dass es das Ganze Platinengrab als einen einzigen Chip (Cortex...) gibt, der zudem noch 100 Mal schneller ist, mehr ROM, RAM etc hat darf man eh nicht. Bin da etwas von runter, denn wenn ich "voll retro mässig" alle Chips durch NMOS Typen ersetze dann brät er mir die 7805er weg und die beiden Trafos brechen zusammen wenn sie fast 550mA an 5V liefern sollen. Die russ. NMOS 8253 Timer werden bald derart heiss, dass man die Flossen verbrennt. Habe auch noch "Retro" 74er hier, die allerersten SN7400N, 50mA pro Baustein.... muss ja nicht sein.
VGA mit AVR geht. PS/2 mit AVR geht auch. Beides gleichzeitig mit einem AVR geht nicht. > Leider kein RTS/CTS, denn PC Adapter damit sind sehr selten. Ich > habe einen, auch mit DTR etc aber noch nicht ausprobiert. Ohne > RTS/CTS veschluckt er sich doch manchmal bei 56700 baud. Das kann ich mir nicht vorstellen. Entweder RTS/CTS oder DTR/DSR sollten die haben. Du bist dir sicher, dass sich der Adapter verschluckt und nicht der Z80? Handshaking funktioniert nicht mit Bytegrenzen und viele Systeme (auch PCs mit 16550) senden noch ihren FIFO leer, wenn RTS deaktiviert wird. Dein Z80 muss also noch bis zu 15 weitere Bytes verkraften, nachdem er die Gegenseite angehalten hat (mit XON/XOFF kann das auch noch mehr werden). > Mit Tri-State meinte ich, dass die Bustreiber einen Enable haben, der > irgendwie angeschlossen werden muss. Die CPU lässt ja die > Adressleitungen nicht immer aktiv. Die Synchronisation auf dem Bus geschieht durch die Steuerleitungen. Deine Enable-Signale musst du dir daraus schon selbst zusammenbasteln, je nachdem, was an deinem Bus hängt. Da ich für Peripherie nur I/O unterstütze, hängen die Enables für meine Steuer- und Adressleitungen auf Masse und für die Datenleitungen an /RD. Mit einem '138 erzeuge ich /SEL, dessen Enables hängen an /M1 und /IORQ. Ohne aktives /SEL haben die Geräte still zu sein. > Bei BUSREQ nimmt sie die hoch, > sicherlich auch bei internen Vorgängen wenn grad kein Fetch anliegt. Ich > weiss nicht ob da was rausgeführt ist (M1?), das man nutzen kann. Mit /BUSREQ nimmst du dem Z80 den Bus weg, damit ein anderer Master spielen kann (DMA), als Enable-Signal taugt das nix (und ist am Z80 sowieso ein Eingang). ;-) > Dein Bus sieht ja auch nicht anders aus als eben alle Pins rausführen > :-) Dazu noch ein paar Select Leitungen, 8 habe ich. Das verpasst allen > externen Karten dann eine fixe Adresse. Man sucht sich nur aus welchen > SEL sie kriegen. Ja. Und was ist da jetzt der Unterschied zu S-100 oder ECB? Außer, dass ich weniger Chips brauche, um das Zeug zu implementieren? ;-) Wenn du keine Hardware dafür hast, spielt dein Bussystem kein Rolle. > bzw kann ich da auch gleuch bei N8VEM weitermachen, > denn da ist alles schon schön dokumentiert und fertig. Seufz. Und wieder die alte Leier. > Und drüber nachdenken, dass es das Ganze Platinengrab als einen einzigen > Chip (Cortex...) gibt, der zudem noch 100 Mal schneller ist, mehr ROM, > RAM etc hat darf man eh nicht. Aber einen Cortex an den Z80 zu klemmen und ein VGA-Signal erzeugen zu lassen, ist wesentlich einfacher, als ein Gattergrab dafür zu bauen. Mit ein bisschen zusätzlichem Speicher kriegst du sogar Pixelgrafik hin. Oder dank höherer Rechenleistung eine höhere Auflösung im Textmodus, damit du nicht auf hässliche 8x8-Klötzchenbuchstaben starren musst.
S. R. schrieb: > - /INT und /SEL (Chip-Select) werden zentral dekodiert > und jeweils als eigene Leitung auf "ihren" Slot geführt. Ich würde dezentral dekodieren. Das schränk man sich nicht gleich von vornherein ein. Außerdem würde ich /NMI, /HALT und vor allem /IORQ mit auf die Leiste setzen. Sonst kann auf den Slaves nur Speicher bzw. memory-mapped-IO eingesetzt werden. Neben S100 und ECB gibt es auch noch diverse Abwandlungen des K1520-Standards... http://hc-ddr.hucki.net/wiki/doku.php/homecomputer:k1520 Jens
Christian J. schrieb: > Hi, > > ok, ich melde mich dann. Sollte zu schaffen sein. Für den es > interessiert, anbei meine kleine Z80 Fabrik, die noch um eine Karte > links ergänzt wird, wo Relais und Eingänge Platz finden. Nett warm die > ganze Geschichte :-) Hi! Schaut cool aus! Was mich wirklich interessieren würde wäre der Schaltplan und der komplette Quellcode...
Harald Nagy schrieb: > Schaut cool aus! Was mich wirklich interessieren würde wäre der > Schaltplan und der komplette Quellcode... Hier.... wobei ich jetzt nicht sagen will, dass die Extension was "Sinnvolles" macht. Das ist nur mein Werk ohne Anwendung dahinter. Extensionboard braucht noch Software für die SD karte, Z80 spielt die Daten bisher seriell dort ein, ein Header enthält alle Eckdaten (sd.c) und der AVR, der mit Arduino programmiert wird nimmt sie auf Software-SPI entgegen (hoffe das klappt) und ees werden open, write, read und close implementiert. Das ist aber alles noch nicht fertig. Bisher nur Timer, Shift Register.
Joe G. schrieb: > Ein weitere VT100 Lösung findest du hier: > http://geoffg.net/terminal.html Die ist ja Klasse! Mit Grafik ESC Sequencen. Nur schade, dass meine ncurses von Frank M. sowas nicht unterstützt, da wäre noch einiges zu machen. Ketzerische Frage: Die oder lieber deine bauen? :-) Die kommt mit PIC32 daher für den ich einen Programmer habe.
Harald Nagy schrieb: > Vielen Dank! Eagle Format, Freeware Version für Linux... ps: Diese Geoff Page hat echt schöne Projekte und alle sind komplett dokumentiert und mit Unterlagen, Layouts usw dabei. Der Mann hat Zeit als Rentner...
Christian J. schrieb: > Ketzerische Frage: Die oder lieber deine bauen? :- Da bin ich relativ schmerzfrei. Wie du magst :-)
Christian J. schrieb: > Ketzerische Frage: Die oder lieber deine bauen? :-) Die kommt mit PIC32 > daher für den ich einen Programmer habe. Also so'n Teil an Retro hängen lohnt doch irgendwie nicht. Da kannst du auch gleich einen RasPi dranhängen.
Christian J. schrieb: > Aber da hat allein der A.K. > schuld :-) Mit seinem MK3801 tip, dem Stromfresser mit den 8 Bit > Krücken-Timern. *stichel* Nachdem du den eigentlich sinnvollen SIO aufgrund schier übermenschlicher Komplexität abgelehnt hattest. ;-)
A. K. schrieb: > Also so'n Teil an Retro hängen lohnt doch irgendwie nicht. Da kannst du > auch gleich einen RasPi dranhängen. Meinste? Also meinen kleinen Himbeer Freund hier mit Tesa Krepp hinter den 14z Uralt Flachbildschirm pappen, das teure HDMI/DMI Konverter Kabel dafür verbreezen, einen 1 Euro FTDI RS 232 Konverter mit Heisskleber anpappen und dann die Himbeere so einstellen, dass die ein Terminal Programm im Autostart hochfährt? Ok, so ein 8 Euro Minikeyboard habe ich auch noch, mit Mäuseklaviertasten. Echt Retro.... ;-( Stimmt, die SIO ist echt Hammer, ohne Diplom im E-Technik kaum zu durchschauen. Da komme ich mit dem STM32F429 besser zurecht, der ist wirklich einfach dagegen.....
Jens schrieb: > S. R. schrieb: >> - /INT und /SEL (Chip-Select) werden zentral dekodiert >> und jeweils als eigene Leitung auf "ihren" Slot geführt. > Ich würde dezentral dekodieren. Das schränk man sich nicht gleich von > vornherein ein. Damit braucht man aber mindestens zwei zusätzliche ICs pro Hardware, und muss dann auch noch widerspruchsfreie Basisadressen konfigurieren können. Das war mir zu viel Aufwand. :-) 7 freie Bus-Steckplätze empfand ich als ausreichend, und wenn man will, kann man ja einen SPI- oder I2C-Bus zusätzlich anschließen. Oder man ersetzt zwei ICs ('138, '148) durch ihre 4-Bit-Pendants für 15 freie Steckplätze. Ich werde aber A8..A15 noch umbenennen. Auf dem Bus sind das ja keine Adressleitungen mehr, sondern zusätzliche, unidirektionale Datenleitungen. ;-) > Außerdem würde ich /NMI, /HALT und vor allem /IORQ mit auf die Leiste > setzen. Sonst kann auf den Slaves nur Speicher bzw. memory-mapped-IO > eingesetzt werden. /NMI ist ein Argument, wobei ich nicht weiß, wozu beliebige Hardware den auslösen können sollte. Bisher war der für die MMU reserviert (Zugriff auf nicht existenten Speicher), aber das funktioniert wohl nicht wie gedacht. /IORQ ohne /M1 ist fahrlässig (wegen Interrupt-Acknowledge-Zyklus), daher habe ich beide zusammen mit der Adressdekodierung in /SEL verwurstet. Wenn /SEL fällt, weiß die Hardware, dass sie für einen I/O-Zyklus angesprochen wurde. /HALT wird bei mir durch /WAIT bereitgestellt, was man auch präventiv ziehen kann. Beim nächsten I/O-Zyklus wartet der Z80 dann. Das hat den Vorteil, dass ein popeliger AVR dann auch mit einer ISR auf /SEL schnell genug reagieren kann. Der Vorteil bei mir ist, dass ich normale 36-Pin-Leisten nutzen kann. Die passen auf die kurze Seite meiner Lochrasterplatinen. ;-)
Hi, ich habe mir deinen Thread durchgelesen wo Du CP/M auf einem Board mit AVR und Slots zum Laufen kriegst. Diese AVR Geschichte wollte ich vermeiden, erstens " kann ich kein AVR" außer Arduino und habe keine Umgebung dafür, wohl aber eine für PICs und so einen Hilfsmotor wollte ich nicht auf dem Z80 Board haben. Über CPM gibt es tausend Seiten, alles scheinbar ganz easy - nur hat ein Grant Searle dafür 2 Jahre gebraucht und tausend Anpassungen. Ich wüsste derzeit nur nicht wie ich anfangen soll das in die Kiste zu kriegen. Mit Asm herumschlagen in dem CPM Source Code möchte ich nicht, eher ein Binary einladen und das läuft dann auch auf meiner Hardware. Gibt es denn ein gutes Beispiel für eine CPM kompatible Hardware, wo auch ein Massenspeicher angeschlossen ist? Ich habe weder Monitor, noch Floppy, noch Tastatur, müsste also rein über ein Terminal laufen. Ich bin drauf und dran das hier auf PLatine sauber nachzubauen, denn wie er es beschrieben hat, hat er jedes einzelnen CPM File anfassen müssen. http://searle.hostei.com/grant/cpm/index.html
Moin, ich frage mich grad wo der Unterschied zwischen einem 128k SRAM und einem 128k NVRAM liegt? Außer dass der eine das Format Sarg hat und der andere ein DIP 28 ist. Mit dem RAM läuft er, mit dem NVRAM startet er nicht mal. Pinning ist identisch. NVRAM im Top853 Tester lässt sich einwandfrei beschreiben, verifyen und auslesen. Daten werden auch gehalten. NVRAM ist also ok. Sieht der Z80 aber leider anders... Hatte eiegentlich vor auch das EPROM durch ein NVRAM zu ersetzen. Seltsam....
Schau doch ins Datenblatt. Da wird irgendein Timing nicht passen.
> Schau doch ins Datenblatt. Zu gefährlich. > Da wird irgendein Timing nicht passen. In dem Fall nicht.
Christian J. schrieb: > ich habe mir deinen Thread durchgelesen wo Du CP/M auf einem Board mit > AVR und Slots zum Laufen kriegst. Diese AVR Geschichte wollte ich > vermeiden, [...] Magst du mir bitte verraten, was ein AVR auf einer Platine mit dem Pinout des Bussystems zu tun hat? Irgendwie kann ich deinen Gedankengang nicht nachvollziehen. Mir geht es nicht darum, mein System nachzubauen. Ich habe dir eine aus meiner Sicht einfache Lösung gezeigt, wie du ein Businterface an dein System stricken kannst. Das "wegen Wettervorhersage" zu verwerfen, ist irgendwie uncool. Naja.
Frank K. schrieb: > Schau doch ins Datenblatt. Da wird irgendein Timing nicht passen. Bei so rund 30 "Timing Werten", die alle weit unterhalb des Kolbentaktes des Z80 liegen und ohne Logic Analyzer besserer Art schwierig. Es hat 2-3 Mal geklappt und dann nicht mehr. Da Kompatibilität im Datenblatt zu allen gängingen EPROMs und SRAMs (ASC6C1008) gewährleistet wird schon seltsam. Pins stehen allerdings senkrecht und nicht so wie bei einem normalen IC v-förmig. Kontaktproblem? Da die Dinger recht teuer sind (16 Euro) werde ich aber keinen zweiten mehr bestellen, um das auszuprobieren.
S. R. schrieb: > Magst du mir bitte verraten, was ein AVR auf einer Platine mit dem > Pinout des Bussystems zu tun hat? Irgendwie kann ich deinen Gedankengang > nicht nachvollziehen. Mir geht es nicht darum, mein System nachzubauen. Aneiander vorbei geredet. Ich habe deinen Busvorschlag bereits soweit umgesetzt. Mit der CPM Geschichte hat das aber nichts zu tun, das ist eine andere Baustelle.
> Da Kompatibilität im Datenblatt zu > allen gängingen EPROMs und SRAMs (ASC6C1008) Der Typ Deines NVRAMs ist aber weiter geheim? Der erst beste Typ, den ich mir gestern angeschaut hatte, hatte z.B. nicht die exakt gleiche Pinbelegung wie Dein RAM. Schau doch nochmal genauer hin.
Angehängte Dateien:
M48Z128 http://www.st.com/web/en/resource/technical/document/datasheet/CD00000526.pdf CE2 ist NC aber das sehe ich schmerzfrei....
> CE2 ist NC aber das sehe ich schmerzfrei....
Dann schau doch nochmal in Deinen Schaltplan.
Angehängte Dateien:
Leo C. schrieb: > Dann schau doch nochmal in Deinen Schaltplan. Yep !!! Vor lauter Bäumen keinen Wald? ich nutze ja CS2 als Chip Select und lege /CS# auf Masse :-( Musste ich ja für den Switch zwischen ROM/RAM. Also einen freien Inverter irgendwo anzapfen und das umverdrahten. Zumindest wenn der Delay durch den Inverter mir nicht andere Probs verursacht aber das sind nur 10ns. Das Nette am NVRAM ist ja, dass amn gewisse Daten wie ROM Prüfsumme bzw die des geladenen Programmes, Anzahl Starts, Betriebsdauer dauerhaft in einer unbenutzten Ecke ablegen kann. Der Stackpointer wird sicher nichts dagegen haben, wenn ich den auf 0xFFDF lege und die 16 Bytes drüber als geschützten Datenbereich verwende. Die Kiste hat im Dauerbetrieb 1 Woche bisher keine gekippten Bits gezeigt aber man weiss ja nie.
Angehängte Dateien:
@Leo C. Ist zwar schon 'früh" aber "Tschibo Wild & Stark" macht es möglich um die Zeit noch zu programmieren. Die Umfrickelei der CS war erfolgreich, ein NVRAM sitzt im RAM Sockel und im EPROM Sockel ein DS1643 8k Timekeeper RAM. Die Kiste hat somit auch eine Uhr, die mitläuft. Ok, nicht mehr sooo ganz Retro-Style aber der Fortschritt der Technik macht auch auf dem Basteltisch nicht halt. Nett, dass das OS jetzt durch einen Loader aktualisiert werden kann, der sich selbst einfach nach oben kopiert und von dort aus Intel Hex einlaedt. Funktionen sind ja mit func_START und func_END als .globl gut erreichbar. Als Spezi für den SDCC weisst Du vielleicht auch, wie man ein zweites Datensegment anlegt? Denn das "EPROM" hat ungenutzten Speicher, der für Variablen genutzt werden könnte. Es gibt ja jede Menge Segmente wie HEADER1...10 usw. Könnte man Variablen durch einen Namens-Vorsatz, zu welchem Segment die gehören also in einen gesonderten Bereich packen?m Sowas wie idata und xdata beim MCS51? Aktuell kann ich das nur durch Tricksen mit #define RAM_SPECIAL 0x3400 __at RAM_SPECIAL struct system_type sys; Und alle Vars müssen im struct liegen. Nur suboptimal wie ich finde. Da der Speicher jetzt durchgehend aus 64k RAM besteht müsste CP/M jetzt auch möglich sein. Sperre ich mich aus, kann ich das NVRAM im Brenner ja neu "flashen".
@ LEEEEEEOOOOOOOOOOOOOOOOOOOOOOOOO !!!!!! wink *bruell* Hast Du irgendeine Idee, wie man dem SDCC klarmachen könnte dass eine Funktion nicht im aktuellen Code ist sondern eine fixe Adresse irgendwo hat? extern __at 0x2000 void myfunc(int,int); Damit müsste dem Compiler doch klar werden, wie der Stackframe beladen wird und wo er dann hinspringen soll bei myfunc(5,6); Klappt nur leider nicht, erzeugt einen Linker Fehler. Wäre ihm nicht bekannt. Geht nur mit Variablen derzeit. Zweck: Nutzung der ROM Routinen für RAM Programm damit Einsparung von viel Platz, da derzeit fast alles doppelt vorhanden ist.
Christian J. schrieb: > Hast Du irgendeine Idee, wie man dem SDCC klarmachen könnte dass eine > Funktion nicht im aktuellen Code ist sondern eine fixe Adresse irgendwo > hat? > > extern __at 0x2000 void myfunc(int,int); Bin zwar nicht Leo, aber gerüchteweise soll C so etwas wie Zeiger auf Funktionen kennen. Ich würde es mal damit versuchen... Grüßle, Volker.
Volker Bosch schrieb: > Bin zwar nicht Leo, aber gerüchteweise soll C so etwas wie Zeiger auf > Funktionen kennen. Ich würde es mal damit versuchen.. Ja.... aber nur auf Funktionen, die sich innerhalb der zum Projekt gehörigen Sourcen befinden. Ich weiss nur, dass "InitHardware" bei 0x7A3 liegt und ich es gern hätte, dass er eine virtuelle Funktion da drauf abildet, ohne dass die wirklich da ist. long hoch2(int n) { return n * n; } int main() { long (*rechne) (int); int zahl = 3; rechne = hoch2; int ergebnis = rechne(zahl); Das klappt. Aber wenn hoch2 außerhalb liegt und nur durch seine Adresse bekannt ist? typedef int (*IntFunc1) (void); typedef int (*IntFunc2) (int); kenne ich auch. IntFunc1 ist dann ein Zeiger auf Funktionen, die nichts zurückliefern. Der Compiler muss ja wissen wie er den Stackframe zusammen bauen muss. Das geht sicher irgendwie.....
Christian J. schrieb: >> Bin zwar nicht Leo, aber gerüchteweise soll C so etwas wie Zeiger auf >> Funktionen kennen. Ich würde es mal damit versuchen.. > > Ja.... aber nur auf Funktionen, die sich innerhalb der zum Projekt > gehörigen Sourcen befinden. Ich weiss nur, dass "InitHardware" bei > 0x7A3 liegt und ich es gern hätte, dass er eine virtuelle Funktion da > drauf abildet, ohne dass die wirklich da ist. Das kann ich mir jetzt nicht vorstellen. Um ein Hardware-Register aus C heraus anzusprechen, kann ich einen Zeiger auf dieses Register richten und dieses über ihn lesen und beschreiben. Warum sollte ich nicht auch einen Funktionszeiger anspringen können, den ich ins ROM zeigen lasse. Ohne es jetzt explizit ausprobiert zu haben, würde ich das ungefähr so machen: typedef int (*IntFunc2) (int); int main(void) { IntFunc2 RomFunction; int Val; RomFunction = (IntFunc2)0x1234; Val = (*RomFunction)(17); ... Oder noch kürzer und die Adress-Konstante direkt in den Funktionspointer casten. Zumindest auf dem 68k mit seinem linearen Adressraum sollte das funktionieren. Grüßle, Volker.
:
Bearbeitet durch User
Volker Bosch schrieb: > Ohne es jetzt explizit ausprobiert zu haben, schade > würde ich das ungefähr so machen:
1 | typedef int (*IntFunc2) (int); |
2 | |
3 | int main(void) { |
4 | IntFunc2 RomFunction; |
5 | int Val; |
6 | |
7 | RomFunction = (IntFunc2)0x1234; |
8 | Val = (*RomFunction)(17); |
9 | |
10 | return Val; |
11 | }
|
ergibt:
1 | leo@cb:/tmp$ sdcc -mz80 -S intfunc.c |
2 | Internal error: validateOpType failed in OP_SYMBOL(IC_LEFT (ic)) @ gen.c:4286: expected symbol, got value |
Leider ein Compiler-Bug.
Vorschlag: Linker-Option '-g' nutzen:
1 | 13. -g symbol=expression |
2 | (one definition per line in a linker command file.) |
3 | This specifies the value for the symbol where the ex- |
4 | pression may contain constants and/or defined symbols |
5 | from the linked files. |
c-code:
1 | extern long hoch_rom(int n); |
2 | int main() |
3 | {
|
4 | int ergebnis; |
5 | |
6 | ergebnis = hoch_rom(3); |
7 | return ergebnis; |
8 | }
|
Irgendwo im Makefile:
1 | ld_globals = -g _hoch_rom=0x1234 |
Und das link recipe erweitern:
1 | $(TARGET).ihx: $(CRT0) $(OBJS) |
2 | $(Q)$(LD) $(LDFLAGS) -i $@ \ |
3 | $(ld_segs) \ |
4 | $(ld_globals) \ |
5 | $(patsubst %,-k %,$(LIBDIRS)) \ |
6 | $(patsubst %,-l %,$(LDLIBS)) \ |
7 | $^ |
Die Adressen der ROM-Funktionen könnte man per Script aus dem Mapfile des ROM-Programms ziehen.
Volker Bosch schrieb: > Das kann ich mir jetzt nicht vorstellen. Um ein Hardware-Register aus C > heraus anzusprechen, kann ich einen Zeiger auf dieses Register richten > und dieses über ihn lesen und beschreiben. In Asm eigentlich kein Thema. Man kann das auch so machen wie beim guten alten DOS mit seinem Int21h, wo man viele Funktionen über ein Soft-Int aufrief oder die im Bios Bios mit Int 13h. Ging allerdings nur von Assembler aus damals meine ich. Wenn das ginge würde ich es aber komfortabel wollen, d.h. eine Liste aller Functionen im ROM, wo sie alle Namen kriegen und eine Adresse und dann nur noch aufrufen. Sonst braucht man zuviel Code für die Umwege. Mit Variablen und Registern alles ganz easy, hat jeder Mikro so eine -h Datei wo all seine register definiert werden aber mit Funktionen... tja..
Leo C. schrieb: > Irgendwo im Makefile:ld_globals = -g _hoch_rom=0x1234 Sieht kompliziert aus ... vor allem wenn man das ROM einmal ändert muss man alles neu machen. extern __at 0x1234 void func(int) erzeugt nämlich einen Linker Fehler, dass er das .globl _func nicht kennt und dem begegnet man ja mit der Defintion wie von Leo beschrieben.
Wobei ich erwähnen muss, dass das was ich möchte absolut nicht dem entspricht wie es damals wirklich gemacht wurde .... ausser dem DOS Int und Bios Int fällt mir nichts ein, wo ein User Pogramm sich der Routinen aus dem Monitor bediente.
> Sieht kompliziert aus ... Ich käme nie auf die Idee, Dir etwas kompliziertes vorzuschlagen. Ich verstehe auch nicht, was an der Zeile kompliziert sein soll. > vor allem wenn man das ROM einmal ändert muss > man alles neu machen. Das macht make natürlich vollautomatisch. Das Rezept dazu habe ich oben auch schon haarklein aufgeschrieben. Nur das Script, das die Adressen aus dem Mapfile holt, habe ich Dir als Übung überlassen.
Angehängte Dateien:
-
DSC08239__1280_x_1024_.jpg
210 KB
Leo C. schrieb: > Das macht make natürlich vollautomatisch. Das Rezept dazu habe ich oben > auch schon haarklein aufgeschrieben. Nur das Script, das die Adressen > aus dem Mapfile holt, habe ich Dir als Übung überlassen. Du weisst dass ich Null Ahnung von Makefiles habe (was ich gedenke aber noch zu ändern...) und ganz sicher eine Woche brauche, um aus einem Text irgendwelche Teile heraus zu schneiden, die dann anderswo nachj irgendwelchen Regeln, die ich nicht kenne wieder eingesetzt würden. Wenn das nicht standardmässig geht lasse ich es bevor ich da anfange zu "frickeln" und damit in zig neue Probleme reinrenne, die ich vorher nicht hatte. Das Projekt für meine kleine Chip-Fabrik ist mit ca 18 .c Files inzwischen zu gross. Schade, hätte ja sein können dass es direkt gegangen wäre. ld_globals = -g _hoch_rom=0x1234 Und wenn es mehr werden? ld_globals = -g _func1=0x1234 _func2=0x4567 ... Warum kann ich die Globals nicht im crt0.s File definieren? Das geht ja mit den Interrupt Funktionen auch, die dort bekannt gemacht werden und meine Vektortabelle bilden. Er setzt brav die Adressen der ISR dann dort ein, die beim Linken ermittelt wurden. ; Interruptroutinen für den Mostek MK3801 Multi I/O Baustein ; Manual STI Baustein MK3801 Figure 7 .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 und ;/////////////////////////////////////////////////////////// ; Tabelle der Mode 2 Int Vektoren auf die Handler Funktionen im C Modul ; Reihenfolge beachten !!! Siehe Manual Mostek 3801, Interrupt Tabelle .org adr_vec_table .dw (_int_sti_gpi_0) <=== hier kommt 0936 rein, s.u. .dw (_int_sti_gpi_1) .dw (_int_sti_gpi_2) .dw (_int_sti_gpi_3) .dw (_int_sti_timer_d) und aus dem int.c File mit gleichen Namen der Funktionen: 10 ; Public variables in this module 11 ;------------------------------------ 12 .globl _int_sti_receive_error 13 .globl _int_sti_transmit_error 14 .globl _int_sti_gpi_7 15 .globl _int_sti_gpi_6 16 .globl _int_sti_gpi_5 17 .globl _int_sti_gpi_4 18 .globl _int_sti_gpi_3 19 .globl _int_sti_gpi_2 20 .globl _int_sti_gpi_1 21 .globl _int_sti_timer_d 22 .globl _int_sti_timer_c 23 .globl _int_sti_timer_b 24 .globl _int_sti_gpi_0 25 .globl _int_sti_timer_a 27 .globl _int_sti_receive_buffer_full 28 .globl _nmi_vint 230 ; --------------------------------- 231 ; Function int_sti_gpi_0 232 ; --------------------------------- 0936 233 _int_sti_gpi_0_start:: 0936 234 _int_sti_gpi_0: 235 ;interrupt.c:111: EI_RETI; 0936 FB [ 4] 236 ei 0937 ED 4D [14] 237 reti 0939 238 _int_sti_gpi_0_end:: So ähnlich wäre das schon toll....
Heute Mittag habe ich mal was gebastelt. Das angehängte Makefile geht davon aus, daß Dein ROM- und Dein RAM-Programm 2 verschiedene Projekte im jeweils eigenen Verzeichnis sind. Es gibt es 2 neue Variablen.
1 | ROM_MAPFILE := ../rom/build/rom.map |
2 | ROM_FUNCS := _hoch_rom _nocheine_rom |
Im ROM-Projekt läßt Du ROM_MAPFILE einfach leer oder auskommentiert. Im RAM-Projekt gibst Du den Pfad (relativ oder absolut) des ROM-Mafiles an, und in der ROM_FUNCS-Zeile alle Funktionen, die im ROM-Projekt referenziert werden sollen.
Leo C. schrieb: > Heute Mittag habe ich mal was gebastelt. Cool! Danke! Wird morgen ausprobiert.... >> ROM_FUNCS := _hoch_rom _nocheine_rom Was kommt da genau hin? Beispiel? Wie man das lernen soll weiss ich echt nicht....
1 | ifneq ($(strip $(ROM_MAPFILE)),) |
2 | ld_globals = $(shell awk -v GLOBALS="$(ROM_FUNCS)" \ |
3 | 'BEGIN {$$0=GLOBALS; for (i = 1; i <= NF; i++) g_values[$$i] = ""} \
|
4 | END {for (x in g_values) if (g_values[x] != "")print "-g " x "=" g_values[x];}\
|
5 | { if ($$2 in g_values) g_values[$$2] = "0x"substr($$1, length($$1)-4+1)}\
|
6 | '\ |
7 | $(ROM_MAPFILE)) |
8 | endif |
> Was kommt da genau hin? Beispiel?
Die Namen der Funktionen, die im ROM liegen und auf die vom RAM-Programm
aus zugegriffen werden soll.
Also von void wasch_mein_auto(int politur, int wachs, int felgen); würde wasch_mein_auto eingetragen.
_wasch_mein_auto Nachtrag: ja, den führenden Unterstrich könnte man auch automatisch zufügen. Habe ich aus didaktischen Gründen weggelassen.
:
Bearbeitet durch User
Christian J. schrieb: > Wie man das lernen soll weiss ich echt nicht.... Den END-Block braucht man eigentlich nicht. Deshalb gehts auch noch eine Zeile kürzer:
1 | ifneq ($(strip $(ROM_MAPFILE)),) |
2 | ld_globals = $(shell awk -v GLOBALS="$(ROM_FUNCS)" \ |
3 | 'BEGIN {$$0=GLOBALS; for (i = 1; i <= NF; i++) g_symbols[$$i] = ""} \
|
4 | {if ($$2 in g_symbols) print "-g " $$2 "=0x" substr($$1,length($$1) - 4+1)} \
|
5 | '\ |
6 | $(ROM_MAPFILE)) |
7 | endif |
Da ist überhaupt nichts kompliziertes oder trickreiches dran. Lernen kann man daß, in dem man den kompakten Zeichenklotz systematisch in seine Einzelteile zerlegt, und dann das Handbuch zu Hilfe nimmt. [1,2] Dieser Teil ist Makefile-Syntax:
1 | ifneq ($(strip $(ROM_MAPFILE)),) |
2 | ld_globals = $(shell ... |
3 | ) |
4 | endif |
ifneq vergleicht die beiden (epandierten) Texte vor und hinter dem Komma. Innerhalb der ifneq-Klammer wird ggf. awk mit 3 Argumenten ausgeführt. 1. die awk-Variable 'GLOBALS' bekommt schon mal einen Wert zugewiesen. (-v...) 2. Das awk-Script/Programm, das ausgeführt werden soll. (Zwischen den '') 3. Die Datei, die awk lesen und filtern soll. ($(ROM_MAPFILE)) Wenn man awk mit Parameter -o aufruft, bekommt man eine "schön gedruckte" Ausgabe des Scripts:
1 | # gawk-Profil, erzeugt Tue Feb 10 13:07:36 2015 |
2 | |
3 | # BEGIN Blöcke |
4 | |
5 | BEGIN {
|
6 | $0 = GLOBALS |
7 | for (i = 1; i <= NF; i++) {
|
8 | g_symbols[$i] = "" |
9 | } |
10 | } |
11 | |
12 | # Regeln(s) |
13 | |
14 | {
|
15 | if ($2 in g_symbols) {
|
16 | print "-g " $2 "=0x" substr($1, length($1) - 4 + 1) |
17 | } |
18 | } |
Der BEGIN-Block zerlegt den übergebenen String in seine Einzelteile (also die zu suchenden Symbole), und legt ein (assoziatives) Array an, dessen Index aus den Symbolen besteht. Dies deshalb, weil man damit sehr bequem mit dem in-Operator suchen kann. Was unter Regeln steht, wird dann auf jede Zeile des Mapfiles angewendet. Wenn also auf 2. Position einer Zeile eines der von uns gesuchten Symbole steht, wird es (passend formatiert) zusammen mit der ersten Position, also dem Wert/der Adresse des Symbols, ausgegeben. [1] http://www.gnu.org/software/make/manual/make.html#index-ifneq [2] http://www.gnu.org/software/gawk/manual/gawk.html
Wieder was dazugelernt aber das ist (derzeit) noch zu kompliziert für
jemanden, der wenig Script Erfahrung hat und der vor allem keine
Anwendungen dafür hat, weil ich jobtechnisch woanders unterwegs bin,
nämlich im Bereich "Maschinenrichtlinie", Functional Safety und der
Zulassung von Maschinen und Systemen.
Was aber scheinbar funktioniert ist:
void(* resetFunc) (void) = 0x1234;
Also ein Sprung nach 0x1234 ohne Parameter.
ergibt:
.area _INITIALIZED
A97B 88 _resetFunc::
A97B 89 .ds 2
und
400 ;main.c:146: resetFunc();
44ED 2A 7B A9 [16] 401 ld hl,(_resetFunc)
44F0 CD E1 7E [17] 402 call __sdcc_call_hl
und
857B 453 __xinit__resetFunc:
857B 34 12 454 .dw #0x1234
455 .area _CABS (ABS)
-----
Das klappt auch:
void(* resetFunc) (int) = 0x1234;
und Aufruf
resetFunc(15);
ergibt:
44EC F3 [ 4] 399 di
400 ;main.c:146: resetFunc(15);
44ED 21 0F 00 [10] 401 ld hl,#0x000F
44F0 E5 [11] 402 push hl
44F1 2A 80 A9 [16] 403 ld hl,(_resetFunc)
44F4 CD E6 7E [17] 404 call __sdcc_call_hl
Und das auch:
int (* resetFunc) (int) = 0x1234;
mit
res = resetFunc(15);
400 ;main.c:146: res = resetFunc(15);
44ED 21 0F 00 [10] 401 ld hl,#0x000F
44F0 E5 [11] 402 push hl
44F1 2A 80 A9 [16] 403 ld hl,(_resetFunc)
44F4 CD E6 7E [17] 404 call __sdcc_call_hl
44F7 F1 [10] 405 pop af
Heute keine Zeit mehr aber sieht so aus als ginge das auch ohne
Umwege,....
@Leo: Leider war deine Arbeit umsonst :-( Es funktioniert auf die von mir gezeigte Weise aber nur bei Trivial Funktionen wie dem Setzen von LEDs und schon gar nicht bei Textausgabe usw. Ist auch klar, denn das Environment des Monitors ist ja nicht mehr da, wenn das Userprogramm läuft. Es laufen keine Ints, die ISR Routinen liegen woanders. Und das Data Segment muss so liegen, dass sich Userprog und Monitor nicht in die Quere kommen. Das klappt nur dann, wenn das Userprogramm kein Startup hat der die Int Vektoren ummodelt, keine Ints ändert usw. also rein als Call Aufruf läuft und konsequent nur die Subs des Monitors nutzt. Trotzdem interessant dass es auf die oben gezeigte Weise grundsätzlich geht.
Christian J. schrieb: > Das klappt nur dann, wenn das Userprogramm kein Startup hat der die Int > Vektoren ummodelt, keine Ints ändert usw. also rein als Call Aufruf > läuft und konsequent nur die Subs des Monitors nutzt. Was hattest Du denn erwartet? Natürlich musst Du die an die Konventionen des Monitors halten. Wenn der sich um Interrupts kümmert, dann darf man da nicht reinpfuschen. Jens
Was bei einem echten Computer noch sinn macht aber nicht bei einem kleinen Steuerrechner, wo man die Hardware ja braucht. wenn ich mal spass dran habe werde ich das umcodieren. ist ja platzverschwendung alle ncurses routinen doppelt zu haben. bei dos früher musste man ja auch ints wie 21h und 13h, wenn man sie umbog wieder zurück auf ihr eigentliches ziel leiten, sonst crashte er.
Hallo. Nimm doch einfach einen SEL Z80 Lehrcomputer. Da geht alles mit. Sogar Terminalfunktionalitat inkl. Assembler. Einfacher geht es nicht. http://petersieg.bplaced.net/?SEL_Z80_Trainer
>Aber die PIC's (vor allem die kleinen) sind eben gar nicht so doof, >sondern es haben davon einige genau diese Ports, mit denen man sie als >periphere IC's in größere Systeme einbinden kann. Im Prinzip sind das >alle, die einen PortD (für 8 Bit Daten I/O) und PortE (für die >Steuersignale) haben, PIC16F87x wenn ich mich recht erinnere. Damit >können diese Teile direkt an einen Systembus angeschlossen werden. und dieser PSP für tatsächlich "ein ganzes Byte" >Versuche mal sowas bei anderen µC zu finden. Für mehrere Bytes (>4) wohl nur über PLD oder mit MCU mit extBusInterface (über INT).
Ingo schrieb: > Hallo. Nimm doch einfach einen SEL Z80 Lehrcomputer. Da geht alles mit. Da jemand den Thread wieder ausgegraben hat... was soll ich mit so'ner Uralt-Sch...e? Programme auf Programmiertabelle schreiben? Handumrechnung der Mnemocnics und eintippen der Hex Zahlen? So habe ich 1984 angefangen, das Ding liegt sogar noch hier verstaubt, der "KEIL 8085 Lerncomputer" (ja, die KEIL's). Ich würde eher sagen "Da geht nix mit!". Zumindest nicht mehr als Blinki-LED und ein paar trivialste Anwendungen zum Verständnis der Funktionsweise einer CPU.
Holm T. schrieb: > Guck mal hier: > > http://www.tiffe.de/Robotron/Motorola/fbug > > das ist ein Arbeitsstand von vor 3 Monaten oder so :) > > Woher ich den habe? Keine Ahnung, früher mal ftp.funet.fi oder so... > Die Anpassung für die Vektorbasisregister-Geschichte und Trap Stackframe > für den 68010 habe ich da vor Jahren schon mal eingebaut, 68010 war zwar > vorgesehen aber noch nicht fertig. Danach ging mit dem gcc kein Coff > mehr > und ich habe nochmal umgebaut. am gcc/ld ist da sicherlich noch viel > Arbeit, aber der Kram funzt erst mal. > Den letzten Stand müßte ich aber auch erst hoch laden, üb den Stand auf > dem Server lief mal eine Problemdiskussion in diesem Forum, Abteilung > gcc.. > > Gruß, > > Holm Hallo Holm, ich habe deinen FBUG da ein wenig angeschaut. Ich möchte den gerne benutzen, doch weiss ich nicht so recht, was ich da alles brauche. Ist der Source, der da in dem Verzeichnis liegt, so lauffähig? was muss ich da alles beachten, wenn ich das auf meiner eigenen Hardware laufen lassen möchte? konkret habe ich eine Hardware mit MC68332. Einen DUART (68681) habe ich da nicht drauf, denn der '332 hat einen integrierten UART. Den möchte ich benutzen. Brauche ich noch was anderes, um den Monitor so benuzen zu können?
Ich würde Dir den Fbug für den 68332 nicht empfehlen, da wäre zu viel zu machen, angefangen von der anpassung des Codes für die Uart bis zum nicht passenden Stackframe bei Traps. Es gab aber IMHO einen CPU32bug von Motorola der als Binärblob ausgeliefert wurde, dazu ein Users Manual mit der Beschreibung der notwendigen Patches zur Anpassung an die Hardware. Ich habe das vor Jahrzehnten mal gemacht auch noch das User Manual auf totem Baum im Schrank. Ob ich den Monitor als Binrary noch habe weiß ich nicht, ich habe aber eine KatCe332 mit einem Erpom wo der drauf ist.. Suche erstmal ob Du das irgendwo zum Download noch bekommen kannst. Edit: ftp://gort.ludd.ltu.se/pub/misc/motorola/mcu332/ Die c32* Files enthalten den CPU32BUG, das Manual findest Du alleine.. Gruß, Holm
Da gibt's sogar noch was bei NXP (= ex Freescale (= ex MOTOROLA)): http://www.nxp.com/products/microcontrollers-and-processors/more-processors/coldfire-plus-coldfire-mcus-mpus/68kmpus-legacy/m683xx/32-bit-microcontroller:MC68332?fpsp=1&tab=Design_Tools_Tab
Hi Holm, danke dir für die Links. Habe da mal rein geguckt. Da sind zwar S-Records drin, aber den Source vom CPU32Bug scheint es wohl nirgends zu geben? das ist sehr schade. Ich weiss nicht wie man das zum Laufen kriegen soll, wenn man nur die compilierten S-Records hat. Aber danke trotzdem, ich werde mal ein wenig herum pröbeln.
Wie man das zum Laufen bekommt steht im Manual: http://www.ece.ualberta.ca/~cmpe401/docs/cpu32bug.pdf Quellen habe ich keine gefunden. Gruß, Holm
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.