Forums

Hi guys, I wrote an article about the inner workings of the SMS. I actually got a lot of info from this site (which I'm extremely grateful and have included the proper citations) so I was wondering if anyone would like to give some feedback before I publish it.

Here it is: http://copetti.org/projects/consoles/master-system/ (I can't add it as an URL). It's a 'private' draft for now.

Thanks.

I fixed your URL. I’ve read your other stuff, I’ve been looking forward to this :)

Very good series. I would like to participate and prepared a german translation of _index.md. Please take a look at https://github.com/bodhi-baum/Architecture-of-consoles/blob/master/articles/_ind...

- Japanese SMS also has rapid-fire and 3D glasses support built in, but no reset button
- The CPUs are a mixture of Zilog and other manufacturers like NEC but they are all official Z80s as I understand it. I don’t think there’s any particular time pattern to it.
- The CPU runs at 3579545Hz (NTSC), not 4MHz
- While only 8KB of system RAM is present, the memory map doesn’t expose 56KB of cartridge ROM, it just wastes 8KB of address space.
- It seems worth mentioning that there’s 16KB of video memory in the Memory section.
- IN/OUT don’t send interrupts to the attached devices, they just signal on a CPU pin that this is an IO bus read/write rather than memory bus. The devices themselves are responsible for checking the (low 8 bits of the) address and this bus pin. If they need time to respond they can halt the CPU - but this doesn’t happen on the SMS.
- The VDP can render up to 256x240 but 256x192 (with the left 8px hidden when scrolling horizontally so effectively 248x192) is by far the most common mode

More later!

Bodhi1969 wrote

Very good series. I would like to participate and prepared a german translation of _index.md. Please take a look at

That would be a great addition! you can open a pull request so we can review it and merge it.

Maxim wrote

More later!

Thanks, I'm making the corrections just now.

Some comments:

- "D4168" isn't a CPU. The "uPD4168" is a type of pseudo static RAM (NEC calls it XRAM, most manufactures call it PSRAM). Did you mean the NEC uPD780 which is a Z80?

- I think it's better to refer to the CPU name (Z80) then the specific part number (Z0840004PSC) because the Z80 had many second sources (Sharp, Rohm, NEC, Mostek, etc.) most of which were also used in the SMS.

They're all Z80s, but Sega didn't prefer or target a specific manufacturer when they designed it. They used whatever was available and affordable.

Maxim wrote

- While only 8KB of system RAM is present, the memory map doesn’t expose 56KB of cartridge ROM, it just wastes 8KB of address space.

I'm not sure I understand this. So the memory map has the 8 KB of RAM and just 8 KB of cartridge ROM?

Maxim wrote

- The VDP can render up to 256x240 but 256x192 (with the left 8px hidden when scrolling horizontally so effectively 248x192) is by far the most common mode

I see, so the effective resolution is 248x192 or 248x240 ? I've attached a sonic screenshot that I use as reference.

result.png (2.67 KB)

Sonic screenshot

Charles MacDonald wrote

I think it's better to refer to the CPU name (Z80) then the specific part number (Z0840004PSC) because the Z80 had many second sources (Sharp, Rohm, NEC, Mostek, etc.) most of which were also used in the SMS.

I agree, I thought it would make it more complete, but it eventually gets confusing.

flip wrote

I see, so the effective resolution is 248x192 or 248x240 ? I've attached a sonic screenshot that I use as reference.

Only if you want a game to scroll horizontally. Games with static screens or only vertical scrolling usually have an effective resolution of 256x192.

Also, when scrolling horizontally, the leftmost column of tiles is blanked, not the extremes on both sides of the screen. Some emulators center the image, so it looks like the latter. However, that's not how the hardware works.

Some other things I've noticed on the first read-through:

- The YM2413 can have one custom instrument, not one custom channel. You can use the custom instrument on all nine channels at the same time if you like. It's also worth mentioning that the chip has two modes of operation: nine channels or six channels plus percussion. As far as I know, no commercially released Master System game ever actually used nine-channel-mode.

- Of the two buttons present on the console itself, only the pause button triggers an NMI. The reset button is simply a button like those on the control pads and is read from the same ports.

The standard memory map is 48KB for ROM, 8KB system RAM and then another 8KB mirror of system RAM with some of the upper bytes also shadowed by some memory-mapped things (paging registers on the cart, 3D glasses). However technically cartridges can map anything they like to the address space (for both memory and IO) - but practically all they do is add some on-cart RAM sometimes.

