Haven't we all had somewhat working code that as soon as we really start looking at it we realize "this can't possibly work" right before it mysteriously stops working?
Happened to me when working on a 3D engine and trying to figure out a lighting glitch. Poking at it, lighting stopped working. Figured my TBN matrices were getting miscalculated, so the lighting shouldn't have worked in the first place. Curious to see why it sort of worked I revert to an older commit in Git and recompile, to find completely non-working lighting. I got a bit spooked, had a long coffee and smoke break, came back and rewrote the matrix calculations from scratch, after which lighting worked just fine. The scary bit is I have a build from around the time of that commit, with only slightly bugged lighting, and for all intents and purposes it should be identical to the commit I reverted to...
I don't understand code creation but I love hearing about history on old video game hardware. It helps put into perspective how archaic game development used to be.
@Maric reminds me of an old piece of hacker folklore: A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.” Knight turned the machine off and on. The machine worked.
The documentation of Sega Saturn was apparently translated and signed by "Sega of America" In a previous video he mentioned that he received documentation from Sonic Team themselves... therefore he already had the Sega Saturn documentation BEFORE he did any work to code games on the Sega Saturn AND THEN he was contracted by Sega Japan directly and given documentation directly from Sega Japan which skipped being "translated" or going through customs at Sega of America.
The Sega Saturn documentation says "Sega of America" which means Sega of America management staff called for the Japanese to English translation... which means that if Sega of America's management staff didn't act professionally, an error can appear in the translated documents which automatically is traced back to Sega of America's staff as the ones responsible for this fiasco which basically sabotaged 3rd party devs from knowing how to handle the Sega Saturn hardware. Further... in 1994 to 1995 all Sega of America cared about was the 32X... an addon that was created by Sega of America's management staff under the thinking that there was 16 million Sega Genesis owners in the U.S.A. and Canada.. North America is also including Mexico... not sure if Sega of America bothered to include Mexico however which Nintendo did. So Sega of America had heavy interests in seeing their 32X be successful and treated the Sega Saturn as an afterthought deliberately while Sega Japan headquarters were trusting their subsidiary branch to do the work they were hired to... In an ideal world where Sega Japan's management were tougher and stricter, the 32X would have been canned... and Sega of America's management staff would have been audited leading to an ONLY Sega Saturn focused hardware and software launch which could have been made a week after the Japanese launch for NTSC/U and a week later for all the PAL regions by targeting older gamers who were likely working adults and went to arcades... something that a certain Sega of America chief in late 94, early 95 immediately dismissed as not possible outside Japan because the subsidiary branch only believed in 12 year olds and their parents as a target audience and in getting as much Disney cartoon characters related videogames to limit videogames into only being for small children which in turn puts a strain on game developers as many Japanese games were being rejected by Sega of America during MegaDrive Genesis MegaCD and later during the Sega Saturn... even more so hilariously during Dreamcast. the game programmer who made this channel is a professional coder... he knew how to read hardware manuals and despite him mentioning that some chips were tricky... he also talks about how he made the older MegaDrive do things not on the feature list... so no doubt he was a hardcore coder back then looking to learn the Sega Saturn hardware as best as he could but even so... You can have great hardware in the Sega Saturn You can have great game coders who made amazing games If an officially translated document has errors, it's going to cause a divide between the talented game devs and smaller devs... More importantly if the U.S.A. based subsidiary branch simply intentionally does not care about doing proper support and the work needed to get the word out to target audiences and they just rely on "parents" which in turn is insulting the actual gamers who purchased these game systems with their hard earned money then you'll have mediocre software sales and mediocre hardware sales and misinformation being spread by gamer magazines who could have been paid off or taken sides.
I couldn't quite understand that part so I downloaded the RU-vid video and looked at _that_ in binary. I find the conversion into pixels and photons makes things very ambiguous.
"3 bits -> 3 commands" Me: ok this should be straight forward to solve. Each bit turns on or off the given command. "...and 011, representing moving data to P" Me: ...never mind then.
The 3rd one is just a variation of the 2nd one. Both move something to P, the only difference is what they move. What bothers me more is that the 1st and the 3rd one both require an argument and there is only one argument you can provide, so mixing these two up in a single call with two different arguments should cause the compiler to fail.
I guess they developed the processor with having a bit mask in mind to turn on or of the 3 commands independently, but ran into some sort of problem with the second and third command and then designed it in a way, that they cannot be enabled at the same time (so its either x10 or x11), with only the first bit being independent. And then the documentation writer mistook all of that for the processor expecting a 3 bit "word" to set the command.
Well I don't think he wrote _everything_ in assembly, just stuff that needed to be fast (like this) Also, he wasn't the only developer at Traveler's Tales.
@Cringe Captor Shrekura Have you ever done computer science in lower years? It's just "this is how you print hello world and now we'll talk about different types of storage for the 1000000000000000000000th time". Completely useless, this is way better... Still, you shouldn't skip classes, even if they don't help you that much
@Cringe Captor Shrekura My school have never taught me anything I didn't know about programming, apart from the very basics of regex and that you can use comparison operators on strings in Python (it isn't a degree though, just GCSEs)
Definitely looks like either a feature that was discovered after the documentation was written (ie, Sega suddenly discovered MOV MC1,X and MOV MUL,P can run in parallel at a per-chip level due to how it's wired. They then added support for unioning those operations in the compiler but forgot to update the documentaiton) or they withheld a small part of the documentation to give themselves some extra benefits for internal software. Since you were working on a Sonic game, then they gave you an example of their secret 6 command code (or whoever you were communicating with accidentally gave you their six command code instead of the 4 command one) so you can make it as fast as possible. My money is on the fact that the documentation was written either before this combined operation was found, or that the documentation was written for a slightly earlier prototype chip when the combined operation wasn't yet possible. I wonder if you can nab a copy of the Japanese developer manual and see if it's the same or if it contains extras that weren't translated?
I second this. Scans of those docs would be a very fascinating read if Jon can somehow obtain some for research purposes (of course, assuming he knows someone who can translate it).
I don’t think this was unintended, because if you generate code that doesn’t rely on it, the chip becomes two times slower at performing what it was designed for. Looks more like bad documentation.
@@noop9k Agreed. The HW designers probably did it intentionally to meet throughput requirements. The person creating the documentation may not have understood it fully or perhaps assumed that everyone would understand that P and X can be updated in parallel. The DSP core itself is only a minor part of the documentation and it is quite simple in comparison to all the DMA stuff, for example.
They most likely just didn't put it in the initial DSP documentation, since there are half dozen examples codes all using this method, some dating back to summer of 1994. And later docs also mention it.
I've always heard the Saturn had very poor documentation, glad to finally see an example. I wonder how many other instructions are missing. Please keep these videos coming!
TL;DR: The manual was correct you can only execute on of each type of instruction at once, but the instructions MOV MUL,P and MOV ALU,A are wrongly labelled as using the X and Y busses while in reality there are special busses for these specific MOVs. *Pure speculation ahead, I have never worked with this chip or anything similar, but as a hobbyist electrical engineer, this is my best guess* I suspect that the DSP doesn't actually run instructions, but instead microcode. Microcode is the logic inside a CPU that looks at the instruction it needs to execute and then determines which internal control signals it needs to enable (or, which strings to pull). These control signals are mostly about routing. If we use the diagram around 0:56 as reference we can see that the memories MD0-3 can output to all 4 busses, so they probably have 4 separate control inputs for each of those busses (an input that signals it to output to the X-bus, an input for the Y-bus, etc.). These are then mapped to different bits in the 'instruction'. In this case they are probably mapped behind some binary encoding to save on space, but the principle is the same. Removing the microcode from the actual hardware makes the hardware faster and gives more granular control over the actual hardware at the cost of making it very difficult to code, what is exactly what we are seeing here. To give an example for what this means in this scenario, if we look at 2:10 you can see the X-bus control part of the command is 6 bits long. Then, looking at the block diagram from 0:56, we can see that 7 components can access the X-bus, which can be encoded in 3 bits. This means it could be that 3 of the 6 bits in the X-bus 'instruction' are for the component that should output to the X-bus, and another 3 are for the component that should read from the X-bus. (This is even more speculative, but seeing as at 4:15 both the MOV MD1,X and MOV MD0,Y instructions start with the bits '110', this could mean the first three bits are the destination, that destination being the multiplier in both instructions) Now we can see that the instruction MOV MUL,P from 2:54 is not actually mutually exclusive with MOV MC1,X because the block diagram shows a separated bus between the multiplier output and P-register. The same goes for the clashing Y-bus commands.
I'm not sure but I doubt there is any microcode for this. It'd be too slow and this is a high speed DSP that executes one instruction per clock. Probably each bit is just an input to a multiplexer selects line or to a register enable line.
Microcode would be too slow for DSP. It is all hardwired. This also means the undocumented bit combinations would do weird stuff, because blocking that would add complexity.
You are spot on - I have built quite a few machines like this over the years :) The "mistake" that coding secrets has made is to consider the "X bus control" and "Y bus control" to be instructions in the conventional CPU sense, whereas as you say they are likely microcode "instructions" with individual bits of the field used for specific steering/enabling of data (E.g. one bit might mean "Transfer the contents of the X bus into the X register". I think Jori & Gunstick have misunderstood - you are not suggesting that there is microcode behind the scenes - you are suggesting the two bus control sections are in themselves microcode.
programmers: it may be possible with some creative thinking and tinkering traveller's tale programmers: it's impossible, but we did it anyway, and we're the best!
This reminds me of undocumented instructions on 6502. 10101100 reads a value into memory into the Y register, 10101101 reads a value from memory into A, and 10101110 into X. What 10101111 does? Why, it loads a value into both A and X. However, constructing similar undocumented transfer instructions that didn't share either source or target didn't work as expected - but combining arithmetic and RMW instructions worked perfectly every time.
I understand literally nothing about coding, but this video more or less affirmed the idea that the Saturn was a bitch to program games for. Good gravy.
I sometimes wonder if trying to make head or tail of the Saturn is why some people who later worked on other machines adapted well to the oddities of some Playstation Hardware - while others just said "Nope" and limited the esoteric sub-processor use to managing a characters hair or some such & otherwise pretended it didn't exist. I wonder if there is any stories to tell about something like Shadowman on the N64 ?
Well processors have had undocumented instructions since they were a thing, but this is a bit of a biggie to leave out of the manual as it almost doubles the efficiency of the chip for certain operations..
They are **illegal** instructions, they may cause problems at any time, and they need to be sent back to wherever they came from. They’re sending their bugs, their malware, and some, I assume, are good opcodes. If they want to be included in this CPU, they can go through proper legal channels to be added in future revisions.
Jon before: "This genius code makes everything run 50x faster than previously thought possible!" Jon now: "Turns out that piece of code was not even possible and we broke space-time, sorry guys, 2020 was actually because of Sonic R..."
Reminds me of working with microcontrollers for automotive engine and transmission control applications. These were often based on common processors like the PowerPC or M68000 but highly modified for the application, and the manual will only cover about 30-40% of what that custom processor can _actually_ do, which makes reverse engineering them quite challenging, to say the least.
Just yesterday I checked this channel out if I was still subscribed since hadn't seen videos in a long time. And here we are, hopefully more uploads now on, fingers crossed!
OH! poorly documented features!... where have i seen that? I know! EVERYWHERE! 🤣 Damn it! Well, thank goodness it worked as it was expected and not as it was documented 😅
@@theRPGmaster agreed mann, unreal has soo much undocumented stuff that it's actually pretty hard to learn in the first place. do u know that in unreal, far clip and near clip plane is not per camera but per project lol. who the heck designed this
Perhaps there is some kind of bit masking going on with the commands? Maybe somewhere down the line of development, the idea you had (where each bit is a different command) got confused with a 3-bit 'word' where the other bits were 0. In logic, these might just be or-ed together at some point?
Definitely a bitmask to ensure certain combinations can't be used or are always combined. A) 100 - MOV CT1,X B) 010 - MOV MUL,P C) 011 - MOV CT1,P This means you can combine A&B or A&C; But not B&C, meaning either B can't be used with C in the same operation or that B is an operation required to run with C.It would be neat to look at this more or just black box test various combinations on hardware
@@AlexMovitz it would be interesting to see how some HDL synthesis tool would simplify the implementation of the encoding all of the known instructions. It clearly isn't just one bit specifying one operand with a one-bit mux...
@@RichardGordonUK That sounds plausible. Then we can assume that 001 is the same as 000, and 101 is the same as 100, as the lowest bit will have no effect unless the middle bit is set. At that point all bit combinations are accounted for.
Sounds like the DSP is executing microcode so the "instructions" are more tightly controlling the logic blocks. If the multiply works on latched inputs, and the moves are slightly staggered to latch after the multiply starts, then it could do those operations at once. Perhaps one is on the positive clock edge and the others are on the negative edge.
It looks like the "command" is a series of flags, rather than an explicit instruction, which is why it takes 3 bits to store them, rather than just 2. So if you have a command that takes no parameters, you can combine it with a command that takes a parameter (and/or another command that takes no parameters). So, depending on what the commands that are available (And whether they require arguments or not) are, you could have a maximum of 8 commands executing simultaneously (ALU, all 3 X-bus commands, all three Y-Bus commands, and a D1-Bus command)
@@CodingSecrets It could fit. My guess is that the bits mean something like (X register write enable, P register write enable, P register source select). So you cannot combine different MOVs to P together, but you can MOV to X and MOV to P at the same time.
I am a researcher at the University. I have never seen an academic doing what you have done to understand old circuits !!!! Congrats you are a top researcher !!!!!!!!!!!!!!!!!!!!!!!!
MOV MUL,P and MOV ALU,A might be grouped under X-Bus and Y-Bus control respectively, but they are not using the actual X and Y busses so it's not totally surprising that they can be performed in parallel. It would be interesting to see if instruction code 111 for the X bus would allow you to move the same 32 bit value to X and P at the same time.
And you can’t just move on and be happy that it works because some insignificant little thing that you do later might break it and then you’ll have no idea what actually broke.
@@JohnnyThousand605 Without this behavior the typical code becomes twice as slow, and also this is used in Sega’s examples. Very unlikely this behavior is unplanned. Just poorly documented.
This information is in one of the DTS / technical bulletins. Not only did you have Sega's example, you probably also had the DTS. SEGA TECHNICAL BULLETIN SOA-8 Augist 16, 1995 Saturn SCU DSP Tutorial 4.3 The X Bus These instructions allow the RX and P registers to be loaded from data RAM, and theyalso allow multiplier’s output to be loaded into the P register. The instructions that loadthe RX register may be used in parallel with the MOV MUL,P instruction. X-businstructions may be used in parallel with ALU, Y-bus, and D1-bus instructions. None ofthese instructions affect the processor status flags.
It seems like concurrent instructions work because on the circuit diagram the logical elements are wired independently and ALU codes don't have overlapping bits. If the ALU codes were consequential or the registers were shared between the operations, the execution of several operations would just mess each other (I didn't work with Saturn, that's just from an experiece from with small weird controllers). Awesome video!
oh man, this reminds me of N64 "micro-codes". legend has it that nintendo had some special micro-codes they only gave out to a select few developers like rare or acclaim to help them make their games run better. i always wondered what those micro codes might be...
This video triggered so many memories... On the subject of the "hidden" instructions an educated guess is that moving data to or from the multiplier use two different data buses which can most certainly be controlled independently so not very surprising to be able to load the registers’s unit with the "input" data buses while at the same time sending the current result through the "output" data bus. The bits layout for X Bus Control also hints at this as "010" (Mul -> P reg) and "011" (Data -> P reg) which both use the "output" data bus can't be specified at the same time because they share the 2nd bit (and the same data bus) whereas "100" (Data -> X reg or Data -> Y reg) which use the input data bus can be "or" with one of the previous patterns. The animation at the beginning of the video is confusing on whether or not the result of the multiplier is sent automatically to the P register but the "010" pattern (Mul -> P reg) of the X-Bus Control bits seems to imply that this is not the case ? Also i infer from your example that the "011" command from Y Bus Control bits should load the A register from the data bus and not the P register as with the X Bus Control bits ? If this is correct the only way to achieve 4 instructions at the same time would be (X-Data->X reg) and either (Mul -> P reg) or (Data -> P reg) So 110 or 111 and (Y-Data ->Y reg) and either (ALU -> A reg) or (Data -> A reg) So 110 or 111 Ok I think I am over reacting to this but.. god it was fun ! Thanks a lot for your videos it is a real pleasure to dive back on these times (as a former Atari ST, Falcon 030 [yes with the DSP56001] and somehow Playstation 2 coder) Keep going !
The Saturn already was underrated because too complicated hardware. If it has even more parallel processing features than written on the book, it's even more underrated and complicated. I'm sure that if more efforts were put on this platform, it could have achieved fantastic games, and SEGA wouldn't have ended that badly.
Man, SEGA was so far ahead that not even its hardware team knew the power they were giving their developers. Only joshing, but that is quite intriguing.
@@CodingSecrets That explains a lot in the respect of how you approach a coding problem or limitation. Great videos and I look forward to watching the link provided. Thanks for the share/upload. 👍🏻
Ah, so Sega never documented any explanation of the combination codes. That's really cool. Bit of an oversight there. Neat how you worked out how it was working from the example code!
You've worked on some technically impressive projects with unfortunate gameplay flaws. I'm amazed at just how many of this type of game you've worked on!
Have a little more respect for the developer here. The Sega Saturn, Sony PlayStation and Nintendo 64 were still the EARLY days of 3d graphics hardware and thus had hardware that you as a coder or programmer are responsible for studying the documentation however if the subsidiary branch, Sega of America is giving you documents filled with errors and later you get correct documents directly from Sega Japan and Sonic Team, it means something. Also as far as your rather disrespectful comment about his games... are you even a real game player or do you just spend time reading critical reviews? Sonic R had game design decisions... the point here is that decisions were made to give each character a different way to participate in the racing element which is rather sophisticated and on par with many of the games being developed and released by game devs of the time period. The decision to make Sonic 3D Blast Flickies Island an isometric perspective was made by upper management... Back then the marketing department from Sega of America kept requesting that all games be in 3d... Something similar was happening at Sony Computer Entertainment America when the PlayStation launched in 1995, many of the Japanese developed 2d games never even got "approved" for localization leading to many consumers being unaware that a 3d only agenda was being pushed on them by some marketing management staff of a subsidiary branch outside Japan... note that in Japan pure 2d graphics games were still in full production. Also during this for some bizarre reason Nintendo Japan themselves placed themselves in a bragging trap about only making 3d graphics games on the N64 which is the real reason why there's a handful of 2d graphics games when the N64 was way more than capable of handling arcade perfect 2d games... aka stuff like the older Konami TNMT arcade games and The Simpsons arcade games which were four players on screen 2d graphics games were perfectly possible on the N64 but were not made due to some arbitrary demand coming from marketing people NOT game devs and definitely NOT from real gamers.
My guess is that the requirements was only 4 instructions at once, implemented with 4 straightforward instructions to meet requirements, then realized after you can actually do 6 because of how straightforwardly they designed the chip.
I'm so glad you're making these again! I just watched a few of your older videos, the ones that stick out the most were Sonic 3D Blast FMV intro and Sonic 3 Bonus level.
The first line in your DSP code screenshot (around the 1:04 mark) is interesting, since it only executes 3 instructions (two of which appear to be moving the first bits of data into the X and Y registers of the Multiplier). In subsequent lines these MOVs are still happening, but you are also moving results out of the Multiplier and ALU. To me that looks like a 3-stage pipeline where you can parallelise copying data from memory to Multiplier, copying result from Multiplier to ALU, and adding data already in ALU. So at the same time you are loading X and Y with new data for the Multiplier to multiply (MOV #0, CT1; MOV MC1,X; MOV MC0, Y), you are also copying the previous result of Multiplier's last calculation into P and the last ALU calculation into A (MOV MUL, P; MOV ALU, A), whilst also simultaneously asking the ALU to add the data already in its registers (AD2). I'm not familiar with the Saturn's DSP at all, just going on observation. It's more apparent when you read those first 3 lines of code together, because you can see: - In line 1 that only X and Y are being addressed (and I'm assuming the MOV #0, CT3 is setting bus line/memory address CT3 to be used for the copy to X+Y). - In line 2 you see the same again, but now the result of the Multiply in line 1 is also being copied out to the ALU, whilst the ALU's A register is cleared (CLR A). - In line 3 you get nearly all the same again, but now ALU register is asked to sum the contents of its registers from line 2 and store it back into its A (Accumulator?) register (AD2; MOV ALU, A), which remember are the results of the multiply of line 1's data plus that CLR A. At the same time the ALU is also receiving its 2nd set of data which is the result of the multiply of line 2's XY data. And at the same time the Multiplier is being primed with a 3rd set of data. It makes more sense to me to rearrange line 3 into 3 parts: MOV #0, CT1; MOV MC1, X; MOV MC0, Y as the first pipeline stage MOV MUL,P as the second pipeline stage AD2 and MOV ALU, A as the third pipeline stage. It isn't even until line 6 that you see something that looks like the ALU's results being copied back out to memory, so I'm guessing up until that point all the arithmetic is being accumulated in the ALU? I suspect I'm wrong about some of those details. All very interesting anyway. :)
I used to write machine code routines for the Z80 in my Amstrad 6128. I discovered that there are quite a lot of undocumented or unofficial instructions for the Z80. These often use instructions that relate to the HL register but apply them to the IX and IY registers. An official example pair could be &7E for LD A,(HL), meaning "load the A register with the number at the address held in HL" and &DD, 7E, d for LD A, (IX+d) meaning "load the A register with the number at the address held in IX +offset d". Many other instructions intended for HL will work on IX if preceded by &DD or IY if preceded by &FD. The official line is that not all Z80 chips will respond correctly, but I've never met one that didn't. Reading through the lists of opcodes for the Z80 one can see an obvious pattern, suggesting a bit-specificity about them, for example &46 means LD B,(HL); &4E means LD C,(HL), &56 is LD D,(HL) and so on, but there is no code &76. Following the pattern it should mean LD(HL),(HL), which is pointless, but if used as DD,76,d it could be used as LD (HL), (IX+d). This might be a very useful code for a rapid data transfer. I think I used it to move screen shots from banked memory into screen RAM
Hi, this is called bit slice programming. In short this is not a hack or a happy accident, it is how the DSP was designed to work from the start. I've not programmed the Sega DSP but I did work on one bit sliced machine back in the day and I therefore designate myself as that "someone" who can confirm your reverse engineering of what's going on and tell you why it works :) Crucially the manual says you can do these four *types* of command simultaneously. But it doesn't explicitly point out that you can also do multiple ops within the X bus concurrently, ditto Y bus. You have coded six commands but they fall into only four types as stated. As you are using different ops within the bus types they will all run happily together - basically it's separate silicon for each of those command bits, and a zero in that command bit inhibits that silicon. Looking at what you showed us, my guess was that you might be able to do all three X bus commands together if the occaison arose, ditto Y bus. It turns out that's my mistake as stated in the manual linked by another commenter The commands were not listed separately in the manual as this technique would be obvious to an experienced bit slice programmer: namely that when you have a single bit position to run a command then you can do multiple commands simply by ORing the relevant bits together, so long as any shared data bits are the same. Whoever wrote that manual had done it so many times it felt like it didn't need saying Given that you obvs have not previously experienced this kind of machine language programming before, I congratulate you on figuring it out by reverse engineering. I was trained in this kind of thing in 1980 and have not used it since 1983, so your video has triggered some techy nostalgia which has cheered my locked down evening no end... :) This is also how some of the microcode within a modern CISC processor works: each machine code command triggers the relevant process within the microcode to implement that command, and the command that work on an entire string will be implemented using a one row loop like I describe below. Some RISC processors also use bit sliced microcode. Let me indulge that nostalgia... The bit slice processor I once worked on had command consisting of many more bits than the data. To distinguish a complete command from a date word we talked about a row of bits making the command. What a bit or group of bits did was defined purely by its position in the row: you can see how this makes it easy for the hardware folk to turn it into silicon. A fun feature was provided where every row had ten bits used as a repeat count. If some of these were set then that row was run that many times before moving on to the next row (1 to 1023 times obvs). If they were all zeroes then that row ran till a condition was met defined by other bits in the row called condition bits. If the condition and repeat bits were all zero it was a noop whatever the rest of the row said but it still took one cycle. So you could write a for loop or a while loop in a single row, and pedantically a row always executed once was coded as a loop with one iteration.
These days you can write straightforward C or Rust and once the compiler and AMD work their magic, it averages something like 2-3 instructions per clock-core. But it's a heck of a lot of magic: hundreds of millions of transistors that don't do the actual computation, only the decoding, scheduling, and reordering work. It's absolutely wild to imagine having to debug 4-6 lanes of explicit parallelism like that.
This reminds me of the hidden opcodes in the C64 6510 processor that weren't (for good reason) in the 6502 manuals that everyone used as reference. Ultimately, a microprocessor is just a machine that runs microcode that controls data flow through the various buses, registers, ALU, etc. If an opcode designed to do A -or- B can actually do A -and- B at the same time by setting/clearing bits that trigger the appropriate microcode (and there is no resulting contention for any resource), it doesn't surprise that the processor just happily does it.
The second identical processor is actually called the "slave" CPU, AFAIK (a master-slave configuration). It's best to avoid intentional fragmentation with technical terms, especially considering how complex the layout already is
Love these short and informative videos, as a old demo coder its great to see how things have been achived in low level code. Today when most, if not all coding is done in far more abstract languages this kind of hand craft is forgotten among younger programmers.
Oh yes! Love these Saturn videos. It has such a reputation in terms of being difficult to programme for, it's great to get an expert view. BTW, as someone who had to code the Megadrive in assembly (i.e. the hard way), I'd love to know what you think about SGDK.
@@litjellyfish SGDK is a modern C SDK for Megadrive. Although of course assembler is what you'd call adequate, you have to admit that C is much more expressive and approachable for the most part :D
@@litjellyfish Pretty much all Megadrive/Genesis games were coded using assembly language (similar to the code in the video). SGDK (Sega Genesis Development Kit) allows games to be written in C instead. I've learnt a little assembly myself and, while it's actually quite fun, it takes a lot of code just to get something to display on the screen. SGDK contains lots of functions, enabling the user to display sprites, backgrounds etc with just a few lines of C code. While I'm sure a super talented and experienced assembly programmer such as the author of this video could get more out of the console by writing assembly, for the rest of us, SGDK is the best option. You can get great results from using it (the recent Megadrive game, Xeno Crisis, was created using SGDK). If anyone is interested in creating their own games using SGDK, I highly recommend this tutorial series: www.ohsat.com/tutorial/
@@mrbig2648 ah i did not know about it he SDK. I was just wondering about that and not about assembler as I did gfx for Megadrive games back in 90s and of course needed to understand code a bit. With macro assembler you could set up pretty similar to functions but using macros and then “pure” assembler commands when needed. Back in the days the performance of the C compilers was pretty bad. I mean there was actually possible to use C compilers on PC with the dev Kits but they where pretty slow and memory and performance wise you lost quite a bit compared to pure assembler. That said maybe more C and just assembler where needed would have been good back then as well. It was also a bit of silly honor to not use C back then :p When I have some time I will check it out. Sometimes I get the urge to make a Kickstarter for some MG Drive as a hobby project.
@@SianaGearz yes I guess maybe also it depends where you come from. Me and most the coders I knew started out with asm and C compilers was a hassle. So expressive wise I am not sure. Today it’s a totally different thing though:)
Thanks again. You are so good at explaining quite complex items. It's a skill in itself and one I can imagine helped you initially wrap your head around some of them.
Op codes that are just flags turning on individual channels in the hardware is interesting. I guess the limited variety of operations in a DSP makes it practical
If is probably more useful to not interpret these as “commands” but as “routing directions”. The multiplier and ALU are always doing their job and you only control what data goes where between execution units by setting these bit fields. Writing all these MOV is pretty much redundant and I think they could come up with more compact format.
For someone used to writing assembly code, MOVs and MULs are going to be the most readable and easy to understand. But you make a good point; as Jon mentions in the video the DSP is not really a general purpose CPU but rather a specialized chip that does a few very specific tasks very quickly. So the "instructions" you use to program it aren't really your typical instructions, but more like a pipeline configuration. Instead of looking at it as executing 6 instructions in parallel, what you're really doing is just flipping bits to decide which component does what, and each component will do what it's set to do on every cycle. That way it also makes sense that you can multiplex several "instructions" together, even though it seems like that shouldn't be possible.
So would it be safe to say the DSP is transport-triggered architecture, in that it's based on routing data to chip elements for tis operation rather than opcodes, per se?
Modern day processors do limited types of "op fusion" for things like multiply accumulate sequences. I wonder if this is similar to that, if the operations happen often enough together it would make sense. Also, weren't Sega's reference manuals for the Saturn famously awful and consistently mistranslated until they came along and wrote a bunch of mid-level libraries, at which point everyone started using that? This was around about the time of the VF2 release so a year or so into the console's lifetime? An alternative theory that is more human error and laziness than undocumented magic.
I think it is like others have said and it comes down to how DSPs work and not that it is actually performing multiple instructions. Imagine a hose that has 2 taps. You can turn the input on and you can open the left, right, or both taps. Turning the flow on or off is needed either way so it makes more sense to control the outputs. This concept can also be turned around for inputs if you turn on a flow every time you want to update a register but by controlling the gates you can say open gate 1, open gate 2, or open no gate and they both stay 0. This would allow controlling 7 inputs with 3 bits.
Actually Hidden / Undocumented Instructions are the norm rather than the exception x86 ISA has tons of them (both the Amd and Intel variants ) They are undocumented because they either serve testing purposes or they are meant to be used by very few people who know about them in the first place KEEP UP THE PEAK QUALITY CONTENT
This does make sense. It's really just an ALU instruction with 5 register writes of which 3 use the D1, X,and Y busses. Some DSPs would just have this as a multiply and accumulate instruction instead of an ADD with the P and A moves infered.
I’d guess that the chip logic and structure serendipitously allows for those two commands to happen simultaneously. the engineer who designed the chip probably figured it out and allowed the assembler code to create binaries to take advantage of it.
Just the kind of content I love! Numbers and code intrigue me greatly and watching you break down a game that I have played time and time again is great! Bless the RU-vid algorithm!
On hardware level the OP code bits are usually used for enabling/disabling the modules or flipflops that correspond with the given operation. I noticed @XL2 pointed out the documentation was updated but it is possible what is actually happening is that there are indeed 2 separate instructions with given op codes, but because they don't interfere with eachother (I'd assume due to not using the same communication lines, either intentionally or not) there's no check preventing them from being executed at the same time by OR'ing the 2 opcodes.
Could be a "bug" that became a "feature"? perhaps the logic gates that were triggered by the command bits were not intended to be able to run at the same time but during testing, someone at Sega discovered they were and never thought to ask the hardware documentation team to update their guide?
This seems common in old hardware, judging from my experience with the 6502. In the 6502, opcodes were one byte, but not every byte was mapped to a command. When designing the actual hardware, the engineers realized they didn't have to check if all 8 bits were right, just needed to do enough checking to distinguish it from the other commands. Because of this, there are "illegal" opcodes that can end up performing two commands together; though they aren't guaranteed to work on every version of the 6502
My first thought was that something similar to some of the 6502's undocumented instructions was happening. eg $AF equates to LDX ($AE) and LDA ($AD) from an absolute address _at the same time._ To do this the same micro-code decides the absolute address and reads a byte from it and the final step uses two bits to decide where to put the loaded byte. If neither is set it goes into the Y reg ($AC), but if bit 0 is set it is put in A, and if bit 1 is set it is put in X. If both bits 0&1 are set it just puts it into both A and X - it obeys both individual bits being set! They may have not intended this with the Saturn, but the effect worked that it eventually became a documented feature. Incidentally on the 6502 the same happens with $8F: it uses bits 0&1 in the same way as $AC-$AF to decide which register to save in the memory address given. When both bits are set it tries to store both A and X at the same time. The result is that the registers are ANDed together, not intentionally but (I think) as a result of the electronics: bits will float high (1) unless specifically pulled low (0). With two sources unless both are (floating) high, the result is that the pull low wins, ie if either is 0, then the result is 0 - the effect of an AND.
Software engineer who's worked on embedded systems speaking: You are almost certainly right that the HW is just taking the sum of the two arguments. I'm guessing the DSP is doing some sort of 'mask and shift' on the incoming instruction and checking each condition to see if the command should execute, rather then checking the entire instruction and matching the entire word. Basically, the HW does the equivalent of this, in sequence: -If Bit 0 is set, do MOV [s],X -If Bit 1 is set and Bit 2 is not set, do MOV MUL,P -If Bit 1 and Bit 2 are set, do MOV [s],P It's interesting this isn't noted in the HW guide. I'm guessing this is an "undocumented feature" of the HW that Sega itself discovered after the fact, then adopted for it's own use to speed processing.
I suspect every bit of the instruction word simply corresponds to a switch in the data routing matrix directly. You have to abandon operation based thinking when thinking of hardware, because generally everything always operates. Every time you think of the word "sequence" applying to things that happen within one cycle, well sometimes maybe, but generally you shouldn't.
It may be worth to look into how emulators interpret code. For example in "yabause" in src/scu.c there is a bit of code that clearly perform up to two commands for X-bus (and similarly for Y-bus as well). If bit 25 is set, "MOV [s], X" is executed. If bits 24-23 are 0b10, then "MOV MUL, P" is executed; and if bits 24-23 are 0b11, then "MOV [s], P" is executed.
Splendid find! Poor documentation is a pain. Someone thought: "well IT'S OBVIOUS we OR those here right? No point writing it down" And then turns out it's not obvious. 100% of the time. That said I'm not without transgressions myself in this regard... But I try, ok? At least once someone hires me again
Jeez, these commands must be being read at the most insane speeds to be able to tell a game to show everything correctly in something as complicated as a 3D game.
