The C64 version was quickly ported from the Atari 8-bit version, that Joe Hellesen did while contracting for Roklan, who was working on this for Atari. The code had various build-time defines in it that could turn it into an 8K binary, without intermissions, or a 16K binary with intermissions.
18:15 Something he missed: I think the title is also supposed to be yellow. You can see it earlier when he had colour mode enabled for the entire screen. It's entirely possible that was what they intended it to look like, but they ran into the fuzzy text issue and didn't have enough time (or space on the cartridge) to fix it, so they just disabled colour mode.
When you said "it looks black and white and stripey" I was so excited because I knew EXACTLY what happened. Ah, I loved programming on C64. I wanna get back to it!!
@@generalawareness101 I got into it late, 1993. We couldn't afford a computer, so I had a C64 from 1993-1999. I didn't care that it was "obsolete" because I still learned a lot about programming from it, and would work as a programmer from 1999-2002. Sometimes I miss it, sometimes I don't.
@@anactualmotherbear Well, I even made a couple of programs that were sold for the C64 so that was my golden years for sure. I moved on to an Amiga 500 around 86. I had someone steal a 1541 from me in 1986 but I still have my C64 from 1983, Datasette, and one, or two, of the 1541s. I had the Monitor but that is long since gone. I moved years ago and just laid the Amiga stuff at the Goodwill door, but not my C64. Funny thing is I haven't programmed a C64 in 36 years YET I saw the code in the video and knew exactly what it was (the addresses for video etc... I didn't but a book would easily refresh my memory on that). Btw, I used the old Amiga 500 until I migrated to a Pentium 166, then a 233 MMX, Intel based machine in 1996. Did you know that the Amiga was faster than a 233 mmx for computation? Good old Motorola 68000 blew Intel out of the water. The AMD K62-500 was my next upgrade and finally for FFT Soundforge stuff it finally was faster than my FFT software I wrote in pure 68k ASM. Pretty sad that a 7mhz machine easily beat out a 233mhz machine. Oh, and I stopped programming for about 5 years because the Intel is a turd based CPU. So many opcodes, and operands, that are archaic just taking up precious room. What got me is on the Amiga I could load a file all the way until it ran out of memory BUT on the Intel Pentium I had to use pages. Pure junk and I got so disgusted I didn't touch programming from 1998 to 2004ish again. I then went into C++ where I stayed. I do miss the simpler times.
Talk about tight on memory. It seems like if they noticed this issue early enough they would have been able to fit a fix into the 8k. Reusing the existing clear routine they could pass a 0x07 or a 0x0f to the routine for the main fill and with a few extra instructions (10 additional bytes needed?) set the two fruit bytes to 0x0f. If the callers of the clear routine had done “LDA #$07” or “LDA #$0F” before the call (eliminating the LDA in the clear routine) that would be two extra bytes. Then the “LDA/STA/STA” for the fruit bytes would add 8 bytes. If they had the original source code when porting the game it seems like they could have come up with 10 bytes. Of course if they realized it late they might have already optimized it heavily for size and didn’t have time to fit in a fix.
This was a fun one to follow along with. I actually use PACMAN as one of my many testing programs for newly repaired C64s and the monochrome title screen always bugged me since I knew the fruit sprites surely were meant to be in color.
0:21 If they don't supply a fastloader, it seems kind of wasteful to spend a bunch of time loading in a corporate-logo bitmap. 1:54 If they'd used multicolor sprites for the ghosts, they could have had eyes. 3:39 Extra-hard to shoplift! 6:03 Looks like Courier and Comic Sans had a baby! 9:58 The "PAC-MAN" title text is also now yellow like it's supposed to be. 18:32 I guess this tells us that thanks to the C64's sprites, the game logic doesn't doesn't need much processor time, since it can withstand a big portion of the CPU cycles vanishing. 19:53 Oh, I didn't know the C64 can do that. I knew that the VIC-20 can. I suppose it gives a lot more capability if you can mix hi-res and multicolored characters. 27:59 I'd expect programming on a modern computer to be much better, too. 28:41 Why would anyone after the 1970s believe that "a.out" is a good filename for an executable? 30:12 You could put the compressed version into a ROM at a different location, copy the content to the start of BASIC, and decrunch it to $7FE0.
28:41 a.out has been the default name for an executable since the Unix days...on Kernigan and Ritchie's PDP, Multics (from which Unix was derived), had an assembler, which was invoked with the "a" command. There was also a programming language on the system called "b". So when K&R made their own language, guess what name they picked 😅
Atarisoft learned how to better use the C64's sprites in _Ms. Pac-Man_ , which has ghosts with eyes, as well as hi-res Ms. Pac-Man and fruit. Or at least they decided to make it different (and better) than the Atari 8-bit version, while _Pac-Man_ for the C64 is a clone of the Atari 8-bit version, and includes all of that platform's limitations. They also mixed multicolor and hi-res characters using the attribute/color map in _Ms. Pac-Man_ . The main advantage of doing it this way instead of using raster interrupts is that you can do it per character cell, including horizontally across the screen. By the way, a worse example of cloning instead of improving is Datasoft's _Bruce Lee_ game. It's still a good game, but the C64 version has all of the sprite limitations of the Atari 8-bit original, and furthermore was implemented in a really bad way. If they simply wanted to clone the original game, all it should have taken was 3 multicolor sprites (one of which would be all-black). But somehow the programmer managed to use all 8 sprites in a manner similar to the Atari version, and wastefully copied sprite data instead of simply changing pointers like how it should be done on the C64. The sprite handling code was so inefficient that it actually forced some frames to be skipped whenever there was fast movement. The C64's sprite system should have allowed for more detailed and colorful Bruce, Yamo, and Ninja characters, with plenty of CPU cycles left over (more than on the Atari, on which copying data is necessary for both vertical movement and animation), but instead the C64 can barely support the game!
Another obscurely interesting & informative video Robin! BTW, 1:35-1:45 is the actual original starting pattern for that stage. Next you can fix the “bug” where Pac-Man just glides across the screen at certain times without “munching.” If you did address that in this video, I may have missed it and apologize. I’m ready to pass out and didn’t have a full watch through in me atm. I intend to rewatch it to pay attention to your code breakdown.
Hi Jeff! I've never noticed Pac-Man not "munching" while playing the game, but the animation does occur really fast so his mouth opening and closing seems to be a 30 Hz flicker which is difficult to see (and I'd guess if this video is being viewed at 30 fps maybe it'd be invisible?) If it's happening in this video, can you send a timestamp so I can examine? Pac-Man's animation should probably be slowed down.
On a hunch I deliberately switched TH-cam to 480p which I think (maybe) also downgrades to 30 fps, and saw that Pac-Man stops munching sometimes. But as long as I'm in 720p60 or higher it looks fine. I think sometimes TH-cam is just showing e.g. even frames from my C64 capture, so it looks like his mouth is stuck open (or maybe closed) not animating - but on the real C64 you can always see it animating.
So, here is a lazy thought... 😁 Since the uncompressed version of your PACFIX.PRG is too large for an 8K cartridge, but the compressed version is only about 6.5K. Why not put that one on the cartridge? - You'd obviously need the "CBM80" at $8004 and all that gas, to make it detect and fire up the cartridge as normal, followed by a small copy routine which copies the compressed version from where it is stored in the cartridge area down to $0801 in memory, plus an extra little code-snip to be called afterwards, that first disables the cartridge ROM before JMPing to $080D (2061 in decimal). - This solution even gives you about 1.5K extra compressed data, for a lot more patches to be added outside of the original's $8000-$9FFF area. Say at $7000 or $7800...
If it's a game that has to sit in RAM anyways, that's a way to do it. But it will break compatibility with the MAX Machine but work fine with the C64 GS because it has the full RAM.
I think it's a great thought! How many people own a MAX machine? 0% of the many Commie fans I know. -- An interesting video would be how many / which games do *not* run on the MAX! It could be pretty long...
The copy routine would first need to copy the copy routine outside of the csrtridge area before the cart area is switched out. Otherwise the jmp to 080d wouldnt be there anymore. Otherwise, it's a genius idea from you.
@@larswadefalk6423 Yeah obviously, maybe I didn't write that part clearly enough. That code-snip should be added to the end of the compressed data and be copied with it. Then started (JMPed to) in its copied position after the copy has been completed.
Don't forget, in the old days there were sometimes big boxes to help fight stealing. It's hard to fit that in your pocket and if you rip it out there's a chance you'll be seen or heard.
Another example: music CDs were packaged in those tall longboxes as an anti-shoplifting measure. Adding electronic article surveillance tags and gates was a key to allowing the package to shrink, as well as big-box retailers wanting to fit more products in the same shelf space.
@@logiciananimal Originally, the Cartridges were meant to fit into the C64's ROM Space of 16KB via Bankswitching. But almost all lines from the CPU are exposed, so you can have bigger carts with simple logic.
Arlasoft, I absolutely LOVE your version! It's so accurate to the arcade version that it'd have blown the competition out of the water! There are a few bugs in it though, like I _think_ the Ghosts being a tad too fast or slightly inaccurate or turning white for a frame when you eat them, which I assume will be fixed next update. I _do_ have a question and the reason I'm asking the following is because I'm working on a MASSIVE Pac-Man Port retrospective and review video, but would you ever want to attempt to make a version of Pac-Man for the Commodore Plus/4 and/or Commodore 16? Visually it doesn't have to be perfect, but I just figured that having a Pac-Man game on there that actually has an accurate maze with decent gameplay would be a DREAM!
Brilliant Robin. Knowing exactly how the C64 handles colour is a valuable skill that is lost on me most of the time. This is definitely a neat solution.
I sort of like the "glitchy" ghosts... they look more like an occult hood that way and a bit scarier, although still cute, if that makes sense. Cool bit of software forensics!
C64 was my first computer and I played with BASIC and games. But seeing a master doing stuff in assembler is mind blowing. Today you create games with high level languages and all kind of engines like unity but back then you had assembler and basic. I can't imagine how hard it was back then to need to type hundreds of lines of assembly first only to see something on the screen, let alone a complete game. I am envious of oldschool devs.
Robin you are a true gem. I may not have a clue on Assembly coding but you always have a knack of making things incredibly interesting -- revealing these never before seen hidden sides. Always must watch tv. Killer content!
Nice work. This reminded me of the original arcade machine which also had a bug in it's code in the ghost's logic for chasing the player. I created my own Deluxe Pacman game which uses the arcade's algorithms on hard mode and corrected the error. It was quite fascinating to read up on how the arcade did things.
@@8_Bit Strange, I already answered you and it isn't here, possibly because I included a link to it? Anyhow, no, I made it for the IBM PC after Commodore went bankrupt I switched to the PC and my wife missed playing Deluxe Pacman for the Amiga (by Edgar Vigdal, who sadly passed away in 2015, my wife passed away last year as well) so I decided to program my own version of the game for the PC (with Edgar's blessings, I had emailed him at the time). I have it available for free now, always been free. Even has a level editor. There's Deluxe Pacman 1 and 2. Originally for DOS, I made versions for 256 colour Windows back then, and later I made a 32bit colour version for newer windows and eventually I remade the game and created Deluxe Pacman 2 for modern Windows. The last version update was in 2018 for Windows 10. I released the source code a while ago for the DOS version and Deluxe Pacman 2. The original code is scary to look at as I was still new to C programming at the time (end of the 1990s). I used the Allegro library for all versions (similar to SDL, except Allegro was around long before SDL was). The game was put out for free and so it has been downloaded millions of times world wide, which has blown me away. I have heard from people that tell me they grew up playing my game as a child, which makes me feel good. On my page I have videos of the game with links to the game (on github, but just a website with zips, not a normal github repo) if you're curious in the game, or the source code. :)
One of my favorite videos you have done! Thank you very much for the content. I love the detail and explanation given throughout the video. Look forward to many more.
There’s another bug in the Atari 8-bit iteration of this game, where the energizer on the 5th, 7th and every key wave thereafter gives infinite blue time on the ghosts-if left uneaten. I wonder if this error was ported over to the C-64 version? This budget issue disk might still be “broken”?
Interesting - I'm sure I've played the C64 version at least to the first key wave and have never noticed infinite blue time, so I think it doesn't have that bug. But it'd be interesting to look into the Atari 8-bit version. Do you know if anyone's ever fixed that bug for the A8?
Fascinating. First time I ever played this version of Pac-Man I guessed that it wasn't putting the characters into multicolour mode properly. Fun to see it fixed.
Every time you say Thunder Mountain I feel like you mean to say Thunder Bay, for some reason. This repetitive releasing of the bug reminds me of my last job where we kept releasing versions with the same crappy, buggy components because they were never high enough priority in Bugzilla to fix. We spent more time reviewing the bugs over and over in meetings than it would take actually fixing them
Pinball construction set also neglected the multicolor register. The most obvious bug in Pac Man is the mouth moving too fast. Standards in those days weren't as high as now.
Having worked at different types of game dev houses, there’s a chance that the title screen was that way intentionally. A producer might have liked it that way (I’ve had that type of thing happen.) Maybe they did do it multicolor (the logo was made for color) but someone didn’t like the text. Maybe they didn’t have time, especially given cartridge space, to do such a “minor” thing. Or maybe, yeah, no one noticed. Who knows without talking to the original people involved.
It looks like a pretty straight port from the Atari 8-bit version, but the Atari 8-bit version's title screen used a wide colored text mode that doesn't necessarily translate straight to the C64. I'm guessing they realized that without more development effort, it would be a tradeoff between showing the title screen in color and making the text as readable as they could, and they just went with the easiest and fastest option. Often software development involves a lot of triage--you want to fix everything, but you want to ship on time as well, and sometimes you have to pick your battles. Atarisoft was churning out game ports to a large number of platforms at a wicked pace around this time. And the development platforms they were using weren't like modern emulation environments.
This was very enjoyable. I haven't coded 6502 since the late '80s and that was on a BBC Micro not a C64. As soon as you started typing in your patch I knew that a BNE was coming after the DEX. It's funny how I remember that stuff.
I played PAC-MAN a lot on my C128 as a kid. I'm talking something like 32-35 years ago so, maybe I'm just wrong... That title screen with gray characters feels extremely weird to me. Same as your first attempt, with the multicolor text... Just weird. But when I've seen the title with yellow letters and the right fruits, it felt like seeing and old friend... Could I've been playing a "fixed" version!??? No way of knowing. All the tapes and disk from that time, are long gone by now... Amazing video. As always :)
Hi. I just wanted to say that this was incredibly cool. I've never seen someone cook up a patch for a live game before, and now I have a better idea of what all goes into it.
Just a thought.....when in multi colour mode the top bit (3) of the colour in colour ram switches between multicolour mode and hires mode. It would of been easier to just change the colour of the text (0-7) to switch to hires.
That's what he did for the final fix. He copied/modified the original code to use high-res color 7 (hi bit clear) and then for two cells where fruit is shown he did a POKE (err, STA) with multi-color 15 (hi bit set). The other change was to actually enable multi-color mode ($d8) on the title screen. -- I'm glad Robin actually did / showed us that hack, other wise I would have made the same complaint :)
No, the main reason of big boxes like this was to draw attention to them when sitting on the shelves. The bigger the box and more colorful the art etc the better the promotion value. To bad at some point almost everything switched over to Amaray style cases. But somewhat understandable since costs were reduced and stores could stock up many more titles.
Love it. Reminds me of old apple rom days. Should add two patches though. Keep the Pac-Man logo in color AND the fruit in color with the text in Hi-res. Never mind….you read my mind before I finished the video.
I don't think the text on the title is supposed to also be yellow (yes the logo needs to be yellow), but the text should probably be white or purple (it looked better that way imo) ... and not yellow... still though, even with all the text yellow, it looks better than before, and I think with that btw routine, it could be fixed, so nice work! Also I really liked the use of PC tools to convert the prg and do the crunching. That's really cool.
Nice feature about the bug in the classic game. The fruit sure did not look right in hi-resolution. The machine code patch made it look much better. I also agree with Exomizer, being an essential for programmers. Back before internet was the norm, I used to use native C64 crunchers, which took longer. The best one required 256K extra RAM, but during that time, I never had that. So I relied more on the Fast Cruel Cruncher or Cruncher AB fast mode, because I didn't want to wait for ages for my production to crunch :)
Pretty good fix but I think it would look even better if you added a few more interrupts to keep the high rest text white / gray and the Pacman yellow and the fruit multicolor as you have it. The yellow text is fine but it would look just a bit better with more variety IMO. Also for memory you probably mentioned this but with a bit more hacking you can usually find the bytes you need. There's always some waste. Good work!
Be good to do a follow up video to this. To fix up the bug pointed out in the comments when you go back to the title screen. Possibly look at the hiscore issue and maybe making the ghost sprites 3 colour. Then see if the compressed version after fixes can still fit on a cart.
Why not incorporate a decruncher in the EPROM? The only issue I see is once decruched, enabling the RAM back into the cartridge space (to copy the decrunched code) instead of the cartridge. I'm not sure if that is possible with a C64. If it is, well, there's your extra space
It's been decades since I wrote machine code on the C64. Seeing that code sure brought back a lot of good memories. Some memories of working through the night to get my code finished. LOL The last C64 i had, I sold about 18 years ago. It was my beloved SX64. I loved that thing. Oh well. TIME PORTALS! AM I RIGHT! ROFL
Im actually using RiscOS 5.28 on a Pi A+ for re-learing and catching up on BASIC programming using BBC BASIC. The last time I programmed a game in BASIC it was done on my 386 back circa 1996 on QBASIC with DOS 6.22. I even x86 compiled it into a .exe. Programming is not my forte, but imma learn.
Night Mission Pinball is suffering from a similar problem. Those monochrome vertical stripy graphics always bothered me. Wasn't sure if it was a lazy port or a bug.
This was such a fun video to watch! Robin you explain things so well, it makes us all experts. lol - I had to try my Atari 800XL cartridge to remember what it looked like on that system. It's so bold and brightly colored. I'll have to find my PacMan for the C64. I never noticed the black and white title screen. I was too interested in getting to the game. Wonder what it's like on the Apple IIe? Good stuff! Thanks Robin
It looks like Atarisoft were going for a similar title screen as on the Atari 8-bit port. The games themselves are practically identical, after all (unlike the case of _Ms. Pac-Man_ , which had a bigger budget and a 16K ROM). Obviously it would have taken more work to make the text characters twice as wide to match those on the Atari title screen, so that was out, but the different text colors could easily have been replicated. I think it's becoming clear at this point that, as you suggested, they might have run out of room (on the 8K ROM) and/or time to do things properly. When the programmer(s) realized that there was only room for a single color map initialization routine, the title screen that was almost certainly intended to closely resemble that of the Atari port (except for character width) was history. They did what they could with the space and time available. If you really want to fix this bug, then in addition to what you've done already, you need to color some of the text differently to match that of the Atari port (bonus points if you make the text twice as wide, as well). The easiest way, obviously, is to create and copy over a custom color map, which takes a lot of memory for an 8K cartridge, but since you're saving to disk, it doesn't matter.
Hi! I don’t know if you noticed but the pac-man title at the top of the title screen also appreciated multicolor mode and became a pleasing yellow that was then removed with your raster wedge Edit: ok I see you made the whole screen text yellow at 26:40. I like it better with the title jumping out yellow and the rest of the text gray 😅
Hi Robin, this was fun. And I like your videos, too. In a German computer magazine called "64'er Issue 08/1988" there was a BASIC program called "Modulgenerator" (cartridge generator) to create an auto start BASIC or ML program. Your new program would easily fit because you can only use programs less than 30 blocks. And in another 64'er magazine is a ML routine to move your "cartridge ROM" to the necessary location. So far as I know there is also a build-in routine in the KERNAL/(BASIC) to move the program. But why not write your own move routine for this game?
@@FadkinsDiet Four raster interrupts? I don't see why any raster interrupts are needed at all, as the C64's multicolor character mode can switch between multicolor and hi-res modes on a per-character-cell basis, via bit 3 of the attribute/color map at $D800.
@@rbrtck If MCM, and as long as the hi-res colors are limited to the first 8 then you're right . In the general case of the hires characters needing colors 8-15, you do need interrupts. (and obviously MBM is something different too, that's what I was thinking of)
Pacman is the kind of game that would definitely be rushed to make a (holiday shopping?) deadline. The 2600 version seems sloppy, as if the released version was a tech demo of the feasibility of a port.
Would it be possible to create a Flag Byte in free memory that is Set during the Title Screen, and Cleared during the actual Game, and use it to Execute the original code during the Game, and the Patch code during the Title Screen? Unfortunately I think this might require the New Patch to replace the entire $8583 Subroutine.
Next up, you should try and fix why the PacMan sprite doesn't always open and close its mouth while traveling. Looking at several parts of the video, it doesn't seem do depend on the existence of dots to be eaten, or the position on screen or even direction, so it should be an interesting bug to fix.
That seems to be an issue with TH-cam showing the video at 30 fps. Rewatch those sections with the player set to 720p60 or better and you should see the mouth continue to move.
Fun video, I love to see the old systems load everything into the memory and you can just inspect and change it. I wonder if this kind of technique is still possible on a Windows PC games, GPU etc
Isn't the logo for pacman ACTUALLY supposed too look exactly like that, yellow and fat characters? And, though obvious, the task is also to find any free area for patches inside the cart area.
After starting a game, hitting F5 returns to the title screen which then reverts to the blurry text. Perhaps that 2nd JSR is subsequently used every time thereafter.
@@8_Bit I miss and I don't miss 6502 assembly language! It's so limited compared to x86 and x64 assembly, which I do a lot of now but it was so nice using assembly on the C64 because it was leaps and bounds faster than that version of BASIC they gave us. I have patched stuff in a similar manner to what you did here. When there isn't enough room to fit your fix/change, you JSR or CALL to another memory location and assemble at that location. I've taken x64 code and actually wrote my own code over a useless function and made sure to disable the actual call to that function so it didn't crash. Trying to think of an example... the code for the BUY NOW button in a demo version but you've already registered it so it's impossible for that button to appear (and that code to run.)
@@8_Bit Both JSRs are executed when F1-starting a game, but none are called when returning via F5 LOL. (Might have spent more time futzing with it.) I suspect there might be a branching logic bug remaining.
NOPE!, MSX1 version by NAMCOT is not stretched, 1983! (TMS9918). That C64 version looks like it has lots of extra-dots in the map, which breaks the exact experience from the arcade.
Ahhh the nightmares for some 40 years, a monochrome fruit supposed to be in color. lol Then Robin goes: "Hold my fruit! We're just going to use a raster interrupts to turn on color mode just above the fruit, and high res mode thereafter." heh I was wondering if there's any free space available within the 8K of the cartridge memory for 30 or so patch bytes. Perhaps running a binary/ pattern search for a short sequence of 00 or FF might reveal a small block of unused bytes which could be used to include the patch. I can't imagine that every single byte within the 8K would be all used, even if you could find several unused 10 bytes, the patch could be broken up into those blocks, thus maintaining the true 8K cartridge size.
The big box for the cartridge game was meant to dissuade cash-strapped youth from putting it in their pocket without paying. Would multicolour mode be enabled at boot up if you used an earlier version of the kernal?
Only the original programmer knows why the monochrome fruit bug was originally introduced, though it was most likely some combination of oversight and time crunch. But not fixing the bug during the porting process isn't that surprising. Why risk fixing something that doesn't really need fixing? After all, there is no bug fix too small or too easy that it can't cause regressions. That's a painful lesson I have learned more than once during over 30 years of programming. The bug doesn't affect game play, and the start screen matches the original C64 version exactly.
In Brøderbund Softwares "Choplifter" for the Commodore 64, the look of the chopper and people always bothered me - it looks like they were meant to be single-colour hi-res sprites, but for some reason they are lo-res multi-colour in stead. Would be interesting to see if it is fixable 40 years later.
The Atari 8bit version of Pac Man looks exactly like the C64 version, however the sound it makes when you eat a blue ghost is horrific, loud and irritating. Yet the C64 version dosen't sound like that. Why? Maybe it's a bug that's lasted for the past 40 years, maybe it can be finally fixed?
Either sprites or multicolor character mode alone (no raster interrupts) would have sufficed. Using more than one sprite would have allowed for hi-res fruit, as well. But then again, not much effort was put into the port of the game itself, to begin with. It's a straight port of the Atari 8-bit (and 5200) version, with all of the sprite limitations of that platform. A much better job was done with _Ms. Pac-Man_ on the C64, which has ghosts with eyes (4 multicolor sprites) and hi-res Ms. Pac-Man and fruit (2 hi-res sprites each, utilizing all 8 sprites total). This port was made specifically for the C64, while _Pac-Man_ was literally the same game as on the Atari, with an unfinished title screen. I think the reason the title screen was left unfinished was that they had run out of room on the 8K cartridge ROM, since they needed the right color map to make it look as intended, while on the Atari it was done in a different way that had more limitations but required less data. _Ms. Pac-Man_ was done better because Atarisoft had more of a budget to work with, in addition to a 16K ROM.
Regarding the title screen…perhaps the whole screen is B&W since it looks like the title PAC MAC should have been in yellow? Regarding the big box…to deter shoplifting?
![Shareปลาวาฬ ส่งท้าย SS1 พาเปียโน ขึ้น Ferrari ก่อนไปขาย แลก Nissan l [Nickynachat]](http://i.ytimg.com/vi/KAknGkTNIvg/mqdefault.jpg)
The C64 version was quickly ported from the Atari 8-bit version, that Joe Hellesen did while contracting for Roklan, who was working on this for Atari. The code had various build-time defines in it that could turn it into an 8K binary, without intermissions, or a 16K binary with intermissions.
I didn't know any of that. The intermissions make it better. 🙂
I love love love this kind of step by step debugging, manual lookup, and iterating on a fix. It’s so valuable to see what *doesn’t* work on the way!
18:15 Something he missed: I think the title is also supposed to be yellow. You can see it earlier when he had colour mode enabled for the entire screen. It's entirely possible that was what they intended it to look like, but they ran into the fuzzy text issue and didn't have enough time (or space on the cartridge) to fix it, so they just disabled colour mode.
watch till the end
“Cherries are red
And this other thing(?) is blue
Just the flip of a single bit
And the colours are back for you”
Roses are red, violets are blue
Watch Robin turn cherries
red color for you. :D
When you said "it looks black and white and stripey" I was so excited because I knew EXACTLY what happened. Ah, I loved programming on C64. I wanna get back to it!!
Back in 1983 I cut my teeth on the C64 with Basic then two weeks later I went straight into ASM/ML to never look back. Loved those days.
@@generalawareness101 I got into it late, 1993. We couldn't afford a computer, so I had a C64 from 1993-1999. I didn't care that it was "obsolete" because I still learned a lot about programming from it, and would work as a programmer from 1999-2002. Sometimes I miss it, sometimes I don't.
@@anactualmotherbear Well, I even made a couple of programs that were sold for the C64 so that was my golden years for sure. I moved on to an Amiga 500 around 86. I had someone steal a 1541 from me in 1986 but I still have my C64 from 1983, Datasette, and one, or two, of the 1541s. I had the Monitor but that is long since gone. I moved years ago and just laid the Amiga stuff at the Goodwill door, but not my C64. Funny thing is I haven't programmed a C64 in 36 years YET I saw the code in the video and knew exactly what it was (the addresses for video etc... I didn't but a book would easily refresh my memory on that). Btw, I used the old Amiga 500 until I migrated to a Pentium 166, then a 233 MMX, Intel based machine in 1996. Did you know that the Amiga was faster than a 233 mmx for computation? Good old Motorola 68000 blew Intel out of the water. The AMD K62-500 was my next upgrade and finally for FFT Soundforge stuff it finally was faster than my FFT software I wrote in pure 68k ASM. Pretty sad that a 7mhz machine easily beat out a 233mhz machine. Oh, and I stopped programming for about 5 years because the Intel is a turd based CPU. So many opcodes, and operands, that are archaic just taking up precious room. What got me is on the Amiga I could load a file all the way until it ran out of memory BUT on the Intel Pentium I had to use pages. Pure junk and I got so disgusted I didn't touch programming from 1998 to 2004ish again. I then went into C++ where I stayed.
I do miss the simpler times.
Do it!
Talk about tight on memory. It seems like if they noticed this issue early enough they would have been able to fit a fix into the 8k. Reusing the existing clear routine they could pass a 0x07 or a 0x0f to the routine for the main fill and with a few extra instructions (10 additional bytes needed?) set the two fruit bytes to 0x0f.
If the callers of the clear routine had done “LDA #$07” or “LDA #$0F” before the call (eliminating the LDA in the clear routine) that would be two extra bytes. Then the “LDA/STA/STA” for the fruit bytes would add 8 bytes. If they had the original source code when porting the game it seems like they could have come up with 10 bytes.
Of course if they realized it late they might have already optimized it heavily for size and didn’t have time to fit in a fix.
You are very good at explaining stuff like this, I know nothing about assembler but found it very easy to follow. Thanks
your videos inspired me to build my own super snapshot cart from scratch, what a powerful tool it is. thanks for the inspiration and enthusiasm.
This was a fun one to follow along with. I actually use PACMAN as one of my many testing programs for newly repaired C64s and the monochrome title screen always bugged me since I knew the fruit sprites surely were meant to be in color.
0:21 If they don't supply a fastloader, it seems kind of wasteful to spend a bunch of time loading in a corporate-logo bitmap.
1:54 If they'd used multicolor sprites for the ghosts, they could have had eyes.
3:39 Extra-hard to shoplift!
6:03 Looks like Courier and Comic Sans had a baby!
9:58 The "PAC-MAN" title text is also now yellow like it's supposed to be.
18:32 I guess this tells us that thanks to the C64's sprites, the game logic doesn't doesn't need much processor time, since it can withstand a big portion of the CPU cycles vanishing.
19:53 Oh, I didn't know the C64 can do that. I knew that the VIC-20 can. I suppose it gives a lot more capability if you can mix hi-res and multicolored characters.
27:59 I'd expect programming on a modern computer to be much better, too.
28:41 Why would anyone after the 1970s believe that "a.out" is a good filename for an executable?
30:12 You could put the compressed version into a ROM at a different location, copy the content to the start of BASIC, and decrunch it to $7FE0.
28:41 a.out has been the default name for an executable since the Unix days...on Kernigan and Ritchie's PDP, Multics (from which Unix was derived), had an assembler, which was invoked with the "a" command. There was also a programming language on the system called "b". So when K&R made their own language, guess what name they picked 😅
Atarisoft learned how to better use the C64's sprites in _Ms. Pac-Man_ , which has ghosts with eyes, as well as hi-res Ms. Pac-Man and fruit. Or at least they decided to make it different (and better) than the Atari 8-bit version, while _Pac-Man_ for the C64 is a clone of the Atari 8-bit version, and includes all of that platform's limitations. They also mixed multicolor and hi-res characters using the attribute/color map in _Ms. Pac-Man_ . The main advantage of doing it this way instead of using raster interrupts is that you can do it per character cell, including horizontally across the screen.
By the way, a worse example of cloning instead of improving is Datasoft's _Bruce Lee_ game. It's still a good game, but the C64 version has all of the sprite limitations of the Atari 8-bit original, and furthermore was implemented in a really bad way. If they simply wanted to clone the original game, all it should have taken was 3 multicolor sprites (one of which would be all-black). But somehow the programmer managed to use all 8 sprites in a manner similar to the Atari version, and wastefully copied sprite data instead of simply changing pointers like how it should be done on the C64. The sprite handling code was so inefficient that it actually forced some frames to be skipped whenever there was fast movement. The C64's sprite system should have allowed for more detailed and colorful Bruce, Yamo, and Ninja characters, with plenty of CPU cycles left over (more than on the Atari, on which copying data is necessary for both vertical movement and animation), but instead the C64 can barely support the game!
Another obscurely interesting & informative video Robin! BTW, 1:35-1:45 is the actual original starting pattern for that stage.
Next you can fix the “bug” where Pac-Man just glides across the screen at certain times without “munching.” If you did address that in this video, I may have missed it and apologize. I’m ready to pass out and didn’t have a full watch through in me atm. I intend to rewatch it to pay attention to your code breakdown.
Hi Jeff! I've never noticed Pac-Man not "munching" while playing the game, but the animation does occur really fast so his mouth opening and closing seems to be a 30 Hz flicker which is difficult to see (and I'd guess if this video is being viewed at 30 fps maybe it'd be invisible?) If it's happening in this video, can you send a timestamp so I can examine? Pac-Man's animation should probably be slowed down.
On a hunch I deliberately switched TH-cam to 480p which I think (maybe) also downgrades to 30 fps, and saw that Pac-Man stops munching sometimes. But as long as I'm in 720p60 or higher it looks fine. I think sometimes TH-cam is just showing e.g. even frames from my C64 capture, so it looks like his mouth is stuck open (or maybe closed) not animating - but on the real C64 you can always see it animating.
So, here is a lazy thought... 😁
Since the uncompressed version of your PACFIX.PRG is too large for an 8K cartridge, but the compressed version is only about 6.5K. Why not put that one on the cartridge?
- You'd obviously need the "CBM80" at $8004 and all that gas, to make it detect and fire up the cartridge as normal, followed by a small copy routine which copies the compressed version from where it is stored in the cartridge area down to $0801 in memory, plus an extra little code-snip to be called afterwards, that first disables the cartridge ROM before JMPing to $080D (2061 in decimal).
- This solution even gives you about 1.5K extra compressed data, for a lot more patches to be added outside of the original's $8000-$9FFF area. Say at $7000 or $7800...
If it's a game that has to sit in RAM anyways, that's a way to do it. But it will break compatibility with the MAX Machine but work fine with the C64 GS because it has the full RAM.
@@AmstradExin Which is why I called it "a lazy thought".
I think it's a great thought! How many people own a MAX machine? 0% of the many Commie fans I know. -- An interesting video would be how many / which games do *not* run on the MAX! It could be pretty long...
The copy routine would first need to copy the copy routine outside of the csrtridge area before the cart area is switched out. Otherwise the jmp to 080d wouldnt be there anymore.
Otherwise, it's a genius idea from you.
@@larswadefalk6423 Yeah obviously, maybe I didn't write that part clearly enough. That code-snip should be added to the end of the compressed data and be copied with it. Then started (JMPed to) in its copied position after the copy has been completed.
An interesting fix, I'm sure that a full fix is now only days away, especially noting the comments already! Thanks Robin!
Don't forget, in the old days there were sometimes big boxes to help fight stealing. It's hard to fit that in your pocket and if you rip it out there's a chance you'll be seen or heard.
Another example: music CDs were packaged in those tall longboxes as an anti-shoplifting measure. Adding electronic article surveillance tags and gates was a key to allowing the package to shrink, as well as big-box retailers wanting to fit more products in the same shelf space.
Definitely looks like a lack of memory and/or time, I'm glad I didn't have to fit my version in 8K!
Love your version, Nick
Could cartridges be larger? (Of course, larger would cost more ...)
@@logiciananimal Originally, the Cartridges were meant to fit into the C64's ROM Space of 16KB via Bankswitching. But almost all lines from the CPU are exposed, so you can have bigger carts with simple logic.
Arlasoft, I absolutely LOVE your version! It's so accurate to the arcade version that it'd have blown the competition out of the water! There are a few bugs in it though, like I _think_ the Ghosts being a tad too fast or slightly inaccurate or turning white for a frame when you eat them, which I assume will be fixed next update.
I _do_ have a question and the reason I'm asking the following is because I'm working on a MASSIVE Pac-Man Port retrospective and review video, but would you ever want to attempt to make a version of Pac-Man for the Commodore Plus/4 and/or Commodore 16? Visually it doesn't have to be perfect, but I just figured that having a Pac-Man game on there that actually has an accurate maze with decent gameplay would be a DREAM!
Brilliant Robin. Knowing exactly how the C64 handles colour is a valuable skill that is lost on me most of the time. This is definitely a neat solution.
I sort of like the "glitchy" ghosts... they look more like an occult hood that way and a bit scarier, although still cute, if that makes sense. Cool bit of software forensics!
C64 was my first computer and I played with BASIC and games. But seeing a master doing stuff in assembler is mind blowing.
Today you create games with high level languages and all kind of engines like unity but back then you had assembler and basic.
I can't imagine how hard it was back then to need to type hundreds of lines of assembly first only to see something on the screen, let alone a complete game. I am envious of oldschool devs.
Robin you are a true gem. I may not have a clue on Assembly coding but you always have a knack of making things incredibly interesting -- revealing these never before seen hidden sides. Always must watch tv. Killer content!
Nice work. This reminded me of the original arcade machine which also had a bug in it's code in the ghost's logic for chasing the player. I created my own Deluxe Pacman game which uses the arcade's algorithms on hard mode and corrected the error. It was quite fascinating to read up on how the arcade did things.
Nice, was your Deluxe Pac-Man for the Commodore 64 as well?
@@8_Bit Strange, I already answered you and it isn't here, possibly because I included a link to it? Anyhow, no, I made it for the IBM PC after Commodore went bankrupt I switched to the PC and my wife missed playing Deluxe Pacman for the Amiga (by Edgar Vigdal, who sadly passed away in 2015, my wife passed away last year as well) so I decided to program my own version of the game for the PC (with Edgar's blessings, I had emailed him at the time). I have it available for free now, always been free. Even has a level editor. There's Deluxe Pacman 1 and 2. Originally for DOS, I made versions for 256 colour Windows back then, and later I made a 32bit colour version for newer windows and eventually I remade the game and created Deluxe Pacman 2 for modern Windows. The last version update was in 2018 for Windows 10. I released the source code a while ago for the DOS version and Deluxe Pacman 2. The original code is scary to look at as I was still new to C programming at the time (end of the 1990s). I used the Allegro library for all versions (similar to SDL, except Allegro was around long before SDL was).
The game was put out for free and so it has been downloaded millions of times world wide, which has blown me away. I have heard from people that tell me they grew up playing my game as a child, which makes me feel good.
On my page I have videos of the game with links to the game (on github, but just a website with zips, not a normal github repo) if you're curious in the game, or the source code. :)
One of my favorite videos you have done! Thank you very much for the content. I love the detail and explanation given throughout the video. Look forward to many more.
There’s another bug in the Atari 8-bit iteration of this game, where the energizer on the 5th, 7th and every key wave thereafter gives infinite blue time on the ghosts-if left uneaten. I wonder if this error was ported over to the C-64 version? This budget issue disk might still be “broken”?
Interesting - I'm sure I've played the C64 version at least to the first key wave and have never noticed infinite blue time, so I think it doesn't have that bug. But it'd be interesting to look into the Atari 8-bit version. Do you know if anyone's ever fixed that bug for the A8?
This happens on the Atari 5200 Pac-Man
@@8_Bit i do not think it’s ever been corrected
Fascinating. First time I ever played this version of Pac-Man I guessed that it wasn't putting the characters into multicolour mode properly. Fun to see it fixed.
Amazing work. Now I have to wonder if full 3-color ghost sprites could fit into that 8k…
Every time you say Thunder Mountain I feel like you mean to say Thunder Bay, for some reason. This repetitive releasing of the bug reminds me of my last job where we kept releasing versions with the same crappy, buggy components because they were never high enough priority in Bugzilla to fix. We spent more time reviewing the bugs over and over in meetings than it would take actually fixing them
Pinball construction set also neglected the multicolor register. The most obvious bug in Pac Man is the mouth moving too fast. Standards in those days weren't as high as now.
All the way through I was "fix the PAC MAN logo to Yellow, fix the logo". You didn't disappoint.
Having worked at different types of game dev houses, there’s a chance that the title screen was that way intentionally. A producer might have liked it that way (I’ve had that type of thing happen.) Maybe they did do it multicolor (the logo was made for color) but someone didn’t like the text. Maybe they didn’t have time, especially given cartridge space, to do such a “minor” thing. Or maybe, yeah, no one noticed. Who knows without talking to the original people involved.
It looks like a pretty straight port from the Atari 8-bit version, but the Atari 8-bit version's title screen used a wide colored text mode that doesn't necessarily translate straight to the C64. I'm guessing they realized that without more development effort, it would be a tradeoff between showing the title screen in color and making the text as readable as they could, and they just went with the easiest and fastest option. Often software development involves a lot of triage--you want to fix everything, but you want to ship on time as well, and sometimes you have to pick your battles. Atarisoft was churning out game ports to a large number of platforms at a wicked pace around this time. And the development platforms they were using weren't like modern emulation environments.
This was very enjoyable. I haven't coded 6502 since the late '80s and that was on a BBC Micro not a C64. As soon as you started typing in your patch I knew that a BNE was coming after the DEX. It's funny how I remember that stuff.
I played PAC-MAN a lot on my C128 as a kid. I'm talking something like 32-35 years ago so, maybe I'm just wrong... That title screen with gray characters feels extremely weird to me. Same as your first attempt, with the multicolor text... Just weird. But when I've seen the title with yellow letters and the right fruits, it felt like seeing and old friend... Could I've been playing a "fixed" version!??? No way of knowing. All the tapes and disk from that time, are long gone by now...
Amazing video. As always :)
Hi. I just wanted to say that this was incredibly cool. I've never seen someone cook up a patch for a live game before, and now I have a better idea of what all goes into it.
Just a thought.....when in multi colour mode the top bit (3) of the colour in colour ram switches between multicolour mode and hires mode. It would of been easier to just change the colour of the text (0-7) to switch to hires.
That's what he did for the final fix. He copied/modified the original code to use high-res color 7 (hi bit clear) and then for two cells where fruit is shown he did a POKE (err, STA) with multi-color 15 (hi bit set). The other change was to actually enable multi-color mode ($d8) on the title screen. -- I'm glad Robin actually did / showed us that hack, other wise I would have made the same complaint :)
As an electrical engineer and embedded programmmer I love that video so much :D
3:28 "Where's the Beef?!" Computer Box edition ;)
Seems like the PAC MAN logo was supposed to be in color in Yellow as well on the title screen.
The big boxes were for theft prevention. Harder to hide a giant box in your pocket than it would have been to hide a cartridge.
No, the main reason of big boxes like this was to draw attention to them when sitting on the shelves. The bigger the box and more colorful the art etc the better the promotion value. To bad at some point almost everything switched over to Amaray style cases. But somewhat understandable since costs were reduced and stores could stock up many more titles.
The box art reflects the 2600 version having super wide pixels, so they started calling the dots he eats "wafers."
Nice Video and excellent coding! That blue object is suppose to be the Galaxian ship which is usually yellow or orange.
Love it. Reminds me of old apple rom days. Should add two patches though. Keep the Pac-Man logo in color AND the fruit in color with the text in Hi-res. Never mind….you read my mind before I finished the video.
Another amazing clip. Kudos. Love each one of your clips
Very well explained, thank you! I always look forward to your end credits music. This one reminded me of Nirvana for some reason.
Thanks, I added a link in the video description to the whole album that song is from.
I don't think the text on the title is supposed to also be yellow (yes the logo needs to be yellow), but the text should probably be white or purple (it looked better that way imo) ... and not yellow... still though, even with all the text yellow, it looks better than before, and I think with that btw routine, it could be fixed, so nice work!
Also I really liked the use of PC tools to convert the prg and do the crunching. That's really cool.
hey Robin Im learning a lot about ML from you by this thanks.
Nice feature about the bug in the classic game. The fruit sure did not look right in hi-resolution. The machine code patch made it look much better. I also agree with Exomizer, being an essential for programmers. Back before internet was the norm, I used to use native C64 crunchers, which took longer. The best one required 256K extra RAM, but during that time, I never had that. So I relied more on the Fast Cruel Cruncher or Cruncher AB fast mode, because I didn't want to wait for ages for my production to crunch :)
I swear by Exomizer, using a wrapper to use it on Apple ][ binaries.
Pretty good fix but I think it would look even better if you added a few more interrupts to keep the high rest text white / gray and the Pacman yellow and the fruit multicolor as you have it. The yellow text is fine but it would look just a bit better with more variety IMO. Also for memory you probably mentioned this but with a bit more hacking you can usually find the bytes you need. There's always some waste. Good work!
My friend Donna Bailey coded Centipede!
Thanks a a lot for another great and instructive video. I always learn so much from your journeys.
Be good to do a follow up video to this. To fix up the bug pointed out in the comments when you go back to the title screen. Possibly look at the hiscore issue and maybe making the ghost sprites 3 colour.
Then see if the compressed version after fixes can still fit on a cart.
Why not incorporate a decruncher in the EPROM? The only issue I see is once decruched, enabling the RAM back into the cartridge space (to copy the decrunched code) instead of the cartridge. I'm not sure if that is possible with a C64. If it is, well, there's your extra space
You can read from cartridge ROM, and store at same address space in RAM, then turn off the cartridge and run the code from RAM. No Problem =)
My brain stumbled through the title and what it got was "39-Year-Old Man Bug Party?"
Excellent work.
I don't have anything of value to add, but I'm just leaving a comment so that The Algorithm sees engagement and boosts your video.
It's been decades since I wrote machine code on the C64. Seeing that code sure brought back a lot of good memories. Some memories of working through the night to get my code finished. LOL
The last C64 i had, I sold about 18 years ago. It was my beloved SX64. I loved that thing. Oh well.
TIME PORTALS! AM I RIGHT!
ROFL
Dear God, am I glad that your real solution wasn't the one that involved doing a busy-wait in an ISR. I've seen some things, but ... :)
Im actually using RiscOS 5.28 on a Pi A+ for re-learing and catching up on BASIC programming using BBC BASIC. The last time I programmed a game in BASIC it was done on my 386 back circa 1996 on QBASIC with DOS 6.22. I even x86 compiled it into a .exe. Programming is not my forte, but imma learn.
Night Mission Pinball is suffering from a similar problem. Those monochrome vertical stripy graphics always bothered me. Wasn't sure if it was a lazy port or a bug.
This was such a fun video to watch! Robin you explain things so well, it makes us all experts. lol - I had to try my Atari 800XL cartridge to remember what it looked like on that system. It's so bold and brightly colored. I'll have to find my PacMan for the C64. I never noticed the black and white title screen. I was too interested in getting to the game. Wonder what it's like on the Apple IIe? Good stuff! Thanks Robin
Great stuff, thanks for sharing this! Also, didn’t they do a surprisingly good job with the ”wacka-wacka” sound effect here?
I had the Thunder mountain Pac-Man and I think Dig Dug as well.
Awesome job dude!
It looks like Atarisoft were going for a similar title screen as on the Atari 8-bit port. The games themselves are practically identical, after all (unlike the case of _Ms. Pac-Man_ , which had a bigger budget and a 16K ROM). Obviously it would have taken more work to make the text characters twice as wide to match those on the Atari title screen, so that was out, but the different text colors could easily have been replicated.
I think it's becoming clear at this point that, as you suggested, they might have run out of room (on the 8K ROM) and/or time to do things properly. When the programmer(s) realized that there was only room for a single color map initialization routine, the title screen that was almost certainly intended to closely resemble that of the Atari port (except for character width) was history. They did what they could with the space and time available.
If you really want to fix this bug, then in addition to what you've done already, you need to color some of the text differently to match that of the Atari port (bonus points if you make the text twice as wide, as well). The easiest way, obviously, is to create and copy over a custom color map, which takes a lot of memory for an 8K cartridge, but since you're saving to disk, it doesn't matter.
nice fix!...they really must have been struggling to find space on the rom..no doubt the title screen would have been one of the last things done
Hi! I don’t know if you noticed but the pac-man title at the top of the title screen also appreciated multicolor mode and became a pleasing yellow that was then removed with your raster wedge
Edit: ok I see you made the whole screen text yellow at 26:40. I like it better with the title jumping out yellow and the rest of the text gray 😅
Also the big box format was used to prevent stealing. At least this is what Metal Jesus says
Hi Robin, this was fun. And I like your videos, too. In a German computer magazine called "64'er Issue 08/1988" there was a BASIC program called "Modulgenerator" (cartridge generator) to create an auto start BASIC or ML program. Your new program would easily fit because you can only use programs less than 30 blocks. And in another 64'er magazine is a ML routine to move your "cartridge ROM" to the necessary location. So far as I know there is also a build-in routine in the KERNAL/(BASIC) to move the program. But why not write your own move routine for this game?
When u put color on. Pac-Man title was in yellow…. When u patched title went back to white
Yes because the title uses multicolor also. You really need four raster interrupts for the title screen to look as intended.
@@FadkinsDiet Four raster interrupts? I don't see why any raster interrupts are needed at all, as the C64's multicolor character mode can switch between multicolor and hi-res modes on a per-character-cell basis, via bit 3 of the attribute/color map at $D800.
@@rbrtck If MCM, and as long as the hi-res colors are limited to the first 8 then you're right . In the general case of the hires characters needing colors 8-15, you do need interrupts. (and obviously MBM is something different too, that's what I was thinking of)
Pacman is the kind of game that would definitely be rushed to make a (holiday shopping?) deadline. The 2600 version seems sloppy, as if the released version was a tech demo of the feasibility of a port.
Would it be possible to create a Flag Byte in free memory that is Set during the Title Screen, and Cleared during the actual Game, and use it to Execute the original code during the Game, and the Patch code during the Title Screen?
Unfortunately I think this might require the New Patch to replace the entire $8583 Subroutine.
The Big Box was technically easy for kids to see, and also theft prevention.
Next up, you should try and fix why the PacMan sprite doesn't always open and close its mouth while traveling.
Looking at several parts of the video, it doesn't seem do depend on the existence of dots to be eaten, or the position on screen or even direction, so it should be an interesting bug to fix.
That seems to be an issue with TH-cam showing the video at 30 fps. Rewatch those sections with the player set to 720p60 or better and you should see the mouth continue to move.
This was really fascinating, great video. =]
As usual, lots of great information here. Pretty cool fix too :-)
I think the most amazing thing here is that the floppy disk from 198something is still readable...
Thunder Mountain. Didn't they make the vector-based Top Gun?
I think it is cleaner to make optimization somewhere in code and fit fix directly as patch without compressing.
Fun video, I love to see the old systems load everything into the memory and you can just inspect and change it. I wonder if this kind of technique is still possible on a Windows PC games, GPU etc
I had this version as well and always wondered why the main screen was done in ugly gray and not more colorful. Or even just in Yelliw.
Isn't the logo for pacman ACTUALLY supposed too look exactly like that, yellow and fat characters?
And, though obvious, the task is also to find any free area for patches inside the cart area.
After starting a game, hitting F5 returns to the title screen which then reverts to the blurry text. Perhaps that 2nd JSR is subsequently used every time thereafter.
Ah, nice catch, I must never have tried that! I'll see if I can come up with a fix for that.
@@8_Bit I miss and I don't miss 6502 assembly language! It's so limited compared to x86 and x64 assembly, which I do a lot of now but it was so nice using assembly on the C64 because it was leaps and bounds faster than that version of BASIC they gave us. I have patched stuff in a similar manner to what you did here. When there isn't enough room to fit your fix/change, you JSR or CALL to another memory location and assemble at that location. I've taken x64 code and actually wrote my own code over a useless function and made sure to disable the actual call to that function so it didn't crash. Trying to think of an example... the code for the BUY NOW button in a demo version but you've already registered it so it's impossible for that button to appear (and that code to run.)
@@8_Bit Both JSRs are executed when F1-starting a game, but none are called when returning via F5 LOL. (Might have spent more time futzing with it.) I suspect there might be a branching logic bug remaining.
3:30 I miss big boxes so much.
NOPE!, MSX1 version by NAMCOT is not stretched, 1983! (TMS9918). That C64 version looks like it has lots of extra-dots in the map, which breaks the exact experience from the arcade.
Ahhh the nightmares for some 40 years, a monochrome fruit supposed to be in color. lol
Then Robin goes: "Hold my fruit! We're just going to use a raster interrupts to turn on color mode just above the fruit, and high res mode thereafter." heh
I was wondering if there's any free space available within the 8K of the cartridge memory for 30 or so patch bytes. Perhaps running a binary/ pattern search for a short sequence of 00 or FF might reveal a small block of unused bytes which could be used to include the patch. I can't imagine that every single byte within the 8K would be all used, even if you could find several unused 10 bytes, the patch could be broken up into those blocks, thus maintaining the true 8K cartridge size.
The big box for the cartridge game was meant to dissuade cash-strapped youth from putting it in their pocket without paying. Would multicolour mode be enabled at boot up if you used an earlier version of the kernal?
As a fun experiment. Would you be able to make the background a different colour from black? Like Red or White? :D
i believe the manual for the Pac/Man 400/800 was large as the box
BIG BOX was to help prevent shoplifting. :)
Thanks for these extra nerdy videos.
THE WHOLE VIDEOGAME IN 8KBYTES!!! I launched the installation of Far Cry 6 over 2 hours ago and it's not finished yet... also had to free 150GB...
great music! it reminded me of Dead Milkman . lovely
That was a nice lecture sir 🫡
The clone "Munchy" was THE most accurate pacman for C64
Only the original programmer knows why the monochrome fruit bug was originally introduced, though it was most likely some combination of oversight and time crunch. But not fixing the bug during the porting process isn't that surprising. Why risk fixing something that doesn't really need fixing? After all, there is no bug fix too small or too easy that it can't cause regressions. That's a painful lesson I have learned more than once during over 30 years of programming. The bug doesn't affect game play, and the start screen matches the original C64 version exactly.
In Brøderbund Softwares "Choplifter" for the Commodore 64, the look of the chopper and people always bothered me - it looks like they were meant to be single-colour hi-res sprites, but for some reason they are lo-res multi-colour in stead. Would be interesting to see if it is fixable 40 years later.
I did always think the helicopter looked funny, it kind of reminded me of artifact color, but that didn't make sense for a c64 program.
Nice wedge, Robin!
The Atari 8bit version of Pac Man looks exactly like the C64 version, however the sound it makes when you eat a blue ghost is horrific, loud and irritating. Yet the C64 version dosen't sound like that. Why? Maybe it's a bug that's lasted for the past 40 years, maybe it can be finally fixed?
Robin that is really cool.
To fit it into less space: eliminate the graphics from the menu, represent the difficulty numerically.
The C64 version is also missing the Highscore feature that the Atari 8-bit version did.... but I think the code for it is still in there...
I don't know why they don't just use a sprite?
Either sprites or multicolor character mode alone (no raster interrupts) would have sufficed. Using more than one sprite would have allowed for hi-res fruit, as well. But then again, not much effort was put into the port of the game itself, to begin with. It's a straight port of the Atari 8-bit (and 5200) version, with all of the sprite limitations of that platform. A much better job was done with _Ms. Pac-Man_ on the C64, which has ghosts with eyes (4 multicolor sprites) and hi-res Ms. Pac-Man and fruit (2 hi-res sprites each, utilizing all 8 sprites total). This port was made specifically for the C64, while _Pac-Man_ was literally the same game as on the Atari, with an unfinished title screen.
I think the reason the title screen was left unfinished was that they had run out of room on the 8K cartridge ROM, since they needed the right color map to make it look as intended, while on the Atari it was done in a different way that had more limitations but required less data. _Ms. Pac-Man_ was done better because Atarisoft had more of a budget to work with, in addition to a 16K ROM.
Regarding the title screen…perhaps the whole screen is B&W since it looks like the title PAC MAC should have been in yellow? Regarding the big box…to deter shoplifting?
I enjoyed this episode. Nothing beats a bit of game hacking 👍😎
I don't know how I got here but this is fascinating.