Fixing a Bug in Rodnay Zaks' "Programming the 6502"

[@willproctor7301]

Programming manuals need ring binders, without them there's no way to read and type with both hands. Bloody pages flipping over.

[@fubaralakbar6800]

Use a chip clip : )

[@KurtRichterCISSP]

Like the gorgeous manuals that came with IBMs. Like this beaut www.ebay.com/itm/IBM-Personal-Computer-Hardware-Reference-Library-Technical-Reference-1502234/114440508101?hash=item1aa52f92c5:g:xgoAAOSwpYhfdoE6

[@VulpisFoxfire]

@@KurtRichterCISSP I'm reminded of the Programmer's Reference Guide.

[@KC9UDX]

@@fubaralakbar6800 sure but by the time you have three sections chip-clipped, you risk disaster!

[@rjc199]

I've taken them and gotten them turned into spiral bounds at Staples before.

[@RobinElvin]

I was lucky enough to be given a copy of the third edition of this book back in the 90s by a kind gentleman who used to visit the place I worked. I believe he used to write code for the BBC micro. We must have got talking about 6502 and one day he brought the book in and gave it to me. Sadly, I think he is no longer with us but the book lives on sitting proudly on my shelf. Anyway, I remember he had highlighted an error so I just grabbed the book and sure enough there is an error on page 24. The second to last example (Negative-Negative) has an incorrect representation of -4. I'm amazed it still wasn't spotted by the third edition!

[@tcpbox]

This kind of situation is so good to read, the people that loves electronics and computers seems to be a good person, I also received a book from a friend that works to me in Burroughs I remember that this action made me so happy at that time when I was initiating my journey in computer science.

[@Doug_in_NC]

This brings back memories!. I learned assembler on a BBC Model B using that book!

[@8_Bit]

Thanks to Retro Innovations for being the first to point out yet another bug in my code shown at the end of the video: if the low byte of the length is 1 (such as a length of $101 bytes) then that last byte won't be copied! The easiest solution (pointed out by csbruce) is to change the last BNE to a JMP. You can find this fix in file BLKCPY9 on the updated .d64 in the description. Viewer jjeeeekk came up with a faster-running fix which is file BLKCPY11 on the .d64, and also checkout elandje's version (now bugfixed) which is BLKCPY10. Thanks to everyone for their comments.

[@JesusisJesus]

It’s not your fault that I don’t understand it, I spent my childhood playing games , typing them in, stuffing it up, an d wrestling with tapes. The C64 is a very deep rabbit hole and the more delve into it the more interesting it can get, because there’s so many treasures to discover.

[@kellerkind6169]

So what is copying (moving) large blocks of memory contents used for (in games or other applications) actually? for moving graphics data to screen memory for exampleIi would imagine?! any other uses than that ?

[@jjeeeekk]

@@kellerkind6169 Take a look a the BASIC interpreter and editor. C64 has 38 Kbyte free BASIC RAM, let's assume a program with 33 Kbyte. If you delete on of the lines at the beginning (say the first line), the whole program code above the deleted line has to be moved down. ;)

[@BruceHoult]

@@kellerkind6169 not necessarily all that large, but almost any real world program will need to copy things around from time to time. Go on to any C project on github and search for memcpy and you'll probably find a lot of them.

[@DarthEd77]

When I was in high school (in either 1984 or ‘85), I took a class on the weekends in 6502 assembly at my local community college, and this was what we used as the textbook. I want my money back! :)

[@brianwild4640]

did not learn that this did not work tho lol

[@MS-ho9wq]

Mr. Zaks was just making sure everyone was paying attention

[@Miestro85h]

The 32kb limit may have a good reason: You can't copy more than 32kb on an 64kb system without overlap.

[@mikegarland4500]

These are so interesting. It's like you were reading my mind and creating these before I even knew I wanted to watch them! This one was very straightforward, and I enjoyed it immensely. Except for a pair of typos on my part, it was very easy to follow and experiment with.

[@professortrog7742]

I literally woke up to the digital age with Sybex books in the 80-ties

[@CommodoreFan_nl]

I own this 6502 book also in the Dutch translation. On page 2 of the Dutch version it says "this book is a translation of the original title: Programming the Z80". The translation is good but i always used the English version besides it. I also own an English version of the Z80 book with a different title. This book is sold by Radio Shack with the title: How to program the Z80.

[@jjeeeekk]

Haha, a Dutch only translation gem. Didn't found such one in the German one. :)

[@bryanday7532]

I just happened to find this book at a thrift store in in Albany, CA the day after this was posted. I bought it on the spot.

[@KurtRichterCISSP]

@5:06 Well, if you know your value will never be zero, you can use 8 bits to represent 1-256...

[@ShampooCell]

Fantastic content Robin, thank you as always! This little routine will come in really handy for graphics routines in my program.

[@bluerizlagirl]

If the destination and source overlap, you have to be very careful about the order of copying in case you overwrite something you have not copied yet. On the BBC Micro, copying a tape game to disc usually involved an extra step where you had to load the main program higher up in memory than where it ran from (overflowing into what will be screen memory when a bit mapped graphics mode is used), disable the disc system and copy the program downwards into its proper location in memory that the disc system would have used. For that, you have to work forwards, _increasing_ Y as you go, otherwise you can stomp over yourself.....

[@matthijsh9147]

The books that I learned the most from were also the ones with the most errors (especially Amiga Machine Language from Abacus). After typing in the code you're wondering why it doesn't work, until at some point you realize the book has a mistake in it and you have to figure out by yourself how to fix it. That's much more instructive than just reading. I've considered writing a book that does this on purpose.

[@BFLmouse]

You can't copy more than 32K on a 6502 unless the source and destination overlap. If the block is over 32K, then the size of the source plus the size of the destination is greater than the entire memory space of the 6502.

