Does anyone know if block copy is soley for copying a contiguous portion of vdc ram? Im working on a windowing library, and if this is true, then to save the screen under the window, I would need to execute a block copy X times, where X = number of rows that the new window will take up. Is this correct?
The VDC's block copy uses a contiguous read-write pattern that starts with the lowest source address and works upward. Therefore, you have to be careful to use the block copy so it doesn't accidentally step on the source. The best way to see how it's done is to look at the screen kernel ROM routines that scroll the 80 column display, since scrolling is nothing more than a series of block copy operations.
You might find it easier to use the 80 Column Display Manager as part of your windowing engine, since it can buffer up to 10 hidden screens on a machine with 64K of video RAM. It wouldn't be at all difficult to create window names to associate with each screen (the screens themselves have internal numbers in 80CDM).
Hey BDD, I would love to use your code with the library, only thing is that it is written in C. But that being said, I would definitely like your opinion of the code if you have some time to take a look. Perhaps some of the routines you have written could be implemented as functions within the library, or improve upon what's already there?
QuoteHey BDD, I would love to use your code with the library, only thing is that it is written in C.
The library itself is written in C? Aren't such libraries usually done in machine code using a relocatable format?
Well, this one is really just C source that could be compiled to object code, so probably yes. I havent messed too much with the linker (cc65), so right now its two C files with the code in it, and a main function to call some test functions (primitive unit testing). At some point Ill figure that out, but as it is, it makes debugging a breeze.