deleted
see this sample who create a palette of 256 colors.
http://masm32.com/board/index.php?topic=813.msg7226#msg7226 (http://masm32.com/board/index.php?topic=813.msg7226#msg7226)
and forget all you know on the 16 bits.
you have a lot of ground to cover before you even think about re-writing the app for 32-bit
software INT's - a thing of the past
segmented memory model - same
manipulating the vga registers directly - not likely
start out by learning some 32-bit basics, then move into graphics
if you install the masm32 package, have a look at the examples and help folders
deleted
Quote from: nidud on October 24, 2012, 03:39:48 AM
So the question is (still), is there anybody who know anything about the function used in this API?
Which function used in which API?
Also, when you post sources, do not assume that we have these includes, or that we know what mouseon etc do.
include clib.inc
include conio.inc
include mouse.inc
.code
main proc c
invoke mouseon
or byte ptr console,CON_COLOR
.if !func(editpal)
invoke resetpal
.else
and console,not CON_REVGA
.endif
invoke mouseoff
sub ax?,ax?
ret
main endp
end
The typical template used here looks like this:
include \masm32\include\masm32rt.inc
.code
start: nop
exit
end startAnything more idiosyncratic is likely to get ignored by forum members (because it means wasting time to rewrite the whole thing).
Oh, and before I forget: Welcome to the Forum :icon14:
Quote
So the question is (still), is there anybody who know anything about the function used in this API?
Well, yes. :bgrin:
There is no equivalent in the Win32 API to set the VGA attribute controller registers or DACs in text mode ( console ). You are more or less stuck to the 16 default colors.
deleted
i am not sure that is strictly true
some functions, like RealizePalette, may alter the vga palette registers, indirectly
i haven't played with it much - it seems it would make more of a difference if i were using a 256-color mode
because newer systems have far improved graphics capabilities, we don't have as much need to do it
keep in mind, that if you were using a 256-color mode, and you changed the palette,
it would affect all visible windows, including the desktop
Quote
So the question is (still), is there anybody who know anything about the function used in this API?
The ddk is a good source for this.It's the perfect level where they can be used.
There is a graphic vga card sample.
firmware can also give some code.
The API are here to do not know all the material details and normalize there use.
deleted
;==============================================================================
include \masm32\include\masm32rt.inc
;==============================================================================
.data
hwndCon dd 0
hdcCon dd 0
.code
;==============================================================================
start:
;==============================================================================
invoke GetConsoleWindow
mov hwndCon, eax
printf("hwndCon %X\n",eax)
invoke GetDC, hwndCon
mov hdcCon, eax
printf("hdcCon %X\n",eax)
invoke GetDeviceCaps, hdcCon, SIZEPALETTE
printf("SIZEPALETTE %d\n\n",eax)
invoke GetDeviceCaps, hdcCon, RASTERCAPS
mov ebx, eax
; RC_BANDING Requires banding support.
.IF ebx & RC_BANDING
printf("RC_BANDING\n")
.ENDIF
; RC_BITBLT Capable of transferring bitmaps.
.IF ebx & RC_BITBLT
printf("RC_BITBLT\n")
.ENDIF
; RC_BITMAP64 Capable of supporting bitmaps larger than 64 KB.
.IF ebx & RC_BITMAP64
printf("RC_BITMAP64\n")
.ENDIF
; RC_DI_BITMAP Capable of supporting the SetDIBits and GetDIBits functions.
.IF ebx & RC_DI_BITMAP
printf("RC_DI_BITMAP\n")
.ENDIF
; RC_DIBTODEV Capable of supporting the SetDIBitsToDevice function.
.IF ebx & RC_DIBTODEV
printf("RC_DIBTODEV\n")
.ENDIF
; RC_FLOODFILL Capable of performing flood fills.
.IF ebx & RC_FLOODFILL
printf("RC_FLOODFILL\n")
.ENDIF
; RC_PALETTE Specifies a palette-based device.
.IF ebx & RC_PALETTE
printf("RC_PALETTE\n")
.ENDIF
; RC_SCALING Capable of scaling.
.IF ebx & RC_SCALING
printf("RC_SCALING\n")
.ENDIF
; RC_STRETCHBLT Capable of performing the StretchBlt function.
.IF ebx & RC_STRETCHBLT
printf("RC_STRETCHBLT\n")
.ENDIF
; RC_STRETCHDIB Capable of performing the StretchDIBits function
.IF ebx & RC_STRETCHDIB
printf("RC_STRETCHDIB\n\n")
.ENDIF
inkey
exit
;==============================================================================
end start
I'm not sure what to make of the GetDeviceCaps-RASTERCAPS return value. The console is not a palette-based device, but apparently supports bitmaps.
hwndCon 102D4
hdcCon E2010545
SIZEPALETTE 0
RC_BITBLT
RC_BITMAP64
RC_DI_BITMAP
RC_DIBTODEV
RC_FLOODFILL
RC_STRETCHBLT
RC_STRETCHDIB
deleted
i am not aware of a "kernel32-only" rule :shock:
that is a very crippling rule, as many win32 functions lie outside kernel32
deleted
Quote from: nidud on October 24, 2012, 04:41:25 AM
Don't waste your time on this jj, it's complicated: stick to the Basic, its easy and comfy :P
Well, under the hood it's often not comfy at all :greensml:
By the way, I liked your discussion of the expansion problem (http://sourceforge.net/projects/jwasm/forums/forum/927109/topic/5793871), and would support the warning option, especially since the workaround is very straightforward:
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
Init
Let esi="This is a stupid test"
.if Instr_(esi, "stuupid")
PrintLine "stuupid found"
.elseif Instr_(esi, "test")
PrintLine "test found"
.endif
Inkey "Found something??", CrLf$
.if Instr_(esi, "stuupid")
PrintLine "stuupid found"
.else
.if Instr_(esi, "test")
PrintLine "test found"
.endif
.endif
Inkey "better??"
Exit
end start
deleted
You are right that Masm's behaviour is "wrong", but where to draw the line? JWasm's strong points are full Masm32 compatibility plus more speed and macros for Win64. Adding features is risky with regard to the userbase.
OTOH, checking if a multiline macro is called after an .elseif seems not too difficult. A warning would really be helpful. Who needs it can use -WX aka "Treat all warnings as errors" ;-)
> I tried to follow the download link, but the page seems to be missing or blocked.
Not blocked for me, I just clicked the link in your message.
deleted
> You have to do it without breaking this compatibility: labelling it as a bug
You know that some software depends on bugs functioning properly :icon_mrgreen:
I thought you meant the SourceFourge link...
MB is online at http://masm32.com/board/index.php?topic=94.0 and active: MasmBasic014Oct12.zip (362.15 kB - downloaded 23 times.)
So who could block a Masm page? AV? Provider? But then, you obviously can post here. I hope the crappy AV brigade has not blocked MasmBasic specifically... :(
deleted
Quote from: nidud on October 25, 2012, 03:13:09 AM
I compiled the sample, it produced a 3 447 641 byte .lst file
Which sample?
I just noticed that the "Simple window" template produces 380k of listing when putting .listall under the include line; however, when assembly option /Fl is specified, it jumps indeed to over 3MB. My testbed arrives at over 10MB of listing with /Fl set. Not exactly MasmBasic's fault, however: A simple MsgBox with masm32rt.inc only also produces 8MB with .listall before the include line...
deleted
if you use /Fl, you may also want to use .XCREF in the source - it makes a big difference :biggrin:
of course, it also helps to use .NOLIST and .LIST around the includes
Quote from: jj2007 on October 25, 2012, 12:21:22 AM
OTOH, checking if a multiline macro is called after an .elseif seems not too difficult.
That's indeed very good news! Since it is obviously a child's play, could you please tell me how to do it? With detailed source code, if you don't mind!
Quote from: japheth on October 25, 2012, 07:56:06 PM
Quote from: jj2007 on October 25, 2012, 12:21:22 AM
OTOH, checking if a multiline macro is called after an .elseif seems not too difficult.
That's indeed very good news! Since it is obviously a child's play, could you please tell me how to do it? With detailed source code, if you don't mind!
It's not child's play, of course, but IMHO a pretty basic exercise (sorry, can't help you with C code....):
include \masm32\MasmBasic\MasmBasic.inc ; download (http://masm32.com/board/index.php?topic=94.0)
.data
MacTable dd m1, m2, 0 ; see CreateMacTable
m1 dd 100 ; line count of macro
db "Instr_", 0
m2 dd 1
db "Instr1", 0
SetGlobals posL, mac$
Init
SetGlobals
Recall "TestElseIfDummyCode.asm", L$()
; call CreateMacTable ; JWasm certainly has something like this, right?
For_ ct=0 To eax-1
mov edi, L$(ct)
.if Instr_(edi, ".elseif", 1)
add edx, 7
mov posL, edx
.if Instr_(edx, edi, "(")
sub edx, posL
Let mac$=Trim$(Mid$(edi, posL, edx))
mov esi, offset MacTable
.While 1
lodsd
.Break .if !eax
mov ecx, [eax]
add eax, DWORD
.if !StringsDiffer(eax, mac$)
.if ecx>1
PrintLine "WARNING: ", mac$, " should not be used after .elseif!!"
.else
PrintLine "Congrats, using ", mac$, " is OK"
.endif
.endif
.Endw
.endif
.endif
Next
Inkey "ok"
Exit
end start
TestElseIf.asm:
include \masm32\MasmBasic\MasmBasic.inc ; download
Instr1 MACRO spos, src, match ; a one-liner
EXITM <ecx==12345678h>
ENDM
Init
mov ecx, 12345678h
Let esi="This is a stupid test"
.if Instr_(esi, "stuupid")
PrintLine "stuupid found"
.elseif Instr_(esi, "test") ; useless, will expand before the jump label
PrintLine "test found"
.elseif Instr1(esi, "test") ; will expand at the jump label
PrintLine "Instr1 found it: ", Hex$(ecx)
.endif
Inkey CrLf$, "Found something??", CrLf$
Exit
end start
deleted
deleted
deleted
NULL is defined in windows.inc.
deleted
Quote from: jj2007 on October 25, 2012, 09:22:20 PM
It's not child's play, of course, but IMHO a pretty basic exercise (sorry, can't help you with C code....):
Even a macro that consists of just EXITM may not work, since the argument behind EXITM may be another macro. So you'll probably have to add recursion in your source sample ( which I cannot read, because I'm suffering from a severe BaSiCphobia , sorry! ).
Quote from: japheth on October 26, 2012, 07:04:04 PM
... your source sample ( which I cannot read,
Strange, very strange: JWasm has no problems to read my sources :icon_mrgreen:
deleted
Hi nidud,
AFAICS the problem is mainly relevant for two cases: elseif macro() and or'ed macros like this:
; Let esi="This is a stupid test"
.Break .if Instr_(esi, "stuupid") ; works correctly
; both macros get expanded at the label, but only the second one gets tested
.Break .if Instr_(esi, "stuupid") || Instr_(esi, "stupid")
There is, of course, a simple workaround for the latter case: two .Break .if lines.
Again, a warning for the noobs would be luxury, but Japheth seems not so eager to dig into it, so I'll pull out and leave him in peace :icon14:
deleted
Quote from: nidud on October 27, 2012, 04:12:12 AM
The next trick is to halt expansion of these two:
.elseif macro
.while macro
Right, I forgot the
.While macro() case in my post above.
deleted
deleted
Quote from: nidud on October 27, 2012, 08:12:52 AM
I forgot..
The new declaration for ParseLine:
ret_code ParseLine ( char *line, struct asm_tok tokenarray[] )
Inserted below label function:
/* expand the line */
if ( CurrIfState == BLOCK_ACTIVE ) {
/* expand (text) macros. If expansion occured, rescan the line */
while ( Token_Count > 0 && ExpandLine( line, tokenarray ) == STRING_EXPANDED ) {
DebugMsg1(("GetPreprocessedLine: expanded line is >%s<\n", line));
Token_Count = Tokenize( line, 0, TRUE );
}
}
/* handle directives and (anonymous) data items */
I just copyed this in there, so this needs some help.
Brrr, what an ugly mess - just for such a VEEEEERRRRY minor issue!? If you mix preprocessor and parser functionality like in your proposal, you'll end in a totally unreadable and unmaintainable pile of sh...
btw, you don't want to query CurrIfState once the conditional assembly directives (IF, ELSE,...) have been handled in the preprocessor.
deleted
Quote from: nidud on October 27, 2012, 08:27:29 PM
Good (or at least better)?
I don't dare to judge.
The only approach that has a faint chance to be implemented is to
delay macro expansion by some kind of syntax extension. You can see this approach in effect in struct initialization, when a macro call is located within the initialization literal. Quite the same approach may be added to the hll directives, that is, the macro call has to be enclosed in <>:
.if <whatever()>
with this approach, you just have to add a few lines in hll.c ( determine if there's a literal following the directive and if so, expand the rest of the line ), the rest of the code remains as it is.
deleted
Quote from: nidud on October 28, 2012, 06:26:02 AM...but a regression test will probably tell a different story.
Unfortunately yes. My little testbed (attached) with the
.While Instr_(esi, ... stuff reports plenty of errors, while the latest JWasm build (25-Oct-2012 04:03) works just fine.
Strangely enough, your modified version assembles my fat testbed without any problems. So it must really be the specific "warning" code.
In the meantime, I have instructed my editor (RichMasm, part of the MasmBasic package (http://masm32.com/board/index.php?topic=94.0)) to issue a warning for
.While mac()and
.elseif mac()- imho the most relevant cases. That was really hard work for a noob who understands only BASIC, but it seems to fit the purpose, and the performance loss is acceptable: overall build time with JWasm is 0.2% slower for the RichMasm source with its 14,000 lines :biggrin:
deleted
deleted
deleted
deleted
Hi nidud,
The warning works fine but somewhere a regression has crept in - see Jwasm expands macros inside quoted text (https://sourceforge.net/tracker/?func=detail&aid=3142937&group_id=255677&atid=1126895)...
Sorry that I can't help you with that - C is just not my cup of tea...
jj
deleted
deleted
Quote from: nidud on October 24, 2012, 12:59:39 AM
Hi all
One of the first programs I wrote was a 16-bit resource editor, and most of the programs I have made after that has been based on using this tool. It is very simplistic and hard to handle in some cases, but it still works.
The programs I made are still used (mostly by old farts), but the main problem with them is the lack of DOS support in newer hardware, especially printers. I also have a small baby project online, which I have been nursing for some time, but now MS is blocking the use of such applications even in XP.
Most of these programs are written in C/C++, so the plan was to convert the resource compiler to 32-bit instead of rewriting all this code. My knowledge of assembly is from 16-bit TASM, so I'm a bit rusty with regards to 32-bit MASM.
The learning curve will be to grind through the console functions first, using kernel32.lib and a few functions from user32.lib (clipboard functions).
The first problem I run into was the color setup, and here is some of the code used for manipulating colors used in 16-bit code:
include clib.inc
include conio.inc
include mouse.inc
.code
setpal proc _CType public uses bx? palid:size_t, clid:size_t
test console,CON_COLOR
jz setpal_end
ifndef __f__
mov ax,palid
mov dx,clid
mov ch,al
mov bx,dx
mov ax,0040h
mov es,ax
mov dx,es:[0063h]
cmp dx,03D4h
jne setpal_end
cli
mov dx,03DAh
in al,dx
mov dx,03C0h
mov al,bl
out dx,al
mov al,ch
out dx,al
mov dx,03DAh
in al,dx
mov dx,03C0h
mov al,20h
out dx,al
sti
else
; missing 32-bit code
endif
setpal_end:
ret
setpal endp
resetpal proc _CType public
push si?
xor si?,si?
.repeat
invoke setpal,si?,si?
inc si?
.until si? == 8
mov si?,56
.repeat
mov ax?,si?
add ax?,-48
invoke setpal,si?,ax?
inc si?
.until si? == 64
invoke setpal,0014h,0006h
pop si?
ret
resetpal endp
getxya proc _CType public x:size_t, y:size_t
ifndef __f__
invoke getxyw,x,y
mov al,ah
mov ah,0
else
local lpCharacter:dword, lpNumberOfAttributesRead:dword
mov eax,y
shl eax,16
add eax,x
mov ecx,eax
invoke ReadConsoleOutputAttribute,
OFSH_OUTPUT,addr lpCharacter,1,ecx,addr lpNumberOfAttributesRead
mov eax,lpCharacter
and eax,00FFh
endif
ret
getxya endp
scputa proc _CType public uses ax? dx? x:size_t, y:size_t, l:size_t, a:size_t
ifndef __f__
mov al,byte ptr x
mov ah,byte ptr y
call __getxypm
invoke wcputa,dx::ax,l,a
ShowMouseCursor
else
local pcx:dword
push ecx
movzx ecx,byte ptr a
movzx eax,byte ptr x
movzx edx,byte ptr y
shl edx,16
mov dx,ax
invoke FillConsoleOutputAttribute,OFSH_OUTPUT,ecx,l,edx,addr pcx
pop ecx
endif
ret
scputa endp
end
The code assign value [0..255] to index [0..15]
So, to my first question: is there a simple way to rearrange the 256 palettes like this in 32-bit, or do I have to apply a table of some sort for that?
The library used for this code could be downloaded from this site: https://sourceforge.net/projects/doszip/files/
hello ,
any chance of the source code for this attachment ?
Like to see the 16bit
Actually I am just looking for an example source for text mode
That 16bit is before my time ,
I did find the interrupts , what a mess LOL
http://www.ziplib.com/emu8086/interrupts.html