Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - SC3000 questions

Reply to topic
Author Message
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
SC3000 questions
Post Posted: Wed Dec 11, 2019 11:53 am
Hi all. I'm porting a MSX-assembly game to the SC3000 (my uncle ported it in the late 80's but that stuff is long gone and so is my uncle).

I'm using z88dk and cannot get it to make a working .sc file. However the WAV-files it makes, they load fine into MAME. The code has bugs so it hangs and reboots. I'd like to load the code into Meka and debug with it's great debugger but I cannot load the .wav into Meka . Any hints how I can get z88dk to make me a working .sc file that I could load into Meka?

Many thanks in advance,
/HH
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 218
Reply with quote
Post Posted: Wed Dec 11, 2019 7:59 pm
I guess lets break this apart a bit.
First off you're not going to get a .WAV file to load on any emulator that doesn't support tape functions so youll need to compile your MSX port into a .BIN file instead which should work every time.
Im assuming the .sc extension is for a SC3000 rom and if so in that case you should know any rom extensions such as .SMS, .GG, .SMD, .NES, .N64, .GEN, .DMG, .GBC so on you get it its typical rom extension to show what system its for, theyre all just .BIN file formats with a different extension.
TLDR, Just try and get your compiler to output a .BIN file of your rom. Then load that .BIN file into your emulator. You can change the extension from .BIN to .sc if it still wont load want and It should still work.
  View user's profile Send private message
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
Post Posted: Wed Dec 11, 2019 9:50 pm
Thanks for your reply!

IllusionOfMana wrote
I guess lets break this apart a bit.
First off you're not going to get a .WAV file to load on any emulator that doesn't support tape functions so youll need to compile your MSX port into a .BIN file instead which should work every time.
Im assuming the .sc extension is for a SC3000 rom and if so in that case you should know any rom extensions such as .SMS, .GG, .SMD, .NES, .N64, .GEN, .DMG, .GBC so on you get it its typical rom extension to show what system its for, theyre all just .BIN file formats with a different extension.
TLDR, Just try and get your compiler to output a .BIN file of your rom. Then load that .BIN file into your emulator. You can change the extension from .BIN to .sc if it still wont load want and It should still work.


I have the WAV loaded into Mame. But can't debug the code from Mame. It's a real pain to "debug" by hand, modify code, compile, load slooowly in "tape-mode" to Mame...

Z88dk spits files out with whatever extension I want but the code is some random shit that Meka won't accept. At the same compile time Z88dk spits out the WAV file which loads nicely into Mame and even Takeda-emu. Debuging still sucks compared to the Meka-debugger.

I had a look on Maxim's stuff and tried WLA-assembler. Coded a snippet which to my surprising made a working .sc for Meka. Now I have to modify the game sourcecode to be WLA-compatible, aargghh.

/HH
  View user's profile Send private message
  • Joined: 08 Sep 2018
  • Posts: 218
Reply with quote
Post Posted: Wed Dec 11, 2019 10:51 pm
like I said, you could have just compiled it as a .bin format and simply changed the extension to .sc by renaming the file in windows. No other compilers or converters required.
  View user's profile Send private message
  • Joined: 03 Oct 2011
  • Posts: 175
  • Location: New Zealand
Reply with quote
Post Posted: Fri Dec 13, 2019 1:20 pm
Hi. Some thoughts.

0. Loading into Meka is a bit tricky because there is no easy way to load both the lower 32kb basic iiib rom and the upper 32kb ram portion by making a 64kb binary or anything like that. However there are some workarounds.

1. Old versions of MESS eg v0.136 have a popup window debugger which I found easier to use than later versions of MAME, plus easier to change the load speed to unlimited to quickly load tape images.

2. If you have the original source then easiest way to port assembler based game is to debug it in Meka or mess is as a 32k rom .sc based at $0000 with Ram from $8000 to $ffff but put stack at ummm I need to check... can’t remember ideal stack address. Something like $8400 I think.... Then when you are ready to switch to running under basic IIIb you rebase your image to start at something like $9900 then write a little basic routine to jump to the machine code and execute it. (If it is a large program I have a technique somewhere for using almost all the 32kb of ram with basic IIIB - more than the 26k of ram you can normally use). Let me know if interested and I will hunt out my notes.

3. Meka debugger is awesome for porting binary files to different systems because you can put breakpoints on io port read / writes and memory range read / writes to find the parts of code that need modification. Mess couldn’t do that. Love the Meka debugger.

