Jump to content
xxl

Acid800 test, illegal instructions

Recommended Posts

OK. There's an ATR. I run the ATR on about six machines. The 800 doesn't pass illegal instructions, but it isn't an XL machine. 1200XL fails BASIC ROM banking, which isn't suprising, there is no BASIC ROM.

You looking for some modified XL/XE?

Share this post


Link to post
Share on other sites

no, only unmodified atari xl/xe (standard CPU)

Share this post


Link to post
Share on other sites

Ran this on my stock 800XL...passed everything

Ran this on Atari800MacX, only passed 22 of the tests!

Share this post


Link to post
Share on other sites

Ran this on my stock 800XL...passed everything

Ran this on Atari800MacX, only passed 22 of the tests!

 

...Correct, the 800XL passes everything.

 

On Altirra, it all boils down to one (1) particular test not passing, IIRC.

Share this post


Link to post
Share on other sites

The reason the archive explodes so much when unpacked is that it also contains full source code and symbols for all of the standalone tests.

 

Anyone who's getting a failure on the illegal instruction test on real hardware -- can you read off the error details? It'll print out a blurb like this:

CPU: Illegal instructions... FAIL.
Test failed: A=55 X=00 Y=00 P=B0 M=00
 Insn: 0B 55 60

This printout says what instruction sub-test tripped the failure and what the result registers were, which I can use to fix the test.

 

Remember that this test is basically designed to be an emulator/hardware breaker, so it tests a lot of things that are rarely hit in actual programs.

 

Atari800MacX is based on Atari800 and should be passing the CPU illegal instruction test. AFAIK, the two emulators that don't on their tip versions are kat5200 and Atari++ (I forget whether Pantheon did).

Share this post


Link to post
Share on other sites

all xl/xe will pass the illegal instructions test...

 

@phaeron

$AB - this code is stable?

AtariWinPlus do not emulate $9E,$9C but passes Your test. Acid800 do not check what happens when page boundary is crossed. Please update.

Share this post


Link to post
Share on other sites

The reason the archive explodes so much when unpacked is that it also contains full source code and symbols for all of the standalone tests.

 

Anyone who's getting a failure on the illegal instruction test on real hardware -- can you read off the error details? It'll print out a blurb like this:

CPU: Illegal instructions... FAIL.
Test failed: A=55 X=00 Y=00 P=B0 M=00
 Insn: 0B 55 60

This printout says what instruction sub-test tripped the failure and what the result registers were, which I can use to fix the test.

 

Remember that this test is basically designed to be an emulator/hardware breaker, so it tests a lot of things that are rarely hit in actual programs.

 

Atari800MacX is based on Atari800 and should be passing the CPU illegal instruction test. AFAIK, the two emulators that don't on their tip versions are kat5200 and Atari++ (I forget whether Pantheon did).

After setting the option to halt the tests at FAIL, the stock 800 with 48K memory failed the 'illegal instruction test' and the BASIC banking test (it has no BASIC).

 

CPU: Illegal instructions.... FAIL

Test failed: A=55 X=55 Y=00 P=30 M=00

Insn: AB 55 60

 

This isn't an XL/XE machine, but I ran it anyway. I suppose it has a different CPU.

 

I don't know where I got BASIC banking. It is ..

MMU: XL banking....FAIL

Unable to bank out ROMs: mask=$03

I guess it is talking about XL/XE BASIC built-in ROM

Edited by russg

Share this post


Link to post
Share on other sites

Here's a newer version of the test. I've excluded the $AB opcode and added page crossing tests for opcodes $9C and $9E. It passes on my 800XL and 130XE. There are additional tests and fixes in this version since 0.9, listed in the README.

 

And yes, you will get failures on the 400/800 and 1200XL for hardware features that don't exist in those models.

Acid800-1.0beta.zip

Share this post


Link to post
Share on other sites

Looking forAtari XL / XE (standard 6502c Sally) which does not passthe cpu illegal instructionstest.

 

http://www.virtualdu.../Acid800-0.9.7z

 

Ran this on my Pal 800. It passed all tests apart from basic switching (no basic). It has a atari 6502c like xl-xe.

 

Just ran 2nd version again on pal 800. Passed all except for basic.

 

James

Edited by sup8pdct

Share this post


Link to post
Share on other sites

Here's a newer version of the test. I've excluded the $AB opcode and added page crossing tests for opcodes $9C and $9E. It passes on my 800XL and 130XE. There are additional tests and fixes in this version since 0.9, listed in the README.

 

And yes, you will get failures on the 400/800 and 1200XL for hardware features that don't exist in those models.

 

Now this beta passes all but MMU banking on stock NTSC 800 with 48K memory. Passed: 50 Failed 1 Skipped 0

It needs some work I think. About half way thru, the GRAPHICS 0 screen splits in half and the results screens are on two lines, like so:

 

 

trol test ..... Pass GTIA: Default valu

e... Pass GTIA: Phantom PMG

DMA... Pass GTIA: CONSOL test.

.. Pass etc.

 

AtariAge editor doesn't show the way I type.. The GTIA are all lined up 2/3 way across the screen.

I think the program is messing up the left margin.

Edited by russg

Share this post


Link to post
Share on other sites

===> TWO (2) FAILED TESTS on non-XL/XE machine <===

 

Ran v1.0-Beta of AcidTEST on my 48K completely-stock (and unmodified) Atari, with SDrive-NUXX active, and one unexpected error is coming-up:

 

POKEY: Direct Serial Input... FAIL. Received byte was not NAK: 41

MMU: XL Banking... FAIL. (this is expected, though).

 

SIO speed multiplier was set to 06 (69Kbps), on SDRive-NUXX setup menu... Will have to test this version on my 800-XL, and see how it goes...

Share this post


Link to post
Share on other sites

Ran v1.0-Beta of AcidTEST on my 48K completely-stock (and unmodified) Atari, with SDrive-NUXX active, and one unexpected error is coming-up:

 

POKEY: Direct Serial Input... FAIL. Received byte was not NAK: 41

 

Uhhh... this means that your SDrive-NUXX is sending back an ACK to a request to read sector 0. That's not supposed to work....

Share this post


Link to post
Share on other sites

Here's a newer version of the test. I've excluded the $AB opcode and added page crossing tests for opcodes $9C and $9E. It passes on my 800XL and 130XE. There are additional tests and fixes in this version since 0.9, listed in the README.

 

And yes, you will get failures on the 400/800 and 1200XL for hardware features that don't exist in those models.

 

Now this beta passes all but MMU banking on stock NTSC 800 with 48K memory. Passed: 50 Failed 1 Skipped 0

It needs some work I think. About half way thru, the GRAPHICS 0 screen splits in half and the results screens are on two lines, like so:

 

 

trol test ..... Pass GTIA: Default valu

e... Pass GTIA: Phantom PMG

DMA... Pass GTIA: CONSOL test.

.. Pass etc.

 

AtariAge editor doesn't show the way I type.. The GTIA are all lined up 2/3 way across the screen.

I think the program is messing up the left margin.

 

UPDATE: The program doesn't start printing half way accross. It is printing correctly. I tried to repeat what I saw before. It is fine.

Share this post


Link to post
Share on other sites

Ran v1.0-Beta of AcidTEST on my 48K completely-stock (and unmodified) Atari, with SDrive-NUXX active, and one unexpected error is coming-up:

 

POKEY: Direct Serial Input... FAIL. Received byte was not NAK: 41

 

Uhhh... this means that your SDrive-NUXX is sending back an ACK to a request to read sector 0. That's not supposed to work....

 

UPDATE:

 

I tried Acid-1.0 on my 800-XL, with same SDrive, and I am getting the same error... The funny thing is that I NEVER got that error on Acid-0.9...

 

Yes, the SDrive is the common element here, but also the change of SW version. Therefore, something is fishy. I will try different SIO speed rates, and see how it goes.

 

F.

Share this post


Link to post
Share on other sites

I Avery.

 

I tested Acid800 v1.0 beta with a stock 800XL PAL + SIO2SD and all test passed.

Share this post


Link to post
Share on other sites