[@8_Bit]

Yeah, it's not a real limitation; my main point is that it should have been better documented.

[@csbruce]

If the copy loop copied data with an INY, it could be used to move overlapping data downward in memory, which could be a block >32K.

[@jjeeeekk]

@@8_Bit That is a real limitation. If this would be used in the BASIC interpreter, which has to move up to 38 K after, say deletion of a line at the beginning, this routine could not be used. If one claims to provide a sample code on how to transfer more than 256 bytes, it is a poor decision to implant a 32 K limitation, IMHO.

[@8_Bit]

@@jjeeeekk Fair enough; through all this, my main point is that the text should have been clear in what this routine can and can't do. The ultimate routine would allow a full 16-bit length, and allow overlapping memory ranges to shift memory both up and down safely. I saw your other comment about your fixes, I'll give them a try in a bit thanks.

[@jjeeeekk]

@@csbruce My words, it's simply a bad idea to reuse the loop for the remainder handling and forcing it to use decrementation. Just add an extra loop for the remainder (as mentiones in my other posting) or rearrange to whole program in that way that FROM and TO are adjusted by the low byte of LENGTH and starting with minus low of LENGTH in Y. This let the loop finish with 0 without handling a remainder.

[@csbruce]

0:56 I used to have that 6502 book. 0:58 Um, that's *_DOCTOR_* Zaks… 9:20 The LDX #BLOCKS is rather buggy. What if you wanted to copy just five bytes? You'd set BLOCKS to 0 and REMAIN to 5, but this code would copy the first block regardless. It's always a good plan to program defensively and handle sizes of 0 (or ≤0 with signed types). It's quite plausible that a calculated size of 0 bytes will be thrown at you at some point. 9:42 I was thinking that the memory-fill routine in your Patreon video the other day looked kind of familiar… 11:42 The copy-block routine could be optimized by unrolling it at last one time over by simply adding a second sequence of « LDA (FROM),Y : STA (TO),Y : DEY » (assuming this loop wasn't erroneously re-used). This would cut the overall cost of the BNE statement in half. It's also worthwhile in a tight loop to consider the cost of spanning page boundaries. The LDA (FROM),Y adds one cycle for crossing into the next page while that's free in the STA (TO),Y instruction. If the "FROM" address is at the start of a page, such as in your example of $1000, there won't be any additional cost. 12:15 I prefer to use operands like "FROM+0" instead of just "FROM" to make it very clear that "FROM" is the low byte of a multi-byte value. This extra clarity doesn't take any extra time or space in the assembled code. The post-increment «INC FROM+1» operation also prepares for the "REMAIN" copy of the last group of

[@KurtRichterCISSP]

I was gonna say all that but Bruce scooped me.

[@jjeeeekk]

Well commented, so I havn't to sum all these up again. ;) Just want to add that more then 32 kbyte is not uncommon even on a 64 k machine, because the source and destination region could overlap (imagine you have a large C64 BASIC program and you delete the first line of code...). In this case the destination has to be lower then the source. But in this version the distance has to be greater then 256 bytes (it's not generally useable to move, let's say an overlapping block by just 1 byte). This is because the inner loop uses decrementation. It has to be increment if it should generally work. As already mentioned, one may take a look to the C64 BASIC memory move routine at $A3BF which does it right and efficient, which transforms the from, destination and length appropriately to be able using the dey-dex to 0 technique. ;)

[@cadeanderson422]

This comes across as a bit pretentious

[@dwhxyz]

@@cadeanderson422 I suspect most people will find these comments come across as some really interesting additions to an already great video...

[@richardkelsch3640]

Wow, not trying to be trollish, but that is a lot of code just to transfer memory blocks. Despite arguments to the contrary, I see the 6502 as a primitive RISC processor (before the term was even brought up). My first CPU where I programmed in assembler, was the Z80, and to transfer a block was just load the HL register pair with the source 16 bit address, the DE register pair with the destination address, and the BC register pair with the number of bytes to transfer, and then using LDIR (or LDDR for backwards transfers) and voila, the CPU did all the work. I guess I was spoiled. I actually have a lot of respect for 6502 programmers doing so much with such little CPU capability. Granted, the 6502 was far more efficient per clock than most Z80 op-codes, but it was also a lower priced CPU, which made sense for easy hardware designs. I tip my hat to you 6502ers.

[@weedmanwestvancouverbc9266]

I remember Jim Butterfield talking about the 6502 and how it made use of clock Cycles much more efficiently because the instructions could be a variable length depending on how it was used. If I remember rightly this was proven correct as ones that used instructions that were all the same length tended to have less efficient ways of doing things sanded up needing more clock Cycles anyway

[@timsmith2525]

I, too, learned Z80 first-and it severely hampered my ability to learn 6502. What do you mean there aren't any 16-bit index registers?! And no: zero page is absolutely NOT like having 256 registers.

[@8_Bit]

Yes, the 6502 definitely takes more code for many typical tasks, but because of its design is roughly 2-3 times as efficient in executing that code, clock for clock, than the Z80 or other similar processors. I remember when I finally learned some 8086 in university, it felt like programming in a high level language compared to the 6502. Multiple 16-bit registers seemed ridiculously luxurious.

[@richardkelsch3640]

@@timsmith2525 True, there's absolutely no way a memory address is as fast to access as a CPU register is. However, the 6502's method of shortening a series of op-codes to only need an 8 bit "address" for a page zero access, meant the operation was able to be shortened to access that zero page. It is a trick to slightly make up for the lack in registers. What made the 6502 desirable, despite its obvious architecture lacking, was its ability for easy circuit designs to support it. Since everything was based on a memory address, everything is treated as a memory address. Whereas, on a Z80 you have memory space, register space, and I/O space. What you lack in sophistication, you make up for in efficiency.

[@richardkelsch3640]

@@8_Bit Indeed, but this video makes the shortcomings of such a severely limited instruction set glaringly obvious. After all of the bug fixing, you still had yet another bug at the end of the video (you already addressed in another comment). What you have demonstrated was the great drawback in 6502 execution efficiency versus coding efficiency. This, sadly, discouraged me from also learning 6502, as I already knew Z80 (in the 80s). The Z80, as far as capabilities available, makes programming far quicker and if I wanted faster speed, the Z80 had far higher clock speeds available as options. However, what any software engineer will tell you is, once you get your own common routines (memory copy etc.) debugged, you can use them on many projects, and the issue of fighting through things like this are minimized.

[@eugenetswong]

Thank you, Robin, and Robin's patrons.

[@benanderson89]

If you want to get back into the monitor after the shortcut has been disabled by TMP, type " @@MON " at the basic prompt. I use a THEC64 so I don't have a cart reset button to get a fresh start without diving into the menu, and I noticed that when I did press shift F8, it quickly flashes the "@@MON" command on screen. I typed it in on a whim and voila, it worked! Shift F8 is just a shortcut to type that in, sort of like a macro -- seems like a waste of ROM Space to type something into the prompt automatically, rather than just call the routine directly.

[@PebblesChan]

There’s always errors and omissions in these types of books. Even Zilog’s latest version of their Z80 user manuals have introduced new errors. The best way to check them is to have the data sheets on hand.

[@jjeeeekk]

Zaks' books (Sybex line from other authors too) should always taken only with caution. The are several errors in sample code or just typos (even in the instruction reference part, which makes it a not very reliable source). Found such in 6502, Z80 and 6809 ....

[@JacGoudsmit]

Until I was about 17 and we got an IBM PC, Rodnay Zaks taught me everything I know about assembly language. I read the first edition front to back, some of it during classes at school. And I probably owe someone an apology for wearing out the covers by carrying it around in my book bag for a few weeks.

[@KubuntuYou]

This is the book i went with when I was learning assembly a few years ago. I liked the cover more than the alternatives so i bought it. Glad i did.

[@flatfingertuning727]

Rather than trying to copy multiples of 256 bytes and then copy the residue using the same loop, it's often better to handle the residue *first* or separately. The lack of a test to say whether a decremented value *was* zero is a bit irksome, but I don't like the style of copying a byte disjointly from the rest. If the destination is a screen buffer, copying things out of order like that may cause a few bytes to appear a frame sooner than everything else near them, which may be a bit ugly.

[@jjeeeekk]

That said, see the suggestion kzbin.info/www/bejne/mnjCoI2Ma9hjkMk&lc=UgwiDK-pGVVGm74dMu54AaABAg

[@Kwstr42]

Yay Moar Robin, I have been looking at C64 books you recommend for when I get my Maxi next month. Also wood paneling my maxi corner for maximum retro, everything retro needs woodgrain

[@BertGrink]

I bet you're following LGR too! 😁

[@Kwstr42]

@@BertGrink what makes you think that? :P

[@rivards1]

I go by the rule that Americans should afford British the respect for their computer and call it the "Zed-X-80/81/Spectrum", but Brits and Canadians should conversely call the American-made chip the "Zee-80" as it was designed to be called.

[@PJBonoVox]

I'm a Brit and I (probably already unintentionally) do exactly that.

[@8_Bit]

It's a reasonable proposition. But I'm just trying to make the Z80 sound more classy!

[@TheHighlander71]

I've read both of mr. Zaks' books and frankly I've been surprised that his texts have been so popular. I've found his books to be cryptic and unecessarily complex. His z80 book starts with writing 16 bit maths routines. While useful, I found it a questionable start to introducing z80 programming. In the program you've analysed I wondered what the value of #REMAIN was. I couldn't see where it was set. Enjoyable video Robin. I've found myself trying to kreep into the heads of many programmers in an attempt to figure out what their code did. It's mental gymnastics! It should be in the Olympics.

[@TheHighlander71]

Ah..found the answer to the remain question :)

