Loading binaries created by asm6809.pl

[tjewell]

Hi all, hope you can help again ... I'm so close ...

I've got perl, VI, asm6809.pl and Xroar all installed on my PC, plus a stack of 'learning machine code for the Dragon' books. I used to be quite good at this 25 years ago, and I fancy giving it a try again! (blimey, I'm rusty). So I'm at the stage now where I've created an assembly file that compiles to a binary just fine. But I don't know what to do with it! Can I 'cloadm' it? Or should I produce a DragonDos binary file? I never had a disk drive back in the day, so I'm not sure how to load that either. Any tips or pointers?

Thanks all!

[snarkhunter]

Hello,

Not sure I can help here, never having tackled any such issue. But still...

You just cannot CLOADM anything else than a m/c executable file from a ".CAS" virtual file, which I doubt your assembler will provide.
So what kind of output file did you get from compiling your source code? Was it a DragonDOS ".bin" executable file?
If so, then perhaps you can try Ctrl-L from XRoar: this will bring up a file requester, from which you will be able to select your binary to be loaded directly into the emulated Dragon's RAM. At which actual memory address, I have no idea whatsoever. I'm not even sure this may ever work. But I guess that would be my first try...

Until someone with a better knowledge than mine (... not too difficult!) pops up and provides a much better reply (... very easy!).
And sorry if the content of this post should prove complete rubbish: big heart, little brains!...


Kind regards,
Lionel

[tjewell]

Thanks for the ideas!

I'm getting so close - I've got the assembler to make DragonDos binaries, and I think that if I add an 'org <address>' at the start of the code, this info will be written into the header. I suspect this tells Xroar where to load the code. I also note there's an '--exec' flag in the assembler too that lets me quite specific about which address gets executed first.

So in theory, I can just start Xroar, 'clear' some space for the code, do a 'ctrl-shift-l' and load the binary file. Of course, at that moment the computer locks, but you can't have it all!

Now, what have I done wrong?

[snarkhunter]

The "ORG" compiling directive may not be enough to get a proper result. You also need to use "PUT" most of the time.

"ORG addr" will generate the executable code as if starting from memory location addr. This is mandatory in case the code is position dependant.

And "PUT addr" will actually compile it at addr memory location.

You're right about the "exec" bit: this tells the starting point for the executable. I do assume that the default value is the generated code's first byte.

When does XRoar freeze? When loading the executable, or when EXECing it afterwards?

Best regards,
Lionel

[sixxie]

It may just be the version of XRoar - the last released one doesn't directly recognise the DragonDOS binary format. The last snapshots in http://www.6809.org.uk/tmp/xroar/ should do, or alternatively, specify --coco instead of --dragondos to the assembler: XRoar has been able to load CoCo ".bin" files from a very early age

Must... make... release... Won't be this weekend, but perhaps if I promise it here and now, I'll do it next week!

Edit: oh, and cool! Glad you're (hopefully eventually) finding that little Perl assembler useful. It's a bit slow, but I think it does a reasonable job.

Further edit: PUT isn't supported yet, sorry! Code will go to its ORG.

[tjewell]

Thanks for your help Snark and Sixxie! I'm now staring at a screen with an exclamation mark in the middle, which means my 'hello world' code now works! Fantastic. I switched to using the Coco binaries, and it worked perfectly.

Certainly, the perl assembler is working just fine for me so far - although I don't think my four line program would particularly tax it. I'm a perl hacker myself, so that means if I'm not quite sure how to do something with it, I can just have a peer at the source code and work it out.

So I've now got a USB stick with my Dragon 'programming environment' on it - portable copies of perl and Vi for Windows, plus Xroar and the assembler. I did try to work within Alldream (my development platform of choice back in '84), but I'm sorry, I just can't cope with 32x16 uppercase only. I've obviously been spoilt! It's much much quicker to program this way - maybe I'll actually get some of my old game ideas written. Only 25 years too late!

Thanks again for you help.

Tony.

[tjewell]

Perhaps I spoke too soon. I've been going slightly mad the last 36 hours - what seemed like an entirely random selection of my programs would just crash the Dragon. Code I was 99.99% sure was just fine. Simple little 4 line programs.

So I've been running debuggers, disassemblers and hexdumpers trying to work out what the hell was up. Eventually I tracked the problem back to Perl, and ultimately DOS. Simple, actually. Every time asm6809 output a binary file, Perl would helpfully add a '0D' before every '0A' in my output code - a carriage return before my linefeed. So a simple "lda #$0A" had an 'OD' inserted into it, resulting in gibberish code and random crashes.

Blimey, that was hard work.

So the fix is simple - Sixxie, I've added a "binmode $output_file;" at line 557 in the assembler script. I guess better minds than mine could work out how to do a 'if DOS then' kinda wrapper round it.

Now everything works perfectly! Rah!

[sixxie]

So the fix is simple - Sixxie, I've added a "binmode $output_file;" at line 557 in the assembler script. I guess better minds than mine could work out how to do a 'if DOS then' kinda wrapper round it.

Erk! Cheers! Of course that's the right fix... And something I should really remember to do generally!

Although it seems a little strange: I'd expect that sort of behaviour if I were writing a "\n", ie actually indicating "newline", but not for packed hex bytes. Live and learn!

[prime]

So the fix is simple - Sixxie, I've added a "binmode $output_file;" at line 557 in the assembler script. I guess better minds than mine could work out how to do a 'if DOS then' kinda wrapper round it.

Erk! Cheers! Of course that's the right fix... And something I should really remember to do generally!

Although it seems a little strange: I'd expect that sort of behaviour if I were writing a "\n", ie actually indicating "newline", but not for packed hex bytes. Live and learn!

I think the problem is that the OS is doing the translation not perl, so whenever you write a $0A it will add the $0D, I guess opening the file in non-binmode in perl just opens a cooked ascii file in dos, opening in binmode, forces dos to not do any translation.

Does that make sense ???

Phill.

[robcfg]

From my knowledge, you can open files in two modes, ASCII or Binary. The Ascii mode translates the characters and the binary one don't.

So, it seems quite logical that you had problems by opening the files in non-binary mode, that is ascii mode.