Does anyone know if the maker of this is still around?  I've tried to get in touch multiple times through the years and nothing.

I wanted to report a bug that ANY midi note off message will cancel any currently playing note on a channel.  Very annoying.  Basically if you start playing one note and then another, it will transition like you hope, but when releasing the first note the new note will stop too.  Makes it very difficult to actually play because if you want notes to continue you have to keep holding all the notes you've played.  The only way around this is to actually program the notes and make the note offs slightly before the new notes sound.

I don't know much of anything about programming but there's probably just some logic that needs to be done and assigning note offs to the note numbers they belong to and ignore them if playing legato until all notes have been released.

Does anyone know if the maker of this is still around?  I've tried to get in touch multiple times through the years and nothing.

I wanted to report a bug that ANY midi note off message will cancel any currently playing note on a channel.  Very annoying.  Basically if you start playing one note and then another, it will transition like you hope, but when releasing the first note the new note will stop too.  Makes it very difficult to actually play because if you want notes to continue you have to keep holding all the notes you've played.  The only way around this is to actually program the notes and make the note offs slightly before the new notes sound.

I don't know much of anything about programming but there's probably just some logic that needs to be done and assigning note offs to the note numbers they belong to and ignore them if playing legato until all notes have been released.

Yea, I think it's probably something to do with the revision of the console or something like that... It's still fairly quirky but will work.  You really have to edit note duration values so they don't overlap or it cuts out.

Is it possible to use the RCA jack on the back of the master system to just plug the sound into the audio interface? Or does it always need to be connected to the RF cable then coax out?

Yea, midi cc's work.  It's a little temperamental upon each start up, you need to plug in the db9 just right or it will hang notes.  I only heard the startup sound the one time too, but it will work.  I suppose I can say it works enough that I'm happy anyways!
Thanks to everyone for their help.

OK, SO I GOT IT.  Apparently you need to plug the db9 into the system once it hangs at the splash screen, then you hear the startup sound.  It stays at the splash screen though, and I'm not sure if it fully works but I'll test the midi commands and see where it takes me.

I'm getting to the point where I wonder if I should just track down a different sega revision.

I've triple checked my pinouts to the 'duino and they are all correct too.  Not sure how much I want to do the bios mod again, since if I bend pin 20 one more time it'll probably fall off tongue  It's been socketed anyway but I feel like the sega I have and the sega in the bios mk1 instructions are different somehow. I'm pretty sure it was all done according to the instructions so I don't know what was wrong, maybe I have all western carts or something.

catskull wrote:

Funny, I've run into similar crashes when programming an arduino from my mac. The screen you saw was a kernel panic right?

By two usb ports, do you mean two serial ports showed up? TTY.usbport and CU.usbport? You should use TTY always though. This page offers more info: https://www.arduino.cc/en/Guide/MacOSX

AFAIK, the arduino IDE will verify itself when you program it.

How are you sending midi data to the arduino?

What model of arduino are you using? Can you post a picture of all of your hardware?

I can say, I've had a rough time getting midi data out of an arduino with my midi gear. I've tried several models and I get absolutely nothing on my FB-01 and a cheap usb midi cable. I also connected it to an analyzer and verified that data was coming out of the arduino's tx line, but I still got nothing on my synth. So really I need as much help as you do hahaha. Like you, I'm at my wit's end. I don't have a master system to try, but I do have a game gear. I'll see if I can get the hardware together to give it a shot.

1. I believe it was some sort of kernel panic but the screen went black like it just shut off
2. Sending midi to the arduino by the max patch app midi to serial highlighted in Little Scale's original blog.  I believe it is only accepting midi data and converting it to something the master system recognizes
3. Using the arduino uno with usb connection

... boy I long to have the sound of the master system at my disposal, I hope I can get this to work.  Seems everyone is using the GG for this project, find it hard to believe nobody in the US or Canada has tried this on a SMS?

....and just finished removing the mod and changed it back to original.  Well, one thing I've noticed now, with the cover off the db9 connector fits much better in there and stays.  Now if I power it on with the arduino it just powers on with a black screen.  Games appear to work so nothing got fried in the process.  If I unplug the db9 connector it does the whole stick at the splash screen thing.