[@BruceHoult]

At the time, I liked the book by Lance A Leventhal much better.

[@TheHighlander71]

@@BruceHoult They must have been very good because they are offered for a lot of money right now.

[@trickyrat483]

If only I hadn't sold my copy.. ..back in 1983. :) The time goes so fast.

[@PebblesChan]

Adam Osborne, Liz & Joe Nichols, Nichols & Pete Rony, Lance Leventhal, Alan Miller, Kathe & Dan Spracklen, Jerry Kane, Russell Rector and Sussana Jacobsen were all great authors of 8 bit microprocessor books.

[@jjeeeekk]

Beside some bugs in sample programs (to be counted on the author) Sybex introduced a lot of typos ... such books are good for learning, but use it only with caution for reference. ;)

[@vanhetgoor]

First I will tell you an anecdote. This happened last century. There once was a restaurant that needed a new food ordering and payment system. The restaurant was owned by former Russian "businessmen" they paid the programmer good money and they demanded it had to be ready soon. The programmer started working on the project and soon it was operable. But there were problems, there was less money in the cash-register since pro new programme was in use. The programmer made one tiny mistake. In real life you start counting at number one, in computers the first record is number zero. When the waiter filled in the order, the computer started with the first record at zero position. The programmer added only the record number one till the last item ordered. Leaving the first record out of the total. The result was that the restaurant suddenly lost great amounts of money. When the programmer was asked what happened, he looked over his work and he found his mistake, changed it and left the island overnight. If Rodnay Zaks it talking about "256" then I am not surprised. If you use Hex for an address or a location then the zero (&H00) is the FIRST address in a row and &HFF (255) is the 256th address in the row, if you are adding and subtracting the zero is nothing, then one means 1, and that is odd. Within one system there are two different meanings of numbers, but you have to keep on paying attention. Because if you don't the Russian "businessmen" could be annoyed, and nobody would like that. The programmer went off the island into alcoholism. The islanders kept quiet about the programmers mistake and soon the heavily overweight Russians were fed up with being a restaurant owner and found something else to play with. So listen to me, 255 is 256 inclusive in real life.

