This was my plan... I think the way Garth has the E signal going out of Q0 is REALLY CLEVER though; it makes me want to do it that way.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I am still having some trouble with this. I wired it up like Garth's example:



And I can verify that the '595 is working, by replacing the LCD with some LEDs, and the delay loops are long enough that I can actually see the bytes changing. I suspect the problem might have to do with this:

From an old thread.

With the control signals on bits 0 and 1 of the SR, they appear instantly, along with the nibble of data, when I pulse the 595. I am thinking that I will have to do something like this, in order to send, say 00111100 to the LCD:



In other words, send 6 bytes per byte of data, along withe accompanying 16 clock delays for the SR. That seems like a fair bit of extra steps / delays; before I try it that way I want to make sure I have the concept right.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I did zoom in on it some, but I think it's pretty clear. Some of your pin names were different from my datasheet, but you also gave pin numbers, so I could cross reference. That made getting everything hooked up pretty straightforward.



Hah! OK, cool.



I made a subroutine called "wait_16." Levinthal says jsr is 6 clocks and rts is six clocks, so I just filled in two nops. It seems to work OK - at least my LED s blink the right bits!

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I did get it working using the VIA shift register... kindasorta. The shift register was working properly, latching data, etc., and the LCD would initialize, but not reliably. My particular one seems to be extra fussy about the timing loops - probably because it's a cheap Chinese knockoff. I decided to go back to using the the VIA's output port (but now in 4-bit mode) so I could check the busy flag. That's where it is now. I don't consider the serial excursion to be wasted time even though I ended up abandoning that path; I gained a good basic understanding of how to use the 6522's shift register; it seems like there are plenty of interesting things to do with it so that it's almost a waste only to use it to drive the LCD!

I do have a question about how the 'pla' instruction works though. Right now I'm doing:


To check the busy flag in bit 7. I wasn't sure if the cmp instruction is necessary; it looks like pla does set the N flag, but the (exceedingly confusing) diagram in Leventhal seemed to suggest that it does it based on the value of the SP (maybe to be used for testing for stack overflows and other such errors?), not the value pulled off the stack. So, I added the cmp just to be safe.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I do! It's my day job, so to speak. "Paganini" has been my handle since my folks got our first dialup account in 1998. So many people now know me by that nickname that I respond equally readily to "Pag" or "Pags" as I do to my own actual name (which is "Nathan," although some call me... "Nate." Sadly, I am only a good violinist, and therefore only attempt the easy Paganini (like Barucaba Variations) and leave the boundary pushing ones to the great violinists All the delays work as you describe for mine, except it seems to need that first delay to be 40ms as described here rather than 15. I'd like to share my delay loops code in the next post. It's working, but I want to make sure I haven't violated any best practices, and maybe it could be improved. Can't really make it run faster (hah!) but maybe I can make it smaller...
Cool. I'll get rid of that cmp then.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

I can now poll the LCD busy signal during normal operation, but I still need to observe the mandated delays during LCD initialization. The shortest delay I need is 100uS, which I calculate to be 400 clocks, since I'm running at 4Mhz.



I figured that 1ms is ten of those, so I made a parent subroutine that is basically the same idea, except with 10 iterations instead of 75:



I make that 4075 clocks, which is 1ms + an extra 18.75 uS, which is fine since we want "at least" 1 ms delay. I did exactly the same thing for 4ms (called DELAY_1ms 4 times) and for 40ms (calledDELAY_4ms 10 times). I will refrain from including them, since they are literally the same subroutines, copy/pasted with the labels and magic numbers changed. Each one picks up a few extra microseconds beyond spec from saving / restoring the X register, and so on. Again this seems fine, since we want "at least," and everything seems to be working.

HOWEVER.

Having four special purpose nested subroutines does not seem to me like an elegant solution to this problem. The roughly 50 bytes they occupy is not that big of a ROM cost, but since I've only got 28kb, I expect that things are going to get crowded as I keep adding features.

Since I have two index register that, in combination, can count up to $FFFF, I feel intuitively that I should be able to create one general purpose delay function that simply accepts a parameter telling it what to count to. The (one single page) section about delay loops in Leventhal does something like this, but it is hard-coded for 1Mhz, and the algebra he uses produces constants for faster clocks that are larger than what can be stored in a single byte. I have not tried too hard to invent this subroutine, because I bet that at some point in the last 50 years someone has already done it, and that someone here on these forums knows where to find it.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

For precise timing I use bespoke loops, and sometimes macros to generate them. Recently I needed to align precisely based on a 6522 timer 1 interrupt, for video synchronization, so my interrupt handler read back the low byte of T1 to see how much it had ticked since reaching zero (variation in interrupt processing speed), then used conditional branches to waste some cycles if necessary depending on the low bits of the value read, followed by an eight-cycle loop executed based on the higher bits of the value read back from the timer. I can share but I don't think it's very useful for your case as you don't need to be precise.

So for "at least" delays where you don't need to be precise, busy-waiting like this is probably not the best approach; but you could just use one index register like this to make an easy-to-use configurable delay similar to what you're already doing:



You could wrap it again with a Y-based loop for longer delays, and/or have variants using different base routines that already wait different periods. But overall it's probably better to use a 6522 timer here, either directly or by setting up an "OS"-level time counter.

(crossed in the post, but here we go anyway...)

Floobydust posted a delay routine here
viewtopic.php?p=29795#p29795
which could surely be adapted. You can use two nested loops easily enough, counting in X and Y, and you can add NOPs to the innermost loop for a coarse slowdown. You can even have three loops if you bring A into play.

There's also a topic
Delay routines
which might be of interest.

As George suggests, if you have a timer, you might well use that in preference. Although I think counting is conceptually simpler.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I have a violin that a great-great uncle made; but I never got good enough at it to play in public. There were 40 of his violins in the house when he died, so my grandfather and each of his seven brothers and sisters got five. I have one of those, and will probably get my mother's when she goes. She's 87. For her, it's just decoration to hang on a wall, as her musical IQ can be expressed with a single digit, at least a hex digit.


Nice!


I've been video'ed many times, but I am not aware of any of them being available online. Doing a search for any, I find there's another Garth Wilson who's apparently a professional cellist.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Great! I don't suppose any of you might be planning to attend the upcoming VCF in Atlanta?



I have two types of 6502, at the moment. One is the modern 14Mhz WDC65C02; the other type is old, 4Mhz, made by California Micro Devices. In theory it's a clone of the Rockwell 65C02s of the same era, but I haven't been able to find a datasheet for it, and I haven't tested to see what it does if you feed it the "new" WDC instructions. The 6502 Assembly Language Programming book by Levinthal *is* limited to the NMOS instruction set, which is what I've been using as my reference. Kind of a period practice for retrocomputing.



You guys sound great! I did a little jazz back in my student days, but I was never any good at it. I find the lack of immediate structure very intimidating. Garth, I notice you're located in southern CA; you wouldn't happen to know Richard Levine by any chance? He's a cellist with the San Diego Symphony, and also a fan of the 6502. I believe he got his KIM-1 back when KIM-1s were a brand new market player.

Thanks everyone for all the material on delays. I like the idea of doing it with a timer, for not the least reason that I have no idea how those VIA timers work, and this seems like a good opportunity to learn. In the long term (once I get some basic I/O up and running on this thing) my plan for Blue April is to go through the XINU book and make a little multitasking OS. I will no doubt need those VIA timers to implement something resembling a RTC when I do that. I'll combine my subroutines into one of the snazzy seedable ones from up-thread first so I have a working backup.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad