Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Was passierte mit der Robotron-Software?

15 views
Skip to first unread message

F. W.

unread,
May 18, 2022, 7:30:13 AM5/18/22
to
Robotron hat ja einige Software des "Klassenfeindes" nachgebaut. Meines
Wissens war DCP ein MS-DOS-Clon, Redabas wohl dBase.

Was passierte eigentlich mit dieser Software?

FW

F. W.

unread,
May 18, 2022, 8:59:26 AM5/18/22
to
Am 18.05.2022 um 14:44 schrieb Peter Heirich:

> Redabas II war eine Raubkopie von dBASE II, die in wenigen bytes
> geändert wurde.

Och, menno. Jetzt wollte ich gerade stolz darauf sein, dass in
*Deutschland* einmal ein *dBase-Clone* programmiert wurde.

:-(

FW

Hans-Juergen Schneider

unread,
May 18, 2022, 12:00:20 PM5/18/22
to
Andreas Kohlbach wrote:
>
> On Wed, 18 May 2022 14:59:24 +0200, F. W. wrote:
> >
> > Am 18.05.2022 um 14:44 schrieb Peter Heirich:
> >
> >> Redabas II war eine Raubkopie von dBASE II, die in wenigen bytes
> >> geändert wurde.

Hatte das tatsächlich 'Redabas II' geheißen und nicht nur einfach
'Redabas'?

> > Och, menno. Jetzt wollte ich gerade stolz darauf sein, dass in
> > *Deutschland* einmal ein *dBase-Clone* programmiert wurde.
> >
> > :-(
>
> In (Ost-) Deutschland wurde zumindest *ein* Arcade-Spiel programmiert,
> basierend auf einem "raubkopierten" Z80 (UB880D). :-D

Der U880 war nicht raubkopiert, sondern nachgebaut.
Der Unterschied liegt bei der Bereinigung von Fehlern, die das
Original hatte.
Außerdem war das vor dem Semiconductor Chip Protection Act von 1984.

MfG
hjs

Arno Welzel

unread,
May 18, 2022, 12:21:19 PM5/18/22
to
Peter Heirich:

> F. W. wrote:
>
>> Robotron hat ja einige Software des "Klassenfeindes" nachgebaut. Meines
>> Wissens war DCP ein MS-DOS-Clon, Redabas wohl dBase.
>>
>
> Redabas II war eine Raubkopie von dBASE II, die in wenigen bytes geändert
> wurde.

Wieso "Redabas II"?

<https://www.robotrontechnik.de/index.htm?/html/software/dbprg.htm>


--
Arno Welzel
https://arnowelzel.de

Diedrich Ehlerding

unread,
May 18, 2022, 2:54:21 PM5/18/22
to
Arno Welzel meinte:

>> Redabas II war eine Raubkopie von dBASE II, die in wenigen bytes
^^
>> geändert wurde.
>
> Wieso "Redabas II"?

Ich hab dir mal was unterkringelt.

--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.

Diedrich Ehlerding

unread,
May 19, 2022, 1:55:30 AM5/19/22
to
Peter Heirich meinte:

>>Ich hab dir mal was unterkringelt.
>
> Soll mir sagen ?

Dass Redabas II eine Raubkopie von dBase II war.
^^ ^^

Hans-Juergen Schneider

unread,
May 19, 2022, 12:29:59 PM5/19/22
to
Andreas Kohlbach wrote:
>
> On Wed, 18 May 2022 18:00:19 +0200, Hans-Juergen Schneider wrote:
> >
> > Andreas Kohlbach wrote:
> >>
> >> In (Ost-) Deutschland wurde zumindest *ein* Arcade-Spiel programmiert,
> >> basierend auf einem "raubkopierten" Z80 (UB880D). :-D
> >
> > Der U880 war nicht raubkopiert, sondern nachgebaut.
>
> Deswegen hatte ich () benutzt.
>
> > Der Unterschied liegt bei der Bereinigung von Fehlern, die das
> > Original hatte.
>
> Was, der Z80 hatte Fehler, die im UB880D bereinigt wurden?

Ja.
Allerdings hab ich auf die Schnelle nichts dazu gefunden.
Ist ja auch schon lange her. Und geheim war das sowieso.

MfG
hjs

Arno Welzel

unread,
May 19, 2022, 1:03:21 PM5/19/22
to
Peter Heirich:

> Diedrich Ehlerding wrote:
>
>> Arno Welzel meinte:
>>
>>>> Redabas II war eine Raubkopie von dBASE II, die in wenigen bytes
>> ^^
>>>> geändert wurde.
>>>
>>> Wieso "Redabas II"?
>>
>> Ich hab dir mal was unterkringelt.
>
> Soll mir sagen ?

Nicht *Dir*, sondern *mir*.

Wegen "dBase II" hieß das auch "Redabas II".

Chr. Maercker

unread,
May 20, 2022, 4:58:43 AM5/20/22
to
Hans-Juergen Schneider wrote:
[der Z80 hatte Fehler, die im UB880D bereinigt wurden?]

> Ja.
> Allerdings hab ich auf die Schnelle nichts dazu gefunden.
> Ist ja auch schon lange her. Und geheim war das sowieso.

In "radio, fernsehen, electronik" erschien in den 1980ern ein Artikel
über unbekannte Befehle des U880. Man hatte ausprobiert, was passiert,
wenn der Program Counter des Z80/U880 mit Byte-Kombinationen gefüttert
wird, die nicht im offiziellen Befehlssatz enthalten sind. Mit wenig
spektakulären Ergebnissen zwar, aber Indiz dafür, dass man sich
seinerzeit in der DDR intensiv mit dem Befehlsdecoder der Z80 CPU
beschäftigt hat. Dass bei den Zwei-Byte-Befehlen des Z80-Befehlssatzes
etliche Byte-Kombinationen nicht dokumentiert sind, ist augefällig.

--


CU Chr. Maercker.

Chr. Maercker

unread,
May 20, 2022, 5:01:46 AM5/20/22
to
Sie ist ausgestorben, weil nach 1989 hoffnungslos veraltet. Kann mich
übrigens nicht erinnern, ob ich jemals eine Diskette mit DCP hatte oder
ob nur auf Platte ausgeliefert wurde.
--


CU Chr. Maercker.

Stefan Froehlich

unread,
May 20, 2022, 7:23:29 AM5/20/22
to
On Fri, 20 May 2022 10:58:41 Chr. Maercker wrote:
> Man hatte ausprobiert, was passiert, wenn der Program Counter des
> Z80/U880 mit Byte-Kombinationen gefüttert wird, die nicht im
> offiziellen Befehlssatz enthalten sind. Mit wenig spektakulären
> Ergebnissen zwar, aber Indiz dafür, dass man sich seinerzeit in
> der DDR intensiv mit dem Befehlsdecoder der Z80 CPU beschäftigt
> hat. Dass bei den Zwei-Byte-Befehlen des Z80-Befehlssatzes etliche
> Byte-Kombinationen nicht dokumentiert sind, ist augefällig.

Wenn ich das noch richtig im Hinterkopf habe, war eine ganze Reihe
davon zwar nicht sinnvoll, aber deren Funktion schlüssig aus dem
OpCode (und damit vermutlich dem Chipdesign) herleitbar. Hier würde
ich auch von einem Klon das gleiche Verhalten erwarten.

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Der kaputte Hauch genialer Module. Stefan!
(Sloganizer)

Hans-Juergen Schneider

unread,
May 20, 2022, 10:15:35 AM5/20/22
to
Stefan Froehlich wrote:
>
> On Fri, 20 May 2022 10:58:41 Chr. Maercker wrote:
> > Man hatte ausprobiert, was passiert, wenn der Program Counter des
> > Z80/U880 mit Byte-Kombinationen gefüttert wird, die nicht im
> > offiziellen Befehlssatz enthalten sind. Mit wenig spektakulären
> > Ergebnissen zwar, aber Indiz dafür, dass man sich seinerzeit in
> > der DDR intensiv mit dem Befehlsdecoder der Z80 CPU beschäftigt
> > hat. Dass bei den Zwei-Byte-Befehlen des Z80-Befehlssatzes etliche
> > Byte-Kombinationen nicht dokumentiert sind, ist augefällig.
>
> Wenn ich das noch richtig im Hinterkopf habe, war eine ganze Reihe
> davon zwar nicht sinnvoll,

Doch das war schon sinnvoll: Der Z80 hat zwei 16-Bit-Register
IX und IY. Und weil ja sowieso ständiger Mangel an Registern
herrscht, wäre es ja gut, wenn man die jeweils halbieren könnte.
Genau so hat das auch wirklich funktioniert und es gab Assembler,
die die Register LX, HX, LY und HY beherrschten.

> aber deren Funktion schlüssig aus dem
> OpCode (und damit vermutlich dem Chipdesign) herleitbar. Hier würde
> ich auch von einem Klon das gleiche Verhalten erwarten.

Der Befehlsdekoder und die interne Weichenstellung waren eben
fest verdrahtet.

MfG
hjs

Wolf gang P u f f e

unread,
May 21, 2022, 7:39:14 AM5/21/22
to
So auch in meiner Erinnerung.
Man konnte mit den undokumentierten Befehlen mitunter ein paar
CPU-Takte einsparen, oder auch zusätzlich (sinnlos) verheizen.
Das Betraf wohl undokumentierte Ladebefehle und auch die Reaktion
des Flagregisters bei undokumentierten Befehle.
...irgendwo hatte ich da mal Notizen gem8, wo die nur geblieben sind?



Andreas Bockelmann

unread,
May 21, 2022, 1:48:42 PM5/21/22
to
Wolf gang P u f f e schrieb:

> So auch in meiner Erinnerung.
> Man konnte mit den undokumentierten Befehlen mitunter ein paar
> CPU-Takte einsparen, oder auch zusätzlich (sinnlos) verheizen.

Es ist zwar ewig her, dass ich mich mit Achtbittern auf Assemblerebene
unterhalten habe, aber unnütz war das Herausstreichen oder Hinzufügen von
Takten nicht. Spätestens wenn man mit der CPU selbst (ohne Interrupt)
irgendwelche Timings einhalten muss. NOP (No Opereation) ist nicht umsonst
erfunden.

Den Z80 habe ich erst im Studium kennen, ich war von der 6502-Fraktion.
Später habe ich noch den einen anderen Atmel AVR bespaßt, ebenfalls
ausschließlich auf Assemblerebene.



--
Mit freundlichen Grüßen
Andreas Bockelmann

Gerrit Heitsch

unread,
May 21, 2022, 1:56:57 PM5/21/22
to
On 5/21/22 19:47, Andreas Bockelmann wrote:
> Wolf gang P u f f e schrieb:
>
>> So auch in meiner Erinnerung.
>> Man konnte mit den undokumentierten Befehlen mitunter ein paar
>> CPU-Takte einsparen, oder auch zusätzlich (sinnlos) verheizen.
>
> Es ist zwar ewig her, dass ich mich mit Achtbittern auf Assemblerebene
> unterhalten habe, aber unnütz war das Herausstreichen oder Hinzufügen
> von Takten nicht. Spätestens wenn man mit der CPU selbst (ohne
> Interrupt) irgendwelche Timings einhalten muss. NOP (No Opereation) ist
> nicht umsonst erfunden.

Auch gerne als NOP auf dem 6502 benutzt war BIT $xx, brauchte 3 Takte
und man musste aufpassen, daß es einem nicht Flags zerlegte.

Gerrit

Hans-Juergen Schneider

unread,
May 22, 2022, 5:41:55 AM5/22/22
to
Wolf gang P u f f e wrote:
>
> Am 20.05.2022 um 10:58 schrieb Chr. Maercker:
> > Hans-Juergen Schneider wrote:
> > [der Z80 hatte Fehler, die im UB880D bereinigt wurden?]
> >
> >> Ja.
> >> Allerdings hab ich auf die Schnelle nichts dazu gefunden.
> >> Ist ja auch schon lange her. Und geheim war das sowieso.
> >
> > In "radio, fernsehen, electronik" erschien in den 1980ern ein Artikel
> > Über unbekannte Befehle des U880.

> ...irgendwo hatte ich da mal Notizen gem8, wo die nur geblieben sind?

Bestimmt hier: https://hjs.lima-city.de/temp/rfe_1983_11-726.pdf

MfG
hjs

Wolf gang P u f f e

unread,
May 22, 2022, 12:51:49 PM5/22/22
to
Stimmt, da steht es auch!
Habe meine Notizen gefunden und ich hatte da vermerkt, dass die
Ladebefehle für die Register H und L durch Vorranstellen von DD bzw. FD
genau so für die Indexregister funktionieren.

Chr. Maercker

unread,
May 23, 2022, 5:20:23 AM5/23/22
to
Hans-Juergen Schneider wrote:
[der Z80 hatte Fehler, die im UB880D bereinigt wurden?
In "radio, fernsehen, electronik" erschien in den 1980ern ein Artikel
über unbekannte Befehle des U880]

> Bestimmt hier: https://hjs.lima-city.de/temp/rfe_1983_11-726.pdf

Hatte einen etwas längeren Beitrag in Erinnerung, aber evtl. gab es noch
einen weiteren, der auf dieser Erstveröffentlichung aufbaute. Dort fand
sich WIMRE die Anmerkung, dass wenig Brauchbares dabei ist.

--


CU Chr. Maercker.

Chr. Maercker

unread,
May 23, 2022, 5:26:37 AM5/23/22
to
Wolf gang P u f f e wrote:
> Man konnte mit den undokumentierten Befehlen mitunter ein paar
> CPU-Takte einsparen, oder auch zusätzlich (sinnlos) verheizen.

Da es überwiegend die beiden Indexregister IX und IY betraf, brauchte es
grundsätzlich ein zusätzliches Byte (und damit einen zusätzlichen Takt
zum Laden) pro Befehl. Da nicht nur Takte einzusparen waren, sondern vor
allem RAM knapp war, habe ich auf den Gebrauch von IX/IY weitestgehend
verzichtet.

> Das Betraf wohl undokumentierte Ladebefehle und auch die Reaktion
> des Flagregisters bei undokumentierten Befehle.

Es waren lt. dem verlinkten Original die kompletten Pendants für IX, IX,
zu den Befehlen, die HL bzw. die beiden anderen Registerpaare konnten.
--


CU Chr. Maercker.

Chr. Maercker

unread,
May 23, 2022, 5:29:59 AM5/23/22
to
Hans-Juergen Schneider wrote:
> Doch das war schon sinnvoll: Der Z80 hat zwei 16-Bit-Register
> IX und IY. Und weil ja sowieso ständiger Mangel an Registern
> herrscht, wäre es ja gut, wenn man die jeweils halbieren könnte.
> Genau so hat das auch wirklich funktioniert und es gab Assembler,
> die die Register LX, HX, LY und HY beherrschten.

Wenn die Register knapp wurden, gab es notfalls EXX. Wobei ich selbst
das selten einsetzen musste.

> Der Befehlsdekoder und die interne Weichenstellung waren eben
> fest verdrahtet.

Ein Vorteil, angesichts gewisser Sicherheitsvorfälle der letzten Jahre. ;-)
--


CU Chr. Maercker.

Hermann Riemann

unread,
May 23, 2022, 8:35:29 AM5/23/22
to
Am 23.05.22 um 11:26 schrieb Chr. Maercker:
> Wolf gang P u f f e wrote:
>> Man konnte mit den undokumentierten Befehlen mitunter ein paar
>> CPU-Takte einsparen, oder auch zusätzlich (sinnlos) verheizen.
>
> Da es überwiegend die beiden Indexregister IX und IY betraf, brauchte es
> grundsätzlich ein zusätzliches Byte (und damit einen zusätzlichen Takt
> zum Laden) pro Befehl. Da nicht nur Takte einzusparen waren, sondern vor
> allem RAM knapp war, habe ich auf den Gebrauch von IX/IY weitestgehend
> verzichtet.

Bei meinen ersten beiden computer war RAM knapp.
Mein erster funktionierender Z80 hatte zwar nur 2 kB RAM + 2 kB EPROM
aber da am bald die 16 kB statische RAM Karte
mit Batterie gepufferten RAMs vom Typ 48Z02 hinzu,
Und dann die 12 K EPROM Karte ( 4 K war durch die CPU-Karte belegt)
Diese Karten habe ich nicht mit Maschinencode etc. voll bekommen.
Da erkannte ich schon, dass ich meine computer nicht zu Lebzeiten
mit eigenen Texten ausfüllen kann.

Hermann
Festplatten Byte Multibillionär

--
http://www.hermann-riemann.de

Hans-Juergen Schneider

unread,
May 23, 2022, 11:22:35 AM5/23/22
to
"Chr. Maercker" wrote:
>
> Wolf gang P u f f e wrote:
> > Man konnte mit den undokumentierten Befehlen mitunter ein paar
> > CPU-Takte einsparen, oder auch zusätzlich (sinnlos) verheizen.
>
> Da es überwiegend die beiden Indexregister IX und IY betraf, brauchte es
> grundsätzlich ein zusätzliches Byte (und damit einen zusätzlichen Takt
> zum Laden) pro Befehl. Da nicht nur Takte einzusparen waren, sondern vor
> allem RAM knapp war, habe ich auf den Gebrauch von IX/IY weitestgehend
> verzichtet.

Es gab Anwendungen ganz ohne RAM. Prominentestes Beispiel ist wohl
die Melodieklingel. Ich hab damals auch einen DCF-Empfänger und eine
serielle Tastatur ohne RAM gebaut. Das freut man sich durchaus über
diese Möglichkeiten.

MfG
hjs

Gerrit Heitsch

unread,
May 23, 2022, 11:33:16 AM5/23/22
to
Es gibt die ACS-77 Uhr (DCF-77). Da werkelt ein Z80 als CPU und als RAM
gibt es nur ein 2114, also 1kx4 womit alles was den Stack benutzen will
nicht verwendet werden kann.

Wer eine solche noch hat sollte sie auf etwas stromsparender umbauen:

https://cschirp.de/index.php/elektronik/acs-77-update.html

Was im Artikel nicht erwähnt wird, vom 2114 gibt es CMOS-Versionen.

Gerrit

0 new messages