6502.org

You can have the prop wait on a pin change, so you could just wire up the select signal to the prop as well.

That's a good thought, but will you need to be careful about glitches? Address decoding is not, generally, glitch-free. Qualify with a signal like phi2 and you'd be OK in most cases, I think. (Not that phi2 is special, just that it's a convenient way to mask off activity towards the beginning of a cycle.)

Good point. If you did that in the prop, you'd probably be OK. wait on phase 2, and then check the select pin. I imagine you could do that fast enough if you used ASM for the cog in question.

Does it need a sticky, does it not show up easily with a search?

On a different topic, does the 65SPI normally run hot? It's getting really warm to the touch after not too long.

Yes. viewtopic.php?p=29701#p29701

Oh, ok. Thanks. Good to know I'm not risking blowing it up. It's the last one Daryl sold, if I remember right.

Well, the plunge has been taken. I've ordered the board through DirtyPCBs, and that SPI-10 module I mentioned earlier. I hope 2 layers will be enough for the latter, but we'll see.

I'm not sure if you have fixed this or not, but I can say from experience that if Kicad says they are not connected then you can pretty much bet they aren't.

I've gotten pretty good at Kicad recently...no expert...but not too bad. Been using it a lot.

At first I used to use global labels all over the place because they were simple. But after talking to some people (and studying other schematics) I learned that style isn't really preferred for many. So I learned how to properly do buses and I have to admit, once I did that I love my schematics so much more now. In fact, I learned how to route buses inside hierarchical sheets which is even nicer.

Let me know if you need some help with this. I can show you one design I'm working on that's my biggest design yet that uses buses and hierarchical sheets with buses.

Please! I got fed up with KiCAD's apparent stupidity, and ended up sending the individual signals out the hierarchical pins.

Below are the steps that I personally take. They may not be the fastest way to do it but it works for me.

On picture "A", I have the steps A to F.

A = Normal wire. I think you have to have a small wire connected to the pins. I've tried it without them (connecting the bus wire directly) but it didn't seem to work. So just create a small wire for each pin.

B = Green bus wire. This angled wire goes from the small wire to the eventual blue bus.

C = Main (blue) bus. These don't have to be connected everywhere. Picture C below shows how I did a few buses. I connect them when I can but I don't worry about it too much.

D = Net name (local label). These are net labels for the individual sheet. They are local only and do not carry over to child sheets (not normally, that is). Not that this label is "D0" for data line 0. Now, the trick is to name the labels in a certain way...such as:

E = Same net. Notice that I have placed the local label ON THE BLUE BUS. I have "named" the bus. BUT, notice the pattern. I have put a range. So the name for the BLUE BUS must follow the D[0..7] for data bus, A[0..15] for address bus, BLAH[0..31] for some 32 bit bus, etc. Kicad will know that the D0 is "inside" the D[0..7] label.

F = Hierarchical pin. Also, notice it has the SAME net name (the range) of the blue bus. Also notice that it MUST be INSIDE the hierarchical sheet (named "VIA.sch" in this example). That sheet is picture B. This step tunnels in the D[0..7] bus into the child sheet. As best as I can tell, you have to tunnel each bus you want in that way. For individual pins (such as ~RESET) then you must put them on a separate blue bus line. If anyone knows a better way then please let me know.


Now, move on to the child sheet (B) called "VIA.sch".

Notice that I created the same local labels (same D0 to D7) and created a blue bus connected to it. Also notice that I have named that bus the same (D[0..7]).

Next, notice the "hierarchical label" connected to the blue bus. This is your entry point from the parent sheet. It must have the same bus name D[0..7] as above. Of course, repeat for other buses. Even though I'm only using A0..A3, I still have to name the entire bus A[0..15]. Well, I don't HAVE to. I could have named the parent bus A[0..3] and then I could use that name too. But I am consistent and name the address bus the entire range, the data bus the entire range, etc. The trick is that the bus name must be a range representation of the lines going into it. So you could have a bus named "D[0..2]" that would only include 4 data lines. But like I said, I like to just name the entire bus so that I can use any line.

I hope this example helps. Let me know if I can help any more.

I think it does. I wasn't using the range notation, and that may have been my problem. I was calling them ADDR_BUS and DATA_BUS, and routing the control signals separately, but it still seems to hold.

Did you have a specific assembler in mind, or were you planning on writing your own?

I might possibly use Krusader, but I haven't looked into it too closely. Originally, I thought I could possibly roll my own and build it into the monitor. I have not yet investigated this side of it much, as I suspect various parts of my hardware are unreliable. The EEPROMs in particular are getting verify errors fairly regularly.

Eight weeks later, the boards have not yet arrived, to my knowledge. Australia Post may be the cause of the delay. There are times they are surprisingly quick, but also times when they're really slow.

In any case, I'm still working on tying more and more of Ittiara together.
None of the hardware has had all of its features exercised yet. I know I can talk to the VIA, so do not doubt that that will simply work when called upon.

I have the DUART working in a basic sort of manner. I have not attempted to use hardware handshaking, nor have I made any use of the counter/timer.

The 65SPI has yet to be successfully exercised. I've got to work with other hardware to know if it's doing anything at all, which makes it more complicated.

I have written a number of (probably naive) routines that are meant to work various aspects of the hardware. I've run a few of them, particularly the ones that exercise the more basic functions of the LCD module(Reverse mode, clear screen and draw line).
EWOZ is working(again), but VTL-02 is misbehaving(constantly sending the OK prompt).
I had botched up D3 as it went to the half of the board with the SPI and the serial chip, so I was getting very strange welcome text out of EWOZ.

I have gotten a propeller FLiP module, to use as a SID emulator(SIDcog). I've decided that I'll interface it over SPI, and I have a little 4-channel bidirectional level converter module that I'll probably use as an interface.

EDIT: It seems a bit of a waste to use the prop solely as a sound device. I will probably implement other things on it as well, like PWM and possibly I2C and GPIO.