Große Auswahl an Computer Magazinen in PDF

[Andreas Kohlbach]

Angeregt durch Joss' Artikel, mochte ich
<https://www.americanradiohistory.com/> hier erwähnen. Es hat die größte
Auswahl an PDF Dokumenten über alle möglichen (englischsprachigen)
Computermagazinen und anderen Themen, wie Audio, die bis in die 1910er
zurückreichen.

So konnte ich endlich die Ausgabe von Popular Electronics aus dem Januar
1975 dort finden, was über den MITS Altair 8800 berichtet. Der Artikel,
der die (Home-) Computer-Revolution losgetreten hat.

Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
Programme parallel ausführen zu können.

Auch wird ein Taschenrechner mit einem Preis von nur unter 90 $USD
beschrieben. ;-)
--
Andreas

My random thoughts and comments
https://news-commentaries.blogspot.com/

[Ralf Kiefer]

Andreas Kohlbach wrote:

> Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
> Programme parallel ausführen zu können.

Ja und? Dem 6809 wird zwar etwas mehr Rechenleistung zugesprochen, und
für den gab's im Jahr 1979 OS-9, also ein
Multiuser-Multitasking-Betriebssystem.


Gruß, Ralf

[Kay Martinen]

Am 05.09.2018 um 23:41 schrieb Andreas Kohlbach:

> Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
> Programme parallel ausführen zu können.

Timeslicing? Interrupt-routinen und normaler Programmablauf?
Da fehlt gewisse ein "Quasi" vor dem 'Parallel'.

Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.

Kay

--
Sent via SN (Eisfair-1)

[Bernd Laengerich]

Am 06.09.2018 um 09:01 schrieb Kay Martinen:

> Timeslicing? Interrupt-routinen und normaler Programmablauf?

Mit iRMX80, der "Intel Real-Time Multitasking eXecutive" von 1976 war
Echtzeitfähigkeit gegeben: "iRMX is a multi-processing, multi-threaded,
pre-emptive, real-time operating system (RTOS)". Habe aber erst mit iRMX86
angefangen professionell zu arbeiten. Die Konzepte darin sind zeitlos elegant.

Bernd

[Ralf Kiefer]

Kay Martinen wrote:

> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.

In Zyklen ausgedrückt recht wenige. Wobei natürlich der 6502 (fast) alle
anderen 8-Bitter schlägt.

Letztendlich ist ein Task-Wechsel eine überschaubare Aufgabe:
- Einleitung eines Task-Wechsels z.B. durch Ticker oder durch ein
$sleep/$wait oder was immer das Betriebssystem vorsieht
- Retten des Registersatzes im vorherigen Prozeßdeskriptor
- Auswählen des nächsten Prozeßdeskriptors aus einer Liste
- Restaurieren des Registersatzes für den nächsten Prozeß
- Beenden des Schedulers, ggf. nur ein rts/rti o.ä.

Hast Du einen 6502, dann ist der Timer-Interrupt in maximal 7 Zyklen
erreicht. Ein paar Zyklen für das Bearbeiten vom IRQ, Registersatzretten
in rund 30Zyklen, Auswahl des nächsten Prozesses in 10-50Zyklen, wieder
rund 30Zyklen für die Register und ein Rücksprung. D.h. beim 6502 könnte
man mit um die 100Zyklen hinkommen (ein 65C02 aus dem Jahr 1983
weniger). Beim 8080 muß man mit ungefähr Faktor 4 bei der Zyklenzahl
rechnen wg. Zyklenzahl der einzelnen Befehle und aufgrund des großen
Registersatzes mit erheblich mehr Aufwand beim Austausch. Ohne je mit
einem 8080 gespielt zu haben schätze ich den Aufwand auf 500Zyklen.

In Kurz mit Stand aus dem Jahr 1976 (oder so):
6502 @1MHz rund 100usec
8080 @2MHz rund 250usec

Ein Vergleich mit aktuellen Produkten vom "Marktführer" wären
interessant.


Gruß, Ralf

[Andreas Kohlbach]

Multitasking ist ja nicht wirklich parallel. Ich verstehe darunter
mehrere CPU-Kerne oder Multithreading.

Dann liegen zwischen 1974 und 1979 etwa 15 Jahre, wenn man (ich
zumindest) die rasante Entwicklung der Hard- und Software in diesen fünf
Jahren auf die heutige Zeit überträgt. 1974 war bei Mikroprozessoren
8-Bit das Ende der Fahnenstange. 1979 kamen bereits die ersten 32-Bitter
auf den Markt.

[Ralf Kiefer]

Andreas Kohlbach wrote:

> On Thu, 6 Sep 2018 00:03:42 +0200, Ralf Kiefer wrote:
> >
> > Andreas Kohlbach wrote:
> >
> >> Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
> >> Programme parallel ausführen zu können.
> >
> > Ja und? Dem 6809 wird zwar etwas mehr Rechenleistung zugesprochen, und
> > für den gab's im Jahr 1979 OS-9, also ein
> > Multiuser-Multitasking-Betriebssystem.
>
> Multitasking ist ja nicht wirklich parallel. Ich verstehe darunter
> mehrere CPU-Kerne oder Multithreading.

Wie stellst Du Dir die späten 1970er Jahre vor? Damals gab's ein paar
Großrechner-Architekturen, die jeder für sich als lauffähiger Rechner
ein ganzes Rechenzentrum füllte. Eine große CPU, viele kleine
Hilfs-CPUs. Multitasking steckte in den Kinderschuhen.

Dann gab's mit den bekannten 8-Bittern die allerersten Personal
Computer, also welche, unter denen ein handelsüblicher Schreibtisch
nicht zusammenbrach. Dazwischen waren Maschinen wie die PDP-8 oder -11
angesiedelt, die man immerhin in einem einzelnen 19"-Schrank
unterbringen konnte. CPU-Kerne, Multithreading? Du hast Dich im
Jahrzehnt vertan.

Die erste mir bekannte Parallelarchitektur von nennenswerter Bedeutung
waren in den späten 1980er Jahren die Transputer. Allerdings hatte diese
Architektur keine Ähnlichkeit mit den heutigen Multikernprozessoren.
Vorher gab's bereits multi-prozessorfähige Bussysteme. Aber auch das war
nur eine Ansammlung von mehreren eigenständigen CPUs in einem Gehäuse.

> 1979 kamen bereits die ersten 32-Bitter
> auf den Markt.

Welche meinst Du? IBM/370?

Gruß, Ralf

[Arno Welzel]

Andreas Kohlbach:

> On Thu, 6 Sep 2018 00:03:42 +0200, Ralf Kiefer wrote:
>>
>> Andreas Kohlbach wrote:
>>
>>> Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
>>> Programme parallel ausführen zu können.
>>
>> Ja und? Dem 6809 wird zwar etwas mehr Rechenleistung zugesprochen, und
>> für den gab's im Jahr 1979 OS-9, also ein
>> Multiuser-Multitasking-Betriebssystem.
>
> Multitasking ist ja nicht wirklich parallel. Ich verstehe darunter
> mehrere CPU-Kerne oder Multithreading.

Was im Ergebnis für den Anwender aber keinen Unterschied macht, wenn es
präemptives Multitasking mit regelmäßigen Taskwechseln ist.

> Dann liegen zwischen 1974 und 1979 etwa 15 Jahre, wenn man (ich
> zumindest) die rasante Entwicklung der Hard- und Software in diesen fünf
> Jahren auf die heutige Zeit überträgt. 1974 war bei Mikroprozessoren
> 8-Bit das Ende der Fahnenstange. 1979 kamen bereits die ersten 32-Bitter
> auf den Markt.

Nicht ganz - die ersten kommerziell erfolgreichen 32-Bit-CPUs gab es
erst ab etwa 1982 und 8-Bit-CPUs haben bis in die 1980er Jahre hinein
durchaus noch eine gewisse Verbreitung gehabt. Die kommerziell
bedeutendeneren CPUs, wie 68020 oder 80386 waren sogar erst ab 1984
relevant.


--
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[Arno Welzel]

Ralf Kiefer:

> Kay Martinen wrote:
>
>> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.

[...]

> In Kurz mit Stand aus dem Jahr 1976 (oder so):
> 6502 @1MHz rund 100usec
> 8080 @2MHz rund 250usec
>
> Ein Vergleich mit aktuellen Produkten vom "Marktführer" wären
> interessant.

Die Größenordnung zwischen einigen 10 nsec bis ca. einigen 100 nsec bei
einer aktuellen Core i7 oder Xeon-CPU.

[Kay Martinen]

Da weiß ich das jetzt nicht (wo und wie) aber wir sind ja hier in
d.a.f.c also hab ich mal in meiner Ausgabe von Ross P. Nelsons
"80386/486 für Programmierer) von 1991 geschaut und finde dort das ein
TaskState Segment (TSS) eine Minimalgröße von 104 Byte (26*32bit Worte)
hat. Und das die CPU den Taskwechsel selbständig durchführt. Das heißt
bei einer 32Bit CPU mit nur einem Kern wie einem 80386DX25 den ich hier
noch rumflegeln hätte komme ich auf eine Zykluszeit von 40ns (was auch
den Beispielen im Buch entspricht). Wenn ich vereinfachend annehme das
sie 32bit pro Zyklus aus dem RAM lesen/schreiben könnte, 32bit Alignment
nutzt und sonst alles passt wären das theoretische 2,08 mikrosekunden
für das Retten/holen des TSS/Registersatzes (26 QW schreiben, 26QW
Lesen). Die Zahl der nötigen Zyklen hängt hier ja auch noch vom Grund
des Taskwechsels (CALL/JMP FAR, INT u.a.) ab. Ein Direkter intersegment
Sprung im PM steht dort mit 19 Zyklen, via Call Gate 32 und via
Task-Gate 43 plus Taskwechselzeit. Bei CALL sind die Zahlen noch höher.

Oh, ich sehe eben in der Tabelle im Buch stehen auch Taskumschaltungen.
Im 386/486 PM dauert der Wechsel 162 Zyklen. Das wären zusammen 205
Zyklen für einen Taskwechsel und bei 25MHz somit mindestens 8,2
mikrosekunden.

Und jetzt sollte ich/wir/jemand mal suchen wie das bei wirklich
"aktueller" Hardware aussieht... Vor- oder nach -Spectre/Meltdown
Patches :-)

Ja, ich weiß, die 386 hatte noch keine Branch-Prediction. Cache dagegen
schon womit zumindest theoretisch auch eine Seitenkanal-attacke möglich
wäre oder?

[Ralf Kiefer]

Kay Martinen wrote:

> Und das die CPU den Taskwechsel selbständig durchführt.

Ein wesentliches Detail.

> Das heißt
> bei einer 32Bit CPU mit nur einem Kern wie einem 80386DX25 den ich hier
> noch rumflegeln hätte komme ich auf eine Zykluszeit von 40ns (was auch
> den Beispielen im Buch entspricht).

Zu 80386-Zeiten hatte DRAM eine Zugriffszeit in der Größenordnung von
100-120nsec.

Allerdings erscheinen mir 26 32bit-Worte recht wenig für einen
Task-Wechsel. Bei einem voll ausgebauten 68030er mit FPU und MMU aus
derselben Zeit müßten es einige mehr gewesen sein. Gerade die MMU ...

Mitte der 1990er Jahre hatten wir auf unseren 68060 die Situation, daß
wir die internen Tabellen der MMU "überstrapazierten". D.h. die hatte
plötzlich zum Prozeßwechsel das Bedürfnis einen Teil ihrer internen
Tabellen ins RAM auszulagern. Die Rechner büßten immens Rechenleistung
ein.

> Oh, ich sehe eben in der Tabelle im Buch stehen auch Taskumschaltungen.
> Im 386/486 PM dauert der Wechsel 162 Zyklen. Das wären zusammen 205
> Zyklen für einen Taskwechsel und bei 25MHz somit mindestens 8,2
> mikrosekunden.

162 Zyklen erscheinen mir sehr wenig.

> Ja, ich weiß, die 386 hatte noch keine Branch-Prediction. Cache dagegen
> schon womit zumindest theoretisch auch eine Seitenkanal-attacke möglich
> wäre oder?

Dazu braucht man eine sehr präzise Zeitmessung.

Gruß, Ralf

[Hermann Riemann]

Am 06.09.2018 um 10:56 schrieb Ralf Kiefer:

> Letztendlich ist ein Task-Wechsel eine überschaubare Aufgabe:
> - Einleitung eines Task-Wechsels z.B. durch Ticker oder durch ein
> $sleep/$wait oder was immer das Betriebssystem vorsieht
> - Retten des Registersatzes im vorherigen Prozeßdeskriptor
> - Auswählen des nächsten Prozeßdeskriptors aus einer Liste
> - Restaurieren des Registersatzes für den nächsten Prozeß
> - Beenden des Schedulers, ggf. nur ein rts/rti o.ä.

Es sei denn beim TMS9900, wo die Register ohnehin im RAM liegen.

Hermann
der sich noch an die Zeitschrift Chip erinnert,
wo sie diese CPU gegen den Z80 antreten ließen.

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

[Peter Heitzer]

Arno Welzel <use...@arnowelzel.de> wrote:
>Ralf Kiefer:

>> Kay Martinen wrote:
>>
>>> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.
>[...]
>> In Kurz mit Stand aus dem Jahr 1976 (oder so):
>> 6502 @1MHz rund 100usec
>> 8080 @2MHz rund 250usec
>>
>> Ein Vergleich mit aktuellen Produkten vom "Marktführer" wären
>> interessant.

>Die Größenordnung zwischen einigen 10 nsec bis ca. einigen 100 nsec bei
>einer aktuellen Core i7 oder Xeon-CPU.

Ich hatte immer grössere Zeiten im Kopf. Vor allem ist die Latenz bei
Hardwareinterrupts verglichen mit aktuellen Mikrocontrollern AFAIK um
einiges höher. Ich habe aber diesbezüglich kein aktuelles Datenblatt
studiert, sodaß ich mich auch durchaus irren kann.

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

[Hermann Riemann]

Am 06.09.2018 um 09:01 schrieb Kay Martinen:

>> Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
>> Programme parallel ausführen zu können.

> Timeslicing? Interrupt-routinen und normaler Programmablauf?
> Da fehlt gewisse ein "Quasi" vor dem 'Parallel'.

> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.

Das wäre doch ein Retro:
Mit so einem Altrechner einen aktuellen Rechner emulieren.
Register, cache MMU Floatingpoints etc
in 16 kB untergebracht,
und der Hauptspeicher (DRAM) auf Kassettenrecorder abgebildet.
Der Kassettenrekorder wird von einem Roboter gesteuert..
Nadeldrucker zur Ausgabe.
Und noch etwas IO wie beim KIM 1
um "Lochkarten" hexadezimal einzutippen.

Ach so.
Auf dem Drucker noch ein paar Photodioden
zum einscannen des Textes.

So das Papier mit seitlichen Löchern ein Magnetband ersetzt.

Hermann
dessen Vorstellungen nicht
alle umgesetzt wurden.

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

[Nils M Holm]

Arno Welzel <use...@arnowelzel.de> wrote:
> Andreas Kohlbach:

>> Dann liegen zwischen 1974 und 1979 etwa 15 Jahre, wenn man (ich
>> zumindest) die rasante Entwicklung der Hard- und Software in diesen fünf
>> Jahren auf die heutige Zeit überträgt. 1974 war bei Mikroprozessoren
>> 8-Bit das Ende der Fahnenstange. 1979 kamen bereits die ersten 32-Bitter
>> auf den Markt.
>
> Nicht ganz - die ersten kommerziell erfolgreichen 32-Bit-CPUs gab es
> erst ab etwa 1982 und 8-Bit-CPUs haben bis in die 1980er Jahre hinein
> durchaus noch eine gewisse Verbreitung gehabt. Die kommerziell
> bedeutendeneren CPUs, wie 68020 oder 80386 waren sogar erst ab 1984
> relevant.

Ach, mit den Bits, das ist so eine Sache. Schon die IBM 70x in den
50'er Jahren war eine 36-Bit-Archirektur. Und dann kommt es darauf
an, was man unter CPU versteht. Wenn man sich nicht auf VLSI ("Chips")
beschraenkt, dann ist die IBM System/360 Model 30 (1964) sicher ein
guter Kandidat fuer die erste 32-bit CPU.

--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org

[Ralf Kiefer]

Hermann Rieman wrote:

> Das wäre doch ein Retro:
> Mit so einem Altrechner einen aktuellen Rechner emulieren.

Das Booten von Windows 10 würde bereits die übliche Lebenszeit eines
Menschen überschreiten und ein Update würde mehrere Menschengenerationen
dauern.

> dessen Vorstellungen nicht
> alle umgesetzt wurden.

Aus naheliegenden Gründen wird's dabei bleiben ;-)

Gruß, Ralf

[Ralf Kiefer]

Peter Heitzer wrote:

> Arno Welzel <use...@arnowelzel.de> wrote:
> >Ralf Kiefer:
>
> >> Kay Martinen wrote:
> >>
> >>> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.
> >[...]
> >> In Kurz mit Stand aus dem Jahr 1976 (oder so):
> >> 6502 @1MHz rund 100usec
> >> 8080 @2MHz rund 250usec
> >>
> >> Ein Vergleich mit aktuellen Produkten vom "Marktführer" wären
> >> interessant.
>
> >Die Größenordnung zwischen einigen 10 nsec bis ca. einigen 100 nsec bei
> >einer aktuellen Core i7 oder Xeon-CPU.
>
> Ich hatte immer grössere Zeiten im Kopf.

