Recent posts

#1

The Workshop / Re: A useful tool: BMP data vi...

Last post by NoCforMe - Today at 12:04:31 PM

Attached is what is probably going to be the last version of this utility.

So @sinsi: I created a humongous BMP to test this, 10,000 X 10,000.
It works. And it doesn't work.
It works in that my code manages to slog through each and every pixel of that file.
But when it comes time to actually display the data (when it's dumping the text to the RichEdit control), it just sits there. Doesn't hang; the UI is responsive. But it just never fills the control. I've let it sit for 10 minutes and no go.

So I'm basically giving up on that. Here's the thing: who the hell is going to actually use this to display data from a file that big?
Yes, as you point out, huge image files do exist. For one thing, I highly doubt that any of those files will be in BMP format nowadays; more likely JPEG, or perhaps PNG, maybe even TIFF.

Besides, I have to ask: what, really, is the use of this program? I ended up using it to create that huge BMP: I took a 100x100 image and used it as a "stamp" to fill up the big file, 10,000 times. Other than that even I haven't really used it. I wrote it kind of as a challenge more than anything.

The text file generated by this BMP is about 720 megabytes (!!). You can't even load a file that big into Notepad. I was able to load it into my EdAsm editor which uses a RichEdit contol (although it reported the size as something over 600 MB), but even it struggled to display it: it would show only so much, then if you scrolled down it would show a little bit more, etc., etc. So entirely impractical to even view this data. (I tested this by writing the text data to a file instead of to the RichEdit control.)

Anyhow, it was fun while it lasted. Now on to the next obsession ...

#2

The Campus / Re: Debugging causeway applica...

Last post by _japheth - Today at 10:02:59 AM

As for the source code, I just tried to assemble the following examples, shipped with the distribution of CW (unmodified). They are in the BIN directory and of course available on Github.

Ok, I restricted myself to the Causeway binaries shipped with Open Watcom v1.9. Not sure if the binaries in github are fully compatible with Open Watcom's debugger WD.

Your example code behaves no different. Linked with WL32, single step causes an immediate system reset. Linked with WLINK, it hangs the computer.

WD itself is a DOS-extended application. This binary uses the Rational DOS-extender DOS4G/W - IMO not the most stable extender. However, on my system WD starts fine and I can single-step thru the sample.

#3

The Campus / Re: Debugging causeway applica...

Last post by 16bitPM - Today at 08:12:57 AM

There's a DOS sub-forum. It's labeled "16-bit", which isn't quite correct for Causeway, but it's the correct place for such topics.

Also, please provide source code - that's a matter of course, IMO. Otherwise, usually only wild guesses are possible...

Assemble with ML, link with "wlink system causeway f sample.obj".


-

Thank you,

I'll post in the right forum next time.
As for the source code, I just tried to assemble the following examples, shipped with the distribution of CW (unmodified). They are in the BIN directory and of course available on Github.

• MULTNEAR.ASM
• MULTFLAT.ASM
• SCREEN32.ASM

Your example code behaves no different. Linked with WL32, single step causes an immediate system reset. Linked with WLINK, it hangs the computer.
The code runs normally without debugger.

#4

The Campus / Re: Debugging causeway applica...

Last post by _japheth - Today at 01:55:44 AM

Does anyone have experience with the Causeway DOS extender?

yes....

I'm trying to debug some examples in the source distribution. All of them crash the computer the moment I try to single-step the first instruction.

I tried using no drivers except HIMEM.SYS, with EMM386, and with the RDOSUMB driver.

For example:

ML screen32.asm
WL32 screen32.obj
WD /tr=cw screen32.exe


WD starts and shows the code correctly. I press F8 and *crash*.

There's a DOS sub-forum. It's labeled "16-bit", which isn't quite correct for Causeway, but it's the correct place for such topics.

Also, please provide source code - that's a matter of course, IMO. Otherwise, usually only wild guesses are possible...

Causeway is probably the best DOS32G/W compatible extender. Nevertheless, for assembly programs, you are perhaps better off reading the documentation for this extender ( provided with OW ).

Masm-compatible sample:

Code Select Expand

.386
.model flat
.stack 4096

.data

text1 db "Hello, CW",13,10,'$'

.code

_start:
push ss
pop ds
mov edx, offset text1
mov ah,9
int 21h
mov ah, 4Ch
int 21h

    end _start

Assemble with ML, link with "wlink system causeway f sample.obj".


 -

#5

The Campus / Debugging causeway application...

Last post by 16bitPM - December 03, 2024, 11:32:46 PM

Does anyone have experience with the Causeway DOS extender?
I'm trying to debug some examples in the source distribution. All of them crash the computer the moment I try to single-step the first instruction.

I tried using no drivers except HIMEM.SYS, with EMM386, and with the RDOSUMB driver.

For example:

ML screen32.asm
WL32 screen32.obj
WD /tr=cw screen32.exe


WD starts and shows the code correctly. I press F8 and *crash*.

Sometimes CTRL-ALT-DEL works, sometimes not 

Computer is an AMD 80386DX-40 with 20MiB of RAM.

#6

The Campus / Re: Operand must be relocatabl...

Last post by 16bitPM - December 03, 2024, 10:58:33 PM

It's 16-bit code, because your code also was 16-bit, but it's actually also relevant for 32-bit ( most likely also for 64-bit ).

Well, well, well!!
Shall I make a bug fix request on Github?

#7

The Workshop / Re: Challenge: Hexify #s

Last post by jj2007 - December 03, 2024, 09:03:11 PM

what if the hex chars use lowercase "a-f" instead

a>A

#8

The Workshop / Re: Challenge: Hexify #s

Last post by NoCforMe - December 03, 2024, 08:38:29 PM

Also, JJ, something I noticed while coding my comma-delimiting code:
The buffer I got from my RichEdit control (using EM_GETTEXTEX) only had carriage returns (0Dh) with no line feeds (0Ah). Is this the way all (ASCII) text in a RichEdit control is encoded? I'm so used to seeing CR-LF that my code broke because I was assuming that's what I would see for line endings.

You need to use GT_USECRLF as the flags member of the GETTEXTEX structure

Actually, it's nice only having one line terminator instead of two.
CR-LF seems to be an ancient holdover from the days of teletype terminals and such, when CR actually returned the carriage and LF fed a new line, just like a typewriter. How quaint.

#9

The Workshop / Re: Challenge: Hexify #s

Last post by sinsi - December 03, 2024, 07:57:23 PM

Also, JJ, something I noticed while coding my comma-delimiting code:
The buffer I got from my RichEdit control (using EM_GETTEXTEX) only had carriage returns (0Dh) with no line feeds (0Ah). Is this the way all (ASCII) text in a RichEdit control is encoded? I'm so used to seeing CR-LF that my code broke because I was assuming that's what I would see for line endings.

You need to use GT_USECRLF as the flags member of the GETTEXTEX structure

#10

The Workshop / Re: Challenge: Hexify #s

Last post by zedd151 - December 03, 2024, 07:56:56 PM

Also, JJ, something I noticed while coding my comma-delimiting code:
The buffer I got from my RichEdit control (using EM_GETTEXTEX) only had carriage returns (0Dh) with no line feeds (0Ah). Is this the way all (ASCII) text in a RichEdit control is encoded? I'm so used to seeing CR-LF that my code broke because I was assuming that's what I would see for line endings.

Yes rich edit likes to save bytes.    No 'trailing' line feed.
When I started working with rich edit code years ago, that threw me off too.

@sinsi, I never knew about that one.  Nice.     (post below this one)