DZ-Jay

@KEslinger, I've updated the IntyBASIC SDK with the latest version of jzIntv and IntyBASIC, and it now includes the "miniecs.bin" @intvnut suggested. You can include the command line "-s1" when invoking "INTYRUN" to enable the ECS. You can find this version on the first post of the IntyBASIC SDK thread. -dZ.

Just in time for the programming contest, I've updated the IntyBASIC SDK to include the latest, bleeding edge IntyBASIC and development tools -- fresh off the oven! https://atariage.com/forums/topic/240526-introducing-the-intybasic-sdk/ This version includes a new "miniecs.bin" and the tools have been updated to include it automatically when loading the emulator, so you can run your ECS-enabled IntyBASIC. -dZ.

Just in time for the programming contest, I've updated the IntyBASIC SDK to include the latest, bleeding edge IntyBASIC and development tools -- fresh off the oven! https://atariage.com/forums/topic/240526-introducing-the-intybasic-sdk/ This version includes a new "miniecs.bin" and the tools have been updated to include it automatically when loading the emulator, so you can run your ECS-enabled IntyBASIC. -dZ.

Just in time for the IntyBASIC programming contest ... I've just updated the first post with the latest version of the SDK. This release includes the latest version of IntyBASIC (v1.4.2) and the emulator (2020-08-22), fresh off the oven! Both Windows and Mac OS X have been updated, respectively. https://atariage.com/forums/topic/240526-introducing-the-intybasic-sdk/ Enjoy -dZ.

Damn, just when I thought I quit. 😡 *sigh* Updated IntyBASIC SDK coming out this week-end in time for the contest ... Really, the things you make me do. :P -dZ.

Wow, that's an ancient page. The ROM there was the original "demo" created back in 2010 with a single screen. You may want to get the full released version here: http://www.carolvsghost.com/getrom

So ... does this mean that the ROM file does not work on the hardware?

By the way, the above is written from my memory working on Arnauld's tracker, but it's been a few years so some of the descriptions of the inner workings would be wrong. -dZ.

