OPLxLPT adapter for ST/TT/F030

[Badwolf]

Sounds great! (& good spot, @czietz)

BW

[nokturnal]

@Czietz thanks! I will check it and fix it. I've started to add same capacitance to gnd (same as on probe 220kOhm 12pF), but I wasn't 100% sure about it.

I also think that adapter would be better if output would be aligned with case and directed upward. But still there will be audio and usb cables directed upward, so I don't know if I should.

[nokturnal]

Something like this will be better?
OPLxLPT pins 25, 24, 23, 22, 21, 20, 19,18 are connected to GND via resistor (got schematics from manufacturer). So, I've connected those signals to 18-15 GND on Atari side and connected shielding one to another:

OPL3LPTAdapter_rev.2.png

[czietz]

According to the schematics on dev-docs, on the Atari side, too, pins 18 - 25 should be ground.

[nokturnal]

I looked up info from manuals and ST internals book and there is a mention that 18-15 are GND and other pins are unused (whatever that means), but maybe schematics are more accurate in this matter..

[edit:]
Yes, so I revieved all schematics that I had and it looks like 18-25 are connected to GND. Next will be reality check.. :lol:

Other differences:
1) On TT schematics there is no mention about SelectIn and Ack signals, but in user manuals both signals are present (like on Falcon).
2) TT has pull up on /STROBE with two resistors on the /STROBE line (Vcc between 3,3kOhm and 10kOhm resistor (?) looks differently than any other schematics, but I don't understand what they did here.
3) On Falcon there's no pullups on /STROBE signal (an error?)

Here's another update:

OPL3LPTAdapter_rev.2.png

edit2:
I've patched my normal adapter and it seems that problem is resolved. Thanks @czietz :D

[nokturnal]

I've noticed one issue on above schematic and turned out that ground was wrongly connected on opl2/3 switch (ground should be connected to opl3lpt side). It ended in non working OPL3LPT on plain STs (,which doesn't have one wire and without A1 line set to low OPL3 refused to work in OPL2 mode). I've updated the schematics on projects repository.
Last three/four months I spent on software side and I've developed simple driver architecture and ported vgm player from Arduino, reworked it to use new interface, added OPL3 handling and wrote drivers for OPL2LPT/OPL3LPT,OPL3 Express(via Netusbee/Lighting ST). I've got OPL3 Duo and OPL2 Audio board in the pipeline too. Still replay has some issues with tempo (it's too fast on some tunes), but it's not that bad and I think I have another year to iron it out ;).
Link for people not reading AF.

[nokturnal]

Hi, so I've implemented two more drivers for OPL3 Duo! and OPL2 Audio boards. Unfortunately SPI emulation takes it toll on plain STs.

OPL3 Duo!
Atari Falcon 030 with full 030:


Some more advanced tunes with 4OP:


Atari 520ST+


OPL2 Audio board:
Atari 520ST+


There's small room for optimisations, but not much. So, next will be player/timing improvements (it's still not interrupt driven and rather rough), adding more formats and work on dedicated ST cart I guess (at least version not burning mmu's). Ideally I would prefer something more integrated with cpu bus and exposed in memory map. So, to sum things up currently I have support for OPL2LPT/OPL3LPT, OPL3 Express via USB and OPL3 Duo! and OPL2 Audio board. :)

[Steve]

This is very impressive!

[mikro]

Impressive indeed.

When you mention a toll, how much CPU time are are talking about? I'd like to eventually use it in ScummVM so the bigger the gap between OPL software emulation, the better.

Btw is there any performance difference between the aforementioned OPL2LPT/OPL3LPT, OPL3 Express via USB and OPL3 Duo! and OPL2 Audio board? I mean from Atari point of view of course.

[nokturnal]

Yes, on OPLxLPT there is less work (opl chip is directly connected to digital lines). On SPI you need to manage several lines (1 for OPL2 board, 3 for OPL3 board), transfers are by 1 bit by generated clock. On USB there is driver overhead and you are talking to serial device and have to use custom protocol (that's how OPL3 express was made). Amounts of writes aren't big, usally I've seen like ~12 bytes at time depending on tune(but might be more). For SPI/OPLxLPT I had to bypass os calls to speed things up. For exact speeds via SPI I would have to dig up my measurements for F030 and ST from logic analyser. I think there's room for optimisation, but I didn't profile anything yet. I think cart version would have best results (less hassle with setting digital lines).