Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #284766 > unrolled thread

Hinweis zur Fehlersuche an alter Z80 Platine.

Back to article view | Back to de.sci.electronics

Contents

  Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-20 07:53 +0000
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Holger <me@privacy.org> - 2020-07-20 10:30 +0200
      Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-20 11:10 +0200
        Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-20 11:59 +0200
          Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-20 10:08 +0000
      Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-20 10:04 +0000
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2020-07-20 11:06 +0200
      Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-20 10:13 +0000
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Michael Bäuerle <michael.baeuerle@stz-e.de> - 2020-07-20 11:08 +0200
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Sebastian Wolf <invalid@invalid.net> - 2020-07-20 12:17 +0200
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Wolfgang Allinger" <all2001@spambog.com> - 2020-07-20 06:20 -0400
      Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Wolfgang Allinger" <all2001@spambog.com> - 2020-07-20 06:27 -0400
      Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-20 20:45 +0200
        Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-20 21:05 +0200
          Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-21 18:13 +0200
            Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-21 18:20 +0200
              Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-21 20:32 +0200
                Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-21 21:07 +0200
                  Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Wolfgang Allinger" <all2001@spambog.com> - 2020-07-21 16:58 -0400
                    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-22 07:09 +0200
                      Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-22 07:44 +0200
                        Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-22 09:57 +0200
                          Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-22 18:31 +0200
                            Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-22 19:06 +0200
                              Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-22 20:27 +0200
                                Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-22 20:49 +0200
                              Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerhard Hoffmann <ghf@hoffmann-hochfrequenz.de> - 2020-07-22 21:05 +0200
                      Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Wolfgang Allinger" <all2001@spambog.com> - 2020-07-22 07:23 -0400
                        Re: Hinweis zur Fehlersuche an alter Z80 Platine. Hans-Juergen Schneider <echo@hrz.tu-chemnitz.de> - 2020-07-22 18:33 +0200
                    Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-22 07:21 +0000
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Rafael Deliano <rafael_deliano@arcor.de> - 2020-07-20 19:17 +0200
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Marcel Mueller <news.5.maazl@spamgourmet.org> - 2020-07-21 22:11 +0200
      Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-22 07:26 +0000
    Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gernot Fink <g.fink@gmx.net> - 2020-07-22 21:46 +0200
      Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-27 07:21 +0000
        Re: Hinweis zur Fehlersuche an alter Z80 Platine. Sebastian Wolf <invalid@invalid.net> - 2020-07-27 09:27 +0200
        Re: Hinweis zur Fehlersuche an alter Z80 Platine. Gerrit Heitsch <gerrit@laosinh.s.bawue.de> - 2020-07-27 09:54 +0200
          Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-27 08:30 +0000
            Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Wolfgang Allinger" <all2001@spambog.com> - 2020-07-27 10:02 -0400
            Re: Hinweis zur Fehlersuche an alter Z80 Platine. Rafael Deliano <rafael_deliano@arcor.de> - 2020-07-27 17:57 +0200
        Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Wolfgang Allinger" <all2001@spambog.com> - 2020-07-27 03:57 -0400
          Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-27 08:35 +0000
            Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Wolfgang Allinger" <all2001@spambog.com> - 2020-07-27 09:40 -0400
              Re: Hinweis zur Fehlersuche an alter Z80 Platine. "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2020-07-27 14:38 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#284920

Gerrit Heitsch wrote:
> 
> On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
> >
> > On 21 Jul 20 at group /de/sci/electronics in article rf7edh$6tv$1@news.bawue.net
> > <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:
> >
> >> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
> >> sinnvolles und auch noch abhängig von der CPU.
> >
> > Bei 8080...Z80 ist das ein RST 7,
> >
> > Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
> >
> > Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
> > ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
> > gedonnert.
> 
> Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
> sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
> und dreht kleine Kreise.

Die CPU springt nicht, sondern ruft. Du musst auch an den Stack denken. 

> Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
> wäre ein realer Adresszähler.
> 
> Abgesehen davon passt das alles nur auf den Z80.

Mit Verlaub: Genau darum geht's hier. 

MfG
hjs

[toc] | [prev] | [next] | [standalone]

#284930

On 7/22/20 7:44 AM, Hans-Juergen Schneider wrote:
> Gerrit Heitsch wrote:
>>
>> On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
>>>
>>> On 21 Jul 20 at group /de/sci/electronics in article rf7edh$6tv$1@news.bawue.net
>>> <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:
>>>
>>>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
>>>> sinnvolles und auch noch abhängig von der CPU.
>>>
>>> Bei 8080...Z80 ist das ein RST 7,
>>>
>>> Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
>>>
>>> Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
>>> ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
>>> gedonnert.
>>
>> Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
>> sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
>> und dreht kleine Kreise.
> 
> Die CPU springt nicht, sondern ruft. Du musst auch an den Stack denken.

