artrag Posted March 3, 2019 Share Posted March 3, 2019 Could it be an interference among defines? How does the code in the ISR has changed ? Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 Here the dump just after the broken frames have appeared. Do you need also the LST file? The LST file would help in order to review the source code in context. The CPU history is only the execution history, so you only can see the branching path followed by the CPU. I'll take a look at it later. If for some reason boss_explode is called again it would fail because bosslife is 128 after the FOR That's easy to see, artrag: just put a write-watch on boss_explode. Get the address from the LST file and use the "w" command. For example, your previous listings showed it in address $0131, so you write: > w 0131 That will output to the console all the writes to address $0131, so it should be easy to see if it ever goes above 127. There has to be something nastier, boss_explode is called only in that loop. Moreover while tracing step by step the code I've ended to this picture that is strange because halfway between the correct frame and the dummy FFFFh frame... What could it be? What's strange about it? What should I infer from that picture? -dZ. Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 (edited) There has to be something nastier, boss_explode is called only in that loop. Moreover while tracing step by step the code I've ended to this picture that is strange because halfway between the correct frame and the dummy FFFFh frame... What could it be? OK, this is great, and it helps. I see that cards #1 to #5 are solid blocks. That means that something is writing to them that way. Knowing the base address of GRAM ($3800), you could compute the address of one byte within any of those cards -- a byte which you do not expect at all to be $FF -- and put a write-watch on it. As you see the output on the console, it should tell you not only the address of the opcode that modified it, but the CPU cycle number when it happened, like this: WR a=MEMMAP.Gram ($3800) d=0000 CP-1610 (PC = BLOCK.FILL.__fill ($5895)) t=17092 The first part tells me the following: a=<write-address> d=<write-value> PC=<program-counter-address> t=<clock-cycle> You can then correlate the clock-cycle of the watch with the ones in the CPU history file, on the right-most column of the file. For example: FFFF 7000 0000 0000 01FE 103D 02F1 1020 ------i- SWAP R0 626 The above indicates the following: FFFF 7000 0000 0000 01FE 103D 02F1 1020 => Registers R0 .. R7 ------i- => CPU Status flags SWAP R0 => Disassembled op-code 626 => Clock cycle From the CPU history we can trace back the path taken that lead to writing the solid block into GRAM. Let us know what you find. -dZ. Edited March 3, 2019 by DZ-Jay Quote Link to comment Share on other sites More sharing options...
Kiwi Posted March 3, 2019 Share Posted March 3, 2019 It could possibly ran out of VBlank time when trying to load both define data and alternate define data. I get that FF data loaded into GRAM slot if I attempt to load card. Possibly do a 'wait' to have fresh VBlank time before loading define and alternate define data. If I remembered, the starfield GRAM data is being redefine so that is interrupting your explosion call. 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 It could possibly ran out of VBlank time when trying to load both define data and alternate define data. I get that FF data loaded into GRAM slot if I attempt to load card. Possibly do a 'wait' to have fresh VBlank time before loading define and alternate define data. If I remembered, the starfield GRAM data is being redefine so that is interrupting your explosion call. I think it has to be something close to what you say. Maybe v140 has a heavier isr routine and I fall outside the vblank window... no idea actually, I'm still investigating Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 artrag: Is the ROM at $Fxxx paged? The code that loads the GRAM is reading the correct ROM address AFAICT, and it's reading $FFFF from that addreess: . _int_vector.vi3: 0006 3800 0000 A639 F47D 3800 02FA 6873 ----I-i- MVI@ R4,R1 184573305 0006 FFFF 0000 A639 F47E 3800 02FA 6874 ----I-i- MVO@ R1,R5 184573313 0006 FFFF 0000 A639 F47E 3801 02FA 6875 ----I--- SWAP R1 184573322 0006 FFFF 0000 A639 F47E 3801 02FA 6876 S---I--- MVO@ R1,R5 184573328 0006 FFFF 0000 A639 F47E 3802 02FA 6877 S---I--- MVI@ R4,R1 184573337 0006 FFFF 0000 A639 F47F 3802 02FA 6878 S---I-i- MVO@ R1,R5 184573345 0006 FFFF 0000 A639 F47F 3803 02FA 6879 S---I--- SWAP R1 184573354 0006 FFFF 0000 A639 F47F 3803 02FA 687A S---I--- MVO@ R1,R5 184573360 0006 FFFF 0000 A639 F47F 3804 02FA 687B S---I--- MVI@ R4,R1 184573369 0006 FFFF 0000 A639 F480 3804 02FA 687C S---I-i- MVO@ R1,R5 184573377 0006 FFFF 0000 A639 F480 3805 02FA 687D S---I--- SWAP R1 184573386 0006 FFFF 0000 A639 F480 3805 02FA 687E S---I--- MVO@ R1,R5 184573392 0006 FFFF 0000 A639 F480 3806 02FA 687F S---I--- MVI@ R4,R1 184573401 0006 FFFF 0000 A639 F481 3806 02FA 6880 S---I-i- MVO@ R1,R5 184573409 0006 FFFF 0000 A639 F481 3807 02FA 6881 S---I--- SWAP R1 184573418 0006 FFFF 0000 A639 F481 3807 02FA 6882 S---I--- MVO@ R1,R5 184573424 0006 FFFF 0000 A639 F481 3808 02FA 6883 S---I--- DECR R0 184573433 0005 FFFF 0000 A639 F481 3808 02FA 6884 ----I-i- BNEQ _int_vector.v 184573439 . I don't see any code in the disassembly that manipulates the page at $Fxxx, but I do see $Cxxx, $Dxxx, and $Exxx: . 89056 ( 0.048%) | $A32F: 0378 0000 CMPI #$0000,R0 84526 ( 0.046%) | $A331: 0206 0031 BLE T245 ($A364) 77835 ( 0.042%) | $A333: 02B8 CA5C MVII #$CA5C,R0 105335 ( 0.057%) | $A335: 0240 CFFF MVO R0,$CFFF 75976 ( 0.041%) | $A337: 02B8 DA5C MVII #$DA5C,R0 104467 ( 0.057%) | $A339: 0240 DFFF MVO R0,$DFFF 75976 ( 0.041%) | $A33B: 02B8 EA5C MVII #$EA5C,R0 104467 ( 0.057%) | $A33D: 0240 EFFF MVO R0,$EFFF 123461 ( 0.067%) | $A33F: 0004 01A0 0369 JSR R5,label_PLAY_SOUND_PSG ($A369) 76892 ( 0.042%) | $A342: 02B8 CA5B MVII #$CA5B,R0 104467 ( 0.057%) | $A344: 0240 CFFF MVO R0,$CFFF 75976 ( 0.041%) | $A346: 02B8 DA5B MVII #$DA5B,R0 104467 ( 0.057%) | $A348: 0240 DFFF MVO R0,$DFFF 75976 ( 0.041%) | $A34A: 02B8 EA5B MVII #$EA5B,R0 104569 ( 0.057%) | $A34C: 0240 EFFF MVO R0,$EFFF 123461 ( 0.067%) | $A34E: 0004 01A4 005D JSR R5,label_PLAY_SOUND_ECS ($A45D) 99023 ( 0.054%) | $A351: 0280 017C MVI var_PALCOUNT ($017C),R0 58362 ( 0.032%) | $A353: 0010 DECR R0 106084 ( 0.057%) | $A354: 0240 017C MVO R0,var_PALCOUNT ($017C) 75976 ( 0.041%) | $A356: 02B8 CA5F MVII #$CA5F,R0 117937 ( 0.064%) | $A358: 0240 CFFF MVO R0,$CFFF 75976 ( 0.041%) | $A35A: 02B8 DA5F MVII #$DA5F,R0 167338 ( 0.091%) | $A35C: 0240 DFFF MVO R0,$DFFF 75976 ( 0.041%) | $A35E: 02B8 EA5F MVII #$EA5F,R0 107260 ( 0.058%) | $A360: 0240 EFFF MVO R0,$EFFF 85473 ( 0.046%) | $A362: 0200 0004 B T244 ($A368) . In previous code you've shown me, C/D/E/F were paged. In this disassembly, only C/D/E are paged. Even if you're not dynamically switching $Fxxx at runtime now, you still need to poke $FFFF with $FA5x to flip in that page if it's marked as paged, where x is the page number. Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 Page F is not used. I'm testing the game in PAL mode, if it is a timing thing, it should disappear, because the Vblank window is larger... I'll let you know Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 Page F is not used. I'm testing the game in PAL mode, if it is a timing thing, it should disappear, because the Vblank window is larger... I'll let you know It isn't a timing issue, as in PAL mode I get the very same problem. It has to be something else.... :-( Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 3, 2019 Share Posted March 3, 2019 It isn't a timing issue, as in PAL mode I get the very same problem. It has to be something else.... :-( It could still be a timing issue manifested differently. It is not an overrun of VBLANK because when the window ends, writing to GRAM fails; it wouldn't result in filling GRAM with $FF. Like intvnut said: The code that loads the GRAM is reading the correct ROM address AFAICT, and it's reading $FFFF from that addreess: *emphasis mine. Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 artrag: Is the ROM at $Fxxx paged? The code that loads the GRAM is reading the correct ROM address AFAICT, and it's reading $FFFF from that addreess: . _int_vector.vi3: 0006 3800 0000 A639 F47D 3800 02FA 6873 ----I-i- MVI@ R4,R1 184573305 0006 FFFF 0000 A639 F47E 3800 02FA 6874 ----I-i- MVO@ R1,R5 184573313 0006 FFFF 0000 A639 F47E 3801 02FA 6875 ----I--- SWAP R1 184573322 0006 FFFF 0000 A639 F47E 3801 02FA 6876 S---I--- MVO@ R1,R5 184573328 0006 FFFF 0000 A639 F47E 3802 02FA 6877 S---I--- MVI@ R4,R1 184573337 0006 FFFF 0000 A639 F47F 3802 02FA 6878 S---I-i- MVO@ R1,R5 184573345 0006 FFFF 0000 A639 F47F 3803 02FA 6879 S---I--- SWAP R1 184573354 0006 FFFF 0000 A639 F47F 3803 02FA 687A S---I--- MVO@ R1,R5 184573360 0006 FFFF 0000 A639 F47F 3804 02FA 687B S---I--- MVI@ R4,R1 184573369 0006 FFFF 0000 A639 F480 3804 02FA 687C S---I-i- MVO@ R1,R5 184573377 0006 FFFF 0000 A639 F480 3805 02FA 687D S---I--- SWAP R1 184573386 0006 FFFF 0000 A639 F480 3805 02FA 687E S---I--- MVO@ R1,R5 184573392 0006 FFFF 0000 A639 F480 3806 02FA 687F S---I--- MVI@ R4,R1 184573401 0006 FFFF 0000 A639 F481 3806 02FA 6880 S---I-i- MVO@ R1,R5 184573409 0006 FFFF 0000 A639 F481 3807 02FA 6881 S---I--- SWAP R1 184573418 0006 FFFF 0000 A639 F481 3807 02FA 6882 S---I--- MVO@ R1,R5 184573424 0006 FFFF 0000 A639 F481 3808 02FA 6883 S---I--- DECR R0 184573433 0005 FFFF 0000 A639 F481 3808 02FA 6884 ----I-i- BNEQ _int_vector.v 184573439 . I don't see any code in the disassembly that manipulates the page at $Fxxx, but I do see $Cxxx, $Dxxx, and $Exxx: . 89056 ( 0.048%) | $A32F: 0378 0000 CMPI #$0000,R0 84526 ( 0.046%) | $A331: 0206 0031 BLE T245 ($A364) 77835 ( 0.042%) | $A333: 02B8 CA5C MVII #$CA5C,R0 105335 ( 0.057%) | $A335: 0240 CFFF MVO R0,$CFFF 75976 ( 0.041%) | $A337: 02B8 DA5C MVII #$DA5C,R0 104467 ( 0.057%) | $A339: 0240 DFFF MVO R0,$DFFF 75976 ( 0.041%) | $A33B: 02B8 EA5C MVII #$EA5C,R0 104467 ( 0.057%) | $A33D: 0240 EFFF MVO R0,$EFFF 123461 ( 0.067%) | $A33F: 0004 01A0 0369 JSR R5,label_PLAY_SOUND_PSG ($A369) 76892 ( 0.042%) | $A342: 02B8 CA5B MVII #$CA5B,R0 104467 ( 0.057%) | $A344: 0240 CFFF MVO R0,$CFFF 75976 ( 0.041%) | $A346: 02B8 DA5B MVII #$DA5B,R0 104467 ( 0.057%) | $A348: 0240 DFFF MVO R0,$DFFF 75976 ( 0.041%) | $A34A: 02B8 EA5B MVII #$EA5B,R0 104569 ( 0.057%) | $A34C: 0240 EFFF MVO R0,$EFFF 123461 ( 0.067%) | $A34E: 0004 01A4 005D JSR R5,label_PLAY_SOUND_ECS ($A45D) 99023 ( 0.054%) | $A351: 0280 017C MVI var_PALCOUNT ($017C),R0 58362 ( 0.032%) | $A353: 0010 DECR R0 106084 ( 0.057%) | $A354: 0240 017C MVO R0,var_PALCOUNT ($017C) 75976 ( 0.041%) | $A356: 02B8 CA5F MVII #$CA5F,R0 117937 ( 0.064%) | $A358: 0240 CFFF MVO R0,$CFFF 75976 ( 0.041%) | $A35A: 02B8 DA5F MVII #$DA5F,R0 167338 ( 0.091%) | $A35C: 0240 DFFF MVO R0,$DFFF 75976 ( 0.041%) | $A35E: 02B8 EA5F MVII #$EA5F,R0 107260 ( 0.058%) | $A360: 0240 EFFF MVO R0,$EFFF 85473 ( 0.046%) | $A362: 0200 0004 B T244 ($A368) . In previous code you've shown me, C/D/E/F were paged. In this disassembly, only C/D/E are paged. Even if you're not dynamically switching $Fxxx at runtime now, you still need to poke $FFFF with $FA5x to flip in that page if it's marked as paged, where x is the page number. I think you could be right, my boss data fall in FXXXh going to try.... Quote Link to comment Share on other sites More sharing options...
artrag Posted March 3, 2019 Share Posted March 3, 2019 EUREKA! Adding POKE $FFFF, $FA5F at the beginning solves the issue. The page where data are wasn't set properly. This because the initialization sequence in v129 was in the prologue, while in v140 it is in basic and it was incomplete. Anyway, the problem was in the custom prologue to support paged data and code. Thanks to everyone 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 3, 2019 Share Posted March 3, 2019 To be clear, artrag is referring to the doctored intybasic_prologue/epilogue I made for him to support paging. I had included an additional initialization step in the 1.2.9 version that I had omitted from the 1.4.0 version. I thought we'd added the explicit initialization step inside the BASIC source, but I suspected the flip for $FFFF had gone missing, as it appeared from the disassembly that the sound code no longer flipped $FFFF either. :-) Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 4, 2019 Author Share Posted March 4, 2019 Glad it could be found! Quote Link to comment Share on other sites More sharing options...
DZ-Jay Posted March 4, 2019 Share Posted March 4, 2019 Great job, guys! :thumbsup: Quote Link to comment Share on other sites More sharing options...
bikeguychicago Posted March 4, 2019 Share Posted March 4, 2019 (edited) All, I am trying to get started with Oscar's book. I've completed all of the setup instructions in chapter 2, typed in the Hello World program and compiled it. When I try to run it, Jzintv comes up but on-screen all I see are a quick flash from a pink background to a green one and, finally to a black one. No text is displayed. I am running on a 2018 MacBook Pro with macos 10.14.3 I am using IntyBasic 1.4 and the latest Jzintv from 12.25.18. The SDL runtime I am using (2.2.0.9) is from here: https://www.libsdl.org/download-2.0.php If anyone can provide some assistance on what I might be doing wrong, please let me know. Thanks! Edited March 4, 2019 by bikeguychicago Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 5, 2019 Author Share Posted March 5, 2019 All, I am trying to get started with Oscar's book. I've completed all of the setup instructions in chapter 2, typed in the Hello World program and compiled it. When I try to run it, Jzintv comes up but on-screen all I see are a quick flash from a pink background to a green one and, finally to a black one. No text is displayed. I am running on a 2018 MacBook Pro with macos 10.14.3 I am using IntyBasic 1.4 and the latest Jzintv from 12.25.18. The SDL runtime I am using (2.2.0.9) is from here: https://www.libsdl.org/download-2.0.php If anyone can provide some assistance on what I might be doing wrong, please let me know. Thanks! A screenshot of your command line of Intybasic execution, the as1600 command and jzintv command line before pressing Enter would help me a lot. Quote Link to comment Share on other sites More sharing options...
bikeguychicago Posted March 5, 2019 Share Posted March 5, 2019 A screenshot of your command line of Intybasic execution, the as1600 command and jzintv command line before pressing Enter would help me a lot. The screenshots are below. - Intvbasic command line: - as1600 command line: - jzintv command line: And the jzintv window after executing the above: Quote Link to comment Share on other sites More sharing options...
+nanochess Posted March 5, 2019 Author Share Posted March 5, 2019 Thanks! I think you need to install the following: http://libsdl.org/download-1.2.php Download the library and put it into /Library/Frameworks (same as libSDL2, just reminded jzintv doesn't use libsdl2 but libsdl) (BTW, just noticed I didn't put that step in the book... too late) Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 5, 2019 Share Posted March 5, 2019 Thanks! I think you need to install the following: http://libsdl.org/download-1.2.php Download the library and put it into /Library/Frameworks (same as libSDL2, just reminded jzintv doesn't use libsdl2 but libsdl) FWIW, jzIntv won't even start if SDL 1.2 isn't already installed. So, if you had a previous SDL 1.2 installed and just happened to install SDL2 next to it, the SDL2 will have no effect. - jzintv command line: It there a chance you can show all of jzIntv's output? Either make the window taller and screen-shot that, or just copy/paste it into a code block here. I'm curious whether it's actually picking up "hello" in the current directory, or some other ROM named "hello" elsewhere. Also, are you able to run known-good ROMs? What EXEC/GROM images are you using? I believe the "IntyBASIC SDK" comes with the minigrom/miniexec, which may only work for IntyBASIC programs at this point. If jzIntv is picking up some other "hello" program somewhere, then that's a possible reason you're seeing blank screen. If you enable jzIntv's debugger, can you see where it gets stuck? Issue the following commands to the debugger: . h r . The h turns on register history, and r runs the program. Once it hangs, press ⌘C to interrupt and get the debugger prompt. Type ! and hit enter, and it'll show you the last 100 instructions that ran. A screen cap (or copy paste into a code block here) might be helpful as well. 1 Quote Link to comment Share on other sites More sharing options...
+nanochess Posted May 18, 2019 Author Share Posted May 18, 2019 Found and solved a bug in intybasic_epilogue.asm it made ECS music player to crash if there was a drum in the ECS section of MUSIC statement. https://github.com/nanochess/IntyBASIC/commit/662e406c22411e6a1e5896c05f75317242368066 4 Quote Link to comment Share on other sites More sharing options...
PlanetJanus Posted May 28, 2019 Share Posted May 28, 2019 All of you amaze me. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted June 12, 2019 Author Share Posted June 12, 2019 Update to version 1.4.1, check first post. Changes, enhancements and fixes in v1.4.1: o Added BITMAP NORMAL, BITMAP INVERSE and BITMAP MIRROR_X to ease reusing BITMAP statements in Color Stack mode. o Optimizes POKE to direct address with a single MVO. o Solved bug in local labels preceded with comma, it required a space. o Solved bug compiling nn = (varptr sfx2_v(0)-varptr sfx2_n(0))-sfxstep o Solved bug in MUSIC.PLAYING (relative to new music format) o Solved bug in music player because new _ntsc interpretation. o Solved crash bug in drums for ECS side of music player. 4 1 Quote Link to comment Share on other sites More sharing options...
Zendocon Posted June 27, 2019 Share Posted June 27, 2019 Is there a sample somewhere of how to use the IntyBASIC music tracker with the ECS sound channels enabled? I didn't see any updates in the documentation for the appropriate syntax. Also, if the ECS is not present, does the music still play and just skip over the ECS channels? Quote Link to comment Share on other sites More sharing options...
+nanochess Posted June 27, 2019 Author Share Posted June 27, 2019 2 hours ago, Zendocon said: Is there a sample somewhere of how to use the IntyBASIC music tracker with the ECS sound channels enabled? I didn't see any updates in the documentation for the appropriate syntax. Also, if the ECS is not present, does the music still play and just skip over the ECS channels? Yes, if the ECS is not present, the tracker still writes to the ports but as no hardware is present then no extra sound is generated. I've include some notes in the manual, but I think now that probably I wasn't clear enough. The MUSIC statement now allows 8 arguments. Notice that once you use the 8 arguments, it activates the ECS tracker because internally now it always will read 8 bytes of music notes (4 words). So make sure you start your MUSIC statements with 8 arguments, to avoid an internal mix (crash) of different song formats. DATA 14 MUSIC C,D,E,-,F,G,A,- MUSIC STOP The 4 arguments use the same syntax as the left arguments, there are 3 notes and one drum. Here is a sample using the extended syntax of the tracker with a long song. (MUSIC GOSUB and MUSIC RETURN help to reduce the music memory usage, MUSIC SPEED allows to change tempo in the fly, and MUSIC_VOLUME helps to fade off the music at end) I've uploaded an example I've made 1 Quote Link to comment Share on other sites More sharing options...
Zendocon Posted June 27, 2019 Share Posted June 27, 2019 Very good. I thought that's how it would work. Thank you very much. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.