Correct VDC Programming from BASIC

[nikoniko]

Well, you're assuming that the test write will actually hit the location we think it's going to hit on a 16K machine.

I'm not assuming. I've now tested it, and it does. And even if it didn't, say it landed in unpredictable places on different 16K setups, it still makes a ton more sense to save and restore one or two locations than to replace an entire 8K. There's absolutely no reason this test needs to take close to a full second to complete. It wouldn't be unreasonable if the delay were necessary, but here it definitely isn't.

As for a user adding to or replacing the defs, wouldn't it be logical to first run the VRAM size test before doing anything that might change VRAM?

You're assuming that this routine is only going to be used standalone by someone who doesn't know how much RAM is on their system or wants to test whether an upgrade worked. The routine could easily be incorporated into another program, say some sort of pop-up utility, where the end user may have no idea a RAM detection routine will be run or what effect it may have.

'Tis better to err on the side of caution

I agree.

...and reload the defs.

Apparently we have a different definition of being cautious.

EDIT: Anyway, this obviously comes down to a philosophical difference, so I'll drop it. You or others are welcome to discuss the issues, though.

[hydrophilic]

Interesting, I had read about the indirect addressing mode but didnt realise peek/poke etc used it.

I cant get my head around the logic of it though. Itd be nice to understand why. I cant see why indirect addressing is a special case.

I believe it's because the indirect addressing modes do 2 memory accesses sometimes.  This is due to page boundary crossing.  Specifically, when writing, the CPU will read the possibly wrong address (before page correction) and then do the actual write to the correct address (after page correction).  Note this always happens on a write operation even if no page-boundary is crossed.  A similar thing can occur during a read, but only if a page-boundary is crossed.

Also note the same addressing problem occurs with normal indexing modes for example LDA $D600,X or STA $D600,Y.

Edit
This double-access can (likely will) cause problems with register 31 of the VDC because the memory-pointer auto-advances whenever a read or write operation is performed on $d601.  Since a write via STA(zp),Y will perform 2 memory operations, this is bound to cause trouble!  Why it would affect other VDC registers is beyond me...
/Edit

Another problem with using BASIC PEEKs and POKEs, especially with register 31, is that you need to check $d600 to be sure the VDC is ready and then immediately send the data to $d601.  If you wait several cycles (like during the parsing of a BASIC program), the write to $d601 can occur when the VDC has become busy again.

I must agree that using the editor ROM routines to read/write the VDC are the most reliable way to use the VDC from BASIC.  Especially when accessing VDC memory via register 31.  From a practical point of view, other VDC registers can be accessed with BASIC PEEKs and POKEs most of the time.  So the question becomes, is 'most of the time' good enough for you?

[BigDumbDinosaur]

Well, you're assuming that the test write will actually hit the location we think it's going to hit on a 16K machine.

I'm not assuming. I've now tested it, and it does.  And even if it didn't, say it landed in unpredictable places on different 16K setups, it still makes a ton more sense to save and restore one or two locations than to replace an entire 8K.  There's absolutely no reason this test needs to take close to a full second to complete.  It wouldn't be unreasonable if the delay were necessary, but here it definitely isn't.

Okay, let's stop this right now.  I'm going to get into your face a bit about this topic, because you are exhibiting an aspect of Commodore computer programming behavior that has annoyed me (and some of my former collaborators) for some 25 years.  Please don't take offense, since what I'm going to say is borne out of literally decades of writing software at the machine level.

Very few amateur Commodore programmers have any of what I call "code discipline," which is the technique of writing structured programs in ways that are acceptable to professionals.  This is okay if you're writing programs for your personal use and don't intend to share them.  It's not so good if many others must also use the program.  It's totally unacceptable when the programmer makes unwarranted assumptions about undocumented hardware behavior.  The latter is exactly what you are doing.

I don't know your computer background, but I'll tell you mine.  I started out in 1970 pounding machine code into post office computers via a Tele-Type machine.  In terms of 6502 M/L, I'd be willing to wager that I have pumped at least a quarter million lines of code into various 6502 powered devices (including Commodore computers) in the last 30 years, a lot of it working directly at the hardware level.  One of my projects involved the Xetec Lt. Kernal hard drive subsystem, for which I scratch-wrote an ISAM database engine, and a set of applications to go with it.  That one project had nearly 100,000 lines of M/L, much of it working at the raw disk level.  Other parts of it included custom code to drive a non-standard 80 column display, which is where my understanding of the 8563/8568 was derived (it was also where the VRAM test was put to use).  With that much M/L under my belt, I've developed a very deep level of hardware knowledge, and I believe I'm more than qualified to rebut what you are thinking.

During my days developing hardware drivers, I quickly learned several hard truths about working at the bare metal:

1) Never assume, unless stated otherwise by the manufacturer, that a hardware register will reset to a predictable state.

2) Never assume that hardware device will behave and/or respond in any way other than stated by the manufacturer.

3) Never assume that access to a dead area of the system map will produce identical results on different, but otherwise identical machines.

You are ignoring at least one of the above truths, number 3, in this case.  You are assuming that a write access to a potentially non-existent memory location will behave the same way in every case and on every machine.  That assumption IS WRONG!  There have been numerous times where I've seen totally unpredictable results when trying to write to non-existent physical RAM.  This is the reason all computer systems conduct some sort of RAM detection/sizing test before announcing X number of KB or MB exist.  The C-64 and 128 both do this at startup (see RAMTAS in the kernal), and for very good reason: uninitialized DRAM is totally unpredictable in behavior.

