129

(2 replies, posted in Atari)

Yes, very cool project smile
Yogi

130

(9 replies, posted in Releases)

Very nice, thanks so  much.
Yogi

131

(5 replies, posted in Atari)

Matej wrote:

Hmmmmm....:)  This is ? a one-off Atari cart??  It's labeled with 2012. OR is it a PD-98xx cart?  Do Tell
Yogi

johey wrote:
jefftheworld wrote:

Are you using a very long midi cable, a passive midi-thru box or anything else that might cause more events than normal to fail?

Thank you for replying! Good suggestions with long cable. I was actually using 5 meters. Though it has to be it! Tried with a 1 meter cable. Played some. Still the same. sad Directly connected from keyboard to Kerberos.

If it was 1 of 1000 notes I would also accept a panic button, but this is far too frequent to be usable.

I might need to test a few more keyboards. The MicroKORG XL works much better than the A-300 Pro. With the later, I cannot manage to send chords. I can send polyphonic events, but only if I press the keys one by one, keeping hold of each key. Pressing down several at once results in one single note. This goes for the Kerberos only and not other instruments. With the MicroKORG XL I can play chords. So in some way the Kerberos has to be more sensitive than other devices. I have four other different midi keyboards to try with (Minibrute, Yamaha YS-200, Akai MPK 61 and E-Mu E-Synth). I also have two different active midi routers/splitters I can try.

   Just some general thoughts to keep in mind. Some of this you may already know.
   The Kerberos midi is just a UART mapped to memory, the C64 softs do all the heavy lifting. Depending on the software, incoming midi events are detected either by polling or an interrupt, at which point the CPU runs the code to decode the current byte and decide if it's  the end or part of a current message or the start of a new one. My point is for each and every event there are clock cycles needed to process the midi.
  What can happen is the receiver code can get swamped by heavy traffic on the bus, I.E a sequencer sending to multiple synthesizers.
  It sounds like you are just directly connecting a KB to the cart, so sending NOn/NOff messages on one channel. which shouldn't be overloading the system, but some KBs use active sensing which sends lots of messages just to say 'I'm here'. There can also be Realtime clock messages sent if using Rhythm or Accompaniment features.
  If you have MidiOx you can see what is being sent by your KB, and filter some of it.
  Anyway, I don't know if any of this applies in your case.
Yogi

SWEET!!!  Going to really try to be there! It's a really good excuse to visit our oldest kid, so the wife will be happy too smile
Yogi

ZAIUSZ wrote:

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, the Midi processing is limited and with only 3 tone channels you are  polyphonic-ly challenged smile
  As to a 'pro sound' sort of mod, I'm sure it can be done but would take some research.  I'm more familiar with the Genny mods, but there has got to be some for the MS. I do know there is a FM mod board Here- http://etim.net.au/smsfm/smsfm.html.
Yogi

ZAIUSZ wrote:

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.

OH This Is Great!! What was the fix if you don't mind?
Very Glad you got it working
Yogi
EDIT: OK so I read your other posts smile for some reason I didn't get a notification in my IN BOX till your last one, oh well. Just good to know it's working, but the whole Splash screen thing: weird bios stuff.
Yogi

ZAIUSZ wrote:

....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.

Good that you got it back to original with no damage. The fact that you only have a blank screen with the Arduino plugged in SEEMS like the described action of the Bios when it fails the checks. But I don't see how that is affected by the Arduino being there.Or for that matter, why it hangs on the Splash screen without it. A normal game will boot without a pad plugged in? In my mind weather or not the Arduino is plugged in should not affect the boot, unless there is something miss wired on the connections? Seems like the Arduino is shorting the MS's Vcc to GND or something.

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?

At this point my best advice is to recheck all the Arduino connections, and at some point re think the Bios disable mod. The SMSM Z-80 code does not include any of the needed Sega code or check sum so if everything else was working fine the Bios would shut the system down when trying to boot. You'll need to get the mod working so a normal cart starts right away without the splash screen. Once the system is in this state you should be able to boot the SMSM cart (but it will only have a blank screen) if the board / EPROM are good. Or else ask LS to include the Sega header info in the ROM. If I could find some good info on writing the header I will add it, but have no System to test it on ( I don't think the GG does all the checks that the MS does).
  The Arduino IDE lives as two versions because the newest is not backwards compatible,and the older V1 is most likely the one LS used; this code is originally from his college days. You should see the LED blinking with USB traffic but you will have to test the activity on the output pins with a logic probe. This testing won't tell you if the data is corrupt or not, but will indicate if the code is running.
  Beat luck,
  Yogi

