Beiträge von Microprofessor

Ob TRS-DOS tatsächlich etwas mit DOS oder CP/M zu tun hat, bin ich mir nicht sicher: http://en.wikipedia.org/wiki/TRS-DOS

Hier findet man Genaueres: http://www.mdutra.com/vdisk

Von beidem habe ich noch nie gehört. Kannst du mir näheres verraten?

Hallo,

vor einiger Zeit habe ich nen TRS-80/100 mit 3,5-Zoll-Diskettenlaufwerk ersteigert. Mit dem Laufwerk kann ich jedoch so lange nix anfangen, bis ich eine 3,5-Zoll-TRS-DOS-Diskette finde oder herausfinde, wie ich mir selbst eine herstellen kann.

Weiß jemand weiter?

Danke!
Stefan

Ist ja gut. War eine Fehleinschätzung aufgrund meiner hiesigen Forumserfahrung. (Ich hab natürlich auch gute Apple-II-Tipps bekommen.) Beim nächsten mal bin ich ausgewogener.

So hat er/es sich auf dem VDFe allerdings dargestellt.

Neumodischer Schnickschnack! [Blockierte Grafik: http://www.cheesebuerger.de/images/smilie/figuren/c010.gif]

Zitat von Kangaroo MusiQue

Maxam
Protext
Soundtrakker 128K
Crime 1.7

Hab ich alle außer den Soundtracker (den hätte ich auch gern). Den Protext hab ich sogar doppelt.

Wir können tauschen: Hast du ein nettes ROM im Angebot? Ich würde mich z.B. über nen Disassembler oder nen BASIC-Compiler sehr freuen.

Danke schon mal!

Ich mache mich nachher mal daran, die mir bekannten Geräte zu listen. Am besten wird es sein, das alphabetisch nach Herstellernamen zu tun und dann darunter die jeweiligen Rechner zu subsummieren. Ich würden den Beitrag dann jeweils um Neuzugänge ergänzen (korrigieren) - vorausgesetzt, man kann hier Beiträge bis in alle Ewigkeit korrigieren.

Stefan
(der seinen Nickname geändert hat )

Hallo,

könnt ihr mir helfen, hier so viele Namen von 8-Bit-Computern mit Z80/Z80A/Z80B/Z80H-Prozessoren zusammenzutragen, wie es geht? Bei Thomas Scherrer gibt es eine Übersicht, die jedoch keinesfalls vollständig ist. Gibt es woanders vollständigere Listen mit Rechnern auf Zilog-Basis oder mit Zilog-Teil-Infrastruktur (Commodore 128).

Ich suche sowohl die Namen von Originalcomputern als auch von Clones (auch mit U880-Prozessor), Einplatinencomputern (etwa "LC80" oder "Mikrorprofessor") und wichtige Z80-Karten für andere Rechner (z.B. Apple II). Die Systeme sollten käuflich zu erwerben (gewesen) sein - oder bekanntere Bastelprojekte (etwa der "NDR-Klein-Computer").

Wenn es möglich ist, mit einem Link zu einer Infoseite (kann ich aber auch selbst raus suchen).

Stefan

-> http://bit.ly/Il5jjr

Hab ich schon gefunden: http://cpcwiki.eu/imgs/2/27/ROMBO_ROM-Board_Manual.pdf

Manual gefunden: http://cpcwiki.eu/imgs/2/27/ROMBO_ROM-Board_Manual.pdf

Zitat von Grisu

Bild 18 auf der 2. Seite...

Jürgen Drews war auch da

Du bist nicht der erste und einzige, der das geglaubt hat!

Zitat von Kangaroo MusiQue

Für den Hicks bring ich mit:

1x ROMBO-Rombox

Bevor ich die nun morgen ausprobiere, frage ich vorher mal nach: Was muss ich beachten? Drin sehe ich z.B. 2 Sockel, die beklebt sind mit "BASIC" und "DOS". Gehören da besondere ROMs rein? Wofür sind die Dip-Schalter? Muss ich eine Reihenfolge beim Bestücken der Box beachten usw. usf.?

Hier mein Bericht bei Telepolis mit Links: http://www.heise.de/tp/artikel/36/36851/1.html

[Blockierte Grafik: http://i.ebayimg.com/00/s/MTIw…IY-4NBPdyKH)(b!~~60_3.JPG]

von hier!

Endlich mal gut ausgestattet und vergleichsweise günstig. Einer der letzten Z80er, der mir für mein Projekt noch gefehlt hat.

Nur eine Folge auf der VCD? Ich habe mir damals die DVD-Box kommen lassen und bin zum Ergebnis gelangt, dass Grisu wohl so eine Art Historischer Materialismus für Kinder sein muss.

Mein Bericht für Telepolis ist auch gerade weggeschickt - mit ordentlich Links zum Verein und LOAD.

Ist das selbstgebastelt? Oder gab es so etwas offiziell? :o

Hallo,

ich hab mir ein 72-Multi-Game-Modul für die Vectrex gekauft. Leider wird das nur noch als offene Platine verkauft, was zwar der Funktionalität keinen Abbruch tut, jedoch weder schön aussieht noch besonders sicher ist.

Daher suche ich ein defektes Vectrex-Modul, in dessen Hülle ich die Multi-Card einsetzen kann. Es wäre natürlich wichtig, dass nicht die Hülle defekt ist.

Ein funktionierendes Modul würde ich allerdings nicht nehmen und zerstören, um die MC darin unterzubringen!

Bitte PN an mich!

Stefan

Heute in der Post:

Links: 72-Game-Modul für die VECTREX
Rechts: Orden für meine redlichen Bemühungen im 10-Kampf

Zitat von Toast_r

Ist euch eigentlich auch aufgefallen, daß die Schleife nicht mehr mit dem Endwert durchlaufen wird ?
Der letzte ausgegebene Wert ist 9.90000001. Ein Durchlauf mit 10 findet nicht statt.

Intern wird die Schleife immer eins weiter gezählt, weil der Interpreter wahrscheinlich nur prüft, ob I schon >10 ist. Wenn du FOR I=1 to 10:NEXT eingibst und danach PRINT I, dann kommt "11" heraus.

Zitat von MaV

Im BASIC vom CPC kann man sich die interne Darstellung recht anschaulich zeigen lassen, weil die Speicheradressen der Variablen mit dem Klammeraffen vor dem Variablennamen ermittelt werden können:

Code

10 MODE 2
20 FOR i!=1 TO 10 STEP 0.1
30 a%=@i!
40 PRINT "Zahl: ";i
50 mant1%=PEEK(a%):mant2%=PEEK(a%+1)
60 mant3%=PEEK(a%+2):mant4%=PEEK(a%+3)
70 expo%=PEEK(a%+4)
80 PRINT:PRINT "Hexadezimale Darstellung:"
90 PRINT HEX$(mant4%,2);" ";HEX$(mant3%,2);" ";HEX$(mant2%,2);" ";HEX$(mant1%,2);" - Exponent: ";HEX$(expo%,2)
100 PRINT:PRINT "Binaere Darstellung:"
110 PRINT BIN$(mant4%,8);" ";BIN$(mant3%,8);" ";BIN$(mant2%,8);" ";BIN$(mant1%,8);" - Exponent: ";BIN$(expo%,8)
120 PRINT:PRINT "Formel fuer den Taschenrechner:"
130 PRINT "(0x";HEX$(mant4% OR &80,2);HEX$(mant3%,2);HEX$(mant2%,2);HEX$(mant1%,2);" * 2^32) * 2^";expo%-128
140 WHILE INKEY$="":WEND:CLS
150 NEXT i!

Alles anzeigen

Zwei Punkte dazu noch:

1) Das höchstwertige Bit in der Mantisse ist das Vorzeichenbit (0=positiv, 1=negativ). Um davon auf die richtige Darstellung der Mantisse zu kommen, ersetzt man dieses Bit immer mit einer 1. Die wird bei Fließkommazahlen eingespart und setzt dort das Vorzeichenbit, weil die erste Nachkommastelle bei der Mantisse IMMER eine 1 ist. (Manche Fließkommaformate dürften das nicht berücksichtigen, ich bin so einem noch nicht begegnet.)
Die binäre und hexadezimale Darstellung stellen also ein genaues Abbild der Zahl im Speicher dar, in der Formel für den Taschenrechner ist dieses Bit aber schon berücksichtigt.

2) Die Größe der Mantisse lässt sich im CPC nicht mehr wirklich korrekt darstellen. Deswegen habe ich mich entschieden in der Taschenrechner-Zeile die Mantisse hexadezimal anzugeben. Ihr braucht also fürs Errechnen des korrekt(er)en Ergebnisses mit dem Taschenrechner einen solchen, der Hexadezimalzahlen darstellen kann. Der Windows-Taschenrechner kann das (XP und 7 getestet).

Viel Spaß mit dem Testen!

Alles anzeigen

Großartig!

Gerade finde ich eine Interview-Aussage von Thomas E. Kurtz (dem Erfinder von BASIC) hier:

Zitat

Alle mathematischen Berechnungen werden mit Gleitkommazahlen durchgeführt. Eines der schwierigsten Konzepte für einen Einsteiger ist die Unterscheidung zwischen Integer- und Gleitkommazahlen. So gut wie alle Programmiersprachen der damaligen Zeit beugten sich der Architektur der Computerhardware bei der es Gleitkommazahlen für mathematische Berechnungen und Integerzahlen für die Effizienz gab. Indem wir alle Berechnungen mit Gleitkommazahlen durchführten, haben wir den Anwender vor den numerischen Typen geschützt. Wir mussten intern ein paar Verrenkungen anstellen, wenn ein Integer-Wert gefordert wurde (wie bei einem Array-Index) und der Anwender eine Kommazahl mitgab (Beispiel 3.1). In solchen Fällen haben wir gerundet. Ähnliche Probleme hatten wir mit dem Unterschied zwischen binären und dezimalen Nachkommastellen. Schauen Sie sich dieses Beispiel an:

FOR I=1 to 2 STEP 0.1

Die dezimale Kommazahl 0.1 ist binär eine mit unendlichen vielen Nachkommastellen. Wir mussten einen Korrekturfaktor verwenden, um die Schleife abzuschließen.

(S. 82f.)

Ich habe das Interview schon ein paar mal gelesen - seltsam, dass ich mich an diese Stelle erinnert habe.

Ja, das Locomotive-BASIC hat ganz elegante Möglichkeiten, direkt auf Maschinen-Prozeduren zuzugreifen (allein schon die Interrupt-Beeinflussung! Das findet man sonst fast nirgends.)

Ich habe hier nen Text einer Pädagogik-Kommission von Ende der 1970er-Jahre, die prüfen sollte, welche Sprache für den Einsatz in der Schule geeignet ist. Das halbe Buch handelt von BASIC und wie schlecht es für pädagogische Zwecke ist, weil es "zu problemfern und zu maschinennah" sei.

Man kann BASIC also im Prinzip nur lieben!

Zitat von jens

Auch aus der Kuriosiätenecke:
Das Omikron Basic hat keine echten Zufallszahlen, sondern geht von einer Reihe aus, die jedesmal wieder gleich abläuft, wenn ich die Erklärung eines Users richtig verstanden habe.
Er hat es festgestellt, weil er mehrere Omikron Programme in VMs hat nebeneinanderlaufen lassen, und bei zwei oder drei VMs kamen identische Ergebnisse nach keine Ahnung wie vielen Durchgängen raus.

Echte Zufallszahlen kann es aus einer deterministischen Maschine wie dem Computer sowieso nicht geben. Es wird allerdings unterschieden zwischen Zufallszahlen und Pseudozufallszahlen. Gute Programmiersprachen verwenden erstere, die zumeist aus Zeilenrücklauf-Abfragen des Videochips und anderen Werten im Prozessor gebildet werden; schlechte (wie etwa das Chipmunk-BASIC) nutzen solche Tabellen und man kann damit immer wieder dieselben Reihen von Zufallszahlen produzieren.

Könnt ihr euch daran noch erinnern: http://support.microsoft.com/kb/124345 ( http://en.wikipedia.org/wiki/Pentium_FDIV_bug )?

Kommt wohl aus derselben Schublade. Was hat es damals Spott und Hohn gegeben ...

Zitat von MaV