[@SuperMurrayb]

That was interesting. The easy fix is to have your lawyers change the licence agreement from owning a copy of the software to just owning a license to use software they never own. That allows new and expanded versions of the software to be developed without fixing the earlier versions. Adding sound to the block transfer would be a nice improvement.

[@KC9UDX]

Errors, careless omissions, and large portions of books devoted to common knowledge, made books of that era very frustrating. Add to this the difficultly of obtaining *any* kind of technical publication...

[@moshly64]

Showing how to implement this as a basic command would be an interesting followup.

[@Wil162]

Awesome video! I don’t know if this has been pointed out before, but for you final solution, I think you can replace the three lines before the ending rts (beq done, dey, bne next) by a single bne next2, where next2 is a label pointing two lines below the next label at the line with the dey command in the loop. This saves three bytes at the cost of three cycles (one time). Don’t worry about the cpy #ff backfiring at you, since we eliminated the case with y=0 before the dey.

[@8_Bit]

Yes, I think you're right. I wish KZbin would allow videos to have updates or even addendums, but I suppose it would be abused too much. I did update the .d64 linked in the description with some improved versions of the code based on some suggestions I received. Thanks!

[@Wil162]

I think this fixes also the problem when the remainder is 1

[@flymario8046]

This should have been filmed on a Breadbin. So very heartless! Great job. I always love your videos.

[@jeremypnet]

My Dad had the first edition. Although it’s pretty good, it was somewhat notorious back in the day for the mistakes. My Dad’s copy was full of annotations where he had found something that was wrong.

[@AriadneJC]

8am and the first video I watch as I have breakfast is 6502 assembly? What a way to wake up properly.

[@matteopascoli]

Seeing your comment, I was curious and clicked on your icon. Do you know when you see someone that shares many subscriptions with yours, and there is a good chance that the other channels they see - and you don’t know yet - may actually be interesting? Omg it reminds me of Napster times 😄

[@leesmithsworkshop]

I have the 6502 book, but trying to find his Z80 book in the uk below £100 is not easy, some are close to £300 :(

[@ShaneDiegoTube]

Holy smokes! I had the 4th edition of the "Programming the 6502" book!

[@elandje]

The code as shown is still wrong, if

[@8_Bit]

Yes, thanks, jbrain pointed out my error in another comment. I'll look at your solution now. (and by jbrain I mean RETRO Innovations)

[@3DPDK]

The best and I think intended use of indirect indexed ( $add, x ) is when using a look-up table to point to a location within another block of data. Similar to a vectored jump, you could consider it a vectored load. The *real fix* to this comes when the programmer realizes that *you can move down through memory* to perform block manipulations. You don't have to count up in memory. Example: Fill the screen with 1000 bytes of a stored screen display at $C000, but protect the last 24 bytes beyond screen memory of block 7. Like the example in the video this is 3 full blocks + 232 bytes of the 4th block. or a "REMAIN" of 232 set ZP1 ; zero page store pointer to $0700 (4th block of screen memory) set ZP2 ; zero page load pointer to $C300 (4th block of stored screen data) LDX #$4 LDY #$E9 ; = 233 but gets decremented to the desired 232 at the beginning of the loop . LOOP . DEY . LDA ($ZP2),Y . STA ($ZP1),Y . BNE LOOP; zero flag set by DEY and unaffected by either STA or LDA . DEC $ZP1+1; decrement the zero page pointers hi byte down -1 . DEC $ZP2+1 . DEX . BNE LOOP . RTS This manipulates exactly 1000 bytes of memory without worrying about comparing the Y register to some remain number and having to decide exactly when to worry about comparing the Y register to some remain number. If you watch the screen when you [shift]+HOME you might notice that the system fills the screen with spaces from the bottom up and leaves the last 24 bytes of block 7 alone. This is how the system block fills exactly 1000 bytes of screen and color memory.

[@williamsquires3070]

This actually still has a bug in that it will not copy properly if dest < src, and they overlap. Let’s say that src=0x1000 and dest=0x0980, and we want to copy 0x0100 bytes. The 1st thing it’s going to do is copy the byte @ 0x10FF -> 0x107F (0x0980+0xFF), but this is still in the source buffer, resulting in overwriting the source buffer, and - if that were executable code - it’s now corrupted. The loop needs to copy from low->high. The existing loop will, however, work if src < dest and they overlap. So this program needs to do a 16-bit comparison (subtraction) between src/dest. If they’re equal, exit out. If src < dest, use the loop that counts backwards, else (src > dest) use a loop that counts forwards. This will still work if the ranges do not overlap. I won’t get started on how to handle copying more than 32kB, however! 😏

[@8_Bit]

Hi, yes, a memory copy that can handle overlapping ranges is an extra challenge. I'm not sure it qualifies as a bug, but it's certainly a limitation of the routine and would cause bugs if used that way!

[@jjeeeekk]

Even the limitation is not mentioned by Zaks IMHO the mission should be to provide a general useful solution. The reader is left with questions how to circumvent such limitations ... it's not not a ideal style of a such a teaching the basics to provide half-cooked solutions. If it would overload the section the author had the opportunity to provide a full-blown solution in an appendix. Yes I know, this is out of scope from what Robin has presented here. ;)

[@ryancraig2795]

Lol, you're using the Commodore 64 Programmer's Reference guide as a reference. As a 14 year old, with that as my only reference to 6502 addressing modes, I puzzled and puzzled over the difference between indirect indexed and indexed indirect. My general knowledge of programming concepts was pretty fuzzy still, too. I understand it now but it's still a little confusing.

[@rarbiart]

I never imagined that my 6502 Bible could contain a bug!

[@bitti1975]

Very interesting! But I found the fix a little bit boring. I would like to know if there is a way to reuse the block loop for the remainder without a performance penalty. But the ideas I came up with need more additional code than just using a separate loop for the remainder... So I suppose csbruce is right, just using a separate loop for the remainder is best since it also leaves the option open to optimize the block loop via unrolling. Still, for a generic copy function this code is still not complete (or dare I say "buggy"?): because the source and target ranges may overlap the program needs to choose the best method (wether to copy in a decrementing or incrementing fashion) accordingly.

[@TrebleWing]

Can you really call yourself a coder if you haven't been struck by the infamous 'off by +/-1' error or two. I've made this exact error many times.

[@joellagerquist1791]

I have always said "It is programmer's license to be off by one"

[@mattiviljanen8109]

Does it count, if I have written a case of "off by one or two"?

[@TrebleWing]

@@mattiviljanen8109 That is extremely meta... I love it.

[@mrmimeisfunny]

Well, at least you haven't published 4 editions of a book with off by 1 errors.

[@aihtdikh]

That is a _very_ clean C64! Did you make a new case, or is this just a very well-cared-for system? Either way, thank you for sharing this deep dive into just how hard assembly programming can be. I believe I have this book somewhere, but I've never had a 6502 to test with. This makes me want to read it again!

[@8_Bit]

It's a regular vintage C64 but I'm just generally pretty careful with my stuff :) And I generally try to clean everything before it goes on camera (though sometimes I forget, or my old eyes just don't see what the camera sees).

[@gpiforgoo]

Stupid question: Instead of adding a check to $ff in the inner loop, would it be faster to add a manual copy of the index 0 in the remain section (near dey to remove the additional byte)?

[@jjeeeekk]

Would be also a solution ... something like REMAINDER LDA #

[@gadi70]

It would be lot faster, altough needs some more space. I'd fix also the linear copying - would be nicer, when copying directly to screen ram or such.

[@jjeeeekk]

@@gadi70 Right, see my previous posting, which Robin has included in the D64 as blkcpy11. It takes only 1 byte more in comparison to the fixed version from the video. ;)