AOL.

> Vor allem ist die Latenz bei
> Hardwareinterrupts verglichen mit aktuellen Mikrocontrollern AFAIK um
> einiges höher.

Dieses Problem zeichnete sich bereits vor über 20Jahren mit den 68060
ab, obwohl wir an denen eine Bandbreite beim DRAM mit damals sehr
flotten 100MB/sec hatten.


Gruß, Ralf

[Tom Nossen]

faszinierend. vielleicht sollte man soetwas einer neuen voyager beigeben
-- in der hoffnung, dass ausserirdische intelligenzen, die das finden,
zu dem schluss kommen, diese elbonier auf ihrem museumsplaneten seien
harmlos und man muesse die umgehungsstrasse halt umplanen.

- :)

ps. interessieren wuerde mich auch, ob itrgendwelche [sic!] nerds dort
dann einen emulator in klingfuck schreiben. und dann in
alt.folk.earthlings darueber diskutieren.

[Bernd Mayer]

Am 05.09.2018 um 23:41 schrieb Andreas Kohlbach:

> Angeregt durch Joss' Artikel, mochte ich
> <https://www.americanradiohistory.com/> hier erwähnen. Es hat die größte
> Auswahl an PDF Dokumenten über alle möglichen (englischsprachigen)
> Computermagazinen und anderen Themen, wie Audio, die bis in die 1910er
> zurückreichen.

Hallo,

Danke für den link.

Da ist wohl für mich auch was dabei im Bereich Audio- und Studiotechnik.


Bernd Mayer

[Marcel Mueller]

Am 06.09.2018 um 09:01 schrieb Kay Martinen:

Möglicherweise kleiner als heute.

Bis die hunderten von Registern gesichert sind und die ganze MMU neu
programmiert ist, gehen schon mal einige tausend Zyklen ins Land.

Je nach CPU waren das damals eher wenige Zyklen. Inmos T805 hatten beim
Prioritätswechsel gar eine Garantie von <500ns. Das packt heute keiner
mehr. Z80 war bei Switch in den Interrupt-Kontext auch recht flott, da
er einen zweiten Registersatz hatte. Die meisten CPUs dürften allerdings
eher bei einigen Dutzend Mikrosekunden gelegen haben.


Marcel

[Andreas Kohlbach]

On Thu, 6 Sep 2018 22:46:56 +0200, Ralf Kiefer wrote:
>
> Andreas Kohlbach wrote:
>
>> On Thu, 6 Sep 2018 00:03:42 +0200, Ralf Kiefer wrote:
>> >
>> > Andreas Kohlbach wrote:
>> >
>> >> Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
>> >> Programme parallel ausführen zu können.
>> >
>> > Ja und? Dem 6809 wird zwar etwas mehr Rechenleistung zugesprochen, und
>> > für den gab's im Jahr 1979 OS-9, also ein
>> > Multiuser-Multitasking-Betriebssystem.
>>
>> Multitasking ist ja nicht wirklich parallel. Ich verstehe darunter
>> mehrere CPU-Kerne oder Multithreading.
>
> Wie stellst Du Dir die späten 1970er Jahre vor? Damals gab's ein paar
> Großrechner-Architekturen, die jeder für sich als lauffähiger Rechner
> ein ganzes Rechenzentrum füllte. Eine große CPU, viele kleine
> Hilfs-CPUs. Multitasking steckte in den Kinderschuhen.

Es ging mir um Mikroprozessoren, also ab der Intel 4004 aufwärts.

Umm ja, wenn man unter "Parallel" auch Multitasking fallen lassen
will. Aber der MITS Altair wurde erst 1975 bekannt, und das "OS" war
zunächst "Micro Soft" BASIC (damals auseinander geschrieben), was auch
I/O machte. Danach wurde CP/M eingesetzt. Beide nicht
multitaskingfähig. Sodass sich mir nicht erschließt, wie man "parallel"
erwähnte.

[...]

[Andreas Kohlbach]

On Thu, 6 Sep 2018 22:54:12 +0200, Arno Welzel wrote:
>
> Andreas Kohlbach:

>
>> Dann liegen zwischen 1974 und 1979 etwa 15 Jahre, wenn man (ich
>> zumindest) die rasante Entwicklung der Hard- und Software in diesen fünf
>> Jahren auf die heutige Zeit überträgt. 1974 war bei Mikroprozessoren
>> 8-Bit das Ende der Fahnenstange. 1979 kamen bereits die ersten 32-Bitter
>> auf den Markt.
>
> Nicht ganz - die ersten kommerziell erfolgreichen 32-Bit-CPUs gab es
> erst ab etwa 1982 und 8-Bit-CPUs haben bis in die 1980er Jahre hinein
> durchaus noch eine gewisse Verbreitung gehabt. Die kommerziell
> bedeutendeneren CPUs, wie 68020 oder 80386 waren sogar erst ab 1984
> relevant.

Der M68000 ist von 1979 und dürfte, wenn auch nur mit 16-Bit Adressbus
ausgestattet, neben der Intel 8086/8088 aus dem selben Jahr die erste
kommerziell erfolgreiche 32-Bit-CPU gewesen sein. Wie gesagt, es geht um
Mikroprozessoren und keine 32-Bit-CPUs von IBM Mainframes aus Jahrzehnten
davor.

[Ralf Kiefer]

Andreas Kohlbach wrote:

> Der M68000 ist von 1979 und dürfte, wenn auch nur mit 16-Bit Adressbus
> ausgestattet

Die Zeitpunkte einer Vorstellung stimmen mitnichten mit der
Lieferfähigkeit überein. Den 68000 gab's erst Ende 1981 in kleinen
Stückzahlen auf dem Markt mit seinem 16bit-Datenbus, 4MB Adreßraum und
durchgehend internen 32bit-Registern.

> neben der Intel 8086/8088 aus dem selben Jahr die erste
> kommerziell erfolgreiche 32-Bit-CPU gewesen sein.

*hüstel* Diese Intel-Mißgeburt als 32bit-CPU zu bezeichnen ist IMHO
gewagt. Segmentgrenzen *grusel*


Gruß, Ralf

[Hermann Riemann]

Am 07.09.2018 um 13:06 schrieb Ralf Kiefer:

>> Ich hatte immer grössere Zeiten im Kopf.

> AOL.

Gibt es da einer neue aktuelle Installations CD?
( In jeder computer Zeitschrift?) ;-)

Hermann
der schon über 1k Silberscheiben entsorgt hat,
und noch immer weit mehr als 1 k Silberscheiben hat.

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

[Hermann Riemann]

Am 06.09.2018 um 22:54 schrieb Arno Welzel:

> 8-Bit-CPUs haben bis in die 1980er Jahre hinein
> durchaus noch eine gewisse Verbreitung gehabt.

https://www.mouser.de/Semiconductors/Integrated-Circuits-ICs/Embedded-Processors-Controllers/Microcontrollers-MCU/8-bit-Microcontrollers-MCU/_/N-a86lo

Hermann
der vermutet, das 8 bit-CPU wegen Energiesparen nicht ausstirbt.

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

[Hermann Riemann]

Am 07.09.2018 um 22:11 schrieb Andreas Kohlbach:

> Der M68000 ist von 1979 und dürfte, wenn auch nur mit 16-Bit Adressbus
> ausgestattet, neben der Intel 8086/8088 aus dem selben Jahr die erste
> kommerziell erfolgreiche 32-Bit-CPU gewesen sein.

8086/8088 war 16 bit CPU.
68000 soll intern auch noch eine 16 bit CPU gewesen sein,
auch wenn der Befehlssatz schon für 32 bit ausgelegt war.

80386 .. Befehlssätze können nur mit seltsamen Umgehungen >=32 bit.

> Wie gesagt, es geht um Mikroprozessoren und keine 32-Bit-CPUs
> von IBM Mainframes aus Jahrzehnten davor.

Nicht nur IBM produzierte mainframes.

Hermann
der vom Befehlssatz damals am liebsten den
https://de.wikipedia.org/wiki/NS320xx
gehabt hätte, der allerdings nicht mehr
zu 64 bit passt ( 68xxx vermutlich auch nicht)

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

[Christian Corti]

Hermann Riemann <nosp...@hermann-riemann.de> wrote:
> 68000 soll intern auch noch eine 16 bit CPU gewesen sein,
> auch wenn der Befehlssatz schon für 32 bit ausgelegt war.

Das spielt für den Programmierer keine Rolle. Der (zuerst XC, später
dann MC) 68000 ist aus dessen Sicht eine reinrassige 32 Bit-CPU.

Christian

[Christian Corti]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
> Die Zeitpunkte einer Vorstellung stimmen mitnichten mit der
> Lieferfähigkeit überein. Den 68000 gab's erst Ende 1981 in kleinen
> Stückzahlen auf dem Markt mit seinem 16bit-Datenbus, 4MB Adreßraum und
> durchgehend internen 32bit-Registern.

Nö, den 68000 gab es schon früher zu kaufen (IIRC liegt hier irgendwo
einer von '79 oder '80 rum). Und der physikalische Adreßraum war 24-bittig,
also 16MB.
(Bild einer '79er-CPU auf Wikipedia:
https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg)

Christian

[Ralf Kiefer]

Hermann Riemann wrote:

> der vermutet, das 8 bit-CPU wegen Energiesparen nicht ausstirbt.

Ganz im Gegenteil: die werden mit "uns"[tm] aussterben. Die Jugend
klickt nur noch irgendwelche Bibliotheken zusammen und braucht daher
Adreßraum im MB-Bereich auch schon für kleinste Anwendungen. Schau Dir
die "Maker"-Szene an! Viele freuen sich, wenn sie die richtigen
Bibliotheken gefunden haben, damit ihre RGB-LED-Kette oder was immer
auch sonst funktioniert. Die Zahl der "Maker", die tatsächlich mit den
einzelnen I/O-Pins und eigenem, sparsamem Code spielen, halte ich für
recht gering.

Gruß, Ralf

[Sebastian Barthel]

Am Sat, 08 Sep 2018 10:17:45 +0200 schrieb Christian Corti:

> Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>> Die Zeitpunkte einer Vorstellung stimmen mitnichten mit der
>> Lieferfähigkeit überein.

> (Bild einer '79er-CPU auf Wikipedia:
> https://commons.wikimedia.org/wiki/File:XC68000.agr.jpg)

Da ist kein Bild ...

[Ralf Kiefer]

Christian Corti wrote:

> Nö, den 68000 gab es schon früher zu kaufen (IIRC liegt hier irgendwo
> einer von '79 oder '80 rum).

Ab in den Tresor damit! :-)

Ich vermute, daß das handverlesene Einzelexemplare waren. Selbst
Motorolas Entwicklerboards kamen erst später. Man sollte mal auflisten,
welche Rechner oder Platinen mit 68000 wann auf dem Markt verfügbar
waren.

Mac in Großserienstückzahl: 24.1.1984
Lisa in Kleinserienstückzahl: 19.1.1983
Sage II und IV: Ende 1982/Anfang 1983
Sun 1: Mai 1982
Apollo DN100: irgendwann 1982
Tandy TRS-80 Model 16: Februar 1982, bis Juni 1982 2000Stück
ausgeliefert, fast keiner verkauft (laut Wiki)
KWS damals aus Karlsruhe: erste ausgelieferten Rechner ("handverlesene"
Einzelexemplare) vermutlich schon Ende 1981, deren größtes Problem war
die Beschaffung der CPU-Chips.

Das "Motorola Educational Computer Board" hat ein User's Manual mit der
First Edition vom Januar 1982. Die BYTE hat das Board erst im
Oktober-1983-Heft vorgestellt. Ob Motorola vorher bereits andere Demo-
oder Entwickler-Boards herstellte und verkaufte, weiß ich nicht. Wer was
weiß ... :-)

Relevanter Punkt damals: es gab keine Software für den 68000. Das fing
erst 1982 richtig an. Sage mit dem p-System, KWS lieferte ROM-basiert
Assembler und Editor, Tandy kündigte Xenix an, das nicht lieferbar war,
Microware begann 1982 das OS-9 vom 6809 auf 68k zu portieren (lieferbar
irgendwann im Jahr 1983), Sun, Apollo, Cadmus, HP u.a. begannen
frühestens 1981 mit den unixoiden Varianten, die Lisa- und
Mac-Entwicklung auf 68k startet ebenso im Jahr 1981 (AFAIR), usw.

> Und der physikalische Adreßraum war 24-bittig,
> also 16MB.

Argl, ja natürlich :-)

> (Bild einer '79er-CPU auf Wikipedia:

Ein "XC" und im Bildtitel als "Pre-release" bezeichnet. Später wurden
die XC-Modelle als Engineering Sample bezeichnet, d.h. nicht ausgereift,
Bugs drin, nicht für die Serie, sondern lediglich als Testexemplare für
Hardware-Entwickler, die damit anfangen konnten ihre Boards zu
entwickeln. Die Serien-Chips der 68k-Baureihe von Motorola hatten immer
ein vorangestelltes "MC" (und Maskennummern) aufgedruckt. BTW die
chronologisch vorangegangene Entwicklungsstufe bei Motorola trug die
spätere numerische Bezeichnung ausdrücklich nicht im Name.
Möglicherweise habe ich solch einen 68030 irgendwo im Keller liegen :-)

Fußnote: Apple lieferte anfänglich LC/Performa 475 mit XC68040 aus. Aber
das 68040-Drama ist eine andere Geschichte ...

Gruß, Ralf

[Sebastian Barthel]

Am Fri, 07 Sep 2018 08:04:03 +0000 schrieb Nils M Holm:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Andreas Kohlbach:
>>> Dann liegen zwischen 1974 und 1979 etwa 15 Jahre, wenn man (ich
>>> zumindest) die rasante Entwicklung der Hard- und Software in diesen
>>> fünf Jahren auf die heutige Zeit überträgt.
>>

>> Nicht ganz - die ersten kommerziell erfolgreichen 32-Bit-CPUs gab es

>> erst ab etwa 1982 und ...

>
> Ach, mit den Bits, das ist so eine Sache. Schon die IBM 70x in den 50'er
> Jahren war eine 36-Bit-Archirektur. Und dann kommt es darauf an, was man
> unter CPU versteht. Wenn man sich nicht auf VLSI ("Chips")
> beschraenkt, dann ist die IBM System/360 Model 30 (1964) sicher ein
> guter Kandidat fuer die erste 32-bit CPU.

Ich glaube das ist sogar so eine Art "Konsens", daß man die als erste
32Bit Maschine bezeichnet. Und ich habe verschiedentlich auch gelesen, daß
die auch sonst eigentlich alles das macht, was eine moderne CPU auch
kann, vielleicht mal von VektorExtensions und Multimedia- oder Java-
Coprozessoren abgesehen.

Und CPU ist wohl generell auch nicht (niemal nie gewesen) über die Bauart
definiert. Nur darüber, daß das Ding halt irgendwie rechnet und
"schleift", also so eine "Bandmaschine" nach Turing abbilden kann.
Wenn also mal irgendwann DNA Computer kommen, heißt das Rechenwerk immer
noch CPU. Ob's dann noch Bitbreiten gibt, wer weiß.

Bei Charles Babbage war das die "Mill".

[Sebastian Barthel]

Da ist ja aber eigentlich auch nichts Falsches dran. Vielmehr hebt das -
zumindest rein theoretisch - die ganze Programmiererei einfach auf ein
höheres abstrakteres Niveau, was ja auch durchaus ein paar Vorteile hat
(nun gut, haben kann).
Kein Mensch würde doch z.B. heut noch ohne ein Bibliothekssystem (und
wenns nur clib ist) auskommen wollen.

Schönes Beispiel gab's neulich ( <= 42 Tage ) mal bei heise: Ein Tool für
debian, was ein Bild anguckt und als Ergebnis liefert, ob da Gesichter
drin sind oder eben nicht.

Und zu 8Bit - ich find die Homecomputer ja auch "hübsch". Aber eigentlich
ist das schon zu der Zeit eine ziemlich dämliche Größe gewesen. Bei den
Adreßbussen kann man ja sagen, daß die üblichen 2x8 = 16Bit sicher schon
OK sein können, je nachdem. Aber beim Rechnen hat man für die
allermeisten Sachen doch lieber schon zumindest Zahlen von einigen
tausend. Ich hätte z.B. 10Bit für eine gute Größe befunden, weil man
damit auch Grafikkoordinaten vernünftig hätte abbilden können, was bei
320x200 Pixeln und 8Bit schon in X-Richtung nicht mehr funktioniert. Und
so ähnlich ist das dann bei Schleifenzählern oder irgendwelchen Daten aus
der "Wirklichkeit" (ADC) oder Meßwerten in Tabellen o.ä.

[Hanno Foest]

Am 07.09.2018 um 13:06 schrieb Ralf Kiefer:

