Serial I/O communications (terminal) code

[Siekmanski]

I know that masm reverses the bits in BITRECORD, call it a quirk. 

[jimg]

Yes, after much more testing, I believe you now.

The big problem is that BITRECORD is defined backward I think.

There is no way to use it in the normal manner and get the correct results-

This-
yy1 BITRECORD <NULL,FALSE,RTS_CONTROL_HANDSHAKE,FALSE,FALSE,FALSE,FALSE,FALSE,FALSE,DTR_CONTROL_HANDSHAKE,TRUE,TRUE,NULL,TRUE>
is not accepted by masm in the data section, even though that's the order it has to be in storage.

doing-
mov     DCB_New.fbits,BITRECORD<0,FALSE,RTS_CONTROL_HANDSHAKE,FALSE,FALSE,         FALSE,FALSE,FALSE,FALSE,DTR_CONTROL_HANDSHAKE,TRUE,TRUE,NULL,TRUE>

is incorrectly accepted by masm but gives the right results. 
It should have been rejected which means .... what?
the wasm decendents will never accept that when they are fixed, so BITRECORD needs to be fixed, but that would break a lot of programs I'm guessing.

In any case, thank you for your patience, I think I have this figured out and will try not to bug you for a while.

[jimg]

I'm not the only one to notice this!
http://www.asmcommunity.net/forums/topic/?id=21057

Odd it never went anywhere.  I'll bet anyone who uses bitrecord only does so with the mov.  That's the only way it could work, by taking advantage of a bug in masm.

And now I'm done.  Really.

[anunitu]

It was common in the "Early" programming days to use "special" code tricks with undocumented chip level code.

here:
https://en.wikipedia.org/wiki/Illegal_opcode

An illegal opcode, also called an undocumented instruction, is an instruction to a CPU that is not mentioned in any official documentation released by the CPU's designer or manufacturer, which nevertheless has an effect. Illegal opcodes were common on older CPUs designed during the 1970s, such as the MOS Technology 6502, Intel 8086, and the Zilog Z80. They exist as a side effect of the wiring of transistors in the CPU, and usually combine functions of the CPU that were not intended to be combined.

While most illegal instructions have useless or even highly undesirable effects (such as crashing the computer), a few might by accident do something that can be useful in certain situations. Such instructions were sometimes exploited in computer games of the 1970s and 1980s to speed up certain time-critical sections. Another common use of them was in the ongoing battle between copy protection implementations and cracking. Here, they were a form of security through obscurity, and their secrecy usually did not last very long.

[jj2007]

Jim,

Check this old thread.

If that doesn't solve the problem, we can write a macro that works correctly and in the same way in ML and the Watcom family.

@Anunitu: corrected, thanks!

@Jim: What is the expected value for the BITRECORD example? I am working on a macro but am confused about the order...

[anunitu]

Thread link not working JJ

[jimg]

@Jim: What is the expected value for the BITRECORD example? I am working on a macro but am confused about the order...

just reversed.
I would rather just have a correct definition for BITRECORD.  No one could be using it in a data statement, because the results would be wrong and not work.  The only way it could be being used at all is in the mov command, and that only works because of a masm bug.  It would work with the old or corrected definition just the same, it just places them in the order specified in the mov, so why not correct it.
Choice number two would be to just make a new correct definition with a new name (I'm currently using xBITRECORD which is kinda lame).
I can understand the lure of a macro, but that would take a lot more code, and current code would have to be changed anyway to use it.
Of course, there is always the chance that I am totally misunderstanding what's going on, but I don't think so.

[jimg]

So I just looked through that old link, and the only way fbits is set is with the mov op.

The obvious way to set it would be something like;

.data
yy BITRECORD  < TRUE, NULL, TRUE, TRUE, DTR_CONTROL_HANDSHAKE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, RTS_CONTROL_HANDSHAKE, FALSE, NULL >
.code
mov eax,yy
mov DCBNew.fbits,eax

but that doesn't work with the current definition of BITRECORD, the fields come out reversed.

[Siekmanski]

So I just looked through that old link, and the only way fbits is set is with the mov op.

The obvious way to set it would be something like;

.data
yy BITRECORD  < TRUE, NULL, TRUE, TRUE, DTR_CONTROL_HANDSHAKE, FALSE, FALSE, FALSE, FALSE, FALSE, FALSE, RTS_CONTROL_HANDSHAKE, FALSE, NULL >
.code
mov eax,yy
mov DCBNew.fbits,eax

but that doesn't work with the current definition of BITRECORD, the fields come out reversed.

Thus, the solution is to reverse the order.

BITRECORD<NULL,FALSE,RTS_CONTROL_HANDSHAKE,FALSE,FALSE,FALSE,FALSE,FALSE,FALSE,DTR_CONTROL_HANDSHAKE,TRUE,TRUE,NULL,TRUE>

And you're going to use it to communicate with modules that only use RX and TX which need to be "No FlowControl"

BITRECORD<NULL,FALSE,RTS_CONTROL_DISABLE,FALSE,FALSE,FALSE,FALSE,FALSE,FALSE,DTR_CONTROL_DISABLE,FALSE,FALSE,NULL,TRUE>

[Siekmanski]

BTW, ever considered to use a FTDI chip to do serial I/O communications? They have a robust api, faster and more reliable than the microsoft stuff we are dealing with now. It has an option to have direct communications with other peripherals.
Also an option is to use bitbanging.  8)

I've stopped using the windows method in 2008 and made the step only using FTDI.  :t

[jj2007]

I can understand the lure of a macro, but that would take a lot more code, and current code would have to be changed anyway to use it.

Attached BitRecord.mac, judge yourself if that is a lot more code. Here are examples of usage:

Code Select Expand

include \masm32\include\masm32rt.inc
include BitRecord.mac

.code
start:
  crlf equ <13, 10>
  mov eax, 0BAADF00Dh
  print hex$(eax), crlf
  print hex$(@Record(11:4, 10:4, 10:4, 13:4, 15:4, 0:4, 0:4, 13:4)), crlf ; BAADF00D as 4-bit fields
  print hex$(@Record(11:4, 1, 0, 1, 0, 10:4, 13:4, 15:4, 0:4, 0:4, 13:4)), crlf ; BAADF00D, first A as 1-bit fields
  print hex$(_Record(11:4, 10:4, 10:4, 13:4, 15:4, 0:4, 0:4, 13:4)), crlf ; D00FDAAB
  print hex$(_Record(0,FALSE,RTS_CONTROL_HANDSHAKE:2,FALSE,FALSE, FALSE,FALSE,FALSE,FALSE,DTR_CONTROL_HANDSHAKE:2,TRUE,TRUE,NULL,TRUE)), crlf
  print hex$(@Record(0,FALSE,RTS_CONTROL_HANDSHAKE:2,FALSE,FALSE, FALSE,FALSE,FALSE,FALSE,DTR_CONTROL_HANDSHAKE:2,TRUE,TRUE,NULL,TRUE))
  exit
end start

There are two macros, @Record and _Record. One of them is "reversed". If the arg has e.g. 15:4, it means 4 bits wide; if there is no ":" then it's a one bit field.

Output:

Code Select Expand

BAADF00D
BAADF00D
BAADF00D
D00FDAAB
0000B808
0000202D

So, which one is correct, 0000B808 or 0000202D? What is the hex$(eax) that corresponds to your expectations?

[jimg]

Thus, the solution is to reverse the order.

BITRECORD<NULL,FALSE,RTS_CONTROL_HANDSHAKE,FALSE,FALSE,FALSE,FALSE,FALSE,FALSE,DTR_CONTROL_HANDSHAKE,TRUE,TRUE,NULL,TRUE>

Yes, I agree, you are correct, that works.
However, I'm going to be a little picky with semantics and say I don't consider that a solution but rather a hack to account for BITRECORD being defined incorrectly.

Regarding FTDI, it's certainly something I might consider for a standalone hardware product, but here I'm just trying to work with what people are most likely to have.

[jimg]

JJ-
So far I have only operated on what seemed logical from the descriptions I could find, and what masm actually does.  Yes, we need to do real world testing.  I'll try to actually try out the values of fbits on a comport to see what's correct.  I'll respond in your other thread about this.