Die CPU ruft nicht, sie springt nach $0038, legt allerdings eine 
Rücksprungadresse auf den Stack. Es ergibt jedenfalls keinen sauberen 
Adresszähler wie ein NOP es tun würde.


>> Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
>> wäre ein realer Adresszähler.
>>
>> Abgesehen davon passt das alles nur auf den Z80.
> 
> Mit Verlaub: Genau darum geht's hier.

Die Originalaussage von Wolfgang war allerdings allgemeingültiger:

Normalerweise hängt so ein Bus ja sowieso an Pullups.

Und von dir kam ein:

Bei den Konsumgütern.

Als ich darauf hinwies, daß das nicht so ist. Ein Z80-Rechner läuft 
unter Kleinrechner und Konsumgut.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#284979

Gerrit Heitsch wrote:
> 
> On 7/22/20 7:44 AM, Hans-Juergen Schneider wrote:
> > Gerrit Heitsch wrote:
> >>
> >> On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
> >>>
> >>> On 21 Jul 20 at group /de/sci/electronics in article rf7edh$6tv$1@news.bawue.net
> >>> <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:
> >>>
> >>>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
> >>>> sinnvolles und auch noch abhängig von der CPU.
> >>>
> >>> Bei 8080...Z80 ist das ein RST 7,
> >>>
> >>> Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
> >>>
> >>> Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
> >>> ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
> >>> gedonnert.
> >>
> >> Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
> >> sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
> >> und dreht kleine Kreise.
> >
> > Die CPU springt nicht, sondern ruft. Du musst auch an den Stack denken.
> 
> Die CPU ruft nicht, sie springt nach $0038, legt allerdings eine
> Rücksprungadresse auf den Stack. Es ergibt jedenfalls keinen sauberen
> Adresszähler wie ein NOP es tun würde.

Ich hatte mich lediglich an die deutsche übersetzung von jump und call 
gehalten. Dort liegt der Unterschied. 
Der Adresszbus kommt alleine schon wegen Refresh durcheinander. da muss 
man den Oszi eben auf das entsprechende Steuersignal triggern. 

NOP ist ja nur zum Lesen gut. Und dafür hatte ich ja den Weg des
geringsten 
Aufwands, nämlich 7F vorgeschlagen. 

> >> Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
> >> wäre ein realer Adresszähler.
> >>
> >> Abgesehen davon passt das alles nur auf den Z80.
> >
> > Mit Verlaub: Genau darum geht's hier.
> 
> Die Originalaussage von Wolfgang war allerdings allgemeingültiger:
> 
> Normalerweise hängt so ein Bus ja sowieso an Pullups.

Ich hatte tatsächlich geglaubt, dass es trotzdem um den Z80 geht. 

> 
> Und von dir kam ein:
> 
> Bei den Konsumgütern.
> 
> Als ich darauf hinwies, daß das nicht so ist. Ein Z80-Rechner läuft
> unter Kleinrechner und Konsumgut.

Gerne auch mal z.B. als CNC-Steuerung oder Chiffriermaschine. 
Du musst wissen, dass die DDR ein ausgesprochenes Z80-Land war. Wir 
hatten ja sonst nichts. Jedenfalls hat man sich sogar die Mühe gemacht, 
kleine Fehler des Z80 zu korrigieren. Ich versteige mich mal in die 
Bahauptung, dass man sich nirgendwo intensiver mit diesem Teil 
beschäftigt hat. 

MfG
hjs


ps. Kleine Story am Rande: Wer sich damit beschäftigt hatte, der 
konnte mit Zettel und Stift assemblieren und fließend von FF bis 
80 rückwärts zählen. 
Bei einer nicht näher beszeichneten Erwachsenenbildung sollten wir 
hexadezimal Affe in dezimal umrechnen. Das sollte wohl witzig sein. 
Jedenfalls hatten alle erkannt, dass das ganz knapp an der B000 ist. 
Also haben wir 4096*11-2 gerechnet und der dumme Lehrer hat sich 
gewundert, wieso das so schnell ging.

[toc] | [prev] | [next] | [standalone]

#284982