[@gadi70]

@@jjeeeekk Nice one. Can't see the problem with able of copying only 32k of data in 64k of address space =) Altough if more than that, linear copying would be the thing to do.

[@ReneKnuvers74rk]

The routine can copy 32kB on a processor that can only address 64kB of memory. Since source and destination cannot overlap (and the program itself occupies memoryspace too) you will NEVER run into the max limit of the routine in a real life situation.

[@BagoZonde]

But this routine didn't work even when copying 4 pages (which is just 1kb) from $1000 to $2000 .

[@golomak6626]

It's strange that Zaks explicitly states he will "first assume" that REMAIN is zero, but then he just ignores that and incorporates REMAIN in the code anyway. To be fair, as long as REMAIN actually *is* zero, the code works fine. :)

[@darthbukowski6894]

I really enjoy these book posts.

[@mcnilz]

So many bugs. Test driven development came into my mind. Maybe there is a clever tool chain on the C64 for TDD.

[@MrThomashorst]

Probably Zaks originally planned to initialyze Y with the remainder and wanted to run the reverse transfer until both pointers (X and Y) reaches zero. That will be a much more efficient algo.

[@AnnatarTheMaia]

As you rightly pointed out, this code can only copy up to 32 KB, so that's still left to fix. In fact, the next level challenge would be for the code to be able to copy an arbitrary size beyond 64 KB and into terabytes. Why? Because why not!

[@MrVasile]

Considering the "edge cases", I think there is still a problem if you wanted to transfer a full 64k. The problem originates in how length is represented...as the actual count contained in a 16 bit number. However, with that method, the largest length you could enter would be $FFFF, which in counting numbers is 64k - 1. The solution might require an understanding that a length of $0000 is the full 64k, then some special handling in the code.

[@CollinBaillie]

I don't think that's right. Sure the most upper byte would be NUMBERED (address) 65535 (64kiB - 1), but the lowest is still 0. So you'd get the full 65536 bytes copied.

[@fplancke3336]

Given that your 64K have to contain page 0 with important system data you don't want to overwrite, including but not only the control variables FROM and TO, this is largely theoretical...

[@mykalimba]

Regarding the error persisting through new version after new version... in those days, it wasn't trivial to contact an author to make them aware of an error like this. You would probably snail-mail the publisher, and the publisher may or may forward the concern to the author. Maybe you could research the author (perhaps at something called a "library" back then) and somehow contact them directly, but the effort probably always outweighed the desire for anyone to see the issue corrected. These days, of course, you can just @ the author on your social media platform of choice, and make them aware of the issue.

[@8_Bit]

Totally true, but still seems slightly surprising given that it was a college textbook and he must have been getting some feedback to prompt the different revisions? But yes, it was certainly a lot more trouble back then.

[@BillAnt]

At 11:00 wow that threw me for a loop (pun intended) by DEC-rementing the Y register index instead of INY-ing it which could have also eliminated the #REMAIN bug. Love to see different solutions to the same problem with a little bug fix. heh I was wondering, is it possible to write the Turbo Macro Pro program to some storage cartridge like KungFu Flash or others so you don't have to load it manually from disk every time? Or better yet to be always available by simply SYS32768?

