Sie sind nicht angemeldet.

Toshi

Vereinsmitglied

  • »Toshi« ist männlich

Beiträge: 3 359

Wohnort: Oedheim/BaWü

Lieblingscomputer: Sage II

  • Nachricht senden

31

Samstag, 16. September 2017, 13:52

Turbo Pascal 1.0 läuft nicht (DIVIDE OVERFLOW)
Link arms, don't make them

Toast_r

2. stellvertr. Vorsitzender

  • »Toast_r« ist männlich

Beiträge: 4 333

Wohnort: 51.32,6.48544

Lieblingscomputer: CBM 720

  • Nachricht senden

32

Samstag, 16. September 2017, 14:07

Was für ein 16 Bit Prozesor ?
Ich dachte, da ist ein 8088 drin ... :tüdeldü:

Ist der nicht intern 16-bit?

Genau, intern.
Das blöde ist halt die 8 Bit Busanbindung, und dann müssen sich Datenbus und Adressbus auch noch die Pins teilen.
Dadurch verbrät das Ding bei jeden Zugriff Unmengen Zyklen.
Hinzu kommt noch die beknackte Segmentierung des Adressraums.
Der 8088 ist einfach eine extrem lahme Gurke.

33

Dienstag, 19. September 2017, 16:47

P-30 mit MSDOS 2.0 aber wie wird gestartet

Hier stelle ich mal den Ablauf bei einer Triumph Adler TA P30 zum starten des TA MSDOS20 dar. In einige Abschnitte ( kommen noch Teile) kan man den recht großen Umweg/ Aufwand von TA hier gewählt wurde.

Hier zum Beitrag erkennt man wie es los geht..und gestartet wid.
alphatronic P30, Fragen zu Steckkarten und Probleme mit den Floppy Laufwerken

Es sind ja offenbar einige USER die das TA MSDOS in Betrieb haben. Und eifrig mit div. Programmen hantieren erfolgreich.
Einfache Frage:
Wie bringen die USER die MSDOS ( <= 2.0) Programme vom PC/WEB / -Archive auf die eigenen TA MSDOS-Disketten übertragen.
Wär doch klasse, wenn hier ein einfaches klares Kochrezept dargestellt wäre!

Wer hat den MSDOS "DEBUG.EXE oder den "SYMDEB.EXE" Symol-debugger betriebsbereit auf dieser Kiste?
Dabei würde ich gene einen kleinen HEXA-DUMP vom DEBUGGER sehen. Und genau den absoluten unteren Speicher zu sehen.
Ich meine etwa so .

-DD0:0(cr) - Prompt vom SYMDEB und den Dump mit DD als Doppelword dann seg= 0 : und ofs=0 enizugeben.

Beispiel DUMP:
Dort ist ja ab 0000: 0000 jeweils pro INT-VECTOR zwei Words. Je INT-TAB stehen dort OFFSET: SEG - also 4 Byte.
Dort sind ja die BIOS-INT Vector-Einträge. Gut wäre der Dump bis zum DOS -SoftINT 21H.
Bekommt das jemand hin?

Vielen Dank und Grüße
Helwie44

Toshi

Vereinsmitglied

  • »Toshi« ist männlich

Beiträge: 3 359

Wohnort: Oedheim/BaWü

Lieblingscomputer: Sage II

  • Nachricht senden

34

Dienstag, 19. September 2017, 21:12


-DD0:0(cr) - Prompt vom SYMDEB und den Dump mit DD als Doppelword dann seg= 0 : und ofs=0 enizugeben.

Beispiel DUMP:
Dort ist ja ab 0000: 0000 jeweils pro INT-VECTOR zwei Words. Je INT-TAB stehen dort OFFSET: SEG - also 4 Byte.
Dort sind ja die BIOS-INT Vector-Einträge. Gut wäre der Dump bis zum DOS -SoftINT 21H.
Bekommt das jemand hin?

Vielen Dank und Grüße
Helwie44

Verstehe nur Bahnhof. Debug hab ich. DD0:0 kann ich auch eingeben. Was muß ich nun machen?
»Toshi« hat folgendes Bild angehängt:
  • debugx.jpg
Link arms, don't make them

35

Mittwoch, 20. September 2017, 12:44

TA MSDOS2.0 Soft - INT Vectoren?

Hallo Toshi,
die Anzeige mit dem DEBUG haben Sie prima hinbekommen. Nun sieht ( Beweis) man - warum der ganzen Datenstrom nicht IBM-Bios kompatibel ist. Aus meinen vorherigen Beiträgen habe ich schon dargestellt, wie alle DATEN (IOs) über ein 8- Bit Port geprügelt wird und noch der 8085 benutzt wird.
Aus dem DUMP ist folgendes abzuleiten:

A) der Speicher wurde getestet und mit 0AAh belegt ( vom INIT-TEST) ist ok!
B) jede 4 Byte Folge besteht ja aus einem INTERRUPT-VEctor. Bestehen aus SEG:OFFSET ( klar immer alles HEXA!).
Mit dem DD im Dump wird genau die logische Sicht der Bytefolge angezeigt. Im Speicher liegen wirklich die 4 Bytes genau rückwärts im Memory.
C) der erster EINTRAG bedeutet INT 0, immer weiter mit INT 1 ... bis hier im DUMP INT 20 - bedeutet 20H.
D) wer jetzt mal z.B. ein IBM Bioslisting aus dem WEB anschaut, findet dort eine gewisse Zahl von Einträgen mit den dahinter zu erreichbaren EPROM Adressen. Also etwa. 0F000h:0Exxxh für die Tastatur, oder Bildschirm und... mehr.
Beim IBM-BIOS ist die Funktion per INT xx Nummer festgelegt ( als BASIS). Für jeden INT xx Aufruf sind die Parameter in div. 8088/8086 Register definiert- daher rennen MS-DOS Programme auf fast allen voll kompatibelen Kisten - leider nicht hier bei TA.

E) bei einigen INT Vectoren sind diverse Einträge etwa mit 0yyy:zzzz belegt. Diese setzen das MS-DOS oder sogar einige Anwenderprogramme. Also ist das ok!
F) wenn dort immer AAAA AAAA steht, bedeute einfach dort hat keiner den INT xx belegt. Kein Programmstück um dort etwas abzuhandeln. ( kann sein - aber hier sehr spartanisch und nicht like IBMPC)

Fazit:
Ich sehe hier nur zwei INT Belegungen (vom TA EPROM, ) - etwa mit F000Fxxx oder war es mit F000Exxx. Sowas zeigt auf den TA EPROM. Diese könnte man mal mit dem U Befehl im DEBUG anschauen. Wie - hier folgend.

Evtl. ist mit dem DEBUG Befehl U nassemble der CODE anzuzeigen. Beispiel:
-UF000:FFF0(cr) das wäre der ENTRYpoint von dem HARDRESET. Dort steht meist ein JMP far ptr F000:E004
oder sowas in der Richtung. Dort könnte man ein neues UF000:E004(cr) machen. Nach einem Befehl-DEBUG wird oft nur mit einfach U fortgesetzt. Mal etwas probieren.

Ich könnte mir vorstellen, dass die Hardwarefraktion (und evtl. Softwareentwickler) sich schon was ausdenken könnten - um die TA P30 Kiste IBM- kompatibel umzutrimmen.

Viele Grüße und bis dann.
Helwie44

Thema bewerten