On 7/22/20 6:31 PM, Hans-Juergen Schneider wrote:
> Gerrit Heitsch wrote:
>>
>> On 7/22/20 7:44 AM, Hans-Juergen Schneider wrote:
>>> Gerrit Heitsch wrote:
>>>>
>>>> On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
>>>>>
>>>>> On 21 Jul 20 at group /de/sci/electronics in article rf7edh$6tv$1@news.bawue.net
>>>>> <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:
>>>>>
>>>>>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
>>>>>> sinnvolles und auch noch abhängig von der CPU.
>>>>>
>>>>> Bei 8080...Z80 ist das ein RST 7,
>>>>>
>>>>> Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
>>>>>
>>>>> Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
>>>>> ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
>>>>> gedonnert.
>>>>
>>>> Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
>>>> sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
>>>> und dreht kleine Kreise.
>>>
>>> Die CPU springt nicht, sondern ruft. Du musst auch an den Stack denken.
>>
>> Die CPU ruft nicht, sie springt nach $0038, legt allerdings eine
>> Rücksprungadresse auf den Stack. Es ergibt jedenfalls keinen sauberen
>> Adresszähler wie ein NOP es tun würde.
> 
> Ich hatte mich lediglich an die deutsche übersetzung von jump und call
> gehalten. Dort liegt der Unterschied.
> Der Adresszbus kommt alleine schon wegen Refresh durcheinander. da muss
> man den Oszi eben auf das entsprechende Steuersignal triggern.
> 
> NOP ist ja nur zum Lesen gut. Und dafür hatte ich ja den Weg des
> geringsten
> Aufwands, nämlich 7F vorgeschlagen.
> 
>>>> Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
>>>> wäre ein realer Adresszähler.
>>>>
>>>> Abgesehen davon passt das alles nur auf den Z80.
>>>
>>> Mit Verlaub: Genau darum geht's hier.
>>
>> Die Originalaussage von Wolfgang war allerdings allgemeingültiger:
>>
>> Normalerweise hängt so ein Bus ja sowieso an Pullups.
> 
> Ich hatte tatsächlich geglaubt, dass es trotzdem um den Z80 geht.

Ich war noch einmal etwas suchen... Anscheinend waren Pullups am 
Datenbus beim Z80 üblich. Ich komme eher aus der 6502-Ecke und da waren 
sie nicht zu finden.

Hatte der Z80 Probleme Leitungen nach HIGH zu ziehen?


> ps. Kleine Story am Rande: Wer sich damit beschäftigt hatte, der
> konnte mit Zettel und Stift assemblieren und fließend von FF bis
> 80 rückwärts zählen.
> Bei einer nicht näher beszeichneten Erwachsenenbildung sollten wir
> hexadezimal Affe in dezimal umrechnen. Das sollte wohl witzig sein.
> Jedenfalls hatten alle erkannt, dass das ganz knapp an der B000 ist.
> Also haben wir 4096*11-2 gerechnet und der dumme Lehrer hat sich
> gewundert, wieso das so schnell ging.

Ich hab neulich einen meiner Taschenrechner aus der Zeit wiedergefunden. 
Ein Privileg Solar 100SR. Den hatte ich mir damals extra gekauft weil 
der auch HEX, OCT und BIN rechnen kann, und natürlich auch wandeln. 
Funktioniert immer noch.

Hatte Quelle nicht viel ihrer Eigenmarke in der DDR herstellen lassen?

  Gerrit

[toc] | [prev] | [next] | [standalone]

#284985

Gerrit Heitsch wrote:
> 
> On 7/22/20 6:31 PM, Hans-Juergen Schneider wrote:
> > Gerrit Heitsch wrote:
> >>
> >> On 7/22/20 7:44 AM, Hans-Juergen Schneider wrote:
> >>> Gerrit Heitsch wrote:
> >>>>
> >>>> On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
> >>>>>
> >>>>> On 21 Jul 20 at group /de/sci/electronics in article rf7edh$6tv$1@news.bawue.net
> >>>>> <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:
> >>>>>
> >>>>>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
> >>>>>> sinnvolles und auch noch abhängig von der CPU.
> >>>>>
> >>>>> Bei 8080...Z80 ist das ein RST 7,
> >>>>>
> >>>>> Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
> >>>>>
> >>>>> Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
> >>>>> ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
> >>>>> gedonnert.
> >>>>
> >>>> Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
> >>>> sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
> >>>> und dreht kleine Kreise.
> >>>
> >>> Die CPU springt nicht, sondern ruft. Du musst auch an den Stack denken.
> >>
> >> Die CPU ruft nicht, sie springt nach $0038, legt allerdings eine
> >> Rücksprungadresse auf den Stack. Es ergibt jedenfalls keinen sauberen
> >> Adresszähler wie ein NOP es tun würde.
> >
> > Ich hatte mich lediglich an die deutsche übersetzung von jump und call
> > gehalten. Dort liegt der Unterschied.
> > Der Adresszbus kommt alleine schon wegen Refresh durcheinander. da muss
> > man den Oszi eben auf das entsprechende Steuersignal triggern.
> >
> > NOP ist ja nur zum Lesen gut. Und dafür hatte ich ja den Weg des
> > geringsten
> > Aufwands, nämlich 7F vorgeschlagen.
> >
> >>>> Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
> >>>> wäre ein realer Adresszähler.
> >>>>
> >>>> Abgesehen davon passt das alles nur auf den Z80.
> >>>
> >>> Mit Verlaub: Genau darum geht's hier.
> >>
> >> Die Originalaussage von Wolfgang war allerdings allgemeingültiger:
> >>
> >> Normalerweise hängt so ein Bus ja sowieso an Pullups.
> >
> > Ich hatte tatsächlich geglaubt, dass es trotzdem um den Z80 geht.
> 
> Ich war noch einmal etwas suchen... Anscheinend waren Pullups am
> Datenbus beim Z80 üblich. Ich komme eher aus der 6502-Ecke und da waren
> sie nicht zu finden.
> 
> Hatte der Z80 Probleme Leitungen nach HIGH zu ziehen?

