andym00

Much better put than my waffling coffee and nicotine deprived post

I just thought there might be some games that are universally considered in Atari land as being outstanding technical achievements, that aren't 3D I mean in C64 land, stuff like Armalyte and Co. is (I guess) heralded by the gamers as being the best their is, then Mayhem in Monsterland and others.. On 7800 you've got TowerTopper/Nebulus/Castellian which looks simply adorable on a real TV (but that's probably just me thinking its one of the best (if not the best) examples of how to use artficating well).. 2600, things like Solaris, Thrust and Pitfall II spring to mind.. I've got to look more into these GTIA modes.. There'd be some very colourful stuff to be had with that and PRIOR=0 as well, but I get the impression they're all a bit too chunky to be useful most of the time.. But maybe that's just me.. Are there any good examples of its use in games ?

I love the day starting off being accused of not understanding something.. Lets just leave the OS out of the equation, they have absolutely no bearing in the situation at all.. There won't be glitches, there won't be any problem with more or less time.. All there is a large polyphase filter bank which is doing the downsampling from 1.79Mhz to 48Khz (or in fact any sample rate I choose), nothing more nothing less.. So with a core generation loop that looks like this: Emulate one 6502 cycle Emulate one pokey cycle Stuff into audio buffer Please explain why I can't can't have the exact cycle to cycle relationship ? I'm only interested in Pal, so the other clocking modes are exact ratios of the base clock frequency, and I'd hope the Pokey emulation (I've not had time to look properly yet) would take care of this internally.. So assuming Pokey and CPU share same clock, then there's no problem right ? So we can forget about that whole issue.. So there's no problem then is there.. The emulation is driven from the sound output code[1], so as the audio output needs more samples, we emulate more cycles.. It's not rocket science.. [1] Well not directly.. The audio generation sits in another thread from the DirectSound/ASIO/KS output code since we want as low latency as possible ~10-20ms, so it just reads from a ring buffer and signals an event from the realtime priority audio thread that handles the audio provider, which is picked up instantly (due to thread priorities) by the emulation thread which has an above_normal thread priority and is invoked immediately after the audio stuffing thread relinquishes control, and does the emulation and polyphase resampling for as many samples as we can into a ring buffer the direct sound stuffer thread actually uses..

And here's Martin Pipers converter (you know Bezerk Redux et al).. MashSamples.zip

Weird, I could have sworn I attached that.. WavToInc.zip

Here's an old one from my 2600 days.. It's not packing into nibbles (I was playing with 5 bit playback) but you can change it *very* easily.. And the output bit depth is part of the command line.. It chucks out something looking like this: ; ; Fri Aug 15 18:25:43 2003 ; Source File: CBRZ_7680.wav ; Bits: 5bit Unsigned ; Amp:: 1.50 ; Rate: 7680 ; Length: 0.14 seconds ; Length: 1109 samples ; Padding: 2048 bytes ; .byte $0f,$10,$0f,$10,$0e,$0f,$0f,$0f,$0e,$10,$11,$11,$0c,$15,$1a,$00 .byte $08,$1f,$1f,$1f,$19,$00,$00,$00,$06,$19,$1a,$00,$00,$08,$17,$1f .byte $1f,$1f,$1d,$11,$00,$0d,$0e,$00,$00,$00,$00,$0f,$1e,$1f,$1f,$1f .byte $1f,$1f,$1f,$16,$11,$00,$00,$00,$00,$00,$00,$09,$11,$1f,$1f,$1f .byte $1f,$1f,$1f,$1f,$1c,$03,$00,$00,$00,$00,$00,$00,$02,$0b,$1b,$1f .byte $1f,$1f,$1f,$1f,$1d,$0f,$03,$00,$00,$00,$00,$00,$06,$15,$1c,$1f .byte $1f,$1f,$1f,$1f,$1f,$19,$0d,$02,$00,$00,$00,$00,$00,$03,$15,$1f .byte $1f,$1f,$1f,$1f,$1f,$1c,$0e,$04,$01,$00,$00,$00,$00,$07,$14,$0c .byte $1b,$1b,$1e,$1e,$1b,$1f,$1e,$12,$06,$03,$00,$02,$00,$01,$07,$18

Adobe Audition, or its prior name Cool Edit Pro.. You can use any bit depth you want, 1bit, 2bit 3bit etc.. And saving works beautifully, though it doesn't pack them into nybbles for you.. I'll have a dig through my old 2600 and 7800 stuff and see I'm sure I've got one, I don't have any 64 tools for that since I hate 4 bit samples on the 64 If not it's 2 minutes knock one up.. But I can't recommend enough using Audition or CEP enough to at least prepare the samples..

Can I just ask the Atari brigade for their opinion of what the absolute absolute *BEST* use of players/missiles, sprites, backgrounds and colours in a game is ??? I'm really curious what's considered to be the absolute state of the art technically, the cream of the crop so to speak.. That runs at 50/60hz.. A real game engine.. I'm not being funny or taking the piss, but I'm curious to know where the technical bar is set on the A8.. And I'm not on about 3D nonsense and such like, so no bloody RoF, please We all know it's faster as are most 3D contraptions on the Atari

No worries, I can stand a bit of salt in my coffee I wasn't planning on going that far, maybe in the future, but certainly not right now.. I just want a nice editing tool and environment to play with on the PC to develop a nice multi-rate SFX driver, but with a nice front end to work with, and as close as possible emulation of the audio.. I mean I've already got all code I need to build such stuff from many previous creations, and I'd much rather build an editor on the PC rather than build a whole editing environment on natively on the A8.. But either way, I don't see that adding refresh cycles and 'pseudo' dma accesses to it would be such a big job if I went that route either.. I'm not interested in music just yet, that comes later, for now just SFX edit: And I've got a 65XE now plus an 800XL but just need to sit down and finally go through all the PC connectivity options and then I can finally start to test on the real thing.. Very soon

Ah, didn't realise that was what RMT used.. I'll give that a go then as well..

What is "cycle accuracy" for you? The problem is that for sound emulation you usually have the problem that the emulation procedure is not in agreement with the frequency of the sound output. Thus, what you usually want is a pokey emulation that can create the sound output for the next "N" cycles of the machine, filling an output buffer of "M" bytes, where on the real machine "N" and "M" would be identical, but due to emulation are not. If that is your concern, the atari++ pokey implementation is fairly good, I believe. What is not supported is the sound modulation due to SIO activity. The SIO base frequency is, however, included. So long, Thomas That's not an issue for what I want.. I'm not interested in generating a screen at all.. All I want to do is running a raw 6502 emulation in a bare 64K address space with a Pokey mapped in there.. Since I'm not generating a screen, I'll using the audio output to clock directly.. If Pokey is actually clocked at 1.79Mhz then I'm quite happy to run one cycle of CPU, then one cycle of Pokey then I'll sample it at that rate and downsample for the output.. It's just the sound I'm after nothing else.. Whatever method it uses I'm quite happy with, as long as I can ask it to emulate for X cycles on it's own.. The idea is I want to write a PC hosted sound effects editor, so I want to put together a little black box consisting of 6502 & Pokey, with the 6502 running the sfx code driving pokey and the PC tool allowing my some nice editing environment.. That's all I'll go give that a go then.. Thanks edit: I did exactly the same thing on the 2600 for writing some sound stuff on the TIA when I wanted good a reproduction as possible, without emulator foibles and frame rate issues..

I thought I'd ask here, since the 8bit forums seem mostly frequented by tumble-weed Is there a Pokey emulation libary or source code available that's considered the best, or in fact absolutely bang on cycle accurate ? I'm just looking for something that I can hook up it to a sound editing tool that's running a 6502 emulator with some sound drivers, and get as close as possible emulation of what I'd get on the real thing ? Does such a thing exist ? If so, which is the best ?

That's not too shabby really.. Still lacking in colour on the sprites, but it definitely has that 'I want to be a c64 when I grow up' feel about it

That's the puppy, thanks

There's a lot more about it on his own website.. http://benheck.com/09-11-2009/new-atari-800-laptop#more-645

You can't.. It only take effect once the current timer value has elapsed..

No.. Look at his code.. He jumps straight into the first interrupt in his list.. Check the code.. He gets the delta times he expects, which will work fine if your just doing colour splits or anything that doesn't care where your position is exactly on the screen.. But since the sprite stuff needs to examine the raster line on the fly to determine if it should continue loading more sprites without waiting for the next interrupt it can't work like that, since it has to figure out where the next raster should be once it's finished whatever needs to be done.. You can do it all with deltas and never look at your raster line, but it means calculating the overhead of any DLIs that might fire, plus computing the workload of the interrupt at the scanline, then calculating a true stand-alone delta value.. Which is going to be a bugger load of work i think..

Right, that's exactly what I understood.. So, no way to recover from a DLI knocking you out, or unexpected workload in an IRQ.. Not without precomputing the deltas taking into account how the irqs intersect DLI, and then computing the workload of each interrupt and adjusting deltas correctly..

I know it's been a long time, but does anyone know where the Tempest Code Project might live now ? It's vanished from its original url, and google does turn up anything hopeful..

Ah.. So I guess at half time the teams swap Player5 ?

My tinkerings led me to conclude that the value 10 would have to be loaded during the time before IRQ1.. When the timer elapses for IRQ 1 then the value 10 is loaded into the counter from the AUDF4 register and begins counting down.. So you have to in 'IRQ0' you have to load the delta value you need for the time between IRQ1 and IRQ2.. In that form it's not that useful for rasters in a real world scenario, with DLIs showing up and an undetermined workload per interrupt and other delays, not if you want to keep it bang on line accurate.. It's exactly the same as the CIAs, except there's no force load, only by STIMER in this case.. That's how it seemed to run on Altirra at least, which I've heard heralded here for its cycle accurate timer emulation, and how I understand it from the docs as well.. If the realities any different I'd love to know exactly how it's different..

I'd always assumed from looking at it (and playing it loads when I was a young lad) that the animations were like Barbarian, in that they animated within the frame and didn't require proper shifting, just byte aligned drawing, but it's interesting to know how much memory they take up.. I'd imagined they'd be bigger than that..

To be fair, they appear to be different games.. The Atari one is clearly 2 a side

I'd only do it because I want as many sprites as possible.. I've just added P5 stuff and god it hurts having to do lda/sta/adc/sta/adc/sta/adc/sta just to set it's X position!! I think I'll probably keep the missiles seperate and just use PF3 for them and multiplex them seperately from the players for lots of little things flying around But sounds like me wanting to do Street Fighter with walloping big sprites and backgrounds on the 64, all very doable, except the distinct lack of ram, and I feel like I'm cheating if I use the REU Out of curiousity, how much memory does of the Fist player images take up ?

lol Would be very nice if someone could incorporate it. As you say if you've got contentious interrupts happening it can all go to pot but if your DLI/timer code takes both into account you can always drop any DLI stuff into the timer irq or vice versa. We'll see, I'll have a bash at it, but right now I've got other things on my mind, though I had written the idea off until just thinking about it now and a kind of solution formulating.. The plexer easily hands out missed sprites anyway, so without any extra effort I know which need to be horizontally split.. Though I'd much rather put these into DLIs and lose the time when a sprite is horizontally split since it'd be a pain to incorporate this into the normal multiplexer code, much more so than just biting the cost of the interrupt overhead each line for the DLI, which at 19 cycles I don't see being so big for the occasions you'd need this.. But I think it'll make regular multiplexing 'iffy' in those zones where horizontal splits are occuring..