- The space used for tile maps, tiles and sprite tables is flexible - most games use the standard layout but some effects come from sacrificing some parts in favour of others, eg putting tiles in unused space and using multiple tile maps. This no area of VRAM is “reserved”.
- Colour RAM is really 6-bit. The data is written as bytes but the upper bits are never saved (probably - certainly they have no effect).
- “ There are 16 pixels defined on every tile, the VDP rules that pixel must weight 4 bytes, that means that up to 16 colours can be chosen.” - I guess you mean every tile is 64 pixels, each pixel is 4 bits.
- “ Whether to be hidden by the next layer in case of overlapping” - I guess this is the priority bit? Maybe “Whether to draw some or all of the tile in front of sprites”.
- You don’t mention the palette select bit for the tile map entry?
- it would be nice to pick out the correct palette for each tile in the example tileset
- “ you may notice the frame has two black vertical columns at each extreme” - this is actually an inaccuracy in Meka. Real games have an overscan “border” and the leftmost 8 pixels are set to this colour when in 248px width mode. This is not done “If H-scrolling is enabled” - scrolling is always enabled, and column blanking is optional, so games could hide it even on static screens.
- Horizontal interrupts don’t (necessarily) happen on every line, they occur every n lines where the game gets to choose what n is (and so they can be disabled). I think this is very similar to the MMC3 mapper on NES if that helps.
- I personally believe the NES put “CHR” memory on the cartridge as a cost-saving measure, not because they planned to enhance things using it - but it worked out well for them in the end, even if it did mean their games were more expensive due to the extra on-cart stuff like RAM and custom chips. (The anticompetitive contracts helped there.) Thus actually shipping 16KB VRAM in the system was not cheaper for Sega (even if the cartridge slot was also simpler).
- The sound chip is register-compatible with SN76489 but differs in a few details, which seem to have been done to improve the quality of music.
- “Periodic noise” is a terrible description from the SN76489 manual. It’s not noise at all, it’s 1/16 duty cycle square waves. However to be useable you have to sacrifice one of the regular square wave channels.
- The “imperfect” sound output is really due to output filtering, and the interaction of what is ultimately a binary signal (1 or 0) with amplifiers and mixers. You also get a lot of noise and interference on a real system :) but nobody really wants to emulate that.

...to be continued...

- The I/O chip in the SMS does more than just handle controller inputs, it also allows disabling different parts of the system. That’s how the different slots (cartridge, card, expansion and BIOS ROM) are handled, and also how a cart could disable system RAM. It’s also part of how the FM extension works (as there’s otherwise a conflict on the I/O ports)
- The expansion port was never used (apart from the never-released floppy disk unit, which may never have been real), even on the Japanese system - the FM unit was for Mark III which had a very different expansion port. Best to ignore it.
- As mentioned above, pause triggers NMI but reset is just like a controller button. This is actually a terrible idea :) and I have no idea why Sega did it this way.
- The BIOSes are not all 8KB - as it’s also where the built-in games go.
- The BIOS interacts with the I/O chip via an I/O port (out opcode), to select which “slot” to make active for ROM input. There’s three types of “I/O” here so it’s confusing...
- The header is not the first 16 bytes, it’s kind of in the middle of the ROM for some reason (usually, offset 0x7ff0).
- As the BIOS can’t be active at the same time as the other “slots”, it has to copy part of its code to RAM in order to do the checks. This, when it decides to boot the game, it has already disabled itself.
- The Japanese BIOS doesn’t “copy data”, it just looks to see if the data seems to be constant or different in the first 256 bytes. An unconnected slot will probably read as all 0xff or 0x00.
- The built in games weren’t small, many were full size games.
- The card interface can only service 32KB of address space. Sega never made a mapper for cards. It seems from early marketing that card games were presented as budget options, despite not really being cheaper to manufacture, but the 32KB limit was really unnecessary.

Well, that’s the end of the article. Much of what I’ve posted is verging on pedantry so feel free to elide unnecessary details. I think the tile priority is an important thing to cover, see my attempt at https://www.smspower.org/maxim/HowToProgram/Tilemap . At least, it could make for one of those layering things you do sometimes as now you sort of have three layers (tiles, sprites, priority tiles).

I think the ability to choose the VRAM layout (within limits) is analogous to later systems with flexible video memory usage like PS1. Maybe there’s a nice way to illustrate that? For example, Phantasy Star uses part of the tile map for extra tiles when in non-scrolling scenes, and the 64B gap in the sprite table too. Road Rash uses two name tables to separate the sky from the road with a smoothly moveable cutoff. I don’t think any game abuses multiple sprite tables though.

I’m happy to answer any questions and have another read through. I know writing this stuff is really hard :) that’s why our website is still so incomplete...

To summarise the screen resolution stuff: the first revisions effectively render 256x192 with borders. Later revisions added optional “extra height” modes with 224 or 240 vertical pixels, but these were rarely and never used respectively, not least because they would not work on the earlier consoles, and so can be mostly ignored. There’s an option to hide the leftmost 8 pixels, just like on the NES, to mask glitches when scrolling as otherwise the rightmost column would partially show at the left. At this point, only 248x192 is really being rendered. In fact, the screen is offset slightly to the left on TVs so the hidden column would often be hidden by the tube edges anyway.

Thank you all very much, really helpful info. I finished around 90% of the corrections, meanwhile I wanted to ask these questions to clarify some bits:

Maxim wrote

- The “imperfect” sound output is really due to output filtering, and the interaction of what is ultimately a binary signal (1 or 0) with amplifiers and mixers. You also get a lot of noise and interference on a real system :) but nobody really wants to emulate that.

I got the info from https://www.smspower.org/Development/SN76489?from=Development.PSG#TheImperfectSN... . So I'm guessing the decay has to do with the type of filter and quality of electronics?

Maxim wrote

- The BIOSes are not all 8KB - as it’s also where the built-in games go.

The Mark III doesn't have a BIOS ROM right? If that's the case, how does it bootstrap the game?

Maxim wrote

- “Periodic noise” is a terrible description from the SN76489 manual. It’s not noise at all, it’s 1/16 duty cycle square waves. However to be useable you have to sacrifice one of the regular square wave channels.

In the manual it said that the third pulse channel could feed the LFSR, is this why the 'periodic noise' sacrifices one pulse?

The sound path on pretty much every system will have a low pass and high pass filters applied. The note I wrote on that page about the “imperfect” result is probably a bit misleading in hindsight - it’s just normal filtering. The chips often recommend it.

I think the Mark III bootstraps directly into the game. Plugging more than one thing at once just garbles the data (technically, I think value from each slot is logically ANDed together).

Yes, to actually choose the notes for 1/16 mode (which is also 4 octaves lower pitch) you have to put it into the mode where the third tone channel is sacrificed. Example (with bad oscilloscope sync, sorry):

Or you can just keep the third channel playing in lock-step, but it’s a weird sound:

Nice, those examples are very useful.

I think I finished 99% of the corrections now, some suggestion were very interesting but I think the technical level was getting too deep for the type of article (also, I can't compete with this website :) ) so I had to draw a line somewhere. Hopefully the end result is interesting enough, and if the reader wants more... well smspower is the first on the 'sources' list!

The tile image is showing the tile map and sprite table areas as if they are tiles, cut off the bottom 32px to show just tiles.

Not much left to nitpick, there’s a few grammar errors that a read through should clear out.

Grammar is not very close friend of mine, thankfully the article can be corrected anytime even after publishing it, as opposed to a video :)

Btw Bodhi1969 I would love to include your translations, don't forget to open a pull request on my repo so we can review it.

Quote

The Z80 has a 16-bit address bus, so the CPU can find up to 64 KB worth of memory. In the memory map you’ll find 8 KB of RAM for general purpose use and up to 48 KB of game ROM, the remaining available space is left unused.

Well, no, there's no unused address space. It's 48 KB ROM + 8 KB RAM + 8 KB RAM (mirror) = 64 KB

Quote

When the PAUSE button is pressed, a non-maskable interrupt is sent to the CPU, the interrupt vector is stored in the game itself. This means that it’s up to the game to honour the press.

The button is anyway labelled as Pause though the games could use this for any action they want: for instance they can open an inventory, or totally ignore it, as the button doesn't really pause any processing at all.

Quote

By contrast and for some strange reason, the RESET button is handled like a keypress on the controller.

This button is often (always?) ignored by SMS games and it's been removed from later revisions.

flip wrote

Grammar is not very close friend of mine, thankfully the article can be corrected anytime even after publishing it, as opposed to a video :)

Btw Bodhi1969 I would love to include your translations, don't forget to open a pull request on my repo so we can review it.

Well, I somehow put it into my fork and now I can´t make a pull request.

flip wrote

The Mark III doesn't have a BIOS ROM right? If that's the case, how does it bootstrap the game?

Z80 just starts execution at 0000h and the game is already mapped in.

According to https://www.smspower.org/Development/Port3E:

Earlier systems (the Mark III and earlier) either only had one media slot, or used a hardware method to activate only one slot: the cartridge provides a bridge between VCC and a line connected to the card's OE line, thereby disabling the card if both are connected simultaneously. (This precedence was reversed in BIOS-using systems.)

sverx wrote

This button is often (always?) ignored by SMS games and it's been removed from later revisions.

Really? Are there any statistics available? Granted, I can't remember having used the RESET button all that often, but I think I would remember if it hadn't worked anyware. But maybe by pure chance I have only ever tried pressing it in games that support it?

OK let's rephrase: the RESET button is seldom used by games. It is also absent on the SMS II. (I don't remember a single game using it, but maybe it's just because I have an SMS II...)

I think reset worked in ALL the games I tried back in the day...

Seriously? :|
OK so I must have a total misconception on the RESET button, again probably because the SMS II was missing that.
What I know for sure is that the button isn't connected to any reset circuit, it's just barely a button that games can 'read', if they want to.

It's true that there's no hardware reset connected to the button, but I think most if not all games made sure that pressing that particular button would soft-reset the game.

