The Extra Spaces in Commodore 64 BASIC Errors
Vložit
- čas přidán 23. 12. 2018
- Why are there two spaces in the famous ?SYNTAX ERROR on the Commodore 64? Why are there three spaces in the little-seen ?BREAK ERROR? Let's dig into it with a C64 machine language monitor and see if we can patch those extra spaces out!
Become a patron: / 8bitshowandtell
One-time donation: paypal.me/8BitShowAndTell
AtariAge Store: www.atariage.com/store/
Jim Butterfield's Commodore 64 Training Tape: • Commodore 64 Training ...
The extended version of my song Commodore 64 Christmas: • A Commodore 64 Christmas
Follow me on Twitter: / bedfordlvlexp
Check out my podcast Growing Up '80s: thecouch.website/category/gu80s/ - Věda a technologie
The BASIC ROM for the C64 was pretty much a verbatim copy of the VIC-20, except it was relocated to $A000 from $C000. The VIC-20 had a very narrow screen, so the "ERROR" part of the message included a carriage return and a Space prefix to start and indent it on a different line. They could easily have cleaned this up by shifting the whole "ERROR" text back one byte and putting a redundant $00 on the end to maintain the code alignment, but they apparently didn't bother.
When you were looking at the error messages in ROM, you could have hit Commodore-Shift to see that the last letter is in upper-case, which in PETSCII means that the high bit is set, which also acts as a terminator.
Good points. I also have notes for an episode about the history of these space errors going through from the PET and VIC-20, and had that info in there, I think someone else commented on it shortly after the episode was first released. I wish I had thought of doing the Shift+Commodore thing to illustrate the high bit being set!
8-Bit Show And Tell is it because of that legendary deal that Jack made with Microsoft-they didn’t change anything because that would have broken their sweetheart deal?
Paul Bruneau I think that was a factor, yes!
8-Bit Show And Tell thanks! Your videos are fantastic btw. I bought a vic-20 then a C64 a couple years later. 30 years later I program iphones 😃
It helps to have exotropia if you're trying to program a VIC-20.
When you consider how last minute the BASIC ROM and Kernal was for the C64, we can forgive them for this! I'm less forgiving about the IEC transfer routine that made the disc drive ridiculously slow!
@stupossibleify Yeah, but that's because of a bug in the 6522 chip that was fixed in the 6526. Essentially, it was supposed to have a hardware shift register, but it didn't work. They were forced to resort to bit banging in software. The Commodore 64 used the 6526 chip, but when the 1541 disk drive came out, they wanted to make sure it was backwards compatible with the 1540, so they used the 6522 *again.*
Now, you may wonder, "wait a minute... why didn't they just skip backwards compatibility, so that there would be a working pair of 6526 chips?" Simple... some jackhole at the factory decided the C64's motherboard wasn't secure enough, so he added a screw hole right through the trace for the 6526's shift register. In other words, it wouldn't matter if the 1541 had a 6526 or not, because the hardware shift register still wouldn't work. It wasn't until the Commodore 128 and the 1571 disk drive that we got a working pair of 6526 chips.
On top of that, the new VIC-II chip introduced "flutter" into the timing, so they had to slow the drive down _even more_ to make it reliable again. The result was a disk drive that, even under ideal conditions, couldn't transfer more than 512 bytes per second using the standard I/O routines.
It really warms my soul to see all these new games coming out for classic systems like the Atari 2600, Sinclair Spectrum, Intellivision, C64 and so on...and new hardware too! In fact, retro gaming is arguably MORE popular now than it has ever been.
I have no idea why this is interesting as I haven't had any interest in a C64 since about 1987 but it is fascinating to learn how they packed as much as they could into it, including pointing to strings they already used elsewhere rather than wasting space.
I love how through bugs/anomalies we get to understand how things work. Excellent video, I always wondered how the error handler printed the messages
I had to rewatch the first couple of minutes today cause all I did during the premiere was stare at the lovely quartflakes! :) Can't believe the video is 37 minutes long, it felt like 20 minutes max! Thanks for the great content and merry Christmas to you and your family!
Now that I think about it it's probably quadflake, not quartflake... Anyways, they're great! :)
@@dru1432 Yeah, I think Darren called them quadflakes. Thanks very much for watching and commenting, it's really encouraging and makes me want to keep making more videos :) Merry Christmas to you and your family too!
@@8_Bit Thank you! :) I'm always looking forward to your video premieres. I try to catch them live whenever I can. :)
I did the same! I spent most of the first watch trying to figure out how Robin has achieved the snowflakes with interrupts!
I thought the extra spaces before "ERROR" simply was a form text alignment so that all different errors messages lined up.
This seems to be the reason: On the PET there was just one space before the ERROR. Then on the VIC-20 they added a carriage return because some of the errors were too long and had an ugly screen wrap otherwise. Then on the C64 they didn't bother to recompile, and instead just patched over the CR with a space.
That was my guess, too.
Late to the party. This was what I thought too.
But /why/? It's not as tho' you got a series of errors in one go (I assume)
@@christopherlawley1842 read the other comments here. the answer is in this video's comment section
You have a knack of teaching! Even as a seasoned C64/6502 hacker I keep watching. And then at the very end my musican heart is also pleased with a nice original song. I think I enjoyed it more than your kids 🤪
Cool snowflake code, I have some suggestions to make it more interesting. Make the outside corner pixels less likely to be generated, should produce more rounded flakes. Randomly have one generated double size. I'd love to see a breakdown and tutorial of the code. Thanks.
Good ideas, and yes, I'll try and get to that explanation of the code.
not only did you get me INTO the C64 way back then you keep me going. i'm sure you're beyond sick of hearing from me with random messages, but these videos are great! keep em coming I learn something new or long forgotten each time.!!
Great tutorial! And I love the C=hristmas song! Keep 'em coming. I once knew this stuff, but my (soon to be) 69 year old brain is forgetting things.
Thanks Dave. Have a great birthday as we ring in 2019!
I just took this a step further and patched these bugs by hex editing the "basic" file for the VICE C64 Emulator I'm using so now it only shows 1 space. I'm sure you could also patch this by flashing your own EPROM chip with these fixes burned on it.
Those extra spaces always triggered me. Even at 13 yrs old decades ago! Thanks for showing what the deal was there. Great stuff!
Love it. For the record in most video editing software you can edit out audio and video separately, optionally extending silences or whatever to keep sync reasonable. So if you want to get rid of audio mistakes there are options - not that you need it! Your narration is perfect to my ear.
Thanks from Australia.
Interesting video! I never thought about those spaces...
But wait, you didn’t change the error messages to random curse words? How disappointing..... 😉
Bugger! You oinked it you fucka'!
That toy game looks really fun. That would have been a very popular and good selling game back in the day.
A fascinating insight and very well narrated. Love the outro song! A belated merry Christmas, and best wishes for the new year from a new subscriber :)
So much fun. I abandoned my C64 at the beginning of 1987 when I got my Amiga. But I never dug that deep. But strange how memory works. I barely know my phone number, but still remember 53281, 53280, 64738 etc ;)
Your much younger brain was much more able to learn and hardwire memories into itself. The older you get the harder you learn because nature assumes after a certain time i. e. after childhood you have learnt 90 % of all life supporting skills that shouldn't be changed or forgotten or relearnt. 🙃👀✌️
This is a very underrated video. You did a great job explaining what was happening. Fascinating stuff.
Dope video, I love errors and stuff in retro tech! Very cool, and I'm glad to see more Canadian youtubers, especially for retro tech!
Keep it up!
Wow cool video! It made me realize I was 16 when i got my C64 Christmas in 1983! But I felt the same way about it (Good Memories!) ☺!
Loved this, great insight, kick ass song and your kids face was the cherry on the top! Happy new year!
Lovely work with the snowflakes! And being sprites and using an interrupt means that they continue while you do other things. Stuff people take for granted nowadays!! Clever stuff with the double symmetry to make a quadroflake. I'd be dead impressed with a routine that made 6-pointed snowflakes!
Nice call out to us Aussies! Not many seem to realise we are in a completely different season.Love watching you videos man!
I lived in Perth, WA for one year in 1987 so that helps me keep a more global perspective :) Thanks for watching!
never really had a 64 but I enjoy low level computer stuff
You should emulate it , if nothing else for the amazing array of 8-bit games
Me either. I have really enjoyed getting into the details of the Commodore 64. Even inspired me to homebrew my own computer from the ground up.
Cool Christmas song. I'm glad you finally got your 64 wish 👍
I used c64 in the 90's (still in the basement somewhere).
6:25 My 1st pick is to notice that ERROR word in both cases (most likely in all) is 9 characters from the left of the screen. Conclusion - there are 9 characters for error "name" that are later followed by ERROR string. EDIT: Check from $A360, and yea, I remember there were longer error messages as well so... funny one.
That was fascinating. Really enjoying these. The tune is spot on 👍
You are dissecting my childhood, and I love it.
Great video! Keep up the great work.
The video at the end was classic! I got mine in 1982.
Excellent work, Sir! I programmed in Z80 assembly, so this makes good sense to me. You do a nice job of explaining everything you're doing. i have subscribed. All good wishes!
I could watch stuff like this forever. My youth back in late 1980s... Aaaaaaaaaaaaaaahhh...
Very cute song! My first pc was a VIC-20. I had always thought that after you had access to assembly you no longer needed peek poke. I guess that is true but peek and poke are a lot easier to use in some cases 🙂
I'm going to say it probably has to do with the VIC-20 which has before the space.
On the Apple //e, you have " ERROR" followed by Ctrl-G (bell) and null at D350.
Case: apple //
Startup: APPLE ][
This really brings back memories for me. My favourite cartridge was the Super Snapshot 5 (in fact I think it was my first and only one I used). And I absolutely loved 6510 assembly, it was so easy to program. A great CPU to learn assembly on to be honest. I have a C64 along with a 1541 and 1571 in storage, I don't think they work 100%. I have my Vice64 emulator with SS5 cartridge ROM, so it comes up like my real machine used to .
I loved how you could copy the ROM into the RAM. The reason why this happened which was not explained is because you could ONLY read from ROM, you could not write to ROM, so when you poked the same value back to the same location, it read the ROM, but because it is Read Only Memory, any writes to that location went to the RAM under it. Anyhow, this also works for all other ROMs like the character ROM because the C64 has the maximum memory addressable for 16bits, all ROMs are located above RAM. You could copy the character set, which many games did, and the redo the characters, which was a handy trick. I one time created my own custom 80 column text with 4bit wide characters (not the best, but it worked) for use with 80 column BBSes back in the day.
I recall a nifty little program in one of the Compute! magazines (or Compute! Gazette) where you could use the hidden RAM under the ROMs as a temporary RAM drive to store small files (just don't power the machine off).
Anyhow, nostalgia overload. :)
Now this isn't a new video but I didn't notice your great channel before recently, so it is new to me. :-)
I know that several people already mentioned that the double spaces was likely a leftover from the VIC, but I found a comment in an official C= ROM listing that verifies that. The line in question states: '00470 A369 20 ERR .BYT $20,' ERROR',0 ;ADD A SPACE FOR VIC-40 SCREEN'
Just discovered your channel. Liking what I see, subscribed and I hope you get more subs!
Watching this in 2021 - nearly forty year old riddle revealed and patched, now i can die in peace. Thank you! :D
You explained it perfectly.
You had me at “Boxing Day test match”!
Loved seeing the basic rom poked into RAM. Is that an intentional “bug” made my commodore? Awesome.
COOL SONG AT THE END!
Great video!
Thanks for watching, Jess! :)
Oh Lord, what has become of me? Here I ‘am, lying in bed and watching somebody on his mission to fight the sinister spaces. And while the fight comes to an end, good prevails eval, the wizard shines in his glory, I ‘am slowly closing my eyes, drifting away with a last tender smile on my face.
thanks for this, now I know how to hack basic :)
looking forward to the follow up with the PET.
Great vid ,man! Will there ever come a video about scrolling,using the raster-irq?
That's a good idea, I"ll put it on my list!
interesting, i never noticed that before. i thought when you mentioned it, it was something to do with the length of the first word, and the error word always started at position 9
That _Toy Store Trouble_ is genius :D
Very interesting. 👍🏼
At 30:20, you changed BREAK00A0 to BREAK0080 but wasn't changing the K to K+$80 a better choice ? Both work but printing char 00 twice seems weird although invisible...
I thought the first part of the error messages were simply fixed-size strings. But no! much more complex than that. I enjoyed the video! ;-)
Great channel 👍😎
I've been finding out a lot about C64 now. I had a Tandy/Radio Shack Color Computer back in the day. I have a few old consoles too, Megadrive/Genesis, NES (needed repairs due to a botched repair), SNES, various Gameboys, DS, DSi, DSi XL, PS2, PS1, PSP,.
Wenlocktvdx 20,000 games for the system..... At least a few hundred still very playable today.... The fun is in figuring out which ones those are
Man, you are guilty of my decision to buy c64 ant recover my software written in assembler on my old types.
I was always curious about those Basic-extending cartridges (like the one you used there, and things like Simon's Basic). How did they actually work? Did they "bank-override" the entire Basic, or patch certain parts, or was there actually some entrypoints for adding new commands provided by the stock ROM-code? Maybe an idea for an exploration video? And great channel, BTW! :)
Thanks, I added this to my list of video ideas. Which is... about 150 items long! But I'm not doing them in order, so who knows, it might happen sooner than later :)
I'll have to study up on this more to know for sure, but my understanding is that most BASIC extensions use various hooks provided by BASIC.
Vectors at $030A or there abouts.
Hah..what a wonderful video. Over 3 decades of commodore experience here, and I've always found something to be wonky with the basic error messages. Never really looked close enough to figure out it was the spaces all along.
In assembly I usually disable interrupts before changing the memory mapping, but in basic there's not really a way to do that. Could that be worked into the poke command itself perhaps?
Thanks, glad you enjoyed the video! Yes, in most cases when changing the memory mapping interrupts should be disabled first, but in this case I think it's safe to leave them as we're switching from ROM to the RAM underneath which has an exact copy of the ROM. The keyscan IRQ can be turned off in BASIC with POKE 56334,PEEK(56334)AND 254 as seen in line 20 of the custom character example on page 110 of the C64 Programmer's Reference Guide.
Great channel! You deserve more views
If I remember correctly, when you wrote to a ROM address, you would write to the underlying RAM instead. This means that you could read from the ROM and write the byte back into RAM without any bank switching. Then when you copied the whole ROM into RAM, you could just switch the ROM out for the RAM.
Yes, that's exactly what I'm doing at 25:20 or so.
8-Bit Show And Tell oh yes, there it is! I think I watched to 20 something minutes before I had to go, but I did assume that it was exactly the thing you were doing.
Hahha - you should consider doing the sport coat thing XD
Also, it would be great to have a follow-up with the history of these "bugs".
Great channel Robin! I just subscribed. :)
A few years back, someone named palordrolap gave the following explanation for the two spaces on reddit:
------------------
Commodore BASIC V2 is the same dialect of BASIC that was on the VIC-20, and the interpreter was pretty much ported wholesale from one computer to the other.
Note that there's nothing specific to either machine in the BASIC language itself, so only minor changes were required.
Now, the VIC-20 had a 22 column screen, and so on that machine, while errors like ?SYNTAX ERROR could have fit neatly on one line, some would not... so the VIC-20 printed a carriage return immediately before the space.
?SYNTAX
ERROR
See how that lines up?
On the '64, plenty more line real estate was available, so the carriage return was superfluous. Since removing a byte from the ROM could be troublesome and require branch recalculations and other things, it seems that the (lazy?) decision was made to replace the carriage return with a harmless space.
Thanks David! I think this explanation makes perfect sense. I've had a follow-up video planned for some time, but I keep getting side-tracked with other ideas :) I'll try to get to it soon.
'I had to go have a sandwich break'. I go out and mow the lawn.
i tested the 128mode via vice. the "normal" errors, like syntax error are corrected, so the just have on space inbetween. the break error has two spaces... so they just done one bugfix.
the vic20 uses returns between... and i figured out, a basic line on the vic 20 can have 88 chars, or 4 screenlines (4*22)
on cbm II the errors have one space and if you break a disk operation as load"$",8 you will get a ?file not found error. instead of break error...
on a cbm 5x0 there is also the correct syntax error. and hit stop at load"$",8 brings a "?stop key detectet" message.
the PET also have correct messages, and it seems u can't break listings, at least i can't do it in VICE using the ESC-Key
the plus/4 behaves like the c128...
I hope this little info is kind of interesting for you ;)
well i tryed it all useing VICE Emulatior...
Awesome! I had tried some of this and have notes for a follow-up episode, but hadn't tried CBM-II, Plus/4. I was thinking of doing a little history of this bug, from the PET through the VIC-20, C64 and C128, as they kept re-using much of the code and just tweaking it slightly. Oh, I wonder if it's totally fixed in the C65? :)
Maybe they're not bugs, something I like to do in my code is make some messages more visible than others, an error would be such a message. So, having 2 or 3 spaces in front would certainly make the error pop out more. Also the fact that those errors are aligned to the same column makes reading easier, which is also something I'm doing a lot.
The reason I don't think it's a bug is because 1) they're extremely easy to fix, and 2) those messages are extremely frequent. So the best explanation is that this was done by design.
I think that $A0 at $A389 might be the opcode of a LDY #$BA instruction! You should have changed $A387 to $CB instead to avoid introducing another obscure bug.
[Edit: I read a bit further down in the comments and realized that the breaK solution isn't that great. My point about the danger of changing the $A0 may still apply.]
[Edit#2: I checked the commented disassembly, and discovered that there's no danger ... the executable code starts at the $BA (TSX) ... nevermind ...]
Can you program a new Basic altogether this way, e.g. a slimmer basic that leaves more space for the program than 38911 bytes?
Am I missing something here? How did you get the snowflakes falling whilst you work? That is true multi-tasking.
Does the POKE 1,PEEK(1) AND 254 restore after runstop/restore?
We still put snowflakes on everything in Christmas here in Australia xD
It's January 2020 and I had a commodore 64 Christmas. Before Christmas I bought the new 2019 with built i games but was more interested in basic. I have an old commodore 16 which, although limited, had better basic. I'm going to try your hacks for the Ready. statement
Instead of changing the A0 to 80 after BREAK you could instead change the 00 before the A0 to 80 and get the same result but have the routine read 1 less null character (which would add a tiny unnoticeable speed increase, not that it matters). So that's POKE 41864,128 instead of 41865 that you use.
EDIT: You can save yet another null character from being read in the routine by adding the high bit to the K of BREAK with POKE 41863,203
Unfortunately, that prints "breaK" (if in lower-case mode) when STOPing a RUNning program. There's two different print routines using that same string: one expects null-terminated strings, the other, high-bit terminated.
Hi Robin. I think the reason that there are two spaces is that it uses the same code as the VIC-20. On the VIC-20's measly 22 column screen the error messages appear on two lines because some of them would wrap. The first line has the error and the second line starts with a space and then ERROR. If you put a line full of ###### on the VIC and then make an error appear on that line, you'll see that the error is printed without any spaces at the end, then there's the carriage return, then on the second line there's a space and then ERROR. I think all they did was re-use that code but make the error stay on one line since the c64 has 40 columns and they didn't have to worry about it being longer than they could fit on that single line. They simply changed the carriage return to another space.
Yes, I think that's exactly it. I had forgotten I had done more research on the topic after this episode was released, and was planning on a little history of these errors going back to the PET and the VIC-20. I just found my notes from December. Thanks for the comment and reminder! :)
It is likely to save space in ROM. They are probably just inserting the type of error into a predefined.
I love how uncomfortable your kids look at the end 😂
I remember being totally bewildered at 9 or 10 years old,
"What the heck is a snytax???" [sic.]
Yeah, I asked my mom (who knew nothing about computers, but was an English teacher) what that strange word "syntax" meant. I didn't understand the explanation very well.
@@Mnnvint
Syntax basically just means grammar. Syntax is one of the three basic aspects of linguistics: morphology, phonology, syntax.
@@RamLaska I know that now, but that explanation would have helped even less than my mom's when i was 8!
f o r t s n y t a x
Who, I had no idea the C64 had (something like) TSRs!!
And the sprites don't slow down an iota while scrolling or executing programs!
**Witchcraft**!!! :O :D
(I mean, I know they're *hardware* sprites, but still. It's buttery smooth, on an 8-bit machine. Weird!)
Makes me want a commodore 64 or 128 again...Thanks...
Wasn't Two Prints a song from the 90s by the Spin Doctors?
22:25 Classifying this as a bug implies that the implementation was unintentional. However, that might not necessarily be the case. I would postulate that the decision could have been made to have "BREAK" terminated with a null character, followed by $A0, since it would eliminate the need to take up additional space by adding it to the table of high bit-terminated strings, with the caveat of having additional space taken up on-screen. Without insight from the developer, it's anyone's guess as to intent.
Seeing as it's possible to eliminate the extra space by modifying a single byte (as I show later in the video), and that neither the PET or VIC-20 display the extra spaces even though the C64 ROM was very directly derived from them, I'm going to continue calling it a bug.
I'm not very agreeable to the idea that the developer's intention is the main factor in deciding whether something is or isn't a bug. If that were the case, I could declare all the code I've ever written to be bug free by simply stating that's how I meant it to be.
@@8_Bit I understand your point, but if anything I would consider it to be a cosmetic imperfection rather than a bug. A bug breaks something.
I'm probably doing something wrong, and braindead most likely..
Just for fun, I tried to do the copy to $c000 in the monitor for VICE for the C64, and it copied all the data from $a000 to $bfff just fine. Verified it by looking at it in the monitor. But it freezes the emulator, when I return back to BASIC.. it's just a black screen. But, using the FOR..NEXT loop to poke the values "back on themselves" from $a000 to $bfff worked just fine. Any idea why that Transfer thing wouldn't work?
Challange to Robin, make them snowflakes at least 48 ones, I think it would be not too difficult. With a nice sort multiplexing algorithm. Basically some sorting work.
Interesting to discover that the C64 effectively has "shadow RAM".
So, could you change the rom, write it to an EEPROM, swap the chip in, and have a permanently fixed rom?
It should work!
That expanding Print listing reminds me of a contest that one of the old Commodore magazines had: To write the shortest game program in BASIC that had user input and kept score. One guy (the winner of the contest) made a full downhill skiing game in only 2 lines, but every command was entered using a shortcut, so if you listed it after typing it, it filled up 5 or 6 lines or more (it's been over 30 years, so I might be off a little!)
Yes, I remember seeing examples like that :) Another funny (or, annoying) thing about those sort of BASIC programs is that you can't edit the lines without retyping the entire line, as the editor will only recognize the first 80 characters!
@@8_Bit Exactly! And variable names, if I remember correctly, were only significant in the first two letters, so that (for example) "name" and "nathan" would be considered to be the same variable. Got me in trouble more than once before I figured out why my programs were not working as expected...
Speaking of bugs and such, wasn't there a "garbage collection" bug where, under certain circumstances, the 64 would appear to freeze as it reorganized internal data? Still miss that old C64, though...
@@JustWasted3HoursHere Yes, that two letter variable name thing could cause a lot of trouble. Best just to never use more than 2, I think. And yeah, I've heard of long garbage collection pauses, but don't recall ever running into it myself. I should look into that, to see how it can be recreated...
@@8_Bit There's a reference to it on the C-64 wiki, here: www.c64-wiki.com/wiki/Garbage_Collection It seems that the way to recreate it is to create hundreds of variables.... (Too many for the string "heap" to handle in a reasonable amount of time). That should be easy to replicate... :)
Here's an example of a program that would cause a GC of about 1 hr and 49 mn, according to that wiki:
1 M=9000
10 DIM A$(M)
20 PRINT "FREE STRING MEMORY: " FRE(0)
30 B$=CHR$(65)
40 PRINT "ARRAY SETUP ..."
50 FOR I=0 TO M : A$(I)=B$: NEXT
60 PRINT "GARBAGE COLLECTION ..."
70 TI$="000000"
80 PRINT FRE(0) "BYTES FREE"
90 PRINT "TIME (HHMMSS): " TI$ " /" INT(TI/3600+1) "MINUTES"
Great video, thank you. I love the song and the reactions! How does the snowflake program work?
Thanks Ed. I've had quite a few people interested in the snowflake program, so I'm thinking about making a video to explain it. But basically it's interrupt driven, so 60 times a second the BASIC environment is interrupted and runs my custom code which moves the snowflake sprites down the screen, and when they hit the bottom, a new snowflake pattern is generated and placed at the top of the screen again. The snowflakes are basically just a random 8x8 pixel in the top left of each sprite, which then is mirrored and flipped into the other 3 quadrants of the sprite.
@@8_Bit I've noticed that there are no more than 8 snowflakes present at once. Using the VIC-II's hardware sprites, by any chance? (lol)
Some people seem having too much time lol. Nevertheless very funny and interesting. Thanks :D
My dear Robin, not all of your southern hemisphere followers are Australians, one from Argentina here.
37+ Minutes about spaces 👍🏻
Woo hoo! 8-Bit Guy is Canadian!
Why didn't they use a special character that the error printing routine recognized and printed the word "FILE"?
My question is if that would introduce any compatibility problems if you patched that permanently in the ROM.
Hmm
I bet they could've saved more bytes by not using the table of pointers, and instead searching through the error message table until they passed a certain number of characters with the high bit set. slower, of course, but for printing error messages it wouldn't matter anyway
Hoping the new (to me) breadbin will fire up and let me pick up where I left off in the 80s. Here for my daily C64 lesson. Now that you have verified these patches, do you ever plan to burn a new EPROM so that they will always be active?
BTW: It sounds like a great idea to fix all C64 design mistakes but in the back of my mind I know there are crazy programmers out there fully relying on some of those mistakes to produce code otherwise impossible... :-))))))))))))))))))
@36:38 Did you ever get the remaining 4 kb..... for christmas? ;)
wasnt using sprites for animating the snowflakes a lot easier ?
Your kids like: what is the old man so excited bout?!
For anyone who wants the 'fix' in a more elegant form here it is:
FOR X=40960 TO 49151: POKE X, PEEK(X):NEXT
POKE 1, PEEK(1) AND 254
POKE 41865,80
POKE 42086,106
Edited note: I had originally used POKE 41863,203 to get the error routine to end at the K of BREAK but as you can see in his reply it prevented another routine from displaying BREAK correctly, it would still have worked it's just that the K would have been a different character because of the high bit being set :)
I didn't use that approach because the BREAK word is used by two different print routines - one expects BREAK to be 0-terminated, the other uses the high bit. So your patch prints the shifted-K when breaking out of a program. Just do 10 GOTO 10, then RUN, then hit the STOP key and you'll see.
@@8_Bit Ahh, so there would be missing information in your video then. It would have been informative to include that information in the video to prevent others making the same mistake I did from just using the information given :)
how do you get to this location, is it basic rom specific ? A369 shows 00 FF 00 FF ...
Yeah, A369 is in the C64 BASIC ROM. If you're seeing 00 FF etc. then you're probably looking at the RAM under the ROMs, so you have to get your machine language monitor to look at ROM instead. If you're using the VICE monitor, then the command "bank rom" without quotes should fix it. If you're in a monitor running on the C64 itself, then you'll need to fiddle with location $0001, setting the low bit. Typically that'd be storing #$37 in location 1.
@@8_Bit It's an Ultimate 1541 2 with a Action Replay Cart. Image. Hm, there is a $37 at location 1 unless its RAM again. hmm
Ah I found the command. * toggles ram/rom on the Action Replay Monitor.
15:05 "the 69 byte" - giggity