Playing around with AsmOne on Winuae..
 

I have a classic wb install using rtg on winuae and im playing around with the example source on asmone.


I can get the example code to assemble just fine, but I dont see anything at all on the screen. Ive tried multiple examples from multiple source - same result.

The code is actually running as it waits for a mouse click as expected.

I press escape
then a <return>
this does a successful 2 pass assembly
then j <return>
to jump to first line of code

Do I need to kick out rtg or something for this to work?

cheers

One example of the code im trying to run:

The code doesn't work from non-native (i.e. RTG) screens that's why you don't see anything. To fix that you have to add a LoadView(0) and 2 WaitTOF() calls (2nd WaitTOF calls is to make the code run correctly from interlaced screens) before killing the system (i.e. before the move.w #$7fff,$dff09a line). I'll attach my ministartup so you can check how it's done or even use it for your own projects. :)

Brilliant, thanks StingRay I will try it out after work tonight.

I eventually got the code to run by changing AsmOne to a PAL Hires mode (Non RTG) but this is a fudge and will I definitely follow your advice for a more robust and versatile startup.

mmm having a little trouble with MiniStartup.s

Is the second line from bottom valid..
(.getit movec vbr,d0)

vbr doesnt seem to be defined and whats a movec?

thanks

VBR is the V.ector B.ase R.egister and movec is a 68010+ instruction to move from/to control register.

Basically you need to use a newer Asm1 version which supports 680x0 opcodes or "cheat" and use the following hex line:

dc.l $4e7a0801 ; movec VBR,d0

Thanks, does that mean that the code will only work on 68020+ processors due to this single instruction?

Nope! Check the code and read the comments and you'll find the answer! :)

hehe checking ;)

I see, the code is only executed when its *NOT* a vanilla 68k ;)

Exactly. :) This piece of code is needed for interrupts to work properly on 68010+ machines as these can have a relocated vector base, simply changing $6c.w to install a custom VBI for example won't work anymore if VBR is set to any other location than $0, $6c+VBR offset must be used in that case. And this is exactly what happens in these lines of code (a0: VBR):
:)

The shutdown and startup code is excellent, works 100% on all configurations so far, I wish I could say the same for AsmOne, I found it really flakey and awkward to edit with.. After having winuae crash on me when I was trying out devpac with cygnus ed, I decided i was going to develop on the pc natively using the winuaedemotoolchain method (VASM), This is by far the best for me, crash proof and a decent editor! I need to research debugging with this setup...


Thanks again for the code and guidance StingRay.

Asm-One unfortunately has a lot of problems indeed, you can try Asm-Pro (which is a reverse engineered and enhanced version of Asm-One) but it has a fair share of problems too. The RTG support is much better than Asm-One's though.

I've been using Asm-Pro 1.16d for years and probably won't ever change as I know all its bugs and how to circumvent them. :)

In case of questions regarding Asm-One/Pro feel free to ask, for VASM you may ask phx who is also a member on this board here, he sure can help you with debugging (I only used vasm for doing Atari stuff and debugged using Asm-Pro on the Amiga side so can't help you there).

Concerning debugging with vasm:
There not many debuggers which work stable and comfortable with all M68k CPUs. I am using bdebug, the Barfly debugger, when debugging on real Amiga hardware. When testing under UAE then the internal debugger is quite useful, so you don't need any extra tools.
BTW, tomorrows vasm snapshot (which will become 1.7c some day) can automatically generate line debug hunks for the assembled source, so you can also debug on the original source with debuggers which support that.

That sounds fantastic phx, i will be sure to check it out. I need to invest more time in learning about debugging 68k in general, I tend to iterate loops and logic in my head from the source code to debug, not looking at the generated code much.

To be honest, I have only been using Vasm for 1 day, but it has been really easy to use and porting code over from AsmOne and DevPac has been painless (without using compatibility settings). I will spend more time reading the great looking manual and exploring features this weekend.