Analysis and reverse engineering of the X-Modul (Vortex)

[SerErris]

Hi all,

I had one in my own CPC history and after getting back to the CPC I wanted to have one. 

Now I got my hands on a X-Modul for the Vortex F1-X/M1-X series with VDOS 2.11-X.

I am going to do a full analysis and reengineering to get this back to live and giving all the opportunity to have one.

So lets start:
Here is the first picture of the assembled module. This one comes without the RS-232 Interface, so it is actually just a ROM module that then interfaces with the DDI-1. DDI-1 is required to run it. The CPC will crash if you only attache the X-Module. Looks like it just jumps into AMSDOS (requires AMSDOS from DDI-1) and if that is not there - it will just fail.

Definitely the initialization routine could have been better, to just stop init when no AMSDOS is available but anyhow. This was 30+ years ago.

You cannot view this attachment.

Log of activities:
Disassembled (actually only opened it), cleaned it and put it to the test with a DDI-1 and a FD-1. Works like a charm - if you connect it the right way. If you just have the interface it is pretty easy to connect it upside down and no surprise - nothing works anymore. 

After getting it run it greeted me with the nice Vortex copright and the VDOS 2.11-X message.

I could not resist - |XMON was a must. The first monitor I ever used and still going strong.

Then I continued with my task:

I desoldered everything from the board, and ran the two sanded chips through my logic probe (actually my eprom programmer, that can do logic tests) and it gave me those two chips:

74LS86 (XOR)  and 74LS367 (6-bit Buffer with latch). 

We will see in the next few days, how those are getting put to work.

Here is the backside of the module: 
You cannot view this attachment.

Please be aware of the botch wires. I am not sure if that is a factory installation or a repair. 

I will come to it in the next section, why I suspect it could be a factory change to the board layout. It is actually possible that the PCB has a bug and they needed to get it repaired without throwing the production of PCBs away. In the 80s labor was much cheaper than PCB production. So just get someone to repair it.

So what are the next steps:
Stripping everything from the board and start redoing the schematics. That is kind of a long process. For "reproduction" I also will create a simplified schematic (actually removing the copy protection). 

Hope that will be an interesting ride for you guys.

BTW: I have read the ROM already with my CPC so I do have a descrambled copy of it. However I am not sure if that works as the ROM crashes in the emulator (WinApe). It should not, but simply does. That is for more analyis on what is going on with it - it did not dive into this subject for now.

[Poliander]

Nice work, I'm very curious to see where it leads to. I hope it is okay to use the pictures you took in the CPCWiki?

[SerErris]

Sure. I have some other pictures as well. That is for a later point in time.

[zhulien]

What is an x module? What does it do?

[GUNHED]

Basically it's a ROM box which provides the Vortex DOS for drives with 0,7 MB Vortex standard format.
Vortex format was supported in Germany by all relevant companies during the commercial era of the CPC (Dobbertin, Vortex, others...).

The X-Modul had (as far as I know) a hardware protection of the EPROM data. You can copy the EPROM, but it's won't work in other ROM boxes.

In addition the X-Modul could be equipped with a serial interface (pretty compatible to Amstrad SIO afaIk).

Today... instead of an X-Modul you would put X-DDOS or VaraDOS (= ParaDOS with Vortex format active by default) in your ROM box.

[SerErris]

Gunhed is right.

It is for me just nostalgy to recreate it. But actually it is really a rombox to keep the EPROM for VDOS and "encrypt it".

Some progress for today:
I have analysed the two ROM captures:
One pulled from the EPROM directly (that is scrambled)
One pulled via CPC directly from the ROM in running mode (that should be not scrambled).

The difference is the following:
The hardware uses two address bits and XORs it with two data bits from the EPROM to actually generate the correct output to the CPC.

CPC_D5 = A2 XOR D5
CPC_D3 = A5 XOR D3

The encryption jumps on every 4 bytes and repeats every &20 bytes. it XORs the databyte with the following sequence:

00 00 00 00 20 20 20 20 00 00 00 00 20 20 20 20
08 08 08 08 28 28 28 28 08 08 08 08 28 28 28 28

That is pretty simple to see on the chracters that due to the nature of the 00 bytes and the 08 bytes are still easy to see in the code.

So it was not really a good way to protect it. However it looks like it was good enough at that time ;-) ...

So this looks like it is all, but I need to continue to reverse engineer the hardware to understand fully what the hardware does.

On with that I desoldered everything from the board and cleaned it. It has two damages (that might be intential) and one that I did create. I also needed to sacrifice the PIN headers, as they could not get removed without melting. But that is not a big problem, I can just put in new ones.

Here are the pictures of both sides and a picture for more reverse engineering.
You cannot view this attachment.
You cannot view this attachment.


The last is both sides put on a scanner and heavily compressed them and then overlayed with two colors to actually see both sides for easier tracing of the lines.

Red is front, blue is back.
You cannot view this attachment.

I started with Kicad to get the logic right and I can tell you this is quite time consuming to get all traces right. It is looking at the schematics, and measuring the path to ensure you got it right.

Also I will enhance the blue/red picture and add missing traces. (they are not really missing, but are drop outs of the massive editing).
Getting my Wacom tablet to work :-) That is much easier than with a mouse.

[GUNHED]

Back the day Vortex would have needed you! 

[SerErris]

The difference is the following:
The hardware uses two address bits and XORs it with two data bits from the EPROM to actually generate the correct output to the CPC.

CPC_D5 = A2 XOR D5
CPC_D3 = A5 XOR D3

Correction: This is confusing as hell - esp. the bit banging here. And me confising Bit 0 and 1 all the time (where do we start to count again) ...

Correct is (validated by hardware now):
CPC_D5 = A2 XOR D5
CPC_D3 = A4 XOR D3

I have worked yesterday on the Seethroug diagram including now a lot more details. I added a lot of layers, that I can use to see all details I need, and that includes the Pin Names from the diffrent parts as well as the CPC Pin names from the connectors.

on JPG it looks a little bit overwhelming as all layers are in place (including the silkscreen print).

You cannot view this attachment.


One finding are the two botch wires I mentioned above.

It actually looks like there is a design error in the board, where they exchanged two pins of the 74LS260 chip (5-NOR). In the original PCB layout ~WR connected to Pin 3 (1C) of the chip and D7 connected to Pin 4 (2A). Actually that does not make sense and they exchanged them, by cutting the two lanes on the PCB and reconnecting them with the botch wires. (pink in the layered picture).


After all that ground work, I can now continue with the schematics, which is much simpler to do now.

[SerErris]

Okay I am done with the Schematics. 

Pretty complex stuff for just a ROM selector. Esp the stuff around the line buffer - maybe required because of the XORing of the data bits 3 and 5. But I still do not understand why the did it with the buffer. This complicates the layout a lot.

Also they put in some resistors in between the connectors (75 Ohm) I am not sure what they have used that, I have never seen it on any other adapter.

Okay - next step will be creating a new PCB.

[zhulien]

What is special in the ROM?  If it is just to use the xddos 704k cpm format, then the super.rom and amsdos80.rom does exactly that.

[SerErris]

Special is, that it was one of the first to support DD 5.25 and 3.5 inch disks (afaik).

Also very special is by now, that they implemented a rom scrambling mechanism.

Coming back to the scrambling mechanism again ... this is just wow.

As stated above the did not only used the A2 and A4 bits to XOR it with D3 and D5 bits of the EEPROM, they made it even more complicated.

I now understood what the buffer is for. They actually using the state of the ~M1 line (Z80 is fetching the command byte of a new command) to switch scrambling on and of.

So not all the bytes are scrambled. Only the data bytes or address bytes are scrambled, the original command byte (the first byte of the command AFAIK) is unscrambled.

It must have been a nightmare to scramble the EPROM to actually work in the setup.

Here is a diagram I created with a logic simulator to actually understand how it works.
M1 low (=M1 cycle command fetch)
You cannot view this attachment.
M1_high = data fetch (other bytes of the opcode or data to fetch because of the command).
You cannot view this attachment.

One could ask, why did they make it so complicated?

The answer is - what I tried to pull the ROM off the CPC does not work, because you will get scrambled opcodes.

That is pretty much clever. 

@GUNHED how did you unscramble the ROM without knowing what byte in the EPROM is a Opcode and which one is a data byte?

I am still trying to understand how they created such a ROM. That must have been done automatically by the Assembler ... strange.

[GUNHED]

