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?
Offline
Jelly Stone park, MD USA
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
Offline
Michigan
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?
Offline
Jelly Stone park, MD USA
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 
Yogi
Offline
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..
Offline
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.
Offline
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
Yogi
Ohhh ok just read this post, it all makes sense. Thanks for helping me understand more about this, great explanation!
Offline
Michigan
yogi wrote:
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
Yogi
K
Offline
Jelly Stone park, MD USA
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
Offline
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...
Offline
Jelly Stone park, MD USA
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
Offline
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.
Offline
Jelly Stone park, MD USA
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
Offline
Jelly Stone park, MD USA
@ 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
Last edited by yogi (Aug 29, 2015 1:10 am)
Offline
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..
Offline
Jelly Stone park, MD USA
Bypassing the Bios should allow the Rom to run without any checks 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