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.
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.
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.
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!
@@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!
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.
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.
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 RU-vid 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 RU-vid 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.
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.
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.
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.
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
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?
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.
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 :)
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.
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.
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. :)
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.
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
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 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.
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?
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.
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!
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.
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
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 :)
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
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 😅
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.
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.
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 think that's a side-effect of my video capture or the video render being at only 30 fps. The Pac-Man animation seems to run at the same rate, or close to it, and when we get "unlucky" it will only capture when his mouth is closed or open, not both.
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.
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.
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
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.
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.
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?
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.
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 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?
If I had to guess, perhaps it was easier and more consistent to simply decide for all versions that the title screen should always be high-res and the game should always be color
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 RU-vid 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.
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.
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?
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.
