Your content is brilliant and also your way of delivering it! Thank you very much for taking time to upload these videos. I for one really appreciate it. PS stick to Laser Genius - that's my favourite ;)
Love the archeology and shocked that they actually included all of that code with the mouse. Different times, back then. I thought you were going to remove all of the JMPs and JSRs and use all relative branching such that it is loadable anywhere, so I can only give you a 9.5 (out of 10). Just kidding, your channel is awesome, thank you!
"It goes behind the border," haha! Interesting that there are even location-related memory locations "back there" I always thought that in order to have border space for things to "go behind" on this machine, we had to turn on border widening (enable scrolling to have a cut-off look or just be more functional in general).
Might have run the demo program once & never touched the driver. Lions ran every .prg file they came across in those days. Knew it used the paddle registers to send coordinates but couldn't figure out how they eliminated the paddle noise. It must have converted the encoder counts into an analog ramp that wrapped around & had an interrupt handler catch the wraparounds.
Brilliant video through which, I dived back into those C64's BASIC instructions that you handle very well, but I almost forgot. If I could double-click on the like button, I would do it. Sadly UA-cam prevents this!
Why was the 1351 source code on that disk messy and in 80-column mode when the 64 doesn't have 80-column mode except virtually in BASIC lines, and why can't TMP just handle those as-is if those were already made for the 64?
Why are there so many C64 programs that start at 32768 or 49152 instead of just barely past all BASIC space? What if someone chose 3000 or 4000 even? I understand that 32768 and 49152 are ^2s. But's so significant about them that they're popular starting points? For example, LodeRunner starts at 679(dec.). How does a programmer decide to start at that location instead of anywhere else, even though that's not a ^2?
Hmm.... I like this idea for a future video. Aside from how it works, I could show the undocumented uninstall routine, how to customize and animate the pointer, and maybe talk about how to use it in an Assembly Language program.
Why start this BASIC program with 50K, and then why start the ML program at a point right above BASIC instead of starting it a lot farther away in the first place?
After over 4 decades, want an idea of how to save a little effort with this stuff now? Try not adding a space wherever spaces aren't necessary, such as right after a line number and a command.
Ha, how do you make sure your save "@..." doesn't create a splat file if you were to be using real Commodore hardware instead of the VICE? FFR, I recommend not teaching people "@" in case they use the real deal; have them scratch and save instead.
@@TheUtuber999: To answer your question: no, it was my understanding that it may work out fine but was very hit-and-miss unless you got an updated DOS chip. So unless you knew for sure, you would best delete and resave instead.
@@HelloKittyFanMan My understanding is that you are correct if you simply use "@", but if you use the syntax "@0:" then there should be no risk of the 1541 bug affecting the save-and-replace operation.
@@TheUtuber999: That would actually make me partially incorrect, then, because I thought I remembered it being described as any time you tried using direct replacement it could splat whether you used the 0 or not. But now what you're saying actually does sound a little bit familiar: just use the 0 and you're fine. But I could have sworn there were other videos where someone said that just using the feature at all in those affected drives could cause trouble at any time.
You have a great presentation style... cool overview of mousing around on the C64.
Thanks!
Your content is brilliant and also your way of delivering it! Thank you very much for taking time to upload these videos. I for one really appreciate it. PS stick to Laser Genius - that's my favourite ;)
Thanks!! I do love the Laser Genius. There will be much more in the future!
"PS stick to Laser Genius..." TMP doesn't require line numbers, though.
Love the archeology and shocked that they actually included all of that code with the mouse. Different times, back then. I thought you were going to remove all of the JMPs and JSRs and use all relative branching such that it is loadable anywhere, so I can only give you a 9.5 (out of 10). Just kidding, your channel is awesome, thank you!
You can’t thank US enough for watching these videos?!? I can’t thank you enough for making them!
Thanks!!
Very good presentation. Its also a ground for doing the application part in assembly, which is my cup of tea. That would make it a one-file deal.
This was great, I learned quite a bit
Great video again. Thank you.
Good video! I had this mouse on my C64.
"It goes behind the border," haha! Interesting that there are even location-related memory locations "back there" I always thought that in order to have border space for things to "go behind" on this machine, we had to turn on border widening (enable scrolling to have a cut-off look or just be more functional in general).
Might have run the demo program once & never touched the driver. Lions ran every .prg file they came across in those days. Knew it used the paddle registers to send coordinates but couldn't figure out how they eliminated the paddle noise. It must have converted the encoder counts into an analog ramp that wrapped around & had an interrupt handler catch the wraparounds.
You are very knowledgeable.
Brilliant video through which, I dived back into those C64's BASIC instructions that you handle very well, but I almost forgot. If I could double-click on the like button, I would do it. Sadly UA-cam prevents this!
Cool video, thanks.
Why was the 1351 source code on that disk messy and in 80-column mode when the 64 doesn't have 80-column mode except virtually in BASIC lines, and why can't TMP just handle those as-is if those were already made for the 64?
Why are there so many C64 programs that start at 32768 or 49152 instead of just barely past all BASIC space? What if someone chose 3000 or 4000 even? I understand that 32768 and 49152 are ^2s. But's so significant about them that they're popular starting points? For example, LodeRunner starts at 679(dec.). How does a programmer decide to start at that location instead of anywhere else, even though that's not a ^2?
how does this mouse technically / logically work? is it too much to ask for a rundown of the assembler source code ?
Hmm.... I like this idea for a future video. Aside from how it works, I could show the undocumented uninstall routine, how to customize and animate the pointer, and maybe talk about how to use it in an Assembly Language program.
So why start the program out with numbers that you don't like and then change them, instead of just starting it out with numbers that you do like?
It that one identical to the Amiga mouse?
They visibly look the same, but they are incompatible.
"So we're gonna read that value of the button out of memory."
Huh, that's weird. Why would we want our reading to be destructive?
"So now lets put into place some code to make an _actual_ program."
You just did already.
Why start this BASIC program with 50K, and then why start the ML program at a point right above BASIC instead of starting it a lot farther away in the first place?
whoa i never knew there was a mouse
"...With the GEOS operating system..."
* "...With GEOS."
* "...With the Graphics Environment Operating System."
After over 4 decades, want an idea of how to save a little effort with this stuff now? Try not adding a space wherever spaces aren't necessary, such as right after a line number and a command.
Ha, how do you make sure your save "@..." doesn't create a splat file if you were to be using real Commodore hardware instead of the VICE? FFR, I recommend not teaching people "@" in case they use the real deal; have them scratch and save instead.
"@0:" should be safe?
@@TheUtuber999: To answer your question: no, it was my understanding that it may work out fine but was very hit-and-miss unless you got an updated DOS chip. So unless you knew for sure, you would best delete and resave instead.
@@HelloKittyFanMan My understanding is that you are correct if you simply use "@", but if you use the syntax "@0:" then there should be no risk of the 1541 bug affecting the save-and-replace operation.
@@TheUtuber999: That would actually make me partially incorrect, then, because I thought I remembered it being described as any time you tried using direct replacement it could splat whether you used the 0 or not.
But now what you're saying actually does sound a little bit familiar: just use the 0 and you're fine. But I could have sworn there were other videos where someone said that just using the feature at all in those affected drives could cause trouble at any time.
You are very knowledgeable.