Naja, nMOS halt. Wobei es wohl in erster Linie darum ging, die Eingänge 
niemals in der Luft hängen zu lassen. Es wurde ja auch davon abgeraten, 
sowas z.B. beim 7400 zu machen, wenn nur drei Gatter gabraucht wurden. 

> > ps. Kleine Story am Rande: Wer sich damit beschäftigt hatte, der
> > konnte mit Zettel und Stift assemblieren und fließend von FF bis
> > 80 rückwärts zählen.
> > Bei einer nicht näher beszeichneten Erwachsenenbildung sollten wir
> > hexadezimal Affe in dezimal umrechnen. Das sollte wohl witzig sein.
> > Jedenfalls hatten alle erkannt, dass das ganz knapp an der B000 ist.
> > Also haben wir 4096*11-2 gerechnet und der dumme Lehrer hat sich
> > gewundert, wieso das so schnell ging.
> 
> Ich hab neulich einen meiner Taschenrechner aus der Zeit wiedergefunden.
> Ein Privileg Solar 100SR. Den hatte ich mir damals extra gekauft weil
> der auch HEX, OCT und BIN rechnen kann, und natürlich auch wandeln.
> Funktioniert immer noch.
> 
> Hatte Quelle nicht viel ihrer Eigenmarke in der DDR herstellen lassen?

Ohne hier jemanden zu nahe treten zu wollen, gab es z.B. die Marke
'Bruns'. 
Und im 'Präsident 6313' werkelt ein U880. 

MfG
hjs

[toc] | [prev] | [next] | [standalone]

#284986

On 7/22/20 8:27 PM, Hans-Juergen Schneider wrote:
> Gerrit Heitsch wrote:
>>
>> On 7/22/20 6:31 PM, Hans-Juergen Schneider wrote:
>>> Gerrit Heitsch wrote:
>>>>
>>>> On 7/22/20 7:44 AM, Hans-Juergen Schneider wrote:
>>>>> Gerrit Heitsch wrote:
>>>>>>
>>>>>> On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
>>>>>>>
>>>>>>> On 21 Jul 20 at group /de/sci/electronics in article rf7edh$6tv$1@news.bawue.net
>>>>>>> <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:
>>>>>>>
>>>>>>>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
>>>>>>>> sinnvolles und auch noch abhängig von der CPU.
>>>>>>>
>>>>>>> Bei 8080...Z80 ist das ein RST 7,
>>>>>>>
>>>>>>> Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
>>>>>>>
>>>>>>> Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
>>>>>>> ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
>>>>>>> gedonnert.
>>>>>>
>>>>>> Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
>>>>>> sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
>>>>>> und dreht kleine Kreise.
>>>>>
>>>>> Die CPU springt nicht, sondern ruft. Du musst auch an den Stack denken.
>>>>
>>>> Die CPU ruft nicht, sie springt nach $0038, legt allerdings eine
>>>> Rücksprungadresse auf den Stack. Es ergibt jedenfalls keinen sauberen
>>>> Adresszähler wie ein NOP es tun würde.
>>>
>>> Ich hatte mich lediglich an die deutsche übersetzung von jump und call
>>> gehalten. Dort liegt der Unterschied.
>>> Der Adresszbus kommt alleine schon wegen Refresh durcheinander. da muss
>>> man den Oszi eben auf das entsprechende Steuersignal triggern.
>>>
>>> NOP ist ja nur zum Lesen gut. Und dafür hatte ich ja den Weg des
>>> geringsten
>>> Aufwands, nämlich 7F vorgeschlagen.
>>>
>>>>>> Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
>>>>>> wäre ein realer Adresszähler.
>>>>>>
>>>>>> Abgesehen davon passt das alles nur auf den Z80.
>>>>>
>>>>> Mit Verlaub: Genau darum geht's hier.
>>>>
>>>> Die Originalaussage von Wolfgang war allerdings allgemeingültiger:
>>>>
>>>> Normalerweise hängt so ein Bus ja sowieso an Pullups.
>>>
>>> Ich hatte tatsächlich geglaubt, dass es trotzdem um den Z80 geht.
>>
>> Ich war noch einmal etwas suchen... Anscheinend waren Pullups am
>> Datenbus beim Z80 üblich. Ich komme eher aus der 6502-Ecke und da waren
>> sie nicht zu finden.
>>
>> Hatte der Z80 Probleme Leitungen nach HIGH zu ziehen?
> 
> Naja, nMOS halt. Wobei es wohl in erster Linie darum ging, die Eingänge
> niemals in der Luft hängen zu lassen. Es wurde ja auch davon abgeraten,
> sowas z.B. beim 7400 zu machen, wenn nur drei Gatter gabraucht wurden.

