Beiträge von DoPe

gibt es dieses "supercopy" programm irdgendwo zum runterladen?

kann es partout nicht finden ...

danke!

sehe ich das richtig, daß eine interne HD-erweiterung aus 2 platinen besteht? eine kleine neben der 16-platine und eine große vis-a-vis?

ist die kleine interne quasi das zwillingsstück zur, im falle einer externen lösung, einschubplatine rückseitig, die sodann mit dem externen gehäuse verbunden wird?

großartig das zu sehen .. tastatur reinigung steht bei mir auch an und die return taste feuert auch manchmal nicht

ein video wäre natürlich ideal gewesen, dann traut man sich als unbedarfter eher über solche operationen

ich weiß ja nicht wie viele dmv-ler es noch gibt, aber nachdem uns alle irgendwann die tastaturen zerbröseln möchte ich mal so in die runde fragen, ob man nicht, wenn sich genug leute beteiligen, per 3d-drucker nachfertigen könnte/sollte?

habe aber keine ahnung wieviel aufwand (zeit,geld) das bedeutet. bin aber gerne dabei .....

vielen dank,

eine frage habe ich noch: wo würde eine interne 16bit (8088) erweiterung angesteckt werden?

wo wird dann die floppy angeschlossen?

danke fritz für den link zu jerry walker !

Hat jemand von den DMV Besitzern schon Erfahrung mit den oben genannten Ersatz-Controllern?

Im User Manual des des "drem"-Einschubs findet sich ein Hinweis, daß der Einsatz auch für den DMV gelingen könnte.

Auf Seite 45 werden die erfolgreichen Einstellungen für einen Kaypro 10 dargestellt

Zitat

A stock Kaypro 10 uses a Western Digital 1002 HDD-Controller and a singel 10MB drive. The controller supports 3 physical drives, bot OEM firmware expects only one disk attached .....

Using a DREM with a stock Kaypro 10 is straightforward: ...."

Superelegant wäre aber die Variante von Scott Baker.

Sein mini-Platine wird zwar in einen ISA-Bus (oder so ähnlich) in seinen Epson QX-10 (Z80, NEC7220, WD-1002 HD0) gesteckt, scheint aber bei entsprechender Platinenanpassung für den Einschubslot am DMV eine vielversprechende Lösung zu sein. DIPsw für die Ports an die der original WD-Controller hängt sind auf der Platine an die jeweilige Maschine anzupassen und in der BIOS - Software sind 2-3 kleine Änderungen vorzunehmen (wird genau beschrieben). Und zur Wahl steht CF Karte oder DOM.

Hat wer Erfahrungen? Kennt sich jemand genügend gut aus um das mit entsprechenden Fachwissen (Bios/Assembler), Umgestaltung der Platine an die BUS-Pins des DMV) ausprobieren zu wagen?

Und bitte wo ist da jetzt der Unterschied zur ursprünglichenn Version, wo war der Fehler?

Wie ist CPM 2.2 einzordnen hinsichtlich CPM80/CPM86?

Im TurboPascal Handbuch 3 wird CPM80 /86 als erlaubte OS angeführt, aber nicht CPM 2.2

Ich denke jetzt mal laut nach: spielt der 8203 chip beim DMV die Rolle die der 8237 DMA chip beim IBM XT hat? Also andersrum, hat der IBM XT somit gar keinen 8203 chip und dieser 8203 holt sich den Takt von wo?

Der V20 war auch im Testgerät verbaut (lt. den Angaben des Programmiers):

Beim Durchstöbern einer Materialsammlung zum DMV (das mir freundlicherweise fritzeflink zukommen ließ), lese ich in einer Datei "NCR.ASC" (bzw. NCR.DOC), in der ein findiger Programmierer die Mühen und Probleme beim Erstellen einer "neuen" io.sys für den DMV erklärt, daß der DMV über eine lausige Speicherperformance verfügt. Wie er meint, kommt diese dadurch zustande, daß der Controllerbaustein (8203), zuständig für den Speicherrefresh des DRAM, ein gutes Drittel der Buszyklen für den normalen Betrieb lahmlegt, um den refresh durchzuführen.

Das hindert natürlich die CPU am schnellen Zugriff auf den Speicher.

Dazu hat er in einer Schleife 500.000 Mal den int 80h aufgerufen und die Zeit gemessen (der int 80h ist am DMV mit Dos 2.11 ein nicht servicierter Interrupt. Wird er aufgerufen, wird mit IRET sofort retournier).

Die verwendete CPU war ein V20 mit 6,66667 MHz (20MHz Taktgeber / 3).

Die Laufzeit war 12,8 Sekunden.

Nun hat er durchgerechnet (mit einer falschen Zykluszahl für den loop-Befehl):