Mal aus der CPC-Sicht, weil ich da zufälligerweise das Format inzwischen kenne. Aber auch grundsätzlich zur Zahlendarstellung:

0,1 lässt sich binär nur sehr schlecht darstellen, ebenso 0,2.

Die Mantisse im CPC ist vier Bytes lang, und die Umrechnung von 0,1 ergibt (,=wie gehabt im Deutschen .=Trennzeichen zur besseren Darstellung):

0,1100.1100.1100.1100.1100.1100.1100.1101

Ja, 0,1 binär ist periodisch (!). Und die letzte Stelle ist auch noch gerundet.

Der Exponent - also das 5. Byte im CPC - ist 125. Von dieser Zahl muss 128 abgezogen werden, ergibt -3)

(Mantisse als Ganzzahl) dividiert durch 2^(Anzahl der Bits in der Mantisse) * 2^(Exponent - 128):
(3435973837 / 2^32) * 2^(125-128)

Das ergibt also für die diese Zahl alleine schon einen recht hohen Fehlerfaktor. Rückgerechnet ins Dezimalsystem ist das:

0,10000000000582076609134674072266

In der Schleife wird jetzt 100 mal auf 1 die Zahl 0,1 addiert, aber eben das fehlerhaft dargestellte 0,1. Das führt irgendwann zu einem Rundungsfehler, der nicht mehr ignoriert werden kann.

WANN der Fehler auftritt hängt von der internen Genauigkeit der Fließkommazahlen ab, und davon wie gerundet wird.
Beim CPC hast du ungefähr eine Genauigkeit von 9 Dezimalstellen nach dem Komma (mal besser, mal schlechter). Andere BASICs liegen da vielleicht in etwa gleich.

Die Formatierung von Octoate zwingt BASIC anscheinend dazu, bei den Zwischenschritten jedes Mal zu runden. Was dann dazu führt, dass die Abweichung in der internen Darstellung von 0,1 nicht kumuliert.

Ein Step von 0.25 zum Beispiel muss problemlos durchlaufen, weil da auch das interne binäre Format eindeutig bleibt. Und wenn nicht, dann geh ich jede Wette ein, dass dieses BASIC dann einen Bug hat.

Alles anzeigen

GANZ HERZLICHEN DANK für die Erklärung!!

Zitat von Octoate

Interessant! Das kannte ich bisher nicht. Weiss da jemand mehr :)?

Witzig ist auch, dass die Ausgabe mit folgender Zeile einwandfrei - also ohne Rundungsfehler - funktioniert:

Code

20 PRINT USING "##.###"; i

Btw, die Variablen kann man schon als "Real" oder "Integer" definieren. So wird bei einigen Programmen aus Geschwindigkeitsgründen ein "DEFINT a-z" vorangestellt, um dem BASIC Interpreter damit zu sagen, dass alle Variablen ganzzahlig sind. Dadurch kann man noch etwas Geschwindigkeit herausholen. Genauso kann man mit "DEFREAL" Fließkommazahlen definieren.

Kann man, muss man aber nicht - das war ja eines der ursprünglichen Ziele von BASIC, als es in den 60ern gebaut wurde. (Ich schreibe gerade nen Artikel über die Geschichte der Sprache fürs nächste RETURN.)

Hallo,

gerade habe ich den Studenten vorgeführt, wie Zählschleifen in BASIC realisiert werden und bin im Emulator auf folgendes Phänomen gestoßen:

10 FOR I=1 TO 10 STEP 0.1
20 PRINT I
30 NEXT I

Die Ausgabe stimmt bis 3.7 - 3.8 wird allerdings bereits als 3.7999999999 dargestellt und so geht es auch weiter bis 8.9999999999. Dann geht es bei normal weiter bis 9.7 - als nächstes kommt dann 9.8000000001 usw.

Das selbe passiert auch im Emulator. Gibt es irgendwo Informationen über diesen Rundungsfehler? (Er hängt natürlich damit zusammen, dass in BASIC nicht zwischen INTEGER- und REAL-Zahlen unterschieden wird. Aber Assembler kennt diese Unterscheidung auch nicht! Werden also im Assembler beim Interpretieren von BASIC alle Variablen intern als REAL-Zahlen behandelt?)

S.