[@8_Bit]

Watch my recent video '"Hello World" on Commodore 64 in Assembly Language, Machine Code' and it shows the SnappyROM for Kung-Fu Flash that has Turbo Macro Pro built-in. Links in that video's description.

[@BillAnt]

​@@8_Bit - Thank you for that info, will definitely check it out. :) While moving bytes indexed by Y $FF to $00, or from $00 to $FF has the same end result, I was made this little mod in the code to move it from $00 o $FF. It's untested so let me know if this would work. (by the way, the "remain" loop also needs some modification to work properly). . LDY #$FF ; Start with $FF but instead of DEY do INY for index $00 . next INY ; Wrap around index to $00 and start moving byte $00 LDA (from),Y STA (to),Y CPY #$FF BNE next ; Exit loop once we copied the last byte in block

[@BillAnt]

​@@8_Bit - Does the Kung-Fu cartridge version of TMP reside at the same address as the disk loaded version at $C000? Besides the cartridge version being instantly available, are there any other benefits such as not taking up any ram or being able to move the code to a different memory location?

[@mykalimba]

Technically, the V2 code was copying the correct NUMBER of bytes (as specified in code), it's just that those bytes included an extra byte on the end, and was missing one at the start. Maybe this is the earliest documented case of the off-by-one error? 🤔

[@snakefriesia6808]

yes, this could well be the case of the very first documented off-by-one error published

[@BruceHoult]

In the 1970s? No way. Decades before that.

[@mykalimba]

@@BruceHoult Yeah, there were most certainly occurances before this, but are any of those occurances DOCUMENTED in some form? ;)

[@edabean007]

Ty patreons :D

[@_jmeg_3436]

I have the 6502 book and it’s fantastic. I had no idea that the GameBoy used a Z80 derivative, though. Really cool!

[@MrSegmentfault]

Z80 was the most commonly used 8 bit cpu in Japan. (arcade, Msx, sega) Nintendo was the odd one when they sourced the 6502 for the Famicom.

[@8_Bit]

Yes, and that's how the guys at HAL Labs got involved in the early NES games; because they had been coding games on PETs at university, they were some of the very few in all of Japan with 6502 experience!

[@BagoZonde]

About the argument at 11:00 with dey used instead of iny, well, it's a good point and I agree it doesn't help the readability there, but I think I know from where it came. It might be just a result of a habit when using this sort of an optimization in situations where you have a value less than 255 and you want to avoid cpy in order to save some cycles when using absolute addressing, e.g. STA TABLE - 1,y. Good point though, here this part of the program could read much easier with iny.

[@fstasel]

Great video again. Btw, "dey" instruction is necessary in the original code for block copier loop to handle to copy remaining bytes since it counts down to zero. Moreover, i don't think that initializing y to ff and comparing it to ff is necessary. Thank you for great instructional video!

[@WilliamLDeRieuxIV]

4:59 "We can no longer use a single index register as 8-bits do not suffice to store a number greater than 256" I guess what they were going for was just 2^8 = 256 = 0001 0000 0000 (and incorrectly thought that was 8-bits). (2^8) + 0 = 9 bits = 256 (0001 0000 0000) [using 8-bits registers would require two registers, a total of 16-bits even if the high 7-bits are unused] (2^8) - 1 = 8 bits = 255 (0000 1111 1111)

[@CollinBaillie]

Ahh, the author. I auto corrected that in my head to "256 numbers" as I watched, but yeah, if I read that around the published date, I would also have taken away some false information.

[@WilliamLDeRieuxIV]

​@@CollinBaillie Yeah I think the author was going for something like "we cannot store more than 256 numbers." Either that or it was a typo and they mean to say 25*5*, though I would think someone would have caught it in a proofread -- but seeing as this was just a small demo they probably didn't pay all that much attention to it.

[@mikeziniti]

Late to the party here, but has anyone pointed out how much the song at the end sounds like one from Olive the Other Reindeer?

[@d2factotum]

I may be thinking about this too simplistically, but considering the original problem was that a single byte didn't get copied, wouldn't the easiest fix have been to add an additional LDA instruction after the last instruction in the original loop? Sure, wouldn't have fixed it for someone passing a zero length, but it wouldn't have made the loop slower either.

[@stuartmcconnachie]

Not only does the routine not copy the last (0th) byte in the final block, it also can’t do overlapping copies (even in the downward direction) if the source and destination are less than 256 bytes apart. Granted you’d still need a different (reverse copy) routine to do an upwards overlapping copy. But given how trivial it is to use the same routine for non-overlapping and downwards overlapping copy, the buggy optimisations in this example seem particularly pointless.

[@srfrg9707]

Damned! I had the same book. Where do I write to ged my refund?

[@karlos2586]

Great man!it's always a trip on the time tunnel!!!

[@j0eCommodore]

What timing! I was looking at some old PET code that does screen invert and it is kinda sloppy, does 1024 bytes - if I were to move it to 64 that would not be good as would then smash BASIC program space. I can adapt this to make a more accurate invert screen characters routine. Thanks!

[@Grunchy005]

I can't help but notice you still have a bug! If len=$0001 the routine will not copy even a single byte. In the corrected code it will ldy #>len, beq remain, and at remain it will ldy #

[@benjaminnice]

Hi, I guess the technique you use for 16bit numbers is only for your assembler or maybe a group of assemblers? So someone only with standard 6502 maybe confused 🤷‍♂️

[@8_Bit]

I think only the earliest assemblers from the 1970s and maybe very early '80s wouldn't have the low and high byte operators < and >. This was further extended for the 65816 with some assemblers using the ^ operator for the "even higher" (bank) byte in a 24-bit address.

[@mykalimba]

