Posts by JenGun

Quote from kkaempf

Es sollte identisch mit der Speedmaster 80-Zeichen-Karte sein.

Im Schmidtke-Zubehörkatalog wird auch der Genie IIs für die 80-Zeichen Karte extra aufgeführt ...

Quote from kkaempf

Speedmaster war von Uwe Böker, der von Trommeschläger unter Vertrag genommen wurde.

Dort wurde der Speedmaster als "Genie IIs" vermarktet und das "Genie IIIs" entwickelt.

Der Speedmaster (1983/1984) hat ja eine "Gemeinsamkeit" mit dem LNW80 (LNW Research, 1982): HRG mit 480*192 Pixel, die in den unteren 16 KB "eingeblendet" wird. Auch der I/O-Port (0xFE, Bit 1) dafür ist gleich ...

Das "GENIE IIs"-System kam erst nach dem "GENIE IIIs" auf den Markt, aus INFO GENIE IIs von TCS:

Quote

Nachdem bereits der bekannte, ebenfalls in Deutschland von TCS produzierte GENIE IIIs ein Renner am Computermarkt wurde, hat TCS sich entschlossen einen weiteren, dem GENIE IIIs ähnlichen Rechner zu entwerfen.

Quote from fritzeflink

Mit der 80-Zeichen-Karte konnte man 80x24 Zeichen darstellen statt 64x16

Diese Karte scheint Ähnlichkeiten mit der 80-Zeichen-Karte von Schmidtke zu haben (wurde ja auch für den Speedmaster angeboten): diese 10 "Jumper"-Einstellungen (Oben Rechts) sind dort ebenfalls vorhanden ...

Quote from guidol

weiss man, was das geaendert wurde dass es nun klappt

Der Fehler wurde anscheinend in cpmtools 2.21 behoben:

Quote

Fix block allocation for large directories.

Quote from klaly

Meine Windows cpmtool Programme sind alle vom 18.09.2017 Verion leider unbekannt.

Habe mal mit MinGW aus dem obigen Repository von Klaus Kaempf ein paar "Windows 32-bit binaries" erstellt (laufen ab Windows 95):

Quote from guidol

Eigentlich - da alle Ausgabe-Definitionen aufeinander aufbauen sollte RUNCPMFB nur mit fput laufen

Welches genau: fputc für "character" oder fputs für "string"?

Quote from guidol

(ist ja nicht wirklich "mein" Code. Ich pass den an und nenne es Fork/Port

Ist ja auch richtig so. Den Code schon irgendwo veröffentlicht?

Quote from guidol

wie hast Du dies so schnell gefunden? Kannst den Source schon auswendig?

Nur etwas Erfahrung mit einem anderen Emulator, der ebenfalls in "C" geschrieben ist ... putchar() und putc(.., stdout) (bzw. fputc(.., stdout) sind praktisch identisch, oder verwendest du nur fputs in RUNCPMFB?

Quote from guidol

Nach der Umstellung auf fput/putchar die FRACTAL.BAS Ausgabe ist auch ohne ANSI-Driver auch "nur" nach jeder berechneten Zeile

setbuf(stdout, NULL); sollte diese "Bufferung" für die Ausgabe ganz abschalten ... wird dann natürlich auch langsamer ...

Kann bei RunCPM in abstraction unter _console_init eingefügt werden, in abstraction_posix.h steht es so:

setvbuf(stdout, (char*)NULL, _IONBF, 0); /* Disable stdout buffering */

Quote from guidol

Und ersetzen der conio durch stdio hilft leider auch nichts an der Ausgabe

Und putchar statt putch verwendet?

Quote from guidol

Ich habe putchar getestet, aber der ist laut Doku eher verwandt mit den File-Command fputc (nach std-out)

Sonst funktioniert ANSI.SYS nicht: das ist ein Filter für "standard output" ...

In abstraction_posix.h findet sich kein conio.h, sonst wäre es ja nicht "POSIX" ... putch ist bei DJGPP in conio.h, aber putchar ist natürlich in stdio.h ... welche "platform" wird denn mit make build für den DJGPP benutzt?

In abstraction_posix.h wird einfach putchar genommen, gibt es natürlich auch bei DJGPP ...

Quote from ThoralfAsmussen

wenn der benutzte Treiber nicht sowieso von Matrox beigesteuert worden ist.

Aus mga_driver.c von XFree86/Xorg:

* The driver is written without any chip documentation. [ ... ]
* Now that MATROX has released documentation to the public, enhancing
* this driver has become much easier. Nevertheless, this work continues
* to be based on Radoslaw's original source

... und für die Parhelia-Serie gab es von Matrox auch nur "binary-only driver" ...

Quote from klaly

Wenn jemand Lust und ein Tool hat

ROMWak hat die angehängten Dateien erzeugt ...

Quote from klaly

Danke für den diskdef Block

ngc224 war in Posting #10 schneller ... das hatte ganz ich übersehen ...

Quote from klaly

Warum allerdings in den "Images" von samdisk, so "komische" Header vor jedem Track enthalten sind verstehe ich gerade nicht.

samdisk copy NKC1CPM68K.TD0 NKC1CPM68K.RAW

Die Datei-Erweiterung ist bei der Konvertierung wichtig. Aus https://simonowen.com/samdisk/cmd_copy/:

Quote

The output file extension determines the disk image type created, as well as the method used to read the disk.

Quote from klaly

Leider habe ich null Ahnung, wie einen diskdefs Block für die cpm-Tools erzeugen könnte.

diskdef mc68k
  seclen 1024
  tracks 80
  sectrk 10
  blocksize 2048
  maxdir 256
  boottrk 2
  os 2.2
end

... getestet mit den obigen Disk-Images und die Dateien sehen "plausibel" aus ...

Quote from guidol

Einfach den Compile-Flag von -m32 (oder -m64) auf -m16 umstellen.

-m16 erzeugt keinen "echten" 16-Bit Code: How does gcc-ia16 differ from 4.9.x's -m16 flag? ...

Quote from fritzeflink

Poste doch bitte deine tpqic01.h, bei der habe ich gerade so meine Probleme..

Ich gehe davon aus, dass du die QIC Konfiguration nicht dynamisch gemacht hast.

Laut dem "zugeworfenen" Link ( ) kann dieser Treiber unter Kernel 2.2 nicht als "Modul" geladen werden, d.h. bei Änderungen in der "Header"-Datei, ist ein "Kernel-Make" sowie "Reboot" notwendig ... bei der "dynamischen Konfiguration" können die Treiber-Parameter mit dem Tool qic02conf einfach (via ioctl) übergeben werden ...

Geht natürlich mit modprobe doch, wie man oben sieht ...

Quote from Metalhead

Nein, ist ein reines DD-Laufwerk. Habe einen konstanten Mangel an HD-Laufwerken (Bin mir aber sowieso über die Probleme bewusst, DD-Disks mit HD-Laufwerken zu schreiben, daher hätte ich bei diesem Projekt für den Transfer-PC sowieso ein DD-Laufwerk verwendet).

Funktioniert denn die erzeugte Boot-Disk in einem anderen (Transfer-)PC?

Quote from Metalhead

Den Memtest lasse ich gerne mal laufen, nur wie kriege ich den auf den PC? Kann BASIC per Serial Daten übertragen?

(Die Alternative wäre natürlich Abschreiben, ist jetzt aber nicht unbedingt meine bevorzugte Variante )

Booting from COM1 wäre auch noch eine Möglichkeit ... aber die paar Zeilen von MEMTEST.BAS sind doch schnell eingetippt ...

Quote from fritzeflink

Die Disketten sollten besser mit einem Permanentmagneten vor dem Beschreiben für den Advance86 gelöscht werden.

Dieser Hinweis befindet sich auch in der "Hilfe" zu ImageDisk, welches für den Zweck eher geeignet ist:

Getestet (Board: ASUS P5A-B, CPU: AMD K6-2 500, FD: 5,25" HD, Diskette: 48 TPI/DD): mit dem DISKCOPY von FreeDOS 1.3 erscheint beim Booten des Images tcs86-02.ima ebenfalls Non System disk or disk error ... mit dd if=tcs86-02.ima of=/dev/fd0 (unter Linux) startet das "Advance 86 Personal Computer DOS" von der Diskette einwandfrei ...

Nach einigen "Wiederholungen" scheint es dann auch mit FreeDOS zu funktionieren ...

Quote from Metalhead

Ich schreibe Diskettenimages auf DOS-Computern idR. mit Freedos Diskcopy.

Das 5,25"-Laufwerk dort ist HD (also kein PC/XT 40-Spur DD)? Die Diskette mal mehrfach "überschrieben"? "Reinigungsdiskette" im Advance86 verwendet? Da man zumindest ins ROM-BASIC kommt, könnte man mit memtest.bas den Speicher > 64 KB testen ...

Quote from Metalhead

Die Images von fritzeflink resultieren leider nur in einem non-system disk Fehler:

Wie sieht es mit dem angehängten Image aus?

Quote from ThoralfAsmussen

DAS ist übrigens was, was bei Apple besser gemacht wird als bei Linux ... mal alten Stoff wegwerfen.

Klar, das wird den "Empfänglichen" dort als "Feature" verkauft ...

Quote from ThoralfAsmussen

Andererseits wäre es auch überhaupt kein Problem, wenn man das nicht im Kernel "pflegen" müßte.

X.org ist nicht im Kernel und da sieht es ähnlich aus: "Legacy C Code" und "Obsolete Hardware" ...

Quote from 1ST1

Vielleicht muss der eine oder andere hier mal aktiv werden, um das zu verhindern?

Niemand "muss" ... Es ist erstmal nur ein "RFC" für den aktuellen Kernel ... und wenn keine/r die Hardware UND Zeit UND Nerven hat, solche "verwaisten" Treiber (in diesem Fall seit 2010) zu "pflegen", wird der Code sehr wahrscheinlich auch entfernt ...

Natürlich wollen "wir" alle die "Rückwärtskompatibilität" bis mindestens ins Jahr 1970 ... und die aktuellen "Security-Patches" ...

Quote from funkenzupfer

Ich vermute mal der TRS-80 macht 60 Hz Bildwiederholfrequenz.

Es gab wohl auch Versionen mit 50 Hz: TRS-80 Model 1 NTSC vs PAL ...

Laut TRS-80 Model 1 (Japanese Version) Service Manual and Schematics konnte dies auch eingestellt werden:

Quote

JP6, JP7, JP8 and JP10 serve to change the vertical synchronizing signal frequency. Setting to 60 Hz is made by connecting between C~1. Setting to 50 Hz made by connecting between C~2. The purpose of this is to prevent the adverse effect of the magnetic field from power transformer by aligning the power frequency with CRT vertical synchronizing signal frequency. The HDVR, VDRV, C2, C8, C16, L8, R1 and R2 signals oscillated from this circuit are combined with gates to produce the horizontal and vertical synchronizing signal timings. The horizontal and vertical synchronizing signals are mixed with Z32 to form the SYNC signal. This is mixed with Video signal and sent from J2 as output. The JP9 shown near the J2 connector in the circuit diagram is used only for Kana version destined for Japan; it is shorted for all others. This is due to the difference in CRT.

Der Inhalt von oldcomputer.info (u.a. obiger Link für "Meritum") scheint "verschwunden" zu sein ... glücklicherweise gibt es noch einen "Mirror" von dieser Seite: https://archive.sundby.com/mirror/oldcomputer.info/ ...

Quote from Toast_r

Nach der Änderung hat es nur ungefähr einen Tag gelaufen.

Das letzte mal davor ungefähr 1 Woche.

Dann scheint ja VMware selbst die "Ursache" zu sein und nicht die Hardware. Steht denn etwas dazu in vmware.log?

Quote from Toast_r

Habe ich mal hinzugefügt. Bin gespannt, ob es hilft.

Vielleicht auch noch serial0.fileType = "device", denn auf der obigen Seite steht:

Quote

see examples for usage as they must be combined in a special way

... vielleicht ist damit die Reihenfolge der Einträge gemeint ...

Quote from Toast_r

Da steht:

Code

serial0.fileName = "/dev/char/serial/uart1"
serial0.present = "TRUE"

Derzeit funktioniert es noch. Letzter Neustart war vor 4 Tagen.

Laut http://sanbarrow.com/vmx/vmx-serial-ports.html sollten noch folgende Einträge hinzugefügt werden:

serial0.tryNoRxLoss = "FALSE"
serial0.autodetect = "FALSE"

Was steht denn in den serial-Zeilen der betreffenden .VMX-Datei?

Quote from Holger

Quote from Peter z80.eu

Leider wird man durch ehrliche Arbeit ja nicht vermögend

Verallgemeinerungen sind IMMER falsch!

Schon, aber mir fällt jetzt direkt auch kein konkretes "Beispiel" ein, welches da als "Gegenargument" taugt ...