Forums

TL;DR: Speedrunner looking for potential techniques

(Also note: not allowed to post links because I'm only recent member)

Hi all,
I'm currently maintaining two projects (in a different community) about potential techniques on different platforms that could be considered for speedrunning purposes.

I'm looking for two primary things regarding SMS:
- answers to my 4 technical questions,
- any experiences of oddities on a real hardware.

1 - Sub frames input
- Is it possible for a game to poll the controller multiple time within a single frame (the I/O ports $DC and $DD)?
- Is it possible to press the reset and pause buttons on a CPU cycle level?

2 - Cart swapping
- Does it have a "cart lock", a plastic piece preventing cart swapping while the console is powered on?

3 - SMS Aladdin Pal-B
- Using NTSC region (for 60 fps) for Aladdin, many frames' input denied but pause (something like 30% randomly)

- Input works correctly until starting the game. The 1st cutscene already has the input issue.
- Input works correctly in the test mode (Press Up, Right, Down, Left, Up, Right, Down, Left at the title screen to acces a test menu which contains several options, including a level select and music test.)
- The input denied frames doesn't seem to have a pattern.

Example video:
watch?v=rJ2KaRuIm_4

4 - Pause button spam glitch
- In Batman Returns you can spam pause after the 59th frame to effectively reduce the waiting time 1 frame per 2 frames of pause.

While Alyosha (developer of the core) found some evidences, we still not sure why this is not present in other emulators AND is it really possible on a real hardware.

His notes:
"To understand what's happening here, you first have to realize that the 'pause' button on SMS is actually tied to a non-maskable interrupt. The routine the game is doing is decrementing a counter at $DFE7. The problem is that the decrement happens once per interrupt. So when you press pause every other frame, you get 2 decrements on frames with the pause (1 for NMI and one for VBlank.)

The obvious question is then why doesn't TwoMbit have this effect? Well I'm not 100% sure but if they happened to poll input at vblank, what would happen is that the NMI would happen first and then immediately the Vblank IRQ would happen before the decrement could take place."

If you are interested in my current state of my projects, PM me for the links.

Thanks in advance :)

Hello and welcome!

Quote

1 - Sub frames input
- Is it possible for a game to poll the controller multiple time within a single frame (the I/O ports $DC and $DD)?
- Is it possible to press the reset and pause buttons on a CPU cycle level?

Yes the controller can be polled at any time. I suspect that the vast majority of games only poll them only once a frame. Using a debugger you can confirm that for a given game.

Pause button is triggering a Z80 non-maskable interrupt so that can happen anytime. In reality, the vast majority of NMI handler will alter some flag that will then be polled by the main loop.

Quote

2 - Cart swapping
- Does it have a "cart lock", a plastic piece preventing cart swapping while the console is powered on?

No. However the way the bus are connected makes hot unplugging/plugging cartridges highly unreliable (it is often going to create interference of some sort and crash the system).

Quote

3 - SMS Aladdin Pal-B

Quote

4 - Pause button spam glitch

I don't see any questions in there. The best way to get any answer that specific is to use a debugger and study the game code.

Pause button spam means invoking the pause routine twice if the time taken ends up shorter than waiting for a halt opcode to complete. Game loops assuming halt = wait for next frame can be tricked into running more rapidly.

I suspect Aladdin is just laggy, so it polls inputs less frequently depending on the time it takes to run the main loop. Pause always gets serviced because it triggers an interrupt, although as Bock said many games just set a flag for the (laggy) main loop to poll.

1 & 2: Thanks for the answer Bock!

3 & 4: These two are the currently known facts after trying to debug and test it. The question would be for these two is:
- Did we figured out correctly and does this really works in real life?

Regarding 3 - Pal-B:
- It looks clear to me that there is something wrong with this. The game has nearly no lag frames but if you watch the video (posted the end of the youtube url in OP), you can see how different is the polling rate.

Example of denied input (you can press anything (but pause) and nothing will happen):
1330, 1334, 1336, 1340, 1346, 1348, 1352 (difference between numbers: 0, 4, 2, 4, 6, 2, 4)

I also have a very lengthy detailed tests about this. I put it in code to don't bloat the page.

ONLY PAL! (5 polls (instead of 1-3) or 3 polls (instead of 1-2) when used in NTSC)
Aladdin, Alien 3, Air Rescue

CAN BE NTSC (1st level gameplay has same polling rate albeit being Europe)
Alien Storm, Tom and Jerry

