7800 Technical questions and looking for oddities

[MESHUGGAHTAS]

TL;DR: Speedrunner looking for potential techniques

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 7800:

- answers to my 3 technical questions,

- any experiences of oddities on a real hardware.

1 - Subframe input

- Is it possible for a game to poll multiple inputs within a single frame (swcha and swch i/o ports)?

2 - Cart swapping

- I only found this on AtariAge forums, anyone knows more details of point me to the relevant threads?

- Would like to know is it possible to swap carts while the console runs without getting a crash, continuing the gameplay?

It doesn't appear to have any ill effects, actually, on the system or the carts. However, it will crash the game in progress and, in about 80% of cases, will actually draw graphics stored on the second cartridge on the screen. Also, with a cart out of the slot the screen resolution apparently changes itself depending on the presence (or lack thereof) of a cartridge in the cartridge slot.

 

3 - Dig Dug reset glitch

- If you press reset 36 times, does the game crashes and will only show garbled lines?

In BizHawk, pressing reset 36 times will result in a visual glitch which seems to be an unrecoverable soft lock.

The resulting soft lock visually identical to another glitch in Choplifter which can result in resetting the game as well.

More about Choplifter glitch:

 

The graphics glitch

This is a bug I discovered that glitches out part of the screen. It seems to happen because you dip below the maximum allowed Y-Position, the game doesn't know where to draw the helicopter graphics and so it freaks out. You can trigger it from the ground through a series of Up,Down+1 and Up,1,(nothing),1. Nothing should happen the first time you try one of these input sequences, but eventually, these sequences will make the helicopter rotate, something it's not supposed to be able to do on the ground.

• You will know when the glitch is active when part of the screen starts glitching out. From here, you can fly up a little and press 1 again to cancel the glitch (and imprint the glitched graphics on the screen), or fly too far up, left or right to crash the game to a colored screen.
• My favorite part is that just before you activate the glitchy screen, you can resume normal play, just without pressing 1. Whenever you want, press the button and the game will crash instantly to a colored screen. You can make a savestate at this point, change up the input and play around with crashing to screens of all different colors and tones. It's very entertaining, and you might even get some surprises, like recognizable graphics and sound effect patterns.

Also, fun fact: I had to switch my Frame Advance hotkey from N to Q because of the frequency with which I pressed Up+Left simultaneously for this run.

 

If you are interested in the current state of my projects, here are the links:

http://tasvideos.org/PlatformResources/Lynx.html

http://tasvideos.org/MESHUGGAH/ForbiddenTechniques.html

Thanks in advance

 

[MESHUGGAHTAS]

I don't find how to edit, so here's is the correct link for my A7800 page: http://tasvideos.org/PlatformResources/A7800.html

[RevEng]

1 - Subframe input

- Is it possible for a game to poll multiple inputs within a single frame (swcha and swch i/o ports)?

Multiple inputs, meaning both swcha and swchb get polled in the same frame? Yes.

 

Multiple inputs, meaning swcha gets polled multiple times in the same frame? Yes, but I doubt any games actually do this. 7800 games tend to have tasks synced at some multiple of the frame rate. For tasks that aren't synced to the framerate, the interval tends to be longer than a frame.

 

 

2 - Cart swapping

- I only found this on AtariAge forums, anyone knows more details of point me to the relevant threads?

- Would like to know is it possible to swap carts while the console runs without getting a crash, continuing the gameplay?

The practical answer here is "no". The console doesn't have a lot of RAM, so none of the commercial games are running wholly (or even partially) out of RAM. If you yank away the cart, the 6502 has no instructions to follow, and a crash is inevitable.

 

 

3 - Dig Dug reset glitch

- If you press reset 36 times, does the game crashes and will only show garbled lines?

Probably, though I don't have a console handy. MAME/A7800 replicates this same behaviour.

 

The reset switch is a soft switch, so there's likely some buggy code handling it.

[MESHUGGAHTAS]

