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 - SG-1000 Hardware Questions...

Reply to topic
Author Message
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
SG-1000 Hardware Questions...
Post Posted: Fri Sep 14, 2018 9:16 am
Hello all,
Long story short; I like 8bit hardware and fell in love with the 8bit Sega consoles ironically thanks to emulation. This later compelled me to buy an actual game gear & master system just to see first hand how they looked & worked.

I have also studied the hardware of these consoles to the best of my ability and am led to think it might be a fun challenge to attempt learning C programming language as well as a little z80 assembly too (since the z80 is used everywhere + ROM hacking sounds fun). Hopefully its a win-win, learning programming & making games.

I have my sights on the SG1000 first however. I understand its rare and possibly counter-intuitive to program for but the sheer simplicity of its primitive & limited hardware makes it a little less intimidating to try out. Problem is I'm having trouble understanding the hardware as there doesn't seem to be much documentation available on it.

Here's what i currently know (correct me if I'm wrong):
-hardware wise, its almost identical to the SMS
-TMS9918 VDP, same found in Colecovision & MSX1
-1KB RAM
-SN76489AN, discrete chip & not integrated
-has a pause button, but is there a reset button?..

Here's what I currently don't know:
-what are the specific limitations of the VDP, what can I do? what can I not do? This mostly pertains to sprites, I've read that it is only 1 color per sprite (+transparent) but I'd like to hear confirmation on that. Are there any good specific docs out there on it?

-does the sound chip have any noticeable differences from the SMS one? I ask because I've been using Deflemask to compose music for the SN...

-are mappers theoretically possible to use with this system to bypass the 48KB ROM limit? I'm guessing so but would like to hear weather its possible or not.

-would SRAM for save data work too?..

-what are the differences between an SG cartridge & an SMS cartridge, is the SMS backward compatible with SG carts?

Thank you all for reading this and forgive me if any of these questions are dumb ones, I'm simply curious to see what limits exist for this system. I have a really cool idea for a mysterious game and would like to know as much as possible before I decide to try and move forward with this idea.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Fri Sep 14, 2018 1:13 pm
Last edited by Maxim on Fri Sep 14, 2018 6:34 pm; edited 1 time in total
The video modes are better documented in the world of MSX and Colecovision, I guess because we usually prefer the more friendly mode 4.

The sound is almost identical, but the noise is a bit different, especially affecting the "periodic" mode.

Mappers and on cart saves can operate identically - but emulator support might not be very good.

The Master System was backwards compatible, but only the Japanese version was actually physically compatible with the cartridges. It also produces quite different colours which can make things look quite ugly.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Fri Sep 14, 2018 6:22 pm
Maxim wrote
The video modes are better documented in the world of MSX and Colecovision, I guess because we usually prefer the more friendly mode 4.


I figured as much, any documentation I did manage to find was from the MSX & Colecovision scene, the color palette is certainly limited but I think I can work with that. I'll re-read over what I have as to better understand these VDP graphic modes.

Maxim wrote
The sound of almost identical, but the noise is a bit different, especially affecting the "periodic" mode.


Ah, that might be of concern to me as half of my themes I have composed thus far make extensive use of the noise channel. One of my themes constantly switches the noise channel between periodic & white. Another theme even goes as far as using the noise channel as the lead instrument, it was a crazy idea but somehow it worked and ended up sounding really cool, I may showcase it sometime but that's for a different thread.

What kind of difference is it? Is it pitch-related? If so, does this pitch difference only affect the noise channel? Or is it simply a difference in sound and there is no pitch change at all? Hell, there's always a chance it might even sound cooler because of the difference.

Maxim wrote
Mappers and on cart saves can operate identically - but emulator support might not be very good.


Thanks for confirming my suspicions, 2 particular games stood out to me in this regard and they were The Castle & Lorretta no Shouzou. One used on-cartridge ram (guessing it was SRAM - the battery backup), The other was abnormally larger than the rest of the games since it was 128KB instead of the usual 32 or 48KB, it had to have used a mapper chip of some sort but I was not sure what exactly. Not too worried about the emulation-side of things, where there's a will, there's a way. ;]

Maxim wrote
The Master System was backwards compatible, but only the Japanese version was actually physically compatible with the cartridges. It also produces quite different colours which can make things look quite ugly.


I've seen that first hand playing SG games on my SMS using my Everdrive. That's okay, I primarily play SG games on my Retropie anyways, its a little more practical considering my Everdrive gives me issues from time to time.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Fri Sep 14, 2018 6:44 pm
Technically, noise is generated using a 16 bit shift register on the SMS. Actual noise uses it to implement a random number generator, which emits a 1 or 0 every so often - at half the rate of the driving frequency. When you go to "periodic" mode, it changes to no random generation, it instead uses it as a kind of delay mechanism, so it emits a 1 1/16 of the time and 0 15/16 of the time. This gets you low pitched, but harsh, tones at 1/32 the driving frequency (exactly 5 octaves lower).

The problem with the original chip is that it has only 15 bits. The noise sounds different - less percussive, I think - and the periodic noise is now 1/15 duty cycle at 1/30 of the driving frequency. In other words - badly out of tune if composed for the SMS.

It's not impossible to fix, but I don't know if any tools exist to do so.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Fri Sep 14, 2018 10:15 pm
Hm.. I wasn't expecting complications in regard to the low-level sound chip differences, that caught me off guard a little. Regrettably I didn't originally think there would be any until delving deeper into it, my mistake for not taking a second glance early on.

My intuition tells me it may still be possible without any specialized tools, but its a "shot in the dark" approach. If I can figure out how to compile some sort of music-playing rom (that is as soon as I learn how to program & compile something in the 1st place), I could see how different it is and if there's a simplistic way around it. I'm thinking maybe if I purposely compose a theme out of tune on SMS then perhaps it will play normally on the SG or close enough at least.. idk really, maybe that's a stupid idea..

Also, does this also apply the other way around too? The SG games I've played on my SMS don't sound out of tune to me but then again I may not have noticed before.

Either way this isn't entirely bad news and I've already learned a few things from all this. I'll have to dig around for some SN76489 docs and see what I can do in the future when I have some spare time.

Thanks for all the input and knowledge, its much appreciated. I think that was all the hardware related questions I had so far, worst-case scenario is that I could always move the milestone to target the SMS instead since that system is supported in Deflemask.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Sat Sep 15, 2018 5:09 am
Deflemask could support it fairly easily, it's just a matter of a constant in the frequency to data conversion. Early games (including SG-1000) basically never use that feature in their music, it's more common in later Master System games (mostly from Matt Furniss),
  View user's profile Send private message Visit poster's website
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Sat Sep 15, 2018 4:32 pm
The real problem with SN76489 vs the SEGA VDP DCSG is that writing a value of zero on the frequency registers of a actual discrete SN76489 has the effect of 0x400 and on SEGA DCSG the effect is 0x001.

This is the VGM data from Mega Drive Sonic the Hedgehog Green Hill Zone (only the SN76489 part) played on a discrete SN76489:
https://drive.google.com/open?id=12XAJIxnJE9sHwzPXV13ddROm_9-YxYuw

After filtering 0x000 writes (changing any 0x000 frequency writes to 0x001) to the SN76489 by software it sounds like this:
https://drive.google.com/open?id=1zQ0QXV4ZgWcQv8GBCcFeQsnK8q1-URQ2

That's a really annoying "gotcha" thing nobody talks about.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Sat Sep 15, 2018 8:56 pm
It's probably not well known... I didn't remember it. It seems like it only affects samples? I may need to change some of my player code...
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Sat Sep 15, 2018 9:21 pm
Man.. this got even more complicated than I imagined. I understand the register concepts but its still a bit confusing to me, still learning these things as i go.

I'm willing to share a .vgm sample of one of my themes to serve as a test subject if need be.
  View user's profile Send private message
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Sat Sep 15, 2018 10:22 pm
This is the macro for the register write code with patching which scans for and replaces the frequency value. Franky is that MSX cartridge with a SMS2 VDP if you don't know it already. I am leeching the I/O address from Franky in my own design for practical reasons.


Franky: MACRO
   super: Driver Driver_PrintInfoImpl
   Previous:
        dw 0
   
   ; a = value
   SafeWriteRegister:
   ; a = value
   WriteRegister:
      push bc
      ld b,a         ; save value
      ld a,(Previous)   ; retrieve previous
      and 09Fh      ; channel number is not important so we mask out
      cp  080h      ; is it frequency setup write?
      ld a,b         ; restore value
      jr nz, no_patch ; nope, it is not
      cp 000h         ; is it zero frequency?
      jr nz, no_patch ; nope, it is not
      ld a, 1         ; it is so we set it as 01
   no_patch:
      out (Franky_DATA),a
      ld (Previous),a ; save previous for next check
      pop bc
      ret
   ENDM


This code has "a small compromise" in that it will "corrupt" some frequencies if the value has "0000" as the lower nibble of on the first write as it will be replaced with "0001"...

This problem of the SN76489 writes of 0x000 weight as 0x400 affects any channels not just the noise generator.
  View user's profile Send private message
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Sat Sep 15, 2018 11:23 pm

Franky: MACRO
   super: Driver Driver_PrintInfoImpl
   
   ; a = value
   SafeWriteRegister:
   ; a = value
   WriteRegister:
      push bc
      ld b,a         ; save value
      and 09Fh      ; channel no is not important so we mask out
      cp  080h      ; is it zeroed frequency setup write?
      ld a,b         ; restore value
      jr nz, no_patch ; nope, it is not
      add a, 01h         ; it is so we set it as 01
   no_patch:
      out (Franky_DATA),a
      pop bc
      ret
   ENDM


On my previous experiments I tried to compute the whole write but since the least significant nibble is written first, the point of saving the previous write is kind of moot unless I would store both bytes without write them then process and write. I made it so it matches the behavior I described on the previous post with that very minor drawback of adding 0x001 to any frequency which the first nibble is "0000".

If you're writing your music driver, just never write 0x000 as a frequency value since it is meaningless on the SEGA VDP (it is the same as writing 0x001) and it causes problems on the discrete SN76489.
  View user's profile Send private message
  • Joined: 31 Oct 2007
  • Posts: 853
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Sun Sep 16, 2018 4:24 am
0 on real PSG chip is the lowest possible freq ($400), while for some retarded reason the VDP PSG has it special cased to 1, losing one freq step on the lower end.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Sun Sep 16, 2018 4:48 am
Tiido, actually SEGA stuff expects that behavior so I have to filter that up.

Also, I fixed that trainwreck of code:

Franky: MACRO
   super: Driver Driver_PrintInfoImpl
   Previous:
      db 0
   
   ; a = value
   SafeWriteRegister:
   ; a = value
   WriteRegister:
      push bc
      ld b,a         ; save current write value
      ld a,(Previous)   ; Here we check if previous byte is the "FIRST BYTE" of a zeroed write to "FREQ DATA LOW"
      and 09Fh
      cp  080h
      ld a,b         ; restore current value
      jr z, frequ      ; If the previous byte is the "FIRST BYTE" of a zeroed write to "FREQ DATA LOW" we deal with it now.
      and 09Fh
      cp  080h
      ld a,b
      jr nz, no_store   ; If the current write is a zeroed write to "FREQ DATA LOW" write we store it for the next write cycle.
      ld (Previous),a ; store "FIRST BYTE" as previous      
   no_store:   
      out (Franky_DATA),a
      pop bc
      ret
   frequ:
      cp 000h         ; is "FREQ DATA HI" a zero value?
      ld a,(Previous)   ; restore "FIRST BYTE"
      jr nz, no_patch ; "FREQ DATA HI" is not zero value
      add a, 01h      ; "FREQ DATA HI" is zero so we set "FREQ DATA LOW" to "0001b"
   no_patch:
      out (Franky_DATA),a
      ld a,b         ; restore "FREQ DATA HI"
      out (Franky_DATA),a
      ld (Previous),a ; destroy previous "FIRST BYTE"
      pop bc
      ret
   ENDM


Now it actually caches one access and does both when it's a zeroed frequency write.
  View user's profile Send private message
  • Joined: 16 Mar 2018
  • Posts: 29
  • Location: Indiana
Reply with quote
Post Posted: Sun Sep 16, 2018 7:04 am
TmEE wrote
0 on real PSG chip is the lowest possible freq ($400), while for some retarded reason the VDP PSG has it special cased to 1, losing one freq step on the lower end.


Just clarifying. On a discrete chip, the data input range is 10bit 0x000-0x3FF but the frequency behavior is as if the range was 0x001-0x400, where the 0x000 triggers the 0x400 frequency. On the Sega implementations a 0x000 input is the same behavior as 0x001 (really high frequency) or does the 0x000 cause a hard ‘1’ to be output?
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Sun Sep 16, 2018 7:40 am
It's not clear because I haven't got an oscilloscope to inspect it, if those frequencies are even visible on the chip output. The analogue filtering certainly makes those frequencies disappear.

It ought to be possible to test it by using tone controlled periodic noise to shift it down in frequency, so tone 1 will correspond to ~7kHz and tone 400 to ~7Hz. A "hard 1" (or zero) would produce nothing.

For emulation purposes, 0-5 or so are all treated as "hard 1" - but the real chip behaviour is more complicated.
  View user's profile Send private message Visit poster's website
  • Joined: 16 Mar 2018
  • Posts: 29
  • Location: Indiana
Reply with quote
Post Posted: Sun Sep 16, 2018 11:43 am
I have an everdrive, mega drive and scope. I could try to throw together a test of the Sega side for the 0-6 inputs. I have a coleco Adam with a discrete chip as well but don’t have a way to program an output for it. I may have a basic tape for it. Not sure if that will get me access to the psg. Let me know if you want me to test it.
  View user's profile Send private message
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Sun Sep 16, 2018 1:14 pm
I have a 315-5124 VDP and this SN76489 chips which I can connect to my MSX computer. I also own an oscilloscope. If any of you come up with a test procedure I can try to apply.
  View user's profile Send private message
  • Joined: 16 Mar 2018
  • Posts: 29
  • Location: Indiana
Reply with quote
Post Posted: Sun Sep 16, 2018 3:57 pm
I’d set the attenuation to 0x0 on all channels. For the discrete, set Tone 0 to 0x000, attenuator to 0xF and measure the frequency at the output of the chip.

Do the same for the vdp but take measurements at frequencies 0x006 down to 0x000.

Be sure to take the measurements right at the Audio output pins from the chips so we aren’t measuring the effects of the audio amp circuit.
  View user's profile Send private message
  • Joined: 31 Oct 2007
  • Posts: 853
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Sun Sep 16, 2018 5:03 pm
From my tests I did about a year ago I saw that attenuators silence the output completely, nothing leaks through. Highest freqs are always output by the chip. On real PSG they're faily noisy due oscillations caused by low bandwidth of the internal buffer amp and difficult to discern while on VDP PSG they're perfectly clear but with great non linearity dependent on exact external resistor value used, especially on MD VDPs as they use MOSFETs and not BJTs like real PSG. External filtering will greatly attenuate these highest freqs on most hardware.

Frequency value of $000 produces (MCLK / 32) / $400 output frequency on TI
PSG while on VDP it produces (MCLK / 32) / $001. Volume and frequency writes
do not reset the phase of tone channels but frequency writes will reset phase
of noise channel. It is possible to keep noise channel output permanently low
by writing into frequency register. All writes take effect immediately.
  View user's profile Send private message Visit poster's website
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Sun Sep 16, 2018 5:17 pm
I'm confused now hahah

I'm getting annoyed with unreliable docs... What the heck is that?
I'll check the dev page on this site, but I am just showing how confusing this can get if you just download stuff found with Google.
SN76489_a.png (42.68 KB)
SN76489_a.png
SN76489_b.png (47.87 KB)
SN76489_b.png

  View user's profile Send private message
  • Joined: 16 Mar 2018
  • Posts: 29
  • Location: Indiana
Reply with quote
Post Posted: Sun Sep 16, 2018 5:36 pm
TmEE wrote
From my tests I did about a year ago I saw that attenuators silence the output completely, nothing leaks through. Highest freqs are always output by the chip. On real PSG they're faily noisy due oscillations caused by low bandwidth of the internal buffer amp and difficult to discern while on VDP PSG they're perfectly clear but with great non linearity dependent on exact external resistor value used, especially on MD VDPs as they use MOSFETs and not BJTs like real PSG. External filtering will greatly attenuate these highest freqs on most hardware.

Frequency value of $000 produces (MCLK / 32) / $400 output frequency on TI
PSG while on VDP it produces (MCLK / 32) / $001. Volume and frequency writes
do not reset the phase of tone channels but frequency writes will reset phase
of noise channel. It is possible to keep noise channel output permanently low
by writing into frequency register. All writes take effect immediately.


Curious about getting the noise to output permanently low. From a hardware perspective, that wouldn’t seem to be possible. Do you have a set of instructions to make that happen and does it happen on both chips? And by frequency writes to the noise channel resetting the phase, does that just mean writing to register 110 or would it reset if noise is being clocked by tone2 and you change tone 2?
  View user's profile Send private message
  • Joined: 16 Mar 2018
  • Posts: 29
  • Location: Indiana
Reply with quote
Post Posted: Mon Sep 17, 2018 3:01 am
I spent some time thinking about the 0x000 case. Surprisingly, my naive Verilog implementation replicates the 0x400 frequency (109.24hz). If you think about it, it makes sense although it doesn’t match the data sheet. (A mathematical interpretation of how you calculate frequency would indicate a hard high output). Each clock cycle the chip decrements a counter. If the counter is 0 it reloads the value and toggles the output. Ordering here is important. If the value is reloaded before the decrement, the value overflows and you get 109.24hz. I can see someone seeing the jump from very high frequencies to a very low like that being counter intuitive and trying to protect the programmer by locking 0x000 to 0x001. Sinc ethe frequency difference is only .1hz.
  View user's profile Send private message
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Mon Sep 17, 2018 4:34 am
Last edited by kaportza on Mon Sep 17, 2018 7:25 pm; edited 1 time in total
It makes me wonder how to SN chip is emulated when I play the SG1000 games on my Retropie. The emulator in use is the libretro genesis-plus-gx emu. I tried looking through the source code that involved the sound but due to my ignorance I find myself stumped and not exactly sure what to look for.. most of all this is way over my head for the time being until I can do some more studying to better comprehend it later on.

From what I've read so far it does seem possible but its beyond my current knowledge & skill set.

I'm really glad I asked about this first before doing anything else. My plan was to literally have everything else done myself; bgm, sfx, gfx, story writing, dialogues, level design & concept art whilst fully understanding the hardware constraints and creatively working within them as part of the challenge (as well as learning programming during this process, even if I fail horribly at it). Once completed I was wanting to launch some sort of crowdfunding effort so I could hire an experienced programmer or two to put all the pieces together, the resulting game would then be distributed freely so the game could establish itself. I think that was the same approach the developer of Cave Story took (love that game btw), though it started out as a PC game rather than a homebrew for a vintage console. *edit; I believe the Cave Story developer was already an experienced programmer though, I was simply referring to that last part about distribution.

Before I were to attempt any of that I figured it might be important to seek the advice of some hardware experts first, it was certainly a good call.

I wonder how the Mojon Twins dealt with this issue when they made Super Uwol for the SG1000, looking through the source code of that game as been a good learning experience for how C programming works. Perhaps looking at the .psg files in hex view may give me a clue? No idea what they used to compose their music.. Running the game through a debug-capable emulator and analyzing writes to the sound chip might provide me with insight, I'll have to try that sometime.

Here's a VGM sample to play with if anyone is interested in getting it to work properly on SG hardware as a proof-of-concept sort of thing. Keep in mind I'm not exactly music literate, I get a vague theme started in my mind and then just kind of "lego brick" combinations of notes & patterns together until it sounds good if that makes any sense lol.

  View user's profile Send private message
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Mon Sep 17, 2018 6:04 am
I tried your VGM on my HW setup and it sounds like this:

https://drive.google.com/open?id=1tV2mZ4rvMpp48Tgbmyk5da3KKL3YE-ce
  View user's profile Send private message
  • Joined: 29 Mar 2012
  • Posts: 879
  • Location: Spain
Reply with quote
Post Posted: Mon Sep 17, 2018 7:49 am
kaportza wrote

I wonder how the Mojon Twins dealt with this issue when they made Super Uwol for the SG1000, looking through the source code of that game as been a good learning experience for how C programming works. Perhaps looking at the .psg files in hex view may give me a clue? No idea what they used to compose their music.. Running the game through a debug-capable emulator and analyzing writes to the sound chip might provide me with insight, I'll have to try that sometime.


I know Mojon Twins (and David, the musician) in person. I'll ask them how they dealt with that
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Mon Sep 17, 2018 7:57 am
If you avoid the corner case of zero wavelength then the whole issue drops away - and it's not even that useful anyway. If you avoid periodic noise then you don't need to adapt for its difference. The noise difference is fairly minor. I'll see if I can make something to demonstrate it.
  View user's profile Send private message Visit poster's website
  • Joined: 31 Oct 2007
  • Posts: 853
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Mon Sep 17, 2018 8:35 am
Enforcer wrote
Curious about getting the noise to output permanently low. From a hardware perspective, that wouldn’t seem to be possible. Do you have a set of instructions to make that happen and does it happen on both chips? And by frequency writes to the noise channel resetting the phase, does that just mean writing to register 110 or would it reset if noise is being clocked by tone2 and you change tone 2?


LFSR is reset on each freq write to the noise channel, reset value is top bit getting set while all others are back to zero. Then depending on chip it takes 14 or 15 cycles for first output to appear.
Tone2 won't have any effect here, only writes to noise channel freq register matter.
Here are the beginnings of the noise patterns on either chip (they're from my PSG emulation core but real hardware matches the behaviour) :
http://www.tmeeco.eu/SMS/SEGA%20VDP%20PSG%20Noise%20Pattern.flac
http://www.tmeeco.eu/SMS/TI%20PSG%20Noise%20Pattern.flac
  View user's profile Send private message Visit poster's website
  • Joined: 16 Mar 2018
  • Posts: 29
  • Location: Indiana
Reply with quote
Post Posted: Mon Sep 17, 2018 12:58 pm
Thanks for the info. My implementation was resetting noise properly on writes and supports both noise styles. I’d capture some examples but I need to get some of the VDP working, unless you know of some code that doesn’t require a VDP to play, just the Z80 and PSG.
  View user's profile Send private message
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Mon Sep 17, 2018 1:15 pm
For sake of science I had to give this test a spin:

Franky: MACRO
   super: Driver Driver_PrintInfoImpl
   Previous:
      db 0
   
   ; a = value
   SafeWriteRegister:
   ; a = value
   WriteRegister:
      push bc
      ld b,a         ; save current write value
      ld a,(Previous)   ; Here we check if previous byte is the "FIRST BYTE" of a zeroed write to "FREQ DATA LOW"
      and 09Fh
      cp  080h
      ld a,b         ; restore current value
      jr z, frequ      ; If the previous byte is the "FIRST BYTE" of a zeroed write to "FREQ DATA LOW" we deal with it now.
      and 09Fh
      cp  080h
      ld a,b
      jr nz, no_store   ; If the current write is a zeroed write to "FREQ DATA LOW" write we store it for the next write cycle.
      ld (Previous),a ; store "FIRST BYTE" as previous      
   no_store:
      out (018h),a   ; write to 315-5124   
      out (Franky_DATA),a ; write to SN76489
      pop bc
      ret
   frequ:
      and 0BFh
      cp  000h        ; is "FREQ DATA HI" a zero value?
      ld a,(Previous)   ; restore "FIRST BYTE"
      out (018h),a   ; write to 315-5124 before patching
      jr nz, no_patch ; "FREQ DATA HI" is not zero value
      inc a         ; "FREQ DATA HI" is zero so we set "FREQ DATA LOW" to "0001b"
   no_patch:
      out (Franky_DATA),a ; write to SN76489
      ld a,b         ; restore "FREQ DATA HI"
      out (Franky_DATA),a ; write to SN76489
      out (018h),a   ; write to 315-5124
      ld (Previous),a ; destroy previous "FIRST BYTE"
      pop bc
      ret
   ENDM
This code will apply patching to any data sent to the SN76489 but will send raw data to the 315-5124. SN76489 is connected to I/O port 0x1C-0x1F and 315-5124 is connected to 0x18-0x1B
I recorded both playing in parallel so the waveforms can be compared. One of them might have a few milivolts stronger signal than the other but I don't think it's too bad.

Resulting recording:
https://drive.google.com/open?id=1Um2s9SDPANotzUcAYURpY_fzqMcBGQnP
Download it and open on Audacity or other sound editor for case study.

L = 315-5124
R = SN76489

P.S.: Sorry about kind of hijacking your thread, kaportza. But I hope you find this info useful.
  View user's profile Send private message
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Mon Sep 17, 2018 8:36 pm
l_oliveira wrote

P.S.: Sorry about kind of hijacking your thread, kaportza. But I hope you find this info useful.


No no its fine haha, I'm all for science! Even if I don't fully understand it right now, others certainly will.

Thanks for testing my theme btw.

Maxim wasn't kidding about that periodic noise difference, its definitely a few notes off, thankfully the square waves & white noise still sounds in tune which is still good news. As I mentioned earlier, I have a rather bizarre theme that uses the noise channel as the lead instrument, thankfully that theme uses the white noise mode instead so that's a relief to know it could still work.

The not so good news is that same bizarre theme is actually just a slowed-down remix of a previous theme I composed which uses a combination of the locked 3-note periodic & white modes to form the beat. That original theme might be toast now if played on the SG...

kusfo wrote

I know Mojon Twins (and David, the musician) in person. I'll ask them how they dealt with that


Thanks, I was thinking about asking them at some point in the future but wasn't sure weather I would get a response.

I realized early on that when I set the noise channel to free range I could still somewhat use the 3rd square wave as long as they are both playing the same note & vice versa. With the SN76489AN however, that appears impossible to do when using periodic.. sure, I could purposely play a periodic note out of tune so that it plays right on the SG, but then the 3rd square wave would be off tune thus making it mostly unusable in that manner.

I looks like some of my existing themes will have to be altered in order to work around this problem but its not too bad. Funny thing is, before I asked about all this, I was thinking about another experimental theme in which the noise channel would once again be the lead instrument but this time in periodic... just to see if it could be done. Imagine how much of a disaster that would've been not knowing how badly it would've sounded because of a small sound chip hardware difference hahaha.
  View user's profile Send private message
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Mon Sep 17, 2018 8:47 pm
You're welcome to ask for hardware recordings if you feel like.
  View user's profile Send private message
  • Joined: 29 Mar 2015
  • Posts: 3
  • Location: Spain
Reply with quote
Post Posted: Tue Sep 18, 2018 6:01 pm
Hi! I'm David from Mojon Twins.

In Super Uwol we used VGM Music Maker. I've attached a module for you to take a look.

2 channels + noise for music and channel 3 for sound effects.

If you need more info, let me know ;)

  View user's profile Send private message Visit poster's website
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Tue Sep 18, 2018 6:14 pm
Can you export it as regular .vgm? The player I have doesn't support .vge files.