I wonder if there is more about the arduino that needs attention.  As I mentioned in my first post, the newest IDE finds multiple errors and they are all where it names the samples out as "not declared in this scope".  Then I went back and tried reprogramming it with version 1 of the IDE and it seemed to work ok-- since it didn't have errors.  Earlier today I tried reprogramming the arduino again in version 1, and i noticed it had 2 usb ports, tried the second one this time and it immediately crashed my computer in a way I've never seen-- black screen and some strange mac warning screen.  Anyway, since i'm also a newby at the arduino, it is as simple as opening the sketch and hitting send right?  Is there any way to verify the contents of the flash memory on the arduino?

Well, I pulled pin 20 on the bios, ran jumpers from pin 1 of the 315-5216 to pin 13 of both cartridge and card, cut the traces to both pins 13, popped it in and it still didn't work.  Once in a while i get i high pitch whine on power on... just tried a game in there and it didn't work either.  I'm pretty sure is is done correctly, so dunno whats up.

well, i can do the bios mod(in the middle of it right now, thank you) but the header code stuff is over my head..

Hey Yogi, mine is the base model version 3010 with hang on/safari hunt built in, and it does go right to the game screen.
The guy who burned the eproms said he used his "best ones" to make sure it worked this time.

I've just finished trying a new cart pcb 171-5519(no letter suffix) with no luck also. 
On another note, my arduino shows blinking lights whenever I send midi data too.
Dunno what to do next.

Well, I got my new eprom in the mail today, and unfortunately the same problem.  I wonder if its my master system itself.. maybe it needs to be a different revision I wonder.  Maybe I'll try a different cart in the mean time...

yogi wrote:
ZAIUSZ wrote:

Excellent information thank you.  I read about "padding" earlier, from what I understand is this used to terminate then end of the block if the size of the EPROM is too large?  Is it necessary on the 27C256 (this is what it was written to) with this code?

Padding fills out the binary file with some code or a selected byte. Sometimes its mentioned when talking about preparing a .bin image to be burned to a EPROM. The SMSM_100_ROM.sms bin file is padded to 32K by LittleScale already so no worries.
   Say for instance you have a bit of code 100 bytes long (about as much as the SMSM code) to put into a 32K EPROM; as long as the running code loops and will never go passed the last op code, the rest of the EPROM doesn't matter to the host system. But the programming tool may need the .bin file to be the exact size of the device you are burning, in which case the .bin file would be filled up with anything to create a file 32K in size for a 27C256. Some programmers do this for you, so as long as your file is equal to or smaller then the selected device, it will work.
  In other cases, like for a EPROM that is larger then the original PROM on a board, the term is slightly different. For example, in our case, you could used a 64K device instead of a 32K EPROM. You would have to deal with the extra address pin, A15. You could tie it to GND or Vcc or leave it floating. Depending on what you do, determines which half of the 64K is active at run time. To be flexible you may want to copy the same 32K bin image to both half's so regardless of how you do the wiring, the same code will boot.
   Hi Jazz just saw your reply. There shouldn't be any floating pins on the 171-5519 board it's a one to one fit smile
Yogi

Ohhh ok just read this post, it all makes sense.  Thanks for helping me understand more about this, great explanation!

Jazzmarazz wrote:

I don't know what yogi has said thus far, but padding is an alternative to pulling your unused address pins either high or low. Are there any address pins left hanging on your 256?

Hi, you mean pins not connected?  I actually wouldn't know enough about this part yet, but right now they are all soldered in with the socket.

yogi wrote:

OH NO, sorry but I gave you a lot of wrong info.
Was just re-reading the Z-80 source code
http://little-scale.com/SMSM/SMSM_100/S … de_Z80.txt
And without the Arduino connected it DOESN'T play the start up sound. That comes from the Arduino code. The Z80 code just sits in a loop waiting for input  and when it gets some it stuffs it to the PSG and then waits again.
  The fact that your's is stalled at the Splash screen still makes me think its an EPROM issue, cause the bootloader hasn't finished.
Yogi

Ahh ok.  Well I'm considering splicing a light phaser to do this right... there must be a certain revision controller that little scale used since the only ones i've ever seen have only 7 wires.  I think it will be way more reliable anyway and i don't need to hold the connector on with elastics..

Excellent information thank you.  I read about "padding" earlier, from what I understand is this used to terminate then end of the block if the size of the EPROM is too large?  Is it necessary on the 27C256(this is what it was written to) with this code?