TulioAdriano wrote:I don't know how complicated that would be for Shiru but would be an amazing feature on TFM Music Maker also.
It's possible (and was planned, but in different form).
If somebody develop SMD-PC link and document it well, I'll support that in TFM MM. I can make SMD-side driver by myself or write list of needed features of such driver, if somebody else plan to make that.
The protocol used is relatively simple. 4-bits data, 2-bits for handshaking. I can describe a working protocol in more detail if you like. I think the ISO file contains the source code for the Genesis side, though that's using my older less efficient protocol. I began work on a newer protocol that was both more efficient and more sophisticated, but never finished it. IIRC, basic data transfer worked. If either of you want the source to use as a base, all you have to do is ask.
Cool, but will it work on XP when I do direct I/O from a DOS program ? As much as I have tested LPT port in XP using DOS, I can't manipulate some signals of LPT port (don't remember which ones)...
That will be fine if there is C source code for data transfer through that cable both for PC and SMD. Code must be 100% working because I don't have real hardware to test it by myself.
TmEE, there is some drivers which open LPT ports under XP - DirectIO, UserPort. They allows to old 16/32-bit Windows applications to work with LPT directly, but I'm not sure if they work with DOS software.
Thanks Shiru... I hope these work with DOS programs otherwise I may have to make a different cable than MODs one (IF it doesn't work with/without these drivers).
EDIT : DirectIO didn't help with XP, BUT UserPort did !!!
Shiru wrote:That will be fine if there is C source code for data transfer through that cable both for PC and SMD. Code must be 100% working because I don't have real hardware to test it by myself.
The source code I have is C on the PC side and 68K asm on the SMD side. If need be I could probably whip together and test a C version of the SMD side or alternatively wrap the 68K ASM in some C functions.
Transferring data is definately 100% working. The parts that weren't finished (in the newer code anyway) were the higher level parts of the protocol.
Mask of Destiny, there is also important question: how fast data transfer with this interface can be? To use SMD as synth for music editor it needed to be up to ~16K per second in peak (in worst case for FM part), usually less, but I can't say how much for now.
IIRC, with the old protocol I got somewhere in the neighborhood of 16 kilobytes/sec (128kbit/sec), maybe a little less. New protocol should be faster, but I don't think I've benchmarked it yet. I should be able to do a quick benchmark once I dig the code up again.
Keep in mind that the handshaking is completely done in software, so the 68K will be completely occupied while doing a transfer (unless you break out of it with an interrupt or something).
Mask of Destiny wrote:Is that 16kbit/sec or 16kbyte/sec?
16 KByte/sec
Mask of Destiny wrote:Keep in mind that the handshaking is completely done in software, so the 68K will be completely occupied while doing a transfer (unless you break out of it with an interrupt or something).
That's OK, I can use VSYNC interrupt or (if that slowdown transfer below acceptable speed) move registers output code to Z80.
drx
There must be some sound present, according to source code, so I also tried to compile it with Microtec compiler, but I have missed graphics somewhere (SEGA logo and sprites), dont know why
org wrote:drx
There must be some sound present, according to source code, so I also tried to compile it with Microtec compiler, but I have missed graphics somewhere (SEGA logo and sprites), dont know why
I'm not sure how good GCC at optimizations, but this one has many -O options, listed in RTL/CONFIG/A_TYPE.H including:
- Global variable optimization
- Stack pop optimization
- Single function return()
- Function in-lining
- Code hoisting and cross jump optimizations
- Register allocation using coloring algorithm
- Instruction ordering
- Optimize in favor size/speed
Since GEMS is compiled with MCC, I have feeling this compiler is used in many SMD games.
org wrote:I'm not sure how good GCC at optimizations, but this one has many -O options, listed in RTL/CONFIG/A_TYPE.H including:
- Global variable optimization
- Stack pop optimization
- Single function return()
- Function in-lining
- Code hoisting and cross jump optimizations
- Register allocation using coloring algorithm
- Instruction ordering
- Optimize in favor size/speed
Since GEMS is compiled with MCC, I have feeling this compiler is used in many SMD games.
That sounds good
Do you know if it can pass parameters in register ?
at least it support function inline which GCC does not support for M68K :-/
