AES (Lanier) 103 (aka Beaugrand Alphatext)

  • I shall try that. We know your disk images are good; they booted and operated correctly.


    the issue here will either be as you say, I'm reading different data because that's what was on the disc, or my drive isn't quite in calibration. I shall do as you say later on today, read the SYSTEM disc and compare.


    Thanks


    --Phil

  • Quote from PhilA

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

    Hi Phil,


    there is no possibility to write a zero flux to the disk! At each write pulse sending to drive you change only the polarity of the magnet in the head. So you have allways North or South!


    Writing no pulses to a track means, that the receiver will turn up the amplifier gain and so you read a noise. You will get "phantom"-pulses.



    Quote from mister-freeze

    But The Checksum is okay. At first glance it looks good. ( PAW , gpospi would you agree ?)

    That is correct!


    The sectors of AES-Lanier disks are shorter than 128 bytes! So you will see data after the check sum, but this is garbage! The seventh byte in the last line of the sector is the check sum. Normally we should not display bytes out of data, but on AES-disks I displayed the whole 128 bytes.


    E.g.: at sector 3 you have one byte checksum hex B7. The byte to the right hex 40 is not existent! when stopp writing a sector the AES stops immediately after the check sum. This happens not exactly at the same time (difference of rotation speed) So if there was written something before to the same sector, there stays some garbage, what you read now.


    Quote from PhilA

    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.

    My experience says, if you want to write an 48tpi disc on a 96tpi drive, you have allways to clean/erase the disk by a strong magnet, except you use this disk only on the same 96tpi drive!


    PAW

  • the issue here will either be as you say, I'm reading different data because that's what was on the disc, or my drive isn't quite in calibration.

    If you can read the white-labelled Disks (written with a known-good 48tpi Drive) and "fluxdump" the read Image without any checksum Error then there ist no need to recalibrate your Track alignment.

  • 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).

    Hi Phil,


    may be, then timing parameters of FLUXTEEN are not correct for this drive, may be to fast.


    There is no parameter for "reset to zero time", because it is dependent, from what position you have to move to zero. So a step to step time (track to track) is defined which will be applied for each track to move. When this time is too long, then it takes a longer time to move (has another sound on stepping), but should be working. For best results use timings from the data sheet of the drive.


    The commandline parameters for the timings are described here: Timing Parameters


    For older drives you may try with:


    MotorStartTime 1000 msec

    StepToStepTime 10 msec or longer

    HeadLoadTime 50 msec

    HeadSettingTime 50 msec


    When is working well, then you can try to make shorter timings, until errors occur.


    PAW

  • Correction: One drive that works well. Two that do not.


    I need to go look see if I have any spares. I do have a spare board and some other odds and ends. Punched another disc, and apart from the fact the media is no good, it is good with the timings to read and write. I took more care with this one to line up the index hole accurately, and punch the rest in accordance.


    I'm also working on checking the board logic. I may see about writing a basic 8080 bootstrap and implanting that on the board to see if the logic is correct (without the I/O and VDU boards plugged in if that causes issues).


    Phil

  • I have decided to remove all logic, test and add a socket. Doing this means I can also capture a view of the electrical lines underneath each chip, which is difficult to do with the chips in place.

    Slow but worth the effort, I think.

    I shall attempt to create a schematic of the CPU board, at least.


    Philip

  • This very Heath-Robinson setup is being used to stress-test. With a basic logic test using jumper wires and LED's, the truth table of each chip is checked. Then, they are run at high frequency to see if they break down and fail at the speeds the computer uses.


    Phil

  • There's definitely something of interest at locations $7EBx


    I'm working through the boot PROM code, breaking it up and looking to see what it's doing. Obviously there's a number of memory location points that I need to go look up; mister-freeze pulled the ROM code from all the chips he could, so I shall have to investigate those.


    I'll post up what I have once I've gone through it.


    Phil

  • Hallo zusammen,


    ich habe ein paar 8" Disketten für AES System abzugeben. Für welches System genau, kann ich leider nicht sagen, es muss so aus der Zeit 1987-1992 sein.

    Vielleicht sind die nützlich für die AES Freunde.


    Gegen Versandkosten und einen Text-Dump der darauf enthaltenen Dokumente.

    Weitere Details bitte per Konversation.


    Martin



    Hi all,


    I have some 8" hard sectored disks for a AES text processing system.

    I don't know in which AES system exactly these were used, they must be from the period between approximately 1988 and 1992. All these are document disks, i.e. no special system disk.


    I have one cardboard box with 6 disks and another nice red plastic foldout box with 9 disks.

    All disks are used, but in good cosmetic condition, but I cannot guarantee that they are still useable.


    As I do not need these disks (famous last words...), I can send them for costs of shipping and a text dump of the documents stored on them.


    PM me, if you are interested.


    Martin

  • It would be nice to know the system addresses now.

    Axel

    Still working on that. Being as the I/O card does not have a dedicated floppy drive controller, instead just the SMC COM2601 UART, the boot prom code appears to be controlling all aspects of the drives.


    Making a guess, IN 05 is data in from the floppy drive, and I think OUT 16 is drive spindle motor on/off.


    $7EBx locations in memory are stack.

    Not sure what is at $8000 yet.


    Phil

  • I saw something hitherto undiscovered this morning- one of the 74LS138 binary to decimal converter chips that interfaces directly with the UART on the I/O board of mine is cracked.

    That would cause the behavior of the I/O board to be highly disruptive if it has failed. I shall use it as the first suspect on that board.


    Phil

  • Quote from PhilA

    I saw something hitherto undiscovered this morning- one of the 74LS138 binary to decimal converter chips that interfaces directly with the UART on the I/O board of mine is cracked.

    Hi Philip,


    are you sure, that 74LS138 is a binary to decimal converter?


    My data sheet says it is 3 to 8 bit binary decoder/demultiplexer.


    PAW

  • PAW I was discussing this on the VCF with Chuck G and he said:


    Using a USART chip for an early FDC would not be uncommon. I'll have to go back to my notes on an early 8" AES disk to look at the encoding, but I do recall that the bitstream was USART order, not traditional FDC order. Using asynch I/O would seem to be a horrible waste of resources, however.


    Has he made a correct assumption, that the data is stored not in a standard WD1660 style format?

  • The letters have worn off chip 56 on my I/O board (950-008901)- can you check what type of chip is connected to yours please? (No hurry).


    My AES is well stowed away at the moment, it would probably take a week.

    Take these HiRes photos, they also helped me identify my ROM types.


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

    Site: https://vintagecomputers.sdfeu.org/aes/


    According to the photo it's a NE558N Quad Timer


    and if you need a new COM2601 USRT with 60! Days Warranty :D:D:

    https://www.ebay.com/itm/20213…f77a5b:g:-q4AAOSw-09aIKyu



    PAW I was discussing this on the VCF with Chuck G and he said:


    Using a USART chip for an early FDC would not be uncommon. I'll have to go back to my notes on an early 8" AES disk to look at the encoding, but I do recall that the bitstream was USART order, not traditional FDC order. Using asynch I/O would seem to be a horrible waste of resources, however.


    Has he made a correct assumption, that the data is stored not in a standard WD1660 style format?

    I am convinced that the 8" AES floppy disks have a completely different format and are therefore not comparable with the 5.25" AES floppy disks.

    If you look at the explanations of the developer of the FluxENGINE, then even for his assumptions there can only be meant an 8" floppy disk. (77T, 32 Sectors).I think his basis was an image of an 8" floppy disk and according to his investigations it should be an M2FM encoding with bytes written backwards. But maybe we'll find out more when I hold Martin Hepperle s 8" disks in my hand.

    The 5,25" Disks on the other hand are FM encoded but PAW knows the details of the 5.25" disks much better.


    Here are the explanations from the FluxENGINE page. ...as I said, it has to be 8" because there are no 77T 32Sec 5.25" hard sectored discs.


    8080 machines with 32kB of RAM, they ran their own proprietary word processing software off twin 5.25” drive units, but apparently other software was available.


    The disk format is exceptionally weird. They used 77 track, 32 sector, single sided hard sectored disks, where there were multiple index holes, indicating to the hardware where the sectors start. The encoding scheme itself is MMFM (aka M2FM), an early attempt at double-density disk encoding which rapidly got obsoleted by the simpler MFM — and the bytes are stored on disk backwards. Even aside from the encoding, the format on disk was strange; unified sector header/data records, so that the sector header (containing the sector and track number) is actually inside the user data.

  • NE558N, thank you!


    I have had such a busy week with not enough sleep! I'll get some good rest and read thoroughly.


    Phil

  • Quote from mister-freeze

    The 5,25" Disks on the other hand are FM encoded but PAW knows the details of the 5.25" disks much better.

    Details you will find here: AES Lanier 5.25" Diskettes


    Has he made a correct assumption, that the data is stored not in a standard WD1660 style format?

    I don't know the "standard WD1660 style format".

    I am more familiar with µPD765, which has been used in IBM PC and also in Philips P2000 series.


    What we can say, the µPD765 controller use standard formats with FM or MFM and sector sizes of 128, 256, 512, 1024, ... bytes.

    They are allways soft sectored and use 16 bit CRCs for error checking.


    AES 5.25" diskettes are hard sectored, FM coded and have a data length of 151 bytes per sector. There is only an 8 bit checksum per sector, not a CRC. The databits in a byte are stored in reverse order on the disk.


    I downloaded the data sheet for this uart.

    It shows that this chip was developed for use in floppy controllers.

    What chip do you mean? I didn't found data sheets of WD1660 or COM2601 UART.


    I think that the usage of an UART/USART for read/write floppies may be possible. The data on the floppy are serial, like on a line. The only problem is the modulation. You know, it is not possible to write the bits directly on to the disk, but you have to use flux changes with different length. So you need additional hardware to code/decode the flux changes to binary bits. These bits you may access with an UART/USART. But I didn't and won't think about this in detail.



    PAW

  • USRT (!) COM2601

    https://datasheetspdf.com/mobile/1412055/SMSC/COM2601/1


    Einen WD1660 kenne ich nicht. Vermutlich ist der WD1770 gemeint...

    Did I menition I've had about 9 hours of sleep since Sunday?


    Yes, WD1770.


    I'm going to stop typiing until I've had a rest!

  • Well, I have had some sleep and come back to the boards.

    I removed the 74121 from it's socket (61) on the I/O board and set it to test on my prototype board.


    Dead! No Q or !Q so that needs replacement.


    It's tempting to jumper !Q high on the board, plug it back in and see if it freaks out...


    Phil

  • Unfortunately that had little effect upon the overall behavior of the computer.


    However, one thing to note was when it did decide to beep, it was with a very clear tone. No crackles as it was doing before (switching the beep on and off very rapidly by the sound of it).


    What I am doing is trying to make a photographic record of what printed wire goes where. This side of the board they've generally kept to vertical traces, the back side horizontal. There are many vias which makes tracing them awkward but I'll do my best to create a schematic of at least the CPU and I/O boards to begin.


    Phil