GEMS YouTube video

Talk about anything else you want

Moderator: BigEvilCorporation

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Fri Oct 24, 2014 8:17 am

Mask of Destiny wrote:For the 0x10 bit and the first nibble this works great without any explicit synchronization between the two processes.
Ok, here is 0x10 available bit test. What if it is in another bit? Or if available checking is some sequence of writes/read? You will need to implement it. To implement it, you have to recompile. What I mean by "implement"?

Imagine me, downloaded your BlastFm, but your BlastFm is not supporting Port communication that I NEED, then I have to implement it myself, or ask you to implement it. Implement myself means: recompiling and HATE :D. Asking author of emulator for support some thing: awaiting of response and implementation, or even rejection of feature.

Plugins offer: switching of them, making it yourself, and does not require rebuild of full system. Also, complatible with other builds of same utility.
Mask of Destiny wrote:You don't need to recompile BlastEm to change the config. That's what the config file is for. =P
Config is turning on/off and settings for already implemented features. Plugins give you nice interface to be able implement any type of provided interface.

Take a look at Retroarch and libretro. Each core of system implemented as separate plugin. If you want to write core: you don't have to change Retroarch, or libretro. And you don't have to recompile it.
Mask of Destiny wrote:Anyway, if you want to discuss the merits of plugin architectures in emulators we should probably take it to another thread.
It's blabla section thread, we can talk about anything. :D

EDIT
http://www.youtube.com/watch?v=hDXsRWKaqGw
(make sure that subtitles are on)
Hehehe.
GEMS internal data -> MOD file under developement.
Patch for windows-only genplus-gx here.

Code: Select all

patch offs     = 10000
envelopes offs = 12900
sequences offs = 13A00
samples offs   = 16E32

13A00 +  3A3E  = 1743E = first channel
16E32 +  91CE  = 20000 = samlpes start
16E32 + 191CE  = 30000 = sram end
8BC2 bytes for sequences data :S Not too much. But I know how to extend :)
Image

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Sun Oct 26, 2014 2:05 am

Separate post, because previous big enough already :D

powerofrecall try this
I'm writing from Ubuntu 64bit.

I got working dosemu with libretro-genplus-gx, but MIDI doesn't work. I don't know why.

Ok, steps to make it work on linux:
0) Install retroarch and dosemu and compile libretro-genplus-gx from sources
1) mkfifo /tmp/gems_parallel
2) create ~/.dosemurc with following code

Code: Select all

$_lpt1 = "cat > /tmp/gems_parallel"
3) save it of course :)
4) apply patch to genplus-gx source
5) make it (with LINUX_GEMS_PARALLEL defined!)
6) run retroarch first: select builded core and GEMS ROM.
7) then run dosemu with GEMS.EXE inside along with EGAVGA.BGI and IMK.DAT

now everything must work. except MIDI.
I have installed virtual midi ports, and when I run amidi -d -p hw:1

Code: Select all

80 2B 00
90 30 7A
80 30 00
90 34 7A
80 34 00
81 18 00
   24 00
Everything looks fine. Then I make symbolic link
ln -s /dev/snd/midiC1D0 ~/.dosemu/run/dosemu-midi_in
after that, trying hexdump -C < ~/.dosemu/run/dosemu-midi_in

Code: Select all

00000000  82 38 00 92 31 7a 82 3b  00 92 38 7a 82 31 00 92  |.8..1z.;..8z.1..|
00000010  3b 7a 82 38 00 92 31 7a  82 3b 00 92 38 7a 82 31  |;z.8..1z.;..8z.1|
00000020  00 92 3b 7a 80 3d 00 82  38 00 90 3d 7a 92 31 7a  |..;z.=..8..=z.1z|
00000030  82 3b 00 92 38 7a 82 31  00 92 3b 7a 80 3d 00 90  |.;..8z.1..;z.=..|
00000040  3d 7a 80 3d 00 81 1d 00  25 00 29 00 82 38 00 3b  |=z.=....%.)..8.;|
00000050  00 90 3d 7a 91 1e 7a 2a  7a 92 31 7a 82 31 00 92  |..=z..z*z.1z.1..|
00000060  36 7a 82 36 00 92 39 7a  82 39 00 92 31 7a 82 31  |6z.6..9z.9..1z.1|
00000070  00 92 36 7a 82 36 00 92  39 7a 80 3d 00 81 1e 00  |..6z.6..9z.=....|
00000080  2a 00 82 39 00 90 3c 7a  91 1b 7a 27 7a 92 30 7a  |*..9..<z..z'z.0z|
looks fine again. But when emulated genesis working: nothing goes there from sequencer. May be GEMS does not respose if you don't send MIDI Clock, or it's only recording. Strange.

