HW-Detect

[NRV]

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

 

[+MrFish]

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

 

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 August 7, 2020 by MrFish
Because I needed to edit it.

[ascrnet]

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.

 

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

[+MrFish]

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.

 

[ascrnet]

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

[+MrFish]

5 hours ago, ascrnet said:

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

hw-detect_test3.xex 3.84 kB · 4 downloads

Yeah, that's it. Thanks!

 

[ascrnet]

12 hours ago, MrFish said:

Yeah, that's it. Thanks!

 

You're welcome, but thanks to you for the feedback! ?

[+MrFish]

1 hour ago, ascrnet said:

You're welcome, but thanks to you for the feedback! ?

 

Alright, some more feedback.

 

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

 

[dmsc]

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!

[+MrFish]

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.

 

[dmsc]

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!

 

[+MrFish]

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 August 9, 2020 by MrFish

[ascrnet]

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 ?

[ascrnet]

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

hw-detect_test4.xex

 

 

[+MrFish]

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.

 

[mikesk8]

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. 

 

[ascrnet]

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. 

 

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 ?

 

[Rybags]

CTIA detection - how does that work?

Do you use a GTIA mode and create PM to PF collisions or something?

[ascrnet]

40 minutes ago, Rybags said:

CTIA detection - how does that work?

Do you use a GTIA mode and create PM to PF collisions or something?

by the OS ROM if it is a 400/800 has a CTIA otherwise it is a GTIA ?

[mikesk8]

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

[Rybags]

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.

[mikesk8]

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)

 

Edited August 10, 2020 by mikesk8

[ascrnet]

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)

 

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

[Rybags]

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.

[ascrnet]

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