>> Vor allem ist die Latenz bei
>> Hardwareinterrupts verglichen mit aktuellen Mikrocontrollern AFAIK um
>> einiges höher.
>
> Dieses Problem zeichnete sich bereits vor über 20Jahren mit den 68060
> ab, obwohl wir an denen eine Bandbreite beim DRAM mit damals sehr
> flotten 100MB/sec hatten.

Dabei fällt mir wieder ein...

Bei der x86 Modellreihe ist die (andauernde) Entwicklung bekannt, man
hat es geschafft, verglichen mit dem ersten Modell geradezu absurde
Geschwindigkeiten zu erreichen. Beim 68000 war mit dem 68060 Schluß.

Frage: Wäre es möglich gewesen, mit ähnlichem Aufwand wie bei x86 bzw.
x86-64, die 68000 Familie entsprechend weiter aufzubohren, oder gab es
da irgendwelche prinzipiellen Probleme, die sich nicht mit Geld hätten
lösen lassen? Bzw. nur viel schwieriger als bei der Konkurrenz.

Hanno

[Sebastian Barthel]

Am Thu, 06 Sep 2018 22:46:56 +0200 schrieb Ralf Kiefer:

> Andreas Kohlbach wrote:
>
>> On Thu, 6 Sep 2018 00:03:42 +0200, Ralf Kiefer wrote:
>> >
>> > Andreas Kohlbach wrote:
>> >
>> >> Mich wundert hier aber, dass man dem "powerful" Intel 8080
>> >> zuschreibt,
>> >> Programme parallel ausführen zu können.
>> >
>> > Ja und? Dem 6809 wird zwar etwas mehr Rechenleistung zugesprochen,
>> > und für den gab's im Jahr 1979 OS-9, also ein
>> > Multiuser-Multitasking-Betriebssystem.
>>
>> Multitasking ist ja nicht wirklich parallel. Ich verstehe darunter
>> mehrere CPU-Kerne oder Multithreading.
>

> Die erste mir bekannte Parallelarchitektur von nennenswerter Bedeutung
> waren in den späten 1980er Jahren die Transputer. Allerdings hatte diese
> Architektur keine Ähnlichkeit mit den heutigen Multikernprozessoren.
> Vorher gab's bereits multi-prozessorfähige Bussysteme. Aber auch das war
> nur eine Ansammlung von mehreren eigenständigen CPUs in einem Gehäuse.

Der letzte von Turing gebaute Rechner war auch schon "Parallel" und
außerdem noch "Vektor". Also eigentlich so eine Art Cray, nur eben quasi
kurz nach Erfindung der ElektronikRechnerei überhaupt.
Die Bedeutung war aber wohl eher die, aus heutiger Sicht, daß er das
nicht zu Ende gebaut hat. Hätte wahrscheinlich nochmal einen ganz anderen
Schub gegeben.

Und wenn man so will ist eine Cray schon ziemlich parallel.
Sowohl was Kerne als auch was Daten angeht.
Jahreszahl hab ich jetzt nicht parat, aber vor Transputern war das
ziemlich sicher.

(Ich finde ja witzig, daß Transputer so gar nicht liefen (im
Privatbereich), aber nun doch in quasi jeder Grafikkarte sitzen, halt als
StreamProzessoren. Späte Rache einer coolen und ziemlich verkannten (evtl.
auch "over-price-ten") Idee.)

[Sebastian Barthel]

Am Fri, 07 Sep 2018 10:02:52 +0200 schrieb Hermann Riemann:

> Am 06.09.2018 um 09:01 schrieb Kay Martinen:
>
>>> Mich wundert hier aber, dass man dem "powerful" Intel 8080 zuschreibt,
>>> Programme parallel ausführen zu können.
>
>> Timeslicing? Interrupt-routinen und normaler Programmablauf? Da fehlt
>> gewisse ein "Quasi" vor dem 'Parallel'.
>
>> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.
>
> Das wäre doch ein Retro:
> Mit so einem Altrechner einen aktuellen Rechner emulieren. Register,
> cache MMU Floatingpoints etc in 16 kB untergebracht,
> und der Hauptspeicher (DRAM) auf Kassettenrecorder abgebildet.
> Der Kassettenrekorder wird von einem Roboter gesteuert.. Nadeldrucker
> zur Ausgabe.
> Und noch etwas IO wie beim KIM 1 um "Lochkarten" hexadezimal
> einzutippen.

Also in Ansätzen gibt es das bereits, bzw. gab. Ist ein älteres Projekt.
Infos dazu unter
<https://www.pagetable.com/?p=824>

Und, ganz wichtig: Ein KIM-1 spielt - wie gewünscht - auch ein Rolle.

[Sebastian Barthel]

Am Fri, 07 Sep 2018 13:49:53 +0200 schrieb Tom Nossen:

> Am 07.09.2018 um 10:02 schrieb Hermann Riemann:
>> Am 06.09.2018 um 09:01 schrieb Kay Martinen:
>>
>>>> Mich wundert hier aber, dass man dem "powerful" Intel 8080
>>>> zuschreibt,
>>>> Programme parallel ausführen zu können.
>>
>>> Timeslicing? Interrupt-routinen und normaler Programmablauf? Da fehlt
>>> gewisse ein "Quasi" vor dem 'Parallel'.
>>
>>> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.
>>
>> Das wäre doch ein Retro:
>> Mit so einem Altrechner einen aktuellen Rechner emulieren. Register,
>> cache MMU Floatingpoints etc in 16 kB untergebracht,
>> und der Hauptspeicher (DRAM) auf  Kassettenrecorder abgebildet.

> faszinierend. vielleicht sollte man soetwas einer neuen voyager beigeben
> -- in der hoffnung, dass ausserirdische intelligenzen, die das finden,
> zu dem schluss kommen, diese elbonier auf ihrem museumsplaneten seien
> harmlos und man muesse die umgehungsstrasse halt umplanen.

> ps. interessps. interessieren wuerde mich auch, ob itrgendwelche [sic!]

> nerds dort dann einen emulator in klingfuck schreiben.

Die "Anderen" werden erstmal einen Test machen und mit sowas wie
Emulatoren in Klingfuck kann man da nicht punkten.

Gibt es als sehr schönes Hörspiel
auch bei YT
<https://www.youtube.com/watch?v=wJ7Snvt-BG8>
"Intelligenz - SciFi Hörspiel"

[Nils M Holm]

Sebastian Barthel <nait...@freenet.de> wrote:
> Kein Mensch würde doch z.B. heut noch ohne ein Bibliothekssystem (und
> wenns nur clib ist) auskommen wollen.

"Bibliothekssystems" im heutigen Sinne und libc + crt0 wuerde
ich aber schon als zwei Extreme eines Kontinuums ansehen. :)

[Ralf Kiefer]

Hanno Foest wrote:

> Bei der x86 Modellreihe ist die (andauernde) Entwicklung bekannt, man
> hat es geschafft, verglichen mit dem ersten Modell geradezu absurde
> Geschwindigkeiten zu erreichen. Beim 68000 war mit dem 68060 Schluß.

Relevante Probleme aus meiner Erinnerung: Motorola hatte bereits große
Probleme den 68040 in Stückzahlen auf den Markt zu bringen. Das führte
in etlichen Firmenzentralen zur Entscheidung die 68k-Baureihe zu
verlassen. Größter Einzelabnehmer war natürlich Apple. Deren Konsequenz
war sich beim PowerPC-Konsortium aktiv zu beteiligen, um ein bißchen
Mitsprache zu haben und nicht wie zuvor einem einzelnen CPU-Lieferant
ausgeliefert zu sein, denn zu den 68020, 68030 und 68040 gab's keine
Second Source.

Aber auch die unixoide Welt verließ nach dem 68030 oder teils 68040 die
68k-Welt aus demselben Grund. Die 88k-Welt wurde bei dieser Gelegenheit
genauso "entsorgt". Einige Details und Erfahrungen wurden in der
PPC-Entwicklung übernommen.

Atari und Amiga spielten zu diesem Zeitpunkt als Abnehmer sowieso keine
Rolle mehr. D.h. den 68060 gab's in relevanter Stückzahl nur im
Automatisierungsbereich und industriellen Umfeld, aber nicht in
Stückzahlen [1]. Diese Welt wanderte zeitgleich ebenso ins PPC-Lager ab
oder brauchte gar nicht diese CPU-Leistung, so daß die mit Motorolas
Coldfire zufrieden war, die es heute als Baukastensystem gibt. Ein
ähnliches Baukastensystem für Embedded gab's dann von Motorola und von
IBM in der PPC-Welt. Nicht zu vergessen: die damaligen Stückzahlen in
der Embedded-Welt waren deutlich größer als die für Desktop-Rechner (die
Margen pro CPU deutlich geringer), und so verabschiedete sich Motorola
aus dem Desktop-Markt zugunsten von Embedded. IBM vertritt dagegen die
PowerPC-Fahne immer noch recht ordentlich im Bereich der Supercomputer.

D.h. die Frage eines leistungsstärkeren Nachfolgers für den 68060
stellte sich auf technischer Ebene gar nicht mehr.

Meine Vermutung: mit dem (finanziellen) Aufwand, der in der Intel-Welt
getrieben wurde Architektur und Befehlssatz vom 8086 bis zu den heutigen
Mehrkernern zu treiben, hätte man ebenso die 68k-Architektur auf die
Spitze treiben können. Es fand sich nur keiner, der bezahlt. Die
Neuentwicklung des 68060 auf Basis des 68040 (siehe z.B. den
Wiki-Artikel zum 68060) zeigte, daß man sehr wohl größere strukturelle
Änderungen unter Beibehaltung der Abwärtskompatibilität schaffte.

Mit einem 68180 (oder so) hätte sogar Motorola Spectre und Meltdown
eingebaut ;-)

> Frage: Wäre es möglich gewesen, mit ähnlichem Aufwand wie bei x86 bzw.
> x86-64, die 68000 Familie entsprechend weiter aufzubohren, oder gab es
> da irgendwelche prinzipiellen Probleme, die sich nicht mit Geld hätten
> lösen lassen? Bzw. nur viel schwieriger als bei der Konkurrenz.

Ich weiß nicht, ob wir das von außen beurteilen können, welche
Schwierigkeiten die CPU-Entwickler letztendlich haben und lösen. Ab
Jahresbeginn war z.B. die Diskussion um Spectre und Meltdown sehr
beliebt. Plötzlich wußten sehr viele Leute, daß diese Fehler "ganz
einfach" zu entdecken und völlig logisch waren und fragten, warum
CPU-Entwickler jahrelang nichts repariert hätten. Ok, das ist
Heise-Forum-Niveau. Über das zu spekulieren, was sich hinter den
mehreren verschlossenen Schichten bei den CPU-Entwicklern tut, ist von
großer Unsicherheit geprägt.


Gruß, Ralf


[1] Ich gehöre zu den Glücklichen mit ein paar VMEbus-Karten mit 68060.
10Stück von denen will ich als Mehrprozessorrechner zusammenstecken. Der
Rahmen ist schon lange fertig, die Betriebssystemkonfiguration fehlt.
Aber ich schaffe das irgendwann :-)

[Ralf Kiefer]

Sebastian Barthel wrote:

> (Ich finde ja witzig, daß Transputer so gar nicht liefen (im
> Privatbereich),

Es gab Fehlversuche von Atari und von Commodore für Rechner, die bis in
den Privatmarkt gepaßt hätten. Apple schielte als Alternative zur
Hauptlinie angeblich zur 88k-Architektur, die Intel-Welt zum i860.

Zu den Zeiten, als die einzelnen Transputer teuer waren, wurden die von
Forschung und Militär gekauft, d.h. in den 1980er Jahren. Und die
kauften aus naheliegenden Gründen nicht nur kleine Stückzahlen, sondern
pro Rechner nicht unter ein paar Dutzend. Es war plötzlich so einfach
die Rechenleistung hochzuskalieren. (Viel) Geld werfen, irgendeine
Transputer-Karte, eine Spannungsversorgung dafür sowie die kurzen Kabel
für die Links kaufen. Leider gab's nie einen gemeinsamen Standard für
die Stecker.

Mein damaliger Arbeitgeber lieferte z.B. zwei solcher Großgeräte
(jeweils ein 19"-Schrank) ans Kernforschungszentrum Karlsruhe für
Atmosphärensimulation u.ä., also eine klassische Aufgabe für
Parallelrechner verwandt mit der Meteorologie. So was war extremst weit
von einem PC entfernt [1]. Aber auch INMOS hatte in den späten 1980er
Jahren Lieferprobleme. Die hätten sehr viel mehr T800 verkaufen können,
wo die Kunden sich mit T414 begnügen mußten, damit sie überhaupt solche
Rechner bekamen.

Mit Übernahme von Inmos durch SGS-Thomson war das Ende absehbar. Leider.

Gruß, Ralf

[1] Ich habe die Preisliste vom Oktober 1987 noch :-) Die (Netto-)Preise
waren wie damals üblich VHB, d.h. real 10% drunter.
VMEbus-Karte mit 6* T414 @20MHz und je 256kB RAM 14880 DM
VMEbus-Karte mit 6* T800 @20MHz und je 256kB RAM 19960 DM
VMEbus-Karte mit 1* T414 @20MHz und 1MB RAM 4220 DM
VMEbus-Karte mit 1* T800 @20MHz und 8MB RAM 11640 DM
VMEbus-Grafikkarte mit 1,25MB VRAM (1280*1024, 8bit) mit Farbtabelle,
zwei Cursorcontrollern, I/O neben eine zwingend benötigte Karte mit
einem T414 oder T800 7410 DM

Und dann ist noch kein Rack, kein Netzteil, kein Massenspeicher, kein
Controller und keine Software dafür vorhanden. Dazu nahm man
typischerweise einen vollständigen Unix- oder OS-9-Rechner, also ab
68020 mit I/O. Solch ein vollständiger Rechner ging 1987 selbst in
Minimalausstattung kaum unter 25000 DM an den Kunde. Die großen Geräte
mit vollen Racks lagen somit schnell im sechsstelligen Bereich.

Eine Auswahl an geeigneten Bildschirmen war zu dieser Zeit nicht
vorhanden. Ich erinnere mich an das typische 20"-Gerät von Hitachi zum
EK-Preis in der Region 6k bis 8k DM.

Damit ist die Frage nach einer Verbreitung im Privatbereich vermutlich
ausreichend beantwortet :-) Als Referenz für den Preis nehme ich die
Miete im Studentenwohnheim von damals rund 180DM/Monat.

[Markus Elsken]

Moin!

Am 08.09.18 um 12:02 schrieb Ralf Kiefer:

> Aber das 68040-Drama ist eine andere Geschichte ...

Wieso Drama? So kamem ein Freund und ich zu je einem Paar 68030/882 mit
50MHz. An der Uni standen zwei Apollo-Workstations, die eigentlich einen
68040 im Bauch haben sollten. Da selbiger aber Lieferprobleme hatte,
wurden sie mit einem Prozessorboard ausgeliefert, welches auf einer
Europlatine (160/100) obige Prozessoren samt Cachelogik hatte und den
040 emulierte. Als dann ein Techniker auftauchte, das Board rauswarf und
den 040er einsteckte sowie einige Eproms wechselte, deklarierte er das
alte Board als "Schrott". Die Chips liefen dann kurze Zeit später in
einer PAK/3 im MegaST und liefen mit 66MHz stabil.

;-)

mfg Markus

[Gerrit Heitsch]

On 09/08/2018 12:30 PM, Hanno Foest wrote:

> Dabei fällt mir wieder ein...
>
> Bei der x86 Modellreihe ist die (andauernde) Entwicklung bekannt, man
> hat es geschafft, verglichen mit dem ersten Modell geradezu absurde
> Geschwindigkeiten zu erreichen. Beim 68000 war mit dem 68060 Schluß.
>
> Frage: Wäre es möglich gewesen, mit ähnlichem Aufwand wie bei x86 bzw.
> x86-64, die 68000 Familie entsprechend weiter aufzubohren, oder gab es
> da irgendwelche prinzipiellen Probleme, die sich nicht mit Geld hätten
> lösen lassen? Bzw. nur viel schwieriger als bei der Konkurrenz.

Es wäre wohl auf ein komplettes Redesign wie bei INTeL rausgelaufen,
also eine CPU die einen 68060 im Microcode emuliert.

Das kostet allerdings eine Menge und lohnt deshalb nur wenn die
Stückzahlen vorhanden sind. Das war meiner Erinnerung nach beim 68060
nicht mehr der Fall.

Gerrit

[Sebastian Barthel]

Am Sat, 08 Sep 2018 15:07:34 +0200 schrieb Ralf Kiefer:

> Sebastian Barthel wrote:
>
>> (Ich finde ja witzig, daß Transputer so gar nicht liefen (im
>> Privatbereich),
>
> Es gab Fehlversuche von Atari und von Commodore für Rechner, die bis in
> den Privatmarkt gepaßt hätten. Apple schielte als Alternative zur

> Hauptlinie angeblich zur 88k-Architektur, die Intel-Welt zum i860. ...

> Mit Übernahme von Inmos durch SGS-Thomson war das Ende absehbar. Leider.

> [1] Ich habe die Preisliste vom Oktober 1987 noch :-) Die (Netto-)Preise
> waren wie damals üblich VHB, d.h. real 10% drunter.
> VMEbus-Karte mit 6* T414 @20MHz und je 256kB RAM 14880 DM
> VMEbus-Karte mit 6* T800 @20MHz und je 256kB RAM 19960 DM
> VMEbus-Karte mit 1* T414 @20MHz und 1MB RAM 4220 DM
> VMEbus-Karte mit 1* T800 @20MHz und 8MB RAM 11640 DM
> VMEbus-Grafikkarte mit 1,25MB VRAM (1280*1024, 8bit) mit Farbtabelle,
> zwei Cursorcontrollern, I/O neben eine zwingend benötigte Karte mit
> einem T414 oder T800 7410 DM
>
> Und dann ist noch kein Rack, kein Netzteil, kein Massenspeicher, kein
> Controller und keine Software dafür vorhanden. Dazu nahm man

> typischerweise einen vollständigen Unix- oder OS-9-Rechner ...

> kaum unter 25000 DM an den Kunde. Die großen Geräte
> mit vollen Racks lagen somit schnell im sechsstelligen Bereich.
>
> Eine Auswahl an geeigneten Bildschirmen war zu dieser Zeit nicht
> vorhanden. Ich erinnere mich an das typische 20"-Gerät von Hitachi zum
> EK-Preis in der Region 6k bis 8k DM.

Stattlich.

Die Preise decken sich auch gut mit denen, die es im Netz für 1989 zu
finden gab.
<http://atw800.complicated.net/>

Ich kannte eigentlich als einzige wirklich vollständige Maschinen in
diesem Zusammenhang den ATW von Atari.

<http://www.michaelp.org/transputer/>
<https://www.maedicke.de/atari/hardware/atw800.htm>
<http://www.atarimuseum.de/atw800.htm>

War auf jeden Fall ein spannender Ansatz, wenn auch evtl. ein bißchen zu
früh für eine Allgemeinverfügbarkeit.


Vielleicht magst Du die Liste ja mal scannen und irgendwo hochladen, das
sind so interessante Dokumente, die oft doch bißchen untergehen.

[Ralf Kiefer]

Sebastian Barthel wrote:

> Die Preise decken sich auch gut mit denen, die es im Netz für 1989 zu
> finden gab.

Es sagt schon was aus, wenn die Preisdifferenz zwischen 6* T414 und 6*
T800 bei rund 5000DM lag. Ich kenne die Einkaufspreise von damals nicht,
aber ich gehe einfach davon aus, daß alleine bei der Differenz der Preis
von Inmos durchgereicht wurde, weil das bei allen anderen Anbietern von
Transputerkarten dasselbe Spiel war. Es waren dieselben Sockel, alles
andere auf der Platine war auch identisch. Lediglich der Inmos-Chip im
Sockel war ein anderer.

> Ich kannte eigentlich als einzige wirklich vollständige Maschinen in
> diesem Zusammenhang den ATW von Atari.

Der große, deutsche Hersteller von Transputer-Hardware in den späten
1980er Jahren war Parsytec. Die waren nahe der RWTH Aachen und dem
Forschungszentrum Jülich und hatten in diesem Umfeld ihren Kundenkreis.
Wir saßen in der Technologiefabrik Karlsruhe im Dunstkreis der Uni sowie
vom Kernforschungszentrum, das nicht nur nukleare Forschung betrieb.
Diese Rechner haben es ggf. aufs Titelbild der Zeitschrift "VMEbus" o.ä.
geschafft, aber selten weiter. Den Heise- und Franzis-Verlag
interessierte das alles nicht. Aber immerhin bastelte der Heise-Verlag
im Rahmen von c't-Projekten auch an Transputer-Hardware.

Ich selbst hatte seinerzeit den kühnen Plan meinem Apple II einen
Link-Adapter zu bauen, damit ich auch mal ein paar Transputer außen
dranhängen konnte. Beim Beschaffen der Bauteile ist's geblieben, denn es
gab noch ganz andere Sachen zu basteln. Preisgünstigere.

Wir hatten einen Occam-Softie an Bord, der sich mit "Farming" und
ähnlichen Fragen beschäftigte, also Lastverteilung. Der hatte schöne
Demo-Programme mit zeitgemäßen Mandelbrötchen, wo er zeigen konnte, wie
die Algorithmen funktionieren, wenn einzelne Prozessoren ausfallen oder
Kommunikationspfade gestört sind. Denn, nicht zu vergessen, jeder
Transputer hatte 4 Links. Damit konnte man redundante Wege, also ein
Netz aufbauen. Dann wurde das Transputernetz über einen Link von der
Wirtsmaschine (Unix, OS-9, DOS-PC, in meinen Träumen Apple II mit UCSD
oder irgendwas anderem) "gefüttert" und der erste Transputer wurde zum
Aufgabenverteiler und -überwacher in einem heterogenen Netz von
Occam-sprechenden Knoten. BTW im Jahr 1987.

> Vielleicht magst Du die Liste ja mal scannen und irgendwo hochladen, das
> sind so interessante Dokumente, die oft doch bißchen untergehen.

Bevor das untergeht, hatte ich letztes Jahr ein paar Sachen gescannt und
in schöner, großer Auflösung dem Al von den Bitsavers angeboten,
abholbereit von meinem Web-Space. War mal wieder nix.

Jetzt habe ich aus diesen Scans kurz zwei Flugblätter aus dem Jahr 1987
verkleinert, aber nicht aufbereitet. Eines ist ein Überblick, was die
Firma im Jahr 1987 anbot, das zweite ist das Angebot der VMEbus-Karten
im Jahr 1987. Beides auf englisch! In deutsch gab's das auch. Jede Seite
hat 200-300kB. Viel Spaß!

www.ralf-kiefer.de/VME/PROTEUS/Flyer_e1_1987_1_small.JPG
www.ralf-kiefer.de/VME/PROTEUS/Flyer_e1_1987_2_small.JPG
www.ralf-kiefer.de/VME/PROTEUS/Flyer_e1_1987_3_small.JPG
www.ralf-kiefer.de/VME/PROTEUS/Flyer_e1_1987_4_small.JPG
www.ralf-kiefer.de/VME/PROTEUS/Products_e1_1987_1_small.JPG
www.ralf-kiefer.de/VME/PROTEUS/Products_e1_1987_2_small.JPG
www.ralf-kiefer.de/VME/PROTEUS/Products_e1_1987_3_small.JPG
www.ralf-kiefer.de/VME/PROTEUS/Products_e1_1987_4_small.JPG

Das Leiterplattenentflechtungs- und -layoutprogramm war eine
Eigenentwicklung, die auf der großen Grafik mit einem Transputer als
Grafikcontroller recht zügig lief. Also im Vergleich mit anderem, was zu
dieser Zeit auf dem Markt war. Alleine die Hardware dafür kostete fast
soviel wie ein Golf GTI zu jener Zeit.

Gruß, Ralf

[Andreas Kohlbach]

On Fri, 7 Sep 2018 22:25:53 +0200, Ralf Kiefer wrote:
>
> Andreas Kohlbach wrote:
>

>> neben der Intel 8086/8088 aus dem selben Jahr die erste
>> kommerziell erfolgreiche 32-Bit-CPU gewesen sein.
>
> *hüstel* Diese Intel-Mißgeburt als 32bit-CPU zu bezeichnen ist IMHO
> gewagt. Segmentgrenzen *grusel*

Argh! Warum dachte ich jetzt, er sei 32-Bit? Es sollte es besser
wissen. :-(

[Andreas Kohlbach]

On Sat, 8 Sep 2018 12:30:27 +0200, Hanno Foest wrote:
>
> Bei der x86 Modellreihe ist die (andauernde) Entwicklung bekannt, man
> hat es geschafft, verglichen mit dem ersten Modell geradezu absurde
> Geschwindigkeiten zu erreichen. Beim 68000 war mit dem 68060 Schluß.

Motorola ist auch schon seit 2011 tot, während Intel (und AMD) wächst und
gedeiht.

[Ralf Kiefer]

Andreas Kohlbach wrote:

> Motorola ist auch schon seit 2011 tot, während Intel (und AMD) wächst und
> gedeiht.

Die Motorola CPUs liefen jahrelang bei Freescale, jetzt NXP. Soll
heißen: Coldfire lebt.

Gruß, Ralf

[Kay Martinen]

Am 08.09.2018 um 22:13 schrieb Andreas Kohlbach:
> On Fri, 7 Sep 2018 22:25:53 +0200, Ralf Kiefer wrote:
>>
>> Andreas Kohlbach wrote:
>>
>>> neben der Intel 8086/8088 aus dem selben Jahr die erste
>>> kommerziell erfolgreiche 32-Bit-CPU gewesen sein.
>>
>> *hüstel* Diese Intel-Mißgeburt als 32bit-CPU zu bezeichnen ist IMHO
>> gewagt. Segmentgrenzen *grusel*
>
> Argh! Warum dachte ich jetzt, er sei 32-Bit? Es sollte es besser
> wissen. :-(
>

IMHO schriebst du in einem anderen Post korrekt von 80386. War's also
ein Teppfuhler?


Kay

--
Sent via SN (Eisfair-1)

[Arno Welzel]

Nils M Holm:

> Arno Welzel <use...@arnowelzel.de> wrote:
>> Andreas Kohlbach:
>>> Dann liegen zwischen 1974 und 1979 etwa 15 Jahre, wenn man (ich
>>> zumindest) die rasante Entwicklung der Hard- und Software in diesen fünf

>>> Jahren auf die heutige Zeit überträgt. 1974 war bei Mikroprozessoren
>>> 8-Bit das Ende der Fahnenstange. 1979 kamen bereits die ersten 32-Bitter
>>> auf den Markt.

>>
>> Nicht ganz - die ersten kommerziell erfolgreichen 32-Bit-CPUs gab es

>> erst ab etwa 1982 und 8-Bit-CPUs haben bis in die 1980er Jahre hinein
>> durchaus noch eine gewisse Verbreitung gehabt. Die kommerziell
>> bedeutendeneren CPUs, wie 68020 oder 80386 waren sogar erst ab 1984
>> relevant.

>
> Ach, mit den Bits, das ist so eine Sache. Schon die IBM 70x in den
> 50'er Jahren war eine 36-Bit-Archirektur. Und dann kommt es darauf
> an, was man unter CPU versteht. Wenn man sich nicht auf VLSI ("Chips")
> beschraenkt, dann ist die IBM System/360 Model 30 (1964) sicher ein
> guter Kandidat fuer die erste 32-bit CPU.

Nicht nur ein guter Kandidat - das *ist* eine 32-Bit-CPU.

Ich habe mich aber ganz bewusst auf VLSI beschränkt, weil es in dieser
Diskussion genau darum geht.


--
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[Arno Welzel]

Sebastian Barthel:

<https://upload.wikimedia.org/wikipedia/commons/2/28/XC68000.agr.jpg>

[Stefan Reuther]

Am 06.09.2018 um 10:56 schrieb Ralf Kiefer:

> Kay Martinen wrote:
>> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.
>

> In Zyklen ausgedrückt recht wenige. Wobei natürlich der 6502 (fast) alle
> anderen 8-Bitter schlägt.
>
> Letztendlich ist ein Task-Wechsel eine überschaubare Aufgabe:
> - Einleitung eines Task-Wechsels z.B. durch Ticker oder durch ein
> $sleep/$wait oder was immer das Betriebssystem vorsieht
> - Retten des Registersatzes im vorherigen Prozeßdeskriptor
> - Auswählen des nächsten Prozeßdeskriptors aus einer Liste
> - Restaurieren des Registersatzes für den nächsten Prozeß
> - Beenden des Schedulers, ggf. nur ein rts/rti o.ä.

- Umschalten des Stacks vom vorigen Prozess auf den nächsten

Und da wird es beim 6502 mit seinem fest positionierten Stack knifflig.
Z80 oder 8080 oder 8086 können den Stack frei positionieren. Aber so
kommt beim 6502 halt noch die Zeit für das Umkopieren von bis zu 256
Bytes dazu.


Stefan

[Gerrit Heitsch]

Warum sollte man den Stack umkopieren? Der 6502 hat keinen
Speicherschutz, es ist also egal.

Gerrit

[Ralf Kiefer]

Stefan Reuther wrote:

> Am 06.09.2018 um 10:56 schrieb Ralf Kiefer:
> > Kay Martinen wrote:
> >> Wie da die Taskwechsel-zeiten waren wäre mal lustig zu hören.
> >
> > In Zyklen ausgedrückt recht wenige. Wobei natürlich der 6502 (fast) alle
> > anderen 8-Bitter schlägt.
> >
> > Letztendlich ist ein Task-Wechsel eine überschaubare Aufgabe:
> > - Einleitung eines Task-Wechsels z.B. durch Ticker oder durch ein
> > $sleep/$wait oder was immer das Betriebssystem vorsieht
> > - Retten des Registersatzes im vorherigen Prozeßdeskriptor
> > - Auswählen des nächsten Prozeßdeskriptors aus einer Liste
> > - Restaurieren des Registersatzes für den nächsten Prozeß
> > - Beenden des Schedulers, ggf. nur ein rts/rti o.ä.
>
> - Umschalten des Stacks vom vorigen Prozess auf den nächsten

Mist :-) Da war noch was. Ich würde das bei einem 6502 sowieso auf sehr
wenige Prozesse beschränken und dann die Stack-Bereiche fest zuweisen.
Aus dem Grund, den Du nennst: das Verwalten des Stack.

Das ist eine Einschränkung beim Programmieren der einzelnen Tasks im
6502, läßt sich aber aufgrund der anderen Grenzen des Prozessors
verkraften, IMHO. Hochsprachen mit intensiver Stack-Nutzung gibt's dann
nicht.

> Z80 oder 8080 oder 8086 können den Stack frei positionieren.

Der 65802 und 65816 können das im 16bit-Modus auch, selbst wenn sie nur
mit 64kB Adreßraum arbeiten.

Beim Design vom 68000 hat man darauf bestens geachtet: nicht nur frei
positionierbar, sondern immer einen zweiten Stack für Interrupts.

Gruß, Ralf

[Sebastian Barthel]

Am Sat, 08 Sep 2018 21:57:09 +0200 schrieb Ralf Kiefer:

> Sebastian Barthel wrote:
>

>> Ich kannte eigentlich als einzige wirklich vollständige Maschinen in
>> diesem Zusammenhang den ATW von Atari.
>
> Der große, deutsche Hersteller von Transputer-Hardware in den späten
> 1980er Jahren war Parsytec. Die waren nahe der RWTH Aachen und dem
> Forschungszentrum Jülich und hatten in diesem Umfeld ihren Kundenkreis.
> Wir saßen in der Technologiefabrik Karlsruhe im Dunstkreis der Uni sowie
> vom Kernforschungszentrum, das nicht nur nukleare Forschung betrieb.

Nun gut, ist jetzt wohl nicht unbedingt das, wo der normale Hobbycomputer-
Anwender in irgendeiner Form Zugang hatte.

> Ich selbst hatte seinerzeit den kühnen Plan meinem Apple II einen
> Link-Adapter zu bauen, damit ich auch mal ein paar Transputer außen
> dranhängen konnte. Beim Beschaffen der Bauteile ist's geblieben, denn es
> gab noch ganz andere Sachen zu basteln. Preisgünstigere.

Na ja, wenn die Bauteile schon da waren, liegen die ja vielleicht noch
irgendwo herum und könnten noch zusammengesetzt werden.
Möglicherweise wäre das ja sogar ein tolles Retro Projekt, was man sogar
im Apple Lager verkauft bekommt, als Grafikbeschleuniger oder so. Kommt
halt drauf an, wieviele solche Transputer Chips noch in der Welt
herumflottieren und wie man sie bekommt.

> Wir hatten einen Occam-Softie an Bord, der sich mit "Farming" und
> ähnlichen Fragen beschäftigte, also Lastverteilung. Der hatte schöne
> Demo-Programme mit zeitgemäßen Mandelbrötchen, wo er zeigen konnte, wie
> die Algorithmen funktionieren, wenn einzelne Prozessoren ausfallen oder
> Kommunikationspfade gestört sind. Denn, nicht zu vergessen, jeder
> Transputer hatte 4 Links. Damit konnte man redundante Wege, also ein
> Netz aufbauen.

Das ist wirklich was Witziges, was bis heute anscheinend nirgendwo so
richtig wieder aufgetaucht ist.
Es ist aber für so eine Anwendung möglicherweise auch völlig unnötig. Da
reicht es einfach fix verkabelte "viele" Prozessoren zu haben und jedem
wird ein Häppchen vom Bild vorgeworfen.

> Bevor das untergeht, hatte ich letztes Jahr ein paar Sachen gescannt und
> in schöner, großer Auflösung dem Al von den Bitsavers angeboten,
> abholbereit von meinem Web-Space. War mal wieder nix.

Das ist schade. Immerhn wäre das so eine Stelle, wo man über so seltene
Infos am ehesten mal stolpern würde, wenn man danach sucht.

Kannst sie ja mal im Vollscanformat dem
<http://oldcomputers.dyndns.org>
anbieten. Das ist auch eine nette Sammlung, wo es thematisch
wahrscheinlich ganz gut hinpassen würde und vielleicht auch auf
Begeisterung beim "Betreiber" der Seite stößt.

> Jetzt habe ich aus diesen Scans kurz zwei Flugblätter aus dem Jahr 1987
> verkleinert, aber nicht aufbereitet. Eines ist ein Überblick, was die
> Firma im Jahr 1987 anbot, das zweite ist das Angebot der VMEbus-Karten
> im Jahr 1987. Beides auf englisch! In deutsch gab's das auch. Jede Seite
> hat 200-300kB. Viel Spaß!
>
> www.ralf-kiefer.de/VME/PROTEUS/Flyer_e1_1987_1_small.JPG

> ..._2_small.JPG, ..._3_small.JPG, ..._4_small.JPG
> www.ralf-kiefer.de/VME/PROTEUS/Products_e1_1987_1_small.JPG
> ..._2_small.JPG, ..._3_small.JPG, ..._4_small.JPG

Sehr schick !

Aber da sieht man auch schon rein an den Bilder, daß man da mit einer
heftigen Preiliste rechnen muß. Da ist ja auf jeder Einzelplatine mehr
RAM drauf als man in einen Atari/Amiga einstecken konnte.

Schönen Gruß,
SBn

[Christian Corti]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
> Ein "XC" und im Bildtitel als "Pre-release" bezeichnet. Später wurden
> die XC-Modelle als Engineering Sample bezeichnet, d.h. nicht ausgereift,
> Bugs drin, nicht für die Serie, sondern lediglich als Testexemplare für
> Hardware-Entwickler, die damit anfangen konnten ihre Boards zu

Mag sein, jedenfalls sind hier noch der eine oder andere XC68000 (oder
XC68010) :-) Klemens müßte das genauer wissen.

