-
Content Count
2,282 -
Joined
-
Last visited
-
Days Won
3
Posts posted by ivop
-
-
@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.
-
2
-
-
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
-
2
-
Sure. I forgot one step in before mentioned procedure: pre-process your image with The Gimp/Photoshop/whatever and crank up the color saturation.
FS dither, netpbm quant:
SPQ, 0.9 dither factor
As before, looks best on CRT.
-
4
-
-
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...
-
7
-
-
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

-
18
-
-
This is just great. Small request: Please add auto-disabling BASIC to the XEX. They fail to load with BASIC enabled and that's pitty for such cool code.
> inc IRQEN
Why that?Does it effectively clear the IRQ (dummy read to $FF writing $00?) bit so no new IRQ is trigger after RTI?
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.
-
But from what little I know and some reading re the numerous sid versions it makes emulation the chip quite awkward ...Indeed. At the top of the source I wrote 6581, but I guess it's closer to the 8580 (e.g. waveform mixing capabilities).
I have been listening to these, and trying exit gracefully but can not find a key press to quit back to DOS. SDX specifically Do these songs run to the end and then quit or is it looping continuously ..
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

-
2
-
-
Moreover, batariBasic has an IDE; Quick and TB XL don't have it.
Perhaps a Turbo Basic XL Cross Compiler could be a nice start?
-
2
-
-
Yes, great stuff indeed,When I said emulating I've not looked at the way you are doing it, are you emulating a chip or emulating the filters / sound generation?
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.
-
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
-
15
-
-
Btw. I wonder if this one can be emulated (even partially): http://csdb.dk/release/?id=87985
(everyone has dreams, I know)
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).
Thanks. Would it be possbile to make a special version that would output to the real 8bit DAC like the highend Covox option on my RAM cards?
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.
-
Creature... I would if I could use straight away the source and sid converter
but right now it would take too much efford to convert each time this strange asm format so that's why I am more into Atari 8bit successor - Amiga 
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

-
3
-
-
Er, what rate is the IRQ intended to run at? The debugger is showing the IRQ running erratically driven by timer 4 at 64KHz (IRQEN=$F4, AUDF4=$00, AUDCTL=$50). Did you intend for timer 4 to run at 15KHz (AUDCTL=$51)?
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).
-
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

-
4
-
-
Ivop... basicly what is the way to go to get a own composed SID into A8 then?
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.-
1
-
-
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.
-
Here's the core of the irq routine (skipped code duplication for clarity):
.org 0x0000 $tempzp L irq sta.z $saveA # 6 + 3 = 9 count_lsb_v1=$(($_here+1)) lda. 0 # 2 freq_lsb_v1=$(($_here+1)) adc. 0 # 2 sta.z $count_lsb_v1 # 3 lda.z $count_msb_v1 # 3 freq_msb_v1=$(($_here+1)) adc. 0 # 2 sta.z $count_msb_v1 # 3 # ---> 15 ### REPEAT THE ABOVE TWO TIMES FOR SECOND AND THIRD CHANNEL count_msb_v1=$(($_here+1)) table_msb_v1=$(($_here+2)) lda $silence # 4 clc # 2 count_msb_v2=$(($_here+1)) table_msb_v2=$(($_here+2)) adc $silence # 4 count_msb_v3=$(($_here+1)) table_msb_v3=$(($_here+2)) adc $silence # 4 sta $AUDC1 # 4 # ---> 18 inc $IRQEN # 4 saveA=$(($_here+1)) lda. 0 # 2 rti # 6 # ---> 8 # total: 9+3*15+18+4+8 = 84Stuff starting with a $ are labels, not hex values. Those look like 0x.... similar to the C programming language.
Mnemonics with a . (dot/period) added are immediate, with .z are zero page. The whole routine runs in zero page.
freq_msb_* and table_msb_* are modified by the sid emulation/softsynth that runs once per frame. All the _here+1 stuff is similar to *+1 in other assemblers. It's all self modifying code.
I don't see how I could use immediate loads as those values have to come from tables at some point. But perhaps you can think of a way to speed this up even more?

Side note: saving and restoring the accumulator could be omitted if one was to write a player routine directly for the softsynth engine, removing the need for sid register emulation, and only use the X and Y register

-
1
-
-
I have been thinking of changing the source format to a more reasonable format, but have been putting it off every time because of the work involved
This whole project started out as a testcase for shasm65, which in itself was just a fun project to see if it could be done (i.e. an assembler as a shell script).Heaven, if you want to convert it yourself, go ahead. It'll probably help if you have an editor which has syntax highlighting for (ba)sh. Suddenly it becomes a lot more readable
I remember that Tezz wanted to do something similar. Perhaps some work has already been done in that direction?I have never written any polled SIO related code, so I'm not sure if I'm the right person to try combining the two. Also, I'm working on two "new graphics mode" projects at the moment

Edit: a short "manual" on how to get a SID converted is in the sid2gumby thread here on AtariAge. Once converted, the resulting binary works with v3, v4 and sid2gumby.
-
Some more info I probably should have put in the first post

Replay rate is 15.6 kHz, just like version 3 (version 2 was 7.8 kHz).
The extra cycles were saved by doing a single INC IRQEN (an RMW instruction) to clear and reset the timer 1 interrupt bit.
Also, I went back to a single channel, which indeed does slightly degrade the sound quality, but as Philsan said, imho that's acceptable if it leaves more CPU time for other things (like a Pokey player, PMG based scroller, or perhaps a SIO loader).
To reply to emkay why it actually saves time to add the channels instead of storing them to Pokey directly:
version 3: lda $1234 sta audc1 lda $5678 sta audc2 lda $9abc sta audc3 24 cycles version 4: lda $1234 clc adc $5678 adc $9abc sta audc1 18 cycles
Sadly, the clc cannot be skipped. It'll start playing a 7.8kHz beep if you omit it.
The tables in v4 are slightly adapted. Its range is now 0-5 instead of 0-7, which is why the quality is a little less. Luckily, the SID chip has three channels, which means that adding three values in the range of $10-$15 gives a result in the range of $30-$3f which is still volume-only

As for the funny assembler format, basically, the source is a Unix shell script (works with zsh, bash, ksh).
Thanks for the feedback,
Ivo
-
4
-

SAP TYPE R, recording (Turbo) Basic tunes to SAP
in Atari 8-Bit Computers
Posted
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.