@@c0mpu73rguy My university still required 2 Cobol courses for my major back in the early 2010s. The way our professor wanted us to work was absolutely archaic. We were expected to telnet onto some school server and write our code their and execute it. I ended up 'cheating' a bit when I saw I could access my directly over FTP. Ended up using an open source Cobol to C compiler on my laptop and writing all my code there before transferring it to the server for submission. Even with the benefits of a modern editor it still took me three nights for each assignment. Day 1: Input & Output formatting, Day 2: Logic, Day 3: Debugging. Gin was the only thing that got me through those two classes, a good mental anesthetic.
@Sydney Bean I didn't actually think COBOL was a difficult language, and I do respect the language for doing some things extremely well. I just hated working with it because it was so tedious to write and how verbose it is. Ultimately I did quite well in those courses. I don't recall what the editor on the server was, but the entire system was old as evident by it only accepting telnet and not SSH. I mostly just wanted syntax highlighting, better compiler errors and to move around the program easier. I think I just used Gedit with the terminal plugin and GnuCobol. I don't do any programming these days, just scripting stuff for my job in infosec.
@@Tithis probably because it was a basic school test/learning environment, they didn’t want to deal with SSH keys and user mgmt for every student every semester, or confuse you by throwing that at you on top of the COBOL stuff. (Even though in the real world, you have to learn multiple things on the fly on a regular basis lol)
There's a great quote from the lead coder behind crash bandicoot. "The manual gives you a number. But to really know, you have to write test code and put it through it's paces." He didn't just take what he was given, but experimented and worked out the limits for himself. A different quote from Jamie Hyneman. "You should never just assume something. You need to actually test it."
Gotta love undocumented opcodes! These things are also the bane of existence of emulator developers and are used in demos and copy protection. If this is what I think it is, it's a hybrid opcode that exists just because of the way the bits work, and its behavior is technically undefined but on real hardware would always be the same. If that's the case, they probably codified it, but forgot to put it in the manual.
2:25 "Operation commands can execute these four types of commands concurrently." The Sega docs do explicitly say types. Although, they probably mean 'in parallel' rather than 'concurrently'.
I'm just glad that copying and pasting code that isn't fully understood isn't a new thing. Even when you are right up against the hardware programming assembly instructions
If you look at the definition for "MOV MUL,P", you'll see it's 010 and no data bits. (That is, 010---, as opposed to 100XXX for "MOV[s],X" and 011xxx for "MOV[s],P"). It's fairly obvious you can't combine "MOV[s],X" and "MOV[s],P" as they would require different data bits, and you probably can't combine "MOV MUL,P" and "MOV[s],P" as they both work on the P register and would conflict there, but there's no reason why "MOV[s],X" and "MOV MUL,P" can't be executed at the same time, and that would be something desirable to have happen simultaneously, as that combination of actions would be quite common to need happen. So it seems likely they quietly implemented a "MOV[s],X AND MOV MUL,P" command as 110xxx, and didn't bother documenting it. And probably the same with the Y register commands also. It also says "Can execute these four types of commands concurrently", but it doesn't say it can only execute one of each type. It's possibly a translation issue, or poor documentation on Sega's behalf (which is why they also distributed example code for developers)
You may be onto something, still, even if opcodes are syntactically similar, that doesn't mean they belong to the same opcode table, as these are usually grouped by segments. A MOV load store opcode makes use of data lines, as opposed as a MOV Inmediate opcode which uses internal registers, or even ALU unit.
Based on typical hardware design practices of the time, as well as the pattern of instruction encodings, combining MOV [s], X and MOV [s], P (binary 111xyz) will result in MDyz (e.g. yz = 10: MD2) being loaded into both P and RX, and CTyz (e.g. CT2) being incremented if X = 1.
DSPs also like to split cycles (maybe even use multi-phase clocks). So it could be possible that this DSP has some logic wired to upper half of the clock, and other to lower one (or rising/falling clock edges). Binary layout of the commands suggests that there's almost no instruction decoding, only activating parts of the logic via bits in command register (like in good old mainframes). So if your commands have non-overlapping bits active, the CPU could use non-overlapping logic to execute them, and in predictable order. BTW, this is very similar to poking around 6502's 'illegal' commands.
Blizzard, Anno Domini 2020: "we wanted to build a main menu in JS so we packaged the entire binary for Chromium. You're not playing our decade old game on a legacy system, right?"
@@drstrangecoin6050 This was a... believe it or not, necessary change. Because previously, they used to package Scaleform, which is a clone of Adobe Flash runtime; but the development tools, due to demise of Flash, are no longer available! Same fate befell its competitor Iggy. There just aren't good robust battle-tested game UI tools available with the demise of Scaleform that don't involve HTML5.
The question I would have is that it looks like assembler for the DSP is specialized just for it, so if I wanted to homebrew with the DSP, is there an assembler that knows about it or a dev tool chain available for the Saturn?
@@BrianBates128 I don't think there is a currently usable assembler available. You can just read the SCU hardware manual and take the instruction bit patterns and define them into a bunch of constants and macros, and just OR them together in your program to assemble the code. This should be the lowest effort path, there's only a handful instructions anyway, it's fixed size.
I saw that vid on Coding Secrets and Seeing Sonic R again made me thought of "Can you feel the Sunshine?" So I felt I had to listen to it and it brightened up my day!
Ben Eater might have the answer to this in his rather lengthy but enormously infotaining 8 bit breadboard computer series (here on UA-cam), specifically when he creates and "eeprom-hard-wires" the control logic signals. These two bits in the DSP's micro-code seem to be both hard-wired to represent a data-forwarding action in an "Output from A, Store to B" fashion, and since two distinct units are involved (per "110" command bit pair), they operate concurrently and without interfering with each other. This is *just my guess* at the inner workings of the system.
possible that the DSP had a revision change after the documentation release and the documentation was never updated? I've had issues come up and i get a hold of hardware devs who where like..."uhm yeah.... gimme a sec...*shuffles papers....oh yeah we changed some things on the ACTUAL release, just BLA BLA BLA....voila, an undocumented function.
Probably just communication friction between technical writers and the engineering team. Same reason you don't ever want to read docs written by engineers. The writer must have tried his best to make sense of the chip, and this is about the best he got.
@@SianaGearz Do you have any examples of docs written by engineers? This seems like it was written directly by the engineers to me (and is pretty par for the course - see TI's C66x docs).
@@juliewinchester1488 I don't think it was supposed to connect to the internet, just enable network play over a local network. It could either use the serial port on the back of Model 1 Megadrives, or communicate through the second controller port like Zero Tolerance did.
The documentation is right... from a certain point of view Those DSP control words are closer to horizontal microcode than typical ISAs. From the hardware engineer's perspective the X Bus Control is one instruction that can link multiple units together. It was just cleaner to express that at the ASM layer as two separate instructions. Same for the y bus control. I agree that the did a disservice by not making it clear in the docs. You can see similar shenanigans with the PDP/8's OPR instruction which uses the immediate value as a ucode control word and can execute more than one pseudo op at once because of it.
Did Traveler's Tales ever buy development kits for more obscure consoles (3do, neo geo, jaguar, Pippin)? Was there any draw to develop on them or was it always the plan to stick with what was selling well?
Wanted to tell you that I REALLY enjoyed this game, still have the soundtracks in my playlist, and (since I had it on PC) once tried (and failed) to improve the textures in the game. Great work all around for a very fun game!
it could've been a happy accident with the design of the DSP. Usually all hardware from this era was all hard coded (because there was no such thing as system drivers etc) so usually it would need to have either 100 OR 010, if the 2nd bit is set making 110 then it'd be like "this doesn't match with what I was programmed with, no" but it seems the DSP was programmed with the awareness of individual bits, so when the first bit in the command is set it will do the command regardless (this makes sense seeing as a 0 usually represents a gap in the data)
Yeah usually the hardware from this era was hard coded, it was the most cost-effective way of doing things at scale. The Nintendo 64 RSP did use microcode which was a revolution at the time, but may not have been the best idea. If they had instead used that die space for more than 4K of texture cache or a texture decompression routine to save cartridge ROM space... Well hindsight is a wonderful thing eh :)
@@sl9sl9 that's actually some really interesting bits of history. This is why I love this stuff and the community surrounding it, so much insight of frankly impressive feats of engineering and programming that would be trivial today
Actually the Saturn did have a Sega-provided sound driver for the 68k CPU that controls the sound subsystem and is MIDI compliant. There are also (vintage) Macintosh tools from Sega for designing sounds and converting MIDI files into music sequence data. I’m working on a custom sound driver for Saturn right now :)
Luckily the diagram of the DSP core pipeline gives us the answers. RX has an enable, controlled by bit 25 (clear = don't load, set = load from X). The P register (split into PL and PH) also has a multiplexer and enable bit. Bit 24 is the enable (set = load multiplier output or X, clear = don't load). Bit 23 operates the P multiplexer (clear = multiplier output -> {PH, PL}, set = X -> PL, sign extend PL into PH) Bits 21-20 of the X bus command determine what is written to the X bus (for a lower two bits equivalent to n, memory MDn will be loaded). Bit 22 enables the increment of the CTx register referenced by bits 21-20. The Y bus commands are a bit simpler. Bit 19 enables the RY load from the Y bus, while bits 18-17 determine the AC register's operation (00 = don't load, 01 = clear, 10 = load from ALU's Q output, 11 = load from Y bus). Bits 15-14 determine the MDy to load onto the Y bus, and bit 16 controls the increment on the CTy register. This means that the real limitation in one of these instruction packets is that RX and P cannot be loaded from two different MDx banks on the same clock cycle, RY and AC cannot be loaded from two different MDy banks on the same clock cycle, and one MDz bank cannot load two different data values to the X and Y buses on the same cycle (although you can transfer the same data to both buses). Theoretically, you should be able to use bits 22-20 and 16-14 to increment one or two of the CTx registers without loading any data. Why you would want to do this, I don't know, but it should be possible. Also worthy of note is that a code of 10100 in bits 12-8 switches the RX multiplexer to read from the D1 bus instead of the X bus, while a code of 10101 switches the P multiplexer to read from the D1 bus instead of the X bus (bits 11-8 select the target register, while bit 12 enables the target register and its multiplexer). It's unclear what would happen if bit 12 was not set but bits 11-8 were chosing a target register of RX or P.
I can explain the 6 vs. 4 instruction conundrum. If you look at the overall architectural diagram at 1:08, there is a dedicated 48bit bus from the MULtiplier to the P register. The X bus only needs to be used for transferring data from one of the MD* banks to the X register. So even though moving the multiplication result to the P register is an "X bus command" it doesn't actually need to use the X bus. So Sega basically just added an undocumented X bus opcode 0x6 (110) that does MOV [s], X AND MOV MUL, P at the same time. They wrote it out as 6 instructions instead of 4 for human readability reasons.
This reminds me of the MMO furcadia that has its own level making and scripting language. For over a decade people begged for loops, but the programmer was worried about people lagging the game etc. Well there was a command 'set countdown timer # to go off in # seconds' and 'whenever countdown timer # goes off' well eventually some really smart dude realized, hey, since the timers execute in order, we can usea variable for the timer #, start at one, then increment the variable at the end of block we want to loop, we will be allowed 100 loops per second. the functionality was there all along and it just took someone to realize it!
Probably exactly what you think, that bit flips that line at the hardware level It's common for DSP's to work that way, they are essentially a pile of functional units hooked to a pile of busses. The 'instructions' mostly control which which unit attaches to which bus and behave more like the scroll on a player piano than conventional instructions; often incapable of branching, much like the piano The tradeoff for the poor facsimile of an instruction set is raw power, it can only do one thing to your data but it can do it *FAST*
your can easily do the arithmetic commands, no problem, in parallel at the exact same time. one example is if you ever want to move "010" when no data bits are set, you can,(MUL, P" as in actually "010" not 010Xxx) , while also doing "MOV MUL, X" no problem. this is supported by the dsp IIRC..
I watched a video that certain instructions that were available for the N64 (I think) were hidden from official documentation and were only found out by studios reverse engineering games
There's a talk titled "Breaking the x86 Instruction Set" by Christopher Domas. He invented a way to find hidden, undocumented (or incorrectly documented) x86 instructions. There's a lot of them.
Not the first time assembly programmers would combine opcodes. I know for some 6502-alikes that combining opcodes was something studious programmers would exploit (and it was important to know which ones wouldn't just crash the system)
I’ve got a few theories. 1: the hardware breaks the commands apart to multiple cycles. 2: it wasn’t documented properly by SEGA 3: the translators messed up.
I can't understand code at all, but I basically got one of three possibilities: A. "Sega had no idea how to make the most of the Saturn's hardware." B. "Sega thought it would be a great idea to hold back some of the system's power so that their games would be superior to everyone else's." or C. "Blame Sega's translators." Because we're talking about Sega of Japan, each is equally likely.
TL,DR: The chips had a command that wasn't in the documentation but was in the sample code that allowed them to do a input and output in the same instruction.
I actually just found this video yesterday and subscribed to the channel and today it's reloaded on a channel I was already subscribed to. I am confusion.
Not sure what you can do but Lego Dimensions was one of my favorite TT games! (Next to Muppet RaceMania of course) Anything about those two games would be cool!
Looking at the binary code, it seems like hardware reads the instructions as bitmasks. The first bit represents the command which writes data to X, and the next two bits commands writing data to P. Since these are writing data to different registers, there is no problem to do these instructions in parallel, so the hardware is wired in such a way that the first bit and the next two bits are independent - no need to do unnecessary checks slowing down the computation. This also partially explains why the three commands have bit representations 100, 010 and 011 - the last two of these instructions are writing data to P, so they cannot be performed in parallel. I guess the second bit tells whether we write data to P, and the third bit tells where we get this data, directly from memory (0) or from the result of multiplication (1), and all this is implemented in hardware. If this is true, then the command x01, although not documented, should behave equivalently to x00, since the second bit prevents writing data to P altogether. I'd love to see this tested, btw ;) As how the machine code is compiled to binary code, I have also a guess. Each command is a 32-bit string. The compiler parses the instructions, turns them into binary and then XORs (or ORs) them together to combine. In this way, the compiler doesn't need to keep track of which commands are performed in one line, so in particular no need to count how many commands there are. This would explain why six commands in one line compiles, and even suggests that technically any number of (conflicting) commands in one line would compile, although the code then doesn't do what is written. This would also be fun to see tested.
"Four types of commands concurrently." i.e. not a strict quantity limit per-type. It is just saying there are four types of commands executed concurrently. If the demo code you were given is correct, then six may be the upper-bound on the number of instructions per-type that can be executed concurrently in a single cycle on the DSP. Your code works... because it was designed for six instructions. Honestly, if that technical specification of yours doesn't tell you the exact lower and upper bounds of every single instruction, then it wasn't written very well because that's the whole purpose of a technical specification in the first place: to document where things begin and end in a(n inadvertently convoluted) system!
It makes sense from an instruction set point of view, at least. A lot of simpler processors have undefined opcodes of one sort or another that work in practice (e.g. on the 6502), and having the instruction decode directly drive the bus enables I could definitely see. An interesting question would be what happens if you do e.g. MOV MC0, Y MOV MC1 Y, which "should" cause bus contention if I'm reading those bus connections correctly (both connected to the Y bus.) What does the third bit of that triplet do?
Check the comments on Coding Secrets, the whole issue is due to an error in the documentation... even the example code from Sega shipped with the SDK worked this way, correctly
Im a game developer and I have no fucking idea what are you talking about. Gamedev nowadays is nothing compared to what it used to be back in the day. As always great video.
It is four types of control commands, that is technically correct. As to why some commands aren't listed, I have no idea. Perhaps something like "these commands can be executed at the same time" got lost somewhere, somehow. X Bus control controls RX, PL and PH. Y Bus control controls RY, ACL and ACH. I was going to suggest that perhaps in the earlier iterations, X and Y buses only controlled RX and RY. But that isn't the case, looking at the data diagram. Maybe it was the case before, but they realized they can do more at the same cycle, but while revising the document, they forgot to add the aforementioned parts. The base document (that explains control commands) feels older; it says 1994 SEGA on the 2nd page, even though on the 1st page the date is shown as 1995, and it is the third edition. Other documents that have examples in them seem to be newer somehow; they say 1994-1995 SEGA on the 2nd page, and the date on the 1st page is 1994 this time. In any case, cutting a whole cycle and instead executing two-in-one is neat!
I’m learning Saturn dev right now. The manuals collectively are thousands of pages of documentation and some of the utility tool screenshots are still in Japanese. It’s a lot to take in.
Hey Jon, do you have anything archived from Muppet Racemania for the PS1? Would love to see things that didn't make the final game and why there are differences between the US and European versions.
Having written: bitbucket.org/Coto88/armv4core/src/master/ I think I can relate to a possible reason: The opcode translation unit in the processor (the opcode table translation by index) never accounted 2 sets of instructions each, but just either of the left column or the right column separately. This means, sort of like a if(OPCODEREAD AND OPCODE1) if(OPCODEREAD AND OPCODE2) rather than switch(OPCODEREAD){ CASE(OPCODE1)... CASE(OPCODE2)... CASE(OPCODE3)... CASE(OPCODE4)...} If we look at ARMv4t processors, ARM mode, ALU opcodes are packed into the barrel shifter registers (the ALU unit), an extension of the ARM processor. By doing that, it's possible to repurpose upcoming opcodes to use new uses of the ALU unit... something Saturn DSP didn't quite do, or simply didn't care to.
I would guess that what you call instructions are not really instructions (the decoding part is missing or it is extremely simple) but they are almost directly the internal control lines the chip is using to handle the internal buses.
FYI the link to your secondary channel is borked somehow. It resolves as: ua-cam.com/users/www.ua-cam.com/users/codingsecrets , throwing an understandable error.
When I traded everything in a decade ago they only wanted games that still had their original cases. So I still have a few they didnt want, and now I'm interested in Saturn again. a great system. Good thing I lost my Sonic R case or they woulda took it. Hehe Edit: today they'd take anything Saturn case or no case. But 10 years ago it was a bother.
Is this a reupload? Not that it's a re-examination of an older video, but that it's a complete reupload of this same video you uploaded recently. I distinctly remember watching this when I was really tired and couldn't comprehend it, so I gave up. That was at least a week ago, I think. So either it was a dream (in which it made up specific comments that I can't find to the tune of "'here it is in binary' me: 'oh, ok, thanks'") and I'm truly clairvoyant or this is just more evidence that the simulation is broken.
Also, I think the difference is explained in the manual showing "100xxx" for the X-Bus Control. Are those xxx's mentioned in another section of the manual? Are those xxx bits to be filled in with other commands, as you do have in the binary line you've extracted, 2 different bit sets in the 2nd half of each X-Bus and Y-Bus Control block? If the xxx are filled in with bits used to denote the end of the X-Bus and Y-Bus Control blocks then you'd expect them to be the same but the 2nd set for X-Bus is 101 and the 2nd set for Y-Bus is 100. I wonder if the xxx section uses a different set of bit combinations so it understands the distinction between the two. Maybe they're different bit combinations so you can't screw up the math doing the same process twice and, maybe, so you don't accidentally move something out of a block without replacing it with something else for the next clock cycle.
I think your idea is correct. If MOV moves are supposed to be mutually exclusive it would only need 2 bits to specify instead of 3 bits, according to ST-97-R5-072694 . This kind of stuff does happen. At least you didn't do a Halt and Catch Fire instruction.
I write operating system code in assembler for mainframes and and I just started a new job to work on an mainframe emulator and I can tell you this kind of stuff happens more than you think. Mainframe Principle of Operations is written at the end, by some really tired guy after working for too long, probably in another language, while his wife is leaving him.
I don't know about control tweaks but one of the config files for the PC ports should unlock the draw distance. I think the specific value is on PC Gaming Wiki, and the mod loader might be able to adjust it
Is it true that developers made their game in the past based on composite outputs ? You guys as developers what do you think about this ? Did you test your game back then on composite or RGB monitors ? Do you think you art were made to be seen on composite or RGB ? What is be real true way to enjoy the art of retro games the way they were intended ? CRT ? HDTV ?
they don't say that it can't make 6 instructions at a time, it says that it can do 4 type of instructions at a time. I think it means that it's not limited at 4 instruction at a time if there's only 4 or less type of instruction
I'm already subbed to Coding Secrets.. but FYI the link in the description doesn't work for some reason.. youtube has mangled it. Maybe prefix with https?
Hello wondering were the arena beasts in episode 2 of lego star wars ever planned like boga in ep3? If so do you have any visual material you can show us?
The only thing that could be is concation. Basically the assembler combines the 2 commands into one command and the hardware interprets as combo command and then sets both registers at the same time. Now if you were setting the same register let's say x register this would lead to an interesting problem because the dsp is a parallel unit. So which value would set if this scenario would happen?
The moment I saw that one command was 100 and the other was 010, I said to myself "Maybe 110 is moving both at the same time?" The thing is I have NO idea how to code or even what GameHut is talking about. From math I know a little binary, and assumed if the numbers weren't used, then it'd free to do it. But this leaves a question: If the code specifies that one "bus" must be used to do two commands at the same exact time...how does it do it regardless if something like 110 signals for it to do it? Does it utilize something else to achieve this?
If you get the chance, could you take a look at the special stages from a sonic fangame called Sonic Triple Trouble 16-bit? It's a game that tries to emulate sega genesis hardware as close as possible and has faux-3d special stages with an artificially lowered frame rate. Considering how smooth the 3D Blast special stages were, I was wondering if it could run at a decent frame rate on an actual sega genesis.
Can you talk about Sega CD architecture and limits a little? Do i understand this correctly - you can do all of the graphics/code data on Genesis gpu with all of the soundtrack/sound been done in CD cpu. So the resulting game will only use loading for music, and all graphics/code data will be avaible at once, like on Genesis game cart ? It looks like Ecco the Dolphin does nearly exactly this, but i can be wrong.
Interesting video! Don't you love it when hardware manuals don't include all options? (: (I've heard that this happened a lot!) Edit: Aha! Looks like you misread it. Maybe you didn't back in the day?
Hey Jon, will there ever be a chance that you might cover something on the Bug’s Life game from 1998 on the PS1? I just replayed it for reliving my childhood’s sake and I think it’s better than people gave it credit for. Cheers from NYC! :)
Can we please recuse jazz without another incident like ceber 5. (Can you please show us the hoover dam decepticon campaign prototype on the ps2 and ps3).
"my code works and I don't know why, so I didn't question it'
Cobol in a nutshell. When it works, you never know why -.-'
@@c0mpu73rguy My university still required 2 Cobol courses for my major back in the early 2010s.
The way our professor wanted us to work was absolutely archaic. We were expected to telnet onto some school server and write our code their and execute it. I ended up 'cheating' a bit when I saw I could access my directly over FTP. Ended up using an open source Cobol to C compiler on my laptop and writing all my code there before transferring it to the server for submission.
Even with the benefits of a modern editor it still took me three nights for each assignment. Day 1: Input & Output formatting, Day 2: Logic, Day 3: Debugging. Gin was the only thing that got me through those two classes, a good mental anesthetic.
@Sydney Bean I didn't actually think COBOL was a difficult language, and I do respect the language for doing some things extremely well. I just hated working with it because it was so tedious to write and how verbose it is. Ultimately I did quite well in those courses.
I don't recall what the editor on the server was, but the entire system was old as evident by it only accepting telnet and not SSH. I mostly just wanted syntax highlighting, better compiler errors and to move around the program easier. I think I just used Gedit with the terminal plugin and GnuCobol. I don't do any programming these days, just scripting stuff for my job in infosec.
@@Tithis probably because it was a basic school test/learning environment, they didn’t want to deal with SSH keys and user mgmt for every student every semester, or confuse you by throwing that at you on top of the COBOL stuff. (Even though in the real world, you have to learn multiple things on the fly on a regular basis lol)
I feel that deep in my bones.
There's a great quote from the lead coder behind crash bandicoot. "The manual gives you a number. But to really know, you have to write test code and put it through it's paces." He didn't just take what he was given, but experimented and worked out the limits for himself. A different quote from Jamie Hyneman. "You should never just assume something. You need to actually test it."
Gotta love undocumented opcodes! These things are also the bane of existence of emulator developers and are used in demos and copy protection. If this is what I think it is, it's a hybrid opcode that exists just because of the way the bits work, and its behavior is technically undefined but on real hardware would always be the same. If that's the case, they probably codified it, but forgot to put it in the manual.
A typo maybe.. not 4 instructions at a time, but 4 TYPES of instructions at a time? Sega was always goofy in their documentation.
Pretty sure you're right here. It says types. 6 instructions of 4 types is still 4 types.
@@sewid Technically they're only doing 4, 2 are just bunched up together
2:25 "Operation commands can execute these four types of commands concurrently." The Sega docs do explicitly say types. Although, they probably mean 'in parallel' rather than 'concurrently'.
translation error maybe, technical translations are always a problem.
I agree. They probably got the "meaning wires" crossed between Instruction and type. It IS just four types, but six instructions total.
I'm just glad that copying and pasting code that isn't fully understood isn't a new thing. Even when you are right up against the hardware programming assembly instructions
Dude this channel has been SO satisfying with the knowledge provided for a set of games I've always been fascinated with. Thank you.
If you look at the definition for "MOV MUL,P", you'll see it's 010 and no data bits. (That is, 010---, as opposed to 100XXX for "MOV[s],X" and 011xxx for "MOV[s],P"). It's fairly obvious you can't combine "MOV[s],X" and "MOV[s],P" as they would require different data bits, and you probably can't combine "MOV MUL,P" and "MOV[s],P" as they both work on the P register and would conflict there, but there's no reason why "MOV[s],X" and "MOV MUL,P" can't be executed at the same time, and that would be something desirable to have happen simultaneously, as that combination of actions would be quite common to need happen. So it seems likely they quietly implemented a "MOV[s],X AND MOV MUL,P" command as 110xxx, and didn't bother documenting it. And probably the same with the Y register commands also.
It also says "Can execute these four types of commands concurrently", but it doesn't say it can only execute one of each type. It's possibly a translation issue, or poor documentation on Sega's behalf (which is why they also distributed example code for developers)
You may be onto something, still, even if opcodes are syntactically similar, that doesn't mean they belong to the same opcode table, as these are usually grouped by segments. A MOV load store opcode makes use of data lines, as opposed as a MOV Inmediate opcode which uses internal registers, or even ALU unit.
Based on typical hardware design practices of the time, as well as the pattern of instruction encodings, combining MOV [s], X and MOV [s], P (binary 111xyz) will result in MDyz (e.g. yz = 10: MD2) being loaded into both P and RX, and CTyz (e.g. CT2) being incremented if X = 1.
DSPs also like to split cycles (maybe even use multi-phase clocks). So it could be possible that this DSP has some logic wired to upper half of the clock, and other to lower one (or rising/falling clock edges). Binary layout of the commands suggests that there's almost no instruction decoding, only activating parts of the logic via bits in command register (like in good old mainframes). So if your commands have non-overlapping bits active, the CPU could use non-overlapping logic to execute them, and in predictable order.
BTW, this is very similar to poking around 6502's 'illegal' commands.
"this is the 4 TYPES of commands that can be executed at the same time. ", yes, right there. Types of control-commands
I'm baffled, didn't I watch this this week already, but it's posted 19 minutes ago?!
As he said at the beginning, this was on his Coding Secrets Channel first, and any/all TT games vids from that channel will be here a week after that.
Deja vu, I've just been in this place before
I remember when I bought the "superjuegos" magazine and sonic r was in the top 10 best looking games of the year back in 1997
Yea it really did show what the Saturn could do in the right hands
Programmers now: Here's my electron app which gives you a bit of QOL, but eats 600mb RAM
Blizzard, Anno Domini 2020: "we wanted to build a main menu in JS so we packaged the entire binary for Chromium. You're not playing our decade old game on a legacy system, right?"
@@drstrangecoin6050 This was a... believe it or not, necessary change. Because previously, they used to package Scaleform, which is a clone of Adobe Flash runtime; but the development tools, due to demise of Flash, are no longer available! Same fate befell its competitor Iggy.
There just aren't good robust battle-tested game UI tools available with the demise of Scaleform that don't involve HTML5.
@@SianaGearz just rewrite the fucker in C# and save a gig of ram
@Sydney Bean I’m not tech savvy what does coding ui in a cross platform GUI toolkit mean?
Sounds like Discord, which is basically Chrome with a dedicated webpage hardcoded into it.
Turns out it was actually impossible, from now on Sonic R doesn't work
It was always impossible. Until now. Now we can finally play it. Our old memories are just implants.
Rip in rest
No great loss there.
Thanks for enabling the mandela effect, and placing us all in an alternate universe timeline... now i can't get sonic r to run lol.
@@CathodeRayKobold Are you that guy who ripped those DS sprites?
Hands down one of the most fascinating and talented coding and game design youtube channels/personalities.
Yeah it looks like the documentation was "correct-ish" but it's more of bitmask for what opcodes or commands run
The question I would have is that it looks like assembler for the DSP is specialized just for it, so if I wanted to homebrew with the DSP, is there an assembler that knows about it or a dev tool chain available for the Saturn?
@@BrianBates128 I'm pretty sure the Sega dev kits included a DSP assembler, as well as a simulator for debugging.
@@BrianBates128 I don't think there is a currently usable assembler available. You can just read the SCU hardware manual and take the instruction bit patterns and define them into a bunch of constants and macros, and just OR them together in your program to assemble the code. This should be the lowest effort path, there's only a handful instructions anyway, it's fixed size.
@@zyrobs sorry, I meant an open source one that I wouldn't have to feel bad for using if it was able to me found.
I saw that vid on Coding Secrets and Seeing Sonic R again made me thought of "Can you feel the Sunshine?"
So I felt I had to listen to it and it brightened up my day!
Ben Eater might have the answer to this in his rather lengthy but enormously infotaining 8 bit breadboard computer series (here on UA-cam), specifically when he creates and "eeprom-hard-wires" the control logic signals. These two bits in the DSP's micro-code seem to be both hard-wired to represent a data-forwarding action in an "Output from A, Store to B" fashion, and since two distinct units are involved (per "110" command bit pair), they operate concurrently and without interfering with each other. This is *just my guess* at the inner workings of the system.
I love these videos, and watched it on Coding Secrets too.
possible that the DSP had a revision change after the documentation release and the documentation was never updated? I've had issues come up and i get a hold of hardware devs who where like..."uhm yeah.... gimme a sec...*shuffles papers....oh yeah we changed some things on the ACTUAL release, just BLA BLA BLA....voila, an undocumented function.
Probably just communication friction between technical writers and the engineering team. Same reason you don't ever want to read docs written by engineers. The writer must have tried his best to make sense of the chip, and this is about the best he got.
@@SianaGearz Do you have any examples of docs written by engineers? This seems like it was written directly by the engineers to me (and is pretty par for the course - see TI's C66x docs).
You should continue the series about making a PUBG-style game on the Megadrive.
Honestly yes, that'd be awesome.
I still want to know the internet connection idea.
@@juliewinchester1488 I don't think it was supposed to connect to the internet, just enable network play over a local network. It could either use the serial port on the back of Model 1 Megadrives, or communicate through the second controller port like Zero Tolerance did.
@@Eddies_Bra-att-ha-grejer Ah, still would have been interesting either way.
@@juliewinchester1488 There was however a modem for the Megadrive that connected through the serial port that could have been used for online play.
Prob almost feasible since Pubg looks and plays like a 2005 game
Me: Sees 'confidential' plastered across the manual.
Me: "Ahh, today we're being naughty!" >:)
I'm planning on getting a saturn copy of this game soon to start my saturn collection, always good to see sonic content on here!
The documentation is right... from a certain point of view
Those DSP control words are closer to horizontal microcode than typical ISAs. From the hardware engineer's perspective the X Bus Control is one instruction that can link multiple units together. It was just cleaner to express that at the ASM layer as two separate instructions. Same for the y bus control. I agree that the did a disservice by not making it clear in the docs.
You can see similar shenanigans with the PDP/8's OPR instruction which uses the immediate value as a ucode control word and can execute more than one pseudo op at once because of it.
Did Traveler's Tales ever buy development kits for more obscure consoles (3do, neo geo, jaguar, Pippin)? Was there any draw to develop on them or was it always the plan to stick with what was selling well?
Didn't even know there was a coding secrets channel.... And there's so many videos to watch. I thought you never uploaded lol
the secret coding secrets channel.
Wanted to tell you that I REALLY enjoyed this game, still have the soundtracks in my playlist, and (since I had it on PC) once tried (and failed) to improve the textures in the game. Great work all around for a very fun game!
Jon Burton: **(uploads a new GameHut video)**
Me: “It’s been *84 Years....”*
it could've been a happy accident with the design of the DSP. Usually all hardware from this era was all hard coded (because there was no such thing as system drivers etc) so usually it would need to have either 100 OR 010, if the 2nd bit is set making 110 then it'd be like "this doesn't match with what I was programmed with, no" but it seems the DSP was programmed with the awareness of individual bits, so when the first bit in the command is set it will do the command regardless (this makes sense seeing as a 0 usually represents a gap in the data)
Yeah usually the hardware from this era was hard coded, it was the most cost-effective way of doing things at scale. The Nintendo 64 RSP did use microcode which was a revolution at the time, but may not have been the best idea. If they had instead used that die space for more than 4K of texture cache or a texture decompression routine to save cartridge ROM space... Well hindsight is a wonderful thing eh :)
@@sl9sl9 that's actually some really interesting bits of history. This is why I love this stuff and the community surrounding it, so much insight of frankly impressive feats of engineering and programming that would be trivial today
Actually the Saturn did have a Sega-provided sound driver for the 68k CPU that controls the sound subsystem and is MIDI compliant. There are also (vintage) Macintosh tools from Sega for designing sounds and converting MIDI files into music sequence data. I’m working on a custom sound driver for Saturn right now :)
Finally video about DSP I want to watch :P
Luckily the diagram of the DSP core pipeline gives us the answers. RX has an enable, controlled by bit 25 (clear = don't load, set = load from X).
The P register (split into PL and PH) also has a multiplexer and enable bit. Bit 24 is the enable (set = load multiplier output or X, clear = don't load). Bit 23 operates the P multiplexer (clear = multiplier output -> {PH, PL}, set = X -> PL, sign extend PL into PH)
Bits 21-20 of the X bus command determine what is written to the X bus (for a lower two bits equivalent to n, memory MDn will be loaded).
Bit 22 enables the increment of the CTx register referenced by bits 21-20.
The Y bus commands are a bit simpler. Bit 19 enables the RY load from the Y bus, while bits 18-17 determine the AC register's operation (00 = don't load, 01 = clear, 10 = load from ALU's Q output, 11 = load from Y bus). Bits 15-14 determine the MDy to load onto the Y bus, and bit 16 controls the increment on the CTy register.
This means that the real limitation in one of these instruction packets is that RX and P cannot be loaded from two different MDx banks on the same clock cycle, RY and AC cannot be loaded from two different MDy banks on the same clock cycle, and one MDz bank cannot load two different data values to the X and Y buses on the same cycle (although you can transfer the same data to both buses).
Theoretically, you should be able to use bits 22-20 and 16-14 to increment one or two of the CTx registers without loading any data. Why you would want to do this, I don't know, but it should be possible.
Also worthy of note is that a code of 10100 in bits 12-8 switches the RX multiplexer to read from the D1 bus instead of the X bus, while a code of 10101 switches the P multiplexer to read from the D1 bus instead of the X bus (bits 11-8 select the target register, while bit 12 enables the target register and its multiplexer). It's unclear what would happen if bit 12 was not set but bits 11-8 were chosing a target register of RX or P.
I can explain the 6 vs. 4 instruction conundrum.
If you look at the overall architectural diagram at 1:08, there is a dedicated 48bit bus from the MULtiplier to the P register. The X bus only needs to be used for transferring data from one of the MD* banks to the X register. So even though moving the multiplication result to the P register is an "X bus command" it doesn't actually need to use the X bus.
So Sega basically just added an undocumented X bus opcode 0x6 (110) that does MOV [s], X AND MOV MUL, P at the same time. They wrote it out as 6 instructions instead of 4 for human readability reasons.
This reminds me of the MMO furcadia that has its own level making and scripting language. For over a decade people begged for loops, but the programmer was worried about people lagging the game etc. Well there was a command 'set countdown timer # to go off in # seconds' and 'whenever countdown timer # goes off' well eventually some really smart dude realized, hey, since the timers execute in order, we can usea variable for the timer #, start at one, then increment the variable at the end of block we want to loop, we will be allowed 100 loops per second.
the functionality was there all along and it just took someone to realize it!
I already watched this on the other channel. Time to watch it again!
ILLEGAL INSTRUCTIONS! OH MY! You're going to Jail in register A.
Nice to see this reuploaded again!
Wow! Love these videos, I can only imagine what murky waters development was like back in the day
Totally lost me! I still enjoyed every second of it!
Probably exactly what you think, that bit flips that line at the hardware level
It's common for DSP's to work that way, they are essentially a pile of functional units hooked to a pile of busses. The 'instructions' mostly control which which unit attaches to which bus and behave more like the scroll on a player piano than conventional instructions; often incapable of branching, much like the piano
The tradeoff for the poor facsimile of an instruction set is raw power, it can only do one thing to your data but it can do it *FAST*
your can easily do the arithmetic commands, no problem, in parallel at the exact same time. one example is if you ever want to move "010" when no data bits are set, you can,(MUL, P" as in actually "010" not 010Xxx) , while also doing "MOV MUL, X" no problem. this is supported by the dsp IIRC..
I watched a video that certain instructions that were available for the N64 (I think) were hidden from official documentation and were only found out by studios reverse engineering games
There's a talk titled "Breaking the x86 Instruction Set" by Christopher Domas. He invented a way to find hidden, undocumented (or incorrectly documented) x86 instructions.
There's a lot of them.
Not the first time assembly programmers would combine opcodes. I know for some 6502-alikes that combining opcodes was something studious programmers would exploit (and it was important to know which ones wouldn't just crash the system)
well they certainly didn't do themselves any favours did they.
I’ve got a few theories.
1: the hardware breaks the commands apart to multiple cycles.
2: it wasn’t documented properly by SEGA
3: the translators messed up.
At least 2 and 3 for sure
Of course! It makes sense now. I totally understood everything you said, uh-huh. Yes sir.
**Cries in non-coder in the corner**
I can't understand code at all, but I basically got one of three possibilities: A. "Sega had no idea how to make the most of the Saturn's hardware." B. "Sega thought it would be a great idea to hold back some of the system's power so that their games would be superior to everyone else's." or C. "Blame Sega's translators."
Because we're talking about Sega of Japan, each is equally likely.
@@juststatedtheobvious9633 I'm inclined to agree. Sega was a clusterfudge of a company doing a clusterfudge of an operation at that time.
Honey wake up, GameHut uploaded a video on Sonic R
TL,DR: The chips had a command that wasn't in the documentation but was in the sample code that allowed them to do a input and output in the same instruction.
I actually just found this video yesterday and subscribed to the channel and today it's reloaded on a channel I was already subscribed to. I am confusion.
Not sure what you can do but Lego Dimensions was one of my favorite TT games! (Next to Muppet RaceMania of course) Anything about those two games would be cool!
I Didn't understand a thing , and i like it
this make me more impressed and appreciate older games more
I Became a computer engineer and it all make sense now
Really impressive !
The return of the king
Looking at the binary code, it seems like hardware reads the instructions as bitmasks. The first bit represents the command which writes data to X, and the next two bits commands writing data to P. Since these are writing data to different registers, there is no problem to do these instructions in parallel, so the hardware is wired in such a way that the first bit and the next two bits are independent - no need to do unnecessary checks slowing down the computation.
This also partially explains why the three commands have bit representations 100, 010 and 011 - the last two of these instructions are writing data to P, so they cannot be performed in parallel. I guess the second bit tells whether we write data to P, and the third bit tells where we get this data, directly from memory (0) or from the result of multiplication (1), and all this is implemented in hardware. If this is true, then the command x01, although not documented, should behave equivalently to x00, since the second bit prevents writing data to P altogether. I'd love to see this tested, btw ;)
As how the machine code is compiled to binary code, I have also a guess. Each command is a 32-bit string. The compiler parses the instructions, turns them into binary and then XORs (or ORs) them together to combine. In this way, the compiler doesn't need to keep track of which commands are performed in one line, so in particular no need to count how many commands there are. This would explain why six commands in one line compiles, and even suggests that technically any number of (conflicting) commands in one line would compile, although the code then doesn't do what is written. This would also be fun to see tested.
I showed this video to my Sega Saturn and it exploded.
"Four types of commands concurrently." i.e. not a strict quantity limit per-type. It is just saying there are four types of commands executed concurrently. If the demo code you were given is correct, then six may be the upper-bound on the number of instructions per-type that can be executed concurrently in a single cycle on the DSP. Your code works... because it was designed for six instructions. Honestly, if that technical specification of yours doesn't tell you the exact lower and upper bounds of every single instruction, then it wasn't written very well because that's the whole purpose of a technical specification in the first place: to document where things begin and end in a(n inadvertently convoluted) system!
It says it can use 4 types of commands. The line with 6 commands, only has 4 types of commands. I don’t see the issue
5:36 that's the issue, manual doesn't specify in binary how 2 commands in one type works
Great video!
What's that, the Sega Saturn had poor hardware documentation?! Say it ain't so!
Nice cross promo!
It makes sense from an instruction set point of view, at least. A lot of simpler processors have undefined opcodes of one sort or another that work in practice (e.g. on the 6502), and having the instruction decode directly drive the bus enables I could definitely see.
An interesting question would be what happens if you do e.g. MOV MC0, Y MOV MC1 Y, which "should" cause bus contention if I'm reading those bus connections correctly (both connected to the Y bus.)
What does the third bit of that triplet do?
i got a little suggestion
i wonder how they made the stuff in the adventures of batman and robin
especially that one space boss
Check the comments on Coding Secrets, the whole issue is due to an error in the documentation... even the example code from Sega shipped with the SDK worked this way, correctly
Im a game developer and I have no fucking idea what are you talking about. Gamedev nowadays is nothing compared to what it used to be back in the day. As always great video.
quadragonals!
It is four types of control commands, that is technically correct. As to why some commands aren't listed, I have no idea. Perhaps something like "these commands can be executed at the same time" got lost somewhere, somehow.
X Bus control controls RX, PL and PH. Y Bus control controls RY, ACL and ACH. I was going to suggest that perhaps in the earlier iterations, X and Y buses only controlled RX and RY. But that isn't the case, looking at the data diagram. Maybe it was the case before, but they realized they can do more at the same cycle, but while revising the document, they forgot to add the aforementioned parts.
The base document (that explains control commands) feels older; it says 1994 SEGA on the 2nd page, even though on the 1st page the date is shown as 1995, and it is the third edition. Other documents that have examples in them seem to be newer somehow; they say 1994-1995 SEGA on the 2nd page, and the date on the 1st page is 1994 this time.
In any case, cutting a whole cycle and instead executing two-in-one is neat!
Judging by what stories you share with us on this channel, SEGA messed up their own instruction manuals for devs.
I’m learning Saturn dev right now. The manuals collectively are thousands of pages of documentation and some of the utility tool screenshots are still in Japanese. It’s a lot to take in.
Hey Jon, do you have anything archived from Muppet Racemania for the PS1? Would love to see things that didn't make the final game and why there are differences between the US and European versions.
Having written: bitbucket.org/Coto88/armv4core/src/master/ I think I can relate to a possible reason:
The opcode translation unit in the processor (the opcode table translation by index) never accounted 2 sets of instructions each, but just either of the left column or the right column separately.
This means, sort of like a if(OPCODEREAD AND OPCODE1) if(OPCODEREAD AND OPCODE2) rather than switch(OPCODEREAD){ CASE(OPCODE1)... CASE(OPCODE2)... CASE(OPCODE3)... CASE(OPCODE4)...}
If we look at ARMv4t processors, ARM mode, ALU opcodes are packed into the barrel shifter registers (the ALU unit), an extension of the ARM processor. By doing that, it's possible to repurpose upcoming opcodes to use new uses of the ALU unit... something Saturn DSP didn't quite do, or simply didn't care to.
I would guess that what you call instructions are not really instructions (the decoding part is missing or it is extremely simple) but they are almost directly the internal control lines the chip is using to handle the internal buses.
FYI the link to your secondary channel is borked somehow. It resolves as: ua-cam.com/users/www.ua-cam.com/users/codingsecrets , throwing an understandable error.
Glad I found my Sonic R disc. Now I just need to get a Saturn!
When I traded everything in a decade ago they only wanted games that still had their original cases. So I still have a few they didnt want, and now I'm interested in Saturn again. a great system.
Good thing I lost my Sonic R case or they woulda took it. Hehe
Edit: today they'd take anything Saturn case or no case. But 10 years ago it was a bother.
Deja vu?
Is this a reupload?
Not that it's a re-examination of an older video, but that it's a complete reupload of this same video you uploaded recently. I distinctly remember watching this when I was really tired and couldn't comprehend it, so I gave up. That was at least a week ago, I think. So either it was a dream (in which it made up specific comments that I can't find to the tune of "'here it is in binary' me: 'oh, ok, thanks'") and I'm truly clairvoyant or this is just more evidence that the simulation is broken.
Also, I think the difference is explained in the manual showing "100xxx" for the X-Bus Control. Are those xxx's mentioned in another section of the manual?
Are those xxx bits to be filled in with other commands, as you do have in the binary line you've extracted, 2 different bit sets in the 2nd half of each X-Bus and Y-Bus Control block? If the xxx are filled in with bits used to denote the end of the X-Bus and Y-Bus Control blocks then you'd expect them to be the same but the 2nd set for X-Bus is 101 and the 2nd set for Y-Bus is 100.
I wonder if the xxx section uses a different set of bit combinations so it understands the distinction between the two. Maybe they're different bit combinations so you can't screw up the math doing the same process twice and, maybe, so you don't accidentally move something out of a block without replacing it with something else for the next clock cycle.
I think your idea is correct. If MOV moves are supposed to be mutually exclusive it would only need 2 bits to specify instead of 3 bits, according to ST-97-R5-072694 . This kind of stuff does happen. At least you didn't do a Halt and Catch Fire instruction.
More than likely what happened is that SEGA always new it would work, but couldn't explain it to the technical writer correctly to do it.
I write operating system code in assembler for mainframes and and I just started a new job to work on an mainframe emulator and I can tell you this kind of stuff happens more than you think. Mainframe Principle of Operations is written at the end, by some really tired guy after working for too long, probably in another language, while his wife is leaving him.
Do you think you could ever do a patch for Sonic R nowadays? You know, fix the controls, improve the draw distance, etc?
I don't know about control tweaks but one of the config files for the PC ports should unlock the draw distance. I think the specific value is on PC Gaming Wiki, and the mod loader might be able to adjust it
Is it true that developers made their game in the past based on composite outputs ? You guys as developers what do you think about this ? Did you test your game back then on composite or RGB monitors ? Do you think you art were made to be seen on composite or RGB ? What is be real true way to enjoy the art of retro games the way they were intended ? CRT ? HDTV ?
they don't say that it can't make 6 instructions at a time, it says that it can do 4 type of instructions at a time. I think it means that it's not limited at 4 instruction at a time if there's only 4 or less type of instruction
FINALLY
Cool !
I'm already subbed to Coding Secrets.. but FYI the link in the description doesn't work for some reason.. youtube has mangled it. Maybe prefix with https?
Hello wondering were the arena beasts in episode 2 of lego star wars ever planned like boga in ep3? If so do you have any visual material you can show us?
The only thing that could be is concation. Basically the assembler combines the 2 commands into one command and the hardware interprets as combo command and then sets both registers at the same time. Now if you were setting the same register let's say x register this would lead to an interesting problem because the dsp is a parallel unit. So which value would set if this scenario would happen?
My favorite game.
The moment I saw that one command was 100 and the other was 010, I said to myself "Maybe 110 is moving both at the same time?"
The thing is I have NO idea how to code or even what GameHut is talking about. From math I know a little binary, and assumed if the numbers weren't used, then it'd free to do it.
But this leaves a question: If the code specifies that one "bus" must be used to do two commands at the same exact time...how does it do it regardless if something like 110 signals for it to do it? Does it utilize something else to achieve this?
A LUT opcode table along AND operation in the decode phase (CPU fetches opcode, CPU tries to decode opcode)
Speaking of a little broken, the hyperlink to the coding secrets channel is borked ;)
I love your videos ... except that they finish too soon!
Where would the 2nd X or Y commands be stored during the cycle?
Someone commented on the last video that at appears to be a bitmask. Why not just try flipping a bit and see what happens?
Looks like witch craft.
YOU THE BEST
I got the notification just now
If you get the chance, could you take a look at the special stages from a sonic fangame called Sonic Triple Trouble 16-bit? It's a game that tries to emulate sega genesis hardware as close as possible and has faux-3d special stages with an artificially lowered frame rate. Considering how smooth the 3D Blast special stages were, I was wondering if it could run at a decent frame rate on an actual sega genesis.
Tails doll!?
No wonder devs flocked to Sony, holy crap
DSP = bugged mechanics
Finally!
What is the music in the intro?
Link in description is broken FYI.
isn't this a reupload? i think i saw this video already... (on this channel - like 3 weeks ago :)
Can you talk about Sega CD architecture and limits a little?
Do i understand this correctly - you can do all of the graphics/code data on Genesis gpu with all of the soundtrack/sound been done in CD cpu.
So the resulting game will only use loading for music, and all graphics/code data will be avaible at once, like on Genesis game cart ?
It looks like Ecco the Dolphin does nearly exactly this, but i can be wrong.
Interesting video! Don't you love it when hardware manuals don't include all options? (: (I've heard that this happened a lot!)
Edit: Aha! Looks like you misread it. Maybe you didn't back in the day?
Hey Jon, will there ever be a chance that you might cover something on the Bug’s Life game from 1998 on the PS1? I just replayed it for reliving my childhood’s sake and I think it’s better than people gave it credit for. Cheers from NYC! :)
Can we please recuse jazz without another incident like ceber 5. (Can you please show us the hoover dam decepticon campaign prototype on the ps2 and ps3).
My brain hurts