Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins Willkommen Gast! RSS

Robotrontechnik-Forum » Technische Diskussionen » StackPointer in Programm verfolgen » Themenansicht

Autor Thread - Seiten: -1-
000
27.07.2009, 18:20 Uhr
Ralph



Hat jemand ne Idee wie ich in einem laufendem Z80-Programm verfolgen kann, wie sich wann der StackPointer SP der CPU verändert ?

Der Haken ist, dass 2x Interrupts jeweils versetzt alle 3ms bzw. 30ms kommen und noch ein weiterer von der Tastatur.. und jede Int-ServiceRoutine verändert den StackPointer.. Das will ich verfolgen und leider nützt mir hier mein Schrittbetrieb mit Hardwarehaltepunkt nichts, weil das Timing damit (durch den Wait am Haltepunkt) nicht mehr stimmt und damit das Programm nicht mehr funktioniert.

Gruß Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 27.07.2009 um 18:22 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
001
28.07.2009, 06:30 Uhr
karsten
Default Group and Edit
Avatar von karsten

@Ralph

Wenn sich dein SP sehr schnell verändert (3ms / 30ms) wie willst du da in Echtzeit was sehen?

Du könntes das Programm etwas umschreiben, und an verschiedenen Stellen in den Interrupt-Routinen den Stand des SP auf eine PIO (2x8 Bit) raus schreiben.
Nur musst du die Werte dann von dort auch wieder sehr schnell lesen und wegspeichern (mit anderem Rechner ?)

Oder ist auch nur ein Fehler in den Interrupt-Routinen und sie unterbrechen sich gegenseitig? Gibt es da ein DI am Anfang und ein EI am Ende?

Karsten
--
1. Grundgesetz der Messtechnik? Wer misst misst Mist!
(fast) alle DDR-Schaltkreise und viele Transistoren
Elektronikarchäologie, MC80, K1520

Dieser Beitrag wurde am 28.07.2009 um 07:08 Uhr von karsten editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
002
28.07.2009, 14:34 Uhr
Ralph



Naja das Problem ist, dass ich das zu untersuchende Programm nicht selbst geschrieben habe. Ich müsste erstmal den Code reasemblieren..

Bin ja auch noch ni auf ne vernünftige Idee gekommen, sonst hätte ich ja nicht hier gefragt! :-) Sonst hat keiner weiter ne Idee ??
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 28.07.2009 um 14:35 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
003
28.07.2009, 21:22 Uhr
tp



Was für ein Programm ist es denn? Und welches System? AC1?

Eventuell kann ja die Antwort auch lauten: Emulator nehmen.

Garantiert zwar den Erfolg auch nicht, aber vielleicht würde sich so ein Hinweis auf das Problem ergeben.
--
Die Zeit ist auch nicht mehr, was sie mal war! (Albert Einstein)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
004
28.07.2009, 21:28 Uhr
holm

Avatar von holm

Der Emulator müßte schon sehr gut sein, wenn er auch mehrere Interrupts emulieren kann.

Krümele Dich mal aus was Du machen willst Ralph und was zum Teufel Dir der Stackpointer-Stand dabei hilft.

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
005
28.07.2009, 22:22 Uhr
Ralph



@tp... EMU fäll aus, weil er (wie Holm richtig erkannt hat) keine Interrupts kann

@holm.. Ich habe hier 2 CP/M Programme RAMR.COM Rasmussen RamTest und CPUTEST.COM, die sich auf 3 versch. CP/M Bios für den AC1 unterschiedlich verhalten. Beide Programme verlegen den SP in den Bereich ab 0F0H bzw. unbekannt und beim korrekten beenden der Tools stürzt das CP/M immer ab.
Durch Zufall fand ich heraus, das das "verlegen" des SP in den Bereich >2000H (aber hinter dem Programm selbst) das Problem behebt. Naja und ich vermute das die Programme mit den vielen Int. nicht klarkommen bzw. sich die jedesmal veränderten SP das Problem sind. Da die versch. CP/M jedoch andere Programme vollkommen korrekt verarbeiten, hab ich eben die ISR's im Verdacht..und wollte das mal verfolgen.
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 28.07.2009 um 22:23 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
006
28.07.2009, 22:25 Uhr
tp




Zitat:
holm schrieb
Der Emulator müßte schon sehr gut sein, wenn er auch mehrere Interrupts emulieren kann.

Da sehe ich kein so großes Problem. Das ist z.B. auch für die Emulation der KC85/3 Tastatur nötig, da dabei sowohl CTC und PIO beteiligt sind. Ohne Daisy-Chain Behandlung funktioniert das nicht stabil.
--
Die Zeit ist auch nicht mehr, was sie mal war! (Albert Einstein)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
007
28.07.2009, 22:31 Uhr
Ralph



@tp... Hm.. Daisy chain war kein schlechtes Stichwort.. das hab ich noch nicht betrachtet..sehe aber an sich darin kein Problem.
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
008
28.07.2009, 22:33 Uhr
tp