Bypassing the Bios should allow the Rom to run without any checks smile Of course you won't have access to the built in games, but you also won't have any problems running J or Euro cart.
Hope this is the fix,
Yogi

@ ZAUST Well, been reading over at SMSPower.org. and this page http://www.smspower.org/Development/BIOSRemoval
seemed like something you may want to read.
  There are some other pages about the SMS-export Bios checks. Will cross check LS's code, looking for the needed strings and checksum (but I don't think I saw any of that last time I looked at it).
Yogi
EDIT this page outlines the header code that needs to be in a cart
http://www.smspower.org/Development/ROMHeader

ZAIUSZ wrote:

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.

Hummm. Well it seems like the bootload/bios is trying to run the cart but failing. If the cart  was not connected/not responding at all the Master S would run the built in ROM.
  Your boards should work, they're the one listed by LS. I'm thinking the EPROMs are burned correct, but the code may be the problem. I'll have to do some reading, but there may be tests by the bios that are hanging it. I remember reading something about the boot checks. LS's Z80 source does include a string but don't know which model LS tested on, so while the code worked for him it may not on a System with the  Bios checks.
  Good to hear there are signs of life on the Arduino! Looked thru the .ino and reviewed his build doc; the only unused pin on the game port cable is pin 5. So was it pin 7 you are missing on the controller? You could check the pin #s, don't trust the color code.
  I'll see what I can find out about the ROM code, in the mean time you could try posting a message on Littlescale's Facebook page, he is more active there now-a-days.
Yogi

ZAIUSZ wrote:

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...

bummer! Can you try something, turn on the Master Sys without a cart. Does the splash screen freeze?  Not sure what it will prove but I don't have a Master Sys just a GG and I think it would freeze on the Splash with no cart. but haven't played with it in a very long time.
Yogi

ZAIUSZ wrote:

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..

You might get a game pad extension cable. Can't say for sure but should have all 9 pins connected.
Yogi

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

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

ZAIUSZ wrote:

Hi Yogi thanks for the info.  Yea, I had to outsource the burning to a guy about 5 hours from me, he is going to reburn one for me and we'll try that.

Oh good, are you using the 27C256 EPROM? If you need another let me know. It wasn't clear but are you using a Master sys or a Game Gear with converter?

Regarding the 'bank mapper', i don't know much (or anything really) about eproms but from what i've read here I assume that the codes are written in blocks and the mapper looks up which block to load or something like that.  In that case, I assume having the external chip for the mapper would cause problems and not work, the one to avoid.  I can say the pcb i used has only the spot from the eprom and one electro and one ceramic cap, according to the blog this is the one you need.

Yes the single chip board is the one to get, but it has to be a 28pin ROM. If you have a 171-5519 board you should be good, but double check the pin count. Even though LS listed "World Grand Prix" I have one with a newer board that has a second mapper chip; I don't know if it's a improved larger version of the game or they just used a more complex board because they were on hand.
  The 27C256 is a standard 28pin 32KByte x 8 memory, some of the Sega games used more then 32K and switched in banks as needed. So an additional circuit is used to decode the command to switch; more often it's an external chip but Sega also designed a PROM with it built in, very custom 32pin PROM.

I do have a logic probe anyway, never used it yet but should be simple enough.

Good, I would test the Arduino by watching the output pins while you are sending Midi, the interface doesn't have to be hooked to the SM. This will help verify some of the setup, but the code in the Arduino could be foobar for some reason or the USB Midi connection is sending bad data; so not 100% but should prove some communications is working.

So anyway, are you saying that even if there is nothing plugged into the master system in the game port I should still hear the new startup sound?  All I hear is the standard sega startup and then it just hangs on that screen.

OK with it hanging on the splash screen it really looks like a EPROM issue. The screen should go blank and you would hear http://little-scale.com/SMSM/SMSM_100/S … tartup.wav
The startup sound is part of the Init code and will run before any port reads happen, kind of a self test. If that isn't happening then for some reason the code isn't running. The cart works with the original ROM so unless there is something very weird with the board you can assume the cart is good and the EPROM is not.
Yogi