I suppose you (RevEng) are the main author of 7800.8bitdev.org. Thank you for writing that page, I've mostly learned only from that page.

 

1 - Subframe inputs - Thanks! I will try to test all released ones then (note to myself: debugger breakpoint swcha swchb read)

 

2 - Cart swapping - My goal is to create Tool Assisted Speedruns using the BizHawk emulator. While the emulator doesn't supports cart swapping on any of the cores, my ForbiddenTechniques page contains many examples on different consoles with very reliable and reproducible cart swapping: NES, Genesis, N64.

 

That's being said, do you mean from a technical view, cart swapping probably won't result a usable state, only crashing?

Would like to ask the same but for cartridge tilting (lifting the cartridge on the left side, I guess this is entirely platform and cartrdige dependent)?

 

3 - Dig Dug reset glitch - Good to hear other emulator also does it, would like to get information about on console.

[+SmittyB]

With regards to cart swapping if an emulator swapped carts between reads from ROM then it technically wouldn't have to crash, but the likelihood that it will start running valid code is probably minimal. It certainly wouldn't be physically possible on hardware with any of the existing software that I know of.

 

A big difference between the 7800 and something like the NES and later consoles is that while the graphics data will be in roughly the same place because of 'holey DMA' the display lists will be wherever the programmer saw fit. That makes it fairly unlikely you'll get any meaningful graphical output.

 

I can't see a reason why tilting/frying the cart would be more or less successful than it is on other consoles.

Edited February 15, 2019 by SmittyB

[MESHUGGAHTAS]

I can't see a reason why tilting/frying the cart would be more or less successful than it is on other consoles.

I don't have on-hand depth experience of tilting/swapping cartridges while the console is turned on for the purpose to speedrun, but here's my notes in my mind regarding this after many time spent researching and understanding the whole phenomenon:

 

1. Different platforms -> Different schematics (implementation and purposes) -> Different media specification -> Different results

 

2. From my page, there's only one technical explanation of tilting the cartridge from the left side: https://retrocomputing.stackexchange.com/questions/1648/how-can-tilting-a-n64-cartridge-cause-such-subtle-glitches

 

I think I'm mssing something as no other information found after searching with google. I've thought that given there's many experimentation of this has been video captured, someone should have already figure out a consistent way to make this a reliable thing.

 

I also don't have any degree of physics or electronics, so all I'm based off is that very high chances of reproduction of tilting cartridges supports the possibility to observe and understand the whole process within a small margin of error.

 