EDIT:
Got everything working! I mean, there wasn't working only MIDI.
You need to add in ~/.dosemurc

Code: Select all

$_sb_irq = (7)
Or run GEMS in this way:

Code: Select all

GEMS -i 5
Because GEMS assume #irq = 7, but dosemu default sb16 #irq = 5.

Useful comands for testing:
write log of sys commands fitler only open/close/read.

Code: Select all

strace dosemu 2>&1 >/dev/null | grep -P '(open|close|read)' > ./dosemu.log
This is how I check that MIDI actually was read.

Then I got dosemu sources and found all things with this type of commands

Code: Select all

find -type f | xargs grep -iHn 'midi_put_data'
This is looking for strings in files, and outputs line and file. I'm just not linux nerd, so I have to find out myself this command :)

Note, if something still reading from some pipe - it stealing data from target application, so it must be stoped.

I need to write full guide, because all this is kinda mess. I think video recording would be nice but I can't do it now.
Image

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 27, 2014 1:48 am

r57shell wrote: EDIT:
Got everything working
This is hilarious, I got exactly to where you did, ported your sockets code to linux, and the MIDI wouldn't work and I got caught up in something else the last two days. Your original code I ported must have been working fine; it's everything else I didn't dive into.

It is great to see you have this working, though, it'll save me from having to tear my hair out over not really completely understanding sockets code :) And frankly, I'm glad. I don't want to have anything to do with it anymore!

You're definitely getting credited in any future productions I do with GEMS. You have done a great service to the community!

I hope lots of people use this, but seeing as we seem to be the only two Sega nerds who like GEMS who knows. Maybe this will make it more popular. :)

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 27, 2014 2:04 am

Oh, by the way, I was trying to get your sockets code to work with a TCP connection using a 'socat' line in the lpt1 section of dosemu's config. Was there a reason a FIFO works and socat (network 'cat') didn't? Not that I really care, as long as it works.

edit: I got everything built and dosemu set up but I'm still not getting anything; what do I need to do to the GEMS ROM? I hex edited in the SRAM info from your first video but nothing beyond that.

MintyTheCat
Very interested
Posts: 484
Joined: Sat Mar 05, 2011 11:11 pm
Location: Berlin, Germany

Post by MintyTheCat » Mon Oct 27, 2014 6:45 am

Very good to hear.

I would like to try out this scheme for myself.

I may have some questions this week. I may also be able to help out with any of the UNIX code.

I will be out until Thursday but should be able to give it a go then.

Cheers,

Minty.
UMDK Fanboy

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Oct 27, 2014 10:08 am

powerofrecall wrote:I hope lots of people use this, but seeing as we seem to be the only two Sega nerds who like GEMS who knows. Maybe this will make it more popular. :)
I hope so. It's complete kit, you may make everything.
powerofrecall wrote:I got everything built and dosemu set up but I'm still not getting anything; what do I need to do to the GEMS ROM? I hex edited in the SRAM info from your first video but nothing beyond that.
I just quote my private message to you:
r57shell wrote:Format of my log...
Listen - when socket was opened
accepted - when client was connected
writed: aa was bb - write in port was performed, write value = aa, was before = bb
readed: xx - xx was readed from socket. (I KNOW that past simple of read is read)
returned: xx - what was readed from port by genesis, it is value returned by port_read function.

NOTE: all returned: 0x10 is omited! (0x10 = not available)

Code: Select all