Christian

[Ralf Kiefer]

Sebastian Barthel wrote:

> Nun gut, ist jetzt wohl nicht unbedingt das, wo der normale Hobbycomputer-
> Anwender in irgendeiner Form Zugang hatte.

Natürlich nicht. Der Kundenkreis setzte sich aus Industriekunden und
Forschungseinrichtungen zusammen. "Endverbraucher" waren fast nie
Käufer. Ausnahme: ein paar Mitarbeiter kauften was ganz offiziell so wie
ich seinerzeit eine echte OS-9-Lizenz.


> > [Link-Adapter für Apple II]

>
> Na ja, wenn die Bauteile schon da waren, liegen die ja vielleicht noch
> irgendwo herum und könnten noch zusammengesetzt werden.

Vor etlichen Jahren hier über d.a.f.c an einen Transputer-Interessierten
weitergegeben.

> Möglicherweise wäre das ja sogar ein tolles Retro Projekt, was man sogar
> im Apple Lager verkauft bekommt, als Grafikbeschleuniger oder so. Kommt
> halt drauf an, wieviele solche Transputer Chips noch in der Welt
> herumflottieren und wie man sie bekommt.

Das ist das Problem vom Kundenkreis, siehe oben. Wenn solche Systeme
irgendwann ausgemustert werden, landen die fast immer im Schredder.
Heute noch mehr als noch vor 10Jahren, weil es eine Hysterie um Daten
gibt. Ich hatte das große Glück etliche VMEbus-Systeme "erben" zu
können.

Andrerseits kann es auch sein, daß solche Anlagen heute noch in Betrieb
sind. Ich hörte von Forschungsanlagen, die in den 1980er Jahren
aufgebaut wurden, und heute mit nur geringen Modifikationen immer noch
laufen. Die brauchen vielleicht mal Ersatzteile. Folge: VMEbus-Hardware
der 1980er Jahre wurde schon nachproduziert, und das 20 oder 30Jahre
nach dem Erstkauf.

> Das ist wirklich was Witziges, was bis heute anscheinend nirgendwo so
> richtig wieder aufgetaucht ist.

Ein ähnliches Konzept verfolgen die ganz großen Server-Anbieter heute im
Internet wie z.B. Akamai. Viel räumliche Verteilung, viel Redundanz bei
Hardware und Kommunikationswegen, gegenseitige Überwachung. Die
Anwendung ist eine andere, aber die Zielsetzung dieselbe: "Es muß
laufen. <Punkt>!"

> Es ist aber für so eine Anwendung möglicherweise auch völlig unnötig. Da
> reicht es einfach fix verkabelte "viele" Prozessoren zu haben und jedem
> wird ein Häppchen vom Bild vorgeworfen.

Genau das machte der "Master" im verteilten System. Das war damals
innovativ, da (vermutlich erstmalig) in größerem Stil Aufgaben derart
parallelisiert wurden. Mehr Rechenleistung? Mit Geld kein Problem :-)
Im kleinen Maßstab gab's einen nahezu linearen Bezug.

Nicht zu vergessen: das war um 1987 herum. MS-DOS-PCs hatten einen
80286, Mac-Anwender konnten ab Herbst den Mac II mit offenenm Bussystem
kaufen (wenn sie das Geld aufbrachten), der Atari- und Amiga-Boom begann
gerade. Viele Heimanwender hatten Apple II oder C64 zuhause.

> > Bevor das untergeht, hatte ich letztes Jahr ein paar Sachen gescannt und
> > in schöner, großer Auflösung dem Al von den Bitsavers angeboten,
> > abholbereit von meinem Web-Space. War mal wieder nix.
>
> Das ist schade. Immerhn wäre das so eine Stelle, wo man über so seltene
> Infos am ehesten mal stolpern würde, wenn man danach sucht.

Für VMEbus-Sachen ist Bitsavers die erste Anlaufstelle.

> Kannst sie ja mal im Vollscanformat dem
> <http://oldcomputers.dyndns.org>
> anbieten.

Mal schaun.


> Sehr schick !

:-)

Beim Blättern in einem alten Ordner habe ich eine nicht so tolle Kopie
eines Zeitschriftenartikel mit dem Aufhänger dieser Grafikkarte
gefunden. Aus VMEbus, Heft März 1987 (jeweils rund 400kB):
www.ralf-kiefer.de/VME/PROTEUS/VMEbus_198703_S62w.jpg
www.ralf-kiefer.de/VME/PROTEUS/VMEbus_198703_S63w.jpg
www.ralf-kiefer.de/VME/PROTEUS/VMEbus_198703_S64w.jpg

> Aber da sieht man auch schon rein an den Bilder, daß man da mit einer
> heftigen Preiliste rechnen muß. Da ist ja auf jeder Einzelplatine mehr
> RAM drauf als man in einen Atari/Amiga einstecken konnte.

Nicht unbedingt das, denn die 1Mb-DRAMs waren zu diesem Zeitpunkt sehr
teuer. Sehr schwammige Erinnerung für 1987: 30 bis 40DM pro Chip. Im
Jahr 1989 gab's bei den DRAMs noch mal eine heftige Preisspitze, als
256kb-DRAMs in Endverbraucherstückzahlen von vorherigen 7-8DM wieder auf
>15DM stiegen. An diesen Preis kann ich mich sehr gut erinnern, denn ich
brauchte zu jener Zeit über 100 Stück nur für mich und ein paar hundert
weitere für dasselbe Hobbyprojekt für Freunde.

Gruß, Ralf

[Michael van Elst]

Christian Corti <u...@reply.to> writes:

>Ralf Kiefer <R.Kiefe...@gmx.de> wrote:

>> Ein "XC" und im Bildtitel als "Pre-release" bezeichnet. Sp=E4ter wurden
>> die XC-Modelle als Engineering Sample bezeichnet, d.h. nicht ausgereift=
>,
>> Bugs drin, nicht f=FCr die Serie, sondern lediglich als Testexemplare f=
>=FCr

>> Hardware-Entwickler, die damit anfangen konnten ihre Boards zu

>Mag sein, jedenfalls sind hier noch der eine oder andere XC68000 (oder

>XC68010) :-) Klemens m=FC=DFte das genauer wissen.


Der Unterschied zwischen XC und MC ist nicht so eindeutig und hat eher
was mit der Ausbeute beim Herstellungsprozess als mit Bugs zu tun. XC
wurde auch in grösseren Mengen produziert und auch bei MC gab es noch
Bugfixes. Was davon ist jetzt "ausgereift" oder "Serie" und was nicht?
Wenn einen Bugs interessieren, dann liefert die Maskenversion eher
intereressante Aussagen als das Kürzel vor der Produktnummer.

--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."

[Gerrit Heitsch]

On 09/09/2018 05:25 PM, Michael van Elst wrote:
> Christian Corti <u...@reply.to> writes:
>
>> Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
>>> Ein "XC" und im Bildtitel als "Pre-release" bezeichnet. Sp=E4ter wurden
>>> die XC-Modelle als Engineering Sample bezeichnet, d.h. nicht ausgereift=
>> ,
>>> Bugs drin, nicht f=FCr die Serie, sondern lediglich als Testexemplare f=
>> =FCr
>>> Hardware-Entwickler, die damit anfangen konnten ihre Boards zu
>
>> Mag sein, jedenfalls sind hier noch der eine oder andere XC68000 (oder
>> XC68010) :-) Klemens m=FC=DFte das genauer wissen.
>
>
> Der Unterschied zwischen XC und MC ist nicht so eindeutig und hat eher
> was mit der Ausbeute beim Herstellungsprozess als mit Bugs zu tun. XC
> wurde auch in grösseren Mengen produziert und auch bei MC gab es noch
> Bugfixes. Was davon ist jetzt "ausgereift" oder "Serie" und was nicht?

Es gab bei Motorola auch noch die Chips mit 'PC' vor der Nummer.

So gesehen auf einem PC68040 in einem NeXT.

Gerrit

[Bernd Laengerich]

Am 09.09.2018 um 12:23 schrieb Gerrit Heitsch:

> Warum sollte man den Stack umkopieren?

Weil der Stack ohnehin sehr begrenzt ist (256 Byte). Mit Ralfs Methode
(Begrenzung der Anzahl Tasks) wäre man da performanter, aber hat dann auch die
Schwierigkeit den Stack nicht begrenzen zu können, potentiell kann also ein
Task den Stack eines anderen zerschreiben ohne daß ein Programmfehler
vorliegt. Fieserweise könnte das dann sogar der Scheduler selber sein, wenn
der Task selber den Stack bis zur Grenze ausreizt, irgendwohin muß der ja
selber den Prozessorzustand retten. Beim umkopieren kann nur der Task der
selber abgewürgt wird Schaden nehmen, was im Endeffewkt aber nicht viel besser
ist.

Bernd

[Klemens Krause]

Christian Corti wrote:
> Ralf Kiefer <R.Kiefe...@gmx.de> wrote:
...

>
> Mag sein, jedenfalls sind hier noch der eine oder andere XC68000 (oder
> XC68010) :-) Klemens müßte das genauer wissen.
>
> Christian

Aha, jetzt soll ich das wissen.
Also in der Gruschtelkiste liegt ein:
MACSS
XC68000L
R9M8015

in einem Bredboard steckt ein
MACSS
MC68000L
CC18130

und dann haben wir noch ein "unbekanntes" Flugobjekt:
SC87842L8
PH78320
auch mit Motorola-Logo, auch mit 64-Pin-DIL-Gehäuse. Nach erster
kurzer Netz-Recherche scheint das ein 68010 zu sein.

Klemens

[Ralf Kiefer]

Klemens Krause wrote:

> und dann haben wir noch ein "unbekanntes" Flugobjekt:
> SC87842L8
> PH78320
> auch mit Motorola-Logo, auch mit 64-Pin-DIL-Gehäuse. Nach erster
> kurzer Netz-Recherche scheint das ein 68010 zu sein.

Wenn Du die Fundstelle mit der Apollo DN300 meinst ... :-)

Du kannst den in einen Knubbelmac stecken, wenn Du einen mit einem
Sockel hast. Die Mac-Systeme laufen mit 68010, und Du kannst danach mit
einem der vielen Systemauskunftsprogramme wie z.B. TattleTech
nachschauen, was das Mac-Betriebssystem zum Prozesor meint.

AFAIR kann auch die KAT-Ce mit dem üblichen ROM das unterscheiden, falls
Du eher so eine zur Verfügung hast.

Oder falls Du die 15 Assemblerbefehle brauchst, mit denen die 68k-CPUs
unterschieden werden können, sach Bscheid. Irgendwo hab ich die ...

Gruß, Ralf

[Gerrit Heitsch]

Der restliche Speicher ist auch sehr begrenzt (64 KB max), da will man
sowieso kein Multitasking-OS drauf installieren.

Gerrit

[Ralf Kiefer]

Gerrit Heitsch wrote:

> Der restliche Speicher ist auch sehr begrenzt (64 KB max), da will man
> sowieso kein Multitasking-OS drauf installieren.

Kommt drauf an :-)

Es muß nicht ein Multi-tasking System sein, wo der Kernel beliebig neue
Prozesse startet und diese sich beenden können. Aber ein paar kleine,
unabhängige Prozesse für Steuerungsaufgaben kann ich mir schon
vorstellen.

Es fragt sich in solch einem Fall von Festanwendung, siehe der Begriff
EMUF, ob nicht eine andere Art des Ablaufs besser wäre.

Daß so was prinzipiell mit 64kB möglich ist, zeigte im Jahr 1979 das
OS-9 auf dem 6809, dessen erste Version tatsächlich nur mit 64kB auskam.
Erst später wurde Bankswitching integriert, so daß der 6809 mehr RAM
bekommen konnte.

Als "gepimpte" Version von CP/M gab's MP/M, auch mit nur 64kB Adreßraum.

Gruß, Ralf

[Gerrit Heitsch]

On 09/10/2018 07:01 PM, Ralf Kiefer wrote:
> Gerrit Heitsch wrote:
>
>> Der restliche Speicher ist auch sehr begrenzt (64 KB max), da will man
>> sowieso kein Multitasking-OS drauf installieren.
>
> Kommt drauf an :-)
>
> Es muß nicht ein Multi-tasking System sein, wo der Kernel beliebig neue
> Prozesse startet und diese sich beenden können. Aber ein paar kleine,
> unabhängige Prozesse für Steuerungsaufgaben kann ich mir schon
> vorstellen.

Man muss dann aber nicht unbedingt einen 6502 nehmen...

> Es fragt sich in solch einem Fall von Festanwendung, siehe der Begriff
> EMUF, ob nicht eine andere Art des Ablaufs besser wäre.

Von der Auslegung her war der 6502 für embedded Anwendungen gedacht,
also feste Aufgaben. Da störte der kleine, feste Stack nicht wirklich.
Oft wurde damals sogar Stack und Zeropage zusammengelegt wenn man nur
die 128 Bytes eines 6532 hatte.

Wenn du etwas wirklich beeindruckendes sehen willst, schau dir den
ROM-Dump des VC-1520 an. 2KB ROM, 64 bytes RAM. Darin zu finden:

- IEC-Kommunikation mit dem Host
- Ansteuerung der Hardware des 4 Farb-Plotters
- Vektorfont mit 96 Zeichen.

Nix mit 'da gibts ein neues Framework...' ;)

Gerrit

[Patrick Schaefer]

Am 08.09.2018 12:02 schrieb R.Kiefe...@gmx.de (Ralf Kiefer):

> Ein "XC" und im Bildtitel als "Pre-release" bezeichnet. Später wurden
> die XC-Modelle als Engineering Sample bezeichnet, d.h. nicht ausgereift,

> Bugs drin, nicht für die Serie, sondern lediglich als Testexemplare für

> Hardware-Entwickler, die damit anfangen konnten ihre Boards zu

> entwickeln. Die Serien-Chips der 68k-Baureihe von Motorola hatten immer
> ein vorangestelltes "MC" (und Maskennummern) aufgedruckt.

Die richtig frühen Prototypen (working samples, funktionieren halbwegs
bei Raumtemperatur) hiessen "PC". "XC" waren engineering samples, also
Teile die schon die Zielspec erfüllen sollten (auch wenn das mangels
abgeschlossener Erprobung noch nicht erwiesen war). Großkunden sind oft
und gerne mit XCs in Serie gegangen.

"MC" hiessen die Teile wenn die Entwicklung abgeschlossen war. Was nicht
zwangsläufig Fehlerfreiheit bedeutete...


Patrick

[Stefan Reuther]

Am 10.09.2018 um 11:13 schrieb Bernd Laengerich:
> Am 09.09.2018 um 12:23 schrieb Gerrit Heitsch:
>
>> Warum sollte man den Stack umkopieren?
>
> Weil der Stack ohnehin sehr begrenzt ist (256 Byte). Mit Ralfs Methode
> (Begrenzung der Anzahl Tasks) wäre man da performanter, aber hat dann
> auch die Schwierigkeit den Stack nicht begrenzen zu können, potentiell
> kann also ein Task den Stack eines anderen zerschreiben ohne daß ein
> Programmfehler vorliegt.

Das kann ja ohne Speicherschutz immer passieren.

Mit fest partitionierten Stacks kommt man z.B. auf 8 Tasks a 32 Bytes,
das kommt mir dann doch ein bissl arg wenig vor. Der 6502 glänzt ja auch
nicht mit einem riesigen Registersatz, da wird man immer mal was sichern
müssen.


Stefan

[Gerrit Heitsch]

Du hast ja auch noch die Zeropage die man schon fast als ausgelagerte
Register bezeichnen kann weil der Zugriff so schnell ist.

Gerrit

[Kay Martinen]

Am 10.09.2018 um 19:23 schrieb Gerrit Heitsch:
>
> Wenn du etwas wirklich beeindruckendes sehen willst, schau dir den
> ROM-Dump des VC-1520 an. 2KB ROM, 64 bytes RAM. Darin zu finden:
>
> - IEC-Kommunikation mit dem Host
> - Ansteuerung der Hardware des 4 Farb-Plotters
> - Vektorfont mit 96 Zeichen.

Witzig das du nicht die 1541 Floppystation erwähnst. Hat kaum mehr
Ressourcen, IEC hat die auch und wenn ich recht erinnere steuert die
einen Disckontroller an für den ihre CPU eigentlich viel zu lahm ist.
AFAIR löste man das Problem durch eine Interrupt-steuerung die dort
damit defacto zum Hauptzweck wird.

Bei anderer üblicher HW war der Interrupt eher für nebenläufiges
zwischen dem Hauptprogramm.

> Nix mit 'da gibts ein neues Framework...' ;)

Okay, bei der Floppy hat es dann ja "quasi" ein neues "Framework"
gegeben. Parallel-speeder, 1571 u.v.m. ;-)

[Andreas Kohlbach]

On Mon, 10 Sep 2018 19:01:43 +0200, Ralf Kiefer wrote:
>
> Gerrit Heitsch wrote:
>
>> Der restliche Speicher ist auch sehr begrenzt (64 KB max), da will man
>> sowieso kein Multitasking-OS drauf installieren.
>
> Kommt drauf an :-)
>
> Es muß nicht ein Multi-tasking System sein, wo der Kernel beliebig neue
> Prozesse startet und diese sich beenden können. Aber ein paar kleine,
> unabhängige Prozesse für Steuerungsaufgaben kann ich mir schon
> vorstellen.

Die kann man vielleicht mittels Interrupt laufen lassen.

Waren es beim C64 nicht die Register 788 und 789 (Dezimal), in die man
die Sprungadresse einer IR eintrug? Um das zu testen hatte ich back in
the day ein Programm geschrieben, was beim C64 einen kurzen Pieps machte,
wenn man eine Taste drückte. Wie ich es vom Bekannten mit dem ATARI XL
kannte. Das war überraschend einfach.

Nur das POKEN der Register gelang zwei von drei Mal. Erst später verstand
ich, dass BASIC zu langsam ist. Und die IR vielleicht schon angesprungen
wurde, nachdem BASIC nur erst den ersten Wert schrieb, somit der zweite
Wert noch auf eine "zufällige" Sprungadresse zeigte, was in der Regel
einen Systemabsturz nach sie zog.

[Ralf Kiefer]

Kay Martinen wrote:

> Witzig das du nicht die 1541 Floppystation erwähnst. Hat kaum mehr
> Ressourcen, IEC hat die auch und wenn ich recht erinnere steuert die
> einen Disckontroller an für den ihre CPU eigentlich viel zu lahm ist.
> AFAIR löste man das Problem durch eine Interrupt-steuerung die dort
> damit defacto zum Hauptzweck wird.

AFAIK kein Interrupt, sondern die einzige bekannte Verwendung des "Set
Overflow"-Beinchens eines 6502.


Gruß, Ralf

[Andreas Schwarz]

On Mon, 10 Sep 2018 16:45:14 -0400, Andreas Kohlbach wrote:

> On Mon, 10 Sep 2018 19:01:43 +0200, Ralf Kiefer wrote:
> >
> > Gerrit Heitsch wrote:
> >
> >> Der restliche Speicher ist auch sehr begrenzt (64 KB max), da will man
> >> sowieso kein Multitasking-OS drauf installieren.
> >
> > Kommt drauf an :-)
> >
> > Es muß nicht ein Multi-tasking System sein, wo der Kernel beliebig neue
> > Prozesse startet und diese sich beenden können. Aber ein paar kleine,
> > unabhängige Prozesse für Steuerungsaufgaben kann ich mir schon
> > vorstellen.
>
> Die kann man vielleicht mittels Interrupt laufen lassen.
>
> Waren es beim C64 nicht die Register 788 und 789 (Dezimal), in die man
> die Sprungadresse einer IR eintrug?

Das ist Adresse welche vom Kernal bei einem IRQ angesprungen wird, vorher wurden
bereits die Register gesichert. Man konnte hier etwas einhaengen und dann in
die urspruengliche IR routine springen (bzw. konformer in das, was da drin stand,
falls der Vektor schon verbogen war).

> Um das zu testen hatte ich back in
> the day ein Programm geschrieben, was beim C64 einen kurzen Pieps machte,
> wenn man eine Taste drückte. Wie ich es vom Bekannten mit dem ATARI XL
> kannte. Das war überraschend einfach.
>
> Nur das POKEN der Register gelang zwei von drei Mal. Erst später verstand
> ich, dass BASIC zu langsam ist. Und die IR vielleicht schon angesprungen
> wurde, nachdem BASIC nur erst den ersten Wert schrieb, somit der zweite
> Wert noch auf eine "zufällige" Sprungadresse zeigte, was in der Regel
> einen Systemabsturz nach sie zog.

Ich verstehe noch nicht ganz, auf was du den Vektor umgebogen hast, dort
muss doch schon ein Maschienenprogramm liegen. Dann haette man das umbiegen
auch gleich mitmachen koennen.

--

-asc

[Axel]

Am Samstag, 8. September 2018 21:57:16 UTC+2 schrieb Ralf Kiefer:
>
> Ich selbst hatte seinerzeit den kühnen Plan meinem Apple II einen
> Link-Adapter zu bauen, damit ich auch mal ein paar Transputer außen
> dranhängen konnte. Beim Beschaffen der Bauteile ist's geblieben, denn es
> gab noch ganz andere Sachen zu basteln. Preisgünstigere.

Ich hab' da mal was vorbereitet ;-) 2 TRAMs intern, extern "so viel wie geht"

Apple II - http://www.geekdot.com/category/hardware/diy-projects/diy-transputer-interfacing/t2a2 ... gibt's auch für den C64.

Zudem neue, schnelle TRAMs oder ein TRAM auf Arduino shield adapter: http://www.geekdot.com/category/hardware/diy-projects/my-own-trams/t2shield/

Ach ja, momentan steht mein Cluster bei 64 Transputern (wären wohl so ca 52k DM allein für die CPUs gewesen)... mehr sind möglich, wenn das Netzteil mitmacht (70A!)
http://www.geekdot.com/category/systems/the-cube/

Viele Grüße, Axel

[Ralf Kiefer]

Axel wrote:

> Apple II -

Mein Traum damals vor 30Jahren :-) Nur hatte ich ein paar mehr TTLs
geplant oder eher planen müssen.

> Ach ja, momentan steht mein Cluster bei 64 Transputern (wären wohl so ca
>52k DM allein für die CPUs gewesen)... mehr sind möglich, wenn das
>Netzteil mitmacht (70A!)

Schön. Allerdings sollte das Netzteil kein KO-Kriterium sein, denn Du
kannst doch die einzelnen Karten separat versorgen. Was ist eigentlich
mit Zwangskühlung bei Deinem Cube? Diese vielen Watt müssen doch
irgendwie raus aus dem Käfig.

Gruß, Ralf

[Martin Peters]

Michael van Elst schrieb:
(...)

> Der Unterschied zwischen XC und MC ist nicht so eindeutig und hat eher
> was mit der Ausbeute beim Herstellungsprozess als mit Bugs zu tun.

Ich habe grade mal ein wenig recherchiert. Bis 1983 gab es folgende
sechs Masken-Revisionen, die man funktional in 3 Gruppen einteilen kann,
siehe [1]

R9M (XC68000, mit sehr hoher WK ausschliesslich)

