C-Lab Export: unidentified IC

Somewhere to chat about MIDI music creation, sequencers and related hardware

Moderators: Mug UK, lotek_style, Moderator Team

czietz
Hardware Guru
Hardware Guru
Posts: 717
Joined: Tue May 24, 2016 6:47 pm

Re: C-Lab Export: unidentified IC

Postby czietz » Fri Jan 26, 2018 12:27 pm

czietz wrote:
Foxie wrote:What I'm currently trying to figure out is how they're writing to the cartridge port. The old trick uses the address lines as data, and it could be the Unitor uses that trick too. But it looks like the Midex uses another trick I'm not aware of. Somehow, they're able to get the data to appear on the actual data lines without causing a bus error.


I'm certainly interested in what you find out in that regard.


Never mind; I think I figured it out myself.

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: C-Lab Export: unidentified IC

Postby Foxie » Fri Jan 26, 2018 7:12 pm

Fujiyama wrote:From what you're saying above you appear to know what the Unitor -N and -C looks like from the inside, but if not -would you like me to take some photos of the Unitor-N circuit board?


I've seen inside the Unitor-C, which I assume is the same as the Unitor-N just with different programming. So no need to worry about taking pics of that, at least for now ^.^


Fujiyama wrote:Oh, another thing: I can't remember if it's already been discussed but someone asked me if there's an MROS driver for C-Lab Export which allows it to be used with Cubase on the ST? I heard somewhere that there is such a driver, but I haven't been able to find it anywhere.


There is, I've attached it here ^.^

It should also work with a simple Modem port to MIDI cable, but you should select only "Modem 1" in Cubase and not use 2 and 3.


czietz wrote:Never mind; I think I figured it out myself.


Would you mind sharing your theory? I haven't figured it out yet.

I did think of one solution that might work. But I don't know if Midex uses it. You could read a "magic" register in the cartridge port space to prime the hardware for writing. And then you write your data byte to ST RAM, as a single byte access. The hardware watches for /UDS or /LDS going low after the "magic" register access. When they do, it "sniffs" the data bus to read the data. Instruction and video fetches are ignored because both /UDS and /LDS activate at the same time which the hardware ignores.

So:

write_byte_d0
move.w sr,-(sp)
move.w #$2700,sr ; Interrupts must be off for this
tst.b $fffbffff.w ; Read magic register
move.b d0,-1(sp) ; Write data to ST RAM
move.w (sp)+,sr
rts

I've heard the Falcon's cartridge port isn't 100% compatible with the ST. I don't know why. There is a modification for the Midex to make it Falcon compatible. This might be related to how the writes are done.
You do not have the required permissions to view the files attached to this post.

czietz
Hardware Guru
Hardware Guru
Posts: 717
Joined: Tue May 24, 2016 6:47 pm

Re: C-Lab Export: unidentified IC

Postby czietz » Fri Jan 26, 2018 8:15 pm

Foxie wrote:Would you mind sharing your theory? I haven't figured it out yet.

I did think of one solution that might work. But I don't know if Midex uses it. You could read a "magic" register in the cartridge port space to prime the hardware for writing. And then you write your data byte to ST RAM, as a single byte access. The hardware watches for /UDS or /LDS going low after the "magic" register access. When they do, it "sniffs" the data bus to read the data. Instruction and video fetches are ignored because both /UDS and /LDS activate at the same time which the hardware ignores.


It's nearly like you guessed. In the MIDEX driver, you can find long code sequences such as...

Code: Select all

00000A38                 ori     #$700,sr
[...]
00000A4E                 lea     ($FA0030).l,a0
00000A54                 movea.l $52(a5),a1
00000A58                 move.w  #$803,d0
00000A5C                 tst.w   (a0)
00000A5E                 move.w  d0,(a1)
00000A60                 move.w  #$903,d0
00000A64                 tst.w   (a0)
00000A66                 move.w  d0,(a1)


A1 points to RAM. So, the Midex is indeed triggered by a read access and snoops the data from the data bus during a following RAM access. The one detail I didn't figure out yet: how does the Midex distinguish between instruction and data accesses, given that a "MOVE.W" is used here (and not "MOVE.B" like in your example)? I can see that the value of A1 is calculated before to be $xxxx30, so probably they use the address as a safe-guard, but what if for some reason the instruction fetch is from $xxxx30 as well?

