Hello to all!
I am dealing with MC68000 processor.
Can't figure out how to send the contents of the address register to the output port.
I wanted to see what is in register a0 and did this:

An LED indicator is connected to the address $3C000.
I assumed that the number $7F would go to the address $3C000, and the number $AA would go to the address $3C001.
But the indicator at $3C000 showed $FF.
The assembler does not generate errors, the description of the 'move' instruction does not prohibit such an operation either.
If to use d0 instead of a0, everything works as I expected.
Where am I wrong?

Resolved, the problem was in the hardware.
My apologies, I was in a hurry to ask questions.

Glad you found a solution. Always good to see the good old 68k being used!

I couldn't see a good reason for what you reported, so it's good, in a way, that it was a hardware problem - otherwise the 68000 would have needed to be much more obscure in its behaviour...

Looking good! Might it need a few more bypass capacitors?

There are also capacitors in the sockets under each memory chip and under the CPU. If necessary, I can add more.

Guys, do any of you participate in the EASy68K forum:
http://www.easy68k.com/EASy68Kforum/index.php
I cannot open this page, the following message appears:
Fatal: ./cache/ is NOT writable.
What can you advise me in this regard?

I'm not a member there, but I see the same message when I try to visit, so I guess the forum's down.
Furthermore, using the Wayback Machine at archive.org (I find myself using that more and more these days - a lot of old information is starting to drop off the net.) the snapshot from April 2021 shows the same message.
Going back a bit further, I guess this snapshot from August 2020 is the explanation: https://web.archive.org/web/20200811122 ... /index.php

It's clear. Apparently, the restoration of the forum was delayed.
Thank you robinsonb5. But, I have a question.
In EASy68K, and in many other assemblers, there is a directive DS (define storage), which does not initialize memory locations, but merely increases the value of the address counter. But, the DS directive works differently in the vasm assembler: it fills the given memory area with zeros. It turns out that these locations are initialized with zeros. I've never used EASy68K and I don't understand what uninitialized memory locations in a.out file should look like? After all, these uninitialized locations should still occupy some part of the output file size?

An uninitialised area still has an address, so the program text would be expected to have some references to the Defined Storage.

But, as it has no data, it's not needed in the executable. I'm not sure what that looks like in 68k, but typically in a unix-like layout the executable will start with the program code, and then the initialised data, and then end. The uninitialised storage is what lies beyond the end of the executable. The heap, if there is such a thing, would start after the uninitialised storage.

In the land of 6502, one can imagine zero page locations will be needed by the program, but will not be initialised, as the program will typically be loaded at a higher address. Possibly DS would be the way to refer to such locations.

Hope this helps a bit - perhaps someone else can do much better and be more specific about the 68k.

Edit: perhaps also see https://stackoverflow.com/questions/356 ... ctionality

OK. So far, it seems to me that the memory area allocated by DS does not inflate the size of the output file if it is located after the executable code. If to place it among the executable code, then the output file will grow. Something like this.
I don't want to create a new topic, let me ask one more question regarding assembler here.
Here's the program I'm currently trying to figure out:
http://marc.retronik.fr/motorola/68K/68 ... onitor.zip
It contains the ORG directive several times, in the following sequence:

How permissible is such a sequence? The vasm assembler was unable to arrange the segments in the correct order and I needed to rearrange the source code fragments to get the correct result.
Do other assemblers besides vasm deal with this sort of thing on their own?

I had similar trouble with vasm not outputting sections as expected. Empty sections at the beginning were not outputting causing the code to be placed in the wrong location in the binary. I worked around it by defining dummy variables in each section to force output. I believe this issue is fixed in a more recent version of vasm.

I think the assembler is pretty good. Do you have a linker script with the locations of .text, .data, etc. defined in it?

I apologize for not checking the forum for a long time and missing the reply to my post. Is there a way to set up notifications about replies?

No, I haven't reached that level of skill yet, it's too difficult for me. I need to read something on this subject.
I use the vasm assembler, but it seems that I do not fully understand all the features of its behavior. Today I came across the following thing.

Here 'bsr writb' assembles incorrectly as '61 00 04 00'. The second word should contain an displacement, that is, the relative distance in bytes to the target label. But for some reason the label address itself is there. As I understand it, this is because the program consists of two sections. If the line 'org $408' is removed, then there will be only one section and everything will assemble correctly.
Is it possible to force vasm to call subroutines from another section with bsr or is it necessary to use just jmp ?

I don't know how to force vasm NOT output empty sections, but only output the ones I need. So far, I'm using a HEX-editor and cutting off pieces that I don't need.

That should happen automatically - probably there's some delivery problem with the emails. Sorry about that, but not much I can do. The emails are, unfortunately, not authenticated (no DKIM, no DMARC). I see them annotated like this:
In case you can set up a filter, the header contains