Thanks again for such an informative video. For the heck of it, I've looked at the Atari code (with Ghidra and my Atari8BitGhidra plugin - it's on GitHub): completely different! I guess there was no shared source code - that was quite common at that time. The "rule of 3" on the Atari implementation: at game launch the variable for the black hole tile is set to 0. When a black hole should appear, the tile index is incremented by 3 and that's where the hole will appear. At 25 it wraps around. So, years, trivially to predict. And the comment suddenly makes sense.
Whoa, thank you for so quickly answering the question I posed at the end of the video! I just found a youtube video showing the black holes on Atari gameplay, and yes, it's really as simple as t=(t+3)%25 in the original. :D I find it fascinating that (you determined that) the Commodore port didn't use any code from the Connelley Group's Atari original. Does anyone know who the original programmer is? Yes, Ghidra is quickly becoming well-suited for 6502 work. The most useful thing to me is the pcode emulation, which allows large windows of self-modifying 6502 code (common in copy protection) to update itself in the Ghidra dissessembly, just as it would on the 8-bit machine. On my c64_ghidra github, I wrote a rudimentary Ghidra emulator harness that gets the emulation job done, but it could certainly be improved upon. Once again, thanks for looking into this; you sir have officially put the nagging black hole question to rest. :)
@@DavidYoud You video about Ghidra I still watch ever now and then. It is such a well done video on how to approach reverse engineering C64 code. I didn't know about 6502Bench, but I am on a Mac, so I try to avoid Windows.
@@DavidYoud It was quite common to _not_ have the code for a port. Often the license for a specific platform was sold and the company then was looking for developers to write the code. If you were lucky, you had access to the original version, so you could see. That combined with schedules counted in weeks, it often resulted in quick ports. Also: we can't forget that often the development happened on the original machine as well. A machine without enough memory. So you see code with 1-character symbols and no comments at all. Today some old code can be found at GitHub, like Fort Apocalypse - it is really written to be compact. Been there, done that… Later (Atari ST, Amiga) cross-development was more common. I've developed an assembler (TurboAss) for the ST, which supported an output API. This was used to transfer via parallel cable code to e.g. an Amiga with a minimal stub. Crashes were caught and the TurboAss supported not just "GOTO line number", but also "GOTO address", so you could just enter the crash address to see where the crash happened. Turn-Arround times were less then 30s, not bad at the time.
What a fantastic video and stunningly powerful tool. Huge thanks for taking the time to make this, and do it so well. While we might think desktop CPU's and GPU's have stagnated a wee bit recently as AMD and Nvidia now wallow in their respective arenas, computing has advanced massively since the days of '8 bits' such as the C64. I remember the 1980's and that C64 well.
So well dissected and clearly presented. I truly appreciated at 01:04:50, the way you explained the pseudo random number generator sub-routine, with the 0/255 value map. Excellent and intelligent video.
You are definitely a computer scientist. In a way, you are treating this entire video as a puzzle solving a game like Zork's twisty little passages. LOL! I have learned more about assembly language from THIS video than I did back in college. BTW- I hated coding at such a low level but it was a required course. Changing the labels makes it much easier to understand. Fun video watching how your puzzle solving mind works.
Thank you. This video is the most help I've found to get started with Retro Debugger. Please do more tutorials on this. I was trying to figure out how to search the RAM for values. Seems like a command line 'Hunt' (HC) in a console window is the only way?
:D Maybe it's the kind of intuitive that means "easy to remember once you know" as opposed to "easy to discover". Either way, I found it more friendly than I expected.
Lastly I would like to propose an answer to your question about what to do with leftover code up concerning the 6502. I personally would renew, reuse and recycle all electricity that comes out of intelligent work. Because it gains knowledge the same as we do. So use those magic squares. Start by arranging those numbered tiles in silicon warrior according to the art. And the Black hole(a) will guide you in the ways of proper handling the now coherent electricity.
Wow you are so amazing. I have been watching this video 1-3 times a day since finding it 4 days ago. I do have a hopeful piece of info that should lead to something phenomenal. Those tiles are ,5 wide and five deep. That is a magic square. There are 3 magic squares total that are currently known. And because these magic squares can be added or subtracted from each other. They make up all other squares. I believe the other 2 magic squares are 4 and 3. How many power pyramids are there on that screen. Also how many sides? 4 if you count the bottom. Lol
So if one takes the 3 magic squares and multiples each number by 3. You get 9, 12, 15. Add those together and you get 36. Which stands for 369 degrees also ,6*6. The 3 rd 6 comes from 15 not being able to divide into 36 evenly and so leaves a remainder of 6. Now add those 6's together and you get 18. Well 1+8=9 and 3 is the square root of 9..
Thanks again for such an informative video.
For the heck of it, I've looked at the Atari code (with Ghidra and my Atari8BitGhidra plugin - it's on GitHub): completely different! I guess there was no shared source code - that was quite common at that time.
The "rule of 3" on the Atari implementation: at game launch the variable for the black hole tile is set to 0. When a black hole should appear, the tile index is incremented by 3 and that's where the hole will appear. At 25 it wraps around. So, years, trivially to predict. And the comment suddenly makes sense.
Whoa, thank you for so quickly answering the question I posed at the end of the video!
I just found a youtube video showing the black holes on Atari gameplay, and yes, it's really as simple as t=(t+3)%25 in the original. :D
I find it fascinating that (you determined that) the Commodore port didn't use any code from the Connelley Group's Atari original. Does anyone know who the original programmer is?
Yes, Ghidra is quickly becoming well-suited for 6502 work. The most useful thing to me is the pcode emulation, which allows large windows of self-modifying 6502 code (common in copy protection) to update itself in the Ghidra dissessembly, just as it would on the 8-bit machine. On my c64_ghidra github, I wrote a rudimentary Ghidra emulator harness that gets the emulation job done, but it could certainly be improved upon.
Once again, thanks for looking into this; you sir have officially put the nagging black hole question to rest. :)
I added your findings to the video description in the updates section.
@@DavidYoud You video about Ghidra I still watch ever now and then. It is such a well done video on how to approach reverse engineering C64 code.
I didn't know about 6502Bench, but I am on a Mac, so I try to avoid Windows.
@@DavidYoud It was quite common to _not_ have the code for a port. Often the license for a specific platform was sold and the company then was looking for developers to write the code. If you were lucky, you had access to the original version, so you could see. That combined with schedules counted in weeks, it often resulted in quick ports. Also: we can't forget that often the development happened on the original machine as well. A machine without enough memory. So you see code with 1-character symbols and no comments at all. Today some old code can be found at GitHub, like Fort Apocalypse - it is really written to be compact. Been there, done that…
Later (Atari ST, Amiga) cross-development was more common. I've developed an assembler (TurboAss) for the ST, which supported an output API. This was used to transfer via parallel cable code to e.g. an Amiga with a minimal stub. Crashes were caught and the TurboAss supported not just "GOTO line number", but also "GOTO address", so you could just enter the crash address to see where the crash happened. Turn-Arround times were less then 30s, not bad at the time.
@@markusfritze I'm going to pin this thread to keep it on the top of the comments. :)
What a fantastic video and stunningly powerful tool. Huge thanks for taking the time to make this, and do it so well. While we might think desktop CPU's and GPU's have stagnated a wee bit recently as AMD and Nvidia now wallow in their respective arenas, computing has advanced massively since the days of '8 bits' such as the C64. I remember the 1980's and that C64 well.
So well dissected and clearly presented. I truly appreciated at 01:04:50, the way you explained the pseudo random number generator sub-routine, with the 0/255 value map. Excellent and intelligent video.
That rewind to last read/write of a particular location would be amazingly useful. All this new-fangled stuff, it's going to put us all out of jobs!
You are definitely a computer scientist. In a way, you are treating this entire video as a puzzle solving a game like Zork's twisty little passages. LOL! I have learned more about assembly language from THIS video than I did back in college. BTW- I hated coding at such a low level but it was a required course. Changing the labels makes it much easier to understand. Fun video watching how your puzzle solving mind works.
Thank you. This video is the most help I've found to get started with Retro Debugger. Please do more tutorials on this. I was trying to figure out how to search the RAM for values. Seems like a command line 'Hunt' (HC) in a console window is the only way?
Yeah, I think the console is how memory searches are done right now.
8 bit show and tell sent me. Awesome tool & video!
Intuitive is not a word l have ever seen used to describe Retro Debugger.
:D Maybe it's the kind of intuitive that means "easy to remember once you know" as opposed to "easy to discover". Either way, I found it more friendly than I expected.
Thank you for very helpful about C64 emulator with debugger. 👍
Thanks for the video. I learned some good stuff that I will definitely try out. I use this program all the time but I guess didn't rtfm enough!
Awesome video. Retro debugger looks super fun
Hey old friend, long time no see. Yah, try out Retro Debugger on some old favorite game, you'll like it.
Lastly I would like to propose an answer to your question about what to do with leftover code up concerning the 6502. I personally would renew, reuse and recycle all electricity that comes out of intelligent work. Because it gains knowledge the same as we do. So use those magic squares. Start by arranging those numbered tiles in silicon warrior according to the art. And the Black hole(a) will guide you in the ways of proper handling the now coherent electricity.
Wow you are so amazing. I have been watching this video 1-3 times a day since finding it 4 days ago. I do have a hopeful piece of info that should lead to something phenomenal. Those tiles are ,5 wide and five deep. That is a magic square. There are 3 magic squares total that are currently known. And because these magic squares can be added or subtracted from each other. They make up all other squares. I believe the other 2 magic squares are 4 and 3. How many power pyramids are there on that screen. Also how many sides? 4 if you count the bottom. Lol
So if one takes the 3 magic squares and multiples each number by 3. You get 9, 12, 15. Add those together and you get 36. Which stands for 369 degrees also ,6*6. The 3 rd 6 comes from 15 not being able to divide into 36 evenly and so leaves a remainder of 6. Now add those 6's together and you get 18. Well 1+8=9 and 3 is the square root of 9..