Dear Maximo, I've made a quick update to the driver software. It wasn't that hard to realize the changes you've mentioned (thanks to modular programming!). Now a quick explanation to the new options so that you can test easily: ************************************************************ ************************************************************ New AmiCDEx (Amiga driver) commands: (2.2BETA 68020 version) Now AmiCDEx looks for both board types (C= & GOLDENGATE=0x2017/9). GOLDENGATE Switches AmiCDEx for Goldengate operation mode. (Automatically set if a Goldengate board is found). GOLDENIRQ=irqvector (e.g.GOLDENIRQ=0x81 , defaults to 0x80 as suggested by you). Giving GOLDENIRQ also sets GOLDENGATE flag to TRUE. BASEADDR=adr Again will override any board detection. However using this with GOLDENGATE option will force running in Goldengate mode. (You may use this if anything goes wrong in board detection). AMIGAGOLDEN This switch is for me while I trying to simulate that IRQVECTOR detection works. I have simulated a Goldengate mode using 0x219000 as IRQ VECTOR base. Since 0x200000 offset is occupied by other CBM software. Some examples: run AmiCDEx SERVE DEBUG DEVICE=your.device UNIT=unit# If autoboard detection functions it should go into Goldengate mode.If this fails try: run AmiCDEx SERVE DEBUG DEVICE=your.device UNIT=unit# GOLDENGATE BASEADDR=0x200000 If this also fails try: ************************************************************ ************************************************************ AmiCDEx.SYS Options: /G or /I (both are the same) /G -> Switch to goldengate mode & use default vector 0x80. /G:0x81 (or /I:0x81) use 0x81 as irqvector. /R -> Switch to simulated goldengate mode (not for you). /T -> Switch back to real goldengate mode (explained below). /V -> As usual verbose operation. The first thing you have to do is you cannot install AmiCDEx.SYS using DEVICEHIGH command. Instead use just DEVICE command as follows: DEVICE=C:\DOS\AMICDEX.SYS /G /V (Default installation with name MSCD000 , Goldengate mode , irqvector=0x80). A problem arised when I tried to allocate communication memory at run-time . As you mentioned that Amiga can see only the lower 512K of PC base memory, this will cause problems if DOS gives memory above 8000:0000. Inorder to fix this problem I have included another BSS section into the driver with an array of ~2400 bytes. This always be located in lower DOS memory (<512K) like the driver software. That is why you cannot use DEVICEHIGH command anymore. A quick hack to AmiCDEx.SYS let me to change options after installing it. Now AmiCDEx.SYS accepts commands just like a character device.For example: echo >MSCD000: /I:0x81 Will change irqvector at run-time and initialize it with new values. If ever a program trashes the default vector 0x80 you may just echo a dummy line: echo >MSCD000: /V The options /R and /T were just for me (they will not be present at release version). With the echo trick above I could switch back & forth between real & simulated goldengate modes. ************************************************************ ************************************************************ Now to the internal operation: AmiCDEx.SYS: With switching to /G mode the driver uses a communication base which is placed into the driver software (BSS section). It then installs this address into the irqvector: (0x80) DEBUG-> d 0000:0200 19 10 21 80 00 00 etc. (1910:2180 is an example). That is read by amiga as 0x19102180 at offset 0x200200 (irqvec=0x80). (All long/ulong transfers are done with motorola mode). Then Amiga converts to this a real address offset: (0x1910<<4)+0x2180 = 0x1B280 . This gives the real PC offset from board addr (0x200000) and adding that value it finds 0x21B280. At that place the PC installs a keyword 'GOLD' (0x474F4C44). You can check this on PC side: DEBUG-> d 1910:2180 (or the equivalent is 1000:b280) 1910:2180 47 4F 4C 44 00 00 etc. or on Amiga side: m 21B280 21B280: 47 4F 4c 44 00 00 etc. The real communication base starts at the next location to 'GOLD'. That is +one ULONG (1910:2184 or 0x21B284). If everything goes well till this point the driver should run OK. ************************************************************ ************************************************************ Remember: That Amiga checks every 1/50 secs (VBL) the IRQVECTOR. If the PC is reset & the irqvector table is cleared , amiga detects this and switches to a dummy AllocMem()'ed communication base address (Since most of the routines assume that the communication base address must be present at run time , this was necessary). However, this does not mean that Amiga driver locks with its internal stuff, rather it keeps watching IRQVECTOR (0x200200). If ever a value other than zero is installed there (PC boots & reloads AmiCDEx.SYS), then again it checks for the 'GOLD' keyword pointed by it. If that is also present then the communication port address is learned again and the driver switches back to normal operation (You can see this process in DEBUG mode, AmiCDEx informs whenever a msg_base change occurs). If for some reason a program trashes the IRQVECTOR , most probably the 'GOLD' keyword would not be present at the calculated location & AmiCDEx goes back to 'dummy' mode. So what all these are meaning: Start AmiCDEx always with DEBUG (+ INFO ) mode to see which base address is used currently. If it says something like 0x78ddcc0 , then it is in dummy mode and has no connection with PC (the PC driver is not installed yet , or something goes wrong with the IRQVECTOR detection). Check the vector manually using an amiga asm-monitor (0x200200). Anyway , send me the whole debug output if you cannot succeed in installing the drivers. Hope you will succeed & I'll eventually release a version that supports both C= & G= boards. Please report Best Regards, - Adil Temel