ivop

Nice! I was wondering, how did you import a MIDI file into RMT?

Here's my go at it. Two slightly different versions. Eight shades of gray, 160x240. done.xex done2.xex

Yes, I have posted a patch to the atari800 mailinglist. http://sourceforge.net/p/atari800/mailman/atari800-users/?viewmonth=201509 No native RLE compressed player yet, but I'm actually hoping on ASAP supporting Type R files

Yes, I think RLE should be enough. The problem with Exomizer or LZ4 or any other 'sliding window' method is that you'll have to keep large parts of the already decompressed and played stream of bytes in memory because a back reference might come up later. RLE is simply decompress 9 bytes, play and discard. This pokey register recorder might also come in handy if a demo screen or game has very limited time left for music. One can compose a song in their favorite tracker, play it and record it and use that recording. A native player will probably take less than one scan line. BTW recorder is done. I'll post the code to the atari800 mailing list shortly. It also supports recording stereo pokey songs.

@miker, the problem with tunes from basic programs is that there's no such thing as an engine @pirx, I'll look into it. At least a periodic register dump to a file will be a useful feature for an emulator anyway. Perhaps with some simple RLE compression of each channel's values (i.e. consider each register as a separate stream of values) several minutes might fit the memory of a stock 48kB Atari, including a native player. Afterwards, it'll be trivial to convert that to a TYPE B SAP file.

CC8 is an improved version of Deep Blue C. http://www.umich.edu/~archive/atari/8bit/Languages/C/cc8.arc It seems you also need the linker and Runtime from either DBC or Ace C: http://www.umich.edu/~archive/atari/8bit/Languages/C/acec.arc

Hi, I was wondering if there's a SAP player that supports TYPE R (timed Pokey registers dump)? I was thinking about adding 'SAP Recording' to atari800 (the emulator), mostly to record (turbo) basic tunes and maybe songs from games where it is hard to separate the audio player from the actual game. But if there's no player for TYPE R, I have to rethink this. Regards, Ivo

I'd like one, too. Thanks, ehm, too!

My $0.02: Firmware for direct access to the SD Card, possibly with a IDE emulation layer in between (i.e. directly compatible with SIDE or MyIDE) (Angled) pin header that exposes some IO pins to the outside world, which enables one to implement e.g. SPI, I2C or a full UART with a simple add-on cable

Sure. I forgot one step in before mentioned procedure: pre-process your image with The Gimp/Photoshop/whatever and crank up the color saturation. No dither, netpbm quant: FS dither, netpbm quant: SPQ, 0.9 dither factor As before, looks best on CRT. spocks.zip

Sorry for the long delay. I expected to post "how it's done" earlier, but life got in the way. So, here's how it's done The color mode does resemble PAL-blending a bit, but instead of doing APAC in graphics 15, which I also did before, I wanted a mode that did not have every other line without any luminance. So instead of mixing a line of luma only with a line of chroma only, I wanted both lines to have both components somehow. Going the RGB route would need three lines and looks horrible. I also did not want to page flip, which, especially on PAL, flickers horribly. Then I thought of YUV. One line contains YU and the other YV. The conversion is pretty simple with some command line fu [1] (mainly netpbm) Convert image to planar yuv Make a copy On the first image, set the V channel to 128 (assuming 8-bit per component) On the second image, set the U channel to 128 Convert both back to RGB Quantize both to 4 colors Select the 8 closest colors from the GTIA palette (sometimes ignoring all gray values and sometimes ignore some purples to improve color spread) Convert both images to Atari's graphics 15 paletted format, optionally use dithering or use spatial color quantization with built-in dither Lastly, interleave both images, i.e. take line 1 from image 1, line 2 from image 2, line 3 from image 1, et cetera That's it. The viewer just switches between two palettes every scan line. Last Saturday, at the computer club we checked a whole bunch of Atari computers and monitors and this mode is highly dependent on a decently tuned GTIA and looks only mediocre on a TFT screen anyway. A CRT is needed for the full effect As for the 8 shades of gray mode, this was actually a by-product of the above. The odd lines use a palette of 0,4,8,12 and the even lines use 2,6,10,14. Always. Conversion is even simpler. Just quantize and dither two copies of the same image, each using one of the two mentioned palettes. After that, interleave, and so on... [1] https://xkcd.com/196/

Hi, Here's two 160x240 no-flicker "new graphics modes" I have been experimenting with. Funny thing is, the viewers are identical. The conversion routines are totally different though. More info and sources will follow... black and white (8 shades of gray) 6 images, e.g. color (guess how many colors ) 8 images, e.g. Best viewed on real hardware and period display bw.zip color.zip

INC is a Read-Modify-Write instruction. It first reads a zero at bit 0, it writes a zero when it is modifying the value internally (increase by one) and then it finally writes a one to bit 0.

Indeed. At the top of the source I wrote 6581, but I guess it's closer to the 8580 (e.g. waveform mixing capabilities). AS5 uses a lot of memory, starting at $0f00 up to (sometimes) $bbff, depending on the size of the C64 player routine. Also, it almost completely wipes page zero. Theoretically this could be saved somewhere, as could let's say up to $2000 to save DOS, but I just power-cycle But I'll keep this in mind if I ever release a sixth version. It's not that hard to implement

Perhaps a Turbo Basic XL Cross Compiler could be a nice start?

I'm emulating the SID chip by playing three channels of samples, summed together, on a single volume-only Pokey channel (this is faster than three separate digi channels and only slightly degrades audio quality; see Atari Sid 4 thread for details). The replay rate is 15.6 kHz. Dynamic range is 24 dB (8dB per channel)[1]. Not emulated are SID filters, ring modulator, test bit, pink noise[2]. Lack of the ring modulator could well be the reason for the odd bum note. There are some hacks in place to filter those out (e.g. Cybernoid II and Master of Magic) but I probably missed a song or two. The other reason could be the lack of pink noise emulation. The noise waveform is emulated by white noise and hence it has no frequency other than being cut-off at half the replay rate (7.8 kHz). The result is that noise-sweeps sound terrible, sometimes even mechanic. There are ideas to simulate these properly with pokey noise generators (like sid2gumby does), but nothing has materialised yet. [1] https://en.wikipedia.org/wiki/Dynamic_range#Audio [2] https://en.wikipedia.org/wiki/Colors_of_noise

Which emulator? Current atari800 does not work without a patch posted recently on its mailinglist. Altirra should work. Be sure to emulate a stock 800XL. Otherwise, use real hardware

Hi all, Here's the final release of Atari Sid 5. All sources have been converted to MADS and tidied up. I tried to use as many MADS features that were useful. The 'preview' sources should be considered obsolete(!). Thanks to Phaeron's 3 IRQ idea, it's a bit faster than version 4 (small gr. 3 screen on should now be possible). Thanks to Wrathchild, the envelope handling state machine has been removed and replaced by code. Some bugs that were present earlier are fixed. I have converted 30 songs and assembled the .xex files, which are attached in a separate ZIP-archive. My mind's a bit fuzzy atm, so I'm sure I'm forgetting to mention something here Regards, Ivo atarisid5-src.zip atarisid5-xex.zip

Something like this could be done on the Atari, but as Rybags said, it would be best to output the uncompressed "mp3" directly on a pokey or covox channel. There's also this C64 demo that uses its sound generators to approximate a waveform. And finally there's a C64 demo that uses a fixed dictionary/codebook of waveshapes and uses indeces into that to compress a larger sample by a factor of eight. (sorry, don't have links handy atm). Yes, that would be possible. The tables have to be adjusted to use a wider dynamic range. [0..85] per voice for replay on a single DAC or [0..255] for three DACs (which will consume slightly more CPU cycles again). Also, the RLE compression of the tables won't be very effective anymore. I guess a delta encoder preceding it might fix that.

OK, I finally bit the bullet. Here is preview3 of Atari Sid V with sources in MADS format! Should be 100% similar to the shasm65 version atarisid5-preview3-src.zip atarisid5-preview3-cn-xex.zip

I intended to run timer 1 at 15.6kHz Something got messed up somewhere after version 2, but not quite enough to be audible I guess. Does this fix it? (I cannot run Altirra on my nine year old computer). atarisid5-preview-cn-try2.xex.zip

Here's a preview (prelisten?) of Atari Sid V. I incorporated phaeron's idea mentioned earlier this thread and added some more changes. CPU usage is now down to 75-78 cycles per scan line, which I guess is pretty nice compared to 96 (v3) and 86 (v4). Compare the "notches" in the volume bars between v4 and v5 Cybernoid's player routine is pretty slow compared to, for example, that of Sadotracker, so the difference can be seen fairly good. The bad thing about v5 is that it now uses 26kB for tables during runtime, instead of 13kB @analmux: I have thought about filters a lot and it is not easy as just adding a bunch of tables. It means, for every channel, that the new sample value depends on the previous value, on the frequency setting of the filter and whether it's low-pass, high-pass or band-pass. In any case, it'll slow down the softsynth core tremendously, if at all possible atarisid5-preview-src.zip atarisid5-preview-xex.zip

As emkay pointed out, you can create them with a C64 tracker For example, all the Metal Warrior 2 songs were created with Sadotracker (Cadaver/Covert Bitops). The player routine is pretty small and fast. During playback with Atari Sid IV you can see little notches in the volume bars. That's the point during the frame where the player and sid register emulation is finished. The faster the player, the higher up the screen those notches appear. Compare Hubbard, Tel and Cadaver and you'll see what I mean.

Thanks Phaeron, for sharing your insight. Perhaps some variant of this might find its way into a future version! Heaven, here's the relevant posting in the sid2gumby thread: http://atariage.com/forums/topic/199103-teaser-sid-2-gumby/?p=2542066 It's very important to notice that the resulting (patched) .sid disassembly is reassembled with atasm -r as to not include the ffff-header. If you're still having problems, please post a more elaborate description of the problem(s) you are facing so I can better help you solve them. Also, I suggest you start with a .SID which is known to work. Some players reset the ADSR envelope in such a way that it is impossible to detect that outside of the player loop and those will not work without rewriting parts of the disassembled sid-file.(player here refers to the original c64 player code).

I do the same as FJC, or right-click and open with an external viewer which has its default settings to fit-to-screen. But I get what Mathy's saying. When I'm reading AA on my tablet, I really dislike having to swipe/scroll around a huge blurry picture.