|
Post by dshadoff on Dec 13, 2021 19:37:04 GMT
I think this is still very early days in development... will take some time I think, but I'm sure that as soon as something is ready for testing, we'll know.
|
|
|
Post by elmer on Dec 15, 2021 16:56:39 GMT
I'm just going to use ".struct/.ends" (and "struct/ends") for the PCEAS version of this, and then "{}" will only be usable while in ".kickc" mode. Ahhhh ... now some niggling little implementation-details are starting to show up, about how ".struct/.ends/{/}" interact with ".zp/.bss/.code/.data". In KickC, the generated-code can change sections within a label-scope, and the scope remains active ... this is used for putting the data definitions for C's function-local-variables into the .data or .bss sections. It also looks like a "}" automatically returns you to the ".code" section, or more-likely, to the same section that the "{" was in. So turboxray and other PCE programmers, how do you want ".struct/.ends" to behave in PCEAS code. Should you be allowed to change section within a scope? Should each section have its own current-scope?
|
|
|
Post by dshadoff on Dec 16, 2021 1:01:47 GMT
I would say that scope should be possible to change, but it reverts back to parent scape at the .ends I never really gave much consideration to this though, and I would hope that the same - return to parent scope - is true of any .include'd code (and macros, if they are able to do the same).
|
|
|
Post by elmer on Dec 19, 2021 16:21:04 GMT
I would say that scope should be possible to change, but it reverts back to parent scape at the .ends OK, now both .proc/.endp and .struct/.ends allow the section to change within them, and the original section is restored when the .endp/.ends is processed. I've also fixed the rather-undocumented .opt pseudo-op which has been in PCEAS since at-least v2.51, but was horribly broken and was never used (AFAIK). Old flags ... ".opt l+" is the same as .list".opt m+" is the same as .mlist".opt o+" is an OPT_OPTIMIZE flag that doesn't seem to do anything ".opt w+" is an OPT_WARNING flag that doesn't seem to do anything New flags ... ".opt a+" enables automatic selection of zero-page addressing if the symbols in the operand are all defined ".opt c+" enables the use of C-style line and block comments ".opt i+" enables the use of "()" for indirect-addressing Since ".opt a+" can change the meaning of instructions, I've also added another traditional-syntax method of forcing absolute-mode. ; **************************************************************************** ; ; The traditional 6502-assembler usage of zero-page addressing when a symbol ; has been previously defined is supported, but only as an option, because ; it can change the meaning of instructions ... ;
.opt a+ ; Enable auto-zp addressing.
01:6097 9C 80 20 stz mysymbol ; Symbol is unknown here, so 01:609A 9D 80 20 sta mysymbol,x ; use absolute addressing. 01:609D 99 80 20 sta mysymbol,y 01:60A0 96 80 stx mysymbol,y ; Unless ZP is only option.
2080 mysymbol = $2080 ; Tell PCEAS that it is ZP.
01:60A2 64 80 stz mysymbol ; Symbol is defined now, so 01:60A4 95 80 sta mysymbol,x ; PCEAS uses ZP addressing. 01:60A6 99 80 20 sta mysymbol,y ; Unless ABS is only option. 01:60A9 96 80 stx mysymbol,y
.opt a- ; Traditional PCEAS behavior.
01:60AB 9C 80 20 stz mysymbol ; Absolute addressing is used 01:60AE 9D 80 20 sta mysymbol,x ; unless specifically told to 01:60B1 99 80 20 sta mysymbol,y ; use ZP addressing. ; stx mysymbol,y ; !Incorrect addressing mode!
; **************************************************************************** ; ; New ".z" and ".a" instruction suffixes for addressing modes, to add to ; the existing, but undocumented, ".l" and ".h" suffixes from v3.21 ... ;
; lda #__ax ; Error, because __ax > $FF. 01:60B4 A9 F8 lda #<__ax ; One method to get lo-byte. 01:60B6 A9 20 lda #>__ax ; One method to get hi-byte. 01:60B8 A9 F8 lda.l #__ax ; Or ... lo-byte of a word. 01:60BA A9 20 lda.h #__ax ; Or ... hi-byte of a word.
01:60BC B9 F8 20 lda __ax, y ; Default is absolute mode. 01:60BF B9 F8 20 lda.l __ax, y ; Addr+0 for lo-byte of a word. 01:60C2 B9 F9 20 lda.h __ax, y ; Addr+1 for hi-byte of a word.
01:60C5 B5 F8 lda <__ax, x ; Force zero-page mode. 01:60C7 B5 F8 lda.l <__ax, x ; Addr+0 for lo-byte of a word. 01:60C9 B5 F9 lda.h <__ax, x ; Addr+1 for hi-byte of a word.
01:60CB BD F8 20 lda >__ax, x ; Force absolute mode. 01:60CE BD F8 20 lda.l >__ax, x ; Addr+0 for lo-byte of a word. 01:60D1 BD F9 20 lda.h >__ax, x ; Addr+1 for hi-byte of a word.
.opt a- ; Traditional PCEAS behavior.
01:60D4 BD F8 20 lda __ax, x ; Default is absolute mode. 01:60D7 BD F8 20 lda.a __ax, x ; Force absolute mode. 01:60DA B5 F8 lda.z __ax, x ; Force zero-page mode.
.opt a+ ; Enable auto-zp addressing.
01:60DC B5 F8 lda __ax, x ; Symbol known, so zero-page mode. 01:60DE BD F8 20 lda.a __ax, x ; Force absolute mode. 01:60E1 B5 F8 lda.z __ax, x ; Force zero-page mode.
|
|
|
Post by elmer on Dec 31, 2021 17:51:37 GMT
New options flags ...
".opt b+" enables automatic conversion of out-of-range branches to long-branches ".opt w+" enables optional warnings, i.e. when a long-branch is generated
; **************************************************************************** ; ; Out-of-Range branches can be converted to long-branches with ".opt b+" ... ; ; The conversion changes the assembled instruction into a short-branch and an ; absolute jump. ; ; Note: In order to be converted a branch must be directly to a label, and ; when inside a label-scope, then only global labels defined within ; that scope can be converted. ;
01:60E3 60 !: rts 01:60E4 60 long: rts 01:60E5 60 .big: rts
01:60E6 00 00 00 00 ds 128 ; Add some distance.
01:6166 80 2D bra !+ 01:6168 44 2A bsr short 01:616A F0 28 beq short 01:616C D0 26 bne short 01:616E 0F 12 23 bbr0 <$12, short 01:6171 8F 12 20 bbs0 <$12, short
.opt b- ; Disable long-branch (default).
; bra !- ; Error, out of range! ; bsr long ; Error, out of range! ; beq long ; Error, out of range! ; bne long ; Error, out of range! ; bbr0 <$12, .big ; Error, out of range! ; bbs0 <$12, .big ; Error, out of range!
.opt b+ ; Enable long-branch conversion.
01:6174 4C E3 60 bra !- ; Converted to "jmp". 01:6177 20 E4 60 bsr long ; Converted to "jsr". 01:617A D0 03 4C E4 beq long ; Converted to "bne and jmp". 01:617E 60 01:617F F0 03 4C E4 bne long ; Converted to "beq and jmp". 01:6183 60 01:6184 8F 12 03 4C bbr0 <$12, .big ; Converted to "bbs and jmp". 01:6188 E5 60 01:618A 0F 12 03 4C bbs0 <$12, .big ; Converted to "bbr and jmp". 01:618E E5 60
01:6190 80 01 bra * + 3 ; Complex target address expressions 01:6192 80 01 bra short + 1 ; with math are never converted. ; bra long - 1 ; Error, out of range!
01:6194 60 short: rts 01:6195 60 !: rts
; In ".struct" and KickC "{}" scoped-labels can only be ; converted to long-branches if they are defined in the ; current scope.
myfunc .struct ; Open new label scope "myfunc".
01:6196 4C 23 62 bra .exit ; Local and multi-labels can be 01:6199 4C E3 60 bra !-- ; converted within a scope.
01:619C F0 03 4C 24 bne _exit ; Convert scoped-label "myfunc._exit". 01:61A0 62
01:61A1 80 F1 bra short ; Label not in scope, so assume short. ; bra long ; Error, out of range!
01:61A3 00 00 00 00 ds 128 ; Add some distance.
01:6223 60 .exit: rts 01:6224 60 _exit: rts
6225 .ends
|
|
|
Post by elmer on Jan 4, 2022 17:14:48 GMT
I might give Nesasm a try someday again to see if the improvements work. I saw that thread on NESDEV where it looks like some people are still using an old fork of NESASM. I'm kinda surprised that nobody bothered to fix up PCEAS's procedure calling for use on the NES, it would seem to be a good fit for *any* console/computer that can benefit from banked-code.
|
|
|
Post by dshadoff on Jan 4, 2022 17:49:14 GMT
Yeah, I haven’t seen any proper overlap of developers between the two systems. There are few enough developers for PC Engine as it is, and most of assume that NES built their own tools and don’t need to share.
|
|
|
Post by turboxray on Jan 4, 2022 21:17:12 GMT
I might give Nesasm a try someday again to see if the improvements work. I saw that thread on NESDEV where it looks like some people are still using an old fork of NESASM. I'm kinda surprised that nobody bothered to fix up PCEAS's procedure calling for use on the NES, it would seem to be a good fit for *any* console/computer that can benefit from banked-code. Because the NES dev scene uses like 5 assemblers hahah. I'd say remove NESASM all together from PCEAS source.
|
|
|
Post by elmer on Jan 5, 2022 17:49:41 GMT
Because the NES dev scene uses like 5 assemblers hahah. I'd say remove NESASM all together from PCEAS source. Yeah the Atari 8-bit scene has quite a few assemblers, too, none of which I like. Then Emmmanuel Marty brought another (C64? Apple?) one out of the woodworks when I was doing the 6502 LZSA decompressors. And gawd, the KickAssembler that KickC uses is a bit of an overly-complex monstrocity clever tool. I don't see much reason to drop the NES stuff from what is PCEAS aka NESASM (and now also aka FUJIAS), because they're really not causing any problems. I was wondering if it was worth doing anything specific to NESASM to make it easier to run KickC code ... but it sounds like there just aren't enough users out there to make the effort worthwhile. I may do something along those lines for the Atari (FUJIAS), because that's something that I know there's an interest in, even if it's only my own interest!
|
|
|
Post by dshadoff on Jan 5, 2022 22:38:17 GMT
The other challenge for keeping NESASM in, is - who will perform testing to understand if/when breakage occurs ? It's a piece of work which distracts from progress elsewhere... I think deciding to keep it supported implies that either (a) you think it's a trivial amount of effort to maintain, and/or (b) you are volunteering to do so...
|
|
|
Post by ccovell on Jan 7, 2022 0:55:54 GMT
I'll chime in as someone who uses both PCEAS and NESASM for PCE and NES/Famicom/etc programming. I could do some sort of testing to see if a new version of either causes some unwanted change in the ASM output.
(But I'm usually the guy who sticks to an old version of an assembler strictly for this reason. Who wants to keep updating syntax in every old ASM project simply because a theoretical update to the assembler might break something?)
|
|
|
Post by elmer on Jan 7, 2022 17:07:25 GMT
The other challenge for keeping NESASM in, is - who will perform testing to understand if/when breakage occurs ? It's a piece of work which distracts from progress elsewhere... I think deciding to keep it supported implies that either (a) you think it's a trivial amount of effort to maintain, and/or (b) you are volunteering to do so... Over the past 5 years I have speedily fixed every single reported problem with NESASM ... of which there have been a total of none. So, from my POV it absolutely has been a trivial amount of effort to maintain. The only specific thing that I've done to it in that time, was to restrict NESASM so it would only allow the legal (and the undocumented) NMOS 6502 instructions, rather than the full 65C02 instruction set that the assembler used to allow in NESASM mode. And I didn't do that for NESASM users, I did it so that I could correctly assemble code for the Atari ... it just also happens to apply to the NES. Now, if the NESASM build becomes an unwanted distraction, or if there is a real reason to split it off, then sure it's easy to do. But until that point I see no reason to remove it, especially since the ability to use it to build KickC code for the NES *might* be useful in the future. I could do some sort of testing to see if a new version of either causes some unwanted change in the ASM output. (But I'm usually the guy who sticks to an old version of an assembler strictly for this reason. Who wants to keep updating syntax in every old ASM project simply because a theoretical update to the assembler might break something?) You seem to be assuming that (a) the syntax is continually changing in incompatible ways, and that (b) the changes that are made have no value. As for the value of the updates, you're right, that is definitely in the eye-of-the-beholder, and if you don't find that the updates offer anything that appeals to you, then I totally understand. But the syntax is absolutely *not* being altered at a whim with no regard about breaking old code. Old code is still supposed to assemble correctly, unless it is relying (for whatever reason) on something that was obviously-broken in previous versions of PCEAS/NESASM. If you wish to try assembling your NES code with the current version of NESASM, that would be much appreciated, and then if anything does fail, we can see if it is fixable (i.e. a mistake was made), or if it really is time to remove NESASM from this branch of what-was-once-MagicKit-a-long-time-ago.
|
|
pokun
Gun-headed
Posts: 85
Homebrew skills: HuC6280 assembly
|
Post by pokun on Jan 7, 2022 20:13:05 GMT
I agree that Nesasm shouldn't be removed. It's one of the 3 most popular assemblers for Nes along with ca65 and asm6, and I now some people still prefer it. One reason it's quite popular is that the hands down best beginner level Nes programming tutorial for many years, the Nerdy Nights tutorial (initially posted on the now non-existing Nintendo Age forums), used Nesasm and it's still one of the most popular tutorials.
I sometimes recommends people to try the latest HuC fork of PCEAS/Nesasm since it seems to me to be the best fork of the assembler nowadays, I would be sad if I would have to see Nesasm having to go.
|
|
|
Post by elmer on Jan 20, 2022 16:33:03 GMT
FYI, although the PC Engine is happy with the new ISOlink CD-ROM file directory being in the 1st sector of the ISO, having it there stops the PC-FX from recognizing the CD as being a PCE CD-ROM, because the PC-FX compares the whole 1st ISO sector with the one stored in its firmware. So I have moved ISOlink's CD-ROM file directory from the end of the 1st ISO sector, to the end of the 2nd ISO sector, which contains the short PCE IPL boot information block, but is otherwise unused (although you can run your own loader code in there). One benefit of moving the directory info is that the new location will also work for PC-FX homebrew CD-ROMs, and so ISOlink will soon support building PC-FX CDs!
|
|
|
Post by elmer on Feb 2, 2022 23:34:30 GMT
As mentioned in the stickied threads, the ISOlink directory format and command-line options have changed a bit, but this should only effect folks who are actually using the recently-added IPL options, which AFAIK is only me! ;-)
I've also checked-in a couple of early example projects that use KickC instead of HuC.
One is a simple "Hello, world", and the other is a conversion of HuC's slightly-more-ambitious "shmup" example project.
I've also checked in the KickC-generated assembly language source files for the curious to look at, since I don't expect folks to actually try to *use* KickC just yet.
The "shmup.c" source file can be compared to the HuC version to give some idea of what it may be like for HuC developers to convert to KickC in the future.
Basically the C code itself may be quite similar, but how you define and organize your variables and graphics data is going to be quite different.
|
|