Jump to content
IGNORED

HW-Detect


Recommended Posts

4 hours ago, MrFish said:

The fix for this is easy. You simply test for <SELECT> to be pressed, then you test for <SELECT> to be released. That's it.

As a general programming advice I prefer the other option, detecting the "just pressed" event, so a detection of a "key not pressed", followed by a detection of "key pressed".

That way you know that no other application can mess with yours.

Also, detecting "just pressed" feels more responsive than detecting "just released", from the user's perspective.

 

But I understand that this doesn't protect you from messing with the next application :D

 

  • Thanks 1
Link to comment
Share on other sites

21 minutes ago, NRV said:

As a general programming advice I prefer the other option, detecting the "just pressed" event, so a detection of a "key not pressed", followed by a detection of "key pressed".

That way you know that no other application can mess with yours.

Also, detecting "just pressed" feels more responsive than detecting "just released", from the user's perspective.

 

But I understand that this doesn't protect you from messing with the next application :D

 

Yes, I would agree that you get more responsiveness from the method you describe, rather than the "nothing happens until I release the button" that you get from the method I described -- which tends to make it feel like 2 actions are needed (button down, button up) to make anything happen. And inside your own app where you have full control, yours would be the preferred method.

 

As you say though, This doesn't protect from having a problem with another app that you might exit to. So, I guess the best solution would be to use the method I describe "at least" for the function of exiting to another app [Edit: ...or I guess you would actually use a combination of both methods, if the NRV method was being used elsewhere in the program -- and the key had some potential for causing a conflict in the running app. So, test for "key not pressed", test for "key pressed", test for "key not pressed". I think that would cover it].

 

Edited by MrFish
Because I needed to edit it.
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

17 hours ago, mikesk8 said:

super, thank you! ? as said before, please let me know and I will test it on my 800 :)

here's another version for you to try.

hw-detect_test2.xex

I made some changes, but I still can't quite detect the 48k of an 800.

18 hours ago, StickJock said:

You might also want to test for 52K on an 800.  There were also 8K cards on really old systems, so maybe walk through RAM in 8K (or even 4K) increments?  400s usually have less than 48K.

 

ATARI-CX853-MEMORY-MODULE-16K-RAM-MEMORY-EXPANSION-AJ079635-UNTESTED

I see, there are several possible combinations. ?

 

6 hours ago, MrFish said:

Well, this may seem like a trivial problem to bring up; but it's common, annoying, and easily fixed.

 

The problem is when people set some input device action (joystick button or console keypress) to exit a currently running program and start another. Once entering the newly started program, if any of those input device actions are being tested for, guess what can happen? The newly started program can see the keypress and takes action. So, in many cases (most) you end up starting some action that may not be desirable (and in many cases can be unaware that anything happened at all, because it can happen so quickly).

 

In the case of HW-Detect, <SELECT> is being tested for an exit to Atari's built-in "Self Test", and what happens is -- unless <SELECT> is only pressed for a minute instance -- <SELECT> will be detected by "Self Test" upon entry; and instead of the current menu selection being on "Memory", it will be on "Audio-Visual".

 