I just caught up with this thread (it's been in my reading list for while), so pardon the belated response. Arnauld's tracker is modelled after old-school microcomputer music software, like Fast Tracker, etc., in that it treats the musical score as a sequence of patterns, and each pattern is comprised of a set of events (i.e., tracker frames) occurring at periodic times. This is similar to how "MIDI" format songs work. The main difference between "MIDI" and "MOD" (i.e., module) trackers like Fast Tracker and Arnauld's, is that they also define a set of instruments. In the case of classic modules, these were PCM samples; on the Intellivision, we use the PSG to synthesize the instruments. There are two kinds of instruments supported in the Intellivision Music Tracker: musical and drums. The distinction is made mostly because the former relies on pitch and amplitude modulation, and plays at discrete semi-tones on the chromatic scale; while the latter are treated more like sound effects, where you can assign arbitrary frequencies, mix in noise, and control the parameters of each on each tracker frame. MUSICAL INSTRUMENTS: Musical instruments are a combination of an envelope, and pitch and volume modulation parameters. Envelope: Instead of using the common 4-stage "ADSR" envelope, the tracker offers a 64-point description of the volume changes over time. Each point represents the volume assigned to a sound channel at a given frame in the length of a note. You can visualize it as a graph of the changes in volume over time, for instance: ATTACK DECAY SUSTAIN RELEASE .--------|---------------------|-------------------------------------------------------|---------------------------------------| F -|. . . . # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E -|. . . . # # # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D -|. . . . # . . # # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C -|. . . . # . . . . # # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B -|. . . # . . . . . . . # # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . V A -|. . . # . . . . . . . . . # # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . O 9 -|. . . # . . . . . . . . . . . # # # # # # # # # # # # # # # # # # # # # # # # # # # # # . . . . . . . . . . . . . . . . . . . . L 8 -|. . . # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # . . . . . . . . . . . . . . . . . . . . U 7 -|. . # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # . . . . . . . . . . . . . . . . . . . M 6 -|. . # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # . . . . . . . . . . . . . . . . . . . E 5 -|. . # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # . . . . . . . . . . . . . . . . . . 4 -|. . # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # . . . . . . . . . . . . . . . . . 3 -|. # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # # . . . . . . . . . . . . . . . 2 -|. # . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # # # . . . . . . . . . . . . 1 -|# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . # # # # # . . . . . . . 0 `+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+-------+------ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 3 7 B F E E D D C C B B A A 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 7 5 4 3 3 2 2 2 1 1 1 1 1 0 0 0 0 0 0 0 The speed of the envelope can be controlled by configuring the number of points to process per frame. You can select from 1 (every frame) to 4 (every fourth frame); essentially quantizing the envelope at various sampling rates. Pitch Effects: This is a four-step "arpeggiator," essentially functioning as a cheap LFO. You can define the shape of the LFO by selecting how many half-tones to go up and down on each step. These changes are then applied throughout the length of a note at the machine's display rate (e.g., NTSC=60Hz). This is typically used for tremolo effect. It can also be used for fast arpeggios, like is done in many 8-bit machines, although it's a bit limited with only 4 steps. Vibrato: The vibrato offers only a single parameter, letting you select the amplitude of the effect's modulation relative to the playback volume of the channel. You can choose from no vibrato, high (+/- 1 amplitude), medium (+/- 1/2 amplitude), and low (+/- 1/4 amplitude). The vibrato is also applied at the machine's display rate throughout the length of a note, although it runs through 8 steps, in a pseudo-triangle shape. It turns out that these simple configurations, which simplify the implementation greatly, afford an exceedingly impressive amount of expression in the way the instruments are synthesized. --- If I were to change anything on Arnauld's tracker, it would be support for more complex shaping of the modulation effects. I like being able to "draw" the envelope of a note as a graph, which is how we always visualized ADSR in the past anyway. I always wished I could do the same for arpeggios and vibrato. To simplify usage, these could all be abstracted with a set of macros, where you could give a set of parameters (ADSR values perhaps?) to each ones and pre-calculating the values table from that. This would allow you to shape the tremolo and vibrato with another envelope, following the common "patching" paths used in old analog synths. Another feature I would add would be to parametized the frequency of the modulation, rather than having it always play at the same speed. To be honest, much of the complexity in using Arnauld's tracker lies in understanding the song data format. However, this could be abstracted with even more macros (or converted from other song formats) to simplify the interface. Yes. The way that the Intellivision Music Tracker handles this is by using a look-up table of pre-calculated amplitude values for modulation, tuned to each semi-tone (actually 30% of each semi-tone). This follows the way that instruments sound in real life. For what it's worth, that's similar to the way Arnauld devised his vibrato effect: the amplitude change per semi-tone is pre-calculated in a table to be ~30% of the note's pitch, then that value is scaled in a ramp to 1/4, 1/2, and 1/1, then back down again, to shape the modulation. --- All that said, there's yet another option you may want to explore, and it's the way some modern(ish) 8-bit music trackers for chiptunes have been implemented. Take a look at one called GoatTracker. On its surface, it appears to be absurdly strange and complicated, but upon deeper inspection, it is basically the same as the other "event-based" trackers, except that it's fully programmable using a specialized "scripting language." Basically, similar to Arnauld's tracker, each channel is given a series of "note events" specifying the note, volume, instrument, and various other parameters. Then, in addition to that, you can specify on any event a call to a small "program" where you treat the sound device's parameters as variables, and can alter them directly over time, using counters, etc. to simulate LFOs. You can chain a few of these "programs," where one modulates the next, simulating the "patches" of an old school synths that alter the signal as it passes through various components. The beauty of this is that the "built-in" features themselves (envelopes, instruments, pitch/amplitude modulation, arpeggiators, etc.) are all implemented in this programmatic way, giving you full flexibility to alter them. It's a rather neat idea. I see it as a low-level virtual machine implementing the driver for each oscillator, with the tracker and instrument being a high-level application implemented on top of it. Once again, the complexity can be abstracted with a high-level interface (either programmatic or user), in a similar fashion to the way that a high-level language abstracts the low-level machine code. Anyway ... off to dream some more. -dZ.

I didn't think so, thanks. @daldude, can you confirm that you are trying with the BIN+CFG or with the ROM binary?

Wow! Thanks for that @Intymike, it confirms that the demo works on the hardware, irrespective of configuration. By the way, is that the BIN+CFG or the ROM? So there may be something wrong with @daldude's setup. I haven't used the LTO Flash!, so ... is there a special configuration you need to set for programs to run?

In the emulator it works. That's why @nanochess was able to record the video without the full six channel music. I know it works with and without the Intellivoice, because @Intymike tested that as part of our previous troubleshooting effort. He also tested with PAL/NTSC console and ECS, mix-and-match between them. I don't think he ever tested without the ECS, though. The main concern here is that we're bypassing the "cart.mac" bootstrapping sequence completely, and it tries to initialize the resources in a quick-and-dirty way. That was done for the "lock-out" feature @shazz and I worked on before. That's all still there, but commented out. So perhaps it'll just be wise to make a build using the "cart.mac" standard bootstrap, since there's no need to avoid it now. That would make the bootstrap more resilient, since we know that "cart.mac" plays well with all devices (although, honestly, I do not see anything that it does specially to handle the ECS apart from page-flipping the ROM away, which we do also). -dZ.

We're not using the ECS RAM for anything, only the PSGs. Still, I find it strange that the program crashes without the ECS since the worse that should happen is that it writes to the non-existent PSGs, which should just drop the memory writes. I thought it could be the Intellivision II/Coleco lock out "feature," but "cart.mac" sets up a valid cartridge header for us (even if we don't use it), so that shouldn't be it either. I think there may be an actual bug in the bootstrap, which is causing it to fail when the ECS is not present. I'll have to investigate this week-end. In any case, are you suggesting re-tracking the songs to sound good on 3 channels but still take advantage of 6? Alternatively, if you just re-track the songs as simpler renditions for 3 channels only, we could detect the ECS in the bootstrap sequence and change the songs table dynamically. We're sort of tight with ROM, but since we require an LTO Flash! to run on hardware, we could employ bank-switching. -dZ.

Are you using the ECS? The ECS is required. We bypass all standard bootstrapping, so no explicit check is performed at start up. I should enhance the program to report an error if the ECS is missing. dZ.

Well, I worked on the sequencing engine and the 6-channel tracker mostly, and on micro-optimizations in the rest. It's just that it's been 3 years. I can dig into it if necessary, if it would help. I just need to know what you are looking for.

In the "bin/rom" folder, along with the other ROMs.

If that image in your post is a screenshot indicative of the problem, then it seems that the logo shows up but the plasma does not. The logo is made up of MOBs (sprites), so that means that your emulator handles them correctly. It's been a while since I've looked at it, but I believe that the plasma is drawn in the background and animated via two mechanisms: The BACKTAB (the BACKground TABle) cells are modified periodically with new colors and custom character cards in GRAM (Graphics RAM). The GRAM (Graphics RAM) custom characters are re-defined periodically. I can't imagine why your emulator is not rendering the background, unless it does not support backgrounds using custom character cards from GRAM, or does not support the Color Stack mode. The orbs in both cases are implemented as MOBs (sprites), so I do not know why MOBs would show up in one part but not on another. In the case of the "Part 2" interstitial, they fiddle with the "priority" bit on the "A" register of the MOBs, to make them go in front and behind the logo. In the case of the rocket, the 8 MOBs are multiplexed at 30Hz across the orbs and the rocket exhaust. The stars in the background are animated using the same two techniques mentioned above: Cycling the GRAM cards through 8 different steps of a pixel shifted downwards, and updating the BACKTAB characters on every 8th step to "move" the character down. Could it be that the STIC emuation in Argon does not support these rapid changes? Those are essentially the same as the other interstitial, but with a different movement pattern. It's weird that one works but not the other. In general, I do not think so. I'll take a look at the code to see if there are any specific nuances that differ between them. The strange thing is that they do not seem to be related. The plasma uses mostly the background and GRAM, and those do not show up in Argon; while the interstitial and rocket sequences use MOBs, which do not show up in Argon. Then there's the case of the two very similar interstitial screens, where one works and the other doesn't. It should not make a difference. We do not touch the EXEC at all. As a matter of fact, we use less of the EXEC than most games: we intercept its bootstrap sequence much, much earlier than many others -- before the system is initialized and the cartridge header is read -- and take over from there. (I just tested the demo with the "miniExec" to be sure, and it still ran normally on jzIntv.) No worries. I'm sorry if the above is a bit vague, but most of the effects themselves were written by others, so I don't recall exactly what they are doing directly. That said, the ZIP archived attached includes the "listing" file generated by the assembler, which should help illustrate the code that is executing at each point. Let me know if I there is any more I can do to help you troubleshoot the problem. If you'd like, send me a PM to continue the discussion. -dZ.

I've updated the first post with a new ROM that fixes the Intellivoice crashing half-way through the demo. Big thanks go to @Intymike for not only reporting the issue, but for going out of his way to test many, many revisions in different hardware configurations until we finally solved the problem. This latest version includes the fixed drums, the fix to the Intellivoice crash, and a few more names added to the scroll-text segment. Enjoy! -dZ.

Thanks to @Intymike for helping me troubleshoot and test the demo ROM on real hardware, and for posting the video. I can finally hear the drums, and I see a few more names in the scroll-text. I'll update the first post with the latest version as soon as the mods give me access to edit it. Thank you all for watching! -dZ.

Hi, @bhall408, Could you describe what problem Argon is having with that effect? The plasma does GRAM cycling, meaning that it reloads a set of pictures in Graphics RAM on every frame. It's the most common and effective way to do graphics animations in the Intellivision. That's the heart of the effect. The plasma was pre-calculated, and multiple tables built with different cards and colors. The background cards are then updated to "move" the plasma around, while the pictures themselves are changed to give different "levels" of density. -dZ.

Oh nooooooo! Not at all. The music is supposed to continue seamlessly, but there is underneath a change in the engine state to start a new visual effects sequence. Check out the AVI attached to the first post to see how it's supposed to sound (although that one was recorded from the noise-less-drums tracker). Most of these bugs are now manifesting because of all the "improvements" I've done since the @Party in 2017. Back then, we patched and hacked the code furiously to make it all work acceptably. dZ.

Thanks for that, I see what you mean! 😱 It seems to start specifically when the rocket comes in. That's probably something in the demo code for that sequence; as you've already seen, I've already found quite a few places where the variables were not initialized correctly. It makes sense that, since the noise generator was being suppressed with the broken tracker, this error went unnoticed -- until now that we have proper drum sounds. I'll take a look and try to fix it tonight. Would you mind testing again after? Unfortunately I do not have the facilities to test on hardware right now. Thanks a lot for your help! -dZ.

Thanks. I also plan to release the source code to the 6-channel tracker to the public domain soon. I'm currently updating the documentation for the Intellivision Music Tracker to go with it. -dZ.

Hello, It bothered me for some time that the drums in the demo songs did not sound right. So I isolated the channel, did some tests, and discovered that indeed, the "noise" output was being disabled on all channels! The result is that the drums are generated in pure tones, lacking the "punch" and "crack" that they should have. It's a subtle change, but still perceptible, especially if you ever listen to the correct sound. It turns out that this bug was introduced a few years back as part of a fix for some other defect in the 6-channel tracker. I'm quite happy to say that this bug has finally been put to rest, and the drums are back and as punchy as they should ever be. Anyway, in case anybody is interested, I've updated the first post with a fixed version of the ROM that includes the updated tracker. If you'd played the demo before, you may want to check out this updated one, so you can listen to the 6-channel songs the way they were always intended. -dZ.

UPDATE: I just looked through my version control and saw that an older version of the INTYBUILD script accepted a full filename instead of just a project name. This was part of a feature that didn't really work that well, and turned out to complicate matters more, so it was removed later on. Keep in mind that the point of the IntyBASIC SDK was to simplify the process of using IntyBASIC, so the whole tool chain was intended to abstract the filenames, while the programmer just works with projects. I'm sorry that this affects your workflow. Like I said before, creating different projects for each one would work -- but really, give TortoiseSVN a try, it's super easy to use, and it integrates with the Windows Explorer so committing a new version is as simple as right+clicking files or folders and choosing the appropriate command from the menu. https://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-quick-start.html I can almost guarantee you that once you use a proper version control system, you'll never go back to just copy+paste files and timestamps. It really is a superior mode of working. -dZ.