Well, would it be possible to make program to decode Vortex DOS ROMs in a way that they can be used in a regular ROM box?

[SerErris]

That is what I am traing to achieve. Then the whole X-Module is not required anymore.

X in X-Modul must stand for XOR pain.

[SerErris]

@Bryce 

coming to opcodes FD (IX register prefix), I need to understand if the next byte read by the CPU still will have M1 active. 

So would it be FD (M1 active) E5 (M1 active)?

I am asking, because this part of the ROM creates an invalid opcode with my current disassembler tweaking.

I am currently using the z80dasm and have patched it, to read and unscramble the bytes. For now I only keep the first databyte unchanged - however it looks like that the FD E5 is in clear text in the ROM. So it would be entirely possible the the Z80 has M1 line active for both fetches.

Any idea how I could figure that out?

[GUNHED]

&DD - IX
&FD - IY

[SerErris]

Yep - I know... that is not my issue :-)

My issue is here:

Code Select Expand

vdos_init:
    call 0b912h        ;c1e9    cd 12 b9     . . .
    or a            ;c1ec    b7     .
    jp z,cpm        ;c1ed    ca 44 c3     . D .
    defb 0fdh,0edh,0ddh    ;illegal sequence        ;c1f0    fd ed dd     . . .
    push hl            ;c1f3    e5     .
    ld hl,(0b1b8h)        ;c1f4    2a b8 b1     * . .
    ld e,a            ;c1f7    5f     _
    ld a,h            ;c1f8    7c     |

...
So I do think that the illegal sequence is actually:
fd e5 d5

That would be then

push iy
push de

and would also make perfect sense.

Anyone has any idea on how I could find out the M1 signal handling for the FD and DD opcodes?

[SerErris]

Okay, found the info:

Here you can clearly see it, yes FD and DD are really just prefixes that actually cause a new M1 cycle and load the next opcode.

https://floooh.github.io/2021/12/06/z80-instruction-timing.html#dd-and-fd-prefixes

So that makes a lot of sense. Continuing to disassemble.

[SerErris]

Okay, switched to z80dismbl. 

After changing z80dasm to do the correct descrambling it still did not got me to where I wanted to be.

I now patched the second diassembler - this time it is written in TypeScript. I never heard before this project of it. However it is one of the best documented source codes Inhave ever seen, and the language is pretty simple to understand. It is JavaScript with strict typing. So VS Code does directly show any mistakes you make and it is much faster. It took me just about 2 hours to make the required changes and now I have run the first disassembling. 

Still a lot of work to do. Unfortunately there is no other way to convert this ROM. At least I could not think of any other way to do it.

I would be really interested who did the existing unscrambled 2.00X Rom. 

[SerErris]

Okay that was hard work .. but I got the ROM INIT process working, so that the Emulator is not crashing.

You cannot view this attachment.

However I would say 95% of the heavy lifting has been done so far.

The proceedure is the following:
1. Modify the disassembler, that it can cope with the scrambled rom
2. Modify the disassembler that it can write proper sjasmplus code.
3. Create a label file with as much labels as you can get your hands on. I compiled one from the VDOS manual, the Firmware manuals and some other sources to identify a lot of the addreses.
4. Create a list of entry points from outside (e.g. jump table and any other ROM entrypoint you can find).
5. Run the disassembler. It really does the heavy lifiting - It walks to every entry point you have defined and creats code segments and stiches everything together.
6. cleanup the assembler code - there are two illegal ops in there (NOPs most probably), that needs further analysis. For now they need to get changed into DB/Byte values, that the assembler can keep them in the ROM.
7. Put the ROM in WinApe and ... see it crash :-) It greeted me with "VDOS blabla, Press Play ..."message. So that was not the envisioned outcome :-)
8. Debug trace the operation (put a breakpoint into C006 for a start) and then go through it. You have the assembly code already, that is much easier. Check at which point it stops working. 
9. Find out, that the ROM Vectors has changed entries from the ROM, and that if you jump to it, you land in scrambled data area. Obviously another missing jump in point. Add that to the list (4.) and start over 5. again. 

And voila ... here is the answer. 

The init completes and runs. No other function has been tested yet and most probably it will break as well as long as it does not use one of the known entries. 

I like when plans work out :-)

[SerErris]

And this nice feature works.

|ROMCAT
You cannot view this attachment.