Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Olympia People - a nice, but failed attempt

  1. #11

    Default

    Sorry for not posing earlier, was busy trying to get data on Olympia.

    So far - noticed that all three 5.25 inch drives I have are 360K - I did expect, that at least one would be 1.2 MB

    I tried all floppies which came with the computer, and so far I have a very limited success in communication - I can actually connect via serial port to another PC, but data transfer is another story:

    Laplink 5 is able to start installation, it even successfully copies remrcv.com file, but then quits
    P1005707.sized.jpg

    Laplink 3 - is able to access the floppy, but immediately disconnects, because of wrong com port message
    Kermit - only once I heard Olympia drive access when using send, but that's all - timeout, retries, and no success
    530 - can access flopy drive, then fails, because can not do anything else
    Even MS-DOS copy to COM1 results in a floppy drive access on Olympia, following by a series of very unsatisfied beeps from it, but no file is created

    I can only use supplied V24 program, which allows me to set serial port parameters, but it is actually not COM1 I believe, this might be why all installs are failing. As for CTTY, I can only use CTTY AUX instead of COM.
    P1005709.sized.jpg


    Besides, I'm not even sure if the copied software is fully compatible with Olympia People - remrcv.com seems to be broken, and kermit on one of supplied floppies just hangs or makes weird screen glitches. I'm starting to think maybe the software has to transferred on Olympia as text, then converted to binary format on Olympia itself?
    Last edited by Adventurer; September 18th, 2018 at 12:23 AM.

  2. #12

    Default

    At least some success - copy /A to com1 at 600 baud speed works, characters are correctly displayed on the Olympia's screen! However, using Olympia's proprietary AUX2FILE command, which should save input from serial to file, results in 0 byte files, although floppy drive seems to working normally during transfer...Any hints, tips, ideas? Already feeling my head spining, trying to finally find a reliable file transfer for this
    P1005711.sized.jpg

    In other words, and after many retries:

    * Text files transfer on Olympias screen works properly - fine, but useless
    * Saving text as file on Olympia only appears to work - disk drive works at intervals as if the data has been written, but there are two problems:
    - Nothing is actually written
    - End of file message is not being received from the host, resulting in machine becoming unresponsive even after end of file transfer
    * Modifying word length, bits and other settings do result in some (though partially corrupted) data written to the floppy, but it disconnects very early like if end of file already received. Faster connection types result in more data written.

    By the way, it appears that monitor output is a standard D-Terminal connector, which was in widespread use only starting in late 90-ties. It has a standard 8 pin DIN plug at the other end, so it will be very easy to make a monitor wire longer.
    P1005702.sized.jpg
    Last edited by Adventurer; September 18th, 2018 at 04:54 AM.

  3. #13
    Join Date
    Feb 2012
    Location
    Cambridge, UK
    Posts
    6

    Default

    I managed to play around with an Olympia People a few years ago. A nice, solidly built computer - very easy to get inside and all the frames holding the power supply and floppy disk drives slide out just by loosening a couple of screws. Unfortunately it stopped working after (I think) the graphics RAM developed a fault and I ran out of time to keep working on it. At the time MAME/MESS had it implemented as a standard PC clone, but I see there was a commit in 2015 that fixed it to be much closer to the actual hardware. As others have pointed out it's DOS compatible but nowhere near the IBM PC memory/IO port layout, and only a simple boot/monitor ROM instead of a full-featured BIOS.

    While I can't help you with your data transfer problem, I've attached my notes from when I was disassembling the boot ROM - perhaps they will be of use to someone.
    Attached Files Attached Files

  4. #14
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    28,212
    Blog Entries
    20

    Default

    You say that the drives are "360K", but in this case, that's a little misleading. Single-sided 96 tpi is "360K", even though the term isn't usually used in connection with 96 tpi drives. What drives do you have in your People? (model and make)

  5. #15

    Default

    Quote Originally Posted by Chuck(G) View Post
    You say that the drives are "360K", but in this case, that's a little misleading. Single-sided 96 tpi is "360K", even though the term isn't usually used in connection with 96 tpi drives. What drives do you have in your People? (model and make)
    I did not mean Olympia drives are low density, these drives I mentioned were my other 5.25 inch drives. I hoped to write some extra images with ImageDisk to use with Olympia, but now have to get correct drive first. Olympia People drives are high density, but either drives or controller does not allow to write more than 640K on a single 5.25 inch floppy. Here is the close up of the Olympia drives.

    P1005692.sized.jpg

    I did not remove them to check the exact model. I will do next time when I will open the computer. So far, fingers crossed, Olympia itself works flawless, all smoke tests passed, and running around 8 hours a day. And I did notice the data are actually written when transferring from my Toshiba Libretto, unfortunately only found as lost fragments with CHKDSK...

  6. #16
    Join Date
    Jan 2007
    Location
    Pacific Northwest, USA
    Posts
    28,212
    Blog Entries
    20

    Default

    Woah--"high density" generally means that media and a drive uses data clocked at twice the original SA400 rate. So, a bog-standard PC "360K" drive is "low density" because it records data at a rate of 250kbps while spinning at 300 RPM. A high-density 5.25" "1.2M" drive records data at 500kbps while spinning at 360 RPM. The "360K" drive uses a track to track distance of 1/48" or 0.53mm. The "1.2M" drive uses a track to track spacing of half that of 1/96" or 0.26mm.

    High density media is very different in terms of magnetic characteristics from "low density" stuff.

    Note that bit density recorded is independent of track spacing. An old convention was to term 250kbps data written at 96 tpi "quad density", but I haven't seen that term in years. And it doesn't address the issue of what one calls 100 tpi drives (obsolete?).

    I find it's more useful to specify the format in terms of sectors, sides and cylinders. So, 256/16/2/80 specifies a disk formatted to 16 sectors of 256 bytes on 2 sides occupying 80 cylinders = 655360 bytes or "640KiB"

    A pet peeve that I have is the 3.5" "1.44MB" disk. Work it out--it isn't any of that. It's 1440 KiB but not 1.44MiB.

  7. #17
    Join Date
    Dec 2005
    Location
    Toronto ON Canada
    Posts
    6,961

    Default

    Quote Originally Posted by Chuck(G) View Post
    ...And it doesn't address the issue of what one calls 100 tpi drives (obsolete?).

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •