Olivetti M40 / M44 L1 boot disk

[tpaxia]

Thanks a lot! You are doing truly commendable work—kudos!
The startup screen looks correct to me. At this YouTube link, you can watch the full hard disk boot sequence of an M30 running BCOS II.

As for the ROMs, I’ll do my best to dump them—perhaps next week before I go on vacation.

Also next week, I should have the schematics for the UC042 (CPU) and GO252 (trivalent alphanumeric video) boards in hand.

You can find photos of the GO252 and the GO255/A graphics extension in the Google Drive folder I already shared.
Specifically, my M40 has two of these boards installed: one from 1985 and the other from 1986.

I’ll take this opportunity to provide a complete list of the boards I have:
- GO151 RS232 and current loop interface
- GO252 B/W alphanumeric KDC controller
- GO201B STC 20MB formatter controller
- GO200X STC 20MB controller
- GO363 ST506 interface controller (XU1707/9)
- GO252 B/W alphanumeric KDC controller
- RA57C 1.0 MB RAM
- UC042 Central Unit (M30/40)
Spare parts/extras:
- (2x) GO280B floppy/minifloppy controller
- GO327 RS232 and current loop interface
- GO255/A graphics video extension
- RA57A 2.0 MB RAM
- UC048 Central Unit (M34/44)

If anyone reading this message has a spare monitor to sell or trade, please feel free to contact me privately; I currently have only one, and I would love to get my M40 up and running again with a dual-monitor setup, just like it was over forty years ago.

Thanks, right now the plan is to emulate the uc (mostly done), memory (not a specific board but you pass the amount of memory you want, done), go252 (video done, keyboard missing), go280 (almost done, I got to “5”, the “descrizione di funzionamento” manual was essential to get the Dma and interrupts right), and finally the go363.

While it would be nice to get the description of the arbiter in the uc (it appears implemented in the gate array), I think that enough info can be obtained from the rom and disassembling the diagnostic tests: it seems to be working.

The largest issue I have right now is understanding how the st506 controller works. I can get it recognized and hopefully we can get enough info from the diagnostic tests once they boot.

I couldn’t determine the disk structure to access the files on disks yet (I see the directory but there must be an allocation table somewhere). Once the floppy controller works it should be easy to figure it out…

I updated the reverse engineering documents on GitHub and pushed a M40 branch on my MAME fork.

 

[tpaxia]

OK, major progress, I can read and disassemble all the diagnostic tests described in the "collaudi" and
boot them.
What do you think?


The ST506 HD is next but it requires a µPD7261AD controller which is not in MAME, so it will take a little bit more.

 

[AndrewMag]

Oh, that’s wonderful—things have moved along very quickly! Truly impressive work.

Yes, my friend Stefano Marinelli (the only one currently with working vintage hardware) confirms that the screen looks exactly like that.

The challenge will be figuring out how to handle the HDDs, on real hardware like on emulator. Mine has an 86MB hard drive, likely running the BCOS II system. To that end, I’m building one of David Gesswein’s MFM disk emulators; the goal is to create a disk image right upon the first boot-up After decades of storage.

In any case, installing BCOS would require at least three system-generation floppies (plus a detailed manual that I don't have), but unfortunately, the second disk has some bad sectors. As for the other OSs I mentioned (DOS, ESE, and MOS), I believe even less is known about them—whether floppy- or hard-disk-based—so it would be great to dig deeper into that.

Out of curiosity, did you manage to use 5.25" floppies images with your emulator? The "Linea 1" floppies are rather peculiar; the 8" ones are DSDD, with track 0 on side 0 recorded in FM while the rest is MFM. It seems the 5.25" floppies might use that same bizarre format, though perhaps I made a mistake with the double-stepping settings when creating the images and only detected 40 tracks.


For anyone interested, this is the diskdefs used with Greaseweazle for the Linea 1 floppy disks.
# prefix: olivetti.

# Olivetti M40 1024kB HD floppies
disk m40
cyls = 77
heads = 1
tracks 0.0 ibm.fm
secs = 26
bps = 128
gap3 = 26
rate = 250
rpm = 360
end
cyls = 77
heads = 2
tracks * ibm.mfm
secs = 26
bps = 256
gap3 = 26
rate = 500
rpm = 360
end
end

 

[tpaxia]

Oh, that’s wonderful—things have moved along very quickly! Truly impressive work.

Yes, my friend Stefano Marinelli (the only one currently with working vintage hardware) confirms that the screen looks exactly like that.

The challenge will be figuring out how to handle the HDDs, on real hardware like on emulator. Mine has an 86MB hard drive, likely running the BCOS II system. To that end, I’m building one of David Gesswein’s MFM disk emulators; the goal is to create a disk image right upon the first boot-up After decades of storage.

In any case, installing BCOS would require at least three system-generation floppies (plus a detailed manual that I don't have), but unfortunately, the second disk has some bad sectors. As for the other OSs I mentioned (DOS, ESE, and MOS), I believe even less is known about them—whether floppy- or hard-disk-based—so it would be great to dig deeper into that.

Out of curiosity, did you manage to use 5.25" floppies images with your emulator? The "Linea 1" floppies are rather peculiar; the 8" ones are DSDD, with track 0 on side 0 recorded in FM while the rest is MFM. It seems the 5.25" floppies might use that same bizarre format, though perhaps I made a mistake with the double-stepping settings when creating the images and only detected 40 tracks.

I am booting directly the diagnostics (A.imd..H.imd, R.imd) that you provided that have a 128 byte/sector boot track.
I didn't try the 5" floppies.
Now I am trying to emulate the keyboard since I don't have the scancodes, but I'll get them once I can run the tests.

To do that properly i am finishing building a python harness which drives a MAME m40 with a lua script, builds a model of the screen from the
video memory writes and can send keyboard commands and intercept traces.
The idea is to be able to list and execute all the tests automatically through the python harness and then get detailed logs. The tests are surprisingly granular and can
help figure out the hardware details. I was able to do that with the arbiter before even getting the floppy to work by just locating and disassembling the
arbiter tests on disks.

The ST506 is actually not that bad. It turns out that the controller is already supported in MAME, there is a tiny translation layer and a DMA/interrupt interface similar to the FDC
controller but the tests should be able to help us debug it.

Unfortunately this is the first time I see the M40 in my life, so I don't know how to bring the system up on the hard drive. Hopefully the manuals and images are enough
to install one of the OSes on the HD. Otherwise we'll ask Stefano Marinelli to help us

 

[tpaxia]

Ah, regarding the system bring up, I don't know if the position of the boards on the backplane would make a difference!
Once the system works I'll add the backplane structure to "insert" the boards in a specific slot to make the emulated system
identical to the hardware one has. Then we could just create the HD image and transfer it to the HD emulator.

 

[tpaxia]

OK, the FDC is perfect, the keyboard works, tests are executing and the Python automated test execution harness is working.
Unfortunately I have to stop for a couple of days but I am confident that the ST506 interface will not be that bad.

 

[AndrewMag]

Thank you so much, and congratulations on this fantastic emulator!

Regarding the various open questions, I hope your interest helps us shed light on many little-known aspects of the vintage hardware itself of the L1 M30/M40.

As for the backplane: yes, there is a priority order, and the service manuals should explain it quite well. Essentially, the CPU almost always goes in first, followed by the RAM, and then the various controllers—video, floppy, HDD.

There Is a power-up console that features a tiny display that shows numbers or characters related to the power-on self-test. There is also an "ISL 1-2" selector; I believe it is used to choose whether to boot from floppy or HDD (or, in my specific case, from a 20MB streaming tape).

I hope to soon be able to dump all the ROMs scattered across the various boards for you and provide some schematics.

In the meantime, my friend Stefano managed to boot the floppy disk containing the ESE system—named "MDOS30.IMD"—on his M34 (the latest version with the UC048 CPU); here is the screen for the "ENVIRONMENT" command. We know little about this Linea1 operating system, and we don't have the HDD version.

However, looking closely at the library name "P6FSYS" is enough to make you jump out of your seat: ESE is a complete emulation of the Olivetti P6060 operating system (sorry for the digression, but it's my favorite retro-computer—I own a restored one, so for me, this brings things full circle!). Stefano confirms that the commands are identical to those in the very latest releases (post-4.0) of the P6060/6066 operating system, for which excellent manuals are available online. It would be worth a try—though he couldn't do it himself—to see if the emulation allows for reading 8" SSSD floppies using the P6060 software. That would be an interesting breakthrough; it would mean that the previous "scientific computer" could also be emulated with relatively little effort, wouldn't it?

 

[tpaxia]

In the meantime, my friend Stefano managed to boot the floppy disk containing the ESE system—named "MDOS30.IMD"—on his M34 (the latest version with the UC048 CPU); here is the screen for the "ENVIRONMENT" command. We know little about this Linea1 operating system, and we don't have the HDD version.

I made more progress from reverse engineering the diagnostic tests. Now all these tests pass and the video attributes, keyboard mappings
and motherboard logic seem to be correct.

Diagnostic results so far

Test      Disk  Coverage                              Result
--------  ----  ------------------------------------  ------------------------------
UC3003     A    CPU module, instructions/addressing   PASS, zero errors
UCV305     A    CPU + MMU, violation/trap semantics   PASS (M44 MMU1 section self-skips,
                                                      that hardware isn't present)
MEM813    A/B   Main memory                           PASS
RAMVID     B    GO252 video RAM                       PASS
6030T6     -    FDU / DMA                             Tests 1,2,3,5 PASS; the rest are
                                    o the 5.25" MFDU
KEYTE1     B    Keyboard, alpha + functions/numeric    Expected-code grids now match
CESTE0     A    Multiprocessor      scope (needs a 2nd CPU module)

Unfortunately MDOS30 still doesn't boot properly. I'll try to fix that before adding the Hard drive.

 

[AndrewMag]

Thanks for the updates!
I don't have any major news, other than the fact that I've added a few more files—again from Stefano Marinelli—to the previously linked Drive folder.

Specifically, there are two new disk images: MDOS31.scp and MDOS31util.scp. These also relate to the ESE (the P6060's emulated environment) and have been tested and confirmed working on Stefano's hardware.

Apparently, "MDOS" was the commercial name for the ESE in the German market, though this remains to be verified.

I’ve also added a few manuals—notably the service manual for the very first edition of the Linea 1 (March '82)—which shows CPU boards that differ from the UC042 and UC048, likely predating them.

Another interesting addition is a logic diagram (though I’m not sure if it’s complete) for the RAM. More documents will be arriving in the coming days.

As for the ROMs I was asked about, I’ve hit a bit of a standstill; I can't figure out if the pinout follows a standard like the 2716 or 2732. The part numbers appear to be proprietary—likely SGS—and I haven't been able to track down a datasheet or any useful information to determine the pinout. I’m hoping the upcoming documentation (specifically the schematics) will shed some light on this.

 

[tpaxia]

As for the ROMs I was asked about, I’ve hit a bit of a standstill; I can't figure out if the pinout follows a standard like the 2716 or 2732. The part numbers appear to be proprietary—likely SGS—and I haven't been able to track down a datasheet or any useful information to determine the pinout. I’m hoping the upcoming documentation (specifically the schematics) will shed some light on this.

Thanks. For now I have replaced the font with the M20 font which seems to be similar to the one on the MDOS screen, but it only includes characters 32-127. I don't know if the M40 has other characters outside that range. if you run the KEYTE1 diagnostic on a real M40 you'll see the characters.

It would be great to have a manual describing the ST506 controller, but I don't think it's blocking.

Also the MOS manuals describes the system generation from a "mostro", master system. It's not clear that we could configure one starting from disks. Maybe Stefano has some insights.

 

[Xolod]

Do you plan to add support for M44?

 

[tpaxia]

Do you plan to add support for M44?

Is there any difference? The manual says that M30s and M40s can be converted to M34&M44. Don't they just use higher speed CPU boards?

 

[Xolod]

Is there any difference? The manual says that M30s and M40s can be converted in M34&M44. Don't they just use higher speed CPU boards?

It's hard for me to say how different the CPU board is in the M44; I've attached a photo. But the BIOS on the board is definitely a newer version.

 

[AndrewMag]

From what I gather, the M44 version is based on an upgraded, faster CPU board (UC048)—probably capable of addressing more RAM (?). Along with the new CPU, Olivetti also released new RAM boards (RA57). However, some compatibility with earlier boards was maintained; there is a compatibility chart of sorts in the M34-M44 service manual.

Regarding @tpaxia's inquiries, Stefano told me that the "mostro" system was typically an M60 with specific specs—supplied to Olivetti dealerships—used to generate the MOS installation tapes. He doesn't clearly recall if a floppy disk version existed, but he thinks that if it had, it would have required something like forty or more 1MB floppies to distribute.

What *did* certainly exist was a sort of stripped-down version—perhaps just the main kernel—on floppies labeled "MOS starter," though we don't have any of those at the moment.

On a positive note, I’ve added a "schematics" folder to the Google Drive containing some documentation on the GO252, UC042, and RAM. Now I can study the pinout of those "odd" ROMs to perform a dump.

 

[1ST1]

What a thread here... Very intersting and you do great efforts for the emulation. I am amazed.

I share something with you for a few days, I also have collected things for L1 M40 from different sources, means, the one or other is not new for you, and just 7z-ed them to my basic dropbox. So you may download it from there until I delete it to get space for another file to share...

I still remember the L1 series of mini computers from my time as apprentice @ Olivetti Frankfurt. In our workshop we had a L1 terminal connected to the computer which was some rooms away from our workshop room. The L1 system there (a bigger one, M60?) was running the Olivetti CESIS software on multiple terminals in service center workshop deartements, managemnt rooms, dispatcher rooms, electronics repair workshops, service desk and on across the whole building. This was something like a ticket system to manage repair tasks, service technicians inhouse and external, and warehouse ordering system for spare parts. So we as apprentice took out of the CESIS the typewriter, computer, what ever repair jobs, we got the device from storage and repaired it. And for each repair job we could look into the catalouge and order the parts from the warehouse. Every technician had a number, mine was "12535" to login/register (no password...) and all repair jobs inhouse and onsite at the customers were managed through CESIS. Inhouse we could book the repair job by our selfes, it knew the swapped spare parts and we had to book the time for the job, so CESIS could calculate also the repair costs. Customer onsite technicians had to call central dispatcher peoples which did that for them. So CESIS was also a database with customer adresses, the devices which were under service contract and all the spareparts for even very old devices like mechanical typewriters. CESIS was networked between all branch offices and service centers inside Germany, Europe and maybe even elsewhere. I was also told by someone working in the central germany sparepart warehouse in Frankfurt (Schmickstraße 14-16) that when a sparepar was not available there, CESIS ordered it from Ivrea/Scarmagno factory as the root hub automatically and the parts were delivered with the next truckload of products over Brenner pass from the factory to Schmickstraße. I don't know if other software / system of that era for this tasks on the market was so advanced in functionality in that time. If you buy today an Olivetti (also some Triumph Adler machines, Exxon Quiq typewriters, ...) device they often have black-silver stickers, rectangle with rounded corners, with the Olivetti name in the black top and a long number (example 12-86-xxxxxxxxxxx) in the silver middle area of the sticker. And it's hard to remove the sticker (don't do it!) as it breaks into little squares - that is the CESIS service contract sticker for this machine. Even my Programma 101 manufactured in 1969 has a CESIS sticker from 1986.

One of the apprentices 1/2 years older than me was then trained on the L1 series to expand that team of service technicians, and if I google for him (P.L. at B., if you read this, you got striked here greetings... ), I still can find him with current adress and everything, but, that's now 36+ years ago that we met at Olivetti Frankfurt, so I'm not sure if he still knows something, and if he remembers me or want to... If you can convince me that his help is really required, I can try, but I can't promise you any success.

And something more, slightly offtopic but as it was mentioned here, put a short paragraph on this: 3 years ago I got a P6060 in very bad shape, dusty, rosty, stinky, stored for 20+ years in a not so good environement, but as I didn't have space (still not) for that huge and heavy beast, lookd as a lot of work for restauration, I gave it away to someone (dirk) who already was searching such a machine since long time and wanted to restore it whatever it means. From his examinations of documents and system design I learned that the P6060/6066 is basically compatible to a on minimum shrinked IBM /360 of the same era on hardware and operating system / software level. I don't know if you are aware of this. Last contact was 2 years ago when we tried to read some diskettes which came with that machine with my greazewasle.

Already courious how this story here continues...

 

[culichi]

OK, major progress, I can read and disassemble all the diagnostic tests described in the "collaudi" and
boot them.
What do you think?
View attachment 1325489

The ST506 HD is next but it requires a µPD7261AD controller which is not in MAME, so it will take a little bit more.

@tpaxia I built the olivetti_m40 branch at c7fc49a3 and spent a while running the DCOS 8.4 diagnostic set and the MDOS and ESE floppies against it. DCOS still boots to the Diagnostic Monitor with keyboard and MAP working, so the split into backplane cards did not cost anything I could see.

The refactor also fixed something I had been chasing on the previous build. Back then slot 14 was reported as type 00 while every other empty position reported FF, and MDOS 3.2 would then write ASCII bytes into that window, data at 0xE000 and status at 0xE008. With the modelled backplane the empty positions show **-**** and those writes are gone, so whatever was producing the phantom board is no longer there.

The GO363 enumerates cleanly. With "-slot5 go363 -hard1" and a blank CHD, SYSTEM ENVIRONMENT shows 3 65-0000. I did read your note that IPL search type E4 and handler 0x1e58 belong to the older GO230 18 MB governo rather than to the GO363, whose ID is 65, so I was not expecting the ROM to IPL from it, and it does not.

What I cannot explain is how MDOS 3.2 (M40MDO32.IMD) reacts to it. Without the GO363 present it derails: it ends up executing in segment 1 around 0x0183, which is right next to the stack pointer the ROM leaves at <<1>>0x01c0, and it racks up 345,891 illegal opcodes in a 120 second run, every one of them b800, that is a TRxB with R0 as destination, so it is executing data rather than hitting an instruction MAME is missing. Put the GO363 in with a blank CHD and the illegal opcodes drop to zero. It then settles in segment 7 between 0xB547 and 0xB59D with a blank screen and stays there.

The odd part is what the card actually sees. With LOG_REGISTERS and LOG_TRANSFER enabled, it is touched exactly three times in the whole run, all of them reads of register 0xFF returning 65, and all three coming from boot ROM addresses (00015E, 00028A and 0005A6). Not one transfer is ever issued. So merely having a board of that type in the config table is enough to change the guest's path and stop the crash, but nothing ever asks the controller for a sector. Given that E4 is the GO230 and 65 is the GO363, could MDOS 3.2 be looking for a GO230 rather than the board we have?

For contrast, the rest of that family does not crash at all on this build: MDOS 3.0, ESE and MDOSUTIL all park cleanly in segment 2 between 0x0912 and 0x091E with a black screen, which at least looks like a wait rather than a derail.

The CHD I used was made with "chdman createhd -chs 820,6,17 -ss 512", picked for the 40 MB geometry class mentioned in go363.cpp. If the probe cares about the geometry class at all, that would be useful to know before anyone reads too much into the numbers above.

 

[tpaxia]

@tpaxia I built the olivetti_m40 branch at c7fc49a3 and spent a while running the DCOS 8.4 diagnostic set and the MDOS and ESE floppies against it. DCOS still boots to the Diagnostic Monitor with keyboard and MAP working, so the split into backplane cards did not cost anything I could see.

Thanks, it is still work in progress, I haven’t been able to boot correctly anything apart from DCOS and I am still trying to figure out if some crashes are MMU bugs.
Unfortunately I don’t know how the other Operating systems are configured or if any one of them could boot using the configuration detected by the ROM (like DCOS does).
At least with the bus support one can try different board configurations…

 

[tpaxia]

I think I am kind of stuck!
"BCOS II Release 3.3 — FD ALL RESIDENT" passes the configuration display and after
hitting control+J stops here at flashing C003.

Any idea of what this means? There are no BCOS II manuals I could find that describe this, unfortunately.

 

[AndrewMag]

Many thanks for the update. I'm sorry I can't be of much help for the time being; unfortunately, my L1 M40 has various hardware issues. I hope to fix them in the coming weeks as I proceed with the restoration. In the meanwhile I tried consulting the former L1 technician Stefano Marinelli (who seems to be the only enthusiast currently with working original L1 hardware). He pointed out the following:

Regarding error C003: I’m not sure if I have a detailed description of this specific error handy, but it is one of the worst kinds—representing a system crash or memory conflict. Judging by the photo you sent, the loading process stopped at the initial stage, which involves the Oslem emulator. Under normal operation, BCOS II should start automatically at this point (pressing Ctrl+J accesses the Oslem commands). Therefore, I believe the error originates within Oslem; that is where we should look for the cause. However, a word of caution: if I recall correctly, some of the floppy disks in the archive were already triggering the C003 error on their own. I can confirm that, among the archive's disks, K02733 loads BCOS II correctly; it contains the system procedure for generating operating system disks but—due to space constraints—lacks other commands. Floppy K02741 contains the JJkeyb keyboard driver; I attempted the generation procedure, but it hangs at a certain point with an error I can't identify...
Floppy K02737 also triggers a C003 error during loading.
I am attaching two more floppy images [MDOS30.IMD and eseuco36.scp added to the Google Drive folder]; I believe they differ from the ones I sent previously. They are also German versions—perhaps you could try them with the emulator. Ideally, we should also find the Italian version of ESE 2.0, as it might differ from the German one.