| flame demo -- 106 bytes [message #379238] |
Tue, 01 January 2019 11:39  |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
Hello,
I was reading this page about the PSX Doom flame effect
http://fabiensanglard.net/doom_fire_psx/
and decided to see if I could do this on the Apple II lores mode.
Then I decided to optimize it for size. I got it down to 106 bytes.
I am sure it can probably be made smaller. Anyway a page about it
here:
http://deater.net/weave/vmwprod/apple2_fire/
I am cheating a bit and using a 40x24 mode to avoid the shifting/masking
to get the full 40x48.
I did get the lores row-address lookup code pretty small, but I'm guessing
people have done it better.
Vince
|
|
|
|
|
|
| Re: flame demo -- 106 bytes [message #379303 is a reply to message #379267] |
Thu, 03 January 2019 00:21  |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2019-01-02, Antoine Vignau <antoine.vignau@laposte.net> wrote:
> Happy new year, Vince.
>
> Using GBASCALC, BASCALC, and VTAB, I'm sure you could save a lot of bytes...
I have it down to 80 bytes now by calling VTAB (the monitor one, not
the Applesoft one. I'm avoiding Applesoft because I want it to run
with Integer ROMs). qkumba helped shave a few bytes off too.
Vince
|
|
|
|
| Re: flame demo -- 106 bytes [message #379304 is a reply to message #379303] |
Thu, 03 January 2019 00:33 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thu, 3 Jan 2019, vince@pianoman.cluster.toy wrote:
> On 2019-01-02, Antoine Vignau <antoine.vignau@laposte.net> wrote:
>> Happy new year, Vince.
>>
>> Using GBASCALC, BASCALC, and VTAB, I'm sure you could save a lot of bytes...
>
> I have it down to 80 bytes now by calling VTAB (the monitor one, not
> the Applesoft one. I'm avoiding Applesoft because I want it to run
> with Integer ROMs). qkumba helped shave a few bytes off too.
>
> Vince
>
Codegolfing FTW
-uso.
|
|
|
|
|
|
| Re: flame demo -- 64 bytes [message #379343 is a reply to message #379238] |
Thu, 03 January 2019 21:18 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2019-01-01, vince@pianoman.cluster.toy <vince@pianoman.cluster.toy> wrote:
> Then I decided to optimize it for size. I got it down to 106 bytes.
> I am sure it can probably be made smaller. Anyway a page about it
> here:
> http://deater.net/weave/vmwprod/apple2_fire/
I managed to create a new flame demo that's a slightly different algorithm
but I managed to fit it in 64 bytes. You can find it at the same location
mentioned above.
To fit it in 64 bytes it uses the monitor SCROLL and VTAB routines.
If you don't want to bother with downloading things just enter this
in the monitor:
70: 2c 50 c0 20 70 fc a9 ff 99 cf 07 88 d0 fa a9 16 85 25 20 22 fc a0 27 a5 4e f0 05 0a f0 04 90 02 49 1d 85 4e 30 09 b1 28 29 07 aa b5 a8 91 28 88 10 e5 c6 25 10 dc 30 cb 00 bb 00 aa 00 99 00 dd
70G
Vince
|
|
|
|
| Re: flame demo -- 64 bytes [message #379348 is a reply to message #379343] |
Fri, 04 January 2019 00:00 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
$78 can
- STA ($2A),Y ($FC70 sets it to $7D0)
DEY
BPL -
since it doesn't matter that you hit $7F8.
Amazing work. I was thinking just this morning that 64 bytes was unlikely. :-)
|
|
|
|
|
|
| Re: flame demo -- 64 bytes [message #379371 is a reply to message #379348] |
Fri, 04 January 2019 10:50 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2019-01-04, qkumba <peter.ferrie@gmail.com> wrote:
> $78 can
> - STA ($2A),Y ($FC70 sets it to $7D0)
> DEY
> BPL -
> since it doesn't matter that you hit $7F8.
True, I was avoiding hitting the screen holes (such as MSLOT $7f8)
but I suppose if you're running this program you're probably beyond caring
about what any expansion cards are up to.
So we're down to 63 bytes...
> I was thinking just this morning that 64 bytes was unlikely. :-)
Yes, I've been wanting to have a useful 64 byte demo for a while and it
turns out to be surprisingly hard. I was under the mistaken impression
that the C64 people had a bunch of them, but it turns out not really.
The DOS people do though.
I probably should have saved this up to submit to a demo competition but
I think now that I've got it posted all over the internet it's a bit late
for that.
I should really test this out on real hardware. The older mac-mini I always
used for video capture has suffered a traumatic hard drive failure though
so I need to get that fixed.
Vince
|
|
|
|
| Re: flame demo -- 64 bytes [message #379380 is a reply to message #379371] |
Fri, 04 January 2019 13:22 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2019-01-04, vince@pianoman.cluster.toy <vince@pianoman.cluster.toy> wrote:
>
> I should really test this out on real hardware. The older mac-mini I always
> used for video capture has suffered a traumatic hard drive failure though
> so I need to get that fixed.
so trying this out on real hardware. Works great on a IIe platinum
(once I make sure I type all 63 bytes properly).
However my II+ boots up with MIXCLR/MIXSET in the "display bottom 4 lines of
text" mode, unlike the emulators or the IIe.
Is MIXSET specifically set during boot? Or is it set in hardware arbitrarily?
I can always set this manually but I'll need to find 2 bytes in order to
get it all fitting in 64B again.
Vince
|
|
|
|
| Re: flame demo -- 64 bytes [message #379387 is a reply to message #379380] |
Fri, 04 January 2019 14:28 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Fri, 4 Jan 2019, vince@pianoman.cluster.toy wrote:
> On 2019-01-04, vince@pianoman.cluster.toy <vince@pianoman.cluster.toy> wrote:
>>
>> I should really test this out on real hardware. The older mac-mini I always
>> used for video capture has suffered a traumatic hard drive failure though
>> so I need to get that fixed.
>
> so trying this out on real hardware. Works great on a IIe platinum
> (once I make sure I type all 63 bytes properly).
>
> However my II+ boots up with MIXCLR/MIXSET in the "display bottom 4 lines of
> text" mode, unlike the emulators or the IIe.
>
> Is MIXSET specifically set during boot? Or is it set in hardware arbitrarily?
>
> I can always set this manually but I'll need to find 2 bytes in order to
> get it all fitting in 64B again.
>
> Vince
>
FB43: AD 53 C0 LDA MIXSET
is called during the reset process.
-uso.
|
|
|
|
| Re: flame demo -- 64 bytes [message #379388 is a reply to message #379387] |
Fri, 04 January 2019 14:54 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2019-01-04, Steve Nickolas <usotsuki@buric.co> wrote:
>
> FB43: AD 53 C0 LDA MIXSET
>
> is called during the reset process.
I'm pretty sure the
FB3C: LDA #$00
FB3E: BEQ SETWND
skips over that, otherwise the machine would boot into graphics mode.
I just think the boot code doesn't bother to do anything with MIXSET/MIXCLR
because it doesn't matter in text mode and when you get around to GR or
HGR/HGR2 they all will set it then.
Vince
|
|
|
|
| Re: flame demo -- 64 bytes [message #379401 is a reply to message #379388] |
Fri, 04 January 2019 17:09 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
I managed to get it back to 64B again by using PHA/PLA to store the
random number seed on the stack rather than in $43, which thankfully
didn't seem to affect the output pattern.
So I've tested on II+ and IIe-platinum and both work fine now.
Updated version of the program:
70: 2C 50 C0 2C 52 C0 20 70 FC A9 FF 91 2A 88 10 FB A9 16 85 25 20 22 FC A0 27 68 F0 05 0A F0 04 90 02 49 1D 48 30 09 B1 28 29 07 AA B5 A8 91 28 88 10 E7 C6 25 10 DE 30 CE 00 BB 00 AA 00 99 00 DD
70G
Vince
|
|
|
|
|
|
| Re: flame demo -- 64 bytes [message #379420 is a reply to message #379402] |
Sat, 05 January 2019 00:57 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
I suspect that it's set (or not) randomly on older hardware.
It's not part of the start-up sequence. It's a power-on thing.
It's been set on all of the hardware that I've ever seen prior to the IIGS, but apparently you are unlucky and it's not set on yours.
I can offer another byte but it requires that X is #$00 on entry, which is unsafe.
|
|
|
|
| Re: flame demo -- 64 bytes [message #379422 is a reply to message #379420] |
Sat, 05 January 2019 01:04 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
The unfortunate side-effect of the PLA/PHA is that the seed is the constant value #$84 (the return address for the TOSUB call).
If you had another byte, then you could BIT $C052 -> LDA $C052/PHA.
|
|
|
|
| Re: flame demo -- 64 bytes [message #379425 is a reply to message #379422] |
Sat, 05 January 2019 01:46 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
I have an idea. It avoids the initial register value, but you still might not like it:
move color_progression to $A0. Entry point is now $A4. Then,
First "don't care" (at $A4) becomes #$A0.
Second "don't care" (at $A6) becomes #$B1.
BIT $C050 goes away(*).
$DD becomes #$B7 #$BF.
A4G
i.e. we get
LDY #$99
LDA ($DD), Y -> #$BFB7+#$99=#$C050
and 63 bytes.
(*) can be optionally replaced by PHA for more random init, and then the color_progression moves to $9F and entry is $A3 so that $DD maintains its place.
|
|
|
|
| Re: flame demo -- 64 bytes [message #379432 is a reply to message #379420] |
Sat, 05 January 2019 10:51 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2019-01-05, qkumba <peter.ferrie@gmail.com> wrote:
> I suspect that it's set (or not) randomly on older hardware. It's not
> part of the start-up sequence. It's a power-on thing. It's been set
> on all of the hardware that I've ever seen prior to the IIGS, but
> apparently you are unlucky and it's not set on yours.
yes, I made sure to test a few times and my II+ always seems to come
up with it set the other way.
Was digging through the schematics and the 74LS259 datasheet and I don't
think it is being initialized one way or another on the older machines.
Which makes sense, it doesn't really matter in normal use so why bother.
It's also quite possible I have a defective 74LS259 but the machine seems
to run properly otherwise.
I'd assume that maybe when they moved to ASICs on the newer machines it'd
be much easier to have all the latches be set to a known state at boot.
Vince
|
|
|
|
| Re: flame demo -- 64 bytes [message #379433 is a reply to message #379422] |
Sat, 05 January 2019 11:22 |
Vince Weaver
Messages: 136
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On 2019-01-05, qkumba <peter.ferrie@gmail.com> wrote:
> The unfortunate side-effect of the PLA/PHA is that the seed is the
> constant value #$84 (the return address for the TOSUB call). If you
> had another byte, then you could BIT $C052 -> LDA $C052/PHA.
I might be OK with the seed not being truly random, as I think possibly
the effect doesn't look as cool with certain values.
The pla/pha code generates the same pattern as using SEEDL but that I
thought was being randomized on keypress and since I am horrible at
entering hex values (especially on the II+ which had a dodgy keyboard)
it in theory should have been random each time I ran it on realy harware?
It's still too early in the morning to be building a mental map of the
6502 stack behavior in my head, I might not be thinking about this right.
Vince
|
|
|
|
| Re: flame demo -- 64 bytes [message #379436 is a reply to message #379433] |
Sat, 05 January 2019 13:07 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
SEEDL is altered by ROM while waiting for keyboard input. The longer that you wait between keypresses, the higher the values in SEEDL/H.
Of course, that PRNG might convergein a short period to the same values as for #$84 seed and make it indistinguishable.
|
|
|
|
| Re: flame demo -- 64 bytes [message #379483 is a reply to message #379433] |
Mon, 07 January 2019 12:42 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
> I might be OK with the seed not being truly random, as I think possibly
> the effect doesn't look as cool with certain values.
Fair enough. If you ever change your mind, the 63 bytes version that I posted earlier has space to enable it.
|
|
|
|
Members
Search
Help
Register
Login
Home
