Atari-Forum

Nice ideas and lot of work !!

The convention is a little far for me, but I hope you'll have fun !

Merci !

Zippy wrote: ↑Mon Apr 25, 2022 4:07 pm

Cyprian wrote: ↑Mon Apr 25, 2022 2:45 pm Honestly I can't imagine debugging without that feature.

To think back in the day even a reset RAM dump cartridge was considered "cheating" by some.

And I still continue to use only Adebug

XnView MP can do batch operations, and it seems it can manage Neo format.

Maybe XnView MP could help ?

Moulinaie wrote: ↑Mon Jan 10, 2022 7:01 pm Both M_PLAYER and MP_STE are written in ASM using ASSEMBLE(Brainstorm).

I really enjoyed ASSEMBLE in the old times. It is few mentioned, I wonder if many developers used it.

It has been a long time since I have used one, but I don't remember having to plug any midi or audio cable to have the display working.

chicane wrote: ↑Thu Nov 11, 2021 12:56 pm

Zippy wrote: ↑Thu Nov 11, 2021 10:12 am You could replace those pairs of "add.w d0,d0" with an "lsl.w #2,d0"

I seem to recall that two 'add.w d0,d0' is faster than a single 'lsl.w #2,d0', on the 68000 at least.

Yes 8 cycles for 2 add.w, and 10 (so 12) for a lsl.w #2 on 68000

MM41 wrote: ↑Mon Nov 01, 2021 8:32 pm With my STe (4mb ,TOS 1.62Fr) ,i can see a red ball moving to the left and a"fast cycling ghost ball" (moving to the left too)

Thanks for testing on HW, I won't have to unpack my STe then !
I suppose this confirms that Hatari implementation is correct. Do you confirm Leonard ?

When you use shifting you are supposed to use End Mask value different than $FFFF, which does clear the problem. This is interesting. Why would there be a requirement to use an endmask value different to $FFFF when skew != 0? I can think of plenty of scenarios where you'd want to use skew !=0 and e...

When you use shifting you are supposed to use End Mask value different than $FFFF, which does clear the problem. But if you theoretically do not need using masking, and want to avoid a destination read bus access by setting $FFFF, then the problem appears. Nevertheless, the blitter internals are ver...

Hi Leonard, Unfortunately my STe is currently packed, but I have previously found the same issue (or at least something very very close). You can look at the following post of the thread about this (which also discuss of other blitter emulation discrepancies): https://www.atari-forum.com/viewtopic.p...

That's really cool, I'll be interested to hear how big the hit in sound quality and volume is. Not sure if I can make use of movep for buffering in my routine since it needs to be pretty adaptable for different output devices but I'll give it some thought :) Concerning volume, a "classical&quo...

Yes, the movep is very useful for that too. I used it (but also the a7 trick) in my replay routine to send all samples to the L or R channel. But it effectively requires to have the right input format : if you are ready to reduce quality (increase noise), then you can convert samples onto 6 bits uns...

It's true there are some very efficient MOD player routines, especially Lance/Paulo one (available here: https://dhs.nu/files.php?t=democreation ) which plays 4 tracks @ 12.5 kHz with only 20% CPU. At least it contains interesting tricks for optimising your own replay routine. And if CPU is really c...

Has someone already used this new modes for a demo ?

Amazing work ! Thanks for sharing !

Additionally, there don't seem to be any overscan effects in the demo, yet, it totally rocks. Shows that design and execution still matter. All praise to overlanders for pulling this off so well. Well there is plenty of sync scrolling going on, which essentially is overscan in all forms possible :-...

Cooking up some batshit, off the wall method for solving a problem, and then prototyping it and seeing that (a) it looks OK and (b) there's still half a frame of CPU left, is my favourite part of making demos :) Yes, it is the most intersting part for me too. Except that there are always a lot of i...

I haven't and didn't want to, in order not to be influenced :wink: . And also I suppose that it is the habit I have taken from back in the days, i.e. to try to reproduce their demos without having access to their source code ! :lol: That's the spirit and that's when you truly can point at something...

Thanks Cyprian & Thomas3 ! Out of interest, has anyone looked into how TCB did theirs all those years back? I haven't and didn't want to, in order not to be influenced :wink: . And also I suppose that it is the habit I have taken from back in the days, i.e. to try to reproduce their demos withou...

Thanks Daniel ! Happy that you have liked it !

Hi guys ! After the release of my STe demo (The Star Wars Demo by The Arctic Land, see links below), I have received lots of nice comments about it (thanks !), but also several requests to explain how the Star Wars scroller is implemented. I have therefore prepared few PPT slides, that are available...

Amazing work ! Congrats !
If only we've had such STE games at the old times

The mixing part, although composed of simple operations, requires quite a significant part of the CPU time.
And as I said it is not impossible to do the kind of stereo mix you describe, but you'll probably have to do it by yourself, I doubt that you find ready to use code on STE.

The main problem is CPU usage. 4 voices soundtracks mixing almost takes half of CPU at low replay frequency on STE. What you are looking for will add two additional voices to mix and lower mixing quality. Not impossible to do, but that's mainly with Falcon (with its DSP) that real stereo management ...