AES (Lanier) 103 (aka Beaugrand Alphatext)

  • Das war mir jetzt noch nicht klar!

    War das Programm/Betriebssystem nur auf "einer" Diskette untergebracht?

    Das Handbuch habe zeitlich noch nicht durchlesen können.

    Wusste nur, daß es Programm-Disketten und Daten-Disketten gibt und die AES selbst keine Disketten formatieren kann.

    Wir haben sowohl eine Programmdiskette (Das Textsystem) als auch eine Textdiskette als Image fuer Fluxcopy verfuegbar !

    Beim 103 ist das System auf einer Diskette und die Texte auf Textdisketten. Das System selbst kann keine Disketten generieren (formatieren), (Das war vom Hersteller anscheinend auch nicht gewuenscht, der wollte seine Disketten verkaufen). Das Geraet unterscheidet zwischen Sysytemdiskette und Textdiskette (n).

  • Vielleich lässt sich das Kopieren in den USA selbst bewerkstelligen. Ob er das mit einem Fluxteen und einem passenden Laufwerk

    selber schaft?

    Die Images könnte man auch mittels Kryoflux machen und einem passenden Laufwerk, wobei ja die meisten älteren Laufwerke mit Shugart-Anschluss funktionieren sollten (einziges Problem wäre hardsektor). Ist ja nur einseitig mit 40 Track. Müsste nur je Track eine Datei aufgezeichnet werden.

  • Wenn ich den Stand der der einzelnen Threads zu diesem Thema zusammenfassend betrachte, brauchen wir zunächst eine funktionierende

    AES 103. Richtig?

    Sonst läßt sich ja keine Diskette testen.

  • Dann habe ich einen jüngeren Hinweis überlesen. Im Mai hattest Du doch:

    "Nur ein echter Test in meinem AES ist mir leider nicht möglich, da der noch massve Netzteilprobleme hat.

    Warte gerade auf Ersatzteile, hoffe ich kann das bald testen."

    Dann ist Reparatur inzwischen erfolgreich gewesen.

    Ich bin also diesbezüglich nicht auf dem aktuellen Stand.

    Es laufen da parallele Threads mit inhaltlichen Überschneidungen.

  • Hi Philip,

    Zitat

    My 103 has some severe hardware issues. I'm about ready to begin desoldering microchips from the board to test their functionality.

    Before you "start your soldering iron", did you think about a test with software in the EPROM?


    Two years ago, I had troubles with my PHILIPS P2500: Repairing P2500

    The RAM was defect, but instead of soldering out all components, I wrote a small program for the Z80, to find out the defective chip.


    Your machine uses an 8080 processor. When you start with a simple program to check the CPU and EPROM and then step by step add other tests, you may save a lot of soldering work. Also the risk of destroying something will be minimized.

    You can also write some routines, what produce periodic signals at suspect chips. So you can check the functionality by a scope.


    Have a nice day!


    PAW

    Einmal editiert, zuletzt von PAW ()

  • Mir sind keine technischen Unterlagen bekannt - Das erschwert die Fehlersuche bei einem Fehler auf den Boards schon extrem.



    Mit Ausnahme des Reverse Engineering des Schaltnetzteiles von PhilA . (Messpunktuebersicht und Schaltplan des 5V Teils)


    http://www.oldbrokenjunk.com/wordpress/?cat=21&paged=2 (Phil, I hope I am allowed to give the address here.)



    Ich habe auch angefangen einen Plan fuer den -15V Teil zu machen, das habe ich aber abgebrochen als ich den Fehler gefunden habe.


    Hauptursache bei den Defekten am Netzteil waren


    1. Defekte Schaltspannungsregler (Unitrode)

    2. Defekte Becherelkos

    3. Defekte Transistoren


    Auf dem Logik-Boards waren bei mir lediglich ein paar Tantal-Elkos auszuwechseln, die waren ganz leicht so zu finden.


    Bei mir sind diese 3 Boards verbaut (Bilder aus der von fishermansfriendtoo verlinkten Seite) :


    CPU Board mit RAM/ROM

    https://vintagecomputers.sdfeu.org/aes/pics/cpu.jpg


    FDC/Keyboard und Printer I/O Board

    https://vintagecomputers.sdfeu.org/aes/pics/fdc_printer.jpg


    Video Board

    https://vintagecomputers.sdfeu.org/aes/pics/video.jpg


    Die 3 Boards scheinen der Grundausstattung zu entsprechen, die RAM-Karte und die Communications-Karte waren scheinbar "Addons"


    Your machine uses an 8080 processor. When you start with a simple program to check the CPU and EPROM and then step by step add other tests, you may save a lot of soldering work. Also the risk of destroying something will be minimized.

    You can also write some routines, what produce periodic signals at suspect chips. So you can check the functionality by a scope.

    I think it's not that easy, because there are no common eproms installed, but bipolar proms. This quickly limits the availability of parts and programming devices.

    However, the RAMS and some other parts are fortunately socketed.

  • PAW - I had thought about it but the PROM that it boots from is a small 512 byte device with a very small address and data space.

    However, it would be possible, in theory, to emulate the PROM and attempt to make the CPU cycle.

    I had started work on that while back, as mister-freeze shows, on my webpage if you view category "Lanier Model 103" ( http://www.oldbrokenjunk.com/wordpress /? cat = 21 ) you'll see I started working backwards through the circuitry from the PROM to try to understand how it was being used. This was mostly because if the contents of the PROM were dumped and translated into 8080 assembly, it made no sense ...


    The CPU does not appear to be getting much in the way of signals that are not totally insane, and every boot the readout from the board differs.


    I may attempt to reverse-engineer the board again, though the number of splits and vias make that difficult.


    Philip

    2 Mal editiert, zuletzt von PhilA ()

  • This was mostly because if the contents of the PROM were dumped and translated into 8080 assembly, it made no sense ...

    Would it do any good to compare our ROM dumps?

    It would be interesting to check see if they match (or, at least, if they are close).


    Does your PROM (chip number 56) still have its paper label attached?

    Mine reads 950-511301 B58K. 950 appears on all the boards, CPU 950-0090, I/O 950-0089, video 950-0091.


    Philip

    2 Mal editiert, zuletzt von PhilA ()

  • This was mostly because if the contents of the PROM were dumped and translated into 8080 assembly, it made no sense ...

    I took a look on your boot ROM (from your webpage). The beginning looks quite good. Why does it made no sense ?

    (I translated a part of it with ZSID into Z80 mnemonics, because I am more familiar with Z80).


    If it is possible to replace the boot ROM by an EPROM (with an adapter), you can look for correct running of the 8080.

    The first program needs no output, but jumping between two addresses, where it is looping for a while. With the scope you can check all address and data lines, also you will see the jumping between the two loop adresses, when the CPU is working. At next step you may test the RAM, because then ROM loads very early the stack pointer and does a call. If the RAM is defect, then the system crashes here.



    But if the comparison of your ROM against the ROM of mister-freeze will show differences, you may try with the contents of the other ROM burning into an EPROM. I think you have an ERPOM burner. There are also EPROM-Emulators with RAM. They are very fast to "burn".


    PAW

  • Had a moment today at lunch so I removed U52, 59, 43, 38


    3 of them are flip-flops. One had blown out underneath, the bottom of the chip was cracked. None of them work correctly.

    1 is a tristate bus buffer. It does not work either.


    I think that the board saw a significant voltage surge.


    Philip

  • Very strange. When I put the PROM code into *80 language it didn't come out like that. It makes sense, there.


    I do not have an EEPROM burner here, however removing the chips and testing their truth tables shows that they have severe faults.


    I think I may have a marathon session of replacing microchips ahead of me.


  • I have attached the ROM dump. The first 2 lines are identical to Phil's ROM after a first glance.


    AFAIR there were Paper Labels on the ROMs of the Video Board but that was not Visible at the CPU-Board--PROM because mine has some kind of resistor network soldered piggyback. I have read it out together with the piggyback construction. I have identified the ROM Type whith help of the above linked Photo.

  • Okay, it would appear poking at the chips is too slow for this particular logic, so I set up a strobe on my Arduino and checked the levels with my analyzer.

    D is set, Q follows D. Correct


    Buffer, Y follows A exactly. Correct.


    Will get some sockets and put them back in the circuit.


    Phil


  • :fp:Oh my goodness, the post office said that the parcel with the goods would take at least 6 weeks, and the letter would be much faster ::post:::D. If we had known that before....


    But I'm very happy that it happened so quickly.



  • Yes. I think that once they left Germany, they were both put into the same box that was marked "Parcels to USA", and then they appear to have both been treated the same upon arriving!

    Either way, thank you. I am building my FLUXTEEN board during my lunch break.

    Testing the discs will need to wait until I have repaired the hardware faults.


    Philip

  • Danke für die ZIPs

    Versetzt mich jetzt in "Zugzwang" einerseits die AES "anzufahren" und ein kompatibles Diskettenlaufwerk für den Fluxteen herauszusuchen.:)

    Da werde ich wohl an Wochenende eine Nachtschicht einlegen müssen, denn ein Arbeitskollege ist seit 7 Wochen krank und hat nach Plan in 2 Wochen

    für 3 Wochen Urlaub angemeldet. Ich schreck jetzt jedesmal hoch wenn das Telefon klingelt: Da will doch wohl keiner was von mir.

  • und ein kompatibles Diskettenlaufwerk für den Fluxteen herauszusuchen

    Du kannst natürlich auch das Laufwerk des AES nehmen um die Images zu schreiben, so wie PhilA das gemacht hat.

    Bei manchen 1.2 MB Laufwerken gibt es mit Hardsector-Disks Probleme, die AES Laufwerke und praktisch alle 96 TPI CP/M Laufwerke (80 Track Double Density) sollten wohl funktionieren. Ich habe ein Philips Laufwerk verwendet, aber beispielsweise Teac FD-55E/F sollten auch gut verwendbar sein.

  • praktisch alle 96 TPI CP/M Laufwerke (80 Track Double Density)

    Die meisten 48tpi Laufwerke auch , single Step (für die Disketten mit 35 bzw. 40 Tracks).

    Meiner Erfahrung nach werden die 35/40 Track Disketten mit einem 48tpi Lauwerk zuverlässiger geschrieben.


    Die Laufwerke des AES 103 sind 48tpi/35T.


    Bei den 96 TPI-Laufwerken mit Doublestep werden die Spuren "schmaler" geschrieben.

  • The only problem I've had with these drives is then not returning to track 0 correctly.


    I.I have found that if I use the COM port and "s1" then send a string of - to instruct it to shuffle the head back to zero the read/write operation is usually more successful.


    There doesn't appear to be a parameter to set for "reset to zero time", just seek/spin-up (unless I misunderstand the commands).


    But yes, the drive from the AES works well to read and write the discs.


    Phil

  • Agreed. I have found that using an older drive to rewrite a disc has enough flux width to "plough the field", if you will accept the analogy.

    Once it has been written with a 48tpi drive, often it can then be overwritten with a 96tpi drive successfully.


    I discovered this when writing disc images using a PC, intended for use in my TRS-80/III.


    Phil

  • [user = '50 '] mister-freeze [/ user] I took your dump files and did a stare-and-compare in Notepad. My read of your disc on the left, your .dmp file on the right.


    It would appear that either the disc was meant to be empty or it is not formatting well or something because there's a moderate amount of data inconsistency. I used FLUXCOPY 0.90 test, compared to 0.3 Full you have on yours - perhaps that is the reason.


    However, the dense areas of data are all immaculate and identical. Perhaps something in the way it is reading the disc?


    Edit: Also not to discount that my disc drive may have bad hardware, also.


    Edit 2: You wrote the disc with a 96tpi drive- my drive is probably not 100% aligned, and that's likely "noise" from data that was on the disc in the skipped tracks.


    Maybe suggestion for PAW to have the track skip actually write the skipped tracks as zero flux instead of jumping over the track?

    2 Mal editiert, zuletzt von PhilA ()

  • But The Checksums are okay. At first glance it looks good. ( PAW , gpospi would you agree ?)


    The Text Disks i sent may differ from the Diskimage because i have treated them on my AES with some test actions before shipping.


    Try again with the System Disk or try to write and read back one of my Diskimages on an empty Disk and then compare them.