Edit: Nevermind, I found a old copy of the vgm maker software at Famitracker's forum.
  View user's profile Send private message
  • Joined: 29 Mar 2015
  • Posts: 3
  • Location: Spain
Reply with quote
Post Posted: Tue Sep 18, 2018 6:24 pm
Ok.

The vgm is 1.50 because psglib needs this vgm version.
m_ingamec.vgm (5.24 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 29 Jan 2014
  • Posts: 95
  • Location: Brasilia, Brazil
Reply with quote
Post Posted: Tue Sep 18, 2018 6:41 pm
https://drive.google.com/open?id=1AADIezfJnt_c9Rl-u3nQ6M3uaK9Wc7VW

L = 315-5124
R = SN76489AN


edit:

Davidian wrote
Ok.

The vgm is 1.50 because psglib needs this vgm version.


Actually I got a copy of Shiru's program and converted the file by myself. The player I am using (Grauw's VGMPLAY-MSX) works with files up to 1.5x for PCM stuff. It doesn't support 1.6x streams yet.

I downloaded this file and compared to the one I converted and they're byte exact. So, I suppose the flac I just posted is fine.
  View user's profile Send private message
  • Joined: 15 Sep 2009
  • Posts: 377
Reply with quote
Post Posted: Tue Sep 18, 2018 7:27 pm
Nuke.YKT, a guy who writes cycle accurate sound chip emulators based on die shots, recently released something called Nuked-PSG - it emulates the SEGA VDP PSG.

As you can see at line 196 of the code, the frequency counter actually counts up, not down. This causes frequency 000 and 001 to be the same.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Tue Sep 18, 2018 7:40 pm
It's labelled as YM7101 which is the Mega Drive chip, but I'd expect it to be very similar to the Master System PSG. There is an SN79486 die picture out there, but I don't know if anyone has done the work to analyse it.

I'm fairly sure the PSG operates in a binary fashion - emitting 1 or 0 on each channel into the attenuation and filtering, and relying on the high pass filters to remove the DC offset. The use of sign bits in the code makes me think it's not a purely decap based emulation, which I'd have thought would be a lot less straightforward.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Thu Sep 20, 2018 5:42 am
l_oliveira wrote
You're welcome to ask for hardware recordings if you feel like.


Yes will do! I'll pm you some other VGMs to test out later.

Davidian wrote
Hi! I'm David from Mojon Twins.

In Super Uwol we used VGM Music Maker. I've attached a module for you to take a look.

2 channels + noise for music and channel 3 for sound effects.

If you need more info, let me know ;)


Thanks for sharing the Super Uwol VGM, excellent work on the music for that game. I was also really impressed on what you guys were able to pull off on a console with only 1/2 the memory in comparison to the NES. The sprite multiplexing was creative too. I'm guessing sprites were stacked to bypass the single color limitation as well. I'll have to take a look at this VGM Music Maker some time, I'm always willing to try out other trackers.