3. From my page, some console devs implemented the feature but either forgot/removed it (Nintendo 64 https://www.therwp.com/article/dk64-stop-n-swop-connection) or used it for crash handling (Genesis Sonic 3D Blast https://www.youtube.com/watch?v=M09oJusoKpI ).

 

4. Developers probably never even think about this possibility of swapping media while console is turned on, leading to odd results, that means there are high chances they don't hve any additional barriers apart from the physical world where this communication between the media (cartridge, cd, floppy, hdd) and the platform (console, PC) goes terribly wrong.

[+SmittyB]

Your first link is pretty much the explanation of tilting/frying.

Doing it on hardware is unpredictable because you're essentially reducing the chance that a signal on a particular pin will get through to the cartridge as you're reducing the quality of the connection which will change the resistance of the circuit and maybe introduce noise in the signal. Which pins that happens on is down to the cartridge design and connector.

 

As somebody mentioned in that thread, the Mario thing will be because the animations and music are loaded from ROM on the fly while the map itself will be in RAM to speed up drawing. It's the same reason you can play the first couple of Ridge Racer games on PS1 with your own music by swapping the CD, because the entire game is loaded into RAM and only the music is loaded in from (CD-)ROM. The issue with applying these principles to the 7800 and other earlier cartridge games is that they rely heavily on the ROM being available, there's just not enough of a benefit to run lots of code off the RAM when it's relatively limited.

When RAM isn't an issue, or when the game is expecting to be swapped there's not so much of a problem, just think of how many multi-disc games exist that ask you to swap the CD while the game is still running. It's exactly the same principle but handled in a more controlled way.

 

The Banjo Stop 'n' Swop thing would have worked had Rare decided to continue with it, but it relies on the particular RAM chips in the N64 being slow to lose their data when they're not powered and having some kid rip the cartridge out of the N64 and stick another one in before that data degrades. The thing that really killed the idea was that there would always be a possibility that Nintendo would put out a revision of the N64 like they did with the NES and SNES with different RAM chips and suddenly that nifty feature doesn't work any more.

[RevEng]

I suppose you (RevEng) are the main author of 7800.8bitdev.org. Thank you for writing that page, I've mostly learned only from that page.

That's me, and you're most welcome.

 

2 - Cart swapping - My goal is to create Tool Assisted Speedruns using the BizHawk emulator. While the emulator doesn't supports cart swapping on any of the cores, my ForbiddenTechniques page contains many examples on different consoles with very reliable and reproducible cart swapping: NES, Genesis, N64.

 

That's being said, do you mean from a technical view, cart swapping probably won't result a usable state, only crashing?

Would like to ask the same but for cartridge tilting (lifting the cartridge on the left side, I guess this is entirely platform and cartrdige dependent)?

I'd say from a technical view cart swapping won't work on the 7800. There's nothing useful running out of RAM, and reading from a ROMless floating bus will crash it before you can get another cart in. Tilting may have a better theoretical chance, but I doubt you could get it to work practically.

 

SmittyB mentions frying, which is power glitching the 6502 to corrupt it's Reset Vector (aka Start Address). The game starts up in some random bit of code. This sometimes produces interesting results on the 2600. I don't think it's useful on a 7800, since it has to successfully run BIOS code before the cart is enabled.

[MrBeefy]

So speedrunning is about glitching the games to beat it quicker? As opposed to beating it the way it was intended?

[Jinks]

So speedrunning is about glitching the games to beat it quicker? As opposed to beating it the way it was intended?

It is a kids thing. Cheat N beat. Really adds fun to the game.

[MESHUGGAHTAS]

It is a kids thing. Cheat N beat. Really adds fun to the game.

So speedrunning is about glitching the games to beat it quicker? As opposed to beating it the way it was intended?

While these are irrelevant for my topic, I guess I should address these.

 

MrBeefy: Yes, according to https://en.wikipedia.org/wiki/Speedrun:

 

 

Many games have opportunities to disarrange the intended sequence of events and skip entire parts of it — often called sequence breaking — and many more have programming mistakes, or glitches, that a skillful player can exploit to their advantage. Tool-assisted speedrunning is a type of speedrunning in which various computer tools are used to obtain performances which would be near-impossible for a human player.

Jinks: I think everything you wrote is incorrect but I don't want to change your opinion or views. Speedrunning is not only all about skipping everything, it's just the shortest way to complete a game. There are also many TASes doing 100 or more percentage runs. Also currently at TASVideos there is no single published TAS that uses a cheat in order to make the game easier at any degree. The same can't be told to speedruns at speedrun.com but might be Speed Demos Archive is also a good no-cheating speedruns place.

 

SmittyB: Thank you for your detailed answer! I've created 4 forum threads so far on various platfoms to investigate/collect informations from the largest active communities, and you fulfilled my answer completely I believe

 

RevEng: Thank you very much for the answer too!

 

I'm very grateful for the answers (especially you guys delivered it in a short time), so let me ask a few other questions, just to verify my informations:

 

4 - Will Atari 2600 games work on the 7800?

This is from AtariAge 7800 FAQ saying "There are a few games that won't work on certain revisions of the 7800 console."

 

Under "Hardware" in the FAQ shows the three different revisions. The reason I'm interested in this is that 2600 games on a certain revision of the 7800 might have an impact like difference in initial memory state, performance (lag frames' position and duration), any change compared to playing it on the original 2600 console.