User avatar
Fujiyama
Atari Super Hero
Atari Super Hero
Posts: 637
Joined: Thu Jul 12, 2007 8:21 am
Location: Norway

Re: C-Lab Export: unidentified IC

Postby Fujiyama » Fri Jan 26, 2018 11:04 pm

Thanks Foxie for the Export driver!
I have just about all the C-Lab devices (except the Unitor-N), so let me know if you need any more photos.
Mega STe | MonSTer (Mega STe) with dual IDE-CF memory card adapter | STe | SM-144 |NEC Multisync 1990SXi | IDE doubler | ST_ESCC | RSVE | ICD Link II | Link '97 | HD floppy drive/AJAX | HD floppy module | Minolta PCMCIA card-drive | Realtime Clock module | Discovery cartridge | Unitor-2 | Export | Combiner | Steady Eye | Human Touch | Unicorn USB

Are you a good person?

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: C-Lab Export: unidentified IC

Postby Foxie » Fri Jan 26, 2018 11:55 pm

czietz wrote:A1 points to RAM. So, the Midex is indeed triggered by a read access and snoops the data from the data bus during a following RAM access. The one detail I didn't figure out yet: how does the Midex distinguish between instruction and data accesses, given that a "MOVE.W" is used here (and not "MOVE.B" like in your example)?


Could it be that it counts accesses? There's a fair number of flip-flops in the Midex and also a GAL for address decoding and perhaps a state machine. It would need to skip the three accesses in between. Do they ever use a different sequence of instructions to access the Midex? If it's always that exact sequence, it could well be a counter.

This would also explain why it needs modifying to work on the Falcon - the video fetching is completely different. Assuming the video fetches are even visible on the cartridge port? Also there's the cache. I've got the schematics for Midex courtesy of guus.assmann and also the details of the Falcon modification, if you'd like to study them. There's a GAL file, it might be possible to convert that into a human-readable form. I'm guessing the Midex works on the MegaSTE with cache enabled? If so, I don't know how.

Have you managed to figure out anything about the internal workings of MROS drivers from looking at the Midex driver? Or the specifics of the Midex? I've identified a few registers in the hardware, but I don't know where they're mapped yet.

If the video fetches are visible on the cartridge port, I guess that means someone could design an HDMI output cartridge. It would sniff the video data and convert it to HDMI. It could also contain a graphics card accessed via the Midex method for higher resolutions. Or perhaps a slow-scan framestore like the Amiga high-res mono monitor. Interesting possibility.

The Unitor also contains a GAL, though I don't know whether there's any connection between the address and data bus yet. It might use a different method.

czietz
Hardware Guru
Hardware Guru
Posts: 717
Joined: Tue May 24, 2016 6:47 pm

Re: C-Lab Export: unidentified IC

Postby czietz » Sat Jan 27, 2018 9:18 am

Foxie wrote:Could it be that it counts accesses? There's a fair number of flip-flops in the Midex and also a GAL for address decoding and perhaps a state machine. It would need to skip the three accesses in between. Do they ever use a different sequence of instructions to access the Midex? If it's always that exact sequence, it could well be a counter.


Yes, it could be. It's always the same code sequence "tst.w (aX); move.w dY,(aZ)" that I see in the driver. On the 68000 there will always be a instruction prefetch cycle after the cartridge port read, then there will be the write access that needs to captured.

Foxie wrote:This would also explain why it needs modifying to work on the Falcon - the video fetching is completely different. Assuming the video fetches are even visible on the cartridge port?


As far as I know, video accesses are not visible on the cartridge port. At least for the ST; they are done between MMU and Shifter only. But the 68030 will access the bus differently, so counting the access cycles probably fails. (On the other hand, I read somewhere there was a different Midex driver for the TT, maybe they tweaked the code sequence accordingly?)

Foxie wrote: Also there's the cache. I've got the schematics for Midex courtesy of guus.assmann and also the details of the Falcon modification, if you'd like to study them. There's a GAL file, it might be possible to convert that into a human-readable form. I'm guessing the Midex works on the MegaSTE with cache enabled? If so, I don't know how.


Aren't the caches write-back? So the write access will be visible; however cycle counting could fail if the instruction fetch is a cache hit...

I have the schematics as well, but not for the Falcon modification, so I don't know what they changed there.

