10:39 "This copy routine only handles full pages. If you don't like that, YOU can rewrite that." The classic start of nearly every career in programming 🙂
This was so interesting, especially how the cart loads into RAM. I'd love to see an exploration of a very large cart like Eye of the Beholder and how the C64/C128 handles it, specifically around memory paging but also how it makes the C128 use two screen mode
Large cartridges behave more like a disk drive, there is a small area that the cartridge appears and the CPU copies it into ram. Max cartridges switch most ram off and the cartridge just appears in the CPU address space
Love it when a game gets bug fixes many decades after it was made. Thanks for the walk-through of getting a game out of its cartridge form and into a loadable game form with fixes no less. Very informative.
I do believe the bouns thingy was kind of memorable. Probably kept for a reason. Thank you @8-Bit Show And Tell, for giving us these cherries on the cream of the early 1980s.
Hahaha when you pointed out that Lemans (I pronounce it "lemons" myself... kidding) says BOUNS instead of BONUS, when you highlited it, I SWEAR I saw "BONUS" for a few seconds. I REALLY had to look at it to see that it did indeed say BOUNS! LOL Another great video Robin! Thank you.
This game was of course famous even around here: starting in the arcades, and then on the C64. Growing up in rural South Georgia, USA, EVERYONE I knew called it "Leh-MONS" complete with the 'S'.
Great work! I think spotting that typo is really hard if you're actually playing / watching the game since it appears for such a short period of time. Nice job fixing it!
Another great and informative video Robin! Great trick using characters typed into screen ram in the BASIC editor to easily get the screen code bytes! Thanks for sharing. :)
Actually, side note. When doing writes into the banked memories, they are going "through" to ram. So in order to do the copying part, you won't even have to switch out the rom. Of course, you'd need that later anyway in order to start the game. But I think you knew that Robin.
Yes, writes would go through to RAM so I wouldn't have to switch out the ROM before the first copy, from $0900 to $E000. But then for the 2nd copy the ROMs did need to be out as I chose to copy from $F000 to $3000 just to make the intention a bit more clear (in my mind, anyway). I could have copied from $1900 to $3000 to delay the ROM switch as late as possible, but that seems even less explanatory to me.
I watched/listened to the video again and I see that you're picking up on this part: "...reveals the RAM underneath, which is where we want to copy the cartridge to" and how it maybe implies that that the ROM had to be out to do the copy. So yeah, that's worth clarifying, thanks.
Last time I checked, Atari 8-bit cartridge dumpers (at least the 1 I used) could automatically save the ROM contents as a binary loadable program already. It doesn't take much. You start a file with the Atari Binary File header which (and I need to refresh my mind on this) is 6 bytes. 255, 255, start load address lo byte- hi byte, end load address lo-hi. Then the bulk of the data, then the next segment loads at a specific address (and I forget what it is) & all binary load files on Atari do this. It loads the Start or Init run address in 2 byte lo-hi address fashion. For cartridges, it's usually the same address because cartridges use the OS Run vector. It's been quite some time & I need to look at my books about this, but it's super easy to dump cartridges on the Atari 8-bit & then binary load & run them. And it usually works unless they put in a copy protection routine to what we called "poke itself out of memory" since you can't over write a ROM. 👍
Regular C64 cartridges that map at $8000 are a bit easier; once saved they can be loaded into memory and then started by either pressing your reset button or SYS 64738. But these Ultimax cartridges, originally intended for the MAX Machine console, are a bit trickier. I imagine it'd be possible to automate this process but I assume nobody's bothered since it would be more work. By the way, there are some Commodore cartridges (VIC-20 and C64) that also do that same "poke itself out" copy protection trick. They probably got it from the Atari.
As a Frenchman the exact pronunciation of Le Mans is without "s" at the end. but it doesn't matter because we also don't know how to correctly pronounce a number of cities or states. Arkansas for example or Albuquerque 😅.
@@gcherowars6758 Indeed the names of city or states of French origin should be pronounced in French but I think that the pronunciation has become anglicized with time as for example Saint Louis whose "t" of Saint and the 's' of Louis do not pronounce. New Orleans same. in "Illinois" the "oi" is difficult to pronounce for anglophones...
That game reminds me a lot of Road Fighter, which I used to play a lot on a PS1 Konami classics disc. That's super cool what you're able to do with 6502 assembly! I adore the major educational detail you put in your videos. I'd like to learn that language in more depth to achieve a life goal of making a new game for an old platform. Keep up the good work!
Tbh, if I didn't look at the release date, I would've figured that this was a Road Fighter knockoff. :P It also gives me a vibe of Sega's Monaco GP, from 1979.
@@comchia4306Yes, it's primarily inspired by Monaco GP. All these early HAL Laboratory games are actually clones of arcade games that were popular in Japan at the time.
One other tiny glitch is at 24:57 with the stoplight. It seems to go from red to red to yellow to CYAN instead of green, but that may be because of a video capture artifact.
I’ve got a very bad memory of this game. There was an arcade version and when I was 10 we went to Spain and I saw there was a credit on the game. There were some teenagers 16-18 talking and smoking (back then you were allowed to smoke and drink in the arcade section of the hotel - good ole times). And I press start. It so happened that the guy had put on some cash and was first smoking before he was going to play. He literally punched me so hard in the face that it knocked me down to the floor and I saw double. And one of the other guys kicked me in the side before they quickly returned to the cabinet and started to play. Whilst I was rolling in agony and tears.
hi there.... there is a game called Hades on the c64 which cannot be completed because it glitches out. someone pointed out its because the corruption starts at the beginning of the basic rom... is there a way to fix it?
Interesting, I hadn't heard of that one. I looked into it a bit and it looks like the best version around was by Ian Coog of Hokuto Force, and if he couldn't fix it 100% then I doubt I could do better! I'll see if I can find out any more info about it.
Could you use labels to calculate the basic end pointer? Ditto could you use an expression to convert the start address into a petscii sys string? Putting all this together would make a pretty handy macro if it worked.
It should be possible in this assembler to use labels for the pointer to the end of BASIC, but I think it's beyond TMP's abilities to handle the PETSCII sys string unfortunately, so some amount of hard-coding is necessary. However, I've seen at least one modern 6502 cross-assembler that can do the whole thing including the string very cleanly.
@@8_Bit hmm it can do logical expressions and basic arithmetic but doesn’t seem to do left/right shift. But could you use multiplication or division to do the shifting? Then you could use and to mask and just add 30 hex. Now to go spin up an emulator (haven’t played with C64 coding in …. Ooh 35 years maybe?) I love your videos - very amusing to watch you fix 40 year old bugs!
I've noticed that you change the contents of address $01 in the monitor program on the fly, but it's usually done between an SEI and CLI command in a program. Why can you safely change $01 in that monitor? I also noticed that your block copy code uses as SEI but appears to be missing a CLI. I'm sure the code you call probably does a SEI again first, but for good measure I think I would include a CLI anyway :) Dumping this code and making it run has been fun to watch. Thanks for another crystal clear explanation.
Super Snapshot does lots of behind-the-scenes magic to make the monitor behave like its independent of the C64 its running on. It tracks what location $01 should be from the user's perspective, but is actually dynamically changing it in the background, along with other registers, as needed, so it's safe. re: not CLI'ing at the end, I think it's actually safer the way I've done it, as a rule. The Ultimax has no built-in ROM at all (no KERNAL, nothing) and it's up to the cartridge code to initialize CPU registers and flags. The first thing LeMans does upon boot/reset is SEI, in fact. If I CLI'd first then maybe an IRQ would happen before the initialization code ran, and maybe that would be bad. If I found the game didn't work properly without a CLI then I'd investigate why and add one to the init if necessary, but then I'd probably consider that a bug that the cartridge didn't properly initialize interrupts itself.
@@8_BitSome super snapshot magic going on there! I've always wondered what the likelihood is of things going wrong if I changed $01 around without disabling interrupts. Maybe a fun experiment :) Not CLI'ing makes sense when you put it like that. Basically you're writing a prequel to the original initialisation. Disabling interrupts a little earlier is probably a good idea. Thanks
Suspect the best way to try out a cross compiled program on real hardware without owning it is to make a cartridge & try plugging it in at a museum or trade show.
That game is a classic early example that bad game logic has been around many years. What do I mean? Well, bad game logic is when a game does not do something you'd expect from what you experience in real life. Things like in current survivor games you could need a log to create just 1 plank when in reality 1 log will create a few planks or in this case your car having a light cone at night to show you have your headlights on but the other cars don't! lol
Is there a reasonable way to reverse this? If I want a CRT from a disk or tape, I assume it has to be modified to call the cartridge ram space, but it'd be cool to see the inverse.
If you've got an actual ".crt" cartridge image for use with emulators or Kung-Fu Flash etc, then check out the cartconv command line utility that's included with VICE emulator. It can go back and forth from binary, and .crt image. There's no automated way that I know of to go from what I show in this video, but with some experience it's fairly easy to examine the code in a machine code monitor and identify and extract the actual binary.
I'm not an expert in TMP but I wonder if it has an "include binary" pseudo op so you can simply ORG $900 and then include the binary. Though in a real 1541 that include might be painful to do on every assembly run.
Maybe! Meantime, have you already seen my code walkthroughs for some of my already-made games in Turbo Macro Pro? I have a playlist called "C64 Game Development" on my channel page. Some of the video titles are "My First Paid Game Dev: Code Walkthrough of Frogs And Flies on the Commodore 64", "Exploring Marz: C-64 6510 Assembly Minigame Code Walkthrough", and my friend's game "Making a New Commodore 64 Game: 1nvader".
@@8_BitThank you kindly for your message. I'm going through your videos and I'm now starting that series. Saw yesterday the 1nvader and Darren did an awesome job. Your explanation is also super helpful. I'm starting reading the books you recommend but my brain doesn't compute Assembler yet :) Much study to do yet.
There’s going to be a part 3 to complete the Lemans Trilogy… right?! I mean we gotta find out how it’s calculating the time and everything. I just need confirmation. 😂
We're mimicking how the MAX Machine "sees" the cartridge. The Max's CPU can see the full 8K of the cartridge from $E000-$FFFF. The Max's VIC-II can see the upper 4K of the cart, $F000-$FFFF, but it sees it in the equivalent of the C64's bank 0 at effectively $3000. The upper 4K of the cartridge may contain both graphics and code/data, not just graphics, so it needs to be at both locations in the C64.
@@8_Bit Ah. So the C64 still needs to see what's at F000-FFFF, but the VIC II needs to see it at 3000-3FFF because it doesn't have a full set of address lines? And in MAX mode, the address select logic is tricked to map the VIC II to the cartridge space?
I think that's more-or-less it, yes. 65XX architecture typically requires ROM at the end of memory since the CPU vectors (particularly reset) are at $FFFx, so that's where the cartridge had to be mapped, and typically requires RAM at the start of memory (because zero page and especially the stack are located at $0000-$1FFF. So given that the VIC-II can only see 16K and it for sure needs to see RAM which is way down at $0000-$07FF, they needed some way of bringing the cartridge ROM into that same 16K range. The MAX Machine and a C64 in "Ultimax" mode do this re-arranging automatically, but since our C64 is not in Ultimax mode we have to simulate that arrangement with this copying.
10:27 Page-aligning the source data also makes the copying faster, since there will be no page crossing with the indexed addressing. 11:34 You could amortize the «bne loop» by unrolling the loop a little. 14:48 Might look a little nicer with a space: «2023 SYS 2062». 15:43 I've heard it pronounced more as "le-mawh": th-cam.com/video/FDhofK4CNwQ/w-d-xo.html 17:01 Must be "Typoglycemia": Aoccdrnig to a rscheeahcr at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe. 21:03 Copying the cartridge data from a lower location works around the problem of not being able to SAVE location $FFFF.
@@8_Bit Thank *you*, Robin! I'm always amazed at how much in-depth info you are able to provide around the topics you address. And please be aware that you absolutely do explain complicated matters well enough for anybody who is sufficiently interested in the topics presented :).
Funny how if you mispronounce anything not in your language, "if your american" everyone tries to correct you, but if you correct anyone for mispronouncing anything in ameican english people call you a "race car driver 😉" . Pull the sticks outta there people.
10:39 "This copy routine only handles full pages. If you don't like that, YOU can rewrite that." The classic start of nearly every career in programming 🙂
This was so interesting, especially how the cart loads into RAM. I'd love to see an exploration of a very large cart like Eye of the Beholder and how the C64/C128 handles it, specifically around memory paging but also how it makes the C128 use two screen mode
Large cartridges behave more like a disk drive, there is a small area that the cartridge appears and the CPU copies it into ram. Max cartridges switch most ram off and the cartridge just appears in the CPU address space
@@phill6859 yeah but I don’t want you to explain it, I want him to.
Love it when a game gets bug fixes many decades after it was made. Thanks for the walk-through of getting a game out of its cartridge form and into a loadable game form with fixes no less. Very informative.
I do believe the bouns thingy was kind of memorable. Probably kept for a reason. Thank you @8-Bit Show And Tell, for giving us these cherries on the cream of the early 1980s.
Hahaha when you pointed out that Lemans (I pronounce it "lemons" myself... kidding) says BOUNS instead of BONUS, when you highlited it, I SWEAR I saw "BONUS" for a few seconds. I REALLY had to look at it to see that it did indeed say BOUNS! LOL Another great video Robin! Thank you.
You did a good job bouncing those lemons.
Impressive as usual, thank you very much for the detailed explanation.
This game was of course famous even around here: starting in the arcades, and then on the C64. Growing up in rural South Georgia, USA, EVERYONE I knew called it "Leh-MONS" complete with the 'S'.
I absolutely love watching your videos.
Brilliant! Loved that short series =D Bonus points for fixing that typo!
... or even BOUNS points! 😉
Great work!
I think spotting that typo is really hard if you're actually playing / watching the game since it appears for such a short period of time. Nice job fixing it!
I spotted it right away in the previous video.
Another great and informative video Robin! Great trick using characters typed into screen ram in the BASIC editor to easily get the screen code bytes! Thanks for sharing. :)
Actually, side note. When doing writes into the banked memories, they are going "through" to ram. So in order to do the copying part, you won't even have to switch out the rom. Of course, you'd need that later anyway in order to start the game. But I think you knew that Robin.
Yes, writes would go through to RAM so I wouldn't have to switch out the ROM before the first copy, from $0900 to $E000. But then for the 2nd copy the ROMs did need to be out as I chose to copy from $F000 to $3000 just to make the intention a bit more clear (in my mind, anyway). I could have copied from $1900 to $3000 to delay the ROM switch as late as possible, but that seems even less explanatory to me.
@@8_Bit agree completely. Would have done the same.
I watched/listened to the video again and I see that you're picking up on this part: "...reveals the RAM underneath, which is where we want to copy the cartridge to" and how it maybe implies that that the ROM had to be out to do the copy. So yeah, that's worth clarifying, thanks.
Last time I checked, Atari 8-bit cartridge dumpers (at least the 1 I used) could automatically save the ROM contents as a binary loadable program already. It doesn't take much. You start a file with the Atari Binary File header which (and I need to refresh my mind on this) is 6 bytes. 255, 255, start load address lo byte- hi byte, end load address lo-hi. Then the bulk of the data, then the next segment loads at a specific address (and I forget what it is) & all binary load files on Atari do this. It loads the Start or Init run address in 2 byte lo-hi address fashion. For cartridges, it's usually the same address because cartridges use the OS Run vector.
It's been quite some time & I need to look at my books about this, but it's super easy to dump cartridges on the Atari 8-bit & then binary load & run them. And it usually works unless they put in a copy protection routine to what we called "poke itself out of memory" since you can't over write a ROM. 👍
Regular C64 cartridges that map at $8000 are a bit easier; once saved they can be loaded into memory and then started by either pressing your reset button or SYS 64738. But these Ultimax cartridges, originally intended for the MAX Machine console, are a bit trickier. I imagine it'd be possible to automate this process but I assume nobody's bothered since it would be more work. By the way, there are some Commodore cartridges (VIC-20 and C64) that also do that same "poke itself out" copy protection trick. They probably got it from the Atari.
As a Frenchman the exact pronunciation of Le Mans is without "s" at the end. but it doesn't matter because we also don't know how to correctly pronounce a number of cities or states. Arkansas for example or Albuquerque 😅.
Same like the capitol of Iowa Des Moines (both s's are silent)
@@gcherowars6758 Indeed the names of city or states of French origin should be pronounced in French but I think that the pronunciation has become anglicized with time as for example Saint Louis whose "t" of Saint and the 's' of Louis do not pronounce. New Orleans same. in "Illinois" the "oi" is difficult to pronounce for anglophones...
That game reminds me a lot of Road Fighter, which I used to play a lot on a PS1 Konami classics disc.
That's super cool what you're able to do with 6502 assembly! I adore the major educational detail you put in your videos. I'd like to learn that language in more depth to achieve a life goal of making a new game for an old platform.
Keep up the good work!
I love Road Fighter!
Tbh, if I didn't look at the release date, I would've figured that this was a Road Fighter knockoff. :P
It also gives me a vibe of Sega's Monaco GP, from 1979.
@@comchia4306Yes, it's primarily inspired by Monaco GP. All these early HAL Laboratory games are actually clones of arcade games that were popular in Japan at the time.
We ❤ you & your videos regardless of how you pronounce certain words.
One other tiny glitch is at 24:57 with the stoplight. It seems to go from red to red to yellow to CYAN instead of green, but that may be because of a video capture artifact.
It may be because the lights are actually cyan in Japan (this being Japanese-developed).
@@fnjesusfreakInteresting! Indeed Hal Labs would go on to create some of the most iconic games ever for the NES.
I’ve got a very bad memory of this game. There was an arcade version and when I was 10 we went to Spain and I saw there was a credit on the game. There were some teenagers 16-18 talking and smoking (back then you were allowed to smoke and drink in the arcade section of the hotel - good ole times). And I press start. It so happened that the guy had put on some cash and was first smoking before he was going to play. He literally punched me so hard in the face that it knocked me down to the floor and I saw double.
And one of the other guys kicked me in the side before they quickly returned to the cabinet and started to play. Whilst I was rolling in agony and tears.
Always interesting , well presented and very educational.
TY. To start TMP you can also do: SYS 2^15 (perhaps a little easier to remember)
E-thousand, nice find, makes perfect sense :D
I love these videos. Although I have no idea about what we are doing😂
hi there.... there is a game called Hades on the c64 which cannot be completed because it glitches out. someone pointed out its because the corruption starts at the beginning of the basic rom... is there a way to fix it?
Interesting, I hadn't heard of that one. I looked into it a bit and it looks like the best version around was by Ian Coog of Hokuto Force, and if he couldn't fix it 100% then I doubt I could do better! I'll see if I can find out any more info about it.
I'm from the UK, I've been saying the S for over 40 years!
One thing I noticed about this game is the has a very similar character set to a lot of classic games on coin-ops of the era.
Le mans is great and all, but have you seen the '24 hours of lemons?'
Funnily enough, TH-cam's automatic captions spell it lemons.
When life gives you LeMans, make... a cartridge dump 😅
Haha, "...my 'Lemons' cartridge..."!
Could you use labels to calculate the basic end pointer? Ditto could you use an expression to convert the start address into a petscii sys string? Putting all this together would make a pretty handy macro if it worked.
It should be possible in this assembler to use labels for the pointer to the end of BASIC, but I think it's beyond TMP's abilities to handle the PETSCII sys string unfortunately, so some amount of hard-coding is necessary. However, I've seen at least one modern 6502 cross-assembler that can do the whole thing including the string very cleanly.
@@8_Bit hmm it can do logical expressions and basic arithmetic but doesn’t seem to do left/right shift. But could you use multiplication or division to do the shifting? Then you could use and to mask and just add 30 hex. Now to go spin up an emulator (haven’t played with C64 coding in …. Ooh 35 years maybe?) I love your videos - very amusing to watch you fix 40 year old bugs!
I've noticed that you change the contents of address $01 in the monitor program on the fly, but it's usually done between an SEI and CLI command in a program. Why can you safely change $01 in that monitor?
I also noticed that your block copy code uses as SEI but appears to be missing a CLI. I'm sure the code you call probably does a SEI again first, but for good measure I think I would include a CLI anyway :)
Dumping this code and making it run has been fun to watch. Thanks for another crystal clear explanation.
Super Snapshot does lots of behind-the-scenes magic to make the monitor behave like its independent of the C64 its running on. It tracks what location $01 should be from the user's perspective, but is actually dynamically changing it in the background, along with other registers, as needed, so it's safe.
re: not CLI'ing at the end, I think it's actually safer the way I've done it, as a rule. The Ultimax has no built-in ROM at all (no KERNAL, nothing) and it's up to the cartridge code to initialize CPU registers and flags. The first thing LeMans does upon boot/reset is SEI, in fact. If I CLI'd first then maybe an IRQ would happen before the initialization code ran, and maybe that would be bad. If I found the game didn't work properly without a CLI then I'd investigate why and add one to the init if necessary, but then I'd probably consider that a bug that the cartridge didn't properly initialize interrupts itself.
@@8_BitSome super snapshot magic going on there! I've always wondered what the likelihood is of things going wrong if I changed $01 around without disabling interrupts. Maybe a fun experiment :)
Not CLI'ing makes sense when you put it like that. Basically you're writing a prequel to the original initialisation. Disabling interrupts a little earlier is probably a good idea.
Thanks
Just to be sure I checked Google translate and "bouns" is not a French word.
Yeah if they wanted to say bonus, it would say something like "prix" or maybe "prime"
Nice! That’s some good work!
This was so dang tasty. Good one, Robin!
So when we addressing what causes the timer to tick faster later on?
There's at least one more video coming in a few weeks that will address that. Sorry I didn't state that in this video.
Suspect the best way to try out a cross compiled program on real hardware without owning it is to make a cartridge & try plugging it in at a museum or trade show.
I’ve had Lemans on floppy disk for a good 35+ years now. Were you not able to find it on a .d64?
I just wanted to learn (and show) how to do all these things (dump a cartridge, make it RUNnable) on my own.
That game is a classic early example that bad game logic has been around many years. What do I mean? Well, bad game logic is when a game does not do something you'd expect from what you experience in real life. Things like in current survivor games you could need a log to create just 1 plank when in reality 1 log will create a few planks or in this case your car having a light cone at night to show you have your headlights on but the other cars don't! lol
Le ManS 😉
Just kidding - wrote this only to obey the instructions at the start of the video. 🤣
Fortunately the world Bonus in French is La Prime, so it was a typo
I'm leaving a comment because it makes me feel better.
Is there a reasonable way to reverse this? If I want a CRT from a disk or tape, I assume it has to be modified to call the cartridge ram space, but it'd be cool to see the inverse.
If you've got an actual ".crt" cartridge image for use with emulators or Kung-Fu Flash etc, then check out the cartconv command line utility that's included with VICE emulator. It can go back and forth from binary, and .crt image. There's no automated way that I know of to go from what I show in this video, but with some experience it's fairly easy to examine the code in a machine code monitor and identify and extract the actual binary.
Where's Part 3? Video has been removed.
Ah! Thanks for catching that. I've updated the link in the video description so it should be correct now.
I'm not an expert in TMP but I wonder if it has an "include binary" pseudo op so you can simply ORG $900 and then include the binary. Though in a real 1541 that include might be painful to do on every assembly run.
That was fun!!
Lemans in English is usually pronounced with the S. In French you don't say the N either; you just say the A through your nose. :)
Is there any chance that you could do a series of programming a C64 game from scratch, with Turbo Macro Pro?
Maybe! Meantime, have you already seen my code walkthroughs for some of my already-made games in Turbo Macro Pro? I have a playlist called "C64 Game Development" on my channel page. Some of the video titles are "My First Paid Game Dev: Code Walkthrough of Frogs And Flies on the Commodore 64", "Exploring Marz: C-64 6510 Assembly Minigame Code Walkthrough", and my friend's game "Making a New Commodore 64 Game: 1nvader".
@@8_BitThank you kindly for your message. I'm going through your videos and I'm now starting that series. Saw yesterday the 1nvader and Darren did an awesome job. Your explanation is also super helpful. I'm starting reading the books you recommend but my brain doesn't compute Assembler yet :) Much study to do yet.
So what was the deal with the timer going faster? Was it a bug or a "feature"?
I think it's a feature, and that'll be covered very fully in the 3rd (and final?) video in April.
Instead of the JMP $E037 a generic solution would be JMP ($FFFC)
There’s going to be a part 3 to complete the Lemans Trilogy… right?! I mean we gotta find out how it’s calculating the time and everything. I just need confirmation. 😂
Yes, it should be out in a few weeks :)
The next part is writing the patched data to a PROM?
This is a comment I made about how to pronounce Le Mans correctly, but it did not made me feel better. I want my money back.
Fun episode. BOONS
maybe it would also be better to increase the duration of the message on the screen by a couple of seconds. now it’s too short
Why not just set gfxsrc=$1900 and only copy 16 pages in the first run, instead of copying the graphics data twice?
We're mimicking how the MAX Machine "sees" the cartridge. The Max's CPU can see the full 8K of the cartridge from $E000-$FFFF. The Max's VIC-II can see the upper 4K of the cart, $F000-$FFFF, but it sees it in the equivalent of the C64's bank 0 at effectively $3000. The upper 4K of the cartridge may contain both graphics and code/data, not just graphics, so it needs to be at both locations in the C64.
@@8_Bit Ah. So the C64 still needs to see what's at F000-FFFF, but the VIC II needs to see it at 3000-3FFF because it doesn't have a full set of address lines? And in MAX mode, the address select logic is tricked to map the VIC II to the cartridge space?
I think that's more-or-less it, yes. 65XX architecture typically requires ROM at the end of memory since the CPU vectors (particularly reset) are at $FFFx, so that's where the cartridge had to be mapped, and typically requires RAM at the start of memory (because zero page and especially the stack are located at $0000-$1FFF. So given that the VIC-II can only see 16K and it for sure needs to see RAM which is way down at $0000-$07FF, they needed some way of bringing the cartridge ROM into that same 16K range. The MAX Machine and a C64 in "Ultimax" mode do this re-arranging automatically, but since our C64 is not in Ultimax mode we have to simulate that arrangement with this copying.
Posting this comment it makes me feel better.
10:27 Page-aligning the source data also makes the copying faster, since there will be no page crossing with the indexed addressing.
11:34 You could amortize the «bne loop» by unrolling the loop a little.
14:48 Might look a little nicer with a space: «2023 SYS 2062».
15:43 I've heard it pronounced more as "le-mawh": th-cam.com/video/FDhofK4CNwQ/w-d-xo.html
17:01 Must be "Typoglycemia": Aoccdrnig to a rscheeahcr at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.
21:03 Copying the cartridge data from a lower location works around the problem of not being able to SAVE location $FFFF.
Danke!
Thank you!
@@8_Bit Thank *you*, Robin! I'm always amazed at how much in-depth info you are able to provide around the topics you address. And please be aware that you absolutely do explain complicated matters well enough for anybody who is sufficiently interested in the topics presented :).
It's definitely pronounced lemons lol.
.
Thanks Doug!
Funny how if you mispronounce anything not in your language, "if your american" everyone tries to correct you, but if you correct anyone for mispronouncing anything in ameican english people call you a "race car driver 😉" . Pull the sticks outta there people.
Uhm, it's pronounced Leeehmaaaan, like the baaaaaaank? Thaaaaaanks . ;)))))))
Oh, I feel so much better now. Thanks