Hi all,

I'm having some wierd things happening....

Here is what I'm doing:

E1C6 5A initcycle: PHY
E1C7 48 PHA
E1C8 A03C LDY #<00111100b ; Init 1, 8 bit, 2 lines, 5x11 font
E1CA 8CE0DD STY lcddata

Now, when I store it, I expect to see DDE0 3C on my logic analyzer in state mode, but whenever I store to that location it is always showing: DDE0 DD, and this is happening when I store to any of the locations on that VIA, DDE0, DDE1, DDE2 and DDE3 are all looking the same.

At first I thought well, maybe the analyzer is missing the data or something, but it is consistent and always to the same memory locations so I'm thinking there is something more here - the code should be sound, I already know that RAM works fine as I have saved and retrieved data from RAM - which suggests there is something going on with communicating with the VIA, somehow my data to the via is getting corrupted.

I'm taking my readings from the same place I take all of my other readings and they all appear normal. I've checked it a dozen times, I am not seeing what I might be doing to cause the problem.

Has anyone seen something like this before?

_________________
-Tony
KG4WFX

Sounds like you may have bus contention when the VIA is enabled. What data bus voltages do you see on the oscilloscope?

I'm checking my logic right now for when the via is enabled to make sure nothing else is, right now there are only 4 things wired in - 2 SRAM chips, 1 EProm and 1 Via

I'm about to have to leave for a bit, but when I get back I'll see what I can find with regard to the voltages, I don't know if I'll be able to do it at home as I'm down to one OScope probe atm so triggering for just when the via is enabled will be a tad difficult

_________________
-Tony
KG4WFX

I think I may have found the problem, not 100% sure tho, as I don't have a substitute, and the symptoms don't jive with reality.

But, it would seem my 74245 chip is too slow for the operation on a few of its buffers in the direction from the CPU out.

But the only problem with my thoughts is that the chip is reading/writing just fine to SRAM - I know this because it is having to push and pop addresses from JSR's and it is saving and getting the correct data.

I tried taking out the 6522 I'm communicating with and I am still seeing the same problem.

I watched the timing of the enables, and I did find one flaw with my enable logic, which I am going to change, but since the problem doesn't seem to me to be where the issue is, I don't know if it will fix anything.

_________________
-Tony
KG4WFX

> E1CA 8CE0DD STY lcddata
>
> Now, when I store it, I expect to see DDE0 3C on my logic analyzer in
> state mode, but whenever I store to that location it is always showing:
> DDE0 DD, and this is happening when I store to any of the locations on
> that VIA, DDE0, DDE1, DDE2 and DDE3 are all looking the same.

I should have read this more carefully the first time.

What specifically does the logic analyzer display? IOW, where along the clock or select cycle does it have you looking? Unlike the desired situation with RAM, the VIA needs the selects and R/W\ valid before phase 2 goes up, even though the data may not be valid yet until after phase 2 goes up. If the analyzer grabs the data bus data too soon, it may very well be showing you just the last operand byte that is being held there by bus capacitance. That is not telling you there is necessarily anything wrong in your circuit.

Before going to the extent of trying to drive a display with the VIA, the better first step would probably be to just connect a beeper or LED to one VIA pin and see if you can get that working. See my "Tip of the Day," #35, 36, and 37, on troubleshooting, parts I, II, and III, at http://www.6502.org/forum/viewtopic.php?t=342&start=30 . You'll find them about a third of the way down.

Next, if you haven't used one of those LCDs before, I should tell you there are certain tricks to get them to initialize correctly and reliably. I can send you some info on that if you need it.

Last, if all you have connected to the processor is two SRAMs, an EPROM, and the VIA, you definitely do not need the '245 bus buffer. Apple used them because they had potentially tons of LS loads on the bus, and the NMOS 6502's of the day probably could not output nearly as much current as the later CMOS processors could.