There's absolutely nothing in the 8563/8568 technical specifications that even discusses how the device behaves when a memory access is attempted to a non-existent location.  Therefore, why on earth would you even start to assume that it would be safe to read out what you think might be the actual location that would be affected by the RAM sizing test, when it is clear in reading the VDC tech docs that there's NO PREDICTABILITY in such an operation?

As for a user adding to or replacing the defs, wouldn't it be logical to first run the VRAM size test before doing anything that might change VRAM?

You're assuming that this routine is only going to be used standalone by someone who doesn't know how much RAM is on their system or wants to test whether an upgrade worked. The routine could easily be incorporated into another program, say some sort of pop-up utility, where the end user may have no idea a RAM detection routine will be run or what effect it may have.

No, I'm not assuming that the routine will be used standalone, but you seem to keep forgetting that it is a test of physical hardware!  What I did assume was that the programmer who might incorporate this test into his own code knows what he's doing.  You don't assume anything about RAM until after you've verified what you're hoping to find.  Therefore, a RAM sizing test of any kind should ALWAYS be run BEFORE alterations to the RAM's contents are to occur (e.g., installing new character fonts).  It's not my problem if some amateur programmer with a half-baked understanding of computer hardware, and limited coding skills, incorrectly utilizes a utility and ends up with baby-puke for a video display.

As for whether the program is to be used in the context of a larger application, any competent 6502 programmer will know how to integrate the VRAM test into his handiwork in a way that makes sense.

Everything about which you seem to be complaining revolves around only one thing: the speed of the test.  The DLCHR sub, which copies 8K from CHARROM to VRAM, takes approximately 780K clocks to complete, resulting in about 800 millisecond SLOW mode performance.  Try testing in FAST mode and see what happens.  The test should run about 70-80 percent faster.  In either case, so what if it does take 800 MS to complete?  The test only has to be run once, you know, not every five minutes.

Anyway, this obviously comes down to a philosophical difference, so I'll drop it. You or others are welcome to discuss the issues, though.

No, this is not a case of a "philosophical difference."  It's a case of doing it right.  I get so tired of seeing Commodore programmers taking unwarranted shortcuts in their programs and then blaming everything but their code when it doesn't work right.  In the world of M/L, doing it right requires work and patience, which never seems to be in adequate supply.  I used to write this stuff to make money, and you can best believe I made sure it was right when it shipped.  If being right means the VDC RAM test takes a perceptible amount of time (Gee!  A whole 800 MS!  Why, so much time was wasted, I could've run out and had lunch!), so be it.  At least when it's run, the user can depend on it to report reliable results every time and not make a mess of the system in the process.  And, if he doesn't like the way it works, the source code is readily available.

[nikoniko]

Okay, let's stop this right now.  I'm going to get into your face a bit about this topic, because you are exhibiting an aspect of Commodore computer programming behavior that has annoyed me (and some of my former collaborators) for some 25 years.  Please don't take offense, since what I'm going to say is borne out of literally decades of writing software at the machine level.

None taken. I respect and admire your technical knowledge and experience more than realize. Whenever I see a new post by you I look forward to reading it, because I know that you will always have something interesting to say, and most of the time I learn something from you. I can't even pretend to fathom why you include the word "dumb" in your username, as it's probably the least fitting adjective I can think of for you in any of its senses.

Unfortunately for you, I *am* dumb and inexperienced about many things, so if you had any ideas of getting away from the kind of people you've found annoying for the last 25 years, you might as well give that up now.

[BigDumbDinosaur]

Okay, let's stop this right now.  I'm going to get into your face a bit about this topic, because you are exhibiting an aspect of Commodore computer programming behavior that has annoyed me (and some of my former collaborators) for some 25 years.  Please don't take offense, since what I'm going to say is borne out of literally decades of writing software at the machine level.

None taken. I respect and admire your technical knowledge and experience more than realize. Whenever I see a new post by you I look forward to reading it, because I know that you will always have something interesting to say, and most of the time I learn something from you. I can't even pretend to fathom why you include the word "dumb" in your username, as it's probably the least fitting adjective I can think of for you in any of its senses.

Unfortunately for you, I *am* dumb and inexperienced about many things, so if you had any ideas of getting away from the kind of people you've found annoying for the last 25 years, you might as well give that up now.

Assuming I survive tomorrow's blood-letting, I don't plan on going anywhere.  If someone bugs me in some way, I make sure they know it.  <Grin>

One of the reasons I come here is so I can post for posterity all the things I've learned over the years in working with computers.  I'm guessing from what I've seen that despite its age and technical obsolescence, the C-128 is still relatively popular.  It is a pretty capable machine, all things considered.  In a space of about four years, I focused a lot of attention on that one computer and thus have a pretty good recollection about how it works and so forth.  There's a lot I did on it from which others should be able to benefit.

Most of my focus was on using the 128 for business computing, hence heavy development of database work, especially with the Lt. Kernal.  Since I was not particularly interested in playing games or doing other recreational computing at the time, I know little about those aspects of software development.  My electrical engineering background has been helpful in figuring out how to drive chips like the VDC and CIA.

So I'll try to help out and if I get a bit huffy at times, just remember I'm basically just a big, broken-down old dinosaur who still remembers what it's like to get burned by a hot vacuum tube.

Speaking of vacuum tubes, how about a tube powered guitar amplifier?  http://www.veroamps.com