Was memory ever an issue when playing music & sfx? Did you guys ever have to worry about running out of ram throughout the game's development process? If so, what was the most memory-intensive part?

Yeah I ran Super Uwol in MEKA to listen to the sound channels and I noticed the lesser use of the 3rd square wave, was it because of a music engine limitation? I ask because my BGMs often max out the use of all channels including 3rd square wave.

Also, I know this isn't music related but what software did you guys use to make the gfx? I'm currently using GIMP for sprite & tile artwork but will need to learn how to convert them into a compatible format later on.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14689
  • Location: London
Reply with quote
Post Posted: Thu Sep 20, 2018 6:55 am
It's normal to avoid the last tone channel (or put the least important music channel on it) because it needs to be pre-empted for SFX.
  View user's profile Send private message Visit poster's website
  • Joined: 07 Oct 2015
  • Posts: 114
Reply with quote
Post Posted: Thu Sep 20, 2018 7:27 am
Exactly, we usually play SFX in the channel with less important stuff, so music doesn't suffer much when playing them.

Exactly, sprites were stacked. That introduces more flickering, but we thought it was more of a gain than a loss.

Memory wasn't an issue when playing music and SFX as the player takes a very small memory footprint. The game doesn't have to remember much, so we could fit everything in the small space. It wasn't really a problem. It would have been for a different game with multi screen levels, tho.

For graphics I personally use a very old version of Photoshop (7) and Aseprite, and all the converters I need are in my toolchain (which I wrote). mkts.exe does the job in Uwol, it's a rather old version but it works with SG-1000 just fine for BG tiles and (meta)sprites.
  View user's profile Send private message
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Mon Sep 24, 2018 9:32 am
na_th_an wrote
Memory wasn't an issue when playing music and SFX as the player takes a very small memory footprint. The game doesn't have to remember much, so we could fit everything in the small space. It wasn't really a problem. It would have been for a different game with multi screen levels, tho.


I saw that too when looking at the ram in MEKA, the usage wasn't all that high. Was video ram ever an issue?

Apart from that, Its increasingly looking like the 1KB system ram is now my main concern at this point. The game I have in mind is an action-adventure rpg but with more detail than usual, along with the possibility of choice-based consequences that determine certain outcomes.

Similar to games like Zelda or Hydlide, I'm hoping to accomplish something similar in that fashion when it comes to having the player explore from area to area, be it external areas in an overworld or internal areas like dungeons & caves. This of course would require mapping as the completed rom would be way past 48KB in size.

This sounds great at first but given all those variables I fear It might eat away at ram availability rather quick, maybe sram could partially offload anything non-crucial if it doesn't impact performance too much?

I'm imagining a rather simplistic yet robust engine that could transition from top-down view or side-view platformer mode. There would also be a basic dialogue routine, chronological timeline and inventory system. Along with save support for progress too. Surely it could be done right?..

Apart from Super Uwol, there were other games that inspired me for their technical creativity; such as Monaco GP for its headlights when racing in the darkness effect, I have yet to figure out how that was done. My theory is that the headlight beam is actually just an underlying group of sprites and the other cars in this darkness area are simply changed to black to blend in, the car sprites are given higher display priority so they will appear over the light when seen. It gives me an idea for a dark dungeon/area which would only be navigable with a light source.

Two other games were Pitfall 2 & Girl's Garden, both of which seem to use cycled animation tile data in VDP memory (water in Pitfall 2 & the bears in Girl's Garden). I think Girl's Garden also uses the extra-large sprite magnification feature I've been reading about in the docs I found, that's really cool too but I don't think its possible if it can be applied to an individual sprite though.
  View user's profile Send private message
  • Joined: 24 Sep 2018
  • Posts: 66
Reply with quote
Post Posted: Mon Sep 24, 2018 4:33 pm
kaportza wrote
I think Girl's Garden also uses the extra-large sprite magnification feature I've been reading about in the docs I found, that's really cool too but I don't think its possible if it can be applied to an individual sprite though.


On the TMS it's all or nothing — the single selection applies to all sprites. Ditto for source data size (i.e. 8x8 or 16x16).

I'm sure you've figured out most of the other details since your first post, but since it went unanswered, in its best graphics mode the VDP offers:

  • [up to*] three sets of tiles, each for use in a different 32x8 part of the screen;
  • each tile is 1bpp with a per-line palette;
  • 32 sprites per frame;
  • 4 sprites per line;
  • each sprite being a single colour and, via a single setting for all sprites, either 8x8 or 16x16 pixels of source data, displayed either at 1:1 size or at 1:2 size;
  • a single collision flag will tell you if any two sprites overlapped; and
  • a flag will tell you if there was ever a line where there should have been a fifth sprite, in which case the number of the sprite that would have been fifth is available.

* an undocumented feature allows you to mask off part of the address here and reduce the number of tile sets; I've no idea whether that is implemented on the SMS VDP.

Memory availability is much the same as the Master System, with available access slots being a maximum of 16/171ths of a line apart, and there's also a 2us delay between you providing a new byte. So 8us is the recommended maximum write speed.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Tue Sep 25, 2018 9:21 am
TomHarte wrote
On the TMS it's all or nothing — the single selection applies to all sprites. Ditto for source data size (i.e. 8x8 or 16x16).


Thanks for confirming, I knew most of all the other stuff you pointed out, except for the 1bpp part. I didn't understand why a monochrome format is used in a color-capable TMS but since I've been reading about the way colors are handled its slowly starting to make sense. It now makes sense why it displays as monochromatic in MEKA's tile viewer.

One thing I'm not sure of yet is the VDP memory size, many sources throughout the internet say 16KB but I need to make sure.

Another technical marvel I enjoy is watching the color-cycling in the SEGA startup logo in these games, I would love to know how that's done.

I've been reading about the graphic modes (I & II) lately and trying to comprehend how they work and what the differences between them are. I guess nearly all existing games use mode 2.

The hard part at the moment is trying to understand the nitty-gritty details of things like the pattern name table, the pattern generator table and the color table. These are a bit confusing to me but maybe It will make more sense over time as long as I stay determined. Finding and reading different docs also helps as each one explains things in slightly different ways.
  View user's profile Send private message
  • Joined: 31 Oct 2007
  • Posts: 853
  • Location: Estonia, Rapla city
Reply with quote
Post Posted: Tue Sep 25, 2018 12:17 pm
There's 16KB of VRAM in all SG and SC machines. Main RAM varies however, SC-3000 has 2KB and SG-1000 has 1KB. SG-1000II I think has 2KB also but I'm not completely certain.
  View user's profile Send private message Visit poster's website
  • Joined: 24 Sep 2018
  • Posts: 66
Reply with quote
Post Posted: Tue Sep 25, 2018 1:12 pm
kaportza wrote
Thanks for confirming, I knew most of all the other stuff you pointed out, except for the 1bpp part. I didn't understand why a monochrome format is used in a color-capable TMS but since I've been reading about the way colors are handled its slowly starting to make sense. It now makes sense why it displays as monochromatic in MEKA's tile viewer.

The whole thing was designed in 1977 and 1978 so don't rule out that some decisions may just be a result of industry inexperience. But I guess it's just that there's only the memory bandwidth to fetch two bytes for each 8x1 portion of the display, and arranging them as (i) one byte defining the foreground and background colour; and (ii) another indicating which positions contain the foreground colour and which contain the background; gives you 16 colours across the entire display. If they'd just gone straight 2bpp then it would have been only 4 colours.

kaportza wrote
I've been reading about the graphic modes (I & II) lately and trying to comprehend how they work and what the differences between them are. I guess nearly all existing games use mode 2.

If it helps for context, the original TMS9918 didn't have the second graphics mode. It was a clever addition for the first revised version, the TMS9918a.

I'm not yet permitted to post links, but if you'll allow yourself the digression, search for "At the right is a set of documents and emails I received from Karl Guttag" to find a page on a site called Spatula City with an archive of memos from inside TI during the TMS design period. On that page see the file e2/198x_Super_Pattern_Graphics_Mode_(Mode_2).pdf for the hand-written proposal to add graphics mode 2. It's short and it also has some content comparing and contrasting the new mode with the existing graphics modes.
  View user's profile Send private message Visit poster's website
  • Joined: 14 Sep 2018
  • Posts: 50
  • Location: Earth
Reply with quote
Post Posted: Wed Sep 26, 2018 9:32 am
TmEE wrote
There's 16KB of VRAM in all SG and SC machines. Main RAM varies however, SC-3000 has 2KB and SG-1000 has 1KB. SG-1000II I think has 2KB also but I'm not completely certain.


Ok good, I'm currently making a text document listing the hardware specs, with the focus on accuracy. Maybe I'll buy an SG-1000 II someday out of curiosity to find out, the original 1000 is a bit too rare & costly anyway. That's one more confirmation, thanks :]

TomHarte wrote
I'm not yet permitted to post links, but if you'll allow yourself the digression, search for "At the right is a set of documents and emails I received from Karl Guttag" to find a page on a site called Spatula City with an archive of memos from inside TI during the TMS design period. On that page see the file e2/198x_Super_Pattern_Graphics_Mode_(Mode_2).pdf for the hand-written proposal to add graphics mode 2. It's short and it also has some content comparing and contrasting the new mode with the existing graphics modes.


Found it, thanks for pointing that out. Its a little tough reading his handwriting but its still quite an interesting find. Luckily I've also found an additional doc on a site titled; The 8-bit TMS9918 "Not Quite a Standard". It's on a site called Nerdy Pleasures and that one has also been fun to read as well.

Looks like I've got a lot of important questions answered, I've also found a good amount of documentation too. Given my non-existent programming & assembly experience this project will still be a monumental task but I still think its at least worth a try. At some point in the future I'll ask about software-related questions since I'm wanting to learn sverx's devkitsms but that's for another time and another thread... Thanks for the help everyone.
  View user's profile Send private message
Reply to topic



Back to the top of this page

Back to SMS Power!