Support for "extended addressing real mode"?

[Johann Hanne]

Hi,

I'm currently developing an alternative firmware for an 80186 based IP
camera. As other choices are more or less non-existent I tried out the
OpenWatcom C compiler and I'm really happy with it. The only problem
is that the 80186 CPU uses "extended addressing real mode" (aka
"extended mode", aka "extended real mode", aka "Turbo186 mode",
aka ...) where the physical address equals "(addr_segment << 8) +
addr_offset", compared to the standard real mode "(addr_segment << 4)
+ addr_offset" (iow, the paragraph size is 256 instead of 16). My
initial assumption was that this mostly/only affects the linker, so I
hacked together a Python program which creates a binary image out of
the OMF files produced by wcc. It turned out that this assumption was
true and I already have a FreeRTOS/lwip/lua stack running. However, my
Python linker is rather limited (no object archive support, only
tested with large memory model, only minimal set of OMF records, ...)
and I wonder how complex it would be to add "extended addressing real
mode" support to wlink, so I have a few questions:
- Is it correct that wlink can't directly produce "flat" binary images
and I have to use wlink + exe2bin?
- Would I need to extend wlink to indicate "extended addressing real
mode" in the exe header (I've seen somebody using "MX" instead of "MZ"
as exe cookie) _and_ exe2bin to act accordingly?
- Would these kind of patches have a chance to get into the official
OpenWatcom source code base?

Regards,
Johann

[Peter C. Chapin]

On 2011-12-13 05:08, Johann Hanne wrote:

> - Would these kind of patches have a chance to get into the official
> OpenWatcom source code base?

What you are suggesting sounds great. I can't comment on your technical
questions as the linker is not my area. As far as getting the changes
into the code base goes the easiest way might be if you had write access
to the wlink portion of the repository and, essentially, to become one
of the Open Watcom contributors. We don't have any kind of official
mechanism for accepting and reviewing patches from the outside (although
it has been done in an ad-hoc manner at times).

Peter

[Wilton Helm]

Extended addressing real mode is already part of OW (has been for about six
years). I developed it for use with the Lantronix DSTNi series of CPUs that
I use extensively in embedded projects.

There are two portions to it. The biggest item, as you suggested is the
linker.
To set it for extended real, use the linker directive OP HSHIFT=8.

The second part only affects things that use HUGE pointers. The RTL has
code that converts between linear and segmented addressing for HUGE
pointers. This issue also impacts segmented protected modes as well, so the
RTL already has a variable called __SHhift that the RTL uses to determine
the amount of the shift. For real mode it is normally set to 12. For
Extended real mode it needs to be set to 8. This is done in the startup
file.

I have made a modified version of ide.cfg and a idedst.cfg that I use to
create DSTni targets through the IDE, which simplifies setting this up. I
also made a streamlined serial port debug trap for use with the DSTni CPUs.
I'm not sure if that is what you are using, or if you are using an FPGA
implementation or some other product. The extended real mode, AFAIK was
created by ARC and is distributed by them as IP.

Wilton

[Wilton Helm]

Oops. I found a typo in my last post. The variable the RTL uses is called
__HShift

[Johann Hanne]

Oh wow, thanks for this!

The SoC I'm using is this one:
http://www.sq.com.tw/english/platform/sq610dx86.htm

No useful documentation available but similar to the DSTni regarding
the basic stuff like UART, timers, DMA, watchdog. Has a UART based
debugger which I had to disassemble, but I can run my code now...