4. From memory I have a hacky technique somewhere for manipulating a Mess state file in old versions of Mess to change the program loaded into memory - ie. you recompile your binary in wladx or whatever then copy it into the mess state file and reopen that and then uou can immediately run your program.

5. You could use a modified version of the Sega sc3000 multicart binary to debug in Meka. That would load the multicart menu system, then have a menu option for loading your software. Once loaded, Meka would treat everything pretty much as if you had just loaded the tape software. Let me know if you want to try that.

6. You can develop as a .sf7 image and load into Meka. You have to write a little loader program for that, although years ago I wrote a little menu system for bootable sf7 images based on the multicart menu system. You could use that to load a hacked copy of basic iiib into memory along with your software to debug. That is how the old machine code tape games were ported to the sf7000 without having to rewrite them and that is essentially how the multicart runs tape games too - with a hacked copy of basic IIIb that skips the rom checksum and then calls back at the end of memory initialisation to load the program to ram and execute it. That might be easiest for your purposes.

7. You can use Sega wav writer by Andrew Kerr to generate wav files from binary blocks for when you have debugger everything and need to convert back to audio. Useful toolkit.

Let me know if you want any more details on the above ideas and I will hunt out my notes. Been a few years since I did much work on that :)

Cheers
  View user's profile Send private message Visit poster's website
  • Joined: 03 Oct 2011
  • Posts: 175
  • Location: New Zealand
Reply with quote
Post Posted: Fri Dec 13, 2019 8:46 pm
helmha wrote
I had a look on Maxim's stuff and tried WLA-assembler. Coded a snippet which to my surprising made a working .sc for Meka. Now I have to modify the game sourcecode to be WLA-compatible, aargghh.


I may have provided a bit more detail than you need :)

Do you want to be able to make a tape loading game that works on the SC-3000 with Basic IIIB (that is what most of the above comments were based around). Or do you just want to be able to make a ROM image that works on a SG-1000 / SC-3000?

If you just want to be able to make a ROM image, then things get a lot simpler - just get the paging / memory layout right for your assembler. You only need the above tricks if you want to debug tape software in Meka running under Basic IIIB.

If you only want to make a SC-3000 / SG-1000 compatible ROM which doesn't require Basic IIIB, the main thing to remember is that the SC-3000 only has 2KB of RAM ($C000 to $C7FF), and the SG-1000 only has 1KB of RAM ($C000 to $C3FF). If your MSX game requires more RAM than that then porting gets a lot harder.
  View user's profile Send private message Visit poster's website
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
Post Posted: Sun Dec 15, 2019 9:48 am
IllusionOfMana wrote
like I said, you could have just compiled it as a .bin format and simply changed the extension to .sc by renaming the file in windows. No other compilers or converters required.


The trouble wasn't the extension of the resulting compilation. Z88dk produced a file which missed for example parts of the datas for the graphics. I didn't understand the SECTION-stuff in Z88dk so that's the reason why the output file is not working. But I've switched over to WLA and have now a working binary file which loads fine into Meka and I'm able to debug it.

And I'm doing this on Linux, so no Windows here. Meka runs fine with Wine. I'd like to have a native version but been unable to make one yet, get errors during build.
  View user's profile Send private message
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
Post Posted: Sun Dec 15, 2019 10:11 am
Thanks honestbob for your reply.

honestbob wrote

2. If you have the original source then easiest way to port assembler based game is to debug it in Meka or mess is as a 32k rom .sc based at $0000 with Ram from $8000 to $ffff but put stack at ummm I need to check... can’t remember ideal stack address. Something like $8400 I think.... Then when you are ready to switch to running under basic IIIb you rebase your image to start at something like $9900 then write a little basic routine to jump to the machine code and execute it. (If it is a large program I have a technique somewhere for using almost all the 32kb of ram with basic IIIB - more than the 26k of ram you can normally use). Let me know if interested and I will hunt out my notes.


The game was released for MSX in a Finnish computer magazine (Mikrobitti, 1989). Source is a BASIC-listing with asm part being string packed into REM-lines. First few lines poked a decrunching-code into memory which then unpacked the game from REM-lines and saved the file with BSAVE. I dumped the binary file and disassembled it and now have a working source. Sourcefile compiles fine with WLA and resulting binary file loads nicely into Meka and the other emu's I've tried.

Quote