Zitat:
Ralph schrieb
@tp... EMU fäll aus, weil er (wie Holm richtig erkannt hat) keine Interrupts kann

Was heißt das denn? Ich meinte keine In-Circuit-Emulatoren. Damit kenne ich mich überhaupt nicht aus. Ich meinte reine Software Emulation.
--
Die Zeit ist auch nicht mehr, was sie mal war! (Albert Einstein)
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
009
28.07.2009, 22:43 Uhr
Ralph



Na ich denke mal Du meinst KCEMU ?.. der kann das für den AC1 leider "noch" nicht.
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 28.07.2009 um 22:43 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
010
28.07.2009, 22:53 Uhr
tp




Zitat:
Ralph schrieb
Na ich denke mal Du meinst KCEMU ?.. der kann das für den AC1 leider "noch" nicht.

Da kenne ich mich natürlich am besten aus .

Die offizielle Version kann's noch nicht. Es gibt aber einen AC1-Entwicklungs-Zweig: Screenshot. Solange keine obskure Hardware vorkommt, ist sowas auch in ein oder zwei Stunden zusammengebaut.

Wobei ich mir aber auch recht sicher bin, dass der jkcemu von Jens den ganzen Interrupt-Krams richtig emuliert.
--
Die Zeit ist auch nicht mehr, was sie mal war! (Albert Einstein)

Dieser Beitrag wurde am 28.07.2009 um 22:54 Uhr von tp editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
011
29.07.2009, 17:55 Uhr
jmueller



Nun, da mein Emulator genannt wurde,
möchte ich mich auch mal zu Wort melden:

@Ralf:
Also ich denke, mit einem Emulator hast du wohl die besten Chancen,
das Problem zu finden, vorausgesetzt, du kannst es im Emu reproduzieren.

Zum Interrupt-System: JKCEMU emuliert es vollständig einschließlich Daisy Chain.
Bugs sind mir da erstmal keine bekannt. Das sollte also passen.

Ich denke, der JKCEMU-Debugger könnte dir gut helfen,
denn er kann auch die Befehlsabarbeitung aufzeichnen.
Der Emulator schreibt dabei vor jedem abzuarbeitenden Befehl
eine Zeile mit den ganzen CPU-Registern in eine Datei.
Die wird damit natürlich ganz schön groß, aber was solls.
Am besten, du setzt einen Breakpoint möglichst kurz vor
und möglichst kurz nach der problematischen Stelle,
und schaltest beim ersten Breakpoint die Befehlsaufzeichnung ein
und beim zweiten wieder aus.
Dann kannst du dir in Ruhe anschauen, was da alles passiert ist,
einschließlich dem Stackpointer.

Ich vermute aber ehrlich gesagt den Fehler im BIOS.
Das Licht ging mir bei dem Hinweis auf, dass es bei SP>2000h funktioniert.
Wenn der SP < 2000h ist, liegt er ja in dem RAM-Bereich,
der weggeschaltet wird, um z.B. eine Bildausgabe zu tätigen.
Damit das funktioniert, dürfte also das BIOS beim Einblenden
des Speichers der Grundplatine den Stack nicht mehr verwenden
bzw. müssten diesen temporär woanders hinlegen,
denn der liegt dann ja im ROM (00F0).
Außerdem dürfen in der Zeit auch keine Interrupts angetanzt kommen,
wenn der SP gerade mal auf den ROM zeigt.
Ich könnte mir vorstellen, dass hier das BIOS nicht alle Eventualitäten abfängt.
Suche dazu in der Programmaufzeichnungsdatei einfach mal nach OUT-Befehlen.
Ich glaube, da liegt der Schlüssel zu deinem Problem.

Jens
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
012
29.07.2009, 18:43 Uhr
Ralph