int 80h 50c

iret 39c

loop 13c (hier hatte er 1,4c eingesetzt ???)

===========

102c (hier hatter er 90,4c)

Daraus folgerte er, daß die "effektive" Geschwindigkeit der CPU nur ca 3,5 MHz beträgt: 90,4 * 500.000 = 45.200.000 cycles / 12,8 sek =3.531.250 Hz = 3,5 MHz

Rechnet man dies korrekter, also mit 102c pro loop und addiert noch 2 x 4c hinzu, um die notwendige fetch-time für das jeweils 2. opcode Byte der beiden 2-byte Befehle int und loop miteinzubeziehen die aufgrund der Leerung der prefetch-queue durch die jmp Befehle (alle 3 befehle sind jmp-Befehle, die nolens volens die prefetch queue leeren) nachzuladen sind , so sieht dies zwar etwas besser aus, aber insgesamt ist das Ergebnis erschütternd:

(102 + 2*4) * 500.000 = 55.000.000 cycles / 12,8 sek = 4.296.875 Hz = 4,3 Mhz

Das bedeutet letztlich, daß 2,4Mhz von 6,7Mhz auf der Stelle treten, wenn, wie im Beispiel, laufend auf das RAM zugegriffen wird (es werden hier im Bsp. keine internen Registerbefehle verwendet, die unabhängig vom Geschehen auf dem Bus immer mit voller Geschwindigkeit ablaufen. loop zählt zwar einen internen Zähler herunter, aber die Hauptlast ist der Sprung zu einer RAM-Adresse um von dort die nächsten opcode-Bytes einzulesen.

Am IBM PC/XT/AT beträgt der DRAM refresh ca alle 4 ms (der timer 1 des 8253 ist dort beim Systemstart so programmiert, daß er alle 72 cycles - 15,08 ysec - dem DMA controller dazu veranlaßt, eine von 256 möglichen Adressen anzusprechen, Dauer 4 cycles).

3,86 ms = 256 x 15,08ysec

D.h. für mind. 4 von 72 cycles ist der Bus für den DRAM refresh reserviert und somit 5,5% der Speeicherbandbreite für Programme verloren. Das kann sich aber je nach laufendem Programmcode noch erhöhen auf 8,3% (6 cycles von 72).

Beim DMV ist der Timer chip 8253 lt. den Handbüchern aber nicht für die STeuerung des DRAM refreshs vorgesehen.

Woher kommt die hohe Refresh-rate beim DMV? Und wurden im DMV so schlechte DRAMS verwendet, daß es notwendig ist?

Und final, kann man die DRAMS austauschen gegen "schnellere" und wo müßte man dann den entsprechenden ticker manipulieren?

Zeile 593: ebenso "MOV CursX,=" ?

Zeile 600: Beistrich nach AX zuviel

Zitat von rfka01

Bislang habe ich nur den Source-Code abgetippt, da das OCR zu ... spannenden Ergebnissen geführt hatte. Ich gebe keine Garantie auf Fehlerfreiheit, aber vielleicht mag ja auch jemand anders damit rumexperimentieren.

In Zeile 309 muß es heißen: " JNC ROT_ONE"

Zeile 80: es ist mit Sicherheit "0D0" der richtige Wert (die Portnummer für cpu-switch)

Zeile 352: ist das eine gültige asm anweisung: "MOV SB16,=" ?

vielen Dank nochmals !

Daß ausgerechnet dieser Abschnitt fehlt ist ein wirklich schade. Darin stehen die Daten zur BIOS Daten area, die sich leider von IBM kompatiblen PCs sehr unterscheidet. Wäre wirklich interessant und für alle möglichen weiteren Projekte von großem Wert gewesen.

siehe

BIOS Data Area

Danke für die Mühen !!!

Ich habe mich vor Jahrzehnten mit ausführlich mit der Programmierung des NEC7220 beschäftigt.

Im Eingangsposting wird die Frage gestellt, worin genau die Unterschiede zu einer herkömmlichen IBM-kompatiblen Graka bestehen, sodaß auf dem DMV so gut wie nix läuft, was damals auf jedem alten PC/XT/AT standardmäßig funktionierte.

Wenn am DMV Programme nicht liefen/laufen, lag das nicht nur (wenn auch vor allem) an der unterschiedlichen Ansteuerung der Graka, sondern auch an unterschiedlichen Portadressen wie zB des 8259 InterruptControllers, des TimerChips 8253, an unterschiedlicher Abarbeitung/Ansteuerung des Keyboards, unterschiedlicher BIOS-Adressen diverser gern von Programmen abgefragter Werte (Keyboard-Buffer, TimeOfDay).

Im Unterschied zu "normalen" Grakas blendet der DMV den Bildschirmspeicher nicht in der Hauptspeicher ein (wie sonst zb bei A000:0000 / B800:000 / etc). Der NEC7220 ist Alleinherrscher über seinen Speicher und um auf ihn zuzugreifen, muß man 1. den Controller über einen CommandPort davon in Kenntnis setzen (zb lesen/schreiben) mit Angabe wieviele Zeichen und nun 2. über einen Datenport (FIFObuffer) die Daten reinschreiben bzw rauslesen.

Der Vorgang ist somit völlig unterschiedlich zu jeder herkömmlichen Graka und jedes Program das versuchte von/an obigen Adressen lesen/schreiben zu können veursacht in wenigen Sekunden einen Absturz.

Die zweite Variante einer schnellen Bildschirmausgabe war dann noch die über den BIOS -Video Interupt 10H zu gehen.

Wobei "schnell" relativ zur Ausgabe über den Dos 21 Interrupt zu sehen ist. Der DMV ist ja sozusagen ein ANSI-Terminal, und das mitgeliefert DOS beinhaltet bereits die Abarbeitung von ANSI-ESCape Sequenzen für die Bildschirmansteuerung, wo andere PCs extra ein ANSI.SYS zu diesem Zweck als Treiber in die config.sys aufnehmen müssen. Und genau diese Übersetzungsarbeit macht die Bildausgabe so furchtbar langsam.

Der VIdeo-Interrupt 10H exisitert standardmäßig am DMV nicht, bzw tut nichts (der macht nur ein IRET).

Dank des Programmes "Clone.exe" wird dieser aber für den DMV erhältlich und damit läuft dann einiges (wie zb WS4).

Clone.exe bohrt auch gleichzeitig den Keyboard Interrupt 16H auf, der dann auch ALT-Tasten simuliert. In meimer Erinnerung sind dann F11-F20 entsprechend ALT-F1 bis ALT-F10).

Der Unterschied in der Geschwindigkeit wird sofort deutlich, wenn man zb statt der MsDos Variante von TurboPascal 3 (die es ja für den DMV gibt) die PC-Dos Variante benztzt. Diese muß zwar extra dazu gepatcht werden und ein weiteres Hilfsprogramm (resident) installiert werden (autoecec.bat), aber dann kommt Freude auf

Für das Clone Programm habe ich ein Manual gescannt, die Vorlage ist/war leider selbst nur eine sehr schlechte Kopie. OCR hat da keine Chance aber die jpegs tun es zur Not auch.

Erstmal vielen Dank für die Bereitstellung und aufgewendete Zeit!

Wird C2-1 bis C2-188 noch nachgeliefert oder ist dieser Teil physisch perdu?

Ich will bei all der Herrlichkeit nicht meckern, aber Seite C2-194 und C2-210 sind leider links abgeschnitten ... kann man da noch was machen?

Lieber K-Town Computeum!

Bussi, Bussi, Bussi !!!

Das langgesuchte Manual ist aufgetaucht. Das wird bestimmt auch rfka01 freuen.

Jetzt wäre es natürlich noch grandios, wenn es in ein pdf gewandelt werden würde, am besten gleich so, daß es einen text-layer hat.

Bin gerne bereit dies mit einer Spende zu unterstützen.

Ich will dabei nochmals auf folgende Info hinweisen, entnommern dem "system techn. manual CPM-86"

edit: insbesondere auf folgende Klarstellung ebendort:

In the NCR DECISION MATE V System Technical Manual series,

the chapters are arranged in numeric sequence and the appendices

in alphabetic sequence:

Hardware — Chapters 1 and 2, Appendix A

CP/M-80 — Chapter 3, Appendix B

MS-DOS — Chapter 4, Appendix C

CP/M-86 — Chapter 5, Appendix D

Das System Techn. Manual MsDos muß entsprechend den anderen manuals (diese halten sich an obiges Schema) ein Inhaltsverzeichnis haben, welches mit Chapter 4 beginnt und Anhänge unter Appendix C aufweist.

Vielen DAnk für die Rückmeldungen.

Jetzt bin ich aber verwirrt. Das ist das Inhaltsverzeichnis vom "MS-DOS Programmer's Manual", mit einem "Cover" lautend auf

"System Technical Manual MS-DOS" ???

Nein, diese Angabe bedeutet nur, daß in den jeweiligen Handbüchern die Nummerierung nicht jedes Mal bei 1 bzw A beginnt,

sondern die Handbuchreihe die Kapitelnummerierung und Appendixnummerierung fortführt.

Das System Technical Manual MsDos ist ein eigenes Handbuch und beinhaltet das "Chapter 4" der "sytem technical manual" Reihe.

Hat keiner der DMV - Besitzer dieses Handbuch?

