AES (Lanier) 103 (aka Beaugrand Alphatext)

  • PhilA , that's great, glad you made it.

    In the meantime I found a manual in english language. If you want I can scan it sometime. It is however so that the control commands (letters for function selection) in the English variant is different to the German. Since you have the German operating system, this probably won't help you at first. How does it behave with the keyboard layout ? Some keys might be assigned incorrectly due to the different keyboard layouts.

    Hopefully you will get the US version of the operating system someday.

    I will take any data relating to the machine if it is available. I have the German version of the manual but my German is quite poor (aka I can't speak German at all...) so the rudiments of operation are quite difficult to understand. However, the way it works, even if the FUNC+key assignment is different, will be useful to understand.

    The key assignment is as you'd expect, DIN. I'm not used to the QWERTZ layout and a few of the keys are accent modifiers as you expect to find.

    I keep looking for people who possibly may have a copy- now that Fluxcopy is a thing, recreation of the discs is possible. I have hope that I'll find some.

    Until then it is nice to be able to type at all, though the most common message the machine gives me is FEHLER. Go figure.

  • My keyboard; missing a few of the additional keys. There are solder locations on the PCB for them, they are populated with blank switches that contain no electronic sensor, used only to support the extra size of the key.


    Phil


  • Tortured the scanner in the office this morning.

    As already mentioned, the operation is the same in principle, only the command shortcuts are different depending on the language version.


    For example, in the German version of the disk/file commands, the letter "S" ("Speichere" in German, which means to save) is used to save the pages. In the EN-US-FR version "M" ("Memorize") is used for this.

    The command "S" has a completely different function in the EN-US version, I think it stands for "Sort".


    But there are also command letters which are the same in the versions, e.g. "R" for "Recall" ("RUFE AB" in German) or "I" for "Index".

  • I was making myself a reference sheet last night, so I can more easily remember the commands.


    I tried saving a test file and it corrupted the disc. Great.


    I've just re-written the image with my FLUXTEEN, shall see if it worked in a minute...

  • FLUXCOPY says it made a good copy; I have SUCCESS! after writing the image. I used the top drive from the computer, so the alignment is good.


    However, attempting to read the disk back gives INDEX: FEHLER so it's not writing properly.


    C:\Users\phil\Desktop\FLUXCOPY>"FLUXCOPY 090 - Test.exe" /c='10' /d='1' /i='48'/f='00' /t='39' /p='S' /s='S /M='1,SHUGART,5.25,DD,39,1,1000,25,50,50,75' /M='2,SHUGART,5.25,DD,39,1,1000,25,50,50,75'


    That's what I'm invoking FLUXCOPY with - I think that's correct parameters?

  • Hi Phil,


    "Success" after writing is no warranty that the data have been written correctly.


    Please reread the written disk with FLUXCOPY and then make a dump with FLUXDUMP. FLUXDUMP tells you, if the disk has errors (checksum). If there are no errors found by FLUXDUMP it is a good base for testing on original system. But it is possible that there are errors on the original system, though no errors detected by FLUXCOPY and vice versa. There is a little difference between decoding the data and there is more or less tolerance for errors.


    FLUXCOPY parameters are looking good.


    If your send me a FLX-image of the original and of the copy, then I can analyse it.

    (When rereading, set the number of retries to 1. This saves space.)

  • I ran it again and saw that it wrote the last 3 tracks against the stop. Looks like the magnetic head was not on Track 0 to start.


    That would certainly cause errors....

  • Zitat

    I ran it again and saw that it wrote the last 3 tracks against the stop. Looks like the magnetic head was not on Track 0 to start.

    FLUXCOPY recalibrates to track 0 only for one time at power on. Then it calculates the actual position relative to the last position. Only when return to track 0 (sensor), it compares to the internal (calculated) position. If the head will be moved to another track (without FLUXCOPY), FLUXCOPY calculates a wrong position.

  • Did you use this Image ?:

    RE: AES (Lanier) 103 (aka Beaugrand Alphatext)

    Please delete the last 5 Tracks (35-39) in the Textdisk-Image Folder of this provided Image. They´re empty and useless. I read this in a 40T drive and forgot to limit the tracks.

    Or you can specify Track 0-34 only in Fluxcopy. Then only the first 35 are written.

    The Shugart SA400 is designed for 35 T only, that may cause the "head bump" if you try to write more than 35 Tracks in this drive.


    C:\Users\phil\Desktop\FLUXCOPY>"FLUXCOPY 090 - Test.exe" /c='10' /d='1' /i='48'/f='00' /t='39' /p='S' /s='S /M='1,SHUGART,5.25,DD,39,1,1000,25,50,50,75' /M='2,SHUGART,5.25,DD,39,1,1000,25,50,50,75'

  • After work today I shall change those parameters, write and dump.

    It must've been at 0 and just ran out of tracks at the end.


    I did use that image, yes.


    Seeing "success" made me think it's doing a write-read-compare?

    Einmal editiert, zuletzt von PhilA ()

  • A little experiment shows that generally indicates a track is unusable. Wonderful.


    I need to find some working discs, punch the timing holes and try write them.


    I am concerned the computer will corrupt the only other working TEXT disc I have.

  • Now I need to reactivate this old discussion. A few weeks ago, the monitor of my AES 7100/203 stopped working. When switching on the system, there were issues with vertical deflection (i.e. all text was just printed at one horizontal line in the middle of the screen). Soon after, there was no video output at all any more. The system itself still works, i.e. it boots from disk and handles commands (entered blindly).


    Meanwhile I opened the system and did some analysis: The PSU and mainboard are working fine. However, the monitor seems to have a capacitor issue (as already suspected). The 12V line from the PSU goes down to 8V when connecting the monitor power wires. Consequently the CRT heating wires are not working (i.e. the end of the picture tube is not glowing as usual) and there is no "sign of life" on the screen.


    So far I figured out that there is a 6-pin video connector on the system board (connector J6), providing the video signals and the power (12V) to the monitor. The PSU provides power for the monitor on connector J7 (Pin #1 = 12V, Pin #2 = GND), linked to pins 3 and 1 on the video connector (i.e. J7#1 => J6#3, J7#2 => J6#1). The other pins of J6 obviously carry Hsync, Vsync, video and (probably) intensity or some kind of brightness control signal (as brightness can be controlled via software on this machine). However, I have no clue about the actual pinouts or signal levels. Unfortunately there is no technical manual/schematics available and AES uses a very specific/proprietary colour coding on the wires (e.g. all PSU wires to the mainboard are just red, but carry +5V, +12V, -12V, -28V and GND). Hence I am hesitant to try measuring directly on the J7 pins. Does anybody here have more information or suggestions how to proceed best? If I remember correctly, there is no other AES 203 in your collections. In this thread we discussed about your AES 103s previously, but I am not sure if the monitor of my system is internally equal to the AES 103...

  • The monitor assembly in the 103 is different. Also the pin assignment is different. See photo on this page:


    However, the CRT chassis and circuit board are probably from a third-party manufacturer. Have you already searched about it ?

  • The monitor assembly in the 103 is different. Also the pin assignment is different. See photo on this page:

    https://ingeniumcanada.org/sci…s-plus-103-word-processor


    However, the CRT chassis and circuit board are probably from a third-party manufacturer. Have you already searched about it ?

    Thx! Indeed they are different. In my system the tube is a Zenith DS12NK201, while the 103 seems to use Philips (according to the link above). Also the monitor PCBs are completely different, even the video connector goes with 7 used pins on 103 while mine has actually 6 pins. So no luck here.
    Also I couldn't find any references/3rd party vendor identification regarding the monitor chassis. There are no company names, logos or other identifiers on the monitor PCB. The chassis itself just has one label, showing "937-516201 and REV.00 101-6570-19. This doesn't lead me anywhere with Google.

  • In fact difficult to find something, neither by the manufacturer MTI nor by the numbers. A case for our searchfox fanhistorie ;)


    If the supply voltage drops so much, I would first check the traces to see which components are clearly connected. Maybe there is an easy-to-find low resistant capacitor ?

    But what speaks against to check the TTL signals at the open connector with a scope? GND will be able to be found out and much more than

    +12V , GND, Video, Vert.-Drive, Horiz.Drive, Video and (probably) 3 contacts for the brightness, will not be there.


    Edit: sorry, you already mentioned the one-wire brightness control

  • Hallo Günther!


    Hast Du eine Wärmebildkamera? Wenn bei Dir die 12V zusammenbrechen, solle etwas warm werden. Einen Tantal habe

    ich jetzt nicht gesehen, aber der wäre jetzt mein Tipp gewesen. Hatte dieses Jahr schon 2 Monitore , die sich ähnlich verhielten: Keine

    vertikale Ablenkung mehr. Beides mal war es ein Tantal in der 12V Leitung auf der Monitorplatine.

  • Wärmebildkamera...gute Idee. Mal sehen ob ich mir sowas besorgen kann.

    Mit Scope durchmessen ist natürlich mein nächster Ansatz, eventuell auch eine Analyse der Leiterbahnen (aber da komme ich zumindest im Monitor nicht so gut ran)...

  • Ich bin ein kleines Stück weiter gekommen. Habe mir heute mal das Videosignal am AES System angesehen:

    Wenn ich das richtig interpretiere, dann liegt Hsync an Pin 4 (ca. 23.8 kHz, positive Polarität) und Vsync an Pin 5 (58.8 Hz, negative Polarität). Das Video-Signal scheint an Pin 6 anzuliegen. Allerdings verwundert mich die eher ungewöhnliche Horizontalfrequenz. Sie ähnelt grob EGA (21.8 kHz) bzw. der HP 9000/300 mit 35731 Monitor (800x400, etwa 25 kHz, jedoch negative Polarität). Mein Nec Multisync LCD 1830 "Allesfresser" Monitor (der mit der HP 9000/300 funktioniert) verweigert bislang jede Ausgabe. Eventuell liegt es an der falschen Sync-Polarität (VGA und HP verwenden ja immer negative Polarität), oder der Nec läuft tatsächlich erst ab 25 kHz. Also muss ich weiter experimentieren und im ersten Schritt mal einen Inverter für Hsync einbauen. Einen GBS8200 hätte ich auch noch zur Verfügung, aber ob der mit diesen Frequenzen und Polaritäten irgendwas anfangen kann? Laut Datenblatt müsste es eigentlich (im CGA/EGA Bereich) passen:

  • Heute hatte ich nicht viel Zeit für den AES, da ich micht um die defekte Festplatte meiner NextStation gekümmert habe. Somit habe ich mir nur einen "Quick & Dirty Hack" für den AES ausgedacht: Einfach mal Hsync & Vsync von einem Rechner mit VGA Karte geholt, das Video-Signal vom AES. Natürlich synchronisiert der Monitor da nicht richtig. Aber immerhin konnte ich sehen, dass tatsächlich ein "brauchbares" Video-Signal vom AES geliefert wird (allerdings nicht wie erwartet auf Pin 6 sondern auf Pin 2 des internen Anschlusses):

    Das erste Bild zeigt den Bootscreen mit AES Copyright-Meldung, das zweite Bild zeigt den Texteditor. Dieser hat in der ersten Bildschirmzeile eine invertierte Statusleiste. Diese kann man bei meinem Hack grundsätzlich erkennen. Insofern bin ich vorsichtig optimistisch, dass ich mit einem Sync-Polaritärswandler ein lesbares Bild bekommen könnte. Als "Restrisiko" bleibt natürlich die ungewöhnliche 23.8 kHz Hsync-Frequenz...

  • Mist, heute leider keine Erfolgsnachrichten: Ich habe einen EGA-Rechner an meinen NEC Monitor angeschlossen, leider meldet der Monitor hier nur "Frequenz zu hoch" (eigentlich aber "Frequenz zu niedrig"). Somit also keine Chance, den AES Output hier darzustellen. Auch mit GBS8200 habe ich nichts erreicht, der meldet immer "No Input Signal" (eventuell weil er Combined-Sync braucht).

  • Hm, nun habe ich meinen zweiten alten NEC aktiviert (NEC Multisync 1525X-BK). Der scheint das Bild ordentlich zu erkennen und zu synchronisieren:

    Alle Bildparameter werden korrekt angezeigt, d.h. entsprechen meinen Scope-Messungen vom AES. Leider bekomme ich trotzdem kein Bild, vermutlich weil die Video-Pegel nicht passen, der Monitor verdaut nur analoge VGA Pegel. Daher nun "Plan B": Pegel des AES Videosignals analysieren bzw. konvertieren. Wenn es ein klassischer TTL Pegel ist, dann sollte er ja leicht auf die analogen Werte zu bringen sein...

  • Hab wieder ein paar Scope-Messungen gemacht. Allerdings bringt mich das nur bedingt weiter, bin bei Scope & Video-Signalen ja noch ein "Rookie". Jedenfalls erkenne ich, dass AES wohl keine TTL Signale ausgibt. Das schaut für mich eher nach Composite oder S-Video Y/C aus (CH1 ist das vermeintliche Video-Signal auf Pin 2, CH2 ist Pin 6). Kann mir hier vielleicht jemand helfen und etwas "Licht ins Dunkel" bringen? Vielleicht poste ich mal im "allgemeinen Forum" und suche nach Video-Experten?

  • Ein stabiler Trigger ist bei Messungen immer sehr wichtig/sinnvoll.

    Bei Videosignalen sind die Sync-Signale dein Freund. Egal ob H- oder V-Sync, ist die Frage was du messen willst. In deinem Fall wahrscheinlich besser H-Sync.

    Und dann taste dich mal vorsichtig vom Sync zum Video Signal. Es reicht wenn du dir eine Zeile anschaust, also vom H-Sync zum H-Sync.

    Was mich etwas wundert ist deine Sampte Rate, die steht immer auf 1MHz. Der Pixeltakt liegt selbst bei alten Geraeten nicht unter 10MHz, bei VGA-Textmode bei rund 28MHz. Um also eine qualitative Aussage ueber dein Videosignal machen zu koennen, solltest du mit deutlich hoeherer Abtastrate arbeiten. Und danach reden wir noch ueber die Bandbreite deines Oszis und der Tastkoepfe.

    ;------------------------------------
    ;----- ENABLE NMI INTERRUPTS
    (aus: IBM BIOS Source Listing)