intvnut Posted January 31, 2018 Share Posted January 31, 2018 Another recent thread from INTVPROG that's getting cock-blocked by Yahoo's crappiness. ___________________________ Hi, there,I just noticed a change in the assembler's formatting of the LISTING file. Whereas each decle was always rendered in its own line, now consecutive decles (like for strings) are arranged on the same line. What's more, these lines appear to be of arbitrary length, making it harder (at least for me) to discern specific words.For instance, contrast the following original formatting: ; I can follow this vertical stream of words... 500F 0001 DECLE 1,1,1,1,1 ; 500F Initial color stack 0 and 1: Blue 5010 0001 5011 0001 5012 0001 5013 0001 5014 0075 DECLE 2017 - 1900 ; $5014 5015 0043 STRING "Christmas Carol", 0 5016 0068 5017 0072 5018 0069 5019 0073 501A 0074 501B 006D 501C 0061 501D 0073 501E 0020 501F 0043 5020 0061 5021 0072 5022 006F 5023 006C 5024 0000 With the new formatting: ; Looks like a jumble of numbers thrown in a pack... 500F 0001 0001 0001 0001 DECLE 1,1,1,1,1 ; 500F Initial color stack 0 and 1: Blue 5013 0001 5014 0075 DECLE 2017 - 1900 ; $5014 5015 0043 0068 0072 0069 STRING "Christmas Carol", 0 5019 0073 0074 006D 0061 0073 0020 0043 0061 5021 0072 006F 006C 0000 Line at location 0x5019 seem to pass beyond its "margin," blending into the source.I find this highly distracting. Is there a way to regain the previous formatting, an assembler directive or option perhaps?dZ. 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 31, 2018 Author Share Posted January 31, 2018 I had fixed an accounting error in the width calculation for emitted data. Now AS1600 is doing the "right thing," which is to output up to 4 words of emitted data on lines with code, and up to 8 words of emitted data on lines w/out code. The emitted data will always be at the left, separated by single spaces. Previously, the limit was 3 words on the same line as code, and it would try to space things out with tabs, and end up with really wonky formatting! This isn't new behavior. It was there back in 2002 when I wrote the Lunar MP Demo whose YouTube video I recently posted. . ;01234567890123456789 f81c 0020 0043 0047 @@m1 BYTE " CGE Demo Version " f81f 0045 0020 0044 0065 006d 006f 0020 0056 f827 0065 0072 0073 0069 006f 006e 0020 0020 . That all got cleaned up a bit in 2013, around the same time as the infamous NOT change. . ------------------------------------------------------------------------ r1055 | im14u2c | 2013-09-24 22:47:49 -0500 (Tue, 24 Sep 2013) | 1 line clean up listing file a bit; allow four hex words per assembled line, and move actual listing info over to column 32 ------------------------------------------------------------------------ . I think somewhere along the way, I may have b0rken support for outputting more than one word on a line for DECLE and STRING, while playing with the expression list stuff. That said, I don't seem to be able to find what version caused "one per line." Right now, these numbers are compiled in constants (and have been for eons). I'm having a hard time finding what version of the assembler outputs the data in the manner you call "original formatting." I tried the following 25 versions: jzintv-1.0-beta-x86_64-linux.zipjzintv-1.0-beta4-x86_64-linux.zipjzintv-20051204-linux-x86_64.zipjzintv-20100914-linux-x86-64.zipjzintv-20101212-x86_64-linux.zipjzintv-20101213-x86_64-linux.zipjzintv-20101224-x86_64-linux.zipjzintv-20150120-linux-x86-64.zipjzintv-20150213-linux-x86-64.zipjzintv-20160314-linux-x86-64.zipjzintv-20160331-linux-x86-64.zipjzintv-20160615-linux-x86-64.zipjzintv-20160817-linux-x86-64.zipjzintv-20170530-linux-x86-64.zipjzintv-20170530b-linux-x86-64.zipjzintv-20170708-linux-x86-64.zipjzintv-20170902-linux-x86-64.zipjzintv-20171031-linux-x86-64.zipjzintv-20171113-linux-x86-64.zipjzintv-20171120-linux-x86-64.zipjzintv-20171231-linux-x86-64.zipjzintv-20171231b-linux-x86-64.zipjzintv-20180108-linux-x86-64.zipjzintv-20180114-linux-x86-64.zipjzintv-20180115-linux-x86-64.zip I tried with the following test case: . ORG $7000 STRING "Four score and seven years ago...", 0 DECLE 1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0 . The output generated was one of two variants: . 0x7000 ORG $7000 7000 0046 006f 0075 STRING "Four score and seven years ago...", 0 7003 0072 0020 0073 0063 006f 0072 0065 0020 700b 0061 006e 0064 0020 0073 0065 0076 0065 7013 006e 0020 0079 0065 0061 0072 0073 0020 701b 0061 0067 006f 002e 002e 002e 0000 7022 0001 0002 0003 DECLE 1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0 7025 0004 0005 0006 0007 0008 0009 0000 0001 702d 0002 0003 0004 0005 0006 0007 0008 0009 7035 0000 ERROR SUMMARY - ERRORS DETECTED 0 - WARNINGS 0 . or . 0x7000 ORG $7000 7000 0046 006F 0075 0072 STRING "Four score and seven years ago...", 0 7004 0020 0073 0063 006F 0072 0065 0020 0061 700C 006E 0064 0020 0073 0065 0076 0065 006E 7014 0020 0079 0065 0061 0072 0073 0020 0061 701C 0067 006F 002E 002E 002E 0000 7022 0001 0002 0003 0004 DECLE 1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0 7026 0005 0006 0007 0008 0009 0000 0001 0002 702E 0003 0004 0005 0006 0007 0008 0009 0000 ERROR SUMMARY - ERRORS DETECTED 0 - WARNINGS 0 . I also tried checking out every 10th SVN revision, starting at r53 (the first really stable build in SVN from July 2006) and ending at 1593 (just a few revs from top of tree). None of the versions that compiled successfully (154 total) behave in the way you describe as "original." How far back are we talking here? Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 31, 2018 Author Share Posted January 31, 2018 dZ-Jay: __________ It's the version I was using during Christmas Carol development. However, I now seem to recall seeing more than one word per line in the past, hmmm. My guess is that it got broken in one of the builds while we were working on my game and you were fixing bugs and adding features. I never updated after Christmas Carol went out, until recently. (Well, I updated back in 2015, noticed the "NOT" issue, and reverted.) Anyway, the reason that I noticed is because I am trying to DIFF an old listing file from Christmas Carol with one built with the latest tools to try to find what is broken. I updated Christmas Carol source code to compensate for the updated "NOT" behaviour, but it is all broken and it won't run correctly. Is there any way to make this configurable? I find it very distracting to have lines "eat into" the actual code stream. You say that it emits up to 8 words of data on a line without code, but the problem is that the line before and the line after most likely do have code, making it all very confusing and harder to read. Can we keep it at 4 always? -dZ. _______________ Wait, I seem to recall updating at least once after Christmas Carol development but before 2015. I believe you increased the line buffer or something like that because my string search macro was breaking in P-Machinery...(Or perhaps I worked around it?)I also see this SVN log entry from February 2015:Christmas Carol:-----Fixed: At some point in time, the assembler changed its behaviour of "PSHR PC" to push the *next* instruction--which is actually correct. However, this caused an "off by one" error in calculating the data argument offset in the DEBUG_HANDLER() routine.-----And.... with the power of Time Machine, I retrieved the old version I was using up to last year, and the file has the following timestamp: Wednesday, May 16, 2012 11:40 438,532 bytes (442 KB on disk)Anyway, I did have an old version. :\ - j. Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 31, 2018 Author Share Posted January 31, 2018 Me: ____________ BTW, regarding this item: -----Fixed: At some point in time, the assembler changed its behaviour of "PSHR PC" to push the *next* instruction--which is actually correct. However, this caused an "off by one" error in calculating the data argument offset in the DEBUG_HANDLER() routine.----- That wasn't a change in the assembler. The assembler doesn't define the behavior of instructions. jzIntv itself incorrectly implemented MVO@ R7, R6, and that was causing Ms. Pac-Man to fail when run in jzIntv. That was the first game I knew of that was using that instruction. I'm guessing you never tried DEBUG_HANDLER() on real hardware? Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 31, 2018 Author Share Posted January 31, 2018 dZ: ___________ Yeah, that was an unfortunate typo. The DEBUG_HANDLER() macro was used only during development, while testing on the emulator. There were a series of macros that saved the state of registers on the stack in order to display machine state on the screen, then HLT'ed. Anyway, that was just an example to point out that I had updated the SDK tools at some point. - j. Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 31, 2018 Author Share Posted January 31, 2018 Me, yesterday: _______________ BTW, I haven't forgotten about this request. I've plumbed the required changes halfway through. The assembler really doesn't have any infrastructure for changing the details of the listing format from within the assembly itself. All that stuff is compiled in behavior. So I have to plumb a bunch of stuff through. In particular, the listing gets created in the back half; however, constant expressions get evaluated in the front half. So, if you're changing listing file parameters on the fly, I need to invent a new metadata record to pass from the front half to the back half to tell it "I'm changing a parameter that affects the back half." I also need to invent a keyword to convey that this expression changes an assembler config value, and so on... It's a simple-to-state request, but slightly less simple to implement. I suppose I could make it a command line flag, but it doesn't really seem like something that belongs on the command line. It's more like a game title. It seems like it should be part of the source. And even if it's slightly removed, you could do something like I did, and INCLUDE "bldflags.asm", and then use the -I command line flag to point to the directory that holds the appropriate build flags. For example, Space Patrol included "bldflags.asm", and relied on the outside build-script to add an appropriate -I flag to point to the right bldflags.asm. The production bldflags.asm was effectively empty. It was non-empty, but everything was commented out, making it effectively empty: . $ cat ./jzintv/examples/spacepat/bin/bldflags.asm ;DOIDLEHST EQU 1 ; def/nodef Enable idle histogram ;DODEAD EQU 1 ; def/nodef DEAD instead of dying ;OLDMENU EQU 1 ; def/nodef Old, simple menu ;SEEKKEYS EQU 1 ; def/nodef Enable seek Keys ;SKIPTITLE EQU 1 ; def/nodef Skip title screen ;SKIPHUT EQU 1 ; def/nodef Skip course intro w/ hut ;JUMPWORLD EQU 7 ; 0 .. 7, works only w/ OLDMENU . I don't know how many of those options still work. But I do know that you could make a directory that had a copy of this file, tweaked appropriately, and then you could rebuild Space Patrol with -I pointed at that directory, and you'd get a corresponding debug build. Anyway, I digress... I'm working on it, albeit slowly. Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 31, 2018 Author Share Posted January 31, 2018 Ok, I just added the following. It'll be in the next release. . ------------------------------------------------------------------------------ LISTCOL expr1, expr2, expr3 ------------------------------------------------------------------------------ This directive controls the formatting of the listing file. Specifically: expr1: Number of hex values shown on lines with source code expr2: Number of hex values shown on lines without source code expr3: Starting column for source code The defaults are equivalent to LISTCOL 4, 8, 32. The value for expr3 must be greater than or equal to 7 + 5*expr1. All three expressions must be greater than 0. expr1 and expr2 must be less than 256, and expr3 must be less than 2048. Example: ORG $7000 LISTCOL 4, 8, 32 DECLE 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1 LISTCOL 4, 4, 32 DECLE 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1 LISTCOL 8, 8, 52 DECLE 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1 Results in: 0x7000 ORG $7000 LISTCOL 4, 8, 32 7000 0000 0001 0002 0003 DECLE 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1 7004 0004 0005 0006 0007 0008 0009 0000 0001 700C 0002 0003 0004 0005 0006 0007 0008 0009 7014 0000 0001 0002 0003 0004 0005 0006 0007 701C 0008 0009 0000 0001 LISTCOL 4, 4, 32 7020 0000 0001 0002 0003 DECLE 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1 7024 0004 0005 0006 0007 7028 0008 0009 0000 0001 702C 0002 0003 0004 0005 7030 0006 0007 0008 0009 7034 0000 0001 0002 0003 7038 0004 0005 0006 0007 703C 0008 0009 0000 0001 LISTCOL 8, 8, 52 7040 0000 0001 0002 0003 0004 0005 0006 0007 DECLE 0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1,2,3,4,5,6,7,8,9,0,1 7048 0008 0009 0000 0001 0002 0003 0004 0005 7050 0006 0007 0008 0009 0000 0001 0002 0003 7058 0004 0005 0006 0007 0008 0009 0000 0001 ERROR SUMMARY - ERRORS DETECTED 0 - WARNINGS 0 Quote Link to comment Share on other sites More sharing options...
intvnut Posted January 31, 2018 Author Share Posted January 31, 2018 The overall diffstat wasn't as bad as I'd feared, once I'd made the compile-time values into variables a few commits back. Also, you can test for the presence of LISTCOL by testing for __FEATURE.LISTCOL. So, if you need your source to compile on older AS1600 versions, you can wrap it in a macro that tests for __FEATURE.LISTCOL. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted January 31, 2018 Share Posted January 31, 2018 Thanks for all your diligence in adding all these cool new features! Perhaps next time I should ask for a pony! -dZ. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.