Jump to content
IGNORED

HW-Detect


Recommended Posts

Hi all,

 

Friends I publish this program that I developed to detect easily and quickly the hardware that our ATARI has, I would like to try it and tell me if it detects well. Any suggestions or improvements will also be welcome.

hw-detect.png

XEX : https://github.com/ascrnet/HW-Detect/releases
Source code : https://github.com/ascrnet/HW-Detect

Regards

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, Rybags said:

Does it give CPU speed?  A quick/dirty method would probably be to see how many register increments could be done in a certain VCount duration.

Does it give extra Ram info like type (Rambo, Compy) and if seperate Antic access is available?

It would be easier to detect the GTIA NTSC CPU speed = 1.79 MHz or PAL CPU speed = 1.77 MHz for the XL / XE / XEGS series

 

what I did is detect RAM from 65kb to 2112kb using the documentation of http://atariki.krap.pl/index.php/Obsługa_standardowego_rozszerzenia_pamięci_RAM

 

I didn't understand you about the ANTIC, if it's NTSC or PAL??

 

regards

Link to comment
Share on other sites

Well,

 

did a fast test with Atari 800 Win emulator. Almost all things worked fine (showed NTSC or PAL correctly, showed Basic Rev. correctly, etc.), but when I set the emulator to 1088k Rambo mode then control characters appeared at various places (top, bottom, etc.).

 

 

hardware_detect.jpg

Link to comment
Share on other sites

44 minutes ago, CharlieChaplin said:

Well,

 

did a fast test with Atari 800 Win emulator. Almost all things worked fine (showed NTSC or PAL correctly, showed Basic Rev. correctly, etc.), but when I set the emulator to 1088k Rambo mode then control characters appeared at various places (top, bottom, etc.).

 

hardware_detect.jpg

Thank you, version 1.1 is already fixed. I wait for tests on real hardware. ?

Regards

Link to comment
Share on other sites

Re CPU speed I was more along the lines of accelerators at 3.6, 7.2, 14.4 MHz.

Though of course yes, detecting Antic swaps would also be handy.  Though you can only really deduce that by the scanline maximum not matching what would be expected from the GTIA PAL register - and generally GTIA only swaps aren't done so you'd probably not worry too much.

If both chips are swapped though and the master clock is still the same, I don't think you'd be able to detect it (though it'd be a rarity and you'd have to ask why anyone would bother).

  • Like 1
Link to comment
Share on other sites

12 hours ago, Stephen said:

I'll try to make time to check this out tomorrow on my 1088XLD (PAL, U1MB, stereo, VBXE).

there's no hurry?
11 hours ago, Rybags said:

Re CPU speed I was more along the lines of accelerators at 3.6, 7.2, 14.4 MHz.

Though of course yes, detecting Antic swaps would also be handy.  Though you can only really deduce that by the scanline maximum not matching what would be expected from the GTIA PAL register - and generally GTIA only swaps aren't done so you'd probably not worry too much.

If both chips are swapped though and the master clock is still the same, I don't think you'd be able to detect it (though it'd be a rarity and you'd have to ask why anyone would bother).

I understand you but I think that 99% of users have the default CPU without acceleration. The same is also true for using different ANTIC and PAL chips.

 

I would like to be able to call the Missile Command in XEGS by pressing a key, I have tried it but without success. Other ideas would be to detect some custom OS like Qmeg among other things.

 

regards

Link to comment
Share on other sites

57 minutes ago, ascrnet said:

The same is also true for using different ANTIC and PAL chips.

You can establish whether ANTIC is PAL or NTSC by looping on VCOUNT until it flips over to zero (or reads less than the currently recorded value), which gives you the maximum VCOUNT value. If it reaches $9B, ANTIC is PAL. Coupled with the GTIA PAL bit, you can then denote ANTIC as an FPS value:

 

NTSC/60

PAL/50

PAL/60

or NTSC/50

 

Since it takes barely any extra code to accomplish this, it's possibly worth including.

1 hour ago, ascrnet said:

I would like to be able to call the Missile Command in XEGS by pressing a key

You can establish whether the machine is an XEGS by clearing bit 6 of PORTB and checking for RAM in the cartridge address space. If ROM if found, you could initialise and start the cartridge with a few lines of code.

 

I suppose you could do other things such as checking for RAM under the OS, etc, and thereby be able to report the host machine as a 400/800, XL/XE, or XEGS.

  • Like 2
Link to comment
Share on other sites

4 hours ago, flashjazzcat said:

You can establish whether ANTIC is PAL or NTSC by looping on VCOUNT until it flips over to zero (or reads less than the currently recorded value), which gives you the maximum VCOUNT value. If it reaches $9B, ANTIC is PAL. Coupled with the GTIA PAL bit, you can then denote ANTIC as an FPS value:

 

NTSC/60

PAL/50

PAL/60

or NTSC/50

 

Since it takes barely any extra code to accomplish this, it's possibly worth including.

You can establish whether the machine is an XEGS by clearing bit 6 of PORTB and checking for RAM in the cartridge address space. If ROM if found, you could initialise and start the cartridge with a few lines of code.

 

I suppose you could do other things such as checking for RAM under the OS, etc, and thereby be able to report the host machine as a 400/800, XL/XE, or XEGS.

thanks for the explanation for the detection of the ANTIC ?

 

ok, I detect the XEGS when the OS is version 4. but it doesn't work for me when I call $5000 for the game?

 

3 hours ago, tebe said:

Thanks for the information and the example, I will review it?

55 minutes ago, ivop said:

I assume to differentiate between NMOS and CMOS? Could you elaborate?

 

The NMOS 6502 / 6502C, CMOS 65c02 and CMOS 65c816 CPUs are detected. It is a routine published in Mads section CPU DETECTION http://mads.atari8.info/mads_eng.html

 

regards

 

Link to comment
Share on other sites

On 11/6/2019 at 10:16 PM, ascrnet said:

Thank you, version 1.1 is already fixed. I wait for tests on real hardware. ?

 

If it's possible to establish whether ANTIC is PAL or NTSC, is it possible to join 2 xex files (NTSC and PAL) into a single one, auto-detecting what part must be executed?

 

Example: let's say having game(NTSC).xex and game(PAL).xex (already compiled .xex). Is it possible to make an unique file game(NTSC-PAL).xex ?

 

 

Link to comment
Share on other sites

You could but it'd be wasteful to have an entire game replicated in such a way.

 

Generally there's not much in the way of differences.  An easy way could be to have a patcher that loads after the main part of the file.  Have an Init section before the patcher to see if it's needed and if not, just don't continue the load process.

Link to comment
Share on other sites

19 hours ago, flashjazzcat said:

The ROM is at $A000-$BFFF, so you should initialise and start as per the OS cart initialisation code using the vectors at $BFFx (have a look at the Altirra OS source code for a good example of this).

 

19 hours ago, Rybags said:

To run the Missile Command you'd also want to clear the WARMST flag (08) so that it does it's initial setup properly.

thanks colleagues for the information ?

 

15 hours ago, tane said:

 

If it's possible to establish whether ANTIC is PAL or NTSC, is it possible to join 2 xex files (NTSC and PAL) into a single one, auto-detecting what part must be executed?

 

Example: let's say having game(NTSC).xex and game(PAL).xex (already compiled .xex). Is it possible to make an unique file game(NTSC-PAL).xex ?

 

 

 

Yes it can but it takes a long time since each game is a different world. I think it's easier to patch the game like that. At the moment my knowledge is few to make a patch from PAL to NTSC as you want. ?

 

regards
Link to comment
Share on other sites

13 minutes ago, ascrnet said:

New version 1.2

There's a bug at the top of .proc @ANTIC. 'max' variable is executed as a BRK instruction and skips first byte of 'LDA VCOUNT', resulting in an 'ANC #$D4' instruction being executed instead on the first loop iteration. Not fatal, though. :)

 

  • Like 1
Link to comment
Share on other sites

On 11/9/2019 at 7:39 PM, flashjazzcat said:

There's a bug at the top of .proc @ANTIC. 'max' variable is executed as a BRK instruction and skips first byte of 'LDA VCOUNT', resulting in an 'ANC #$D4' instruction being executed instead on the first loop iteration. Not fatal, though. :)

 

? Thank you very much for the warning, I will change it !!!?

Regards

Link to comment
Share on other sites

If you want to support an array of memory expansions and older 400/800 then a contiguous Ram test from $3FF0 to $CFF0 in steps of 4K is probably a good idea (so 52K would also work).

Not sure how the 52K and 64K schemes work on the 400/800 - I think some use $CFFF as a banking register.

Link to comment
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...