Listen 
writed: 00 was 00 // it's some 
writed: 00 was 00 // kind of initialization 
writed: 40 was 00 // when genesis is turned on 
accepted // now I open GEMS.EXE in dosbox 
readed: FF // genesis trying to read port, and it's successful  
returned: 0F // returned low 4 bits because 0x40 in port 
returned: 0F // and again: this two times is checking for 0x10 bit (available flag) 
returned: 0F // and again: but this time it was looking for value 
writed: 00 was 40 // now switching for high 4 bits 
returned: 0F // and reading high 4 bits 
writed: 40 was 00 // 0x40 writen as acknowledge 
readed: 7F // so when reading again occured, my callback trying to read from socket with success 
returned: 0F // it was looking for "available flag" (returning low 4 bits) 
returned: 0F // this time it's reading actual value (still returning low 4 bits) 
writed: 00 was 40 // swap to high 4 bits 
returned: 07 // returning high 4 bits 
writed: 40 was 00 // and acknowledge
By the way, it's log from libretro-genplus-gx :D . It's working, but I was really confused why it wasn't working... Issue was with activation of SRAM. In genplus-gx if SRAM starting address is less than end of ROM, then SRAM automaticaly disabled. So I have to CUT OFF 0x10000+ bytes. After that, it's working fine, except that fact, that genplus-gx does not support SRAM of size > 0x10000. Shame :lol: I need to expand it, otherwise GEMS won't work because it's required more (for simple tracks with all features), or MUCH more if your banks are big.
powerofrecall please record video of playing some MIDI straight from sequencer!
Last edited by r57shell on Mon Oct 27, 2014 5:18 pm, edited 1 time in total.
Image

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 27, 2014 2:34 pm

Alright, I think I have it working. When I first start it though GEMS (in emulator) it seems slow to respond to messages but once I send a program change through the MIDI piano this fixes it. I will make a video soon showing Renoise -> GEMS midi -> GEMS in emulator :D

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 27, 2014 5:57 pm

I'm still having some random problems with it.

Sometimes it takes a while to "start working" but once it does, all the GEMS functions work. Patch edit, play sequences, virtual MIDI piano etc. But it might not work for a while after starting, and sometimes doing the Re-Sync Genesis helps (this crashes if you don't have a module open, but if you do, it seems to work properly).

I think this has something to do with the printer time-out line in .dosemurc, but changing it to lower or even higher values doesn't really seem to affect anything. From what I could tell messing with this earlier when I was trying to get my code working, the printer timeout closes the pipe after the specified number of seconds, and the pipe is opened again when dosemu needs to squirt more parallel data out. Since you're working with a FIFO I don't think this should really matter.

My symbolic link MIDI connection has appeared to stop working also but I don't think this is related to your code or your guide. I think I am having a MIDI conflict with my other devices and routing and I should be able to get this sorted out myself. So, it might be a bit before I get a video of this setup.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Oct 27, 2014 8:37 pm

1) LPT timeout setting is default
2) Because it's pipe, and it's working like socket - it has buffer of "not readed" data.

First example: if you pause emulator or shut it down at all: your dos emu will freeze, because when pipe comes full, it's locking write until someone read it from other side.

Second example: because it has buffer - everything from dos going straight into that buffer. Genesis can't read faster than 200 KB/s from pipe (unless you turn on turbo mode in emulator), but actually it's reading slower. So you have to wait after "downloading is done" for a while, before whole pipe was read by genesis.

So easiest approach to find out when pipe is empty: press debug->debug on AFTER downloading was done. Genesis will show debug screen when loading was done.

3) make sure that #irq of sb16 is same as #irq setting in GEMS.EXE.

4) MIDI connection: I have to setup it everytime, because virmidi devices dissapearing after reboot. First: check that your virtual MIDI devices installed: command "aplaymidi -l" for exmaple. Next, check your symbolic link is still working: ls -al ~/.dosbox/run

Don't try to "cat < /tmp/gems_parallel" - it can steal bytes. I'm not sure is it stealing from ~/.dosbox/run/dosbox-midi_in.

If there was desync: best way is to: shutdown dosemu and retroarch, then
1) start retroarch and load content (ROM)
2) start dosemu and run GEMS.EXE
Image

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Mon Oct 27, 2014 9:12 pm

r57shell wrote: 4) MIDI connection: I have to setup it everytime, because virmidi devices dissapearing after reboot.
I do know that you can fix this by adding the line

Code: Select all

snd-virmidi
to your /etc/modules file and it will persist across reboots. That's not what I'm having trouble with. It's just not working. I did update the kernel recently, maybe it is the problem. Hexdump even produces some sort of data when I use Renoise, but it seems like no MIDI is coming out the other end (even for other linux MIDI programs) so something is definitely broken that I will have to fix. This is annoying as I had it working. While I was hacking around on all this I did build newest svn of dosemu and I think it actually has proper (ALSA hardware device opening) MIDI IN support so I may try that out as well.

I didn't know about that debug thing. Neat. Maybe I'll figure out what all that stuff means.

I'm sure I'll get it figured out, it is just my bad luck that now everything else works, and what I had working before now isn't... :evil:

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Tue Oct 28, 2014 3:08 am

Alright, I'm stuck on this.

