On 7/9/06, Jared Putnam <[EMAIL PROTECTED]> wrote:
I'm confused about the mnemonics of the assembly. A typical statement
looks like
NOOP [-v,-h,-d] #640
Am I correct in concluding that -v and -h refer to the vblank and
hblank assertions? In the program Timothy posted, every instruction
has the -d modifier. Does this mean that some programs will never need
to assert the data line, or is this an oversight? Also, how is cursor
control reflected in the mnemonics?
Actually, the syntax was just something I made up on the spot and is
perhaps something we should change.
What I meant to express was that -v means that the vertical sync is
low, while +v means the signal is high. Sometimes, a given VESA mode
wants active low (high always except during the pulse), and sometimes
a mode wants active high (low always except during pulse).
If +d is completely missing from the example program, then that's a
mistake on my part. +d tells the DVI transmitter (and ultimately the
monitor) that the video data is valid and should be displayed. -d
means indicates blanking. +data_enable is equivalent to -blank.
Our video circuitry doesn't care about the polarities of v and h.
They're just whatever we program into the code. So, if you want to
change from active high to active low, you actually have to reload the
whole program. :)
In fact, however, it would require virtually no extra logic to include
a polarity xor gate for each of these flags in a config register (for
an FPGA anyhow). Is there a way that having this configuration would
not be redundant? If we had some other logic that looked at the
syncs, then we may have to program THAT logic with appropriate
polarity info.
Finally, is it really a good idea for the mnemonics to reflect hardware
details? I'm referring to the part in brackets here. All a programmer
cares about is whether the signals are asserted; he shouldn't have to
care whether they are active low or active high. I'm proposing
something like
NOOP [v,h] #640
where only the asserted signals are listed between the brackets instead
of stating whether the lines are high or low. Timothy's program
already does this for returns.
Honestly, the reason I didn't do it the way you suggest is because I
wanted to make sure people understood what I was describing. I'd much
rather just include the flags (in arbitrary order) when the bits are
set.
As a suggestion, how about we name the flags this way:
h - hsync is high
v - vsync is high
d - data enable is high
x - reset cursor x
y - reset cursor y
r - return from subroutine
i - assert video interrupt
z - [yet-unassigned bit 24]
[If x is present without y, cursor y advances by 1 line.]
My next suggestion is to remove the commas, just stringing them
together in any order.
And then perhaps we can remove the brackets. If any flags are set,
they're separated from the mnemonic by a dot. So NOOP with +v and +h
looks like this:
NOOP.vh
Is that good, or would that confuse people, since it's the same syntax
that some assemblers use for operand size? Do we care, since almost
no one will ever see the assembly code or even use it indirectly (ie.
compiler goes directly to binary)?
I think we can retain # to indicate a count and an unadorned number is
an address (program or memory). Or perhaps we can put an address in
parentheses with the count being a prefix. So, for instance, if we
wanted to call address 200 a count of 40 times, it would look like
this:
CALL.rvh 40(200)
Or would that confuse people, making them think it's an offset?
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
