I just tested it with the updated PLD, and it still doesn't spew 'X's into the terminal, but this time, it clicks once on channel B(after the initial power-up click). This is encouraging, as it seems that something is now working that wasn't before. I tested the /RD and /WR outputs on a breadboard, to satisfy my curiosity, and it is correct, now.

I do have some goals for this build, and I am slowly working towards them. I wrote them down and stowed them with the rest of the documents on that design.

I have to chide you a bit. The electrical signal should not be a consideration. Negating the logic statement instead of declaring the RD and RW pins as low true will usually consume more PTs and in some cases, may cause unexpected logic inversions.

Correct syntax holds that if a pin is low-true, it should be declared as low-true and the logic statements that affect it should not be negated as a substitute. Internal logic should always be positive in nature. It's usually the most efficient way.

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

I don't remember it well enough - but perhaps BDD do:
When it starts with PALs - I remember a fat green/white covered book from AMD - there were only PAL types with fixed assigned outputs. There were types like 12L6 or 18L4 or so having low active outputs. There also exists types 12H6 etc. having high active outputs. I think it was a requirement in that days, using an assignment like "PIN 6 = !RD" if one has a L-type PAL, and for H-types you need to say "PIN 9 = VMA" or the like.

Trying to use a L-type but having an active high output was nearly impossible - only using one extra input and output to implement an inverter could do it.

I think from these days it comes, that it is common practice to declare the active state during pin assignment and then using positive logic for the desired functions.

I vaguely recall that, but was not into programmable logic in those days. I'm getting too old to recall a lot of this stuff anymore.

The general rule is low-true outputs are to be declared as such. That way, PTs are not used up to invert the logic to what is wanted. I've fooled around with both methods and in all cases, the consumption of PTs was less when I only used positive logic and declared low-true outputs as low-true. In some cases, logic the way he wants to do it would compile and simulate, but would not fit the target device.

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

That's probably true. I imagine that the PLD has both inverting and non-inverting outputs coming out of the gate array, and it connects one or the other to the output pin depending on whether the pin is declared as active-low or active-high.

Does marking inputs as active-low work? I seem to recall that it doesn't. However, it would make sense to be able to, because then you wouldn't be mixing signal-thinking with logic-thinking.

Declaring an input as low-true will work. For example, the connection to the reset line in a 6502 machine could be PIN 1 = !RWB. However, other logic in the design would have to account for the inverted meaning of pin 1. My practice is to not invert inputs, as oftentimes, logic will take care of it. So I would write RESET = !RWB to make RESET go true when RWB goes (low-) true.

In the CUPL reference guide, the following is said about pin polarity declarations:

The concept of polarity can often be a confusing one. In any PLD design, the designer is primarily concerned with whether a signal is true or false. The designer should not have to care whether this means that the signal is high or low. For a variety of reasons, a board design may require a signal to be considered true when it is logic level 0 (low) and false when it is logic 1 (high). This signal is considered active-low since it is activated when it is low. This might also be called low-true. If a signal is changed from active-high to active low then the polarity has been changed.

For this reason, CUPL allows you to declare signal polarity in the pin definition and then you do not have to be concerned with it again. When writing equations in CUPL syntax, the designer should not be concerned with the polarity of the signal. The pin declarations declare a translation that will handle the signal polarity.

Emphasis added.

In general, pins that are low-true should be declared low true and all logic statements should be written solely with positive logic. There is nothing to be gained by going against the grain, so to speak, and creating a less efficient design.

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

Thanks. I was asking because I thought I remembered someone saying it was bad practice(or outright impossible) to invert inputs in that manner. I must have been wrong.
I can think in terms of logic, it's just far easier if I don't have to convert between that and signals, potentially causing errors.

Actually, it isn't easier. In designing your PLD you should think in terms of true/false. If a statement is true, do this. If it is false, do that. Declare the low-true pins as such, and then stop thinking about voltages.

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

I think I may have failed to get my point across... If I can do all the conversions(from voltage to logic and vice-versa) in the one place, and do all the logic in one place, as you've pointed out is the intended way of doing it, it's easier to think about, not having to keep track of what needs to be converted to logic.

Anyway, I did convert the PLD file to that method. I haven't burned it yet, but it does compile. I'll also try the Echo program, and see what that does.

The echo program works. I wired up one of my DIL LED units, and 8 lights go on when I power up the computer. When I ground one of the input pins on the DUART, one of the lights goes out, and when I let it float, it lights up again. The DUART is indeed being accessed.

I saw mention somewhere on the forums recently, of someone(I think Dan Moos) dumping a byte received on a serial port out on a VIA port. I'll try that idea on channel A, then on channel B.

Did you have a look at the stuff I posted a while back on how I configure the 28L92 in POC V1's firmware?

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

I'm working on that right now, converting it to SB-Assembler syntax. I'll want to modify it, at least for this purpose. I'm tempted to convert to LDA/STA initialisation, but that seems kinda pointless. I actually came up with a thing I called a 'vectored data table', that turns out to be nearly exactly what you did there.

Incidentally, if that's an equivalent to a .lst file generated by SBasm, it looks like the X1 clock rate gets truncated to 16 bits. I punched 3686400 into my calculator program and converted it to hex, and it's $384000, a 24-bit number. The listing shows it as $4000.

Correct handling of quantities exceeding $FFFF occurs in Kowalski's assembler. Although the listing only displays the least significant word of any value greater than $FFFF all quantities are internally represented with 32 bits. The bit shift operator >> can be used to extract the most significant word, e.g. MSW = $00384000 >> 16, which will set MSW to $0038. I make extensive use of this capability in my mkfs program.

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

Ah. I suspected that was the case. I did think you probably wouldn't have released it unless it worked.

So I tested the serial mirroring program, and its getting past all the initialisation code, but I have yet to get it to echo the Serial input to the VIA.
I know it's finishing the initialisation because I put in code to write specific values to the VIA port after each step(VIA and DUART). I put an INC VIA.ORA into the DUART init loop, but it's too fast to see.

It should poll SRA, and wait for the RxRDY bit to become 1 (signifying that there is a character waiting, as I understand it). At that point, it copies the top character of the Rx FIFO to VIA port A. I thought I had the code in place to do that, but something's clearly wrong, because it's not working. At this point, I've stopped because it's getting late.

I've put the code up if anyone wants to take a sqiz, and it's in a zip, as it's spread across multiple files. I hope it's readable.