Dann möchte ich mal einen Aufruf starten an alle DMV Besitzer: Hat jemand das System Technical Manual MsDos in Papierform und kann vielleicht das Inhaltsverzeichnis einscannen und posten?

Ja, danke, aber genau darunter ist eben das gesuchte Manual nicht

In den vorhandenen system-tech-manuals gibt es auf den Einleitungsseiten eine Übersicht über die tech-manuals.

Ich hoffe, ich darf das ungesühnt unter CPM Maschinen posten - der DMV kann halt auch MsDos ...

Ich kann unter den manuals auf oldcomputers-dyndns.org etc zwar alle möglichen "system technical" manuals finden, aber leider keines für MsDos. Dabei sollte es aber eigentlich ein solches geben.

Weiß jemand mehr? Link?

Zum Fehler bei den ausgegebenen Zeichen:

es müssen in den beiden initialisierungs fori i:= ... schleifen die beiden werte 48 und 55 vertauscht werden.

Lauft das benchprogramm eigentlich auf einem Originalrechner oder in einer simulations-maschine?

Letztlich glaube ich daß tofro Recht hat: der bascom compiler rechnet die real-Zahlen mit 4 Bytes, während turbo3 dies mit 6 Bytes macht. Das könnte den Laufzeitunterschied ausmachen.

so, letzter versuch heute abend

ein bißchen was sollte sich jetzt aber schon bewegen: das auszugebende zeichen wird jetzt vorinitialisiert in einem array.

dadurch braucht es kein if i > 9 ... sowie kein else und keine indexaditionen mehr.

damit sollte man jetzt endlich die schallmauer 40 durchbrechen ....

PROGRAM Fractal;
{$R-} (* range checking off *)

VAR A, B, CA, CB, T : Real;
    POWA, POWB      : Real;
    X, Y, I : Integer;

    XLIN : ARRAY [-39..39] OF Real;
    zeichen : array [0..15] of char;
    
LABEL nextX;

BEGIN

FOR X:=-39 TO 39 DO BEGIN
    XLIN[X]:= X*0.0458;
END;
for i:=0 to 9 do begin
    zeichen[i]:=char(55+i);
end;
for i:=10 to 15 do begin
    zeichen[i]:=char(48+i);
end;

FOR Y:=-12 TO 12 DO BEGIN

  CB:= Y*0.08333;
   
  FOR X:=-39 TO 39 DO BEGIN
    CA:= XLIN[X];
    A := CA;
    B := CB;

    FOR I:=0 TO 15 DO BEGIN
      POWA:=A*A;
      POWB:=B*B;
      IF ( POWA + POWB ) > 4 THEN begin
        write(zeichen[i]);
        GOTO nextX;
      end;
      B := 2 * A*B + CB;
      A := POWA - POWB + CA;
    END; (* Ende FOR I *)

    WRITE (' ');

 nextX:
  END; (* Ende FOR X *)

  WRITELN('');
END; (* Ende FOR Y *)

END.

seltsam ... das ist ja langsamer als die 41 die wir schon hatten

wurden da jetzt alle änderungen vorgenommen, also auch die verlegung der write() anweisung in die innere schleife oder ist das nur das weglassen der variable T ?

noch eine ersparnis zum obigen code

statt:

T:= POWA - POWB + CA;

B:= 2 * A*B + CB;

A:= T;

geht es kürzer mit:

B:= 2 * A*B + CB;

A:= POWA - POWB + CA;

die variable T ist unnötig.

einsparung von 2 integer additionen sowie einem goto sollte ein bißchen was bringen

PROGRAM Fractal;

VAR A, B, CA, CB, T : Real;
    POWA, POWB      : Real;
    X, Y, I : Integer;

    XLIN : ARRAY [-39..39] OF Real;

LABEL nextX;

BEGIN

FOR X:=-39 TO 39 DO BEGIN
    XLIN[X]:= X*0.0458;
END;


FOR Y:=-12 TO 12 DO BEGIN

  CB:= Y*0.08333;
   
  FOR X:=-39 TO 39 DO BEGIN
    CA:= XLIN[X];
    A := CA;
    B := CB;

    FOR I:=0 TO 15 DO BEGIN
      POWA:=A*A;
      POWB:=B*B;
      IF ( POWA + POWB ) > 4 THEN begin
        if i > 9 then
          write(chr(55+i))
        else
          write(chr(48+i));
        GOTO nextX;
      end;
      T:= POWA - POWB + CA;
      B:= 2 * A*B + CB;
      A:= T;
    END; (* Ende FOR I *)

    WRITE (' ');

 nextX:
  END; (* Ende FOR X *)

  WRITELN('');
END; (* Ende FOR Y *)

END.