RS232 in BASIC-80 / MBASIC

danke für den tipp. Werde es ausprobieren, wenn ich wieder am Rechner sitze.

Das sieht gut aus:

PIP PUN:=BIOS.COMÄEBÜ

ergibt keine Fehlermeldung.

Du hast auf der Questar_cpm diskette folgende Programe,

Wobei BSEND und BRCV wohl von BYROM SOFTWARE TELECOMMUNICATIONS SERIAL NO. LB-357 VERSION    4.4
COPYRIGHT (C) 1980   ist und 2 Rechner mit einander verbindet.

FORMAT  COM.....................
PIP     COM...:.................
SUBMIT  COM.....................
SUB     COM.....................
ED      COM...4.................
ASM     COM...@.................
DDT     COM...&.................
LOAD    COM....................
STAT    COM...).................
SYSGEN  COM.....................
DUMP    COM.....................
MOVCPM  COM...z..... !".........
COPY    COM....#$...............
SMOOTH  COM....%................
WFORMAT COM....&'...............
WLOAD   COM....(...............
CPM57   COM...n)*+,-./..........
CONVER  COM...^012345...........
BASIC   COM...@6789:;<=>?@A.....
BSEND   COM...6BCDE.............
BRCV    COM...(FGH..............

Bsend habe ich vor Wochen probiert und keine Kommunikation mit meinem Windowsrechner hinbekommen. Mit dem jetzigen Wissen wär es nochmal ein Versuch wert.

Mit PIP habe ich es schon fast geschafft, dskparam.com zu übertragen. Leider hat der Z80emu keine daten auf meine serielle Schnittstelle schicken wollen und mit dem Windows Terminalprogramm Hterm konnte ich dem lauschenden Questar/m kein Ende der Datenübertragung übermitteln.

Bin guter Dinge, dass das noch was wird.

Habe mit PIP weiter experimentiert und bin einen Schritt weiter. Die Daten werden strukturiert übertragen und auch das Ende der Übertragung wird erkannt auf Questar/M Seite. (Siehe Screenshots)

Geholfen hat es im Sendeprogramm TeraTerm einen Delay von 1 msec/char einzubauen. Die Einstellungen sind 9600 Baud 8N1 XON/XOFF.

Leider scheitert Load DSKPRAM.HEX mit folgender Fehlermeldung:

ERROR: INVERTED LOAD ADDRESS, LOAD ADDRESS 0000

Mit DDT DSKPRAM.HEX komme ich auch nicht weiter, da das Programm dann hängt.

Sind die Daten, die ich per Emulator "Z80Emu" und dem Programm genhex.com erzeugt habe überhaupt richtig? Wenn nein, wie erzeuge ich die Hexfiles? Das in Fritzes Doku genannte UNLOAD finde ich nirgends.

Probier mal mit dem DDT

DDT

i dsdkpram.hex

dann mit SAVE n dspram.com sichern

At any point in the debug run, the operator can stop execution of DDT by using either

a ctl-C or Go (jmp to location 0000H), and save the current memory image by using a

SAVE command of the form

SAVE n filename.COM

where n is the number of pages (256 byte blocks) to be saved on disk. The number of blocks

is determined by taking the high order byte of the address in the TP A and converting this

number to decimal. For example, if the highest address in the Transient Program

Area is 1234H, the number of pages is 12H or 18 in decimal. The operator could type a

ctl-C during the debug run, returning to the Console Command Processor level, followed

by

SAVE 18 X.COM [Beispiel]

UNLOAD:

http://oldcomputers-ddns.org/public/pub/cdr…lutl/index.html

Nur damit ich es richtig verstehe:

Du willst DSKPRAM.COM in DSKPRAM.HEX umwandeln, damit Du es als Textdatei und nicht als Binärdatei senden kannst?

Eine andere Möglichkeit dazu ist UUENCODE/UUDECODE, für das Decodieren gibt es hier eine BASIC-Version, die man in überschaubarer Zeit direkt auf dem Zielrechner eintippen kann.

https://archives.scovetta.com/pub/mirrors/ft…/index30b5.html

Ich habe bislang immer kompilierte Versionen auf die Zielmaschine bringen können, daher habe ich die BASIC-Version noch nicht selber ausprobiert.

Gruß

Robert

oder hier:

http://oldcomputers-ddns.org/public/pub/cdr…m/cpm/startkit/

Ja, genau. So steht es in der Anleitung von Fritz. Könnte aber wirklich mal versuchen, die eigentliche Datei direkt zu übertragen.

Es hat endlich geklappt!

1. dskpram.com und unload23.com auf eine virtuelle Diskette gezogen in Z80EMU mit der Funktion import->binary

2. Im virtuellen CP/M mit unload23 die dskpram.hex erstellt

3. Diese per export->binary als Datei in die Windowswelt geholt

4. Per Send File in Teraterm die Datei an den Questar/M (dort PIP dskpram.hex=RDR:ÄEBÜ) übertragen

5. Am Ende der Übertragung hängt der Zielrechner - dann Teraterm schließen und Putty starten und dort die Taste "PAUSE/Unterbr" drücken

5. Mit dem LOAD Programm aus dskpram.hex wieder eine dskpram.com gemacht.

6. Fertig: Programm ist auf der Exotenmaschine ausführbar!

Wow, das war ein Stück Tüftelei!! Danke an alle, die mich unterstützt haben.

Ergebnis im Anhang!!

Passt doch... und jetzt noch die anderen Programme, und Qterm, Mex, Kermit oder ähnliches und was es da noch so schönes gibt falls wir die serielle

Schnittstelle konfigurieren können.

Die Patchadresse in PIP für send und recieve könnte hierbei helfen. Nur so ein Gedanke .

Drive Parameter Block (DPB):

4000 04 0F 01 7300 7F00 C000 2000 0300

Habe das "Probe2.com" auf dem gleichen Weg probiert...das sind 47 kB als .hex-Datei!!

Hat leider nicht geklappt.

Geklappt hat bisher:

skew.com

uudecode.com (waren 29 kB als Hex-Datei)

Probiere jetzt probe2.com per uue-Format zu übertragen (23 kB).

Welches Programm gibt die Infos zu den Low-Level Disk-I/O und zur seriellen Schnittstelle aus? So wie ich es im Emulator gesehen habe, müsste das probe2 sein, oder? Finde dazu kein Manual.

Probe2 entspricht probe102.com aus http://oldcomputers-ddns.org/public/pub/cdr…tl/00-index.txt

PROBE102.LBR    38272  12-28-86  Display address of CCP, BDOS, & BIOS

Wenn ich mir probe2.com z.B. mit Notepad++ anschaue finde ich:

PROBE Version 1.01 2 Sep 1984

PROBE will tell you what version of CP/M or MP/M you are

running, and display the I/O byte if appropriate. It then

displays the addresses of the CCP, BDOS, and BIOS. The BIOS

jump table will next be displayed including the extended BIOS

calls for CP/M+, and XIOS calls if running MP/M. It then

displays the disk parameter blocks (DPB's), disk parameter

headers (DPH's), group size, total disk size, number of

directory entries, space required for directory entries, total

usable space on the disk, and the disk space allocation vectors

for any selected drive (A: through P:).

PROBE was written in 'c' to help decode the disk formats of

a number of different machines to aid in transportability. It

was inspired by BDLOC, TELL, ALLOC, and a number of other public

domain CP/M utilities.

Paul Sittler - My Word!! RCP/M (409) 845-0510 (late nights)

Veterinary Public Health RCP/M (409) 845-0509 (24 hours)

Dept of Veterinary Public Health, Texas A&M University

College Station, Texas 77840-4468

Ja, genau! Habe ich mittlerweile auch gesehen als dieser Text beim Programmstart langsam auf dem Bildschirm ausgegeben wurde.

Wollte sehen, ob man die Infos irgendwie auf die serielle Schnittstelle schicken kann. Hab jetzt Fotos gemacht und in dem Questar/M Thread eingestellt.

Zitat von Aquarius

Ja, genau! Habe ich mittlerweile auch gesehen als dieser Text beim Programmstart langsam auf dem Bildschirm ausgegeben wurde.

Wollte sehen, ob man die Infos irgendwie auf die serielle Schnittstelle schicken kann. Hab jetzt Fotos gemacht und in dem Questar/M Thread eingestellt.

Unter CP/M + gibt es PUT und GET um I/O umzuleiten

Für CP/M 2 sind externe Programme notwendig.

P bringt eine UNIX aehnliche Pipe, so dass die Bildschirmausgabe in eine Datei umgelenkt werden kann.

Des Weiteren kann eventuell auch die IOBYTE Funktion genutzt werden.

http://www.seasip.info/Cpm/iobyte.html

http://www.gaby.de/cpm/manuals/ar…m#Section_1.6.1

IOBYTE details (weiss gerade nicht die Quelle)

Many thanks to Andrew Quinn for his help and support on this - most appreciated.
(If you don't know what the CP/M IOBYTE is then you can safely ignore this section!)
For full details on how to map logical devices to physical devices, please refer to the CP/M 2.2 manual available on the internet.
The CP/M IOBYTE (location 0003 in the memory map) is implemented to allow logical devices to be re-directed to the two 
physical ports.
The physical ports on this machine have been assigned to "CRT:" (the TTL serial port A) and "TTY:" (the RS232 serial port B).
For flexibility with all logical devices...
the CRT: port (TTL serial) is also assigned to physical devices UP1:, UP2:, UR1: and UR2:
the TTY: port (RS232 serial) is also assigned to physical devices LPT:, UL1:, RDR:, and PUN:

During startup you are asked to press the Spacebar on the window that is being used. This allows the machine to identify which serial port is connected to the user terminal. Depending on which of the serial ports is identified (CRT or TTY) the IOBYTE is set appropriately.

So...
If you activate the terminal on the CRT port, the IOBYTE is set to 00000001b ie. List is TTY:, Punch is TTY:, Reader is TTY:, Console is CRT:
If you activate the terminal on the TTY (RS232) port, the IOBYTE is set to 00000000b ie. List is TTY:, Punch is TTY:, Reader is TTY:, Console is TTY:

These can be changed dynamically as required.
eg. from the CP/M prompt, if STAT is installed...

STAT CON:=CRT:  - to set the console to the TTL port
STAT CON:=TTY: - to set the console to the RS232 port
...see the CPM 2.2 manual for more details.
Alternatively, the I/O can be changed within, say, Microsoft CP/M BASIC by "poke"ing the IOBYTE (location 3) with a suitable value. This allows programs to utilise BOTH serial ports for input and output within the same program.
PIP and STAT use these physical and logical mappings. Other communications programs (eg. Kermit) will also work with them.

Da wohl die IOBYTE Funktion implementiert ist sollte auch Generic Kermit gehen.

Auszug aus http://www.z80.eu/downloads/cpkermit.txt

1.6.1. Generic Kermit-80

"Generic Kermit-80" is an implementation of Kermit that should run on any 8080-

compatible CP/M 2.2 system with no modification at all, or perhaps only a minor

one. Unlike other Kermit-80 implementations, it contains no system-dependent

manipulation of the serial port.

All I/O is done with standard CP/M BIOS calls, and I/O redirection is done using the CP/M IOBYTE function, which,

according to the Digital Research CP/M Operating System Manual, is an optional feature of any particular CP/M implementation.

If your system does not provide

the IOBYTE function, Generic Kermit-80 will not work; furthermore, not all

systems that implement IOBYTE do so in the same way. The SET PORT command may

be used to select the devices to be used for input and output. Table 1-1 lists

the options to the SET PORT command and their effects.

-----------------------------------------------------------------------

SET PORT xxx input from output to

CRT CRT: CRT:

PTR PTR: PTP:

TTY TTY: TTY:

UC1 UC1: UC1:

UR1 UR1: UP1:

UR2 UR2: UP2:

Table 1-1: Kermit-80 SET PORT Options

Kermit als Generic 2.2 Version erstellt, übertragen und folgendes Ergebnis erhalten:

Kermit-80 v4.11

?Consistency check on configuration failed

Da hast du wohl nicht das Generic Kermit, es sollte sich auch so melden..

Probiere mal dieses hier aus:

http://gaby.de/ftp/pub/cpm/znode51/germany/modem/kermit.com

http://gaby.de/ftp/pub/cpm/znode51/germany/modem/kermit.dok

http://gaby.de/ftp/pub/cpm/znode51/germany/modem/

Ich habe mir das Kermit411 nach der Beschreibung von Peter z80.eu mal als Generic CP/M2 Kermit erstellt und kann es ohne Fehler starten.

In http://www.z80.eu/downloads/cpkermit.txt lese ich:

?Kermit has not been configured for a target systemor
?Consistency check on configuration failed

The first message indicates that the overlay wasnot found where the system-independent module expected to find it, probably

because the overlay address is incorrect;

the second indicates that the version of CPXLNK used in the system-dependent module is incompatible with the system-

independent module.

Folglich hast du für dein System nicht das richtige Modul gelinkt, mit den vielen CPV???? Dateien hat man sich bei der

Auswahl schnell vertan.

Ich habe das Kermit unter MYZ80 mal generiert und konnte es ohne Fehlermeldung starten.

ftp://kermit.columbia.edu/kermit/a/cpsker.hex | Kermit

ftp://kermit.columbia.edu/kermit/a/cpvgen.hex | "Generic": CPM 2.2 systems with IOBYTE (terminal req'd)

Siehe:

09:31 C0:WORK>

09:31 C0:WORK>dir

Drive C0 [WORK] Files: 3/88k Free: 6984k

CPSKER .HEX 68k : CPVGEN .HEX 4k : KGEN39 .COM 16k :

# ich nutze ein MLOAD für ZCPR

09:32 C0:WORK>mload kg411=cpsker,cpvgen

MLOAD ver. 2.4 Copyright (C) 1983, 1984, 1985

by NightOwl Software, Inc.

Loaded 26086 bytes (65E6H) to file C0:KG411.COM

Start address: 0100H Ending address: 73C7H Bias: 0000H

Saved image size: 29440 bytes (7300H, - 230 records)

09:33 C0:WORK>dir

Drive C0 [WORK] Files: 4/120k Free: 6952k

CPSKER .HEX 68k : CPVGEN .HEX 4k : KG411 .COM 32k : KGEN39 .COM 16k

# Aufruf von Kermit mit KG411.COM

09:33 C0:WORK>kg411

Kermit-80 v4.11 configured for Generic CP/M-80 with Generic (Dumb) CRT Terminal

type selected

For help, type ? at any point in a command

Komisch. Ich denke, dass ich die gleiche Vorgehensweise gewählt habe.

mload kermit=cpsker,cpvgen

Die Files habe ich auf der von Dir verlinkten Seite heruntergeladen.

Werde es nochmal in Ruhe versuchen und zum Vergleich die von Dir erzeugte Version testen.

Jetzt habe ich es hinbekommen!

Irgendwas hat die Übertragung gestört - habe jetzt als Abhilfe folgenden Befehl verwendet, um die ASCII Bildschirmausgabe abzuschalten:

PIP KGEN39=RDR:ÄBÜ

Kermit läuft und jetzt habe ich einen Memory-Dump des Rechners endlich in die Moderne Welt übertragen können.

Kermit (kgen39.com) braucht nur die Option SET FILE-MODE BINARY und es unterhält sich rasend schnell und komfortabel mit dem Programm Teraterm (Transfer>Kermit>Receive).

Kermit 411 läuft ebenfalls - dort muss die Option nicht gesetzt werden.

Das ist ein echter Quantensprung im Vergleich zu PIP - danke fritzeflink !