3. Meka debugger is awesome for porting binary files to different systems because you can put breakpoints on io port read / writes and memory range read / writes to find the parts of code that need modification. Mess couldn’t do that. Love the Meka debugger.

Yeah, I'm with you. GRRREAT STUFF !


Quote

5. You could use a modified version of the Sega sc3000 multicart binary to debug in Meka. That would load the multicart menu system, then have a menu option for loading your software. Once loaded, Meka would treat everything pretty much as if you had just loaded the tape software. Let me know if you want to try that.

This sounds very interesting.


Quote

6. You can develop as a .sf7 image and load into Meka. You have to write a little loader program for that, although years ago I wrote a little menu system for bootable sf7 images based on the multicart menu system. You could use that to load a hacked copy of basic iiib into memory along with your software to debug. That is how the old machine code tape games were ported to the sf7000 without having to rewrite them and that is essentially how the multicart runs tape games too - with a hacked copy of basic IIIb that skips the rom checksum and then calls back at the end of memory initialisation to load the program to ram and execute it. That might be easiest for your purposes.


Sorry, my skills and knowledge are too limited for that.

Quote

7. You can use Sega wav writer by Andrew Kerr to generate wav files from binary blocks for when you have debugger everything and need to convert back to audio. Useful toolkit.


I tried to run WavWriter but it won't work with Wine and I don't have a Windows-puter nor a license for Win.

Quote

Let me know if you want any more details on the above ideas and I will hunt out my notes. Been a few years since I did much work on that :)

Cheers


Thanks a lot! At the moment I don't want, I want the game to work fully first.

/helmha
  View user's profile Send private message
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
SC3000 emulation questions
Post Posted: Thu Jan 02, 2020 9:47 am
Okay, I've got the game running quite good. The original version on MSX uses envelopes and such with PSG that don't exist on Sega so those would be impossible for _me_ to port. Instead I made some similar sounding stuff with Deflemask and harnessed PSGlib into the SC3000 version.

I put a "vblank wait" into the game's main loop for the sounds timing as PSGlib doc's recommend. Code for the vblank is shamelessly stolen from Racer sourcecode. This seems to work correct only on Meka. Game runs smooth and as fast as it should. Also sounds play right. With other emulators there's problems with timing. Original MSX version uses a simple djnz-loop as delay. If I use that type of delay, the sounds don't play right on emulators.