T6E (XC68000[2], MC68000[3])
`BF4 (?)

CC1 (MC68000, unklar, ob auch XC68000)
`DL6
`GN7

In [1] wird behauptet, die Masken-Revision R9M haette den Handelsnamen
XC68000 gehabt. In [2] wird R9M als "first set released by the vendor
for user evaluation" genannt.

Das klingt soweit auch plausibel. Auch der von Klemens genannte XC68000
ist ja ein R9M und Fotos im Netz von XC68000 sah ich bisher nur als R9M.

Wer [1] liest, bekommt auch den Eindruck, R9M waere die einzige Maske
gewesen, die als XC68000 lief, wohingegegen [2] behauptet, dass es
T6E-Revisionen gab, die XC68000 waren. Aber [3] zeigt ein Foto eines T6E
als MC68000.

Auffaellig finde ich, dass [2] zwar CC1 beschreibt, aber nicht auf
dessen in [1] erwaehnten "Vorgaenger" BF4 eingeht, der (weil er nach [1]
keine logisch funktionalen Unterschiede zu T6E aufweist) vmtl. ein Fix
von T6E ist. Wahrscheinlich war BF4 einfach extrem selten.

(...)

> Wenn einen Bugs interessieren, dann liefert die Maskenversion eher
> intereressante Aussagen als das Kürzel vor der Produktnummer.

So sieht's aus. Zumal sicher auch selektiert wurde und die Frage, ob ein
Baustein den Anforderungen der MC68000-Spec entsprach auch davon abhing,
wie gut man den Prozess im Griff hatte.

Gruss,
Martin

[1] M68000 FAMILIE, TEIL 1 Grundlagen und Architektur
Werner Hilf, Anton Nausch,
te-wi, ISBN 3-921803-16-0
[2] http://www.dtic.mil/dtic/tr/fulltext/u2/a111491.pdf
[3] http://www.cpushack.com/wp-content/uploads/2013/03/MotorolaMC68000L6-MACSS.jpg
(aus http://www.cpushack.com/2013/03/22/cpu-of-the-day-ibm-micro-370/)

[Sebastian Barthel]

Sehr krasses Zeug ! Very impressive !

Und das Apfelmännchen ist auch wirklich richtig(!) schön schnell.

Der Name könnte evtl. noch zu A2T2 geändert werden, das würde auch
vermutlich nochmal richtig viele Leute abholen.
Allerdings stand da irgendwo, daß der IIGS das vermutlich geeignetste
System sei, da würde ich sagen, daß das einfach schon deshalb nicht so
ist, weil den kaum jemand hat. Apple II dagegen, insbesondere aber C64,
sind doch noch ein wenig verbreiteter.

Dürfte auch ein paar schöne Demos geben, wenn sowas mal in die richtigen
Hände gerät.

Ansonsten: Guck mal nach dem Acorn TUBE System der alten BBC Micro
Computer (8Bit). Könnte Dir evtl. gefallen.

[Ralf Kiefer]

Sebastian Barthel wrote:

> Allerdings stand da irgendwo, daß der IIGS das vermutlich geeignetste
> System sei, da würde ich sagen, daß das einfach schon deshalb nicht so
> ist, weil den kaum jemand hat. Apple II dagegen, insbesondere aber C64,
> sind doch noch ein wenig verbreiteter.

Der Apple IIgs ist in Deutschland selten, denn hier kauften die
Heimanwender zu dieser Zeit eher Atari oder Amiga. Dagegen in den USA
gibt's recht viele IIgs, auch heute noch. Die letzte Baureihe vom IIe,
den Platinum mit dem integrierten Ziffernblock, gab's daher in Europa
offiziell gar nicht mehr.

Gruß, Ralf

[Kay Martinen]

So weit ich mich daran erinnere musste ein eigenes Progrämmchen das über
den Interrupt-Vektor laufen soll vorher dessen Wert Sichern (vermutlich
auf dem Stack :-).

Nur noch als Vermutung weil zu lange her: Richtig gemacht müssten damit
doch auch mehrere Verkettete Progrämmchen per Interrupt laufen.

Oder ich verrenne mich da jez irgendwie. (Besser heut abend noch mal
drüber nachdenk).

[Axel]

Am Dienstag, 11. September 2018 12:53:43 UTC+2 schrieb Sebastian Barthel:

> Sehr krasses Zeug ! Very impressive !

Danke für die Blumen ;-) Ist recht einsam in meiner Ecke :*)

> Und das Apfelmännchen ist auch wirklich richtig(!) schön schnell.

Ja das rockt, was? Aber mein(e) i860er sind dann doch noch eine Ecke zorniger:
http://www.geekdot.com/putting-it-to-use/

> Der Name könnte evtl. noch zu A2T2 geändert werden, das würde auch
> vermutlich nochmal richtig viele Leute abholen.

Seid wann kommt die Wurst zum Hund?! :-D
Nee, im Ernst: Ich stehe halt auf der Transputer Seite, daher werden Transputer and Dinge angeschlossen und nicht andersherum...
Aber Traffic habe ich schon genug (gehabt). Es gab mal div. Posts auf A2 pages, und verkauft habe ich auch so ~10 stk. Alle schworen, etwas dafür zu programmieren... bis jetzt kam nix zurück.

> Allerdings stand da irgendwo, daß der IIGS das vermutlich geeignetste
> System sei, da würde ich sagen, daß das einfach schon deshalb nicht so
> ist, weil den kaum jemand hat. Apple II dagegen, insbesondere aber C64,
> sind doch noch ein wenig verbreiteter.

Geeignet(er) deshalb, weil mehr Farben, OS 6.x etc. Aber ein Apple II(+/e) tut auch wunderbar mit der T2A2... von C64 Usern kamen übrigens genau Null Anfragen, daher gibt es auch (noch) nur den Prototypen.

> Dürfte auch ein paar schöne Demos geben, wenn sowas mal in die richtigen Hände gerät.

Der vergleichsweise langsame Bus beider Systeme ist da meist ein Hindernis. Irgendwann muss der Transputer ja mal seine Daten ausspucken.

> Ansonsten: Guck mal nach dem Acorn TUBE System der alten BBC Micro
> Computer (8Bit). Könnte Dir evtl. gefallen.

Klar kenn ich die TUBE. Meine Wurzeln liegen ja (auch) bei Acorn, wenn auch mehr Archimedes... und bisher waren mir die B's und Master einfach immer zu teuer.
Toll wäre ein T2tube aber auf jeden Fall - und so schön durch-und-durch Britisch :-P

[Gerrit Heitsch]

On 09/10/2018 10:34 PM, Kay Martinen wrote:
> Am 10.09.2018 um 19:23 schrieb Gerrit Heitsch:
>>
>> Wenn du etwas wirklich beeindruckendes sehen willst, schau dir den
>> ROM-Dump des VC-1520 an. 2KB ROM, 64 bytes RAM. Darin zu finden:
>>
>> - IEC-Kommunikation mit dem Host
>> - Ansteuerung der Hardware des 4 Farb-Plotters
>> - Vektorfont mit 96 Zeichen.
>
> Witzig das du nicht die 1541 Floppystation erwähnst. Hat kaum mehr
> Ressourcen, IEC hat die auch und wenn ich recht erinnere steuert die
> einen Disckontroller an für den ihre CPU eigentlich viel zu lahm ist.
> AFAIR löste man das Problem durch eine Interrupt-steuerung die dort
> damit defacto zum Hauptzweck wird.

Also die 1541 passt da eher nicht so gut... Denn die hat 16 KB ROM und 2
KB RAM. Das Lesen der Bytes erfolgt auch nicht via IRQ sondern via des
Set-Overflow-Pins am 6502. Der wartet in einer engen Schleife
(Sprungvefehl auf sich selbst) und der extern gesetzte Overflow befreit
ihn daraus. Ist schneller als ein IRQ.

Gerrit

[Gerrit Heitsch]

Und mir ist schon ein 6502 in einem SX-64 untergekommen bei dem genau
dieser Eingang defekt war.

Gerrit

[Christian Corti]

Martin Peters <martin...@news.uni-stuttgart.de> wrote:
> Ich habe grade mal ein wenig recherchiert. Bis 1983 gab es folgende

Hut ab!

Christian

[Erik Heinz]

* Gerrit Heitsch wrote:
>
> Also die 1541 passt da eher nicht so gut... Denn die hat 16 KB ROM und 2
> KB RAM. Das Lesen der Bytes erfolgt auch nicht via IRQ sondern via des
> Set-Overflow-Pins am 6502. Der wartet in einer engen Schleife
> (Sprungvefehl auf sich selbst) und der extern gesetzte Overflow befreit
> ihn daraus. Ist schneller als ein IRQ.

Und trotzdem waren da noch jede Menge Reserven. Schnellader konnten durch
bloßen temporären Austausch der Software das Lesen inclusive Übertragung
über den seriellen Bus bis zu 10fach beschleunigen. Schreiben bis zu 4fach,
wenn ich mich recht erinnere.

Gruß,
Erik

[Gerrit Heitsch]

Ja, aber die liefen wenn die Daten schon im Puffer waren. Obiger Trick
lief wenn die Floppy die Daten in den Puffer gelesen hat.

Ansonsten...:

https://www.pagetable.com/?p=656

Viel Spass beim Lesen und Verstehen des Codes.

Gerrit

[Sebastian Barthel]

Am Tue, 11 Sep 2018 13:34:56 +0200 schrieb Kay Martinen:

> Am 10.09.2018 um 23:48 schrieb Andreas Schwarz:
>> On Mon, 10 Sep 2018 16:45:14 -0400, Andreas Kohlbach wrote:
>>
>>> On Mon, 10 Sep 2018 19:01:43 +0200, Ralf Kiefer wrote:
>>>>
>>>> Gerrit Heitsch wrote:
>>>>
>>>>> Der restliche Speicher ist auch sehr begrenzt (64 KB max), da will
>>>>> man sowieso kein Multitasking-OS drauf installieren.
>>>>
>>>> Kommt drauf an :-)
>>>>
>>>> Es muß nicht ein Multi-tasking System sein, wo der Kernel beliebig
>>>> neue Prozesse startet und diese sich beenden können. Aber ein paar
>>>> kleine, unabhängige Prozesse für Steuerungsaufgaben kann ich mir
>>>> schon vorstellen.
>>>
>>> Die kann man vielleicht mittels Interrupt laufen lassen.
>>>
>>> Waren es beim C64 nicht die Register 788 und 789 (Dezimal), in die man
>>> die Sprungadresse einer IR eintrug?
>>
>> Das ist Adresse welche vom Kernal bei einem IRQ angesprungen wird,
>> vorher wurden bereits die Register gesichert. Man konnte hier etwas
>> einhaengen und dann in die urspruengliche IR routine springen (bzw.
>> konformer in das, was da drin stand,
>> falls der Vektor schon verbogen war).
>>
>>
>>> Um das zu testen hatte ich back in the day ein Programm geschrieben,
>>> was beim C64 einen kurzen Pieps machte, wenn man eine Taste drückte.

>>> ... Erst später

>>> verstand ich, dass BASIC zu langsam ist. Und die IR vielleicht schon
>>> angesprungen wurde, nachdem BASIC nur erst den ersten Wert schrieb,
>>> somit der zweite Wert noch auf eine "zufällige" Sprungadresse zeigte,
>>> was in der Regel einen Systemabsturz nach sie zog.
>>
>> Ich verstehe noch nicht ganz, auf was du den Vektor umgebogen hast,
>> dort muss doch schon ein Maschienenprogramm liegen. Dann haette man das
>> umbiegen auch gleich mitmachen koennen.

Wenn er das vorher gepokt hat, sollte das dann schon da sein. Also so
eine DATA Zeile, die nach $5000 geschrieben wird und wo am Ende der
Rücksprung dazukommt, was einmal kurz den Ton an macht.

> So weit ich mich daran erinnere musste ein eigenes Progrämmchen das über
> den Interrupt-Vektor laufen soll vorher dessen Wert Sichern (vermutlich
> auf dem Stack :-).

Nicht zwangsläufig.
Der "normale" Modus war wohl eher das man den Rücksprung direkt hinten an
die eigenen Routinen als JMP angehängt hat. ( JMP $EA31 (?))

> Nur noch als Vermutung weil zu lange her: Richtig gemacht müssten damit
> doch auch mehrere Verkettete Progrämmchen per Interrupt laufen.
>
> Oder ich verrenne mich da jez irgendwie. (Besser heut abend noch mal
> drüber nachdenk).

Prinzipiell wäre das theoretsich korrekt, aber verkettete Interrupts am
C64 - ich glaub da nicht dran, ehrlich. :)

Zudem müßte man dann die Kette von hinten auch wieder abbauen, wenn man
da zwischendrin was ändern will (oder noch eine Adresse mehr merken). Ist
also auch noch relativ unpraktisch und Zeit kostet es auch noch ohne Ende.

Was ich mir vorstellen kann, daß es Programme gab, wo der Vektor immer
schön reihum mit anderen Werten beschrieben worden ist, jede mit einem
eigenen fixen Rücksprung oder evtl. auch so, daß man eine vorhandene
Interruptroutine quasi durch vorangestellten Code erweitern konnte, den
man dann nach Wahl zuschalten konnte, der aber in der eigentlichen
Rountine wieder ankam und darüber dann auch beendet wurde.

Also sowas

.5000 Routine Zusatz
.5020 Routine IRQ
.5036 Rücksprung in den Kernel

und dann kann man mit SEI und $5000 oder $5020 nach Adresse $0314
umschalten zwischen lang und kurz.

Interessant finde ich auch immer wieder die Rasterstrahlroutinen, wo sich
innerhalb des Interrupts dann noch eine Warteschleife findet, etwa um den
Farbbalken zu bewegen. Das ist sowas, wo sich einem echten
"Systemprogrammierer" wahrscheinlich alles umdreht, wenn er es sieht.
(Glücklicherweise hatten die zu der Zeit schon ihre Unix Maschinen und
haben sich nicht mit sowas abgegeben.)

[Andreas Kohlbach]

Wohl weil ich damals nicht erkannte, dass es am langsamen BASIC lag.

[Sebastian Barthel]

Am Tue, 11 Sep 2018 04:51:19 -0700 schrieb Axel:

> Am Dienstag, 11. September 2018 12:53:43 UTC+2 schrieb Sebastian
> Barthel:

>> Und das Apfelmännchen ist auch wirklich richtig(!) schön schnell.
>
> Ja das rockt, was? Aber mein(e) i860er sind dann doch noch eine Ecke
> zorniger:
> http://www.geekdot.com/putting-it-to-use/

Nice !

Ich kann mich da noch an Rechenzeiten von 30min erinnern. Aber die Karte
da - oder gar 3 davon - waren wohl auch eher so top-notch und man mußte
außerdem noch wissen, daß es sie überhaupt gab.

> Aber Traffic habe ich schon genug (gehabt). Es gab mal div. Posts auf A2
> pages, und verkauft habe ich auch so ~10 stk. Alle schworen, etwas dafür
> zu programmieren... bis jetzt kam nix zurück.

Mal direkt zurückfragen ?

Irgendwas werden sie doch gemacht haben, wenn sie sich sowas schon
tatsächlich kaufen. Nur zum reinen Hinlegen ist das ja dann relativ
sinnfrei.

Gibt ja wahrscheinlich durchaus noch ein paar sehr nette Sachen, die
damit prima gehen müßte. Mir würde so spontan dieses eindrückliche Demo
von SUN mit dem Wegsuchen im Labyrinth einfallen, da müßte man deutlich
was sehen. Oder Game of Live in Sektoren. Oder Grafikwandler zeilenweise.

Vielleicht bringt es ja auch was, mit dem Teil mal an einer "Ausstellung"
teilzunehmen und da einen Programmierwettbewerb auszuschreiben, mit
Publikumswertung und kleinem Preis. So bißchen wie die FORTH Wettbwerbe,
die da immer ganz beliebt zu sein scheinen.

>> Allerdings stand da irgendwo, daß der IIGS das vermutlich geeignetste
>> System sei, da würde ich sagen, daß das einfach schon deshalb nicht so
>> ist, weil den kaum jemand hat. Apple II dagegen, insbesondere aber C64,
>> sind doch noch ein wenig verbreiteter.
>
> Geeignet(er) deshalb, weil mehr Farben, OS 6.x etc. Aber ein Apple
> II(+/e) tut auch wunderbar mit der T2A2... von C64 Usern kamen übrigens
> genau Null Anfragen, daher gibt es auch (noch) nur den Prototypen.

Das ist eigentlich erstaunlich, weil von da ja durchaus immer noch Demos
kommen, die noch mal ein Tick besser sind als 5 Jahre zuvor.
Und in einer "Wild-Competition" hat man ja eigentlich mit einem halbwegs
ansehnlichen Demo und einem Transputerboard wahrscheinlich schon wegen
dem Coolnessfaktor fast von vornherein gewonnen.

>> Dürfte auch ein paar schöne Demos geben, wenn sowas mal in die
>> richtigen Hände gerät.
>
> Der vergleichsweise langsame Bus beider Systeme ist da meist ein
> Hindernis. Irgendwann muss der Transputer ja mal seine Daten ausspucken.

Kommt halt drauf an was gemacht wird. Aber prinzipiell ist das ja
anscheinend DAS Problem an Rechnern, seit Lochbandzeiten. Deshalb macht
die Natur das ja auch überall völlig anders - hochparallel und jede
Datenleitung auf Maximium und sie gibt nur das bereits fertige Ergebnis
weiter.

>> Ansonsten: Guck mal nach dem Acorn TUBE System der alten BBC Micro
>> Computer (8Bit). Könnte Dir evtl. gefallen.
>
> Klar kenn ich die TUBE. Meine Wurzeln liegen ja (auch) bei Acorn, wenn
> auch mehr Archimedes... und bisher waren mir die B's und Master einfach
> immer zu teuer.
> Toll wäre ein T2tube aber auf jeden Fall - und so schön durch-und-durch
> Britisch :-P

Witzig. Ich mag den auch sehr, den Archimedes.

BBC's werden aber bestimmt nicht mehr billiger. Und so wie es aussieht,
ist jetzt noch eine gute Gelegenheit einen von der Insel direkt zu
beschaffen - wenn die Herrschaften sich dann ganz auf ihr Königreich
besonnen haben, wird das bestimmt nicht einfacher (Zoll usf).

Wenn Du magst, kannst Du auch mal bei windfall.nl vorbeischauen, der hat
(te) da bißchen modernere Hardware zum Thema TUBE.


Schönen Gruß,
SBn

[Andreas Kohlbach]

On Tue, 11 Sep 2018 19:20:48 +0000 (UTC), Sebastian Barthel wrote:
>
> Am Tue, 11 Sep 2018 13:34:56 +0200 schrieb Kay Martinen:
>
>> Am 10.09.2018 um 23:48 schrieb Andreas Schwarz:
>>> On Mon, 10 Sep 2018 16:45:14 -0400, Andreas Kohlbach wrote:
>>>
>>>> Um das zu testen hatte ich back in the day ein Programm geschrieben,
>>>> was beim C64 einen kurzen Pieps machte, wenn man eine Taste drückte.
>>>> ... Erst später
>>>> verstand ich, dass BASIC zu langsam ist. Und die IR vielleicht schon
>>>> angesprungen wurde, nachdem BASIC nur erst den ersten Wert schrieb,
>>>> somit der zweite Wert noch auf eine "zufällige" Sprungadresse zeigte,
>>>> was in der Regel einen Systemabsturz nach sie zog.
>>>
>>> Ich verstehe noch nicht ganz, auf was du den Vektor umgebogen hast,
>>> dort muss doch schon ein Maschienenprogramm liegen. Dann haette man das
>>> umbiegen auch gleich mitmachen koennen.
>
> Wenn er das vorher gepokt hat, sollte das dann schon da sein. Also so
> eine DATA Zeile, die nach $5000 geschrieben wird und wo am Ende der
> Rücksprung dazukommt, was einmal kurz den Ton an macht.

Da standen ja andere (default) Werte drin. Wenn ich also meine Routine in
49152 hatte und dann

POKE 788,0:POKE 789,192

machte, stand ggf. nur 0 in 788 aber eine andere Zahl als 192 in 789,
wenn er zwischendurch den IRQ triggerte. Nachgeschaut, es steht
Hexadezimal EA und FE jeweils drin. Da sollte 234 und 254 in Dezimal
sein. Dort finde ich:

.C:faec B6 F0 LDX $F0,Y
.C:faee 4B A2 ASR #$A2
.C:faf0 3D E4 9E AND $9EE4,X
.C:faf3 90 3E BCC $FB33
.C:faf5 A6 9E LDX $9E
.C:faf7 A5 AD LDA $AD
.C:faf9 9D 01 01 STA $0101,X
.C:fafc A5 AC LDA $AC
.C:fafe 9D 00 01 STA $0100,X
.C:fb01 E8 INX
.C:fb02 E8 INX
.C:fb03 86 9E STX $9E
.C:fb05 4C 3A FB JMP $FB3A
.C:fb08 A6 9F LDX $9F
.C:fb0a E4 9E CPX $9E
.C:fb0c F0 35 BEQ $FB43
.C:fb0e A5 AC LDA $AC
.C:fb10 DD 00 01 CMP $0100,X
.C:fb13 D0 2E BNE $FB43

[...]

>> So weit ich mich daran erinnere musste ein eigenes Progrämmchen das über
>> den Interrupt-Vektor laufen soll vorher dessen Wert Sichern (vermutlich
>> auf dem Stack :-).
>
> Nicht zwangsläufig.
> Der "normale" Modus war wohl eher das man den Rücksprung direkt hinten an
> die eigenen Routinen als JMP angehängt hat. ( JMP $EA31 (?))

Ich hatte IIRC auch nie gesichert.

[...]

[Sebastian Barthel]

Am Tue, 11 Sep 2018 13:17:39 +0200 schrieb Ralf Kiefer:

> Sebastian Barthel wrote:
>
>> Allerdings stand da irgendwo, daß der IIGS das vermutlich geeignetste
>> System sei, da würde ich sagen, daß das einfach schon deshalb nicht so
>> ist, weil den kaum jemand hat.
>

> Der Apple IIgs ist in Deutschland selten, denn hier kauften die
> Heimanwender zu dieser Zeit eher Atari oder Amiga. Dagegen in den USA
> gibt's recht viele IIgs, auch heute noch. Die letzte Baureihe vom IIe,
> den Platinum mit dem integrierten Ziffernblock, gab's daher in Europa
> offiziell gar nicht mehr.

War auch durchaus ein schönes Gerät. Habe das sogar schonmal "probieren"
können. Aber bei 1500DM für einen Apple II mit bißchen Upgrade und
schönen Auflösungen (GS) oder 1000DM für einen Amiga oder Atari muß man
schon Apple Liebhaber sein, um sich dann statt eines 32Bit(-artigen)
Geräts ein 16Bit Maschinchen ohne die Möglichkeit zu (R...)Kopien
hinzustellen. Also im Rahmen der europäischen und v.a. deutschen
Gegebenheiten durchaus nachvollziehbar.

Schönen Gruß,
SBn

[Ralf Kiefer]

Martin Peters wrote:

> Ich habe grade mal ein wenig recherchiert.

Danke für diese nützliche Recherche.


> `GN7

Diese Maskennummer kommt mir bekannt vor. Ich habe dazu "spontan" mal
nachgeschaut: den hatten typischerweise die Macs der Anfangszeit drauf.
Und die fand ich mit Datecodes deutlich über 1983 hinaus. Außerdem hat
Motorola die in Plastik- und in Keramik-Gehäuse eingepackt.


Gruß, Ralf

[Ralf Kiefer]

Braucht der auch diese Funktion?

Gruß, Ralf

[Sebastian Barthel]

Am Tue, 11 Sep 2018 15:57:04 -0400 schrieb Andreas Kohlbach:

> On Tue, 11 Sep 2018 19:20:48 +0000 (UTC), Sebastian Barthel wrote:
>>
>> Am Tue, 11 Sep 2018 13:34:56 +0200 schrieb Kay Martinen:
>>
>>> Am 10.09.2018 um 23:48 schrieb Andreas Schwarz:
>>>> On Mon, 10 Sep 2018 16:45:14 -0400, Andreas Kohlbach wrote:
>>>>
>>>>> Um das zu testen hatte ich back in the day ein Programm geschrieben,
>>>>> was beim C64 einen kurzen Pieps machte, wenn man eine Taste drückte.
>>>>> ... Erst später verstand ich, dass BASIC zu langsam ist. Und die IR
>>>>> vielleicht schon angesprungen wurde, nachdem BASIC nur erst den
>>>>> ersten Wert schrieb, somit der zweite Wert noch auf eine "zufällige"
>>>>> Sprungadresse zeigte,
>>>>> was in der Regel einen Systemabsturz nach sie zog.
>>>>
>>>> Ich verstehe noch nicht ganz, auf was du den Vektor umgebogen hast,
>>>> dort muss doch schon ein Maschienenprogramm liegen. Dann haette man
>>>> das umbiegen auch gleich mitmachen koennen.
>>
>> Wenn er das vorher gepokt hat, sollte das dann schon da sein. Also so
>> eine DATA Zeile, die nach $5000 geschrieben wird und wo am Ende der
>> Rücksprung dazukommt, was einmal kurz den Ton an macht.
>
> Da standen ja andere (default) Werte drin. Wenn ich also meine Routine
> in 49152 hatte und dann
>
> POKE 788,0:POKE 789,192
>
> machte, stand ggf. nur 0 in 788 aber eine andere Zahl als 192 in 789,
> wenn er zwischendurch den IRQ triggerte.

Ja, deshalb steht in dem Buch 64intern (auf Seite 366) auch folgendes:

" ... Zu beachten ist, daß vor dem Ändern dieses Vektors das Auslösen
einer Unterbrechung durch den Assembler-Befehl SEI verhindert werden muß,
damit nicht die Gefahr besteht, daß der Prozessor schon nach Ändern von
nur einem Byte dieses Zeigers versucht, in eine Interruptroutine zu
verzweigen. ..."

Aber irgendwie sind das wahrscheinlich genau solche Sätze, die man als
Erstleser einfach mal überliest (Thema Didaktik!), weil man damit einfach
nichts anfangen kann, und wenn das dann nie wieder irgendwo thematisiert
wird, bleibt so ein IRQ Programm eine völlig unverständliche Sache, weils
dann nie funktioniert.