Bei NMOS sind offene Eingänge nicht so sehr das Problem. CMOS mag es 
nicht, ebenso die bipolaren TTLs.

Der 6502 war dauernd auf dem Bus... Wenn er sich den auch noch mit dem 
Videochip teilte war immer noch Restladung auf den Leitungen. Das ging 
soweit, daß man beim C64 ein Programm in einem Speicherbereich laufen 
lassen konnte in dem kein Speicher war. Man musste nur dafür sorgen, daß 
der Videochip im jeweils vorherigen Zugriff das gewünschte Byte gelesen 
hat. Die CPU hat dann bei ihrem Lesezyklus dasselbe Byte nochmal gelesen.

Ist nicht ganz einfach in der Programmierung.



> Und im 'Präsident 6313' werkelt ein U880.

Könnte sein, daß ich so einen noch irgendwo im Archiv habe.

  Gerrit

[toc] | [prev] | [next] | [standalone]

#284988

Am 22.07.20 um 19:06 schrieb Gerrit Heitsch:

> Ich war noch einmal etwas suchen... Anscheinend waren Pullups am 
> Datenbus beim Z80 üblich. Ich komme eher aus der 6502-Ecke und da waren 
> sie nicht zu finden.

Nein. Aber wenn sich gerade niemand zuständig fühlt, den Bus zu treiben,
dann ist trotzdem nichts gegen saubere Pegel einzuwenden. Bei CMOS
sowieso. CMOS kann tierisch Strom ziehen wenn die Eingänge auf Halbmast
hängen. Das halbe mA worst case des 22k-Pullup geht da völlig unter.

> 
> Hatte der Z80 Probleme Leitungen nach HIGH zu ziehen?

Nö. Nur seinen Systemtakt an Pin 6 wollte er wirklich
mit HIGH kurz vor 5V angeliefert bekommen.

Gruß, Gerhard

[toc] | [prev] | [next] | [standalone]

#284956

On 22 Jul 20 at group /de/sci/electronics in article rf8hle$lqh$1@news.bawue.net
<gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:

> On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
>>
>> On 21 Jul 20 at group /de/sci/electronics in article
>> rf7edh$6tv$1@news.bawue.net <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)
>> wrote:
>>
>>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
>>> sinnvolles und auch noch abhängig von der CPU.
>>
>> Bei 8080...Z80 ist das ein RST 7,
>>
>> Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
>>
>> Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
>> ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
>> gedonnert.

> Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
> sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
> und dreht kleine Kreise.

PATSCH, stimmt auch wieder. Aber der SP macht den Adressraum :)

> Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
> wäre ein realer Adresszähler.

Auch ne Alternative, allerdings ohne WRcycles :O

> Abgesehen davon passt das alles nur auf den Z80.

Passt zum Fred :)

HIV, hatte der 8080 nicht auch RST?


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[toc] | [prev] | [next] | [standalone]

#284980

