Latest Win32 VASM Build?

[jotd]

Hey BTW VASM is GREAT!! Just what I was looking for. I tried GCC/MinGW toolchains but the syntax they require is beyond me, and that one can create binary/no header modules.
Volker Barthelmann you rule! (and thanks to the guy who built it for windows, it's always a pain to build those intricate programs, even with gcc)

[Leffmann]

Originally Posted by jotd

Thanks leffman, but I really don't get the @py -2 "%~dp0\geotool" %* command line.
py is not a valid command, -2 is not a valid python option.
the rest I understand...

That's the Python selector for when you have multiple versions installed, you can just change it to whatever Python 2 is called on your system.

You also have to checkout commit 5304, in the next commit after that the directory structure was changed completely.

[jotd]

thx Leffman, did not know that.
About VASM, I just had to change a few things (1/2h work) from phxass working source and it assembled all right so that's really cool.
VLINK worked just fine and the executable (CD32load, which is not so small) works great.

That VASM just rules!!! big thumbs up Volker & Frank.

[phx]

Originally Posted by jotd

That VASM just rules!!! big thumbs up Volker & Frank.

You're welcome.

vasm and vlink are under constant development. So when you notice something which should be improved or which is wrong, just tell me.

[jotd]

Oh, yes. I stumbled upon an annoying bug/limitation:

instructions with "space" chars won't compile:

move #0,d0 => OK
move #0, d0 => error

In macros (at least), if last char is a space it triggers an error, difficult to understand


MY_MACRO xxxx<space> => error when evaluating.

nothing blocking, my exe runs fine as I said. Big thanks for this huge program. The future of the amiga lies in cross development.

[matthey]

Originally Posted by jotd

Oh, yes. I stumbled upon an annoying bug/limitation:

instructions with "space" chars won't compile:

move #0,d0 => OK
move #0, d0 => error

In macros (at least), if last char is a space it triggers an error, difficult to understand

Try using vasm -spaces switch.

The manual for vasm is here:

http://sun.hasenbraten.de/vasm/release/vasm.pdf

[phx]

Originally Posted by jotd

MY_MACRO xxxx<space> => error when evaluating.

Hm. Couldn't reproduce that. Can you attach a real example please?

[clenched]

This post is to shed some light on why my earlier request was made. The modified binary output module uses Windows' WriteProcessMemory function to shunt output for the a.out file directly into the address space of the emulator being used.

In this case, VASM assembles the Z80 program and output is sent directly to VICE C128 emulator. The only thing to do on VICE end is press RETURN key to start. No saving and loading to and from disks or tape is involved.

Graphics, sound, code can be changed without the emulator breaking stride. The effects are immediate the instant new data are accessed. Same goes for WinUAE too. For this to work it is essential to know the proper ORG to send bytes.

        org     0400h+7*40              ; poke command to 40 col screen
        byte    "B"&$bf,"A"&$bf,"N"&$bf,"K"&$bf,"0:"
        byte    "S"&$bf,"Y"&$bf,"S"&$bf,"65488"
        org     0e00h                   ; a famous logo goes here
        incbin  "\cbmspr"               
        org     03000h                  ; program to be run
        di
        ld      a,0e00h>>6
        ld      (07f8h),a
        ld      a,84
        ld      (bc),0d000h
        out     (c),a
        inc     c
        out     (c),a
        ld      a,1
        ld      (bc),0d025h
        out     (c),a
        inc     c
        ld      a,2
        out     (c),a
        inc     c
        ld      a,6
        out     (c),a
        ld      a,1
        ld      (bc),0d01ch
        out     (c),a
        ld      (bc),0d015h
        out     (c),a
        halt
        org     0ffd2h                  ; PATCH 1
        byte    0beh                    ; modify bank
        org     0ffeeh                  ; PATCH 2
        jp      03000h                  ; go here when Z80 wakes up
        end

[Leffmann]

That's pretty neat. With WinUAE I use a directory-based drive and a small "listener program" to automatically start a program after building on the host, but I think this could be very quick and useful if you want to emulate booting from cartridges or swapping ROM images.

I'm guessing you're using WM_COPYDATA or something to communicate to vasm where in VICE's address space the C128's RAM sits?

[clenched]

Originally Posted by Leffmann

I'm guessing you're using WM_COPYDATA or something to communicate to vasm where in VICE's address space the C128's RAM sits?

No. I load whatever emulator in SoftIce or ollydbg and run it. Open the emulator's own debugger and write some obscure bytes as close to address 0 as possible. Use Windows debugger to find that series and put a hardware breakpoint there.

Restart emulator and pick out a few bytes of machine code associated with the address where it stopped. These will be the target of ReadProcessMemory search through the exe. One more read of address where memory allocation was stored will do it.

Actually this method is mainly for VICE & WinUAE since they are updated. On old emulators that aren't updated anymore, I just provide a static address after manually finding it. Just add a stack of arguments in addition to standard -cbm-prg to select emulator. ( -2600 -apple etc.)

[jotd]

BTW "IFMI" directive is unknown to VASM.
I think it's equivalent to IFLT right?

[phx]

IFMI seems to be a rare directive. Neither A68k, Devpac, AsmOne nor PhxAss support it. I only found it in BAsm.
Ok. Implemented it, together with IFPL.

You're right, of course: IFMI==IFLT and IFPL==IFGE. And as a third alternative you can write:

        if      expression<0

BTW, any chance for a real example of your MY_MACRO problem?

[jotd]

Thanks for this, I'll tell Bert to change the IFMI directive in whdload include file.

About the reproducer, cannot seem to find a simple example to reproduce but I successfully assembled that:

PARSEHEXARG:MACRO
	move.l	(A0)+,D0
	beq.b	.sk\@
	move.l	D0,A83     ; note the A83 register
	;tst.b	D0
	;beq.b	.sk\@
	SETVAR_B	D0,\1_keycode  ; the variable does not exist
.sk\@
	ENDM
	
SETVAR_B:MACRO
	move.b	\1,RelVar_\2(A4)
	ENDM

RelVar_button1 = 0
RelVar_button2 = 0


t:
	PARSEHEXARG	button1
	PARSEHEXARG	button2 
	rts

[clenched]

phx - Since the macros appear OK, here's something to look at. This was stumbled across by accident while trying to adapt the 6800 for use with TRS-80 Color Computer emulator. (not a good match but close enough to play)

With this CPU the output module won't accept any options. To verify this I wrote S-records with -s19 -s28 -s37 -exec and each one was identical. The exec field stays at zero.

	org	$1234
start	byte	"VASM"
	end

c:\vasm>vasm6502_oldstyle -quiet -Fsrec -s19 -exec -o con: \vasm.asm
S00A000073656731323334EC
S10712345641534D7B
S9031234B6

c:\vasm>vasm6502_oldstyle -quiet -Fsrec -s28 -exec -o con: \vasm.asm
S00A000073656731323334EC
S2080012345641534D7A
S804001234B5

c:\vasm>vasm6502_oldstyle -quiet -Fsrec -s37 -exec -o con: \vasm.asm
S00A000073656731323334EC
S309000012345641534D79
S70500001234B4

c:\vasm>vasm6800_oldstyle -quiet -Fsrec -s19 -exec -o con: \vasm.asm
S00A000073656731323334EC
S309000012345641534D79
S70500000000FA

c:\vasm>vasm6800_oldstyle -quiet -Fsrec -s28 -exec -o con: \vasm.asm
S00A000073656731323334EC
S309000012345641534D79
S70500000000FA

c:\vasm>vasm6800_oldstyle -quiet -Fsrec -s37 -exec -o con: \vasm.asm
S00A000073656731323334EC
S309000012345641534D79
S70500000000FA

[phx]

Originally Posted by jotd

About the reproducer, cannot seem to find a simple example to reproduce but I successfully assembled that:

Thanks. I see a problem with your example when using the -spaces option. In this case SETVAR_B generated

        move.b  D0,RelVar_button2 _keycode  (A4)

Seems I forgot to trim the blanks behind a macro argument. Without -spaces this is no problem as a blank already terminates the operand field.

Fixed.

Originally Posted by clenched

With this CPU the output module won't accept any options. To verify this I wrote S-records with -s19 -s28 -s37 -exec and each one was identical.

Right. There was a bug in the 6800 cpu module, which made vasm ignore the command line options in all other modules.

Fixed.

[Lazycow]

@clenched: what I always wanted to know: What's faster on the C128? 6502 code or Z80 code? Ever made a benchmark?

[jotd]

@phx yes that was the problem!

And what about register A83?

[clenched]

Originally Posted by Lazycow

@clenched: what I always wanted to know: What's faster on the C128? 6502 code or Z80 code? Ever made a benchmark?

It was sometime in the 90s the last time I experimented with the Z80 on a real C128. Nothing remarkable comes to mind either way about speed. I have three C128s packed away if anyone a knows a good test.

[phx]

Originally Posted by jotd

And what about register A83?

You mean the externally defined symbol A83?
A83 is not a register, so it is handled as an undefined symbol, which is automatically declared as externally defined by vasm, unless you specify the -x option.

[jotd]

oh I understand. I should specify -x for my code then! thanks.