> Nachgeschaut, es steht
> Hexadezimal EA und FE jeweils drin. Da sollte 234 und 254 in Dezimal
> sein. Dort finde ich:
>
> .C:faec B6 F0 LDX $F0,Y
> .C:faee 4B A2 ASR #$A2
> .C:faf0 3D E4 9E AND $9EE4,X
> .C:faf3 90 3E BCC $FB33
> .C:faf5 A6 9E LDX $9E
> .C:faf7 A5 AD LDA $AD
> .C:faf9 9D 01 01 STA $0101,X
> .C:fafc A5 AC LDA $AC
> .C:fafe 9D 00 01 STA $0100,X
> .C:fb01 E8 INX
> .C:fb02 E8 INX
> .C:fb03 86 9E STX $9E
> .C:fb05 4C 3A FB JMP $FB3A
> .C:fb08 A6 9F LDX $9F
> .C:fb0a E4 9E CPX $9E
> .C:fb0c F0 35 BEQ $FB43
> .C:fb0e A5 AC LDA $AC
> .C:fb10 DD 00 01 CMP $0100,X
> .C:fb13 D0 2E BNE $FB43
>
> [...]

Also da stimmt irgendwas mit der Adresse nicht.

Zum einen bin ich mir bei dem Rücksprung ($EA31) sicher und zweitens ist
das Listing hier erst ab $FAF3 in einem "normalen" Lesemodus - sagt
zumindest das ROM Listing.

>>> So weit ich mich daran erinnere musste ein eigenes Progrämmchen das
>>> über den Interrupt-Vektor laufen soll vorher dessen Wert Sichern
>>> (vermutlich auf dem Stack :-).
>>
>> Nicht zwangsläufig.
>> Der "normale" Modus war wohl eher das man den Rücksprung direkt hinten
>> an die eigenen Routinen als JMP angehängt hat. ( JMP $EA31 (?))
>
> Ich hatte IIRC auch nie gesichert.

Wozu auch, wenn man den Rechner nach Abschluß einfach per Resetknopf
wieder flott macht.

Aber eine interessante Idee ist das trotzdem mit den verschiedenen IRQ
Routinen beim C64. Man könnte die dann auch noch durchwechseln, so ala
"Scheduler im Interrupt" für Interruptroutinen. Nur geht das auch
einfacher.


VG, SBn

[Gerrit Heitsch]

Ja, denn der SX-64 ist eben eine Kombination aus C64, Monitor und 1541
in einem Gehäuse, natürlich auf getrennten Platinen. Es gibt auch
Verrückte, die es geschafft haben dort eine zweite 1541 einzubauen (also
Laufwerk und Platine!), so wurde aus dem SX-64 ein DX-64. :)

Gerrit

[Kay Martinen]

Am 12.09.2018 um 17:00 schrieb Gerrit Heitsch:
> On 09/12/2018 12:11 AM, Ralf Kiefer wrote:
>> Gerrit Heitsch wrote:
>>
>>> On 09/10/2018 11:11 PM, Ralf Kiefer wrote:
>>>> AFAIK kein Interrupt, sondern die einzige bekannte Verwendung des "Set
>>>> Overflow"-Beinchens eines 6502.
>>>

IMHO wurde mit SO! aber auch eine (Interrupt)routine direkt angestoßen.
Die Alternative wäre Polling und das ist noch langsamer.

>>> Und mir ist schon ein 6502 in einem SX-64 untergekommen bei dem genau
>>> dieser Eingang defekt war.
>>
>> Braucht der auch diese Funktion?

Na, Die Floppy darin schon.

> Ja, denn der SX-64 ist eben eine Kombination aus C64, Monitor und 1541
> in einem Gehäuse, natürlich auf getrennten Platinen. Es gibt auch
> Verrückte, die es geschafft haben dort eine zweite 1541 einzubauen (also
> Laufwerk und Platine!), so wurde aus dem SX-64 ein DX-64. :)

Er bleibt; trotz der Irreführenden Namenswahl; ein 8-Bitter. ;-)

Immerhin hat man dann Auswahl. Wenn #8 nicht mehr will kann man #9
nehmen. Und wer braucht schon ein Diskettenfach IM Computer!

[Andreas Kohlbach]

On Wed, 12 Sep 2018 10:14:19 +0000 (UTC), Sebastian Barthel wrote:
>
> Am Tue, 11 Sep 2018 15:57:04 -0400 schrieb Andreas Kohlbach:
>
>> Da standen ja andere (default) Werte drin. Wenn ich also meine Routine
>> in 49152 hatte und dann
>>
>> POKE 788,0:POKE 789,192
>>
>> machte, stand ggf. nur 0 in 788 aber eine andere Zahl als 192 in 789,
>> wenn er zwischendurch den IRQ triggerte.
>
> Ja, deshalb steht in dem Buch 64intern (auf Seite 366) auch folgendes:
>
> " ... Zu beachten ist, daß vor dem Ändern dieses Vektors das Auslösen
> einer Unterbrechung durch den Assembler-Befehl SEI verhindert werden muß,
> damit nicht die Gefahr besteht, daß der Prozessor schon nach Ändern von
> nur einem Byte dieses Zeigers versucht, in eine Interruptroutine zu
> verzweigen. ..."
>
> Aber irgendwie sind das wahrscheinlich genau solche Sätze, die man als
> Erstleser einfach mal überliest (Thema Didaktik!), weil man damit einfach
> nichts anfangen kann, und wenn das dann nie wieder irgendwo thematisiert
> wird, bleibt so ein IRQ Programm eine völlig unverständliche Sache, weils
> dann nie funktioniert.

Das 64erIntern bekam ich erst sehr viel später. Ich hatte mir "meine"
Technik von jemand anderem abgeschaut, ohne sie wirklich zu verstehen.

Das habe ich im C64 Emulator VICE ausprobiert. Der Auszug ist vom in VICE
eingebautem Monitor Programm (ALT-h ruft ihn auf). Und das Listing wäre
noch sehr viel länger, dass ich es kürzte.

>>>> So weit ich mich daran erinnere musste ein eigenes Progrämmchen das
>>>> über den Interrupt-Vektor laufen soll vorher dessen Wert Sichern
>>>> (vermutlich auf dem Stack :-).
>>>
>>> Nicht zwangsläufig.
>>> Der "normale" Modus war wohl eher das man den Rücksprung direkt hinten
>>> an die eigenen Routinen als JMP angehängt hat. ( JMP $EA31 (?))
>>
>> Ich hatte IIRC auch nie gesichert.
>
> Wozu auch, wenn man den Rechner nach Abschluß einfach per Resetknopf
> wieder flott macht.

Haha!

Aber ich war kein Programmierer. Und kannte nur BASIC mehr oder weniger
schlecht. Als mein Freund mir sagte, er kennt jemanden, der "Maschine
schreibt" und ob wir den nicht mal besuchen wollen, war ich
interessiert. Und fasziniert, was er das machte, ohne es zu
verstehen. Zurück am eigenen C64 haben wir dann ein paar Sachen in
Assembler (naja, mit ein Monitorprogramm namens "Moni64", kein
ausgewachsener Assembler) gemacht, nur um zu sehen, das er oft
abstürzte. Aber wir hatten auch einen Resetknopf gebastelt... :-)

Im Laufe der Zeit dann ein Buch gefunden, was 6502 Assembler etwas näher
bringt. So hatte ich etwas gelernt, die "Piep-Routine" zu schreiben, ohne
aber den IRQ wirklich zu verstehen. Rumprobieren halt.

[Hermann Riemann]

Am 10.09.2018 um 19:23 schrieb Gerrit Heitsch:

> Wenn du etwas wirklich beeindruckendes sehen willst, schau dir den
> ROM-Dump des VC-1520 an. 2KB ROM, 64 bytes RAM. Darin zu finden:

> - IEC-Kommunikation mit dem Host
> - Ansteuerung der Hardware des 4 Farb-Plotters
> - Vektorfont mit 96 Zeichen.

Erinnert mich etwas an den
https://de.wikipedia.org/wiki/ECB85
wo ich neben den Treiber für Drucker und Plotter
auch noch einen C ähnlichen Disassembler programmierte.
Um Platz zu sparen habe ich 3 byte Arrays verwenden.
Ist da 1. Bit gesetzt, so sind die 7 bits
ein Index für ein weiteres array ( Unterprogramm)
Die ersten 32 nicht ASCII Zeichen wurden für Sonderfunktionen
wie z.B. 1 oder 2 byte Datenausgabe verwendet.

Hermann
dessen ECB85 einen Kurzschluss zwischen der EPROM Spannung
und einer Leitung daneben nicht heil überstanden hat.

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

[Martin Peters]

Sebastian Barthel schrieb:
(...)

> > machte, stand ggf. nur 0 in 788 aber eine andere Zahl als 192 in 789,
> > wenn er zwischendurch den IRQ triggerte.
>
> Ja, deshalb steht in dem Buch 64intern (auf Seite 366) auch folgendes:
>
> " ... Zu beachten ist, daß vor dem Ändern dieses Vektors das Auslösen
> einer Unterbrechung durch den Assembler-Befehl SEI verhindert werden muß,
> damit nicht die Gefahr besteht, daß der Prozessor schon nach Ändern von
> nur einem Byte dieses Zeigers versucht, in eine Interruptroutine zu
> verzweigen. ..."
>
> Aber irgendwie sind das wahrscheinlich genau solche Sätze, die man als
> Erstleser einfach mal überliest (Thema Didaktik!), weil man damit einfach
> nichts anfangen kann, und wenn das dann nie wieder irgendwo thematisiert
> wird, bleibt so ein IRQ Programm eine völlig unverständliche Sache, weils
> dann nie funktioniert.

Sowas haette man schon beim Systemdesign verhindern koennen, indem man
dort nicht nur Platz fuer einen Vektor (2 Byte), sondern fuer einen
Sprungbefehl (3 Byte) vorgesehen haette.

Das Problem ist halt, dass das Schreiben eines Vektors als atomare
Operation erfolgen muss. Das ist bei einem 16-Bit-Wert (wie einer
Adresse) auf einer 8-Bit-CPU eben mit systemspezifischen Aufwand
verbunden.

Stuende dort ein Unterprogramm, muesste man nur darauf achten, dass
zunaechst immer ein RET in die erste Adresse geschrieben wird, bevor die
Adresse des Sprungziels in die folgenden beiden Byte geschrieben wird.
Erst im letzten Schritt ersetzt man RET durch den Opcode fuer den
Sprungbefehl.

Einfach, aber wirksam :)

[Sebastian Barthel]

Am Sat, 15 Sep 2018 15:25:51 +0000 schrieb Martin Peters:

> Sebastian Barthel schrieb:
> (...)
>> > machte, stand ggf. nur 0 in 788 aber eine andere Zahl als 192 in 789,
>> > wenn er zwischendurch den IRQ triggerte.
>>
>> Ja, deshalb steht in dem Buch 64intern (auf Seite 366) auch folgendes:
>>
>> " ... Zu beachten ist, daß vor dem Ändern dieses Vektors das Auslösen
>> einer Unterbrechung durch den Assembler-Befehl SEI verhindert werden

>> muß, ...

>
> Sowas haette man schon beim Systemdesign verhindern koennen, indem man
> dort nicht nur Platz fuer einen Vektor (2 Byte), sondern fuer einen
> Sprungbefehl (3 Byte) vorgesehen haette.
>
> Das Problem ist halt, dass das Schreiben eines Vektors als atomare
> Operation erfolgen muss. Das ist bei einem 16-Bit-Wert (wie einer
> Adresse) auf einer 8-Bit-CPU eben mit systemspezifischen Aufwand
> verbunden.
>
> Stuende dort ein Unterprogramm, muesste man nur darauf achten, dass
> zunaechst immer ein RET in die erste Adresse geschrieben wird, bevor die
> Adresse des Sprungziels in die folgenden beiden Byte geschrieben wird.
> Erst im letzten Schritt ersetzt man RET durch den Opcode fuer den
> Sprungbefehl.
>
> Einfach, aber wirksam :)

Na, klingt ja plausibel. Aber ich vermute, daß dort schon mit Absicht
echte Sprünge drinstehen (Speed (keine Rücksprungadresse merken)). Zudem
unterscheidet es sich vom Handling selbst auch nicht so wesentlich; ob
man nun SEI / CLI macht (wenn das Flag sowieso schon da ist) oder so ein
RET (RTS) überschreibt, das macht jetzt nicht soviel Unterschied.
Allerdings ist es so eine Konstruktion, über die man lange grübeln kann,
wenn man sie nicht selbst gebaut hat (self-modifying code). Ist bißchen
wie ein "Demo-Trick". Natürlich ein sehr cooler, insbesondere, wenn man
das an mehreren Stellen nebeneinander macht, quasi so als
Freischalteoption für Extrafunktionen.

Schönen Gruß, SBn

[Kay Martinen]

Am 11.09.2018 um 21:11 schrieb Erik Heinz:
> * Gerrit Heitsch wrote:
>>
>> Also die 1541 passt da eher nicht so gut... Denn die hat 16 KB ROM und 2
>> KB RAM. Das Lesen der Bytes erfolgt auch nicht via IRQ sondern via des
>> Set-Overflow-Pins am 6502. Der wartet in einer engen Schleife
>> (Sprungvefehl auf sich selbst) und der extern gesetzte Overflow befreit
>> ihn daraus. Ist schneller als ein IRQ.

Ja, die Details sind mir entfallen aber es muß schneller gewesen sein
als ein IRQ denn das hatte ich so in Erinnerung. Der SO Eingang ist auch
Low-Aktiv wenn ich recht erinnere.

> Und trotzdem waren da noch jede Menge Reserven. Schnellader konnten durch
> bloßen temporären Austausch der Software das Lesen inclusive Übertragung
> über den seriellen Bus bis zu 10fach beschleunigen. Schreiben bis zu 4fach,
> wenn ich mich recht erinnere.

Oben ging es aber um die Übertragung innerhalb der Floppystation
zwischen Diskcontroller und CPU. Die Schnellader wirkten sich m.E. nur
auf dem IEC-Bus zum Hostcomputer aus. Da gab es in der Tat noch
reserven. Ich hab jedenfalls noch nie gehört das auch die Übertragung
zum Diskcontroller schneller gemacht wurde. Das die; so wie sie war; eh
am Limit arbeitet dagegen schon.

[Sebastian Barthel]

Am Mon, 10 Sep 2018 23:57:13 -0700 schrieb Axel:

> Am Samstag, 8. September 2018 21:57:16 UTC+2 schrieb Ralf Kiefer:
>>
>> Ich selbst hatte seinerzeit den kühnen Plan meinem Apple II einen
>> Link-Adapter zu bauen, damit ich auch mal ein paar Transputer außen
>> dranhängen konnte.

> Ich hab' da mal was vorbereitet ;-) 2 TRAMs intern, extern "so viel wie
> geht"
>
> Apple II -
> http://www.geekdot.com/category/hardware/diy-projects/diy-transputer-
interfacing/t2a2

> ... gibt's auch für den C64. ...


Habe hier gerade noch einen schönen - wenn auch nicht von der
Bildqualität - Videobeitrag dazu gefunden

https://www.youtube.com/watch?v=Bn35IbEcEMM

Vielleicht so als lustiges "History"-Detail ganz interessant.
Ist aus dem BBC Computer Education Projekt.

[Andreas Schwarz]

On Sat, 15 Sep 2018 15:25:51 +0000 (UTC), Martin Peters wrote:

> Sowas haette man schon beim Systemdesign verhindern koennen, indem man
> dort nicht nur Platz fuer einen Vektor (2 Byte), sondern fuer einen
> Sprungbefehl (3 Byte) vorgesehen haette.
>
> Das Problem ist halt, dass das Schreiben eines Vektors als atomare
> Operation erfolgen muss. Das ist bei einem 16-Bit-Wert (wie einer
> Adresse) auf einer 8-Bit-CPU eben mit systemspezifischen Aufwand
> verbunden.
>
> Stuende dort ein Unterprogramm, muesste man nur darauf achten, dass
> zunaechst immer ein RET in die erste Adresse geschrieben wird, bevor die
> Adresse des Sprungziels in die folgenden beiden Byte geschrieben wird.
> Erst im letzten Schritt ersetzt man RET durch den Opcode fuer den
> Sprungbefehl.
>
> Einfach, aber wirksam :)

Fuer den Fall, dass der Smiley das Ganze jetzt nicht als ironischen Beitrag
kennzeichen sollte.

Das waere ein fuerchterlicher Overkill, als ob da nur eine einziger Vektor
stehen wuerde, die ganze (extended) Zeorpage ist voll von Zeigern. In
Zeiten in denen jedes Byte kostbar war, waere sowas ein teures Zugestaendnis,
fuer einen Anwendungsfall, welcher eine absolute Ausnahme darstellt.

Weiterhin waere das eine ziemliche Design Katastrophe, in diesem Bereich
steht kein Maschinencode, es ist fuer Zeiger, Buffer, u.ae. gedacht.
Selbstmodifizierenden Code per Design vorzusehen, ist jetzt auch nicht
so der Hit.

Mein ironischer Gegenvorschlag, in der Regel steht dort ($314,$315)
ein Verweis auf $EA31 (die kernal IRQ Routine), lege deine (der OP)
IRQ Routine doch einfach nach $C031, dann brauchst du nur ein Byte
zu aendern (was du dann auch in Basic umpoken kannst). 8)

--

-asc