YT YouTube2Text

YouTube2Text → Transcripts → Why Do Arcade Games Boot Up Like This?

Why Do Arcade Games Boot Up Like This? — Transcript

by Retro Game Mechanics Explained · 6,802 words · 738 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00Warning!
0:00This video will have
0:01a higher than average amount of flashing colors and graphics.
0:05If you're sensitive to this sort of thing,
0:07you might want to skip forward to the second half of the video.
0:10I'll be putting this warning sign in the corner for a few seconds
0:14before each video clip, so you can brace yourself.
0:17Let's look at some arcade game self-tests!
0:20♪ [intro jingle] ♪
0:23Retro Game Mechanics Explained is brought to you
0:26by its YouTube members, Patreon supporters, and viewers like you.
0:31Thank you!
0:34In a couple of my previous videos about Pac-Man, I've
0:36shown this short clip of the game starting up for the first time,
0:40and there have been
0:41a handful of comments asking me what the heck is going on here.
0:45This isn't the game glitching out or anything.
0:47It's intended to look like this.
0:49In fact, it's intended
0:50to look exactly like this, and if it doesn't, there's a problem.
0:54This is one of many self-tests that we'll look at today.
0:58Essentially, this is the machine testing every single bit of memory
1:02that is included on board by writing ones and zeros everywhere,
1:06and then reading them back to make sure they all work properly.
1:09If even a single bit doesn't stay a one when set or zero
1:13when reset, it will be detected and reported as an error.
1:18This way, the manager of the arcade machine
1:20can quickly fix it and get it back in working order.
1:23These game machines are moneymakers, after all,
1:26and if they're just giving away free games when they aren't supposed to,
1:29or if they're just flat out broken, they aren't bringing in the quarters.
1:33The reason for all of the glitchy looking graphics is because video
1:37memory itself is included in the memory tests,
1:40and the jumble of tiles on the screen is just a side effect of writing
1:44a bunch of different numbers to all of the memory locations.
1:48All of these tests are only done when the machine is booted
1:51up, which is presumably done
1:53when no players would be around to see anyway.
1:57The most common self-tests at boot are memory tests,
2:00but a lot of games will also perform ROM checksums as well,
2:03which is just another form of memory test if you think about it.
2:07While these are a quick
2:08and easy way to check for crude modifications of game code,
2:12they're also good to ensure the integrity of the ROM chips,
2:15as well as if they're even present
2:17and seated correctly on the motherboard.
2:19Other tests can include a sound test,
2:22which is usually just a sound or two that lets you confirm
2:25that the audio is present and in working order,
2:27as well as a big grid pattern like this, which helps
2:30with checking the alignment and brightness of the CRT monitor.
2:35A lot of arcade machines have some sort of switch,
2:37either in the cabinet or on the motherboard itself,
2:40that allow the manager to put the game into service mode.
2:44This mode can allow access to more tests, and provides results
2:48of the tests that can stay on screen for longer than half a second.
2:53Usually, everything you see at boot is present
2:55here as well, such as the checksums and memory tests.
2:59Full fledged sound tests are more common here,
3:01allowing for every sound effect and music track to be played back.
3:05More full screen grids are common, as well as color bars
3:08for more involved testing and color correction.
3:12Service mode is also where the game’s DIP switch states are shown.
3:16This small set of switches, usually located on the motherboard,
3:19control game properties such as the number of lives
3:22you start with, number of points
3:24to get an extra life, game difficulty, and so on.
3:27Being a physical switch you have to flip,
3:30you wouldn't need an extra battery to save these settings.
3:33The switches were usually unlabeled though, so this was a way
3:37you could change the settings without having
3:39to find the owner's manual to tell you which switch did what.
3:44I want to analyze some of these self-tests
3:46and figure out exactly what is happening at each step.
3:49But first, it would be a good idea to be familiar
3:52with the different types of memory, at least with video memory,
3:55as it's easy to tell apart visually during all of the tests.
3:59First, we can split memory into two main categories:
4:02read only memory and read/write memory.
4:06Read only memory, or ROM, is self-explanatory.
4:09This memory cannot be written to.
4:12These memory chips are burned once,
4:14and so the data they have on them generally can't be changed.
4:18Yes, technically some types of ROM can be rewritten,
4:20but for our purposes now, we'll just ignore that.
4:24There are two main types of ROM found in arcade machines.
4:27The first is the program ROM.
4:30These ROM chips contain the game code and they determine exactly
4:33how the game runs.
4:35The other type of ROM is graphics
4:37ROM, also known as character ROM or sprite ROM.
4:41These chips hold all of the graphics data used
4:43in the game from the backgrounds, text, and sprites.
4:47Program ROM and graphics ROM are generally stored separately
4:50because while the main processor utilizes the program ROM
4:54in order to execute the game code, it's the graphics processor
4:58or video unit that requires access to the graphics ROM.
5:02These two processes are usually happening simultaneously,
5:05and having them on separate chips helps with that functionality.
5:09Also in this read only category would be BIOS
5:12data--basic input/output systems.
5:14While the main processor in arcade machines might not have a BIOS,
5:18there are often more dedicated chips and microprocessors
5:21that might have embedded BIOS programs.
5:25The other kinds of memory can be written to
5:27to well, store information, the first of which is a technicality:
5:31processor registers--accumulators, index
5:34registers, stack pointers, etc.
5:37These memory locations aren't found on a memory chip,
5:40but rather inside the processor itself.
5:42Generally, there are a small number of these values when compared to
5:45how much data can be stored inside a dedicated memory chip.
5:49The rest of the writeable
5:50memory here are all random access memory or RAM.
5:54Random access, meaning that there isn't much, if any, variance
5:58in access time between two locations in that memory.
6:02Here we can have audio RAM, which is memory that is dedicated
6:05to the sound system for playing sound effects and music.
6:08This can hold music data, but often that is kept in the program ROM.
6:12While audio RAM
6:13holds stuff like the length and pitch of currently playing notes.
6:17There's also video RAM,
6:19which is memory that is dedicated to the graphics system.
6:22We'll come back to that.
6:23And then there's general purpose RAM, which can be used
6:26for any other purpose, sometimes referred to as work RAM.
6:30This is where you would find all of the game variables
6:32such as timers, level numbers, entity positions, velocities,
6:36and a whole bunch of other properties.
6:39We're going to split up the video RAM even further,
6:42just because
6:42it's pretty visually distinct when it comes to all of these self-tests.
6:46There's the tile RAM, also known as tilemap RAM, or background
6:50layer RAM, or sometimes just plain video RAM.
6:54This memory just holds the tile ID
6:56of every tile that should be visible on screen.
7:00This is usually partnered with the tile palette RAM or tile
7:03color RAM, which defines which colors each of these tiles uses.
7:08Those palettes are derived
7:10from the values that are found in color RAM, which holds
7:13definitions for each of the colors the tiles and sprites can use.
7:17Sometimes this is stored as red green blue color values,
7:20but it can also be in other formats depending on the hardware.
7:24Color data is also sometimes just stored in ROM instead
7:27if the color palette of the game isn't dynamic.
7:31And finally, there's the sprite RAM or object RAM,
7:34which holds data on every moving sprite on the screen.
7:38Unlike the tiles, which are restricted to a grid,
7:41these sprites can move anywhere on the screen,
7:43so this data usually contains X and Y position pairs as well as a sprite
7:48tile ID and palette number, not unlike the tiles themselves.
7:52Not every arcade
7:53machine system will have all of these types of memories,
7:56and the amount of each memory can vary as well.
7:59A game that only has a single background
8:01tile layer will only need
8:02enough memory to list out all the tiles that fit on screen,
8:06but a game that has multiple layers will need extra tile RAM for example.
8:11And any vector based game won't have any of these types of video RAM,
8:15but rather a different kind of video RAM meant for storing instructions
8:18for drawing all of the vectors on the screen.
8:23Let's look at a bunch of examples now.
8:26First, here is Galaxian’s bootup sequence.
8:29Blink and you miss it--this one's pretty quick.
8:32The first thing that happens is actually a solid black screen,
8:35which is a memory test on the generic work RAM.
8:38There's nothing drawn to the screen yet
8:40at this point, which is why it's completely dark.
8:43Second is the memory test on the tile RAM.
8:46The most common kind of test is to write a bunch of numbers
8:49in a sequence to the entirety of memory,
8:52and then read back everything
8:53to make sure that they match what was written.
8:55In this case, the game starts with a certain tile ID 64
9:00and then adds 47 to the ID to find the next tile’s ID,
9:04wrapping around at 256 if needed.
9:07Then it reads all of them back, making sure
9:09all of the IDs are 47 away from each other.
9:13It does this test 32 times, starting with a different initial tile ID
9:17each time.
9:19The next test is incredibly quick
9:21and you can't even see it after the tile RAM test.
9:24The game calculates the ROM checksums.
9:27While Galaxian has character ROM chips and program
9:30ROM chips, only the program ROM chips are checked.
9:34This is done by adding up every single byte from
9:37each of the ROM chips into one value, wrapping around at 256.
9:42If the ROM is genuine, it will always add up to the same number.
9:46The fourth test here is on the sprite RAM.
9:49A similar test to the tile RAM is done on the sprite RAM,
9:52which is what causes these graphics to flicker all over the place.
9:56Due to the pattern of numbers used for the test,
9:59the sprites always show up on this screen in this diamond shape.
10:03Then very briefly, if all of the tests pass, the letters
10:07“OK” are shown on the screen along with the DIP switch settings.
10:11One coin in the coin box will give one credit,
10:14the player gets an extra life at 7000 points,
10:17and starts with three lives.
10:20Then the screen fills with this grid pattern
10:22for a moment just so you can quickly check the screen alignment.
10:26Then the game jumps into normal gameplay with attract mode.
10:30If any of the tests fail, the whole process starts over.
10:34This way, if there was just a fluke, it will start normally on a retry.
10:38But if there's a real problem,
10:39the tests will keep going over and over and over again.
10:43In the case of Galaxian, the manager of the machine
10:46would need to switch the game into service mode.
10:48When in service mode, the tests do not start over
10:52and instead the game will report which chip went bad.
10:55If a ROM chip failed its checksum test, it will report bad ROM,
10:59and if any of the RAM chips
11:01failed their bit test, it will report bad RAM.
11:05You would have to defer to the owner's manual to decode
11:07the number here, which narrows it down to which chip went bad.
11:12Here's another one.
11:13Teddy Boy Blues has a relatively long self-test on boot.
11:17Its memory tests are pretty extensive.
11:20The game seems to hang on this screen that shows “IC CHECK” for a while.
11:25That's because instead of just checking if each
11:28bit in each byte in memory works correctly,
11:31requiring eight passes, (one for each bit),
11:34it checks if every byte in memory can properly hold every eight-bit
11:38value from 0 to 255, essentially
11:41requiring 256 passes.
11:44Eventually, the words on screen start to flash along with the background.
11:48This is the color RAM being checked for all possible values.
11:52Next, video RAM is checked very thoroughly by making sure
11:55every tile in the tilemap can possibly be every tile ID,
12:00and this game has two background layers,
12:03so the second one is checked after the first one is done.
12:06Lastly, the scrolling
12:07behavior of the background is tested with a bit of movement.
12:10Then the game starts up normally 47 seconds after powering on.
12:16If any of the tests fail, the screen immediately
12:19shows the ID of the bad chip on the motherboard.
12:22This game’s service mode doesn't have much, it
12:25just features the state of the DIP switches, buttons,
12:28and a very simple music and sound test, along
12:31with a second screen with some color bars.
12:35The last game I want to show off here is Joust
12:372, only because it has the coolest service mode in a game I've seen.
12:41When this game starts up, the first thing that happens
12:44is a few memory tests, along with a short sound test.
12:48Unlike most games that use sprite
12:50objects in conjunction with a grid-based background layer,
12:53Williams Electronics games like Joust use a gridded out background
12:57along with a single bitmap pixel-based layer for moving objects.
13:02That's why this memory test looks a lot more like TV static
13:05than any of the other ones we've seen so far,
13:07because this is the bitmap layer being tested.
13:11This next screen is a fun
13:12visual representation of the ROM checksums being tested.
13:16The big rectangle is the motherboard, and each little rectangle
13:19is the location of a particular ROM chip on the board.
13:23Each chip will light up green when the checksum passes
13:26and will turn red if it fails.
13:29If everything goes smoothly, the game reports
13:31“all systems go,” which is fun.
13:35The real fun here though, is the service mode.
13:38There are so many in-depth tests and options here.
13:41Upon entering service mode, the ROM checksums are performed again.
13:45Then next up is the RAM tests again.
13:48However, these tests will just keep going on forever
13:51until you press the button to advance to the next screen.
13:54So if you really wanted to stress test
13:56that memory, you could leave this going for a long while.
13:59The next test is a test of the CMOS RAM.
14:02Remember everything about DIP switches?
14:05This game doesn't have any, and instead
14:07saves all of its options in a special memory location here.
14:10It also stores a bunch of other stuff,
14:12including the high scores, so those can persist over a machine reset.
14:17The next screen is a simple sound test
14:19that plays each of the game’s sound effects and music tracks.
14:22[Joust 2 sounds]
14:23[Be careful, warrior!]
14:25[vulture screaming]
14:26Then there's the switch test, which lets you test
14:29each of the cabinet’s input buttons and coin boxes.
14:33The next screen cycles through a bunch of solid colors,
14:37and the next screen shows a fancy grid pattern.
14:42Then another solid screen
14:43of red, green, blue, and then some color bars are useful
14:47for diagnosing issues with the video system.
14:51And the next screen is the bookkeeping totals.
14:54The game keeps track of a bunch of statistics
14:56about how much it's played,
14:58how many coins have been fed, total number of credits,
15:01and how many minutes of gameplay have occurred.
15:04The final screen
15:05is all of the settings that take place of any DIP switches.
15:09The advantage of using special battery-backed RAM for these settings
15:13is that you can be a lot more granular with the options.
15:16For example, you can start with anywhere from 1 to 99 lives.
15:21There's also a difficulty setting and an option
15:23to extend the number of letters a player can input
15:26when they achieve the highest score on the leaderboard.
15:29But my favorite parts are here at the bottom.
15:32There's an option specifically to overwrite the high score’s
15:35name with custom text without removing the score itself.
15:39Just in case someone enters something inappropriate,
15:43there's also an option to set
15:45a custom message text that appears on the title screen.
15:48You can input a full two lines of text and reposition it on the screen,
15:53which just seems silly, but also really cool that the option
15:57is even there.
15:57[Who will challenge me?]
16:01The last thing I want to do in this
16:02video is analyze the code for a couple of these self-tests.
16:05I'm going to go over Pac-Man and Super Pac-Man's
16:08testing functions, breaking down the assembly code.
16:11Despite being the sequel, Super Pac-Man’s self-test is entirely
16:15different and much more complicated for reasons we'll see shortly.
16:19Oh, and there's not going to be any more flashing colors and graphics
16:22for the remainder of the video, so you're safe there.
16:25Let's go ahead and look at Pac-Man's code.
16:29Pac-Man uses a Zilog Z-80 processor,
16:32and here's the assembly code for all of the self-tests.
16:36Z-80 assembly is pretty sparse, and it takes a lot of instructions
16:40to do simple things, which is why this seems like a lot of code.
16:44It can be split up into three main sections: the ROM checksum tests,
16:49the RAM memory tests,
16:50which can be split into the writing phase and the reading phase,
16:55and then the clearing of all memory.
16:57Let's look at the checksum calculations first.
17:01Pac-Man uses four ROM chips, and each
17:03chip's checksum is calculated independently.
17:07If a chip's checksum is incorrect, the game will report
17:10which chip failed so it can be replaced.
17:13And each chip actually has two checksums.
17:16The even and odd bytes are summed together separately.
17:20So this code first calculates the four chips’
17:23even-byte checksums, then their odd-byte checksums.
17:27Here's some equivalent pseudocode for this big nest of loops.
17:31Being an 8-bit CPU, this innermost loop
17:35sums together each 256-byte page of ROM.
17:39Or rather, the 128 even or odd bytes in each page.
17:44The next inner loop
17:45advances through the 16 pages per ROM chip.
17:49This line of code here is doing what's referred to as “kicking
17:53the watchdog,” which is essentially just resetting an internal timer.
17:57The watchdog is a hardware mechanism that is responsible
18:00for restarting the entire system if left idle for too long,
18:04so that if the game were to ever lock up somehow,
18:07it would restart all on its own without needing someone to physically
18:10come out to turn the machine off and on again.
18:13In order for this not to happen, this particular register
18:17needs to be written to regularly,
18:19and it's done several times during all of these tests.
18:23Here's the actual comparison to confirm the checksums.
18:26The running sum total is an 8-bit value that wraps around at zero,
18:31and it should equal exactly zero after each calculation.
18:36Generally, the
18:37last byte in each ROM chip (or the last two bytes, one even
18:41and one odd) is reserved to be the checksum complement,
18:44which is pre-calculated at the time the ROM is burned onto the chip.
18:48The value is chosen to be the exact value
18:51needed to make the entire sum equal zero.
18:54If any of the checksums are found not to equal zero, then execution
18:59jumps down to this small block to flag the ROM as faulty.
19:03This small block of code is responsible
19:05for advancing to the next ROM chip after each checksum.
19:10This line of code resets the coin counter state.
19:13I'm not exactly sure what it's doing here, but sure.
19:16And then this small block of code flips from checking
19:19the even bytes to the odd bytes.
19:22If all of the
19:22tests pass, then execution jumps forward to the next section.
19:26If not, then the bad chip is identified by referring
19:29to the current memory address that the test was working on.
19:33The tests are marked
19:34as failed, and at this point the RAM tests are completely skipped.
19:38There's one small caveat here that's worth pointing out.
19:41See this comparison instruction?
19:44The ROM data gets memory mapped to $0000 through $3FFF,
19:49and this instruction is in charge of detecting
19:51when the calculation has hit the end of the ROM range.
19:54This $30 is referring to the upper eight bits of the ROM address,
19:59but because this is $30 instead of $40,
20:03the fourth ROM chip is actually never checked at all.
20:06The fourth ROM chip is the one that includes
20:08this self-test routine, but I'm not sure if this was on purpose or not.
20:13The fourth ROM chip does have a checksum complement
20:16at the end of the data, but both the even and odd bytes are incorrect.
20:20So if this instruction gets changed to “CP $40”
20:25like it should be without recalculating the proper checksum
20:28(but still taking into account the change to this instruction),
20:31the game will erroneously report that the fourth ROM chip is bad.
20:35The equivalent fix in the pseudocode would be to change this
20:38less than comparison to a less than or equal comparison.
20:44Next are the RAM tests.
20:46There are six tests performed, two on the work
20:49RAM, two on the video RAM, and two on the color RAM.
20:53This small table lists the six tests.
20:57The first parameter in each entry is the starting address for the test:
21:00$4C00 being work RAM, $4000 is video
21:05RAM, and $4400 being color RAM.
21:09The second parameter is the bitmask for each test.
21:12These three memory regions all used 4-bit RAM chips,
21:16so each of them needed two chips for a bytes worth of information.
21:20The lower four bits of each
21:22byte are stored on one chip, and the upper four bits on the other.
21:26That's why there are six tests here.
21:28There are six chips in total, and each test is dedicated to one chip.
21:34The last parameter in each entry is just how many pages of memory
21:37to test, and in our case, each chip has four pages worth of data
21:41or 1024 four-bit nybbles.
21:45Before looking at the code for this one,
21:47let me explain exactly how this test works.
21:51The test is split into two phases: writing to the memory
21:54and filling it up with a certain pattern of values,
21:57and then reading the memory back and checking to make sure
21:59all of the values are equal to what you wrote in the first place.
22:03There's an entire philosophy around what values are the best values
22:07to write to RAM to test it for errors best,
22:10but here they went with completely random values.
22:13The problem with filling memory with random values is remembering
22:17what you wrote in the first place, so that you can check it again later.
22:21And we're testing the integrity of the memory itself,
22:24so we can't store copies of all these values anywhere.
22:28So we'll use the next best thing,
22:29which is a sequence of pseudorandom values.
22:33This way, instead of having to remember
22:35which value we wrote to each location,
22:37we can just calculate what it should be on the fly.
22:41The way this was done in
22:42Pac-Man was starting the sequence with a known seed value,
22:46and then multiplying and adding to that value to get the next number,
22:49essentially just like a random number generator.
22:53The starting seed can be anything.
22:55Let's just start with 200 for this example.
22:59The first number in the sequence is just the seed
23:02bitwise ANDed with the particular bitmask used in this test.
23:07For this example, I'm going to be using the bitmask of %00001111.
23:11ANDing with this value of decimal 15 is equivalent
23:16to modulo 16, or dividing by 16 and taking the remainder.
23:21This gives us the first number in our sequence of 8.
23:25Each subsequent number is just the previous number
23:28plus 51, then bitwise ANDed with the bitmask again.
23:32So the next few numbers in our sequence are 11, 14, and 1.
23:38Now, every
23:3916 numbers in the sequence, there's an additional step.
23:43After adding 51, but before applying the mask,
23:47the number is multiplied by 5 and 49 is added to it.
23:52So the 17th number in the sequence after 5 isn't 8, but rather 9.
23:58This happens again on the 33rd and 49th number, and so on.
24:03The sequence ends up being 1024 numbers long for each of the tests.
24:09Now, this isn't a very random sequence of numbers, but
24:12it doesn't have to be that random, just good enough for the memory test.
24:16And remember, this sequence is dependent
24:18only on the very first number we chose.
24:21Just by changing the seed value from 200 to, say, 201,
24:26we can end up with a different sequence of numbers,
24:29and of course with a different bitmask
24:31we get an entirely different set of numbers.
24:34These bitmasks ensure only one RAM chip is being tested
24:37at a time, and lets the game report which one is faulty.
24:42Okay, let's take a look at the code now.
24:44This seems like a lot, but it's really not that bad.
24:47It's just a lot of math.
24:49Here's the equivalent pseudocode.
24:51The two big chunks here
24:53are the write phase and the read phase of the test.
24:57The innermost loop of each
24:58is calculating the next value in the sequence.
25:02Here's the AND instruction that applies the tests’ bitmask.
25:06And here's the read or write to RAM.
25:09Here's the adding 51, the multiplying by 5,
25:13and adding 49.
25:16The seed value for the first test
25:18here is $FF or 255.
25:22After one write phase and one read phase.
25:25The seed is reduced by $11 or decimal 17.
25:31This SUB instruction subtracts 16
25:33and then the DJNZ branch instruction decrements it by one more.
25:3815 total passes are done
25:40as the loop here breaks out when the seed value becomes zero.
25:45This is actually kind of frustrating to see, because this convoluted
25:48sequence of numbers was actually chosen
25:51so that every four-bit memory location gets every possible
25:55four-bit combination written to it while still feeling random.
25:59There are 16 possible values for a four-bit
26:02nybble to have, but only 15 of them are tested.
26:06The missing values are exactly the values that would be present
26:10had the test been run one more time with a seed value of zero.
26:15Oh well.
26:17The biggest loop here is over the six entries in the test table,
26:21which in the assembly
26:22has a very crude way of checking for the last entry by comparing
26:26against the memory address high byte and the mask together.
26:30Finally, if there ever
26:31is a mismatch in any of the memory comparisons,
26:34the code jumps down to this small block.
26:37The chip number is derived from the bitmask itself,
26:40and the RAM is flagged as faulty.
26:43Lastly, all of memory is cleared to set up
26:46for the screen that displays the result of the tests.
26:49First, the work RAM is cleared out to all zeros.
26:53Then the video RAM is cleared out to all $40,
26:57which is just a completely blank tile.
27:00Then the color RAM is cleared out to all 15,
27:04which is the default blue and white color palette.
27:07I'll skip over how the test result screen is displayed,
27:10because we'll look at that in the next example.
27:15Super Pac-Man's memory
27:16tests are significantly simpler, but not as robust.
27:21Additionally, the hardware in this machine is completely different.
27:24Pac-Man had its Z-80 CPU,
27:27six ROM chips, six RAM chips,
27:30and an interface for all of the I/O, such as the buttons and coin boxes.
27:35On the
27:36other hand, Super Pac-Man has a pair of co-processors.
27:39The main CPU can access video RAM, as well as three work RAM chips.
27:45It can also access two larger program ROM chips.
27:49The sub CPU only has access to a smaller program ROM,
27:53as well as a shared RAM chip dedicated for audio.
27:57There are also two character ROM chips on board,
27:59one for all of the graphics for the tiles, and one
28:02for all of the graphics for the moving sprites.
28:06And finally, there are two I/O microcontrollers
28:09that interface together with the main CPU through a smaller RAM chip.
28:14Due to the limited accessibility, both CPUs
28:17have to do their own self checks on what they can reach.
28:20Let's look at the code now.
28:23We'll start with the
28:24main CPU, since the sub CPU initially starts
28:27dormant and needs to be initialized by the main CPU anyway.
28:31Both co-CPUs are Motorola MC6809Es,
28:36so the assembly code here looks quite a bit different.
28:40The first thing on its checklist
28:41is to do a memory test on the four main RAM chips.
28:45That's done here,
28:46and here's what the pseudocode would look like for this block.
28:50Instead of using a pseudorandom sequence of numbers like Pac-Man did,
28:54Super Pac-Man sources its number sequence
28:57by just using the ROM itself.
28:59It just grabs the first 8000 bytes of one of the ROM chips
29:03and dumps it all into RAM,
29:05and then reads it back to make sure it matches.
29:08This is done 16 times, each time a different number
29:12is added to the value from ROM before writing or reading it.
29:16This way, each byte in memory gets at least 16 different
29:20values written to it.
29:22Any address that fails
29:24one of these checks gets kept track of right here.
29:27The code path here is a little weird,
29:29because even if all of the tests pass, this code still runs.
29:33It's just that the chip that gets marked as the failed chip
29:36is the fifth one, which hasn't even been checked yet.
29:39It takes care of that later, though.
29:42Also, Super Pac-Man stores the chip
29:44number in terms of its graphics tile indices,
29:47where the tile that displays a one is tile $31, a tile
29:52with two is tile $32, and so on, which is where that comes from.
29:57In my pseudocode, I just keep track of the chip number
29:59itself from 0, 1, and so on.
30:03The next thing in the checklist is to wipe out all the memory
30:06that just got filled, and it does this similar to Pac-Man.
30:10Video RAM gets all $20, color
30:13RAM gets all 2s, and work RAM gets zeroed out.
30:18Once that
30:18is done, the game quickly writes a few strings to the screen,
30:21which serve as the template to the self-test screen.
30:25This table here has each of the strings.
30:27They start with the video RAM address to start drawing the string,
30:31followed by each character to draw in order.
30:34The strings are null terminated and the table is as well.
30:39Here's where it checks for which RAM chip failed.
30:42If none of the chips failed, this will be reporting the fifth chip
30:45as bad, which we know can't be the case yet.
30:48So that's the cue to keep going forward...
30:50which is the exact chip that gets tested next.
30:54This test is very similar to the first, in that ROM
30:57is dumped into the RAM to fill all $3C0 bytes.
31:01However, these two chips are smaller, and just like in Pac-Man,
31:05one holds the upper four bits
31:06of each memory location and one holds the lower four bits.
31:10So the main difference in the test is that when a failure is detected,
31:14the game XORs the original ROM value
31:18with the value it read back from the faulty RAM address.
31:21This results in the bits only being set where they differ.
31:26It can then determine which chip is the bad one based on
31:29which bits are flipped.
31:32Next on the checklist is the small amount of RAM
31:35in the buffer chip between the main CPU and I/O chips.
31:39This is done not unlike before, just making sure
31:42to ignore the upper four bits of data, since the I/O
31:45buffer chip only outputs four bits at each location.
31:50Up next is the ROM checksums.
31:52The main CPU can only see the two big ROM chips,
31:56so those are checked for here.
31:58This is pretty standard as before, just summing up
32:01all of the bytes on each chip into a single 8-bit value.
32:05Super Pac-Man stores a more proper checksum
32:08and checksum complement together in the second ROM chip.
32:11(All of this code seen here is in the second ROM chip.)
32:15If you add up all of the bytes in the ROM, you'll get the checksum.
32:19But if you store the checksum in the ROM itself, then
32:23now you have to account for the extra byte, which increases the checksum.
32:27To prevent this self-reference, the checksum’s complement
32:30is stored next to the checksum.
32:32The complement is usually just whatever value
32:35when added to the checksum equals zero.
32:38Though Super Pac-Man uses a checksum of $66
32:42and a complement of $28 for some reason.
32:45It still solves the self-reference problems though.
32:49A complement wasn't included for the first ROM chip
32:52because its checksum was stored on the second chip,
32:55so there's no self-reference in the first place.
32:58If either of the checksums don't add up, then a bad
33:01ROM is reported.
33:05Okay, next on the list is to start up the sub CPU.
33:08This is done by writing to the address $500B here.
33:13The two processors run in parallel,
33:16which would normally make our exploration here
33:18a little more difficult,
33:19but thankfully the two processors basically
33:22wait for each other to finish here because the game wants to make sure
33:25everything is good to go before starting everything up for good.
33:30Once the main CPU fires up the sub CPU,
33:33it essentially sticks itself in a really long loop.
33:36Right before starting the sub CPU, it wrote the value $00
33:40to the shared memory address $4040 here, which is a 16-bit write.
33:46So address $4041 also gets set to $00.
33:51This is the byte that the main CPU will be listening
33:54to for the sub CPU to report its results.
33:58As long as that byte remains zero, it will hang in this loop for a while.
34:03It isn't forever though, and if time runs out,
34:05the main CPU
34:06will assume that something went wrong with the sub CPU’s program
34:10and report that the third, smaller ROM chip went bad.
34:15Let's look at the sub CPU's tests real quick.
34:18The first thing it does is test the two smaller RAM chips again.
34:23While these chips were already tested by the main CPU,
34:26these are this processor's main memory since
34:29it can't access the larger RAM chips, so it's worth trying it again.
34:34It's also using a different ROM chip to dump
34:36data into, so it's a bit more robust too.
34:40It does make sure to skip testing the two bytes that the main
34:42CPU is listening for, as to not ruin everything.
34:46If there is a failure, then the bad chip is determined
34:49just as before, and the result is placed into address $4040,
34:54which is the one that the main CPU isn't watching yet.
34:57This will hold the RAM result, but the sub CPU will go ahead
35:01and test the ROM while it's at it.
35:04This is done just like
35:05before with a checksum, complement, and everything.
35:08This code is structured like a loop since there's actually available
35:12hardware for the sub CPU to have access to another ROM chip,
35:16but it wasn't necessary for Super Pac-Man, and it was easier
35:19just to reduce the loop count by one than to restructure the code here.
35:24If all of the tests passed, then the special number
35:27$4F is used as a success value.
35:30The result of this test is then written to address $4041,
35:35which will trigger the main CPU to continue onward with its tests.
35:39After that, the sub CPU then goes into its own waiting loop,
35:43waiting for the main CPU to erase the result that it just wrote.
35:48Once that happens, the sub CPU will then clear out the RAM
35:51it has access to, and finally, it will wait again for the main
35:55CPU to tell it what to do next by monitoring the value at
35:58memory address $40FB here.
36:04That's it for the sub
36:05CPU, so let's jump back to the main CPU's code.
36:09After hearing the response from the sub CPU,
36:12it will check for failures and report them if necessary.
36:15Otherwise, if both values are $4F,
36:18then the game continues onward with more code.
36:21These lines here write the letters “OK” next to the words
36:25“ROM” and “RAM,”
36:26and if there were any failures at this point,
36:28the game reports it by writing the number of the chip next to either
36:32the word “ROM” or “RAM” as necessary.
36:35The bigger RAM chips are numbered 1 through 4,
36:38the smaller shared RAM are 5 and 6, and the I/O RAM is number 7.
36:43The big ROM chips are numbered 1 and 2, and the smaller one is number 3.
36:49Now there's actually one more test that happens,
36:52but it's a little bit later after the game sets up
36:55a lot more of the code structure for the entire game.
36:58Just like how the main CPU started up the sub CPU,
37:02it has to start up the special I/O chips as well.
37:06It was able to test the I/O buffer RAM without any problems,
37:09because those I/O chips hadn't been initialized yet.
37:12In the process of starting up the game, those chips eventually
37:15get started and start utilizing that buffer.
37:18Each one uses 16 4-bit nybbles of the buffer.
37:23They utilize it in different ways depending on what mode they're in.
37:27For example, they can monitor the player's input, listen
37:31for newly inserted coins, or output the state of the DIP switches.
37:35However, when they first start up, they go into a startup mode.
37:39In this mode, the I/O chips will add up the last seven nybbles
37:43it has access to and then put the result in the first two nybbles.
37:48The upper four bits in the first spot and the lower four
37:51bits in the next spot.
37:53In Super Pac-Man,
37:54the chips will also first initialize the last seven nybbles
37:59to all be 15.
38:02This means that the first two nybbles will end up being 6 and 9.
38:0615 times 7 is 105, which in hex is $69.
38:11The main CPU can ensure the integrity of the I/O
38:14chips themselves by verifying that this sum is correct.
38:19Here's the code that does that.
38:22This is tied in with more general code,
38:24since these I/O processes are run every frame during gameplay.
38:28It's just that this startup mode is only run at the very beginning
38:31of course.
38:33The location of the I/O buffer
38:35memory to the main CPU is at $4800 for the first I/O chip,
38:39and $4810 for the second.
38:42So this routine is run once for each chip.
38:46This bit of code just figures out
38:48which mode the I/O chip is in and runs the appropriate routine.
38:52The startup mode is mode eight.
38:55This is some more convoluted assembly math, but it's essentially
38:58taking the negative of the calculated sum in the first two nybbles,
39:03and then adding that back together with the final seven nybbles.
39:06Together, it should all equal zero.
39:09If it does, there's no problem.
39:11But if it doesn't add up, then the game immediately
39:14reports the chip number on the self-test screen.
39:17I like this code because theoretically it can run at any time.
39:21So if the I/O chip found itself in the startup mode again somehow
39:26and was also faulty, a random number 1 or 2
39:29would show up on screen and the game would lock up like this.
39:36Thank you so much for watching.
39:38I want to make another huge shout out to all of my YouTube
39:41members and Patreon supporters for all of the help.
39:45Everyone scrolling by your screen right now plays a big part
39:48into making this channel possible,
39:49and allows me to keep doing what I like doing.
39:52And if you're just a viewer, making it all the way to the end here
39:55also helps out a lot just due to the algorithm and everything.
39:58So special shout out to you as well!.
40:01Members and patrons can also get early access
40:04to videos, as well as some behind the scenes content.
40:07Supporting either on Patreon or YouTube gets you the same stuff,
40:11so you can pick whichever one is more convenient for you
40:13if you'd like to chip in a bit.
40:15Thank you so much and see you next time!

About this transcript

This page contains the full transcript of Why Do Arcade Games Boot Up Like This? by Retro Game Mechanics Explained, generated from the public captions YouTube serves with the video. The transcript has 6,802 words across 738 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.