Jump to content

Photo

Interesting

someone has been enlightet

89 replies to this topic

#76 José Pereira OFFLINE  

José Pereira

    River Patroller

  • 3,306 posts
  • Location:Lisbon - Portugal

Posted Thu Mar 15, 2012 1:24 PM

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...8;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.goo...ariarea.krap.pl

#77 andym00 OFFLINE  

andym00

    Stargunner

  • 1,036 posts
  • Location:A geordie cowfield...

Posted Thu Mar 15, 2012 1:36 PM

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 :)

#78 phaeron OFFLINE  

phaeron

    Stargunner

  • 1,106 posts
  • Location:USA

Posted Thu Mar 15, 2012 9:45 PM

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.

#79 simonl OFFLINE  

simonl

    Chopper Commander

  • 160 posts
  • Location:UK

Posted Fri Mar 16, 2012 2:07 AM

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 by simonl, Fri Mar 16, 2012 2:12 AM.


#80 andym00 OFFLINE  

andym00

    Stargunner

  • 1,036 posts
  • Location:A geordie cowfield...

Posted Fri Mar 16, 2012 2:50 AM

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 ?

#81 Heaven/TQA OFFLINE  

Heaven/TQA

    Quadrunner

  • 8,700 posts
  • Location:Baden-Württemberg, Germany

Posted Fri Mar 16, 2012 5:10 AM

you are all nerds & geeks... ;)

#82 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 7,753 posts
  • Location:United Kingdom

Posted Fri Mar 16, 2012 5:27 AM

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.

#83 simonl OFFLINE  

simonl

    Chopper Commander

  • 160 posts
  • Location:UK

Posted Fri Mar 16, 2012 5:41 AM

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! :grin:

Cheers,

Simon

#84 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 7,753 posts
  • Location:United Kingdom

Posted Fri Mar 16, 2012 5:43 AM

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


T'would appear so. Thank you! :)

#85 andym00 OFFLINE  

andym00

    Stargunner

  • 1,036 posts
  • Location:A geordie cowfield...

Posted Fri Mar 16, 2012 5:45 AM

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 :)

#86 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 7,753 posts
  • Location:United Kingdom

Posted Fri Mar 16, 2012 5:49 AM

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.

#87 andym00 OFFLINE  

andym00

    Stargunner

  • 1,036 posts
  • Location:A geordie cowfield...

Posted Fri Mar 16, 2012 5:53 AM

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 by andym00, Fri Mar 16, 2012 6:02 AM.


#88 flashjazzcat OFFLINE  

flashjazzcat

    Quadrunner

  • 7,753 posts
  • Location:United Kingdom

Posted Fri Mar 16, 2012 5:57 AM

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.

#89 phaeron OFFLINE  

phaeron

    Stargunner

  • 1,106 posts
  • Location:USA

Posted Fri Mar 16, 2012 2:06 PM


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.

#90 andym00 OFFLINE  

andym00

    Stargunner

  • 1,036 posts
  • Location:A geordie cowfield...

Posted Fri Mar 16, 2012 2:28 PM

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 ;)




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users