Hallo Jens... Zunächst mal Danke für Deine Meldung.. Ich gehe auch davon aus, das die Probleme im BIOS und nicht selbst bei den Programmen zu sehen sind, sonst wären ja die Programme nicht im Umlauf.
Leider kann ich dazu eben Deinen JKCEMU noch nicht verwenden, weil er ja das CP/M noch nicht kann :-( aber das wird ja auch mal..
Was die Umschaltung beim AC1 betrifft, so kann ich die sicher ausschließen, denn jedesmal wenn eine AC1 Monitorroutine verwendet wird, wird auch DI ausgelöst, bzw. die beiden anderen CP/M sind von Frank Nagel bzw. Jürgen Beisler und funktionieren dort wohl auch, allerdings weis ich nicht, ob die beiden jemals die beiden Problemprogramme getestet haben.
Evl. programmieren ja die Programme auch die CTC um ??

Das Problem mit dem SP tritt übrigens bereits ab 1000H nicht mehr auf...

Ich werd wohl oder über mal warten, bis der JKCEMU auch CP/M für den AC1 kann ! Jens ich werd Dir dazu mal noch eine ausführliche Mail schicken!

Grüße vom Ralph
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 29.07.2009 um 18:44 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
013
29.07.2009, 22:40 Uhr
jmueller



Hallo Ralf,

> Leider kann ich dazu eben Deinen JKCEMU noch nicht verwenden,
> weil er ja das CP/M noch nicht kann :-(

Nun, das stimmt so nicht ganz.
Richtig ist, dass JKCEMU noch kein Floppy-Disk-System emuliert.
Aber es emuliert zwei RAM-Floppies nach MP 3/88.
Und dafür gibt es auch CP/M.
Ich zumindest habe eine CP/M-Variante für eine 256K RAM-Floppy,
und die läuft auch im Emulator.
Damit könntest du es probieren.

> Ich werd wohl oder über mal warten, bis der JKCEMU auch CP/M für den AC1 kann !

Das setzt mich ja richtig unter Druck ;-)
Also, Floppy-Disk-Emulation ist in Planung und soll auch in der nächsten Version kommen.
Doch im Augenblick genieße ich noch das schöne Wetter
und lasse deshalb die Freizeitprogrammierung erstmal etwas ruhen.
Es wird also noch etwas dauern...

Jens
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
014
29.07.2009, 23:00 Uhr
Ralph



@jmueller... hab Dir grade ne Mail geschrieb und z.B. steht da...

Leider geht das CP/M noch nicht, weil Du zwar beim IO-Adr. 14H Bit2=H den
Bereich von 0-1FFF abschaltest, aber das wiedereinschalten mit IO-Adr.Bit2=L
klappt nicht und es ist offensichtlich auch kein RAM da, obwohl 00H ist zu finden...??!
Bitte beachte aber bei der ganzen Sache, dass der AC1 den RAM Bereich von
1000H (BWS)-1FFFH quasie 2x als RAM hat.. einmal als normaler AC1 RAM und
dann noch via 64K RAM welcher über Modul1 und MEMDI gesteuert wird.
CP/M wäre sehr wichtig... z.B. auch um das SP Problem zu lokalisieren...

Seh ich das falsch ? Mach ich was fasch ?
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
015
29.07.2009, 23:04 Uhr
Ralph



@jmueller... Wäre ja toll wenns gehen würde... aber ich hab grade nochmal getestet.. Ein einfaches Programm welches aus
Quellcode:
LD A,04H
OUT (14H),A
NOP
XOR A
OUT (14H),A
RET


kehrt nicht in den Monitor zurück! Sei mal so gut und schick mir bitte mal das CPM was bei Dir geht.

Gruß Ralph

Edit: Also ich habe grad mal ein CP/M getestet, was noch die FA eigene (und IO verschwenderische IO 1C..1FH) Umschaltung hat.. und das geht tatsächlich ! aber wir brauchen die andere Steuerung über Modul1 auch noch ! am besten konfigurierbar. DANKE!!
--
Es geht alles erst richtig los !

Dieser Beitrag wurde am 29.07.2009 um 23:18 Uhr von Ralph editiert.
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
016
29.07.2009, 23:55 Uhr
Ralph



@alle... Hab ja oben grad geschrieben das das CPM für den AC1 auf Basis der im FA veröffentlichten Schaltung schon im JKCEMU funzt!.. ja und da hab ich doch mal mein ZSDOS fix eben auf diee Umschaltung umgebaut..und siehe da ! es läuft.. :-)
So kann ich ja mal mein SP Problem am Pool analysieren *grns*..

Beste Grüße vom Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
017
01.08.2009, 20:38 Uhr
jmueller



@Ralf:
Hast du schon neue Erkenntnisse bzgl. deinem SP-Broblem?

@alle AC1-Kenner:
Ich habe inzwischen gelernt, dass das SCCH-Modul 1 (ROM-Modul)
ein Durchschreiben auf den 64K DRAM gestattet,
d.h., wenn ROM eingeblendet ist,ist der RAM trotzdem beschreibbar.
Obwohl schon beantwortet, möchte ich zur Sicherheit folgende Frage
explizit stellen:
Funktioniert das Durchschreiben auch für den Monitor-ROM auf der Grundplatine,
d.h., für ROM, der nicht durch das ROM-Modul bereitgestellt wird?

Jens
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
018
01.08.2009, 20:58 Uhr
Ralph



@jmueller... ja das Durchschreiben muss auch im Bereich des Monitor ROM' ABER NICHT im Bereich 1800..1FFFH funktionieren !

Was mein SP Problem betrifft, so hab ich das Problem noch nicht gefunden, fang aber grade an mit dem JKCEMU daran zu arbeiten und hoffe auf Erfolg.

Gruß Ralph
--
Es geht alles erst richtig los !
Seitenanfang Seitenende
Profil || Private Nachricht || Suche Zitatantwort || Editieren || Löschen
Seiten: -1-     [ Technische Diskussionen ]  



Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek