intvnut Posted October 27, 2015 Share Posted October 27, 2015 (edited) I suppose I was using an old version of jzintv. So far everyone can change in intybasic_prologue.asm the 415 to 520 as suggested by intvnut. Also, I failed to note this: You also have to invert the sense of the branch that follows: CMPI #520,R2 ; <- new threshold MVII #1,R0 BLE _MAIN3 ; <- was BGE, now is BLE CLRR R0 _MAIN3: MVO R0,_ntsc What's weird is that I specifically used the --pal flag and the NTSC value to calibrate timing in Desert Bus, and it worked flawlessly. Down to within about 3 seconds when simulated out to 8 hours! Now I'm really confused... the timing code came from an example by intvnut, but I can't see you taking into account IntyBASIC's "minor issue". Weird. It's entirely possible I was still updating the display at 60Hz... Did you try an animation test? :-) I seem to recall my early --pal support was basically junk. Edited October 27, 2015 by intvnut Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 29, 2015 Share Posted October 29, 2015 It's entirely possible I was still updating the display at 60Hz... Did you try an animation test? :-) I seem to recall my early --pal support was basically junk. It's been a while. What I do remember is that I set up the timing, benchmarked it to an 8 hour run, and then set --pal. And it was all messed up (faster or slower, I can't even remember that much). I then added the IntyBASIC check for NTSC, adjusted my timing accordingly, and it worked like a charm with --pal. If you remember: it was a dead-simple counter that just checks the FRAME count, and if it goes over 50/60 (as appropriate), increments the number of seconds. Like I said, it was dead accurate over 8 hours so it at least adjusted for the CPU speed properly. I really should test this out with the current IntyBASIC and the year-old version I first wrote it in, that may help Oscar. Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 29, 2015 Share Posted October 29, 2015 If you remember: it was a dead-simple counter that just checks the FRAME count, and if it goes over 50/60 (as appropriate), increments the number of seconds. Like I said, it was dead accurate over 8 hours so it at least adjusted for the CPU speed properly. Or at least the refresh rate. I believe for awhile I had had the NTSC CPU clock rate for both, and just changed the refresh interval. Or something. All I know is that the PAL numbers were jacked up in the older versions. Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 29, 2015 Share Posted October 29, 2015 Or at least the refresh rate. I believe for awhile I had had the NTSC CPU clock rate for both, and just changed the refresh interval. Or something. All I know is that the PAL numbers were jacked up in the older versions. Oh. Riiiiiiight. I always assume that the CPU and the refresh rate are tied together, but I guess that's not necessarily the case. Which means audio is an open question. I'll run a bunch of tests next time I'm stationary for a bit. There are a surprising (to me) number of PAL users here; I'd hate to see homebrew that isn't inclusive. Quote Link to comment Share on other sites More sharing options...
intvnut Posted October 29, 2015 Share Posted October 29, 2015 Oh. Riiiiiiight. I always assume that the CPU and the refresh rate are tied together, but I guess that's not necessarily the case. Which means audio is an open question. I'll run a bunch of tests next time I'm stationary for a bit. There are a surprising (to me) number of PAL users here; I'd hate to see homebrew that isn't inclusive. Just to confuse things worse: in jzIntv, I can control the CPU MHz, PSG MHz and refresh rate separately. I think I was getting 2 of the 3 correct. The only real way you'd notice the CPU MHz was wrong was with a timing loop such as what IntyBASIC uses. What really boggles me is that the timing loop that's there expects fewer iterations for PAL than for NTSC, but every aspect of the PAL system would give you more iterations. The slower refresh interval gives you more time between interrupts (which means more iterations). The faster CPU gives you more iterations per second regardless of the refresh interval. Anyway, find your old version of Desert Bus that you timed for 8 hours on jzintv --pal and let's look at it. We can even look at a disassembly if needed, or at least use jzIntv's debugger to watch it in action. Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 29, 2015 Share Posted October 29, 2015 OK no, the problem is IntyBASIC. I just compiled with 1.1, and it detects PAL just fine. 1.2.4, seems to not notice it. Obviously something changed, I'll see if my feeble brain can find it. The section in the prologue is identical, but something has to have changed somewhere. Is it maybe just not checking for the NTSC const properly? In fact, how DOES this magic actually work?: IF NTSC = 1 THEN print at 0,"ntsc" ELSE print at 1,"pal" I'm never defining NTSC anywhere. I assume the compiler has it hard-coded; maybe that part got commented out. Here are the ROM, ASM, and LST files from 1.1 and 1.2.4. I'm literally doing nothing but calling the above line in an infinite loop. I ran a diff between the .asm files, and I see absolutely nothing that clues me in. The vast majority of the changes are in bug fixes in the math routines, and JLP support. So I'm way out of my depth. Maybe you guys can figure this out. pal_test_111_vs_124.zip Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 30, 2015 Share Posted October 30, 2015 And I'm finally understanding more about how each PSG register is being used. Oscar, I think you have a typo: SOUND 4,[NOISE 6 bits],[MIX] Noise and mix register ($38 value by default) According to the PSG documentation that I can find, there are only 5 bits on that register. Which my testing seems to confirm - once I go over 31, it seems to wrap back 0. I also want to figure out a better way to explain how the MIX register works. We may need a lookup table because active-low tends to be confusing to people: $38 turns on all 3 tones, and disables all noise. $7 would be just noise. $0 turns on noise AND tones for all 3 channels. $63 means complete silence for all 3. And every mix in between. Or better yet, change how the syntax works. Maybe something like SOUND 0,value,volume,mix, where mix is 0=silence, 1=tone, 2=noise, 3=both? To me it makes more sense to control the mixer on a per-channel basis like this. SOUND 4 would then just take a single (5-bit) value for noise. Thoughts? I'm only just starting to figure out how the envelope generator works, but I'll get there. Already coming up with some trippy stuff. 1 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted October 30, 2015 Share Posted October 30, 2015 According to the PSG documentation that I can find, there are only 5 bits on that register. Which my testing seems to confirm - once I go over 31, it seems to wrap back 0. Yep! Noise is a 5 bit register and common to all channels. $63 means complete silence for all 3. Its $3F for silence on tones and noise for all 3. Even the "Your friend the EXEC" manual gets that wrong . Bits 6 and 7 have to be zero or you'll stop the controllers from working. I'm only just starting to figure out how the envelope generator works, but I'll get there. Already coming up with some trippy stuff. You can get even more interesting results by modulating the channel volume. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted October 30, 2015 Share Posted October 30, 2015 You can get even more interesting results by modulating the channel volume. I agree, especially because it allows you to control the envelope for each channel individually. That said, I do like that the built-in envelope generator can serve as a sort of LFO amplitude modulator with various waveforms. Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 30, 2015 Share Posted October 30, 2015 Its $3F for silence on tones and noise for all 3. Even the "Your friend the EXEC" manual gets that wrong . Bits 6 and 7 have to be zero or you'll stop the controllers from working. I have absolutely no idea where $63 came from. However yes, it would disable one of the controller ports. Whoops! Quote Link to comment Share on other sites More sharing options...
+nanochess Posted October 30, 2015 Author Share Posted October 30, 2015 And I'm finally understanding more about how each PSG register is being used. Oscar, I think you have a typo: SOUND 4,[NOISE 6 bits],[MIX] Noise and mix register ($38 value by default) According to the PSG documentation that I can find, there are only 5 bits on that register. Which my testing seems to confirm - once I go over 31, it seems to wrap back 0. I also want to figure out a better way to explain how the MIX register works. We may need a lookup table because active-low tends to be confusing to people: $38 turns on all 3 tones, and disables all noise. $7 would be just noise. $0 turns on noise AND tones for all 3 channels. $63 means complete silence for all 3. And every mix in between. Or better yet, change how the syntax works. Maybe something like SOUND 0,value,volume,mix, where mix is 0=silence, 1=tone, 2=noise, 3=both? To me it makes more sense to control the mixer on a per-channel basis like this. SOUND 4 would then just take a single (5-bit) value for noise. Thoughts? I'm only just starting to figure out how the envelope generator works, but I'll get there. Already coming up with some trippy stuff. Thanks for the report, I'll correct it. BTW, I'm sure you're meaning $3F instead of $63 Quote Link to comment Share on other sites More sharing options...
carlsson Posted October 30, 2015 Share Posted October 30, 2015 Apparently he converted hexadecimal to decimal but forgot to remove the dollar, as $3F = decimal 63. 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted October 30, 2015 Share Posted October 30, 2015 Apparently he converted hexadecimal to decimal but forgot to remove the dollar, as $3F = decimal 63. That is amazing if so - I don't usually make that kind of mistake. The only time my brain sees decimal values of registers is when I output them to the screen, which I definitely wasn't doing here. I'm atrocious at doing hex <-> dec in my head, so I generally just stick to hex and binary values for things. Maybe my subconscious is smarter than I think (but still not quite smart enough). Quote Link to comment Share on other sites More sharing options...
artrag Posted November 1, 2015 Share Posted November 1, 2015 (edited) Is there any technical document about how to code the intellivoice? It would be nice having commands in intybasic to fully control intellivoice e.g. with custom samples. Edited November 1, 2015 by artrag Quote Link to comment Share on other sites More sharing options...
freewheel Posted November 1, 2015 Share Posted November 1, 2015 Is there any technical document about how to code the intellivoice? It would be nice having command in intybasic to fully control intellivoice e.g. with custom samples. This is a very large can of worms There are the basic voice samples that you can easily use in IntyBASIC, of course. Custom samples need to be encoded very specifically to work with the Intellivoice. Information on how to do it is out there, sort of. But it's non-trivial. You'd also have to add your voice data to intybasic_epilogue.asm, but that's reasonably easy: _OY: DECLE _OY.end - _OY - 1 DECLE $0310, $014C, $016E, $02A6, $03AF, $00CF, $0304, $0192 DECLE $03CA, $01A8, $007F, $0155, $02B4, $027F, $00E2, $036A DECLE $031F, $035D, $0116, $01D5, $02F4, $025F, $033A, $038A DECLE $014F, $01B5, $03D5, $0297, $02DA, $03F2, $0167, $0124 DECLE $03FB, $0001 _OY.end: ; 34 decles Just define your sound/word, and insert the voice data with a unique label, and it should work? At least *some* people have tools to help with this - I believe the Elektronite guys have an encoding program. But they don't tend to put their tools out there for just anyone to use. And the encoding is the (very) hard part. Quote Link to comment Share on other sites More sharing options...
artrag Posted November 1, 2015 Share Posted November 1, 2015 Where do I find docs on what the data are? They should be the 12 coefficients of a linear filter. Usually in this kind of systems you can also specify the pulse in input. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted November 1, 2015 Share Posted November 1, 2015 Where do I find docs on what the data are? They should be the 12 coefficients of a linear filter. Usually in this kind of systems you can also specify the pulse in input. The technical specs and information on instruction set and usage are available in the SDK-1600 distro that includes jzIntv. Quote Link to comment Share on other sites More sharing options...
Carl Mueller Jr Posted January 7, 2016 Share Posted January 7, 2016 IntyBASIC SDK v1.2 coming real soon! Did this ever materialize? I can't seem to find the link to any version of the SDK. Carl Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted January 7, 2016 Share Posted January 7, 2016 Did this ever materialize? I can't seem to find the link to any version of the SDK. Carl http://atariage.com/forums/topic/240526-introducing-the-intybasic-sdk Version 1.1 is in the first post, 1.2 hasn't come out yet Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted January 7, 2016 Share Posted January 7, 2016 http://atariage.com/forums/topic/240526-introducing-the-intybasic-sdk Version 1.1 is in the first post, 1.2 hasn't come out yet Also the newest IntyBASIC (1.2.4 as of today) is in the first post of this thread. You can manually update the IntyBASIC files from 1.2.4 into the appropriate places after you install the SDK. Quote Link to comment Share on other sites More sharing options...
+nanochess Posted February 16, 2016 Author Share Posted February 16, 2016 I've stopped development of IntyBASIC for more or less 3 months but now finally I've restarted with some "minor" modifications that will shape IntyBASIC at large: New in version 1.2.5: Added UNSIGNED statement, allows to make unsigned comparisons (useful for larger than 16-bits values) Added PLAY VOLUME statement (do you want to make music softer?) Added NO DRUMS syntax to PLAY (allows to use noise channel for explosions) Added MUSIC JUMP statement (allows to have an intro in music and a looping part) Added MUSIC.PLAYING expression (allows to exit when music has finished playing) Added CALL statement (like USR but outside expressions so you don't need a variable) DATA allows for string literal (for text programs) DO statement followed by colon now isn't taken as label. Corrected bug in PAL detection. Updated constants.bas (corrections and new constants for Coloured Squares mode) and keypad.bas sample. Added contrib/ColouredSquares.bas a sample of drawing lines in Coloured Squares mode by GroovyBee. Added samples/bats.bas (animated bats) Added samples/envelope.bas (using envelope sounds) Enjoy it! (see first post) 5 Quote Link to comment Share on other sites More sharing options...
GroovyBee Posted February 16, 2016 Share Posted February 16, 2016 You can add this to the next release too. 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted February 18, 2016 Share Posted February 18, 2016 Ooooooo, several things I've been dying to see working. Just in time, my friend! 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted March 13, 2016 Share Posted March 13, 2016 Finally getting around to looking at MUSIC JUMP. I imagine it's used for this: PLAY intro_label intro_label: MUSIC A3,-,-,- more notes main_music: MUSIC C3,-,-,- more notes MUSIC JUMP main_music So that you can have an intro, then loop the body of the music. And I assume that MUSIC REPEAT serves no purpose here, because you'll forever loop due to the JUMP statement..? How possible would it be to have something like MUSIC JUMP, but a bit more selective? Like this: PLAY song_label song_label: MUSIC A3,-,-,- more notes MUSIC LOOP song_label,2 'rest of the music goes here MUSIC C3,-,-,- more notes So that I could loop over the first section twice, then continue on with the rest. Ideally allowing a counter for how many times to loop. Right now I just duplicate a lot of MUSIC statements to accomplish this, which isn't a big deal given the available ROM size, but still. Can something like this be done? 3 Quote Link to comment Share on other sites More sharing options...
freewheel Posted March 21, 2016 Share Posted March 21, 2016 I think this is a bug in the manual, in the area discussing PRINT: For Foreground/Background mode, use $0000-$0007, and $0200 is bit 0 of background color, $0400 is bit 1 of background color, $1000 is bit 2 of background color and $2000 is bit 3 of background color. (check MODE statement below) I think bit 2 and bit 3 are reversed here. Both from what I know, plus explicit testing. I had this backwards at some point too, so I wonder if there's a STIC guide out there with the wrong register details. 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.