The reason why the POKEY: Direct Serial Input test wasn't failing on 0.9 is simple... that version didn't have that test. It was something I'd added afterward to detect emulators that are are pushing bytes directly to SERIN without also reflecting the bitstream in SKSTAT bit 4 (including Altirra). What it does is send a Read Sector command to D1: for sector 0, then it polls SKSTAT and manually reads off the bits of the NAK byte. I should probably add an SIOV test for this case so that it skips the test if D1: doesn't respond or otherwise actually does accept a read sector 0 request.

 

But anyway, not to hijack the thread....

 

The illegal instruction test in Acid800 does basic tests on a whole bunch of instructions, but it isn't an exhaustive test. It consists of a series of test cases that look like this:

  	 ;	   insn		  A   X   Y   P   M    A   X   Y   P   M
       ;SLO (zp,X) (ASL + ORA)
       dta        $03,<a0,$60, $00,$02,$00,$30,$81, $02,$02,$00,$31,$02
       dta        $03,<a0,$60, $f0,$02,$00,$30,$81, $f2,$02,$00,$b1,$02

 

The first three bytes are the instruction, the next five bytes are the input register state and value for the D5 memory location, and the last five bytes are the result state. The test list is in src/Acid800/source/cpu_illegal.s in the archive. If anyone has requests or suggestions for additional test cases, I can easily add them. The intent is for this test to succeed on all properly working Ataris, however, so I've been disabling marginal tests as they are discovered.

Share this post


Link to post
Share on other sites

The reason why the POKEY: Direct Serial Input test wasn't failing on 0.9 is simple... that version didn't have that test. It was something I'd added afterward to detect emulators that are are pushing bytes directly to SERIN without also reflecting the bitstream in SKSTAT bit 4 (including Altirra). What it does is send a Read Sector command to D1: for sector 0, then it polls SKSTAT and manually reads off the bits of the NAK byte. I should probably add an SIOV test for this case so that it skips the test if D1: doesn't respond or otherwise actually does accept a read sector 0 request.

 

(...)

 

 

Intuitively, I would simply suggest to enhance this particular test just a bit, by first checking devices already registered/existing prior to executing the mini-test, and then try addressing any "D" device that is actually not registered.

 

The issue here is that the whole suite of Acid does require constant reading from the host I/O device from where it is being booted/ran.

 

I am not sure if reading from Sector-0 is something particularly (and purposefully) supported by the NUXX drive implementation.

 

My 0.02c.

 

F.

Share this post


Link to post
Share on other sites

I am not sure if reading from Sector-0 is something particularly (and purposefully) supported by the NUXX drive implementation.

 

My 0.02c.

 

F.

 

The SDrive NUXX is really just an SDrive. It uses the same hardware and firmware. It's just dressed up real nice. So this may be a feature/bug/oversight in the firmware. I'd lean towards bug/oversight. I'm betting Acid800 is the first software to test for a sector zero read...

Share this post


Link to post
Share on other sites

 

The SDrive NUXX is really just an SDrive. It uses the same hardware and firmware. It's just dressed up real nice.

 

 

Minor correction: designed, manufactured and made a REAL, SOLID product, infinitely better than any shacko-SDdrive units I have seen so far.

 

 

 

(...) So this may be a feature/bug/oversight in the firmware. I'd lean towards bug/oversight. (...)

 

 

Completely agree here... but there is evidence on this thread of the OPPOSITE.

Share this post


Link to post
Share on other sites

The SDrive NUXX is really just an SDrive. It uses the same hardware and firmware. It's just dressed up real nice.

Minor correction: designed, manufactured and made a REAL, SOLID product, infinitely better than any shacko-SDdrive units I have seen so far.

I wasn't arguing with you. I worked with c0nsumer while he was designing the whole project. I've got a prototype, sans case, kicking around at home.

(...) So this may be a feature/bug/oversight in the firmware. I'd lean towards bug/oversight. (...)

Completely agree here... but there is evidence on this thread of the OPPOSITE.

Where's the evidence? I only see you trying your SDrive. The only "works for me" response was with an SIO2SD.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...