The logic analyzer is utilizing 2 pods - the first pod is triggering on the low to high transition of the PHI 2 clock (to get the address), the second pod, is triggered by PHI 2 in high state (to get the data).

I had gone thru getting LED's to work a long time ago (with a 6502 instead of a 65816 of course), and didn't have a problem with that - but I had two major differences - 6502 and a slower clock.

I'd be happy to see the info you have on them - there is one flag in the data sheet that makes little sense to me and I'm not sure what it does, but it is after initialization - I know the data sheet on mine (I've been using graphic LCD's for a while, this is the first character only LCD I've used in probably near a year) it's got a specific initialization cycle, namely waiting >15ms after power on to send an init byte (basically to tell it to be in 8 bit mode and a few other things), then wait >4.1ms and send the same init byte, then wait >=100uS and send the same init byte, then after that send turn on bytes, clear screen bytes, etc. with checks of the busy flag.


I put the 245 in for two reasons - one was due to the fact that it was recommended in the 65816 manual with the circuit to access the upper 8 bits of the address bus, the other was because this thing is going to end up with probably about a dozen ram chips, and 12 more vias, plus a few ports incase I want to build an expansion.

I was originally going to do this with a 6502 but I wanted the "easier" expandibility beyond 64K address range and also wanted the 16 bit capability of the 65816 - plus I've been aching to use one for a long time now .

_________________
-Tony
KG4WFX

Well,

I've been doing more experimenting today and checking as many signals as I could.

In answer to earlier questions - the data bus, highs are >4V - it does seem a bit noisy, and there are spikes on lows for some reason, but highs seem to be valid highs.

I have reduced my program to just a few statements:

E000 18 BIOS: CLC ; clear carry
E001 FB XCE ; Set "normal" mode
E002 20BAE1 JSR set8bit ; Set us to 8 bit mode

;* We will only try storing to LCD area
E005 A9FF LDA #<$FF
E007 8DE2DD STA lcdddra
E00A 8DE3DD STA lcdddrb
E00D A901 LDA #<$01
E00F 8DE0DD STA lcddata
E012 8DE1DD STA lcdcont
E015 4C15E0 loopa: JMP loopa

Ok, so at this moment, here is what I'm seeing:

E pin is being changed from a high to a low reflecting emulation/normal status

Program continues to step through, I'm looking at the low to high of the clock.

At the transition of low to high, at the STA's for the ddrb's, the via is enabled, and it appears that there is an FF

When I store to the PA and PB registers, at the point of the up clock transition, it appears that capacitance in the circuit is holding the data at DD (Probably left over from the STA instruction) - I'm not sure if a 01 or a DD is actually clocked into the via - it all depends on when the via actually takes the data and when / if that DD ever changes to an 01.

Checking the pins on the via's PA and PB with a logic probe, they are all 0's - so it didn't get set to DD or to 01.

I did find one problem which I fixed (had to do with the clock circuit).

I wonder if the 6522 isn't fully reset by the time the cpu sends it signals?

Also seeing how long it takes to go from a low to a high on the address bus makes me almost want to put a schmitt buffer of some kind in there for the chip select logic, I do notice (or have noticed in the past) that it is possible for 2 things to be enabled at once like RAM and something else due to a float period during the rise time that seems to affect my cs logic - which could be very bad if the enables are long enough with r/w signals that could corrupt data.

Unfortunately, I know I made 1 big mistake in this project, which I will have to just work through - I made too many changes from my norm for a single project - ie: I switched from bread boarding to wire wrap (first time wirewrapping, but my connections seem solid), I switched from '138 CS logic handling to an FPGA for more flexibility, I switched from using a 6502 (which although I am not a master of I am a bit more familiar with) to a 65816. I will work it all out, not sure how just yet, but I will

_________________
-Tony
KG4WFX

Interestingly, it looks like you could leave the accumulator in 16-bit mode since you're writing to both DDRA and DDRB together, then PA and PB together.

As for the macro definitition, it's quite simple:



You can punch this into your C32 code verbatim and it will work. It will take only 2 bytes and 3 clocks instead of your 6 bytes and 15 clocks. Macros are like a subroutine for the assembler to execute instead of the target computer. The resulting code is the same as if you had just put the SEP instruction line in there instead of a JSR. It's more efficient and easier to read.

> Program continues to step through, I'm looking at the low to high of the clock.

The data is not guaranteed to be valid yet. It is guaranteed to be valid by a certain setup time before phase 2 falls, so that would be the better time to latch it into the logic analyzer.

> it all depends on when the via actually takes the data

The set-up time is in the timing diagrams. As long as that set-up time is met, the data will be latched into the VIA on the falling phase-2 clock edge.

> I wonder if the 6522 isn't fully reset by the time the cpu sends it signals?

Just run the same reset signal to both the processor and the VIA. The reset just puts the VIA's registers to a known state, which you can also do by writing to them. They won't fail to take a write just because you didn't have a good reset signal to the VIA.

> that it is possible for 2 things to be enabled at once like RAM and
> something else due to a float period during the rise time that seems to
> affect my cs logic - which could be very bad if the enables are long
> enough with r/w signals that could corrupt data.

RAM must never be selected before phase 2 goes up. Phase 2 must be brought into the RAM selects. Otherwise, depending on variations in chip production, temperature, and other factors, you could have the situation where the RAM sees R/W\ go low before the address has been valid and stable long enough, meaning you'll be writing to unintended addresses. Even people who think they're getting away with it may find themselves getting bit by it if they change an IC, operate the computer at higher or lower temperatures than they have in the past, etc.. It's too precarious.

> I put the 245 in for two reasons - one was due to the fact that it was
> recommended in the 65816 manual with the circuit to access the upper
> 8 bits of the address bus

Mine shows only a '573 to latch the upper 8 bits. Does yours show something more?

> the other was because this thing is going to end up with probably about
> a dozen ram chips

If you can dip down to 3V, you can now get 2Mx8 in a single SRAM, and fast too-- 8 or 10ns. Otherwise the biggest SRAMs I know of are 512Kx8.

> and 12 more vias, plus a few ports incase I want to build an expansion

I'd certainly be interested in what kind of project would need 12 VIAs! I thought 5 was a lot. Remember that with a single VIA's serial port you can connect hundreds of bits of input or output. There are also now more and more ICs interfaced through I2C and SPI, which improve the chances you'll live long enough to wire it all up. The serial interfaces are good for things that don't need quite as much speed as you can get through the parallel ports.

I'll check on the falling edge and see what's different.




Ok, I wasn't sure if that were a possibility, I had read somewhere about wanting to make sure the 6522 was reset before the uP so the uP wasn't sending signals before the 6522 was ready.



Ok, this is easy to fix, but as a question - when one uses a '138 to select ram, it is possible for the address to select the ram before the r/w is settled, isn't it?



actually, yes. I had gotten mine from WDC just after I had gotten my shipment of '816's, and on the page that shows the suggested latch circuit, it also shows a 245 bi-directional buffer on the data circuit.



hehe, well, that'll have to wait until I see if I can make it work

Another question tho - the VPA and VDA pins, will they go up when the address is stable, or will they end up going up before the address lines are stabalized? According to the way I read the data sheet, they will go up when the address is valid...

_________________
-Tony
KG4WFX

> Ok, I wasn't sure if that were a possibility, I had read somewhere
> about wanting to make sure the 6522 was reset before the uP so the uP
> wasn't sending signals before the 6522 was ready.

You won't be writing to the VIA anyway until you've executed at least a short reset routine.

> Ok, this is easy to fix, but as a question - when one uses a '138 to
> select ram, it is possible for the address to select the ram before the
> r/w is settled, isn't it?

According to the timng diagrams, address will not be formed before R/W\, but rather at the same time. That's the dangerous part. If you want to gate the R/W\ with phase 2 instead of gating the CS, that would be fine too.

> Another question tho - the VPA and VDA pins, will they go up when the
> address is stable, or will they end up going up before the address lines
> are stabalized? According to the way I read the data sheet, they will go
> up when the address is valid...

The address is not guaranteed to be valid before VPA and VDA say they are. Their function is to tell what's happening in that cycle, not to give the go-ahead that the address is now valid timingwise. They can be used to control cacheing (sp?).

I did find the problem finally - it ended up being the clock circuit - in all of the revisions due to switching around clocks and speeds and such, it seems that the buffer for the oscillator never got put back in the circuit (the chip was there, but it was no longer wired in, no idea how that happened - probably from one night to the next day type of thing) and the oscillator was direct driving the 6522 and the 65816, and it seems that the two were too much load and the clock could not keep the output at proper levels to drive everything correctly - it would also seem the CPU is more tolerant then the 6522. When I replaced the buffer in the circuit (like it shows on my hand-drawn schematics ), it all worked fine.

I did also swap out my logic handler chip with one I programmed to shift all RAM operations to phi2 high phase like you had mentioned.

I am using the VDA and VPA signals though - although not for timing, I am using them to guarantee that during the period of address lines shifting, various IC's won't get enabled together causing possible severe problems.

According to the datasheet I have...



the way I interpret this is that I can use the these signals to know that the address is now valid - nothing more - which was my only concern in that my logic chip operates fast enough that at the clock speed of the cpu, it is possible for it to enable multiple chips in sequence and long enough to cause data corruptions or other problems - eventually I may build in nots, but it will require some serious AND gates, utilizing the VDA and VPA seems to have solved that problem, and only required the changing of a few gates.

ps - and yes, the line I quoted above

> The Valid Data Address (VDA) and Valid Program Address (VDA)

is an actual typo in the datasheet I have =)

I tested everything today, and it worked well - now I just have to re-integrate the LCD and see what happens.

_________________
-Tony
KG4WFX

The timing diagram however has the same timing (even same envelope) for VPA and VDA as for A0-A15, meaning the address will not be valid before VPA or VDA is, or if it is, it'll be by luck only. It's all the same tADS time. This re-confirmed to me what it said elsewhere about telling what that cycle was going to be for, in order to do cacheing.

Well, it's nothing worth arguing about - we are interpretting the same data in slightly different ways, no big deal - as long as it works

_________________
-Tony
KG4WFX

Finally - a conclusion to the saga....

Well, I finally tracked down all of my main errors, now I'm down to tweaking for this particular LCD before I move on to add code for the main lcd.

My problems were as follows:

Logic error in logic glu IC

Clock not properly buffered

Timing error in the code

Last but not least - I had accidentally swapped the PA and PB registers and was sending all of the data to the control lines and all of the controls to the data lines.

the logic glu IC was an easy fix - a few extra lines into it and added support for dealing with PHI clock for the ram, and all was good.

Clock not properly buffered took a while to catch since I had gone thru several variations of circuits due to my original selection of clocks, (see earlier post)

Timing error in the code - during part of the initialization I wasn't waiting quite long enough, and during the screen clearing operation, I wasn't waiting long enough causing instructions to get lost in the process.

Swapped the PA and PB registers in the source code - I felt like a real moron on this one, I must have had dislyxia (or however you spell it) the night I was typing that portion of the code in and once I had gotten all of the other problems worked out, I couldn't figure why it wasn't working - hooking the logic analyzer up to the PA and PB ports on the 6522 revealed the data being funnled to the wrong places. A few quick changes (and a swift kick to my butt for such a stupid mistake) and it worked beautifully.

Ahh.... now that I have the raw code for this section done, I can start weeding it before I move onto the next section...

_________________
-Tony
KG4WFX