edit: Some new informations:
- There are SMS games with only PAL while GG with NTSC, example: Ariel, Asterix and the Great Mision
- There are GG games with only PAL (but there is no display type change for GG so it's 60fps), example: Asterix and the Secret Mission
- Bram Stroker's Dracula SMS E (PAL) but GG has both regions
- I couldn't find anywhere about Game Gear being region dependent, yet I found many different regions for most of the Game Gear games

edit3: TASes published using the erroneous setting (NTSC for a Europe ROM resulting in fluctuating input poll which makes input denied):
[2920] SMS Danan: The Jungle Fighter (USA/Europe) in 7:18.14 by Aqfaq - SMS Export, only European (with Brazil) ROM found, has input denied issue when using NTSC

edit4: So it seems that if a game has a constant half rate gameplay, there won't be input denied issue. Some movies that uses European ROM but plays on 60hz listed below

[2271] SMS Astérix (USA/Europe) in 26:20.56 by Johnnypoiro - SMS Export, only European (with Brazil) ROM found, 1.0, however there is no input deny in 1st level because every even frame is lag frame
[2834] SMS Batman Returns (Europe) in 1:38.24 by mamuuuut - SMS Export, only European (with Brazil) ROM found, however there is no input deny in 1st level because every even frame is lag frame
[2985] SMS Cheese Cat-Astrophe Starring Speedy Gonzales (Europe) in 13:07.26 by Mephistus & Really_Tall - SMS Export, only European (with Brazil) ROM found, however there is no input deny in 1st level because every even frame is lag frame

edit5: TwoMbit tests:
- from readme: "- there are a few pal games which have glitches playing with us/jp region selected. These are no emulation bugs. It behaves the same at a real system."
- also note TwoMbit has option to select between SMS1 and SMS2 unit
- there's 3 region settings: Japan, Europe, USA (and Auto)
- since there's no frame stepping, I couldn't test the input denied issue
- Game Gear games seems to be always 60hz

final edit:
According to many sites of sega gamers, these are my conclusions:
- GG is always 60hz
- SMS1 and SMS2 only differs from the VDP and one minimal change
- Brazilian SMS is supposed to be PAL-M, 60hz, however some people commented on having 50hz... This will be a task for someone to track down. This might be an inaccurate fact!
- There are carts that don't fit into other region's unit

Regarding 4 - Pause glitch:
- SG-1000 Bank Panic has a very similar pause glitch as SMS Batman Returns (this time it's more of 1 frame reduce per 3 frames with P, emtpy, P)
- I'm a bit pessimist on how reliable would be this on a real console, so I'm mainly looking for someone to test it.

Re: the pause button:

Yes, it generates an NMI.

No, it doesn't do so at any time. It's routed through the VDP, and will only ever occur exactly one line before the start of new pixels per this thread.

So any emulator that signals an NMI at any other time is incorrectly implemented.

EDIT: based on a quick peek inside the TwoMBit code, it most definitely isn't what it claims to be: "cycle/bus accurate". E.g. check out vdp.cpp, line 150, where:

(1) scroll position is cached, the v counter is incremented, etc, regardless of the device being emulated. This timing differs between the SMS and the GG; and
(2) sprite overflow is calculated post hoc. In reality it is set as the raster runs.

Also see the whole triage of initDelay() and updateDelay() that is triggered by write_port_BE. On a real machine, the amount of time a write takes to reach VRAM is a fixed amount plus a function of the current raster position. This emulator just uses a larger fixed amount.

So, honestly, if I were you I wouldn't trouble myself too much with things that appear to work one way on hardware but aren't reproduced in that emulator.

TomHarte:
- Reset/pause: Thanks, I suppose this is entirely depends on the programmer of the games then?

- Do you know any better emulator for SMS than TwoMbit (and BizHawk since that's the emulator which I will use and write to feature request for the devs)?

Quote

So, honestly, if I were you I wouldn't trouble myself too much with things that appear to work one way on hardware but aren't reproduced in that emulator.

This is what I exactly want as the goal of my projects is the ability to reproduce speedruns done on real console in the BizHawk emulator. We know that open bus and many physical phenomena won't be possible to implement as a 100% matching feature, but I'm optimist and try to do whatever I can in order to let this happen.

I'll have to let somebody else answer on suitable emulators, alas; I've no idea what BizHawk currently uses for its Master System, or whatever other accurate options would either lend themselves to being embedded within BizHawk or else already provide good speed-running functionality.

On reset/pause: yes, it should entirely depend on the game title. But the fastest you should be able to press the pause button is once per frame, communicated to the software one line before pixels begin. So one extra interrupt per frame. An NMI rather than an IRQ, but obviously a particular title may unify its treatment of those.

MESHUGGAH wrote

Do you know any better emulator for SMS than TwoMbit (and BizHawk since that's the emulator which I will use and write to feature request for the devs)?

I don‘t know about the specific needs for speedrunning, but from a developer’s point of view, Emulicious is by far the most accurate enulator I know. If something works in Emulicious, it works exactly the same on real hardware.

Kagesan wrote

MESHUGGAH wrote

Do you know any better emulator for SMS than TwoMbit (and BizHawk since that's the emulator which I will use and write to feature request for the devs)?

I don‘t know about the specific needs for speedrunning, but from a developer’s point of view, Emulicious is by far the most accurate enulator I know. If something works in Emulicious, it works exactly the same on real hardware.

To be explicit, I didn't consider that because it appears to be Java based, and it's not clear to me that it's open source. So it'd be problematic for BizHawk integration on at least two fronts. I don't mean to state any opinion about its other qualities.

For the record, my negligible understanding of the specific unusual requirements of tool-assisted speedrunners are great support for input capture and replay, and especially manipulation of that implied timeline — being able to rewind at will, an arbitrary amount of time, and attempt further play from more or less any previous instant. That's the 'tool-assisted' part, the fun being to construct the minimal time that a title could be completed in by any means, which usually involves a fair amount of ingenuity and lateral thinking. And then I keep falling back on BizHawk integration because I believe it handles all the good stuff of tooling, just needing cores it can implement from which it can capture complete state periodically and feed input with precise timing.

All that plus the more normative requirements of being as cycle accurate as possible, of course. You're not looking to exploit somebody's haphazard emulation of a game.

So, even though you'll hear me boast elsewhere about my emulator, and its steps towards lots of good accuracy stuff (real VDP timing, chroma dots, genuine composite video**, low-latency everything, etc, etc) I'd propose that it's unsuitable for this purpose because it lacks state captures and because the aggressive code sharing between things it emulates means that it sprawls a little too much to be "a core" in emulator collection terms. Well, that plus the entirely different approaches to managing latency that such frameworks tend to impose*. Though that's with no specific knowledge of BizHawk internals. Just a pessimism born of things like RetroArch.

* audio usually being an obvious one. Quite a lot of these throw-everything-together frameworks don't give you any better scheduling precision than one execution per frame. So the only workable audio strategy if adapting code to work within one of those is just to queue up quite a lot of it. So extra audio latency. And I can think of various non-audio complaints, but we might be straying into chip-on-shoulder territory here.

** not a hacky post-hoc filter on an otherwise perfect framebuffer, in which someone asserts that, you know, composite video is blurry, right?, but rather computing the actual 1d composite signal, communicating only that outwards, and having the screen output be a decoding of that. The usual gutter-level emulation "NTSC[/composite] filter" is as much about emulating NTSC as would be taking an existing game, displaying it in only 8 colours, and saying you've written a BBC Micro emulator.

Chips on shoulders abound!

I think we can have the best of both worlds. I like "perfect" emulation - sharp pixels and unfiltered audio, often with the sprite limit removed and no CRAM write dots - but at the same time I'm happy to have cycle accurate emulation underneath it and low latency. After that I like to have nice debugger tools, and source I can hack on and submit pull requests for. Some people want blurry squashed video and muffled audio, and it's great to offer that too. I think the model for an emulator "core" has changed over the years and one size definitely does not fit all.

Coming back to the Master System and TASing, speedrunning and TASbot, I think it's a tricky problem. Emulators probably don't have enough accuracy on some timing aspects to mess with such things as microsecond scale input handling, and reproducing anything more than frame accurate timing on real hardware is going to be tough because we just don't have that read strobe used for TASbot on Ni****do consoles.

As for Aladdin and its dodgy controls, that's really just software. It may have its timing thrown off on NTSC hardware as there are fewer cycles per frame, but I doubt it as it's a Japanese developed game with a very similar Game Gear version. It may just be crappy code.

Dealing with it shortly: sharp pixels should be offered by an accurate emulator, as the real machine has RGB output that produces sharp pixels. My test for a good emulator is directly from first principles: how well does it imitate the real thing? Also, at least my emulator models input as arbitrarily placed within frame. There's no way I'm alone in that.

(EDIT: gluing it on here in retrospect rather than further lengthening the off-topic part of the discussion, my philosophy is a little more like: an emulator should first do exactly what the real hardware does. Then it can do more. The only thing that I would consider as making an emulator worse rather than better is offering only something inaccurate. Like compelling the user into square, perfect pixels, so that you've no option but to play at an aspect ratio the assets weren't designed for.)

Digressions aside, I notice that the CLK and IOREQ signals are present on the cartridge slot, so could a putative TASBot not provide a plug-through for that? Or is there some sort of prohibition on using anything beyond the ordinary user-facing input and output ports for information? And/or would the optics be problematic, in that you'd end up spending 80% of your time explaining to the latest set of people who saw a video but didn't read anything that, no, you're not modifying the cartridge. Just catching a couple of timing signals.

I had a look at Aladdin and it is a bit weird. It reads the controls outside the VBlank interrupt, and it seems to do so at an inconsistent rate, so it ends up doing it on a different line every time - sometimes near the end of the frame, sometimes near the start. I suspect it is running its main loop at an unstable rate and will sometimes skip frames. Here's some Meka debugging:

# w r io dc
Watchpoint [0] added.
[0] Watch IO R. DC
# w line #0
Watchpoint [1] added.
[1] Watch LINE E 0000
# c
09CA: [0] watch IO read from DC, read value=ff
0A04: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
05B6: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
109F: [1] watch LINE 0 event
8470: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
8472: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
09CA: [0] watch IO read from DC, read value=ff
3C4A: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
17A1: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
05B9: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
09EE: [1] watch LINE 0 event
846F: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
09CA: [0] watch IO read from DC, read value=ff
3B75: [1] watch LINE 0 event
859C: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff
8472: [1] watch LINE 0 event
09CA: [0] watch IO read from DC, read value=ff

What this is doing is logging each time it reads the controller ("IO read from DC") and each time it starts a new frame ("LINE 0 event"). You can see some frames it reads the controller twice, some not at all. Compare to a "normal" game like Alex Kidd in Miracle World:

26A7: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
26A2: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
26A7: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
26A2: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
26C0: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
26A2: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
9C60: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
4124: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff
2B0A: [1] watch LINE 0 event
036F: [0] watch IO read from DC, read value=ff

I'd just wire TASbot up internally :)

Actually, I guess we're being foolish. If you're additionally watching the bus by any means, you can just replay controller inputs as and when the game reads them.

That's other than pause and reset, but given that a game isn't required to use interrupts at all, and if it does it may receive as many as one per pixel line, I don't see a good option for those other than hooking into the VDP sync signals?

Thanks guys!

TomHarte: Will try Emulicious and test what I can.

Maxim: Regarding SMS Aladdin, I assume you used NTSC region settings since that's have the weird polling issue. I think it will poll consistently in PAL region settings. Then again, where it goes wrong? It doesn't accounts the region difference?

The general pattern for SMS games is to split work between the VBlank - which will run every frame, provided you don't make it take longer than a frame to run of course - and a main loop. The VBlank is special time because you can do your video updates in there, but games generally also update sound (because lagging sound could be noticeable) and read the inputs in there too.

The main loop can then be running game logic which doesn't have such timing dependency. In general though, you need to have a target frame rate (60, 30, or less) and aim to always do one frame of work in less than the time a frame takes. Going past that generally leads to slowdown.

Aladdin seems to work fine in PAL/50 mode, and nobody cared that it was a bit unresponsive in 60Hz regions (Brazil, South Korea). The Game Gear version works correctly at 60Hz.

Thanks Maxim, really great to hear this (problem seems to be correctly emulated)! I assume if I type the same as you inside Meka (edit: the lines with a # prefix), I get the same log text so I can test the other games with this input polling problem? (0] watch IO read from DC, read value=ff )

This confirms that the game reads from the controllers once per frame. It doesn't confirm the game code correctly reacts to it. Also, Meka is a 90s era emulator at heart and while it has good compatibility, its accuracy regarding certain edge behaviour is not great.

Author	Message
MESHUGGAH Joined: 11 Feb 2019 Posts: 5	SMS Technical questions and looking for oddities Posted: Mon Feb 11, 2019 12:51 pm
MESHUGGAH Joined: 11 Feb 2019 Posts: 5	TL;DR: Speedrunner looking for potential techniques (Also note: not allowed to post links because I'm only recent member) Hi all, I'm currently maintaining two projects (in a different community) about potential techniques on different platforms that could be considered for speedrunning purposes. I'm looking for two primary things regarding SMS: - answers to my 4 technical questions, - any experiences of oddities on a real hardware. 1 - Sub frames input - Is it possible for a game to poll the controller multiple time within a single frame (the I/O ports $DC and $DD)? - Is it possible to press the reset and pause buttons on a CPU cycle level? 2 - Cart swapping - Does it have a "cart lock", a plastic piece preventing cart swapping while the console is powered on? 3 - SMS Aladdin Pal-B - Using NTSC region (for 60 fps) for Aladdin, many frames' input denied but pause (something like 30% randomly) - Input works correctly until starting the game. The 1st cutscene already has the input issue. - Input works correctly in the test mode (Press Up, Right, Down, Left, Up, Right, Down, Left at the title screen to acces a test menu which contains several options, including a level select and music test.) - The input denied frames doesn't seem to have a pattern. Example video: watch?v=rJ2KaRuIm_4 4 - Pause button spam glitch - In Batman Returns you can spam pause after the 59th frame to effectively reduce the waiting time 1 frame per 2 frames of pause. While Alyosha (developer of the core) found some evidences, we still not sure why this is not present in other emulators AND is it really possible on a real hardware. His notes: "To understand what's happening here, you first have to realize that the 'pause' button on SMS is actually tied to a non-maskable interrupt. The routine the game is doing is decrementing a counter at $DFE7. The problem is that the decrement happens once per interrupt. So when you press pause every other frame, you get 2 decrements on frames with the pause (1 for NMI and one for VBlank.) The obvious question is then why doesn't TwoMbit have this effect? Well I'm not 100% sure but if they happened to poll input at vblank, what would happen is that the NMI would happen first and then immediately the Vblank IRQ would happen before the decrement could take place." If you are interested in my current state of my projects, PM me for the links. Thanks in advance :)

Bock Site Admin Joined: 08 Jul 2001 Posts: 8651 Location: Paris, France	Posted: Mon Feb 11, 2019 2:07 pm
	Hello and welcome! Quote 1 - Sub frames input - Is it possible for a game to poll the controller multiple time within a single frame (the I/O ports $DC and $DD)? - Is it possible to press the reset and pause buttons on a CPU cycle level? Yes the controller can be polled at any time. I suspect that the vast majority of games only poll them only once a frame. Using a debugger you can confirm that for a given game. Pause button is triggering a Z80 non-maskable interrupt so that can happen anytime. In reality, the vast majority of NMI handler will alter some flag that will then be polled by the main loop. Quote 2 - Cart swapping - Does it have a "cart lock", a plastic piece preventing cart swapping while the console is powered on? No. However the way the bus are connected makes hot unplugging/plugging cartridges highly unreliable (it is often going to create interference of some sort and crash the system). Quote 3 - SMS Aladdin Pal-B Quote 4 - Pause button spam glitch I don't see any questions in there. The best way to get any answer that specific is to use a debugger and study the game code.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Mon Feb 11, 2019 2:53 pm
	Pause button spam means invoking the pause routine twice if the time taken ends up shorter than waiting for a halt opcode to complete. Game loops assuming halt = wait for next frame can be tricked into running more rapidly. I suspect Aladdin is just laggy, so it polls inputs less frequently depending on the time it takes to run the main loop. Pause always gets serviced because it triggers an interrupt, although as Bock said many games just set a flag for the (laggy) main loop to poll.

MESHUGGAH Joined: 11 Feb 2019 Posts: 5	Posted: Mon Feb 11, 2019 3:44 pm
MESHUGGAH Joined: 11 Feb 2019 Posts: 5	1 & 2: Thanks for the answer Bock! 3 & 4: These two are the currently known facts after trying to debug and test it. The question would be for these two is: - Did we figured out correctly and does this really works in real life? Regarding 3 - Pal-B: - It looks clear to me that there is something wrong with this. The game has nearly no lag frames but if you watch the video (posted the end of the youtube url in OP), you can see how different is the polling rate. Example of denied input (you can press anything (but pause) and nothing will happen): 1330, 1334, 1336, 1340, 1346, 1348, 1352 (difference between numbers: 0, 4, 2, 4, 6, 2, 4) I also have a very lengthy detailed tests about this. I put it in code to don't bloat the page. ONLY PAL! (5 polls (instead of 1-3) or 3 polls (instead of 1-2) when used in NTSC) Aladdin, Alien 3, Air Rescue CAN BE NTSC (1st level gameplay has same polling rate albeit being Europe) Alien Storm, Tom and Jerry edit: Some new informations: - There are SMS games with only PAL while GG with NTSC, example: Ariel, Asterix and the Great Mision - There are GG games with only PAL (but there is no display type change for GG so it's 60fps), example: Asterix and the Secret Mission - Bram Stroker's Dracula SMS E (PAL) but GG has both regions - I couldn't find anywhere about Game Gear being region dependent, yet I found many different regions for most of the Game Gear games edit3: TASes published using the erroneous setting (NTSC for a Europe ROM resulting in fluctuating input poll which makes input denied): [2920] SMS Danan: The Jungle Fighter (USA/Europe) in 7:18.14 by Aqfaq - SMS Export, only European (with Brazil) ROM found, has input denied issue when using NTSC edit4: So it seems that if a game has a constant half rate gameplay, there won't be input denied issue. Some movies that uses European ROM but plays on 60hz listed below [2271] SMS Astérix (USA/Europe) in 26:20.56 by Johnnypoiro - SMS Export, only European (with Brazil) ROM found, 1.0, however there is no input deny in 1st level because every even frame is lag frame [2834] SMS Batman Returns (Europe) in 1:38.24 by mamuuuut - SMS Export, only European (with Brazil) ROM found, however there is no input deny in 1st level because every even frame is lag frame [2985] SMS Cheese Cat-Astrophe Starring Speedy Gonzales (Europe) in 13:07.26 by Mephistus & Really_Tall - SMS Export, only European (with Brazil) ROM found, however there is no input deny in 1st level because every even frame is lag frame edit5: TwoMbit tests: - from readme: "- there are a few pal games which have glitches playing with us/jp region selected. These are no emulation bugs. It behaves the same at a real system." - also note TwoMbit has option to select between SMS1 and SMS2 unit - there's 3 region settings: Japan, Europe, USA (and Auto) - since there's no frame stepping, I couldn't test the input denied issue - Game Gear games seems to be always 60hz final edit: According to many sites of sega gamers, these are my conclusions: - GG is always 60hz - SMS1 and SMS2 only differs from the VDP and one minimal change - Brazilian SMS is supposed to be PAL-M, 60hz, however some people commented on having 50hz... This will be a task for someone to track down. This might be an inaccurate fact! - There are carts that don't fit into other region's unit Regarding 4 - Pause glitch: - SG-1000 Bank Panic has a very similar pause glitch as SMS Batman Returns (this time it's more of 1 frame reduce per 3 frames with P, emtpy, P) - I'm a bit pessimist on how reliable would be this on a real console, so I'm mainly looking for someone to test it.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Mon Feb 11, 2019 6:24 pm
TomHarte Joined: 24 Sep 2018 Posts: 66	Re: the pause button: Yes, it generates an NMI. No, it doesn't do so at any time. It's routed through the VDP, and will only ever occur exactly one line before the start of new pixels per this thread. So any emulator that signals an NMI at any other time is incorrectly implemented. EDIT: based on a quick peek inside the TwoMBit code, it most definitely isn't what it claims to be: "cycle/bus accurate". E.g. check out vdp.cpp, line 150, where: (1) scroll position is cached, the v counter is incremented, etc, regardless of the device being emulated. This timing differs between the SMS and the GG; and (2) sprite overflow is calculated post hoc. In reality it is set as the raster runs. Also see the whole triage of initDelay() and updateDelay() that is triggered by write_port_BE. On a real machine, the amount of time a write takes to reach VRAM is a fixed amount plus a function of the current raster position. This emulator just uses a larger fixed amount. So, honestly, if I were you I wouldn't trouble myself too much with things that appear to work one way on hardware but aren't reproduced in that emulator.

MESHUGGAH Joined: 11 Feb 2019 Posts: 5	Posted: Tue Feb 12, 2019 11:28 am
MESHUGGAH Joined: 11 Feb 2019 Posts: 5	TomHarte: - Reset/pause: Thanks, I suppose this is entirely depends on the programmer of the games then? - Do you know any better emulator for SMS than TwoMbit (and BizHawk since that's the emulator which I will use and write to feature request for the devs)? Quote So, honestly, if I were you I wouldn't trouble myself too much with things that appear to work one way on hardware but aren't reproduced in that emulator. This is what I exactly want as the goal of my projects is the ability to reproduce speedruns done on real console in the BizHawk emulator. We know that open bus and many physical phenomena won't be possible to implement as a 100% matching feature, but I'm optimist and try to do whatever I can in order to let this happen.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Tue Feb 12, 2019 2:47 pm
TomHarte Joined: 24 Sep 2018 Posts: 66	I'll have to let somebody else answer on suitable emulators, alas; I've no idea what BizHawk currently uses for its Master System, or whatever other accurate options would either lend themselves to being embedded within BizHawk or else already provide good speed-running functionality. On reset/pause: yes, it should entirely depend on the game title. But the fastest you should be able to press the pause button is once per frame, communicated to the software one line before pixels begin. So one extra interrupt per frame. An NMI rather than an IRQ, but obviously a particular title may unify its treatment of those.

Kagesan Joined: 01 Feb 2014 Posts: 877	Posted: Tue Feb 12, 2019 2:50 pm
Kagesan Joined: 01 Feb 2014 Posts: 877	MESHUGGAH wrote Do you know any better emulator for SMS than TwoMbit (and BizHawk since that's the emulator which I will use and write to feature request for the devs)? I don‘t know about the specific needs for speedrunning, but from a developer’s point of view, Emulicious is by far the most accurate enulator I know. If something works in Emulicious, it works exactly the same on real hardware.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Tue Feb 12, 2019 4:14 pm
TomHarte Joined: 24 Sep 2018 Posts: 66	Kagesan wrote MESHUGGAH wrote Do you know any better emulator for SMS than TwoMbit (and BizHawk since that's the emulator which I will use and write to feature request for the devs)? I don‘t know about the specific needs for speedrunning, but from a developer’s point of view, Emulicious is by far the most accurate enulator I know. If something works in Emulicious, it works exactly the same on real hardware. To be explicit, I didn't consider that because it appears to be Java based, and it's not clear to me that it's open source. So it'd be problematic for BizHawk integration on at least two fronts. I don't mean to state any opinion about its other qualities. For the record, my negligible understanding of the specific unusual requirements of tool-assisted speedrunners are great support for input capture and replay, and especially manipulation of that implied timeline — being able to rewind at will, an arbitrary amount of time, and attempt further play from more or less any previous instant. That's the 'tool-assisted' part, the fun being to construct the minimal time that a title could be completed in by any means, which usually involves a fair amount of ingenuity and lateral thinking. And then I keep falling back on BizHawk integration because I believe it handles all the good stuff of tooling, just needing cores it can implement from which it can capture complete state periodically and feed input with precise timing. All that plus the more normative requirements of being as cycle accurate as possible, of course. You're not looking to exploit somebody's haphazard emulation of a game. So, even though you'll hear me boast elsewhere about my emulator, and its steps towards lots of good accuracy stuff (real VDP timing, chroma dots, genuine composite video*, low-latency everything, etc, etc) I'd propose that it's unsuitable for this purpose because it lacks state captures and because the aggressive code sharing between things it emulates means that it sprawls a little too much to be "a core" in emulator collection terms. Well, that plus the entirely different approaches to managing latency that such frameworks tend to impose. Though that's with no specific knowledge of BizHawk internals. Just a pessimism born of things like RetroArch. * audio usually being an obvious one. Quite a lot of these throw-everything-together frameworks don't give you any better scheduling precision than one execution per frame. So the only workable audio strategy if adapting code to work within one of those is just to queue up quite a lot of it. So extra audio latency. And I can think of various non-audio complaints, but we might be straying into chip-on-shoulder territory here. ** not a hacky post-hoc filter on an otherwise perfect framebuffer, in which someone asserts that, you know, composite video is blurry, right?, but rather computing the actual 1d composite signal, communicating only that outwards, and having the screen output be a decoding of that. The usual gutter-level emulation "NTSC[/composite] filter" is as much about emulating NTSC as would be taking an existing game, displaying it in only 8 colours, and saying you've written a BBC Micro emulator. Chips on shoulders abound!

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Tue Feb 12, 2019 6:02 pm
	I think we can have the best of both worlds. I like "perfect" emulation - sharp pixels and unfiltered audio, often with the sprite limit removed and no CRAM write dots - but at the same time I'm happy to have cycle accurate emulation underneath it and low latency. After that I like to have nice debugger tools, and source I can hack on and submit pull requests for. Some people want blurry squashed video and muffled audio, and it's great to offer that too. I think the model for an emulator "core" has changed over the years and one size definitely does not fit all. Coming back to the Master System and TASing, speedrunning and TASbot, I think it's a tricky problem. Emulators probably don't have enough accuracy on some timing aspects to mess with such things as microsecond scale input handling, and reproducing anything more than frame accurate timing on real hardware is going to be tough because we just don't have that read strobe used for TASbot on Ni****do consoles. As for Aladdin and its dodgy controls, that's really just software. It may have its timing thrown off on NTSC hardware as there are fewer cycles per frame, but I doubt it as it's a Japanese developed game with a very similar Game Gear version. It may just be crappy code.

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Tue Feb 12, 2019 6:23 pm Last edited by TomHarte on Tue Feb 12, 2019 9:45 pm; edited 1 time in total
TomHarte Joined: 24 Sep 2018 Posts: 66	Dealing with it shortly: sharp pixels should be offered by an accurate emulator, as the real machine has RGB output that produces sharp pixels. My test for a good emulator is directly from first principles: how well does it imitate the real thing? Also, at least my emulator models input as arbitrarily placed within frame. There's no way I'm alone in that. (EDIT: gluing it on here in retrospect rather than further lengthening the off-topic part of the discussion, my philosophy is a little more like: an emulator should first do exactly what the real hardware does. Then it can do more. The only thing that I would consider as making an emulator worse rather than better is offering only something inaccurate. Like compelling the user into square, perfect pixels, so that you've no option but to play at an aspect ratio the assets weren't designed for.) Digressions aside, I notice that the CLK and IOREQ signals are present on the cartridge slot, so could a putative TASBot not provide a plug-through for that? Or is there some sort of prohibition on using anything beyond the ordinary user-facing input and output ports for information? And/or would the optics be problematic, in that you'd end up spending 80% of your time explaining to the latest set of people who saw a video but didn't read anything that, no, you're not modifying the cartridge. Just catching a couple of timing signals.

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Tue Feb 12, 2019 6:24 pm
	I had a look at Aladdin and it is a bit weird. It reads the controls outside the VBlank interrupt, and it seems to do so at an inconsistent rate, so it ends up doing it on a different line every time - sometimes near the end of the frame, sometimes near the start. I suspect it is running its main loop at an unstable rate and will sometimes skip frames. Here's some Meka debugging: # w r io dc Watchpoint [0] added. [0] Watch IO R. DC # w line #0 Watchpoint [1] added. [1] Watch LINE E 0000 # c 09CA: [0] watch IO read from DC, read value=ff 0A04: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 05B6: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 109F: [1] watch LINE 0 event 8470: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 8472: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 09CA: [0] watch IO read from DC, read value=ff 3C4A: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 17A1: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 05B9: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 09EE: [1] watch LINE 0 event 846F: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 09CA: [0] watch IO read from DC, read value=ff 3B75: [1] watch LINE 0 event 859C: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff 8472: [1] watch LINE 0 event 09CA: [0] watch IO read from DC, read value=ff What this is doing is logging each time it reads the controller ("IO read from DC") and each time it starts a new frame ("LINE 0 event"). You can see some frames it reads the controller twice, some not at all. Compare to a "normal" game like Alex Kidd in Miracle World: 26A7: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 26A2: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 26A7: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 26A2: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 26C0: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 26A2: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 9C60: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 4124: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff 2B0A: [1] watch LINE 0 event 036F: [0] watch IO read from DC, read value=ff

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Tue Feb 12, 2019 6:28 pm
	I'd just wire TASbot up internally :)

TomHarte Joined: 24 Sep 2018 Posts: 66	Posted: Tue Feb 12, 2019 8:31 pm
TomHarte Joined: 24 Sep 2018 Posts: 66	Actually, I guess we're being foolish. If you're additionally watching the bus by any means, you can just replay controller inputs as and when the game reads them. That's other than pause and reset, but given that a game isn't required to use interrupts at all, and if it does it may receive as many as one per pixel line, I don't see a good option for those other than hooking into the VDP sync signals?

MESHUGGAH Joined: 11 Feb 2019 Posts: 5	Posted: Wed Feb 13, 2019 8:50 am
MESHUGGAH Joined: 11 Feb 2019 Posts: 5	Thanks guys! TomHarte: Will try Emulicious and test what I can. Maxim: Regarding SMS Aladdin, I assume you used NTSC region settings since that's have the weird polling issue. I think it will poll consistently in PAL region settings. Then again, where it goes wrong? It doesn't accounts the region difference?

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Wed Feb 13, 2019 9:42 am
	The general pattern for SMS games is to split work between the VBlank - which will run every frame, provided you don't make it take longer than a frame to run of course - and a main loop. The VBlank is special time because you can do your video updates in there, but games generally also update sound (because lagging sound could be noticeable) and read the inputs in there too. The main loop can then be running game logic which doesn't have such timing dependency. In general though, you need to have a target frame rate (60, 30, or less) and aim to always do one frame of work in less than the time a frame takes. Going past that generally leads to slowdown. Aladdin seems to work fine in PAL/50 mode, and nobody cared that it was a bit unresponsive in 60Hz regions (Brazil, South Korea). The Game Gear version works correctly at 60Hz.

MESHUGGAH Joined: 11 Feb 2019 Posts: 5	Posted: Wed Feb 13, 2019 10:10 am
MESHUGGAH Joined: 11 Feb 2019 Posts: 5	Thanks Maxim, really great to hear this (problem seems to be correctly emulated)! I assume if I type the same as you inside Meka (edit: the lines with a # prefix), I get the same log text so I can test the other games with this input polling problem? (0] watch IO read from DC, read value=ff )

Maxim Site Admin Joined: 19 Oct 1999 Posts: 14744 Location: London	Posted: Wed Feb 13, 2019 10:20 am
	This confirms that the game reads from the controllers once per frame. It doesn't confirm the game code correctly reacts to it. Also, Meka is a 90s era emulator at heart and while it has good compatibility, its accuracy regarding certain edge behaviour is not great.

Forums

View topic - SMS Technical questions and looking for oddities