Alrighty, I've tweaked it with the latest suggestions, I think it's ready to be published now. If new corrections arise, feel free to ping me. Thanks everyone.

Bodhi1969 wrote

Well, I somehow put it into my fork and now I can´t make a pull request.

You have to step on my repo, click on 'Pull Requests', then 'New Pull Requests', then 'compare across forks' to see your fork.

flip wrote

Alrighty, I've tweaked it with the latest suggestions, I think it's ready to be published now. If new corrections arise, feel free to ping me. Thanks everyone.

Bodhi1969 wrote

Well, I somehow put it into my fork and now I can´t make a pull request.

You have to step on my repo, click on 'Pull Requests', then 'New Pull Requests', then 'compare across forks' to see your fork.

Have a look at your repo.... ;-)

sverx wrote

Seriously? :|
OK so I must have a total misconception on the RESET button, again probably because the SMS II was missing that.
What I know for sure is that the button isn't connected to any reset circuit, it's just barely a button that games can 'read', if they want to.

I think Kagesan summarized it well

The correct term is "software polling", as in, game software polls the reset button.

I was under the impression that all games supported the Reset button.

I just tried the following games that I have inside next to my SMS1 atm and they all supported the Reset button:
Pacmania (1991)
Asterix (1991)
Gauntlet (1990)
Sonic 2 (1992)
Michael Jackson's Moonwalker (1990)

yeah correct.
I lack gamer experience here of course, and the fact that the SMS I had lacked the button totally.
Also I believe that if SEGA dropped the button entirely I guess it wasn't that important after all. They dropped cards too, and that's a bummer. :|

sverx wrote

yeah correct.
I lack gamer experience here of course, and the fact that the SMS I had lacked the button totally.
Also I believe that if SEGA dropped the button entirely I guess it wasn't that important after all. They dropped cards too, and that's a bummer. :|

As a kid who often unexpectedly heard the Sega startup tone when pausing a game, I can confirm the Reset button worked, that the positioning of the Reset & Pause buttons on the SMS I was cruel, and that its removal from the SMS II made the world a better place.

JohnnyDelirious wrote

As a kid who often unexpectedly heard the Sega startup tone when pausing a game, I can confirm the Reset button worked, that the positioning of the Reset & Pause buttons on the SMS I was cruel, and that its removal from the SMS II made the world a better place.

LOL! :D

Anyway I had a friend run tests on all the cartridges he has (far from a complete set, but several cards nonetheless) and he confirmed the reset button had effects on all of them. So it's probably something that SEGA required that was supported in order to publish a game (or allow it to be published).

It would be nice if we could find a game / games that ignores the reset button (I mean of course excluding homebrew)

I guess it’s more likely to be ignored in later games from the SMS2 era. I don’t know of any examples of games either ignoring it or using it for any other purpose.

Both Micro Machines and Cosmic Spacehead seems to ignore it.
Fantastic Dizzy seems to support it, even if it's a game that requires a new VDP (because of the extra height video mode).

(tried those quickly in emulation only)

A theory about it being a licence requirement might hold then...

Author	Message
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Write-up about the SMS architecture Posted: Sat Oct 10, 2020 4:14 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Hi guys, I wrote an article about the inner workings of the SMS. I actually got a lot of info from this site (which I'm extremely grateful and have included the proper citations) so I was wondering if anyone would like to give some feedback before I publish it. Here it is: http://copetti.org/projects/consoles/master-system/ (I can't add it as an URL). It's a 'private' draft for now. Thanks.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sat Oct 10, 2020 5:10 pm
	I fixed your URL. I’ve read your other stuff, I’ve been looking forward to this :)

Bodhi1969 Joined: 01 Oct 2020 Posts: 32 Location: Gummersbach, Germany	Posted: Sat Oct 10, 2020 5:40 pm
	Very good series. I would like to participate and prepared a german translation of _index.md. Please take a look at https://github.com/bodhi-baum/Architecture-of-consoles/blob/master/articles/_ind...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sat Oct 10, 2020 5:46 pm
	- Japanese SMS also has rapid-fire and 3D glasses support built in, but no reset button - The CPUs are a mixture of Zilog and other manufacturers like NEC but they are all official Z80s as I understand it. I don’t think there’s any particular time pattern to it. - The CPU runs at 3579545Hz (NTSC), not 4MHz - While only 8KB of system RAM is present, the memory map doesn’t expose 56KB of cartridge ROM, it just wastes 8KB of address space. - It seems worth mentioning that there’s 16KB of video memory in the Memory section. - IN/OUT don’t send interrupts to the attached devices, they just signal on a CPU pin that this is an IO bus read/write rather than memory bus. The devices themselves are responsible for checking the (low 8 bits of the) address and this bus pin. If they need time to respond they can halt the CPU - but this doesn’t happen on the SMS. - The VDP can render up to 256x240 but 256x192 (with the left 8px hidden when scrolling horizontally so effectively 248x192) is by far the most common mode More later!

flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Posted: Sat Oct 10, 2020 6:36 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Bodhi1969 wrote Very good series. I would like to participate and prepared a german translation of _index.md. Please take a look at That would be a great addition! you can open a pull request so we can review it and merge it. Maxim wrote More later! Thanks, I'm making the corrections just now.

Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Posted: Sat Oct 10, 2020 6:48 pm
Charles MacDonald Joined: 28 Sep 1999 Posts: 1197	Some comments: - "D4168" isn't a CPU. The "uPD4168" is a type of pseudo static RAM (NEC calls it XRAM, most manufactures call it PSRAM). Did you mean the NEC uPD780 which is a Z80? - I think it's better to refer to the CPU name (Z80) then the specific part number (Z0840004PSC) because the Z80 had many second sources (Sharp, Rohm, NEC, Mostek, etc.) most of which were also used in the SMS. They're all Z80s, but Sega didn't prefer or target a specific manufacturer when they designed it. They used whatever was available and affordable.

flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Posted: Sat Oct 10, 2020 6:56 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Maxim wrote - While only 8KB of system RAM is present, the memory map doesn’t expose 56KB of cartridge ROM, it just wastes 8KB of address space. I'm not sure I understand this. So the memory map has the 8 KB of RAM and just 8 KB of cartridge ROM? Maxim wrote - The VDP can render up to 256x240 but 256x192 (with the left 8px hidden when scrolling horizontally so effectively 248x192) is by far the most common mode I see, so the effective resolution is 248x192 or 248x240 ? I've attached a sonic screenshot that I use as reference. result.png (2.67 KB) Sonic screenshot

flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Posted: Sat Oct 10, 2020 7:09 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Charles MacDonald wrote I think it's better to refer to the CPU name (Z80) then the specific part number (Z0840004PSC) because the Z80 had many second sources (Sharp, Rohm, NEC, Mostek, etc.) most of which were also used in the SMS. I agree, I thought it would make it more complete, but it eventually gets confusing.

Kagesan Joined: 01 Feb 2014 Posts: 876	Posted: Sat Oct 10, 2020 7:52 pm
Kagesan Joined: 01 Feb 2014 Posts: 876	flip wrote I see, so the effective resolution is 248x192 or 248x240 ? I've attached a sonic screenshot that I use as reference. Only if you want a game to scroll horizontally. Games with static screens or only vertical scrolling usually have an effective resolution of 256x192. Also, when scrolling horizontally, the leftmost column of tiles is blanked, not the extremes on both sides of the screen. Some emulators center the image, so it looks like the latter. However, that's not how the hardware works. Some other things I've noticed on the first read-through: - The YM2413 can have one custom instrument, not one custom channel. You can use the custom instrument on all nine channels at the same time if you like. It's also worth mentioning that the chip has two modes of operation: nine channels or six channels plus percussion. As far as I know, no commercially released Master System game ever actually used nine-channel-mode. - Of the two buttons present on the console itself, only the pause button triggers an NMI. The reset button is simply a button like those on the control pads and is read from the same ports.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sat Oct 10, 2020 8:03 pm
	The standard memory map is 48KB for ROM, 8KB system RAM and then another 8KB mirror of system RAM with some of the upper bytes also shadowed by some memory-mapped things (paging registers on the cart, 3D glasses). However technically cartridges can map anything they like to the address space (for both memory and IO) - but practically all they do is add some on-cart RAM sometimes.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sat Oct 10, 2020 8:44 pm
	- The space used for tile maps, tiles and sprite tables is flexible - most games use the standard layout but some effects come from sacrificing some parts in favour of others, eg putting tiles in unused space and using multiple tile maps. This no area of VRAM is “reserved”. - Colour RAM is really 6-bit. The data is written as bytes but the upper bits are never saved (probably - certainly they have no effect). - “ There are 16 pixels defined on every tile, the VDP rules that pixel must weight 4 bytes, that means that up to 16 colours can be chosen.” - I guess you mean every tile is 64 pixels, each pixel is 4 bits. - “ Whether to be hidden by the next layer in case of overlapping” - I guess this is the priority bit? Maybe “Whether to draw some or all of the tile in front of sprites”. - You don’t mention the palette select bit for the tile map entry? - it would be nice to pick out the correct palette for each tile in the example tileset - “ you may notice the frame has two black vertical columns at each extreme” - this is actually an inaccuracy in Meka. Real games have an overscan “border” and the leftmost 8 pixels are set to this colour when in 248px width mode. This is not done “If H-scrolling is enabled” - scrolling is always enabled, and column blanking is optional, so games could hide it even on static screens. - Horizontal interrupts don’t (necessarily) happen on every line, they occur every n lines where the game gets to choose what n is (and so they can be disabled). I think this is very similar to the MMC3 mapper on NES if that helps. - I personally believe the NES put “CHR” memory on the cartridge as a cost-saving measure, not because they planned to enhance things using it - but it worked out well for them in the end, even if it did mean their games were more expensive due to the extra on-cart stuff like RAM and custom chips. (The anticompetitive contracts helped there.) Thus actually shipping 16KB VRAM in the system was not cheaper for Sega (even if the cartridge slot was also simpler). - The sound chip is register-compatible with SN76489 but differs in a few details, which seem to have been done to improve the quality of music. - “Periodic noise” is a terrible description from the SN76489 manual. It’s not noise at all, it’s 1/16 duty cycle square waves. However to be useable you have to sacrifice one of the regular square wave channels. - The “imperfect” sound output is really due to output filtering, and the interaction of what is ultimately a binary signal (1 or 0) with amplifiers and mixers. You also get a lot of noise and interference on a real system :) but nobody really wants to emulate that. ...to be continued...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sat Oct 10, 2020 11:03 pm
	- The I/O chip in the SMS does more than just handle controller inputs, it also allows disabling different parts of the system. That’s how the different slots (cartridge, card, expansion and BIOS ROM) are handled, and also how a cart could disable system RAM. It’s also part of how the FM extension works (as there’s otherwise a conflict on the I/O ports) - The expansion port was never used (apart from the never-released floppy disk unit, which may never have been real), even on the Japanese system - the FM unit was for Mark III which had a very different expansion port. Best to ignore it. - As mentioned above, pause triggers NMI but reset is just like a controller button. This is actually a terrible idea :) and I have no idea why Sega did it this way. - The BIOSes are not all 8KB - as it’s also where the built-in games go. - The BIOS interacts with the I/O chip via an I/O port (out opcode), to select which “slot” to make active for ROM input. There’s three types of “I/O” here so it’s confusing... - The header is not the first 16 bytes, it’s kind of in the middle of the ROM for some reason (usually, offset 0x7ff0). - As the BIOS can’t be active at the same time as the other “slots”, it has to copy part of its code to RAM in order to do the checks. This, when it decides to boot the game, it has already disabled itself. - The Japanese BIOS doesn’t “copy data”, it just looks to see if the data seems to be constant or different in the first 256 bytes. An unconnected slot will probably read as all 0xff or 0x00. - The built in games weren’t small, many were full size games. - The card interface can only service 32KB of address space. Sega never made a mapper for cards. It seems from early marketing that card games were presented as budget options, despite not really being cheaper to manufacture, but the 32KB limit was really unnecessary. Well, that’s the end of the article. Much of what I’ve posted is verging on pedantry so feel free to elide unnecessary details. I think the tile priority is an important thing to cover, see my attempt at https://www.smspower.org/maxim/HowToProgram/Tilemap . At least, it could make for one of those layering things you do sometimes as now you sort of have three layers (tiles, sprites, priority tiles). I think the ability to choose the VRAM layout (within limits) is analogous to later systems with flexible video memory usage like PS1. Maybe there’s a nice way to illustrate that? For example, Phantasy Star uses part of the tile map for extra tiles when in non-scrolling scenes, and the 64B gap in the sprite table too. Road Rash uses two name tables to separate the sky from the road with a smoothly moveable cutoff. I don’t think any game abuses multiple sprite tables though. I’m happy to answer any questions and have another read through. I know writing this stuff is really hard :) that’s why our website is still so incomplete...

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sat Oct 10, 2020 11:20 pm
	To summarise the screen resolution stuff: the first revisions effectively render 256x192 with borders. Later revisions added optional “extra height” modes with 224 or 240 vertical pixels, but these were rarely and never used respectively, not least because they would not work on the earlier consoles, and so can be mostly ignored. There’s an option to hide the leftmost 8 pixels, just like on the NES, to mask glitches when scrolling as otherwise the rightmost column would partially show at the left. At this point, only 248x192 is really being rendered. In fact, the screen is offset slightly to the left on TVs so the hidden column would often be hidden by the tube edges anyway.

flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Posted: Sun Oct 11, 2020 4:16 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Thank you all very much, really helpful info. I finished around 90% of the corrections, meanwhile I wanted to ask these questions to clarify some bits: Maxim wrote - The “imperfect” sound output is really due to output filtering, and the interaction of what is ultimately a binary signal (1 or 0) with amplifiers and mixers. You also get a lot of noise and interference on a real system :) but nobody really wants to emulate that. I got the info from https://www.smspower.org/Development/SN76489?from=Development.PSG#TheImperfectSN... . So I'm guessing the decay has to do with the type of filter and quality of electronics? Maxim wrote - The BIOSes are not all 8KB - as it’s also where the built-in games go. The Mark III doesn't have a BIOS ROM right? If that's the case, how does it bootstrap the game? Maxim wrote - “Periodic noise” is a terrible description from the SN76489 manual. It’s not noise at all, it’s 1/16 duty cycle square waves. However to be useable you have to sacrifice one of the regular square wave channels. In the manual it said that the third pulse channel could feed the LFSR, is this why the 'periodic noise' sacrifices one pulse?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sun Oct 11, 2020 5:33 pm
	The sound path on pretty much every system will have a low pass and high pass filters applied. The note I wrote on that page about the “imperfect” result is probably a bit misleading in hindsight - it’s just normal filtering. The chips often recommend it. I think the Mark III bootstraps directly into the game. Plugging more than one thing at once just garbles the data (technically, I think value from each slot is logically ANDed together). Yes, to actually choose the notes for 1/16 mode (which is also 4 octaves lower pitch) you have to put it into the mode where the third tone channel is sacrificed. Example (with bad oscilloscope sync, sorry): Or you can just keep the third channel playing in lock-step, but it’s a weird sound:

flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Posted: Sun Oct 11, 2020 6:27 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Nice, those examples are very useful. I think I finished 99% of the corrections now, some suggestion were very interesting but I think the technical level was getting too deep for the type of article (also, I can't compete with this website :) ) so I had to draw a line somewhere. Hopefully the end result is interesting enough, and if the reader wants more... well smspower is the first on the 'sources' list!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Sun Oct 11, 2020 7:19 pm
	The tile image is showing the tile map and sprite table areas as if they are tiles, cut off the bottom 32px to show just tiles. Not much left to nitpick, there’s a few grammar errors that a read through should clear out.

flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Posted: Sun Oct 11, 2020 9:22 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Grammar is not very close friend of mine, thankfully the article can be corrected anytime even after publishing it, as opposed to a video :) Btw Bodhi1969 I would love to include your translations, don't forget to open a pull request on my repo so we can review it.

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Mon Oct 12, 2020 9:49 am
	Quote The Z80 has a 16-bit address bus, so the CPU can find up to 64 KB worth of memory. In the memory map you’ll find 8 KB of RAM for general purpose use and up to 48 KB of game ROM, the remaining available space is left unused. Well, no, there's no unused address space. It's 48 KB ROM + 8 KB RAM + 8 KB RAM (mirror) = 64 KB Quote When the PAUSE button is pressed, a non-maskable interrupt is sent to the CPU, the interrupt vector is stored in the game itself. This means that it’s up to the game to honour the press. The button is anyway labelled as Pause though the games could use this for any action they want: for instance they can open an inventory, or totally ignore it, as the button doesn't really pause any processing at all. Quote By contrast and for some strange reason, the RESET button is handled like a keypress on the controller. This button is often (always?) ignored by SMS games and it's been removed from later revisions.

Bodhi1969 Joined: 01 Oct 2020 Posts: 32 Location: Gummersbach, Germany	Posted: Mon Oct 12, 2020 11:36 am
	flip wrote Grammar is not very close friend of mine, thankfully the article can be corrected anytime even after publishing it, as opposed to a video :) Btw Bodhi1969 I would love to include your translations, don't forget to open a pull request on my repo so we can review it. Well, I somehow put it into my fork and now I can´t make a pull request.

Bock Site Admin Joined: 08 Jul 2001 Posts: 8648 Location: Paris, France	Posted: Mon Oct 12, 2020 12:45 pm
	flip wrote The Mark III doesn't have a BIOS ROM right? If that's the case, how does it bootstrap the game? Z80 just starts execution at 0000h and the game is already mapped in. According to https://www.smspower.org/Development/Port3E: Earlier systems (the Mark III and earlier) either only had one media slot, or used a hardware method to activate only one slot: the cartridge provides a bridge between VCC and a line connected to the card's OE line, thereby disabling the card if both are connected simultaneously. (This precedence was reversed in BIOS-using systems.)

Kagesan Joined: 01 Feb 2014 Posts: 876	Posted: Mon Oct 12, 2020 1:52 pm
Kagesan Joined: 01 Feb 2014 Posts: 876	sverx wrote This button is often (always?) ignored by SMS games and it's been removed from later revisions. Really? Are there any statistics available? Granted, I can't remember having used the RESET button all that often, but I think I would remember if it hadn't worked anyware. But maybe by pure chance I have only ever tried pressing it in games that support it?

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Mon Oct 12, 2020 2:07 pm
	OK let's rephrase: the RESET button is seldom used by games. It is also absent on the SMS II. (I don't remember a single game using it, but maybe it's just because I have an SMS II...)

kusfo Joined: 29 Mar 2012 Posts: 882 Location: Spain	Posted: Mon Oct 12, 2020 2:10 pm
kusfo Joined: 29 Mar 2012 Posts: 882 Location: Spain	I think reset worked in ALL the games I tried back in the day...

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Mon Oct 12, 2020 2:42 pm
	Seriously? :\| OK so I must have a total misconception on the RESET button, again probably because the SMS II was missing that. What I know for sure is that the button isn't connected to any reset circuit, it's just barely a button that games can 'read', if they want to.