Wolfgang Allinger wrote:
> 
> On 22 Jul 20 at group /de/sci/electronics in article rf8hle$lqh$1@news.bawue.net
> <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:
> 
> > On 7/21/20 10:58 PM, Wolfgang Allinger wrote:
> >>
> >> On 21 Jul 20 at group /de/sci/electronics in article
> >> rf7edh$6tv$1@news.bawue.net <gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)
> >> wrote:
> >>
> >>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
> >>> sinnvolles und auch noch abhängig von der CPU.
> >>
> >> Bei 8080...Z80 ist das ein RST 7,
> >>
> >> Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.
> >>
> >> Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR
> >> ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM
> >> gedonnert.
> 
> > Wie denn? Der erste $FF lässt die CPU nach $0038 springen. Dort findet
> > sie wieder einen $FF womit sie nach $0038 springt, ab da bleibt sie dort
> > und dreht kleine Kreise.
> 
> PATSCH, stimmt auch wieder. Aber der SP macht den Adressraum :)
> 
> > Pulldowns wären in diesem Falle sinnvoller. Dann hättest du NOP und das
> > wäre ein realer Adresszähler.
> 
> Auch ne Alternative, allerdings ohne WRcycles :O
> 
> > Abgesehen davon passt das alles nur auf den Z80.
> 
> Passt zum Fred :)
> 
> HIV, hatte der 8080 nicht auch RST?

Ja, hatte er. 

MfG
hjs

[toc] | [prev] | [next] | [standalone]

#284925

Wolfgang Allinger <all2001@spambog.com> wrote:

>On 21 Jul 20 at group /de/sci/electronics in article rf7edh$6tv$1@news.bawue.net
><gerrit@laosinh.s.bawue.de>  (Gerrit Heitsch)  wrote:

>> Mit Pullups würde die CPU dann Opcode $FF lesen. Das ist selten was
>> sinnvolles und auch noch abhängig von der CPU.

>Bei 8080...Z80 ist das ein RST 7,

>Ist wie ein CALL 38h, aber eben nur 1 byte. War für IR Vectoren gedacht.

>Dh. die CPU strampelt sich durch den ganzen Adressraum und macht sogar WR  
>ins RAM, es wird die aktuelle (16bit) Returnadr in 2 cyclen ins RAM  
Jetzt habe ich es verstanden. Die CPU dreht sich zwar auf der Stelle, da
auf 0x38 wieder ein call auf 0x38 steht, aber der SP wird jedesmal 
dekrementiert und adressiert das RAM. Also ein leeres EPROM als 
Testdevice. Sollte man teuer verkaufen :-)


-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#284802

> mit dem Tastkopf ... schon wird die Startmeldung und die Fehlermeldung
> "BDOS Error on disk ..." angezeigt, was korrekt ist,

Wenn man Prüfspitzen aufsetzt, biegt man oft die Leiterplatte
leicht durch. Kann bei kalten Lötstellen, schlechten IC-Sockeln
den gewünschten Effekt haben.
Bei Oszilloskopen hat man oft über den Masseclip eine weitere 
Erdverbindung nachgerüstet. Wenns erst mit der funktioniert
sollte man mit Ohmmeter prüfen ob die ursprünglichen GNDs
alle tatsächlich Verbindung haben.

MfG  JRD

[toc] | [prev] | [next] | [standalone]

#284893

Am 20.07.20 um 09:53 schrieb Peter Heitzer:
> Wonach sollte ich am ersten suchen? Merkwürdigerweise scheint die
> Initialisierung von CTC und SIO immer zu funktionieren, aber danach
> hängt das Programm im EPROM.

Alte EPROMs bekommen gerne mal Alzheimer. Es ist kein Fehler, sie mal 
mit dem richtigen Inhalt - hoffentlich vorhanden - drüber zu 
programmieren. Löschen muss man dafür an sich nicht.

Eine andere Option wäre ein Wackelkontakt, den Du beim Messen am Bus 
zufällig vorübergehend behoben hast. Alle Steckverbindungen 
einschließlich IC-Sockeln und Pins auf Verfärbungen prüfen. Wenn sie 
Schwarz sind, kennst Du das Problem. Wenn nicht, ist das leider kein 
Freispruch.

> Ich hätte zwecks IC-Tausch noch ein paar funktionierende Karten des
> selben Typs zur Verfügung. Welche ICs sollte ich als erstes tauschen?

Ich glaube nicht an einen Bauteildefekt.


Marcel

[toc] | [prev] | [next] | [standalone]

#284926

Marcel Mueller <news.5.maazl@spamgourmet.org> wrote:
>Am 20.07.20 um 09:53 schrieb Peter Heitzer:
>> Wonach sollte ich am ersten suchen? Merkwürdigerweise scheint die
>> Initialisierung von CTC und SIO immer zu funktionieren, aber danach
>> hängt das Programm im EPROM.

>Alte EPROMs bekommen gerne mal Alzheimer. Es ist kein Fehler, sie mal 
>mit dem richtigen Inhalt - hoffentlich vorhanden - drüber zu 
>programmieren. Löschen muss man dafür an sich nicht.