I used the C64 Merlin assembler, and various cross-assemblers that ran on Atari and PC machines, and they all had the low-byte and high-byte assembler "operators", IIRC. Understand, that the assembler is just a program/tool (application, in today's nomenclature) that translates a file (or multiple files) of characters to machine code. Its simplicity or complexity is a function of how much effort is put into creating the tool. Early assemblers were bare bones, but as time passed, they became more powerful with cool directives and operators that did things to make writing assembly language programs much easier.

[@benjaminnice]

Hi, Thanks guys. I have only really written a small amount of 68k assembler and motorola use to publish the 68k programmers ref, so there wouldn’t be as much room for assemblers to vary. Although I could be wrong.

[@G7VFY]

Does the Lance Levanthal book have any similar errors?

[@8_Bit]

I was surprised not to find any in when I read through it about 6 months ago. It's a very dense book though, with surprisingly small type, so I have to point out that I probably wasn't giving it the same sustained level of scrutiny I gave Zaks' book :)

[@odedavrishami9087]

great to see that man. liked it very very match.

[@Inquire98]

Thank You, thank you very much ☺️ I'd like to know 🙄 if there is a career and future in 8-bit computing 🤔 Let me know 👍🏿

[@TheCodeCrafter]

Hey Robin, great video. I wanted to take a look at the code and have discovered that the link for the .d64 file seems to be broken. I think youtube is doing some redirection but its failing out. Not sure if this has something to do with the fact that your not using SSL for the destination or not, I know Google is concerned about non encyrpted sites these days. Anyways, can you just post the url in plain text? Thanks!

[@8_Bit]

Strange that the link isn't working; it's just plain text for me here and the download works (using Chrome on a Mac) with both http and https. Here it is with https in case it helps you: 8bitshowandtell.com/prg/tmpzaks.d64

[@TheCodeCrafter]

@@8_Bit Hey Robin, thanks so much for getting back to me so quickly. So I was using Chrome (version 87 on Linux) and the link in the show description didn't work. The link you provided above did work, no issues. I tried the link in the description on my work Mac, running Chrome (version 88) and no dice; on Safari no issue. What version of Chrome were you using when you tested it? I wonder if we have a change in the behaviour of newer versions of Chrome, or simply a bug somewhere... Thanks so much again for getting back to me again! Regards, Craig.

[@AndyH2O]

and the song at the end is great too!

[@BruceHoult]

Is it really not possible to run the program directly from the monitor? On the Apple ][ you'd just say "900 G" and no need to pop into basic.

[@8_Bit]

G 900 would run the program from the Super Snapshot monitor, but the RTS at the end would likely crash since that monitor only gets banked in when the "freeze" mode on the cartridge is active. Calling it from BASIC allows it to return cleanly. There may be a workaround; I'll try to figure it out if I do similar experiments in a future episode.

[@BruceHoult]

@@8_Bit I don't have a C64 or this cartridge, but I found a manual (for 5.0). It says the BR command in the ML Monitor sets the BREAK vector so it enters the monitor. So you can just end your program with $00 instead of $60.

[@mykalimba]

Those books look to be in mint or near mint condition! I still have my 6502 book, and it's ratty as all heck!

[@8_Bit]

I've always been (overly?) careful about my stuff but if you check out last month's video about the C64 Programmer's Reference Guide you'll see my old roughed-up copy there. I even find blood on a few pages!

[@MattKasdorf]

I'm actually surprised that after all this time that there isn't a place with known good routines, such as a block copy, for the 6502. Every new 6502 Assembly coder shouldn't have to reinvent the wheel.

[@8_Bit]

There's some pretty good resources here: codebase64.org/doku.php?id=base:6502_6510_coding and here: 6502.org/source/ But re-inventing the wheel does seem to be what most 6502 programmers do anyway :)

[@carlmuller8967]

If your code is not in ROM (e.g. for C64 your code will be in RAM) just use self-modifying code - there is no instruction cache... save the cycles per byte copied!

[@MattKasdorf]

I've yet to try, but are the C64 Zero Page memory locations (FB, FC, FD, FE) also available on the original PETs, or Upgraded # BASIC PETs? 🇨🇦

[@MattKasdorf]

Tried, it does appear to work 🤔

[@AlexEvans1]

leave the original loop alone, for the remain, check for zero, if zero return, if not decrement, branch to where it did before, at branch done instead branch to last and pick up remaining byte. it runs nearly as fast as the original code, and teh code is only a couple bytes longer.

[@davidjohnston4240]

I learned 6502 when I was 10, from the first edition, which I still have.

[@michaelbarry8005]

How about if you special-case for y=0 and rearrange for same size but slightly faster because you can eliminate the CPY instruction in the inner loop? *= $0900 source = $1000 dest = $2000 len = $0408 from = $fb to = $fd lda #source sta from+1 lda #dest sta to+1 ldx #>len beq remain ;handle < $100 ldy #0 ;copy from top next0 dey next lda (from),y sta (to),y dey bne next lda (from),y ;copy y=0 byte sta (to),y inc from+1 inc to+1 dex bmi done bne next 0 remain ldy #

[@jack002tuber]

Great video, thanks for releasing it. The commands you used, #> and #

[@8_Bit]

The Turbo Macro Pro assembler can be downloaded here: turbo.style64.org/ I also included it in the downloadable .d64 in the video description, so the source files can just be loaded up easily in an emulator.

[@jack002tuber]

@@8_Bit Thank you!

[@saganandroid4175]

At 13:08 there seems to be a rather confusing (to ,me, anyway) edit. 13:42 you talk about a 32K limit and some high bit. Wait, what?

[@GrowlyBear917]

Using BMI as a branch means the branch will be taken whenever the highest-order bit is a "1". That means that only 128 values can be used, 00 to 7F. Once you go past 7F, the highest order bit becomes "1" and it branches. But in all practicality, the limit on this program is you can block-copy the lowest 32,768 bytes of memory to the highest 32,768 locations, and since the Commodore 64 only has 65,536 bytes, this program will work fine. It's when you start using banked memory, like in a Commodore 128, or in a computer that has even more RAM, that you need larger numbers. But usually with 8-bit computers, the memory range for your destination will be defined by a bank number, which is a separate register, located in the memory-management unit or MMU. And that high bit... In "Signed Integer" notation, it is the SIGN bit. Signed integers are not from 0 - 255, instead they are from minus 128, through zero, onward to positive 127. The next number after 127 is minus 128. Hope that clears up stuff.

[@8_Bit]

Thanks Growly Bear. I'll take a stab at it too: BLOCKS is a byte representing the number of 256-byte blocks to copy, while REMAIN is another byte representing the number of bytes remaining to copy in the final (incomplete) block. BLOCKS and BYTES can be combined into a single 16-bit value length as I show later in the video during the C64 section. Normally a 16-bit length could represent up to 65,535 bytes (assuming 0 is allowable too) which is 64K. But instead the X register (which is counting the number of blocks) can only hold 7 bits of length because its high bit is dedicated to flagging when the remaining bytes are being copied; BMI checks if the high bit is set and if so its considered negative or "minus". Since we've lost that bit, we only have 15 bits dedicated to length, and 2^15 = 32,768 bytes or 32K. Why didn't I just say that in the first place, eh? :)

[@michaelbarry8005]

It might not be as fun as figuring things out for yourself, but most mere mortals aren't going to beat Bruce Clark for this. www.6502.org/source/general/memory_move.html The reason he offers moveup and movedown is to allow you to choose which one provides proper results if the regions overlap.

[@gadi70]

it seems we are here for a 8-bit storage?

[@TomStorey96]

Z80 equivalent ld HL, 0x1000 ld DE, 0x2000 ld BC, 0x0408 ldir But where's the fun in that 😋

[@8_Bit]

Yeah, the Z80 is certainly nice for some of these tasks :)

