Page 3 of 4
Posted: Thu Oct 11, 2007 5:43 am
by Shiru
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.
Posted: Thu Oct 11, 2007 7:32 am
by TmEE co.(TM)
Well, I AM going to make a PC to MD link... so I could get some real sound out of my MD tracker
Simple LPT port to MD controller port cable
Posted: Thu Oct 11, 2007 9:01 pm
by Mask of Destiny
Such a cable already exists:
http://www.retrodev.com/transfer.html
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.
Posted: Fri Oct 12, 2007 5:25 am
by TmEE co.(TM)
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)...
Posted: Fri Oct 12, 2007 5:46 am
by Shiru
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.
Posted: Fri Oct 12, 2007 10:51 am
by TmEE co.(TM)
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 !!!
Posted: Mon Oct 15, 2007 2:08 am
by Shiru
That's good. I also remember another one driver which can work with DOS software too - GiveIO.
Posted: Tue Oct 16, 2007 5:47 pm
by Mask of Destiny
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.
I'll dig up what I have sometime this week.
Posted: Wed Oct 17, 2007 1:51 pm
by Shiru
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.
Posted: Wed Oct 17, 2007 8:20 pm
by Mask of Destiny
Is that 16kbit/sec or 16kbyte/sec?
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).
Posted: Wed Oct 17, 2007 10:36 pm
by Shiru
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.
Posted: Wed Dec 12, 2007 8:21 am
by org
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
My resources:
http://org.dremora.com/SMD/Microtec_C_Compiler.rar
http://org.dremora.com/SMD/M68000PRM.pdf
http://org.dremora.com/SMD/GEMS.rar (I replaced old 2.0 GEMS in SHIP directory to the new 2.5 from GEMS directory)
http://org.dremora.com/SMD/srec_120.zip
http://org.dremora.com/SMD/FixCheckSum.rar
To compile demo, run test.bat in GEMS.rar
You must replace paths to your MCC68K in test.bat and ship.cmd also.
SHIP.BIN in GEMS.rar is my compilation and SHIPORIG.BIN is made by drx.
Regarding IO port access under XP: I think WinIO library from
http://www.internals.com/ can be useful.
Posted: Wed Dec 12, 2007 12:50 pm
by Stef
Hey another C compiler for 68000 =)
Do you know how good is code optimisation compared to GCC ?
Posted: Wed Dec 12, 2007 1:12 pm
by org
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.
Posted: Thu Dec 13, 2007 5:45 pm
by Stef
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 :-/