>Eine andere Option wäre ein Wackelkontakt, den Du beim Messen am Bus 
>zufällig vorübergehend behoben hast. Alle Steckverbindungen 
>einschließlich IC-Sockeln und Pins auf Verfärbungen prüfen. Wenn sie 
>Schwarz sind, kennst Du das Problem. Wenn nicht, ist das leider kein 
>Freispruch.

Den Datenbus habe ich ohms schon durchgemessen. Es waren jeweils unter 
1 Ohm. Ich werde mir mal die Platine genauer nach schlechten Lötstellen
ansehen. Bei den Platinen wurden auch immer Modifkationen vorgenommen
(mit Fädeldraht usw.). Vielleicht wurde eine Leiterbahn aufgetrennt und
eine andere Verbindung mit Fädeldraht ist inzwischen abgefallen.

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#285113

In article <hnl0rnF1cf0U1@mid.individual.net>,
	"Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> writes:
> Sonst passiert nichts. Beim Messen mit dem Oszilloskop bin ich 
> zufälligerweise auf Datenleitung D3 während Reset (via Taster) mit dem
> Tastkopf gewesen und schon wird die Startmeldung und die Fehlermeldung
> "BDOS Error on disk ..." angezeigt, was korrekt ist, da nur die Karte
> 
Ist dieses verhalten reproduzierber?
Verwendest du einen 10/1 Tastkopf? Damit würde ich eher eine Mechanische
Wirkung als eine elektrische vermuten.

Gernot

[toc] | [prev] | [next] | [standalone]

#285230

Gernot Fink <g.fink@gmx.net> wrote:
>In article <hnl0rnF1cf0U1@mid.individual.net>,
>        "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> writes:
>> Sonst passiert nichts. Beim Messen mit dem Oszilloskop bin ich 
>> zufälligerweise auf Datenleitung D3 während Reset (via Taster) mit dem
>> Tastkopf gewesen und schon wird die Startmeldung und die Fehlermeldung
>> "BDOS Error on disk ..." angezeigt, was korrekt ist, da nur die Karte
>> 
>Ist dieses verhalten reproduzierber?
Ist reproduzierbar. Auch ein 1k8 Pullup verursacht das Verhalten. Ich
habe jetzt an zwei Datenleitungen 1k8 Pullups gelötet und nun scheint
die Karte zu funktionieren. Erklären kann ich mir es allerdings nicht.

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#285231

Am 27.07.2020 um 09:21 schrieb Peter Heitzer:
> Gernot Fink <g.fink@gmx.net> wrote:
>> In article <hnl0rnF1cf0U1@mid.individual.net>,
>>         "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> writes:
>>> Sonst passiert nichts. Beim Messen mit dem Oszilloskop bin ich
>>> zufälligerweise auf Datenleitung D3 während Reset (via Taster) mit dem
>>> Tastkopf gewesen und schon wird die Startmeldung und die Fehlermeldung
>>> "BDOS Error on disk ..." angezeigt, was korrekt ist, da nur die Karte
>>>
>> Ist dieses verhalten reproduzierber?
> Ist reproduzierbar. Auch ein 1k8 Pullup verursacht das Verhalten. Ich
> habe jetzt an zwei Datenleitungen 1k8 Pullups gelötet und nun scheint
> die Karte zu funktionieren. Erklären kann ich mir es allerdings nicht.

Da wird ein Timing arg auf Kante genäht sein.

[toc] | [prev] | [next] | [standalone]

#285232

On 7/27/20 9:21 AM, Peter Heitzer wrote:
> Gernot Fink <g.fink@gmx.net> wrote:
>> In article <hnl0rnF1cf0U1@mid.individual.net>,
>>         "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> writes:
>>> Sonst passiert nichts. Beim Messen mit dem Oszilloskop bin ich
>>> zufälligerweise auf Datenleitung D3 während Reset (via Taster) mit dem
>>> Tastkopf gewesen und schon wird die Startmeldung und die Fehlermeldung
>>> "BDOS Error on disk ..." angezeigt, was korrekt ist, da nur die Karte
>>>
>> Ist dieses verhalten reproduzierber?
> Ist reproduzierbar. Auch ein 1k8 Pullup verursacht das Verhalten. Ich
> habe jetzt an zwei Datenleitungen 1k8 Pullups gelötet und nun scheint
> die Karte zu funktionieren. Erklären kann ich mir es allerdings nicht.

Eprom zu langsam?

  Gerrit

[toc] | [prev] | [next] | [standalone]

#285235