I've checked that both my virtual midi port (/dev/snd/midiC1D0) and the symbolic link to that port (~/.dosemu/run/dosemu-midi_in) indeed are receiving MIDI data (doing 'hexdump -C' on both of them provided ongoing data from the MIDI clock as well as other data) but dosemu itself doesn't see it.

I've checked the symbolic link itself, it's still linked, tried logging dosemu, it's not getting anything... do we have any Unix wizards in here that might know what the hell is going on? This is amazingly frustrating considering I had it working before.

This was really easy to do before once I learned about the symlink, but now it isn't wanting to work.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Tue Oct 28, 2014 9:16 am

r57shell wrote:3) make sure that #irq of sb16 is same as #irq setting in GEMS.EXE.
r57shell wrote:Useful comands for testing:
write log of sys commands fitler only open/close/read.

Code: Select all

strace dosemu 2>&1 >/dev/null | grep -P '(open|close|read)' > ./dosemu.log
This is how I check that MIDI actually was read.
Note: read is called only if you send MIDI data.
Image

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Tue Oct 28, 2014 2:27 pm

I have the IRQ set up correctly. In fact when I was working with GEMS without the emulator before I was using the -i 5 option. First thing I checked. :) I even went back and changed the dosemu.conf file to 5 and tried starting it the way I did before, with -i 5, no luck.

So the log does have read() in it (many calls), meaning dosemu is getting MIDI? Now I'm really confused. When I originally was using GEMS the thing I got stuck on the first time was MIDI clock/start/stop (which I had to enable in Renoise). Without those MIDI messages, GEMS won't record. After that, it worked, so the GEMS IRQ and MIDI clock was the very first thing I checked when it wasn't working. So now we have all this and the recording isn't working, and I'm not getting sound of GEMS either (at least MIDI, the virtual keyboard and everything else does work).

So you know for sure that sending MIDI to GEMS, at any time, is supposed to sound on the Genesis? Like an instrument?

Other stuff: For some reason, having MIDI connected to dosemu while starting GEMS makes it block; disconnecting it lets GEMS start. This was true even when MIDI was working for me.

The only other thing I can think of is the dosemu version I am using I built myself from the sourceforge svn, maybe I need to revert to the packaged one I was using before...

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Tue Oct 28, 2014 4:25 pm

powerofrecall wrote:So the log does have read() in it (many calls), meaning dosemu is getting MIDI?
Yes. Definitely. Does this read is reading from pipe? Look at file descriptor. There a lot of reading from other stuff.
powerofrecall wrote:So now we have all this and the recording isn't working, and I'm not getting sound of GEMS either (at least MIDI, the virtual keyboard and everything else does work).
Recording does not work, there are two reasons:
1) MIDI does not work at all
2) Start clock/stop clock, and MIDI clock messages does not send.
powerofrecall wrote:So you know for sure that sending MIDI to GEMS, at any time, is supposed to sound on the Genesis? Like an instrument?
No, it depends on patch bank and MIDI program message -> for selection of patch. Best way to be sure that it's working: look at debug screens, while playing some MIDI recording. Some of screens must be very dynamic.
powerofrecall wrote:Other stuff: For some reason, having MIDI connected to dosemu while starting GEMS makes it block; disconnecting it lets GEMS start. This was true even when MIDI was working for me.
It caused by initialization of MIDI used in GEMS.EXE. It fetch everything available in MIDI before start. While fetching available data: it's using big enough timeout, so if your sequencer is sending MIDI clock event faster than timeout in GEMS.EXE, GEMS will never stop fetching available data before start.
powerofrecall wrote:The only other thing I can think of is the dosemu version I am using I built myself from the sourceforge svn, maybe I need to revert to the packaged one I was using before...
Maybe. Two days ago, when I did git clone from repo, it was fine. But, I didn't compile it though.

Also, you may check port address in GEMS and DOS, they must be 0x330 both. (or same at least)
Image

powerofrecall
Very interested
Posts: 237
Joined: Fri Apr 17, 2009 7:35 pm
Location: USA

Post by powerofrecall » Wed Oct 29, 2014 2:23 pm

Alright, it's working now. I have no idea what I changed, though! I am now starting up gems with 'gems -a 330 -i 5' and it works. This makes zero sense, since I changed dosemu.conf to match the IRQ 7 setting gems wanted, but now that I changed it back to 5, and started with that particular command line... it works. Not that I'm complaining.

Now I just have to make an awesome song to show off GEMS in a video 8)

Post Reply