Jump to content

Recommended Posts

1 hour ago, Rybags said:

CTIA is very rare - supposedly only went into production machines for less than 18 months.

Lots of people would have taken the upgrade offer which means even more rare.

 

Detection method - the only thing I can think of besides setting up a mode and prompting the user is PM collisions.

Unsure if that'll work.  PMs can work a bit differently when GTIA modes are enabled.

It is relatively easy, using P/M collision registers:

GRAPHICS 0
PMGRAPHICS 2
? "X"

POKE 623, 64
PAUSE 0

SETCOLOR -4,4,10
PMHPOS 0, 100
MSET PMADR(0) + 16, 16, 255

POKE $D01E, 1
PAUSE 0
CHK = PEEK($D004)

PAUSE 0
POKE $D01E, 1
PAUSE 0
PMHPOS 0, 54
PAUSE 0
TEST = PEEK($D004)
PAUSE 0

PMHPOS 0, 100
POKE 623, 0

GR.0

IF CHK
  ? "CHECK ERROR!"
ENDIF

IF TEST = 4
  ? "CTIA"
ELIF TEST = 0
  ? "GTIA"
ELSE
  ? "ERROR!"
ENDIF

REPEAT: UNTIL KEY()

Have Fun!

  • Like 4

Share this post


Link to post
Share on other sites
On 8/10/2020 at 9:50 PM, dmsc said:

It is relatively easy, using P/M collision registers:

GRAPHICS 0
PMGRAPHICS 2
? "X"

POKE 623, 64
PAUSE 0

SETCOLOR -4,4,10
PMHPOS 0, 100
MSET PMADR(0) + 16, 16, 255

POKE $D01E, 1
PAUSE 0
CHK = PEEK($D004)

PAUSE 0
POKE $D01E, 1
PAUSE 0
PMHPOS 0, 54
PAUSE 0
TEST = PEEK($D004)
PAUSE 0

PMHPOS 0, 100
POKE 623, 0

GR.0

IF CHK
  ? "CHECK ERROR!"
ENDIF

IF TEST = 4
  ? "CTIA"
ELIF TEST = 0
  ? "GTIA"
ELSE
  ? "ERROR!"
ENDIF

REPEAT: UNTIL KEY()

Have Fun!

thank you for the example but does not detect CTI/GTIA well with FB 4.3 interpreter and using altirra XL/XE with CTIA😅

Share this post


Link to post
Share on other sites
3 hours ago, ascrnet said:

thank you for the example but does not detect CTI/GTIA well with FB 4.3 interpreter and using altirra XL/XE with CTIA😅

It does, but you need adjust the second PMHPOS position for where the X ends up horizontally on screen, specifically 48 for a left margin of 0. Running from the interpreter, 54 is too far right.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
On 8/12/2020 at 9:22 PM, phaeron said:

It does, but you need adjust the second PMHPOS position for where the X ends up horizontally on screen, specifically 48 for a left margin of 0. Running from the interpreter, 54 is too far right.

Thanks for the explanation, although my goal was to do the same but from an assembler.😅

 

This version if it detects the CTIA or GTIA chip of the ATARI cost me a bit but it works at least in the emulator. in case someone wants to test it in the real hardware

hw-detect_test5.xex

 

now i will go back to detecting 48k of ram, i detect 16k and 32k without problems but 48k not. i will keep investigating .....😅

Share this post


Link to post
Share on other sites
16 hours ago, ascrnet said:

Thanks for the explanation, although my goal was to do the same but from an assembler.😅

 

This version if it detects the CTIA or GTIA chip of the ATARI cost me a bit but it works at least in the emulator. in case someone wants to test it in the real hardware

hw-detect_test5.xex 4.04 kB · 5 downloads

 

now i will go back to detecting 48k of ram, i detect 16k and 32k without problems but 48k not. i will keep investigating .....😅

I ran it on my Atari and it detected now correctly GTIA=PAL :) looks ok; I guess more people with NTSC systems should test. 

IMG_2202.JPG

Share this post


Link to post
Share on other sites
5 hours ago, mikesk8 said:

I ran it on my Atari and it detected now correctly GTIA=PAL :) looks ok; I guess more people with NTSC systems should test. 

 

Thank you so much for your feedback.👍

  • Thanks 1

Share this post


Link to post
Share on other sites
21 hours ago, ascrnet said:

Thank you so much for your feedback.👍

Welcome:) Thank you for your work! Please let me know once the memory part will be ready and I will test it :)

  • Thanks 1

Share this post


Link to post
Share on other sites
On 8/15/2020 at 5:25 PM, mikesk8 said:

Welcome:) Thank you for your work! Please let me know once the memory part will be ready and I will test it :)

This version detects the following ram sizes 24k, 32k, 40k and 48k.😁

hw-detect_test6.xex

Now the application works with at least 24k, because of the latest improvements... 

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, ascrnet said:

This version detects the following ram sizes 24k, 32k, 40k and 48k.😁

hw-detect_test6.xex 4.1 kB · 2 downloads

Now the application works with at least 24k, because of the latest improvements... 

Super, thank you. I will test it and let you know. I think there are quite few Atari 400 machine with only 16k (max in stock configuration) left; not sure how many Atari 800 with 8k (initial setup). I guess 16k detection would help :)

Share this post


Link to post
Share on other sites

Here is the test - 48k detected on my Atari 800 (48k) - all good :) I hope other people with different memory sizes will test too.

IMG_2259.JPG

Share this post


Link to post
Share on other sites
6 hours ago, mikesk8 said:

Here is the test - 48k detected on my Atari 800 (48k) - all good :) I hope other people with different memory sizes will test too.

IMG_2259.JPG

thanks for the test😁, you can test it in 24k, 32k, 40k by taking out RAM modules in your 800?😇

Share this post


Link to post
Share on other sites
6 hours ago, ascrnet said:

thanks for the test😁, you can test it in 24k, 32k, 40k by taking out RAM modules in your 800?😇

Majority of Atari 800 have 48k in 3 modules of 16k, meaning we can test 16/32/48k only. 

Share this post


Link to post
Share on other sites
20 hours ago, mikesk8 said:

Majority of Atari 800 have 48k in 3 modules of 16k, meaning we can test 16/32/48k only. 

Perfect, when you have time try it with 2 modules of 16 or 32k. I hope to have soon some time to see why it does not work in 16k as version 1.5 does. 🙄

Share this post


Link to post
Share on other sites

Did you get it to test 800s for 52K?

 

There was an upgrade BitD that added 4K from $C000-$CFFF.

 

 

Share this post


Link to post
Share on other sites
10 hours ago, StickJock said:

Did you get it to test 800s for 52K?

 

There was an upgrade BitD that added 4K from $C000-$CFFF.

I'm sorry it doesn't detect 52kb in 800, what I do is detect CC00 where is the second character set that is exclusive of XL/XE to know if it is an older equipment since I didn't think how to differentiate them. 😅

Share this post


Link to post
Share on other sites

There's multiple >48K upgrades for 400/800.

 

I don't have the definitive information but AFAIK, one of them uses a 16K window at $4000 in similar fashion to the 130XE (don't know how banking is done)

 

The one presenting 52K - possibly there's a 52K only one but I've read of a 64K one that presents the 4K window at $C000 and uses $CFFF as the banking register.

So for testing 52K, probably a good idea to try location $C000.

 

You probably already know but to test for RAM it's a good idea to store 2 distinct values and test for them in the one location - noting some "non RAM" addresses can return 00, FF or an address reflection depending on machine.

Share this post


Link to post
Share on other sites
25 minutes ago, Rybags said:

There's multiple >48K upgrades for 400/800.

 

I don't have the definitive information but AFAIK, one of them uses a 16K window at $4000 in similar fashion to the 130XE (don't know how banking is done)

 

The one presenting 52K - possibly there's a 52K only one but I've read of a 64K one that presents the 4K window at $C000 and uses $CFFF as the banking register.

So for testing 52K, probably a good idea to try location $C000.

 

You probably already know but to test for RAM it's a good idea to store 2 distinct values and test for them in the one location - noting some "non RAM" addresses can return 00, FF or an address reflection depending on machine.

Fully agree there are 400/800 with more RAM

 

I did the typical thing to go saving bytes and reading them to detect the RAM up to 40kb I had no problem in the detection, but 48kb (A000) or 52kb (C000) does not work is like I can not save anything in those areas when I did my tests.🙄

 

Surely there is something I am not understanding.😅

Share this post


Link to post
Share on other sites

The OS tests for RAM on 4K boundaries which is more than sufficient.  The only exception I can think of there would be the rare case where you might replace the FP Rom with an SRAM (or possibly some mods exist that put switchable Ram in that little 2K hole)

 

So really all you'd need to do is check locations $xFF0 (staying away from $CFFF  which I'm fairly sure can be a banking register).

Generally all you need to do is save what's there, then do a test store of 2 different values and verify if they read back.  Then restore original contents if it's found to be Ram.

 

The 40 and 48K thing is no great mystery.  What can hinder you there is if a cartridge is inserted since it can mask part or all of the area.

In theory a Right Cartridge could mask the 32-40K area and leave 40-48K as RAM.  But in practice the Monkey Wrench is generally used with the factory Basic cart in the other slot.

Share this post


Link to post
Share on other sites
On 9/1/2020 at 5:13 AM, Rybags said:

The OS tests for RAM on 4K boundaries which is more than sufficient.  The only exception I can think of there would be the rare case where you might replace the FP Rom with an SRAM (or possibly some mods exist that put switchable Ram in that little 2K hole)

 

So really all you'd need to do is check locations $xFF0 (staying away from $CFFF  which I'm fairly sure can be a banking register).

Generally all you need to do is save what's there, then do a test store of 2 different values and verify if they read back.  Then restore original contents if it's found to be Ram.

 

The 40 and 48K thing is no great mystery.  What can hinder you there is if a cartridge is inserted since it can mask part or all of the area.

In theory a Right Cartridge could mask the 32-40K area and leave 40-48K as RAM.  But in practice the Monkey Wrench is generally used with the factory Basic cart in the other slot.

Thank you for the information, but I focus on the more common than extraordinary cases.

 

I already understood that it happens, I detect well 48k and 52k for 400/800. The problem I have it if it is XL/XE since I cannot record anything in C000 because from here it is part of the ROM.😅

Share this post


Link to post
Share on other sites

XL/XE you just disable interrupts then switch out the OS.

A successful test of addresses $C000 and $E000 would probably be sufficient to assume a 64K or better system.

  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites
On 9/3/2020 at 11:09 AM, Rybags said:

XL/XE you just disable interrupts then switch out the OS.

A successful test of addresses $C000 and $E000 would probably be sufficient to assume a 64K or better system.

Thank you very much for the help, with that I can already access the memory reserved in XL/XE for the OS.🤩

 

Now waiting for friends to try it in the real Atari, the github was updated but is the same version 1.6👍 

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.

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...