Gerrit Heitsch <gerrit@laosinh.s.bawue.de> wrote:
>On 7/27/20 9:21 AM, Peter Heitzer wrote:
>> Gernot Fink <g.fink@gmx.net> wrote:
>>> In article <hnl0rnF1cf0U1@mid.individual.net>,
>>>         "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> writes:
>>>> Sonst passiert nichts. Beim Messen mit dem Oszilloskop bin ich
>>>> zufälligerweise auf Datenleitung D3 während Reset (via Taster) mit dem
>>>> Tastkopf gewesen und schon wird die Startmeldung und die Fehlermeldung
>>>> "BDOS Error on disk ..." angezeigt, was korrekt ist, da nur die Karte
>>>>
>>> Ist dieses verhalten reproduzierber?
>> Ist reproduzierbar. Auch ein 1k8 Pullup verursacht das Verhalten. Ich
>> habe jetzt an zwei Datenleitungen 1k8 Pullups gelötet und nun scheint
>> die Karte zu funktionieren. Erklären kann ich mir es allerdings nicht.

>Eprom zu langsam?
Das Verhalten zeigt sich auch bei einem EPROM-Simulator mit 120ns RAM.
Es hängen auch relativ viele IC direkt am Datenbus. Da könnte der Z80 u.U.
Probleme mit der Anstiegszeit haben. Gibt es SIL-Widerstandsarrays mit gemeinsamen
Punkt in der Mitte? Das wäre beim Z80 praktisch, da hier VCC zwischen den 
Datenleitungen liegt. Eine der sensitiven Datenleitungen ist (zufälligerweise?)
direkt neben VCC. Die Versorgungsspannung schaute aber sauber aus.
Die Resetlogik ist auch nicht nach meinem Geschmack. Ein Supervisor wie 
ein TL7705 wäre sinnvoller. 

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [prev] | [next] | [standalone]

#285242

On 27 Jul 20 at group /de/sci/electronics in article ho7hl2Ftb8iU5@mid.individual.net
<peter.heitzer@rz.uni-regensburg.de>  (Peter Heitzer)  wrote:

> Gibt es SIL-Widerstandsarrays mit
> gemeinsamen Punkt in der Mitte? Das wäre beim Z80 praktisch, da hier VCC
> zwischen den Datenleitungen liegt.

Kenne die nur mit gemeinsamen Anschluss an einem Ende. Nimm doch 2x4R und  
das gemeinsame Bein jeweils an Vcc.

> Eine der sensitiven Datenleitungen ist
> (zufälligerweise?) direkt neben VCC. Die Versorgungsspannung schaute aber
> sauber aus.

IMHO hast Du kein Problem gegen Vcc sondern gegeneinander und/oder GND.

Aber da alles gesockelt ist, mit OmoMeter/Quietschi findbar.
Ich hab nen Quitschie, der nur über/unter 0,1Ohm unterscheidet, rein Anna- 
Lügt-Vergangenheit, also schnell und zuverlässig und dem auch 220V etc.  
Missbrauch übersteht.

Dann mit Generator die D0..7 treiben über >5k und mit Oscar die Signale  
begucken. Irgendwer reisst das dann runter...

> Die Resetlogik ist auch nicht nach meinem Geschmack. Ein
> Supervisor wie ein TL7705 wäre sinnvoller.

Z80 können schon mal mucken, wenn kein ordentlicher Reset. Dann merkt man  
bitter, dass das intern wohl ein 4biter ist. Aber ich glaube nicht, dass  
das aktuell Dein Problem ist.

PS. Einer meiner MA hatte mal nen Z80, bei dem der Tauschregistersatz  
nicht funktionierte. den hat er gehütet, wie seinen Augapfel. Damit  
brachte er alle vollmundigen Board-Tester zur Verzweiflung. Selbst in den  
100kDM++ Klasse hat den kein System gefunden, egal ob von hp oder  
sonstigen NobelstSystemen.

"Bernd bring mal Deinen Z80, hier will jemand wieder mal einen Tester  
vorführen!" ...




Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

-- 
Ich bin in Paraguay lebender Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

[toc] | [prev] | [next] | [standalone]

#285245

 >> 1k8 Pullup

> Gibt es SIL-Widerstandsarrays mit gemeinsamen
> Punkt in der Mitte?

2 Stück 5pin Arrays mit 4 Widerständen auf
gemeinsamen Kontakt...

Soweit der Bus eine Terminierung will:
es gab auch Varianten die weniger DC-Belastung
hatten. Aber deutlich mehr Bauteile.

MfG JRD

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | de.sci.electronics

csiph-web