Beiträge von LGB-Z

    Gábor excuse me, my english isn't well.


    No problem, welcome to the club, mine is kinda lame as well :)


    Ah, so I can see, you are at least prepared for the difficulties for such a project. Sounds interesting. I wouldn't say that Raspbian is "bloated" but yes, compared to a bare metal project, it IS, no doubts, in fact almost everything is bloated then compared to bare metal :) (though still some can have a middle-way to strip down a Linux distro to the absolute minimum and using that .. yeah, it's still not bare metal, that's true!!) I'm not sure still about SDL2 though. The link you've provided discuss about building SDL2 on Raspbian / some kind of Linux, not on "bare metal" (yes, SDL supports working without X, but still depends on the Linux kernel/framebuffer then, and also some OpenGL stuff, I guess) ... Though I can be wrong ...


    I always enjoy to do projects like this, but unfortunately, I have not so much free time for everything :( If you can create a demonstration to be able to compile some SDL example code (which would compile for Linux / Windows as well without any hack, and on the top of your bare metal project as well - again without any change on the SDL example code of yours), then I think we have a good hope already. But unfortunately I have no time to play with that at level (even though it's quite exciting "game to play"). But, I think, if you can provide a more or less complete test-case where everything already works, and any "standard" SDL app can be run), then it's a much easier project already, and maybe then it's time for me too, to jump in (I have raspberry pi 1 and 3 too, so I can play with that).


    What Xemu uses from SDL mainly:


    * getperformancecounter stuff, and others for timing
    * create window/renderer/texture, with OpenGL acceleration (though it works without it, just I guess it will be painfully slow), streaming texture support
    * able to scale textures on rendering with/without antialiasing
    * alpha blending of textures (needed for OSD, and the soon-coming OSD based menu system ... though probably it can be commented out with all of these functionalities then)
    * SDL audio stuff (unless you don't need audio)
    * SDL joystick/game controller functions (unless you don't want to support these)
    * SDL keyboard stuffs
    * SDL basic event handling stuffs
    * standard C library functions (most important part are file system related functions)
    * POSIX (even on Windows, provided by mingw then ...) functions, quite various things


    Just some quick ideas by heart now, far from being exact or complete list ....

    @LGB-Z: Hi, Lénárt. Nice to meet you here. Please, could you make an arch=ARM11 (BCM2835) for me? I would like to try something out. It is for a "BARE METAL" project.

    Let's stick with Gábor, Lénárt is my family name :)


    It does not make sense to create a new "architecture" unless I (or you) know what to do differently for that architecture ... I mean, I can do that, but without filling the needed code, Makefile changes etc etc etc needed for that given "port" of Xemu, it will result in the same as some other "arch=" (architecture). For "bare metal" you basically want to run something without any OS, etc. For starting point, you must port the whole SDL2 project to that situation. Then you must add your own code to do initialization of the hardware itself you want to run on, providing/implementing some C / POSIX like functions, including implementing file system, time/date/timing stuff, audio/video "drivers" etc. Basically you need to write your own "mini OS", since in case of bare metal, you don't have an already existing underlying infrastructure provided by the OS. So you must do that for yourself. Also, for sure, you need the dedicated toolchain for the given architecture, but that's the most easy part really, the bulk of a "bare metal" project is rather the other stuffs.


    What you want to do can be similar to the "Commodore Pi" project for example, I believe, for that project as well, not so much happened since years, since all of the CPU / hardware / etc initialization must be done manually, and the performance somehow is horrible compared to using an OS (as it turned out, it's not so much trivial to set CPU's caches, programming the "chipset" - well in case of Raspberry Pi, it's really a SoC but anyway). So you see ...


    Anyway, I had some similar idea as yours here some time ago, but it's really not so easy to do so. Xemu is developed to utilize SDL2 also some common OS functions like filesystem etc. All of these dependencies must be provided first, to be able to run Xemu on it .... (Xemu is not even a "clean" SDL project, ie it used other calls as well than only SDL ones, let it be C standard, or even POSIX, which is provided in case of Windows by the mingw cross-compiler's run-time stuff ...).


    But in fact, I already tried to run Xemu on Raspberry Pi (though years before, even before C65/M65 emulation in Xemu ...), it works, but note, that it wasn't a bare metal project, but running on the Raspbian OS (Linux) of Rapsberry Pi (though it worked without X, as SDL2 has support for using framebuffer implementation of the Linux kernel directly, I believe ... or something similar, I can't remember now so much).

    Just by the way: The NSIS Installer for creating windows installs is also available for Linux. So no need to use wine for this. In ubuntu this pakage is named "nsis"

    Wow, I haven't even had the idea that it can be the case, useful advise, I'll check it out, thanks!


    Thanks for the explanation. Our security system had a fit over it, but I believe you that it is false from using the NSIS installer.


    The builds are very much appreciated. You can just zip them up and distribute them that way- much easier! Most of us old-school guys do not need installers. :)

    :) :) That's funny, because I exactly tried to put work into this, to provide more easy way for windows users to be able to try Xemu :) OK, I'll put out a zip file as well then, with just the xemu's exe files and the needed SDL2.dll for the given architecture (32/64 bit version of exe+dll).

    Btw, I tried to insert a warning on that download page of mine about the problem, with a link to the nullsoft's article about the TONS of false positive on NSIS installers ... This kinda sucks though, I'm really unsure how this should be done better not to "catch the attention" of antivirus software with a sane enough installer. Btw, still, some windows expert/power-user/tester/etc is still wanted to fill the holes of my lacking Windows knowledge ... Thanks.

    Is this trustworthy, or did I just install a virus ?!
    https://www.virustotal.com/en/…c5ab/analysis/1556134224/


    The site is now blacklisted as well as containing malware.


    Huh ... I believe at least it's just a false positive ... I haven't even used Windows to create those EXEs _THOUGH_ it's surely never say never, I had to use Nullsoft's NSIS installer creator (running with wine on Linux) to create those installers. That is one reason I hate Windows, always dealing with stupid viruses etc ... But if you google for "nullsoft trojan" you'll see how many articles found that many antivirus software treats Nullsoft's installer as virus/trojan/whatever, which is their fault ... So at least I *believe* that's only a false positive (in fact, some articles mentions that the reason for this: though NSIS is a legit installer creation tool, many virus/trojan author started to use it to pack dangerous content inside, so some antivirus software now badly marks the NSIS itself as being a virus). Maybe other with more Windows experience can judge on this, I can only develop software for Windows (with cross-compiler running on Linux), but I never actually even used Windows, so I no idea about this virus world too much :-O


    So it seems it's very hard to make any Windows based distribution of Xemu, always some problem, should I stick with source, and let windows users to compile? Windows world simply does not allow too much things, and always causes problems, it seems, we should all use Linux :) Ah, probably not. Just I am sad because of these stupid Windows/virus problems :( Though, as always, I am open with suggestions, even with ones that I should try another scriptable installer makers to create installers for Windows, and similar things. Thanks in advance!

    type "POKE0,64" in c64 mode to switch to 1MHz


    type "POKE0,65" in c64 mode to switch to 40 MHz !!!


    type "SYS58552" in c64 mode to switch to c65 mode

    Actually, those POKEs works in C65 mode as well, then it switches between 40MHz and the "standard" C65 speed. Mega65 (M65 for being short) has some CPU speeds, the "C64" ~1MHz, the "C65" ~ 3.5MHz, the "M65" 40MHz (currently, it changed some times already, because of the evolving design and timing details at FPGA level), but also has a "C128"-style 2MHz mode for example (bot no other C128 features, to be precise). Surely, in C65 mode, one can say "GO64" to go into C64 mode (resembling to C128, though the details are very different, surely this is not an M65 thing, it's the same on the C65). For C65, the "C64 mode" is not like C128, the additional hardware & co can be easily accessed if desired (though a "sequence of key values" needs to be written to enable VIC-III registers) so even C65 or M65 software can be realized with the need to load in C64 mode first ... A real C65's C64 mode is kinda limited in terms of C64 compatibility (eg, the problem with read-modify-write opcodes, no NMOS 65xx opcodes etc), M65 is expected to refine the situation a lot with better C64 compatibility in C64 mode. Also, interestingly, C65's VIC-III is kinda different from VIC-II (no way that's it only an "extended" VIC-II design, it's much more felt like a new stuff with trying to keep VIC-II basic features intact, as far as I can feel, at least from the implementation details level!), for example the designers felt, that it's OK to introduce the new scheme that VIC-III only changes video mode at every "bad line" and not between, and they even claimed that it's a good thing and helps split-screen programming. Well, I am not sure if it's a great idea ;) Anyway, VIC-II and VIC-III are kinda different, even if no VIC-III features are used, not so much hope for any "modern demo effect" to be able to work on C65/VIC-III even not in C64 mode using only "legacy" VIC-II modes and registers because the details, timing, etc are kinda different. I think, M65 tries to refine this situation as well ... Though these comments of mine are basically more my experience programming/emulation M65 and C65 rather than being any official statement of the M.E.G.A. team in this case!


    Hopefully this was not too much off-topic from me to mention.

    Hi adtbm,


    Hi LGB !
    Nice to meet you over here !
    Thanks for all the time and work you have invested already in the Mega65 emulator.
    So my first question would be: What is the/your official name for the Mega65 fork of the the xemu emulator ?
    Xmega65 ?


    Well, I am not so a kind of naming guy, you can call that way if you like :) I really have no name about the emulators inside the Xemu project, I usually call them "x" + targat_name :) Or maybe Xemu/Mega65 or Xemu/M65 for short in case of the Mega65 emulator inside Xemu. Bust Xmega65 also sounds reasonable for me.


    Zitat

    Paul also shows up here regulary and i have the task in the name of the MEGA Team, to try to coordinate and forward the Mega65 (Emulator included) related questions, inside forum64, to the appropriate people from MEGA to be able to provide answers.


    Well, then emulator related ones can be forwarded to me :) I'm not sure I am the right person to summarize things after all, that would be a novel already :)


    Zitat

    So once again: :wilkommen:


    Thaks!


    Hi emulaThor and btw, all ;-P


    Thanks. Honestly, I worried that it's against the rules to post in another language in an already existing German topic. In my experience, it's always a very big "sin" to do on many forums / communities. So hopefully I won't be banned because of doing it. If anyone has problem with this, I'm sorry about that and please suggest another thread, etc where it's fine to write in English. Thanks for your patience to my lack of the German language (which is especially a shame, since I was taught German for two years in the school but I totally forgot everything for now ...). Hopefully at least it was honoured that I tried to write in German :)


    OK, let's clear things about Xemu & Co (sorry about this part of history, and maybe not so relevant things to the topic at first sight). It's totally my project, we can say, it's a one-man project (me). I had some one-two-etc-liner contributions though, I have to clarify that, to avoid the suspect that I want to hijack other's work and help (which is always welcome, for sure). Xemu has some parts, where there is code which wasn't written by me though, only I "adopted" with trying to keep the software license things clean and legit. In the C65 and M65 (short for Mega65) emulators of Xemu, it's the SID emulation part, and I "borrowed" some macros from VICE in relation of the CPU (yeah, I love the BCD mode ...) emulation (Xemu has some other non-commodore specific emulators with more "imported" code, like the Z80 emulation). Xemu was originally written by me as the world first working emulation of the Commodore LCD, which even hadn't got any sane specification how it works, so I had to deal with some "detective" works debugging the ROMs, hunting for images on the net with PCB photos, and asking some ex-Commodore-engineers and such for months to be able to write some kind of specification then my emulator. i also helped then the mess/mame project to bring their Commodore LCD emulation to a working level (I assume they did, I have no idea what happened there then). Then, that emulation is started to become my own framework to emulate other things as well, what seemed to be interesting for myself, starting with the Commodore 65.


    Then we had some chat with the leader of the Mega65 project if I can modify my Commodore 65 emulator to emulate Mega65, which can help the development of the Mega65 itself and I went in. But it was clear after a while that it's hard to maintain a "mixed" emulation within Xemu, which is able to emulate a "pure" Commodore 65 and Mega 65 (which needs SD-card access emulation and many other, even to just able to boot) so they became two different emulation "targets" inside Xemu. Since Mega65 seems to be the most complex thing now inside Xemu, indeed, it sometimes dictates the way of the whole Xemu project, but Xemu is not only a Mega65 emulator, other stuffs can benefit from that too, in the long term. Also please note, that I cannot say I am so great in writing emulators, I'm - I guess - just keen enough to do so :) My emulators have some problems after all, being too hard to use by average users, and some aspect of emulations were not even in the focus too much, like good sound emulation, or supporting all the nifty things of VIC-III and VIC-IV. Mega65 emulation inside Xemu _tries_ to keep up with the development of the Mega65 itself, but the main focus was to help mega65 developers themselves, so it's more strong on the "system level" rather than the "multimedia centric" features (like good audio, good gfx, etc etc). Surely, I don't say I don't want to change on this, I can do what I do, within a time I have :)


    No, Mega65 and Xemu is not the same project, though currently as a Mega65 team member (we can say, I hope ...) I have mostly the task to try to create an as good emulator of the Mega65 as possible (where Mega65 emulation in Xemu is in fact only one emulator among others), but it's not exactly an easy task do, especially that Mega65 is in rapid "movement" as a target, since it's under development, you see. Since my time is limited, the most work goes in the Mega65 emulation though currently, besides other structural changes in the "Xemu core" dictated by that.


    The next interesting thing about me, that I am not a windows user, to a very strange level, I never used Windows neither at home nor at my workplace (being "UNIX System Engineer"). But I understand the needs of the people, in fact, that's the sole reason I learnt some Windows specific programming stuffs myself to be able to provide Xemu for Windows! It's funny because I use Linux to produce Windows binaries as well (with mingw cross-compiler) what I can't even test too much, without Windows ... Recently, I tried to be even more friendly about Windows users, that I tried to create an installer for Xemu on Windows, using Nullsoft's NSI install shield, running with WINE on Linux. I think, the main problem with "me" that I have messy habit to release binaries, let it be Windows or anything other, and not everybody is keen to compile things from source code especially because that needs Linux or UNIX-like environment even to produce Windows EXEs which can be used then only Windows presents (though for that, the "bash prompt" in Windows 10 should be enough with some components installed, as far as I know).


    In nutshell, it's welcome if anybody wants to help, in any way. In fact, even just Windows testing and telling the opinions can be great, as my Windows user experiences converges to zero, I guess.


    Meanwhile, I tried quickly put together some kind of "distribution" page which maybe helpful, but please be patient with those stuff :)


    http://xemu-dist.lgb.hu/


    I've even managed to compile Xemu/mega65 for "the web platform" (meaning it runs inside the web browser, without any installation etc needed) using the great emscripten compiler based on clang core (the the UI is totally broken now). I've also quickly tried to put those "experimental" NSI windows installers on-line, on that page. Currently my main web site (lgb.hu) is down (server problem) so if anyone has an URL ending with lgb.hu in relation with Xemu, it may not work. This very page is hosted now on another web server, and only a half-an-hour work of mine to quickly put some things together to be able to used then by others. The web demonstration tries to solve the issue to give a quick preview for everyone, without the need of complex installation, configuration, etc tasks. It was an attempt of mine, to try to solve this problem, I've even read here (with google translator ...) that people has problems trying to run Xemu/C65 or Xemu/Mega65.


    I'm not sure what you mean about "new hardware" though ... New hardware of Mega65? It's an FPGA based hardware implementation, and I have the FPGA board, I can even synthesize the bitstream from the VHDL of the project. Or did you mean about new hardware to run Xemu on? Sorry, I really can't get the point here, but as you can see, not only my German, my English is neither perfect :)


    I'm really sorry about my long message here, anyone knowing me can tell, it's a major problem with me, to always writing monster sized posts, mails, whatever :)


    Wlecome LGB, nice to see you joined us ;-)
    It is ok for using english here. As you can see there are really people interested in your Xemu.
    Of course mainly the C65/MEGA stuff, altough I also often dig into xclcd :-D


    You did a great job, and I hope that your project will benefit from the increased attention here.
    Sadly enough I can't speak magiar, altough it could help a bit in my future home (when I fully retire) in Salaj ;-)

    Hi Freddy,


    Thanks, I've already written a loooong answer to emulaThor, though the forum told me, that my message is hidden till a moderator enables it ... I guess I wrote too much, or it's "too English", or just because the external URL I put into ... Now I try to write a short message here, with the hope, it won't be blocked then ...

    Hallo Freunde, es tut mir leid, Google hier zu veröffentlichen. Ich kann gar nicht Deutsch sprechen (und ich denke, es ist vielleicht gegen Regeln, in anderen Sprachen in diesem Forum und in diesem Thema als Deutsch zu posten).
    Ich bin der Autor von Xemu, und ich möchte nur sagen, dass ich glücklich bin, zumindest anderen zu helfen, wenn ich genug Zeit dafür habe (da Xemu ein Hobbyprojekt von mir ist). Ich bin mir nicht sicher, wo es sein sollte. Ich würde den Google-Übersetzer nicht ständig verwenden, und ich bevorzuge Englisch, es sei denn, einige sprechen Ungarisch. :) Ich habe mich gerade in diesem Forum angemeldet, um dies zu sagen.

    I'm not sure if it's not a subjective thing. Actually I LOVE to type on C64 keyboard even nowadays! And meanwhile I use - of course - PC keyboards a lot, as well ... So it would be hard to give you an answer, it depends on your taste. But surely, I am curious to try M65's keyboard as well, if it's ready :)

    Also don't forget the DMA engine which helps very fast transfer/fill memory areas with optional features like integer and/or fractional skip rates at source/target, and so much. I also used once a 256 colour video mode with a "setup" as "tiled gfx" in the way that every "pixels" under each other exactly has +8 offset, so then DMA can be used to fill that area with gfx with skip target rate of 8. This for sure needs to set up "video RAM" with 16 bits mode, and with address of "glyps" arranged in the way that the scenario I've described above would apply ... Thus a bit tricky to do, but a "bit more linear" then to handle, even if it's vertically and not horizontally, but at least always +8 then. Or so, hard to explain with my "fantastic" English :)

    Also don't forget the DMA engine which helps very fast transfer/fill memory areas with optional features like integer and/or fractional skip rates at source/target, and so much. I also used once a 256 colour video mode with a "setup" as "tiled gfx" in the way that every "pixels" under each other exactly has +8 offset, so then DMA can be used to fill that area with gfx with skip target rate of 8. This for sure needs to set up "video RAM" with 16 bits mode, and with address of "glyps" arranged in the way that the scenario I've described above would apply ... Thus a bit tricky to do, but a "bit more linear" then to handle, even if it's vertically and not horizontally, but at least always +8 then. Or so, hard to explain with my "fantastic" English :)

    Also don't forget the DMA engine which helps very fast transfer/fill memory areas with optional features like integer and/or fractional skip rates at source/target, and so much. I also used once a 256 colour video mode with a "setup" as "tiled gfx" in the way that every "pixels" under each other exactly has +8 offset, so then DMA can be used to fill that area with gfx with skip target rate of 8. This for sure needs to set up "video RAM" with 16 bits mode, and with address of "glyps" arranged in the way that the scenario I've described above would apply ... Thus a bit tricky to do, but a "bit more linear" then to handle, even if it's vertically and not horizontally, but at least always +8 then. Or so, hard to explain with my "fantastic" English :)

    Yes, indeed as rosetiff described ... C65 didn't know about illegal opcodes, so in this sense programs trying to use illegal opcodes of NMOS 6502+friends would result in crash anyway, or at least very "interesting" things, so not so much difference what causes the crash then :). HOWEVER as Mega65 wants to implement more C64 compatibility in C64 mode, new C65+M65 opcodes will be "hidden" in that mode, and you can enjoy the "NMOS instruction set" including illegal opcodes. So no accident can happen ever. In C65/M65 mode, there are virtually no "old" programs at all exists, we can say, so it's not a problem there ... The only "accident" I can imagine that newly written M65 programs accidentally using NOP + XXX (nn),Z where programmer does not have the intend to use the new instruction ... I don't think it's a common problem in the future, but anyway, future assemblers supporting M65 may can emit warnings, if it detects the generated code consist of the sequence not the result of a new opcode's token though, like some existing 65xx assemblers can warn user if it emits JMP indirect on page boundary which is known to be buggy on NMOS 65xx CPUs.

    Actually, 65xx asm syntax always used index register syntax with comma, so Paul's idea about ($nn)+Z does not feel somehow right for me, sorry about that ... But I can leave with that, I won't kill myself if I see only that :)

    As fredrikr suggested, I would say something like that, though not "LDAF", that's not my taste, about my always-three-letters-fetish ;-P

    Some assemblers already introduced modifiers like Z: to denote zero page, like LDA (Z:$nn),Y which is (I had this example before ...) helps to signal the Zeropage addressing used. I would extend this idea, however the opcode still holds only 1 byte long ZP address, thus, not inside the brackets, but outside! That is for example:

    LDA Q:($nn),Z

    In this example "Q:" means that the "pointer reference" done by zero page addressing is meant for a Q (again, Quad-byte) "entity", that is 32 bit. This would even work:

    LDQ Q:(Z:$nn),Z

    Ok, it's just too cryptic maybe :) For the "Z:" part is kinda just for the fun here as an example, but that part is understood at least by CA65, I don't know others. But the more clear and not so "artificial" example is:

    LDQ Q:($nn),Z

    This combined the "LDQ" (load Quad byte) with the 32 bit addressing mode when fetched a Quad-byte as pointer from the zeropage starting at $nn. Basically it's the same as for example:

    LDA *($nn),Z

    just to have a more clear way to define the meaning of "*" converted into "Q:". That even harmonizes well with the usage of "Q", within opcode (like LDQ) is the data which is 32 bit, within addressing part, the "Q" in "Q:" means the address uses 32 bit (32 bit, again = Quad byte, thus Q).

    Btw, I choose Q since it sounds logical to quad-byte. And quite close to X,Y,Z letters anyway. W would not make sense as it means 'Word' and also already used with 65CE02 for INW. 'D' for 'double' (word) or 'L' for 'long' would be logical, but somehow it looks strange for LDL and LDD, LDQ is kinda easier to recognize :)

    < and > are problematic because of used as lo,hi bytes operators in many assemblers, I think. {...} sounds nice on PC screen maybe, but dangerous on lower resolutions and easy to confuse with (...), as you also suggested. The (q$nn),Z has other problem, that the $nn can be actually a label/symbol, so: MYLOC = $AA then (qMYLOC),Z is not sane too much, as there is no way to separate the 'q' from the label. Ok, with a space, maybe ... I would try to keep ($nn),Z similarities btw, since it's basically really similar, the same addressing mode, just the ZP location is extended from 16 bit memory pointer to 32. So I like ideas:

    LDA (($nn)),Z
    LDA !($nn),Z
    LDA [[$nn]],Z

    or anything which similar to the original addressing mode, just with a bit "extra" added, to signal the difference between 16 and 32 bit pointer value on the ZP. Btw, I would try to avoid put anything between (...), as basically that's the location, which is ZP even with this addressing mode. Logically, the difference is how that ZP location is interpreted, a 16 bit value stored from that ZP address, or 32, which then can be referenced after Z added to the value fetched from ZP. Well, or such :) So, technically with assemblers support it, this is valid even now with 6502 only:

    LDA (Z:LOC),Y

    Like, ca65, "Z:" just signals that LOC must be interpreted as zero page address, ie just one byte. Surely, it does not make sense here to be used, as this addressing mode only supports that ... But you can use it even here, if you want. I just want to show with this, that inside the (...) signs it's more about the address of the pointer itself, and not about the interpretation of that data (ie being a 16 bit address then to be used, or a 32 bit for M65 ...). In this synax ( and ) signs means that the ZP location (which is still 8 bits, even with M65 32bit stuff) must be read than as a 16 (6502) or 32 bit address to be used then to add with Z to form the address of the operand. This, I think, only outside of (...) should be modified to be logical, or (...) must be replaced maybe with other signs, or whatever. I would also keep the structure being (...),Y and (...),Z intact since it's basically the same function just 32 bit pointer instead of 16 bit. Etc, etc, sorry, I write too much again, I guess, as usual, I struggle to express myself well enough and in a compact form, if it's English and not Hungarian :)

    But that's only my logic, for sure ;)

    Honestly, I don't like this AXYZ stuff too much, I mean at assembly syntax level. I was always fan of the "three letters" only, used by any 65xx CPU assembly syntax. yes, I know, it's more a personal opinion and feeling, rather than actual "science", that's true :)

    I would choose a new name for the '32 bit register", let's say "Q" (just a proposal, Q would mean Quad-byte, basically the "concatenated" registers of AXYZ ...), so LDQ would be LDAXYZ ... That's look much more cleaner for me, but this is only my opinion. Also, like "CMP" used for X register is "CPX", I would name "ADCAXYZ" as like "ADQ" for example instead, so the third letter shows the difference. If there is "INC AXYZ" at all, I would call that "INC Q" (like INC A) or "INQ" (like INX, when register name is part of the asm token name itself).

    The ((ZP)),Z syntax seems to be OK, ((ZP))32,Z it's a kinda strange to look at it :) If it's need it's still better - I think - this way: 32:(ZP), Z or kinda other syntaxes like @(ZP),Z or whatever, where "@" or "32:" shows the referenced memory (in ZP here) holds a 32 bit pointer, so it's special compared to the usual 16 bit address referenced.

    For the 32 bit load constant ... I see one extra value here: without a dedicated "single" opcode, there is a chance that an IRQ routine happens meanwhile. By using a "pseudo" op (at assembler level ...) you may expect that it's an "atomic" operation, as it's a single "opcode", so there is some - though minor ... - danger here, I am not sure it's even worth to be mentioned.

    :: @LGB added on 11 Mar ’19 · 14:57

    In fact, INQ sounds quite well, as 65CE02 already knows INW, though in the second case, it's not a register but a read-modify-write style op on a 16 bit value. But it does not matter too much, as it can be thought of different addressing modes, and after all, different addressing modes have different opcodes anyway :)

    Other proposed syntax for the 32 bit ZP stuff: L(nn),Z or !(nn),Z, maybe '@' is used somewhere else.

    In general, what I like about the asm syntax of any 65xx CPU that it's quite simple, always three byte names for ops, and easy to parse, even for a "hand written" (in 65xx asm!) monitor program or such (both for asm and disasm). But surely, the asm syntax is only a syntax, does not involve too much about the implementation details, so it's more like a cosmetic topic, but can be important for future assemblers want to support M65 stuff, and especially when some wants to write native tools running on M65 itself, where it can be important that the syntax should be simple and compact enough (it does not matter too much for a cross-platform assembler running on PC or such ...).