Foxie wrote:Have you managed to figure out anything about the internal workings of MROS drivers from looking at the Midex driver? Or the specifics of the Midex? I've identified a few registers in the hardware, but I don't know where they're mapped yet.


I haven't figured out much. I looked specifically for the way they use to write data. I didn't care for the function of the other registers. As the address decoding is done in the GAL, wouldn't disassembling it be the key to find the addresses of the registers you have already identified?

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: C-Lab Export: unidentified IC

Postby Foxie » Sat Jan 27, 2018 2:33 pm

czietz wrote:Aren't the caches write-back? So the write access will be visible; however cycle counting could fail if the instruction fetch is a cache hit...


That's the reason I was thinking of. I think the Midex predates the MegaSTE so there can't be any hardware workaround for that. But the driver might have been updated since, and could disable the cache before every access.

Will the 030 access the bus one instruction at a time, or does it fill its cache in "bursts"? I imagine the TT is more complicated with a 32 bit bus.


czietz wrote:I have the schematics as well, but not for the Falcon modification, so I don't know what they changed there.


I've attached the pdf. I haven't looked into the modification in much detail yet.


czietz wrote:As the address decoding is done in the GAL, wouldn't disassembling it be the key to find the addresses of the registers you have already identified?


Do you recommend any particular software for disassembling it?
You do not have the required permissions to view the files attached to this post.

czietz
Hardware Guru
Hardware Guru
Posts: 717
Joined: Tue May 24, 2016 6:47 pm

Re: C-Lab Export: unidentified IC

Postby czietz » Sat Jan 27, 2018 4:02 pm

I don't know which accesses can be seen on the TT or Falcon cartridge port.
Thanks for the PDF; it's more complicated that I thought. It'll need quite a lot of reverse engineering to understand what the Midex Falcon patch does.
As for the disassembler: I'm lucky to have access to IDA. It's maybe a little overkill (and overpriced) just for disassembling Atari binaries. Maybe someone else can recommend a free disassembler?

User avatar
Foxie
Captain Atari
Captain Atari
Posts: 354
Joined: Wed Feb 03, 2016 7:12 pm

Re: C-Lab Export: unidentified IC

Postby Foxie » Sat Jan 27, 2018 11:14 pm

czietz wrote:As for the disassembler: I'm lucky to have access to IDA. It's maybe a little overkill (and overpriced) just for disassembling Atari binaries. Maybe someone else can recommend a free disassembler?


For disassembling Cubase drivers, I've so far used TT Digger. It seems OK for the purpose. There's a lot of data mixed in with the code though which complicates it. Does IDA make the task significantly easier?

I'm not sure what kind of tools are needed to disassemble the GAL file though. I suppose the ideal outcome would be to turn it into a schematic somehow.

I'm pretty amazed they didn't use a microcontroller in the Midex actually. They did in the SMP24, so it's not as if they didn't have access to programming tools. The Log3 does use an MCU, but not the Unitor.

czietz
Hardware Guru
Hardware Guru
Posts: 717
Joined: Tue May 24, 2016 6:47 pm

Re: C-Lab Export: unidentified IC

Postby czietz » Sun Jan 28, 2018 11:11 am

Foxie wrote:For disassembling Cubase drivers, I've so far used TT Digger. It seems OK for the purpose. There's a lot of data mixed in with the code though which complicates it. Does IDA make the task significantly easier?


I have never used TT Digger, so I cannot compare. Sorry.

Foxie wrote:I'm not sure what kind of tools are needed to disassemble the GAL file though. I suppose the ideal outcome would be to turn it into a schematic somehow.


I used JEDI on the Atari for that once. (I think it's only available in German, though.) But you won't get a schematic but the logic equations that define the GAL. A GAL has a very simple internal structure for a PLD. It's just selectable inputs combined by AND, the output of the AND gates combined by OR ("sum of products"). In registered mode you get some flip-flops on top on the outputs, nothing too complicated.

Foxie wrote:I'm pretty amazed they didn't use a microcontroller in the Midex actually. They did in the SMP24, so it's not as if they didn't have access to programming tools. The Log3 does use an MCU, but not the Unitor.


I think in the early nineties MCUs were still much more expensive than a whole lot of 74xx logic and a PAL/GAL.


Return to “MIDI Software and Hardware”

Who is online

Users browsing this forum: No registered users and 1 guest