[@andrewdunbar828]

That's the simple way, but it's not the fast way (-:

[@stefanedell3467]

for loop value 255-0- random memory- when 255-0 if 255-0 = true my value true= 255-0, execute value, if value: 255-0

[@MattKasdorf]

BlkCpy9 and 11 are essentially hidden from me in the .d64 file, might someone please post the whole code as a comment.

[@jjeeeekk]

My version AKA BlkCpy11: SOURCE=$1000 DEST=$2000 LEN=$0200 FROM=$FB TO=$FD LDA #SOURCE STA FROM+1 LDA #DEST STA TO+1 LDY #0 LDX #>LEN BEQ REMAIN NEXT LDA (FROM),Y STA (TO),Y INY BNE NEXT INC FROM+1 INC TO+1 DEX BNE NEXT REMAIN LDX #

[@MattKasdorf]

@@jjeeeekk Excellent! Many thanks, it seems to work 🤔 even though $FB-$FE don't appear to be "free" locations in the Zero Page for the PET/CBM.

[@MichaelDoornbos]

My eBay patience paid off again. I just picked up a First Edition (Green Cover) of this one. Woot!

[@LibertyWarrior68]

It might not be a bug, rather a feature, you might not want the late by copied.

[@gekk1985]

how about 68000?

[@The.Doctor.Venkman]

Great video Robin. I also liked that you pronounced the letter 'Z' as Zed not Zeeeeee lol!

[@TheWyleECoyote]

Why? You often mistake the letter z for something else? Maybe the number zero is too easy to mistake for something else as well so you call it "not" instead? What do you use instead of 'not' in a conversation when you mean the word "not" instead of the number '0'?

[@wolcek]

Well, if this was the only bug here... Let's make TO=FROM+1, and all goes haywire.

[@TheEmbeddedHobbyist]

Don't tell me now the book i've had for years has a bug in it, with all this covid-19 the last thing i want is an old bug. :)

[@elandje]

The program can be simplified even more if you decrement the Y register before the transfer, the code will then be more elegant: lda #source sta from+1 lda #dest sta to+1 ldx #>len beq remain ldy #0 next dey lda (from),y sta (to),y cpy #$00 bne next nexblk inc from+1 inc to+1 dex bmi done bne next remain ldy #

[@jjeeeekk]

Use TYA (which sets the Z flag also) instead of CPY #0 (in this case A can be destroyed). This aves one byte of code, even thought cycles remains the same.

[@8_Bit]

Hi, I gave this a try with a length of $101 and source and dest the same $1000 and $2000. It seems to properly copy $1000 to $2000-$2100, then leaves $2101-$21FF alone, but then continues copying to $2200 and beyond until it writes over IO and crashes. It seems to be missing an exit condition after the remainder section is handled.

[@elandje]

@@8_Bit Yes, the program was not correct, my statement that the instruction 'bmi done' was not necessary was false. I've reinstated this instruction and now the program should work so I hope you will give it another try. Bug free programming stays an art in itself...

[@elandje]

@@jjeeeekk Yes, I had the same thought later, but didn't want to change the code.

[@8_Bit]

@@elandje Okay, thanks, I tried out the revised version and it seems to work great. I've updated the .d64 and your version is BLKCPY10 on there.

[@thatlinuxguy]

Lol my university library still has this book. I might take a look.

[@FoxyVulpes]

Original NES uses Z80? .. actually that's wrong, the original NES uses a RP2A03 / RP2A07 CPU, which is based on a 6502, without BCD ....

[@8_Bit]

I included the original NES in my list of 6502-based machines, from 0:18 to 0:36.