The other emulators I've tried:
- Mame
- Kega-fusion3.6
- Retroarch (bluemsx and some other core I can't remember)
- Takeda sc3000.exe
- Emulicious (colors are wrong but that's a known thing with other than SMS stuff)

With those emulators the game runs really slow.

If I disable the "vblank wait" in the game sourcecode, the game runs way too fast in every emulator and sounds are squeaky.
Could this be because of my bad coding or is it a problem of these other emulators or perhaps their settings? I'm a horrible coder so it could very well be the problem, but why does it work with Meka...?

Thanks for any hints.
  View user's profile Send private message
  • Joined: 14 Apr 2013
  • Posts: 489
Reply with quote
Post Posted: Thu Jan 02, 2020 10:48 am
helmha wrote
I put a "vblank wait" into the game's main loop for the sounds timing as PSGlib doc's recommend.

It depends on the samplerate of your sounds. For example if it's 60Hz you need to call PSGFrame 60 times per second. In that case the easiest way to achieve this is to call it every frame interrupt (because on NTSC frame interrupts occur at 60 Hz).

helmha wrote
Code for the vblank is shamelessly stolen from Racer sourcecode.

I don't know what this code looks like, can you post it in here for easier reference?

helmha wrote
Original MSX version uses a simple djnz-loop as delay. If I use that type of delay, the sounds don't play right on emulators.

Do I understand correctly that you removed this code when you inserted the "vblank wait"?

helmha wrote
- Retroarch (bluemsx and some other core I can't remember)

You try your SC3000 port on an MSX emulator?

helmha wrote
- Emulicious (colors are wrong but that's a known thing with other than SMS stuff)

Colors are _NOT_ wrong. In Emulicious you are running your rom on a Mastersystem so you are seeing the correct colors of a Mastersystem running the rom.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 2559
Reply with quote
Post Posted: Thu Jan 02, 2020 11:59 am
Racer's vblank wait seems to be a simple HALT instruction, so it's assuming the only active interrupt is vblank - and it should work if it's so, but it will work badly if there are other interrupts active, for instance the line IRQ one.

you should check the values you wrote into the VDP registers, mainly in registers #0 and #1 to see if frame interrupt is enabled and line interrupt is not.
  View user's profile Send private message Visit poster's website
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
Post Posted: Thu Jan 02, 2020 1:19 pm
Calindro wrote

It depends on the samplerate of your sounds. For example if it's 60Hz you need to call PSGFrame 60 times per second. In that case the easiest way to achieve this is to call it every frame interrupt (because on NTSC frame interrupts occur at 60 Hz).


Oh yes, sorry. PAL is what's being used, so 50 times/sec.


Calindro wrote

Do I understand correctly that you removed this code when you inserted the "vblank wait"?

Sorry, yes of course. If I leave the original delay there too, the game is even slower.

Calindro wrote

You try your SC3000 port on an MSX emulator?


Bluemsx supports also Sega SG1000 and SC3000. Retroarch uses bluemsx as core for .SC and .SG files. Gearsystem is the name of the other core that I couldn't remember.

Calindro wrote

Colors are _NOT_ wrong. In Emulicious you are running your rom on a Mastersystem so you are seeing the correct colors of a Mastersystem running the rom.


Ok, sorry for my bad english.
  View user's profile Send private message
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
Post Posted: Thu Jan 02, 2020 1:50 pm
sverx wrote
Racer's vblank wait seems to be a simple HALT instruction, so it's assuming the only active interrupt is vblank - and it should work if it's so, but it will work badly if there are other interrupts active, for instance the line IRQ one.

you should check the values you wrote into the VDP registers, mainly in registers #0 and #1 to see if frame interrupt is enabled and line interrupt is not.


Interrupts are enabled on register #1. As far as I know, on SC3000 register#0 there's only bit 1 usable and that's mode select (M3).

Below is the stolen code. Disabling waitForVBlank call makes things way tooooo fast. If I put the original djnz loop in there, it works but sounds play too fast and eh, it ain't good. Without sounds then the djnz-loop is fine.

This is a learning process (thanks to this site, good stuff here) for me so things might be (are) possibly wrong. But strange is that it works fine in Meka with the exact code below, but not the others. I would like to get this fully working so it's playable on the Nvidia Shield with Retroarch.


....
.org $38
  push af
  in a, ($bf)
  ld (vdpstatusflag), a
  pop af
  ei
  reti
...
waitForVBlank:
  push af
-:  ld a, (vdpstatusflag)
  bit 7, a        ; bit 7 interrupt flag
  jp z, -
  res 7, a
  ld (vdpstatusflag), a
  pop af
  ret

....

main_loop:
  call waitForVBlank
  call PSGFrame
  call PSGSFXFrame
  ...handle input, move sprites, update scores etc
  jp main_loop
  View user's profile Send private message
  • Joined: 05 Sep 2013
  • Posts: 2559
Reply with quote
Post Posted: Thu Jan 02, 2020 2:03 pm
sorry, I didn't read well enough (we're in 2020 and I've still got to learn to read properly...) - I'm in no way expert on SC-3000, which is probably using a TMS chip, no mode 4 and other SMS stuff.
Still, the code seems correct.
If it's not giving you a steady 50Hz music output, and you have slowdowns, it might mean that your program is taking too much time between interrupts, and you 'skipped' some
  View user's profile Send private message Visit poster's website
  • Joined: 11 Dec 2019
  • Posts: 8
  • Location: Finland
Reply with quote
Post Posted: Thu Jan 02, 2020 3:17 pm
sverx wrote
sorry, I didn't read well enough (we're in 2020 and I've still got to learn to read properly...) - I'm in no way expert on SC-3000, which is probably using a TMS chip, no mode 4 and other SMS stuff.
Still, the code seems correct.
If it's not giving you a steady 50Hz music output, and you have slowdowns, it might mean that your program is taking too much time between interrupts, and you 'skipped' some


Yeah the code is just fine! Now, please don't shoot me :D

I had the game launched in Mame and after finishing a call I accidentally dropped my cellphone. Right on the keyboard of my laptop where Mame is running. At the same moment I heard the game music starting to play at the correct speed and sprites flying across the screen :D It appears my phone hit the F10-key (toggle speed throttling). I had no idea of such a key doing that. I should probably learn how to read documents too ;D For days I've been pulling my hair because of this irritating problem.

Yay! So this problem seems solved at least for the case of Mame.

Thanks for your time and replies!
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!