As I said, this may seem like a trivial problem (with other programs I've seen, the problem can have more serious consequences); but the intention of Atari's "Self Test" program is that the initial menu selection is the top item ("Memory"), not the second item ("Audio-Visual").

 

The fix for this is easy. You simply test for <SELECT> to be pressed, then you test for <SELECT> to be released. That's it.

 

Thank you very much for the feedback, I already left CONSOL without value.?

Link to comment
Share on other sites

1 hour ago, ascrnet said:

Thank you very much for the feedback, I already left CONSOL without value.?

 

Thanks for addressing the issue, but the problem still persists. The only way to eliminate the problem is to ensure that the user has released the <SELECT> button prior to exiting.

 

Link to comment
Share on other sites

23 minutes ago, MrFish said:

 

Thanks for addressing the issue, but the problem still persists. The only way to eliminate the problem is to ensure that the user has released the <SELECT> button prior to exiting.

 

 ahhhhh by pressing the START or SELECT keys, thanks for the clarification now if it works better ?

hw-detect_test3.xex

  • Like 2
Link to comment
Share on other sites

Hi!

11 minutes ago, MrFish said:

Alright, some more feedback.

 

When I use <START> to "Reboot" the system, BASIC is being enabled, even though it's disabled in Altirra.

That won't work, as Altirra does not know how to re-disable BASIC. What the emulator does is simply to fake the pressing of OPTION key on bootup. After that, the emulator behaves just like a standard machine.

 

Have Fun!

  • Like 1
Link to comment
Share on other sites

12 minutes ago, dmsc said:

That won't work, as Altirra does not know how to re-disable BASIC. What the emulator does is simply to fake the pressing of OPTION key on bootup. After that, the emulator behaves just like a standard machine.

 

If that's the case, I should be able to hold down <OPTION> during reboot and avoid entering BASIC, which I had already tried and wasn't able to do.

 

Link to comment
Share on other sites

Hi!

1 hour ago, MrFish said:

If that's the case, I should be able to hold down <OPTION> during reboot and avoid entering BASIC, which I had already tried and wasn't able to do.

 

The problem is that the code waits for all the console keys to be released before jumping to the cold start vector. Then, you have exactly 81 scan-lines (so, about 5.1ms) to press OPTION again, and that is not physically possible!

 

The last 4 instructions implement the logic to wait for the console keys to be released:

27D5: AC 1F D0  LDY $D01F   ;CONSOL
27D8: A5 80     LDA $80     ;LOMEM
27DA: C9 01     CMP #$01
27DC: D0 08     BNE $27E6
27DE: C0 06     CPY #$06
27E0: F0 0B     BEQ $27ED
27E2: C0 05     CPY #$05
27E4: F0 11     BEQ $27F7
27E6: C0 06     CPY #$06
27E8: F0 03     BEQ $27ED
27EA: 4C 06 28  JMP $2806
27ED: AD 1F D0  LDA $D01F   ;CONSOL
27F0: C9 07     CMP #$07
27F2: D0 F9     BNE $27ED 
27F4: 4C 77 E4  JMP $E477   ;COLDSV

 

Have Fun!

 

  • Like 2
Link to comment
Share on other sites

59 minutes ago, dmsc said:

The problem is that the code waits for all the console keys to be released before jumping to the cold start vector. Then, you have exactly 81 scan-lines (so, about 5.1ms) to press OPTION again, and that is not physically possible!

 

The last 4 instructions implement the logic to wait for the console keys to be released:


27D5: AC 1F D0  LDY $D01F   ;CONSOL
27D8: A5 80     LDA $80     ;LOMEM
27DA: C9 01     CMP #$01
27DC: D0 08     BNE $27E6
27DE: C0 06     CPY #$06
27E0: F0 0B     BEQ $27ED
27E2: C0 05     CPY #$05
27E4: F0 11     BEQ $27F7
27E6: C0 06     CPY #$06
27E8: F0 03     BEQ $27ED
27EA: 4C 06 28  JMP $2806
27ED: AD 1F D0  LDA $D01F   ;CONSOL
27F0: C9 07     CMP #$07
27F2: D0 F9     BNE $27ED 
27F4: 4C 77 E4  JMP $E477   ;COLDSV

 

 

I figured it was something along those lines.

 

So, one solution would be to just test for <START> to be released, rather than all the console keys.

 

I suppose it might be nice to have an option to "Return to DOS" too, as that's all I'm really looking for here.

 

Edited by MrFish
  • Like 1
Link to comment
Share on other sites

3 hours ago, MrFish said:

 

Alright, some more feedback.

 

When I use <START> to "Reboot" the system, BASIC is being enabled, even though it's disabled in Altirra.

 

In theory this is fine, since the program jumps to COLDSV this is like pressing the ATARI's on/off switch.
the ATARI starts again as usual, if you press OPTION on the black screen you deactivate Basic on the real hardware.

 

3 hours ago, MrFish said:

 

If that's the case, I should be able to hold down <OPTION> during reboot and avoid entering BASIC, which I had already tried and wasn't able to do.

 

on the real hardware if it works, even if you have a floppy connected she will load

 

2 hours ago, dmsc said:

The problem is that the code waits for all the console keys to be released before jumping to the cold start vector. Then, you have exactly 81 scan-lines (so, about 5.1ms) to press OPTION again, and that is not physically possible!

 

absolutely right

1 hour ago, MrFish said:

So, one solution would be to just test for <START> to be released, rather than all the console keys.

 

I suppose it might be nice to have an option to "Return to DOS" too, as that's all I'm really looking for here.

 

if I leave him alone with the key and not all of them.

I once thought about putting the option back into DOS, but I asked myself today who would use it ?

Link to comment
Share on other sites

49 minutes ago, ascrnet said:

now try this version, with OPTION you go to the D.O.S. if you loaded it before

Thanks!

 

1 hour ago, ascrnet said:

I once thought about putting the option back into DOS, but I asked myself today who would use it ?

Actually, you may be surprised how many people are still using a DOS. Many people have hard disks or flash media for mass storage and use either MyDOS or SpartaDOS X for their operating environment. SpartaDOS X is still being actively developed, for good reason.

 

Link to comment
Share on other sites

I have tested test3 version and the results are:

-memory is now "unknown" from 64k in the previous version

-CITA PAL is detected and not GITA PAL (in my machine); previous version had GTIA NTSC; ANTIC in both versions were PAL; my machine is PAL with NTSC B OS. 

 

IMG_2135.JPG

Link to comment
Share on other sites

19 hours ago, MrFish said:

Thanks!

 

Actually, you may be surprised how many people are still using a DOS. Many people have hard disks or flash media for mass storage and use either MyDOS or SpartaDOS X for their operating environment. SpartaDOS X is still being actively developed, for good reason.

 

Ah ok, I even remind myself that in the XL-XE models you can detect if there is a DOS in memory. I was going to put it in your time but I thought it would be too much. ?

 

3 hours ago, mikesk8 said:

I have tested test3 version and the results are:

-memory is now "unknown" from 64k in the previous version

-CITA PAL is detected and not GITA PAL (in my machine); previous version had GTIA NTSC; ANTIC in both versions were PAL; my machine is PAL with NTSC B OS. 

 

IMG_2135.JPG

Thanks for the test on the hardware ?

Unknown memory is fine, as I plan to do a separate routine for detecting 400/800 ?

already detects CTIA well in 400/800 ?

 

Link to comment
Share on other sites

8 hours ago, ascrnet said:

Ah ok, I even remind myself that in the XL-XE models you can detect if there is a DOS in memory. I was going to put it in your time but I thought it would be too much. ?

 

Thanks for the test on the hardware ?

Unknown memory is fine, as I plan to do a separate routine for detecting 400/800 ?

already detects CTIA well in 400/800 ?

 

I am sorry, but my feedback was not clear :( I have GTIA PAL and the software detected CTIA PAL, which is not correct :(

Link to comment
Share on other sites

OS Rom for CTIA?  I don't get that.

 

Supposedly the official OSes for 400/800 are rev A and B for NTSC and only A for PAL.

It would be fair to assume an OS-A NTSC machine has CTIA but it's not a given.  Plenty of people took up Atari's offer to upgrade to GTIA (from memory you paid for the chip but the official service centres installed it for free)

It's been discussed before, and the generally accepted thing is that PAL CTIA probably never existed.

Link to comment
Share on other sites

5 hours ago, mikesk8 said:

I am sorry, but my feedback was not clear :( I have GTIA PAL and the software detected CTIA PAL, which is not correct :(

Here is the updated screen with Basic detection, which is correct (Basic version A) :)

 

Summary:

- Processor seems OK

- Ram not yet

- OS seems OK

- Basic seems OK

- TV system not yet

- Sound seems OK (I think all Atari 800 are mono in stock configuration)

 

IMG_2138.JPG

Edited by mikesk8
Link to comment
Share on other sites

13 hours ago, Rybags said:

OS Rom for CTIA?  I don't get that.

 

Supposedly the official OSes for 400/800 are rev A and B for NTSC and only A for PAL.

It would be fair to assume an OS-A NTSC machine has CTIA but it's not a given.  Plenty of people took up Atari's offer to upgrade to GTIA (from memory you paid for the chip but the official service centres installed it for free)

It's been discussed before, and the generally accepted thing is that PAL CTIA probably never existed.

I'm sorry I didn't know that information, I assumed all 800 were CTIA since I'm not a fan of the 400/800 series.?

I'll see how I can detect the CTIA and GTIA chip regardless of the OS Rom.

9 hours ago, mikesk8 said:

Here is the updated screen with Basic detection, which is correct (Basic version A) :)

 

Summary:

- Processor seems OK

- Ram not yet

- OS seems OK

- Basic seems OK

- TV system not yet

- Sound seems OK (I think all Atari 800 are mono in stock configuration)

 

IMG_2138.JPG

Thanks for the test, I'll soon be improving the detection. "Patience!!!" ?

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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

I've been reviewing the book of Mapping The Atari and there's a very good example to correctly detect CTIA and GTIA

10 POKE 66,1:GRAPHICS 8:POKE 709,0:POKE 710,0:POKE 66,0:POKE 623,64:POKE 53248,42:POKE 53261,3:PUT#6,1
20 POKE 53278,0:FOR K=1 TO 300:NEXT K:GRAPHICS 18:POKE 53248,0:POSITION 8,5:? #6;CHR$(71-PEEK(53252));"TIA"
30 POKE 708,PEEK(20):GOTO 30

the idea is simple is to activate the graphic mode and activate the graphic mode 9 that is only in the GTIA and using PM detect a collision. in summary in CTIA there is a collision and in GTIA there is not.?

  • Like 2
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...