Geschichte eines Alphatronic P2, der eine Reparatur (oder mehr) versucht.

    Das (vorläufige) Ende einer langen Reise:


    Ich habe den Floppy-Controller aus der P2-3A nochmals überprüft, es ist tatsächlich ein alter FD1771 verbaut. Testweise habe ich den gegen einen neueren Chip getauscht, aber MFM Disketten können trotzdem nicht gelesen werden. Es gibt also wenig überraschend noch weitere kleine Unterschiede auf der Controller-Platine.


    Im Zuge dieser Tests habe ich auch gleich noch neue EPROMs in die CPU Platine meiner "Test-P2" eingebaut. Diese CPU Karte hat sehr unpraktische EPROM Sockel, die auf der Außenseite einen erhöhten Rand haben. Damit konnte ich meine Zwischenstecker nicht anbringen, weil sie zu breit sind und am Rand anstoßen. Ich habe die EPROMs also mit etwas Bastelei direkt in die Sockel auf der Platine gesteckt. Siehe da, nun läuft auch dieses System! Es meldet sich wie gewohnt das MOS und erlaubt die Befehlseingabe. Booten kann ich natürlich nicht, da ich in diesem System nun den alten FM-Floppy-Controller aus der P2-3A habe (und dafür fehlen mir Floppies bzw. passende Gotek Images). Mit dem derzeit verbauten neuen Floppy-EPROM (Version 42D) funktioniert der alte FM-Controller natürlich keinesfalls, dazu müsste wieder das alte 011er EPROM eingesetzt werden.

    Einmal editiert, zuletzt von gpospi ()

    Das mit Eproms sieht ja schon sehr künstlerisch aus . Ich muss jetzt mal fragen welche EPROM's denn eigentlich da rein gehören -

    also Typ und Zugriffszeit.


    BG

    mesch

    Original sind hier 2KB EPROMs von Texas Instruments, Typ TMS2716 verbaut. Die Stromversorgung bzw. Pin-Belegung der TI EPROMs unterscheidet sich von "normalen" 2KB EPROMs anderer Firmen (TI Pin 19 = VDD/12 Volt, TI Pin 20 = A10, TI Pin 21 = VBB/-5 Volt). Deshalb muss man beim Einsetzen normaler EPROMs an diesen Pins Änderungen vornehmen. Die Zugriffszeit sollte relativ egal sein, die alten Rechner sind ohnehin nicht so schnell. Meine neuen EPROMs haben 200ns Zugriffszeit.

    Zitat von gpospi

    Original sind hier 2KB EPROMs von Texas Instruments, Typ TMS2716 verbaut. Die Stromversorgung bzw. Pin-Belegung der TI EPROMs unterscheidet sich von "normalen" 2KB EPROMs anderer Firmen (TI Pin 19 = VDD/12 Volt, TI Pin 20 = A10, TI Pin 21 = VBB/-5 Volt). Deshalb muss man beim Einsetzen normaler EPROMs an diesen Pins Änderungen vornehmen. Die Zugriffszeit sollte relativ egal sein, die alten Rechner sind ohnehin nicht so schnell. Meine neuen EPROMs haben 200ns Zugriffszeit.

    Owei, die haben die seltene 3-Spannungsversion verbaut. Dann ist alles klar.

    Zitat von gpospi

    ch habe den Floppy-Controller aus der P2-3A nochmals überprüft, es ist tatsächlich ein alter FD1771 verbaut. Testweise habe ich den gegen einen neueren Chip getauscht, aber MFM Disketten können trotzdem nicht gelesen werden. Es gibt also wenig überraschend noch weitere kleine Unterschiede auf der Controller-Platine.


    Der 1771 kann nur FM, womit auch Single density Disketten reichen.


    MFM kann z.b. der 1791 Kontroller.

    Mit freundlichen Grüßen


    fritz

    War doch meine Vermutung - aus meinem vorherigen Beitrag (FM / MFM) - gewesen.

    Ein Blick in die Datenblätter, hilft oft den Hintergrund möglicher Fehlerzustände zu analysieren.

    alphaTronic P2 auf dem OP-Tisch

    Auf dem schönen Foto von gpospi ist doch zu sehen, wie kompakt und eigentlich durchdacht das alphaTronic Px System konzipiert wurden.


    Von den ursprünglich verbauten drei je 16 kB RAM-Karten - sind dann später nur noch eine 64 kb/ Resetzustand 48 KB RAM-Karte verblieben.

    alphaTronic P2 auf dem OP-Tisch - voll in Funktion


    Die wesentlichen Komponenten habe ich farblich von mir gesondert bezeichnet. Ich meine, evtl. wäre diese Darstellung für nicht so vertraute alphaTronic P2 Owner oder User - als Übersicht hilfreich.


    Richtig einen guten Job hat gpospi mit dem "ERLEBEN" einer alphaTronic P2 gemacht. Wenn man bedenkt, dass diese P2 Maschine ziemlich aus den Anfangsserien stammt.

    helwie44 † - Danke für Ergänzungen! Ja ich habe inzwischen recht viel über die verschiedenen Alphatronic Modelle gelernt. Lediglich die Probleme mit der 48 KB/64 KB Umschaltung im "normalen" P2 System konnten wir nicht lösen (das hat sich für mich ja erübrigt, da ich die 64 KB Speicherkarte nun im P3 Rechner einsetze).
    Mit den Alphatronic Systemen bin ich übrigens erstmalig als Schüler in den späten 1980er Jahren in Kontakt gekommen. Deshalb freut es mich besonders, dass ich diese Rechner nun (über 30 Jahre später) reparieren und meiner Sammlung hinzufügen konnte.

    Die anderen Schulrechner aus dieser Zeit (CBM 720 Rechner samt Grafikerweiterung und Doppelfloppy) fehlen mir leider noch, ich habe lediglich einen CBM-610 im Kasten.

    Der Drucker zu meinem TA P2-3A funktioniert übrigens auch noch, lediglich ein neues Farbband müsste ich von irgendwo her bekommen. Es handelt sich dabei um den DRH-136 A3 Drucker, der ist mit fast 60 Zentimer Breite weitaus weniger kompakt als die P2 Rechner ;-).

    Der modulare Aufbau der P1/P2/P3 ist super, das erleichtert die Fehlersuche und Reparatur (einfach einzelne Steckkarten austauschen bzw. einzeln durchmessen).

    Ein (hoffentlich) passendes Farbband für den Drucker habe ich auch schon gefunden, werde ein Update geben sobald es eintrifft.

    Ich habe nun das neue Farbband bekommen, jetzt kann man die Druckausgaben auch lesen ;)

    Ich hatte schon fast vergessen, wie mühsam das Einspannen des Endlospapiers war und auch wie laut die Nadeldrucker sind...

    Hat hier eigentlich jemand Erfahrung mit der CRT 4A Grafikkarte für die P2 Rechner? Mich würde diese Erweiterung sehr interessieren, aber man findet dazu kaum Informationen und schon gar keine funktionierenden Karten...

    Externe Grafik-alphaTronic P2

    Das ist offenbar eine Zusatzkarte von einem externem Entwickler für eine alphaTronic P2 (TA) einsetzbar wurden konnte. Dazu passen auch der MC 80 BUS mit solchem Stecksystem. Ich habe dazu ein buntes Prospekt von TA - mit einerm sogar Farb-Bildschirm mal gesehen. (im WEB? uni Stuttgart, oder)


    Evtl. könnte nur irgenwie noch ein Mensch von der damaliger TA -dds Zeit, einen Entwickler ( oder Händler/Anwender/Kunde) zu dieser Karte etwas berichten. Aber ich selbst habe solche Karte nicht gesehen - leider!


    Gerade habe ich ein Datenblatt vom EF 9366 hier abgelegt. Aus den Überblick-Funktionsbilder könnte man die Arbeitweise sich vorzustellen können.


    Grüße und eifriges Fachsimplen

    Helwie44

    helwie44 †

    You mentioned some graphic extension card sometime ago, that used part of the unused memory range in the first 16K. While being third-party, I bet this one was mapped using unused ports (I think 8 ports in both 5xh and 7xh ranges were available).


    gpospi

    After taking a look to the datasheet, it seems to have a resolution of 512x256, noninterlaced.

    Bottom ic row seems decode logic (again, without docs is difficult to know how it's wired) and bus control signals translation (it was designed with 65xx/68xx CPUs in mind, without separate read and write signals), second-to top is RAM 4116 (x8) for a total of 16K. This memory is private and not accessible to the 8085. Top row may be glue logic, the GDP seems to multiplex memory address.


    I found an application example but with 4164.


    Thank you for posting it, always interesting to learn more about this system.

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    Gefällt mir 1

    Thanks jlopez , gpospi for the infos and the Link:

    Zitat von jlopez

    I found an application example but with 4164.


    Thank you for posting it, always interesting to learn more about this system.

    I found the manufacturer for the P2 graphics controller card. From about 1982.

    In the info-PDF (German) is something more to the graphics card and the manufacturer.


    Is actually something easy (or even better) times for a P2 / P3 replicate. Of course, with better components to develop!


    If we feel like doing this, a software package in assembler with subroutines after the PLOT 10 system would be a nice task for me!

    But the hardware would have to knit someone - or?

    So it was not a third-party but TA...


    Yes, it has a low ic count. And anything that brings fresh air here is welcome.


    Assuming they aren't counterfeits (most come from PRC), EF 9366 seem to be available and inexpensive. Not considering 4116, but as my first boards some SRAM. If going the monochrome way it coud be sourced for about 11€, the colour way about 17€ (I'm not counting board or other ICs). Just some numbers. What ports did it use? Decoding a port is easy using a couple of 74138, but the wiring is important to be known. Does it uses slot C?


    Regards

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    hello jaume,

    I mean it is set via a 4-bit switch dip (upper half-byte) the basisport address. It was as I see, was not the C-series of the mc 80 bus used.

    the connection side of the graphics card is not shown on the photo.

    Zitat von helwie44

    hello jaume,

    I mean it is set via a 4-bit switch dip (upper half-byte) the basisport address. It was as I see, was not the C-series of the mc 80 bus used.

    the connection side of the graphics card is not shown on the photo.

    Sounds good. That leaves less requirements to consider.

    I have some work to do... and a deadline in Tuesday, but I may give it a try during the weekend.


    Regards

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    This PDF I already know (in fact I just copied a scaled down version of it into my original post). Building the board should be feasible if we would have:

    • Picture of the wiring on both sides
    • List of components or at least a colour picture (to identify values of resistors).

    Without such info I doubt that it makes sense to start a project. At least my knowledge and time are for sure not enough to re-design a graphics controller just by looking at a black+white photo...


    I think there was also a graphics board for the PC8, maybe this can still be found somewhere. However I also had no luck with this so far.

    Zitat von gpospi

    This PDF I already know (in fact I just copied a scaled down version of it into my original post). Building the board should be feasible if we would have:

    • Picture of the wiring on both sides
    • List of components or at least a colour picture (to identify values of resistors).

    Without such info I doubt that it makes sense to start a project. At least my knowledge and time are for sure not enough to re-design a graphics controller just by looking at a black+white photo...


    I think there was also a graphics board for the PC8, maybe this can still be found somewhere. However I also had no luck with this so far.

    Hello gpospi!


    I think we need neither, as a 2019 design would use only the GPD as a vintage part. Everything else is secondary, depends on technology changes. Having no slot C implies no hidden requirements and by having dip switch it means it could be mapped wherever the user wants to. As it seems the GDP is the workhorse of this board and the other semiconductors are rather passive, the remaining things to do would be:

    • Interface the GDP with the MC-80 bus
    • Interface the GDP with its private RAM

    The example I found could be used as a basis for the rest of the circuit. It doesn't seem that TA did much more than that. The resistors near the switch expect them to be 4k7-10k, the top ones may be the ones of the oscillator.


    Regards

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    A replica would be harder to made, more expensive and with a higher risk of failure. As more the vintage (specific) parts are used, higher is the risk.

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    Yes ok, this approach makes sense if we don't aim for full compatibility with the CRT 4A graphics board (as we anyway don't have the original software). Of course a new board using the same controller as the CRT 4A would be very close to the original board, probably just the MC80 interface (address mapping) would be different.


    Going a bit further the simplest solution would be to hook up a Raspberry with HDMI/BAS video output to the system (MC80 bus or even serial port) and define a graphics control language (to be sent from the P2 to the Raspberry, running a "display interpreter"). The "display interpreter" could basically do whatever we want, like emulating the EF9366 commands or run e.g. a "LOGO" interpreter (https://en.wikipedia.org/wiki/Turtle_graphics). A quick search led me to existing LOGO implementations for the Raspberry (http://raspberry-python.blogsp…logo-turtle-graphics.html, https://www.raspberrypi.org/forums/viewtopic.php?t=1290) and there are several examples available (e.g. <script src="https://gist.github.com/ramalho/ca3a355b3df471e29282.js"></script>). Piping serial input to the Xterm console on the Raspberry would not require any programming.


    Actually a similar approach (having a dedicated "video terminal device") is being used in the Philips P2000C: The main unit is a Z80-powered CP/M system which has an internal serial interface to a terminal board (based on a second Z80). The terminal can display graphics, output is controlled via Escape-Commands (similar to matrix printers' ESC/P language).

    4 Mal editiert, zuletzt von gpospi ()

    Zitat von gpospi

    Yes ok, this approach makes sense if we don't aim for full compatibility with the CRT 4A graphics board (as we anyway don't have the original software). Of course a new board using the same controller as the CRT 4A would be very close to the original board, probably just the MC80 interface (address mapping) would be different.


    Going a bit further the simplest solution would be to hook up a Raspberry with HDMI/BAS video output to the system (MC80 bus or even serial port) and define a graphics control language (to be sent from the P2 to the Raspberry, running a "display interpreter"). The "display interpreter" could basically do whatever we want, like emulating the EF9366 commands or run e.g. a "LOGO" interpreter (https://en.wikipedia.org/wiki/Turtle_graphics). A quick search led me to existing LOGO implementations for the Raspberry (http://raspberry-python.blogsp…logo-turtle-graphics.html, https://www.raspberrypi.org/forums/viewtopic.php?t=1290) and there are several examples available (e.g. <script src="https://gist.github.com/ramalho/ca3a355b3df471e29282.js"></script>). Piping serial input to the Xterm console on the Raspberry would not require any programming.


    Actually a similar approach (having a dedicated "video terminal device") is being used in the Philips P2000C: The main unit is a Z80-powered CP/M system which has an internal serial interface to a terminal board (based on a second Z80). The terminal can display graphics, output is controlled via Escape-Commands (similar to matrix printers' ESC/P language).

    Wait...


    In this case, it does seem (by ic count) they added nothong and they relied just on the GDP. A different approach doesn't necessarily mean incompatibility. Do you remember my first memory board? It was to the original board what day is to night; yet, it was the same thing to the computer. The only compatibility issues here may be introduced in the MC-80 interface but, being switch-configurable that is difficult to happen. Sometime ago, I read about unused ports (we need 11) and there's only one free 16-port range on the whole alphatronic series. As I don't recall the source mentioning CRT4, it could be plausible they used that same range. Then, the only incompatible thing would be software, but with the source at hand it can be fixed anytime if new information apears.


    This night I thought about a solution to the DRAM issue. Not an easy fix, but I think I found a solution. I don't have time now as I must leave but today I'll share it. It's not as cheap as I expected but if well-sourced it could still beat the 4116s in terms of cost. My doubts are if that is a valid solution, as I use components I have never used and don't know how would they behave exactly.


    Regards

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    When dealing with multiplexed memory addresses, latches are required to build the real "lineal" address. To recreate the 14-bit address two 8-bit latches are required, one would be updated by RAS and another one by CAS (these signals may require to be inverted). And that's the easy part.


    Then I realized the GDP outputs only a single bit and, even if the output of the memory is a byte it can set (or reset) a single bit of it. That's the real problem. Using long memories of 1-bit width was the original approach. If replaced by SRAM, extra work should be done.


    First approach: 32K x 8

    It would be cheap and fit the address space. Without a complicated logic it would rewrite all bits of a cell every time it writes or erases a pixel, corrupting the result. Even if made to work, it wouldn't be time-compliant.

    Not viable.


    Second approach: 16K x 8, Dual Port SRAM

    The memory ic may cost 5-6 times (at least) what a 32Kx8 or a 4116 would cost but still be cheaper than the 8x4116 assembly. It would neither require the three voltages. This solution would come configuring port A as read-only and B as a write-only, sending the output through a demultiplexer and the output of the latter to feed the SRAM input. I know, it seems confusing, a drawing should be easier to understand.

    Both address busses in the SRAM should be wired exactly the same so input port address corresponds to output port address. The demux is not a 74157 as it has both enable inputs tied together. So a different approach was taken.

    All 8 inputs of the decoder should be connected to two controlled buffers: one inverted and one non-inverted. This way every selected bit would be introduced in the data bus while the rest would simply flow through this section.


    Note that those are not schematics, just concepts, some thoughts. Those may be improved or corrected over time or, if a better solution is found, replaced. This is also made to consider both complexity and cost and if cost is deemed too high, the project may not proceed.


    Regards

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    Gefällt mir 1

    Port requirement for a graphics controller card

    The already sizzierten considerations jlopez and gpospi but I look at me until weekend times.


    PORTs:

    With the required 16 ports hanging together, as with the grafic chip, there is no problem in the MC-80 BUS and like in an alphaTronic P2 / P3.

    From the concept at that time at the KISS and then also at the Px MAschinen, in the upper nibble a so-called BASIC-PORT address by DIP switches or at TA often fixed on the lamination.

    So only the BASIC PORTS would be used / occupied:

    0x, V24

    1x, keyboard

    5x, floppy

    78, BANKING

    8x, DISK Sysquest (used by helwie44 † )

    x :: = 4 lower bits == 16 consecutive ports fit in!

    About the memory, I've been considering how to proceed with option #2. However it's too complex to develop. The GDP has simply not aged well, as it was made only with the 41xx family in mind. Using modern memories in the design is too complex and expensive to be considered viable. Still, there are two options.


    Third approach: following closely the datasheet

    Using 4116. I've been able to find sources of them, especially in PRC. Requires three different power lines.


    Fourth approach: following closely the example

    Using 4164. At this point, the cheapest of the viable options. Requires a single supply line.


    If someone has an idea about how to proceed in this case without using 35-40 years old memories, I'd like to hear about it.


    About MC80 bus interfacing and decode logic, 4 ICs, the switch and the resistors/resistor pack are required. This section could be built for around 3,63€ (estimate).

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol:

    Gefällt mir 1
    Zitat von jlopez

    If someone has an idea about how to proceed in this case without using 35-40 years old memories, I'd like to hear about it.


    As you can see - unfortunately nobody has reported in the hardware area to the problem / solutions.


    I would like to have a "graphic SUPER CARD" for the MC80 BUS. I would develop the software as driver and a program package such as "PLOT10" according to the hardware and make it available to everyone.


    Is that for next year?


    I should still have the circuit diagram from the MC-80 interface card for connecting a hard disk disc station. That was 2 x 5 MB SyQuest Q-PAK. At that time ( 1980 ?) , the developers worked in the field of communications engineering at the RUB (Ruhr University Bochum) for KISS and alphaTronic Px.


    If I find the schematic - I insert the documents here.

    Helwie44

    I've been (and still currently) busy with some university work. There are still five deadlines to meet between tomorrow and January 8th.

    Seeing no better option, 4164 are the way to go. Past Dec. 23rd (deadline #2) I'll work on it.


    Regards

    When I tried to list all retro systems I have at home, the "The message is too long, must be under 500 characters" error appears! :lol: