Interesting

[José Pereira]

lax #imm is opcode $AB

Though its behaviour is properly unstable for values other than $00..

http://vice-emu.svn....eneral/ane-lax/

http://noname.c64.or...1&topicid=30951

 

I'm just guessing that might be the cause of it.. I started using that very heavily in this stuff when I realised I can do fast 16bit negates leaving the result in AX like so:

    lax #$00
    sbx #lo
    sbc #hi

 

It could well be simply the POKEY emulation..

 

About illegal I think some of you will like to read this:

http://translate.google.com/translate?client=tmpg&hl=pl&langpair=pl%7Cen&rurl=translate.google.com&twu=1&u=http://atariarea.krap.pl

[andym00]

Not sure which bit I should be reading there... Did you mean to post a link to a specific article or post ?

But, you have just given me an idea, well the 'atari sounds for the masses' thing did

[phaeron]

The problem is the INC $D20E instruction in the IRQ handler. On an NMOS 6502, a read-modify-write instruction first does a read of the address, followed by a write of the same value back to that address, followed by a write with the correct result. In this case it has the effect of acknowledging the timer #4 IRQ. Atari800 doesn't appear to emulate the false write and this prevents the IRQ routine from acknowledging the IRQ, locking the CPU into a loop.

 

This technique won't work on a 65C02 or 65C816, by the way, because the CMOS variants do a false read instead of a false write. However, that's a moot point in this case with the invalid instruction usage.

[simonl]

The problem is the INC $D20E instruction in the IRQ handler. On an NMOS 6502, a read-modify-write instruction first does a read of the address, followed by a write of the same value back to that address, followed by a write with the correct result. In this case it has the effect of acknowledging the timer #4 IRQ. Atari800 doesn't appear to emulate the false write and this prevents the IRQ routine from acknowledging the IRQ, locking the CPU into a loop.

 

Well spotted, it only emulates the false writes for GTIA registers as far as I can see i.e. in the cycle exact version of the RMW_GetByte macro in cpu.c

 

if ((addr & 0xef00) == 0xc000)

 

After a quick hack to to add in $D20E to the above it's generating a pretty listenable version of the tune!

 

Thanks for the help guys,

 

Simon

Edited March 16, 2012 by simonl

[andym00]

The problem is the INC $D20E instruction in the IRQ handler. On an NMOS 6502, a read-modify-write instruction first does a read of the address, followed by a write of the same value back to that address, followed by a write with the correct result. In this case it has the effect of acknowledging the timer #4 IRQ. Atari800 doesn't appear to emulate the false write and this prevents the IRQ routine from acknowledging the IRQ, locking the CPU into a loop.

 

This technique won't work on a 65C02 or 65C816, by the way, because the CMOS variants do a false read instead of a false write. However, that's a moot point in this case with the invalid instruction usage.

 

Oh, that'll teach me to take that stuff for granted in emulators in this day and age.. I figured everyone had been emulating correct RMW behaviour for ages..

Incidentally, how on earth did you find that without a debugger ?

[Heaven/TQA]

you are all nerds & geeks...

[flashjazzcat]

lax #imm is opcode $AB

Though its behaviour is properly unstable for values other than $00..

http://vice-emu.svn....eneral/ane-lax/

http://noname.c64.or...1&topicid=30951

 

I'm just guessing that might be the cause of it.. I started using that very heavily in this stuff when I realised I can do fast 16bit negates leaving the result in AX like so:

 lax #$00
 sbx #lo
 sbc #hi

 

It could well be simply the POKEY emulation..

 

Andy, I'm getting an addressing mode error when attempting to use LAX #imm in MADS. I'm using a lot of signed 16 bit arithmetic in the GUI, so this technique could be really useful. Of course I can set up a macro to get around the error problem.

[simonl]

Andy, I'm getting an addressing mode error when attempting to use LAX #imm in MADS. I'm using a lot of signed 16 bit arithmetic in the GUI, so this technique could be really useful. Of course I can set up a macro to get around the error problem.

 

Does MADS use ANX #$xx rather than LAX #$xx?

 

you are all nerds & geeks...

 

Sad but true!

 

Cheers,

 

Simon

[flashjazzcat]

Does MADS use ANX #$xx rather than LAX #$xx?

 

T'would appear so. Thank you!

[andym00]

Andy, I'm getting an addressing mode error when attempting to use LAX #imm in MADS. I'm using a lot of signed 16 bit arithmetic in the GUI, so this technique could be really useful. Of course I can set up a macro to get around the error problem.

 

I had modify ACME when I wanted to start using that instruction, well that addressing mode, and I guess only some assemblers support the immediate version, unless the author just carpet bombed the instruction set and implemented everything they could find.. I think up until fairly recently it was considered an off limits illegal instruction simply because it was so volatile, but now it's clear there's a few cases where it's stable and it's starting to get a bit more use, well I speak for myself there anyway..

The odd thing is that it doesn't turn up in many of the documents about illegals..

 

If you're feeling brave:

 lda #$ff
 lax #any_value

is good as well by all counts, though I've yet to convince myself that I trust it yet

 

That 16bit negate, can also do two 8 bit negates as well.. Either by setting the carry after the sbx, or by skip the sec and instead adjusting your 2nd parameter by one because the carry will always be clear after the sbx.. Depends on what data you have where at what times I guess Still saves some cycles in those odd handy cases where things are all in the right place..

 

edit: As long is it generate opcode $AB it's the one

[flashjazzcat]

Thanks Andy. I'm working on clipping routines at the moment so this is all useful. I don't want to become reliant on anything unsafe, though. Saving a few cycles on negates will really mount up when you're drawing dozens of objects in the tree.

[andym00]

I can imagine that it's 16bit hell in there..

Don't know if you're aiming for only 65xxs, but if you want to run on 65C02 & 65816 processors then steer clear of the illegals..

Edited March 16, 2012 by andym00

[flashjazzcat]

I can imagine that it's 16bit hell in there..

Don't know if you're aiming for only NMOS 65xxs, but if you want to run on 65816 processors and CMOS ones then steer clear of the illegals..

 

Heh... pretty much, but everything's reduced to 8-bit where appropriate - certainly by the time it hits the screen. Good point regarding the 65816. The cycle savings with the illegals are often marginal, but like you say it depends on the situation and the application. There's still a lot of fun to be had figuring out efficient, unorthodox methods using the official instruction set.

[phaeron]

The problem is the INC $D20E instruction in the IRQ handler. On an NMOS 6502, a read-modify-write instruction first does a read of the address, followed by a write of the same value back to that address, followed by a write with the correct result. In this case it has the effect of acknowledging the timer #4 IRQ. Atari800 doesn't appear to emulate the false write and this prevents the IRQ routine from acknowledging the IRQ, locking the CPU into a loop.

 

This technique won't work on a 65C02 or 65C816, by the way, because the CMOS variants do a false read instead of a false write. However, that's a moot point in this case with the invalid instruction usage.

 

Oh, that'll teach me to take that stuff for granted in emulators in this day and age.. I figured everyone had been emulating correct RMW behaviour for ages..

Incidentally, how on earth did you find that without a debugger ?

 

Who said anything about not having a debugger?

 

Just hit F8 in Atari800. It's almost unusable in the Windows build since every time you step it reselects the display window, but it was enough to track down the problem.

[andym00]

Who said anything about not having a debugger?

 

Just hit F8 in Atari800. It's almost unusable in the Windows build since every time you step it reselects the display window, but it was enough to track down the problem.

 

Gah.. I went through the menus and things and couldn't see any mention of anything debugger related and assumed it didn't have one..

As for using it, I don't think so.. Altirra is the best thing since sliced bread, especially in the debugger department