Kagesan Joined: 01 Feb 2014 Posts: 876	Posted: Mon Oct 12, 2020 4:29 pm
Kagesan Joined: 01 Feb 2014 Posts: 876	It's true that there's no hardware reset connected to the button, but I think most if not all games made sure that pressing that particular button would soft-reset the game.

flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Posted: Mon Oct 12, 2020 4:59 pm
flip Joined: 10 Oct 2020 Posts: 8 Location: Scotland	Alrighty, I've tweaked it with the latest suggestions, I think it's ready to be published now. If new corrections arise, feel free to ping me. Thanks everyone. Bodhi1969 wrote Well, I somehow put it into my fork and now I can´t make a pull request. You have to step on my repo, click on 'Pull Requests', then 'New Pull Requests', then 'compare across forks' to see your fork.

Bodhi1969 Joined: 01 Oct 2020 Posts: 32 Location: Gummersbach, Germany	Posted: Mon Oct 12, 2020 6:11 pm
	flip wrote Alrighty, I've tweaked it with the latest suggestions, I think it's ready to be published now. If new corrections arise, feel free to ping me. Thanks everyone. Bodhi1969 wrote Well, I somehow put it into my fork and now I can´t make a pull request. You have to step on my repo, click on 'Pull Requests', then 'New Pull Requests', then 'compare across forks' to see your fork. Have a look at your repo.... ;-)

kusfo Joined: 29 Mar 2012 Posts: 882 Location: Spain	Posted: Tue Oct 13, 2020 9:04 am
kusfo Joined: 29 Mar 2012 Posts: 882 Location: Spain	sverx wrote Seriously? :\| OK so I must have a total misconception on the RESET button, again probably because the SMS II was missing that. What I know for sure is that the button isn't connected to any reset circuit, it's just barely a button that games can 'read', if they want to. I think Kagesan summarized it well

asynchronous Joined: 14 Aug 2000 Posts: 741 Location: Adelaide, Australia	Write-up about the SMS architecture Posted: Tue Oct 13, 2020 9:46 am
	The correct term is "software polling", as in, game software polls the reset button. I was under the impression that all games supported the Reset button. I just tried the following games that I have inside next to my SMS1 atm and they all supported the Reset button: Pacmania (1991) Asterix (1991) Gauntlet (1990) Sonic 2 (1992) Michael Jackson's Moonwalker (1990)

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Tue Oct 13, 2020 10:22 am
	yeah correct. I lack gamer experience here of course, and the fact that the SMS I had lacked the button totally. Also I believe that if SEGA dropped the button entirely I guess it wasn't that important after all. They dropped cards too, and that's a bummer. :\|

JohnnyDelirious Joined: 02 Jul 2018 Posts: 2 Location: Toronto, Canada	Posted: Mon Oct 26, 2020 3:19 am
	sverx wrote yeah correct. I lack gamer experience here of course, and the fact that the SMS I had lacked the button totally. Also I believe that if SEGA dropped the button entirely I guess it wasn't that important after all. They dropped cards too, and that's a bummer. :\| As a kid who often unexpectedly heard the Sega startup tone when pausing a game, I can confirm the Reset button worked, that the positioning of the Reset & Pause buttons on the SMS I was cruel, and that its removal from the SMS II made the world a better place.

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Mon Oct 26, 2020 9:19 am
	JohnnyDelirious wrote As a kid who often unexpectedly heard the Sega startup tone when pausing a game, I can confirm the Reset button worked, that the positioning of the Reset & Pause buttons on the SMS I was cruel, and that its removal from the SMS II made the world a better place. LOL! :D Anyway I had a friend run tests on all the cartridges he has (far from a complete set, but several cards nonetheless) and he confirmed the reset button had effects on all of them. So it's probably something that SEGA required that was supported in order to publish a game (or allow it to be published). It would be nice if we could find a game / games that ignores the reset button (I mean of course excluding homebrew)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Mon Oct 26, 2020 12:17 pm
	I guess it’s more likely to be ignored in later games from the SMS2 era. I don’t know of any examples of games either ignoring it or using it for any other purpose.

sverx Joined: 05 Sep 2013 Posts: 3805 Location: Stockholm, Sweden	Posted: Mon Oct 26, 2020 3:11 pm
	Both Micro Machines and Cosmic Spacehead seems to ignore it. Fantastic Dizzy seems to support it, even if it's a game that requires a new VDP (because of the extra height video mode). (tried those quickly in emulation only)

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14728 Location: London	Posted: Mon Oct 26, 2020 3:39 pm
	A theory about it being a licence requirement might hold then...

Forums

View topic - Write-up about the SMS architecture