HW-Detect

[Chilly Willy]

There were all kinds of weird boards for the 400/800. There's a doc on Atari Memory Expansion boards that covers many of them, along with expansions for XLs and XEs. I had the Mosaic memory expansion. It gives you 48KB of ram like normal, then a number of 4KB banks of ram at $C000-$CFFF. You set the bank by writing any value to $FFC0+n, where n is the bank number (max of 36 banks, or a total of 192KB including the first 48KB). I made a number of patched roms to utilize Mosaic bank ram for things like BASICXL and ACTION! so that I could run them from DOS. Left me 4KB more ram for programs, too.

 

[ascrnet]

On 11/14/2019 at 6:46 PM, flashjazzcat said:

Try to store and retrieve two different known values at address $4000 or higher.

Thanks and it works, I already published version 1.3?

On 11/14/2019 at 7:53 PM, Rybags said:

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.

thanks for the info?

On 11/14/2019 at 9:15 PM, Chilly Willy said:

There were all kinds of weird boards for the 400/800. There's a doc on Atari Memory Expansion boards that covers many of them, along with expansions for XLs and XEs. I had the Mosaic memory expansion. It gives you 48KB of ram like normal, then a number of 4KB banks of ram at $C000-$CFFF. You set the bank by writing any value to $FFC0+n, where n is the bank number (max of 36 banks, or a total of 192KB including the first 48KB). I made a number of patched roms to utilize Mosaic bank ram for things like BASICXL and ACTION! so that I could run them from DOS. Left me 4KB more ram for programs, too.

 

Thanks for the information, I am slowly learning and improving?

The 1200XL does not have basic as you know. My question how can I know if it has a basic cartridge? ?

 

Greetings and thanks for the help

[Chilly Willy]

https://atariwiki.org/wiki/Wiki.jsp?page=Atari BASIC

 

• Atari Basic Rev. A.rom ; ? PEEK(43234) should return: 162
• Atari Basic Rev. B.rom ; ? PEEK(43234) should return: 96
• Atari Basic Rev. C.rom ; ? PEEK(43234) should return: 234

 

If you want to identify other Basic carts, you'd need to check each one out. Start on this page

https://atariwiki.org/wiki/Wiki.jsp?page=Basic

Edited November 16, 2019 by Chilly Willy
more info

[ascrnet]

26 minutes ago, Chilly Willy said:

https://atariwiki.org/wiki/Wiki.jsp?page=Atari BASIC

• Atari Basic Rev. A.rom ; ? PEEK(43234) should return: 162
• Atari Basic Rev. B.rom ; ? PEEK(43234) should return: 96
• Atari Basic Rev. C.rom ; ? PEEK(43234) should return: 234

If you want to identify other Basic carts, you'd need to check each one out. Start on this page

https://atariwiki.org/wiki/Wiki.jsp?page=Basic

Thanks, I already do that. My question is especially for the 1200XL if there is a way to know if a cartridge is inserted in it.

Regards

[Rybags]

TRIG3 is cartridge sense on all XL and later machines.  For a normal cartridge it should always be active (low), for some banked cartridges that allow access to all the Ram underneath, it should go inactive when the Ram window is selected (it's connected to RD5 which cartridges use to signify their presence in the $A000-$BFFF region)

 

For a double-check if it's Rom there, write a couple of bytes around $BFF0, compare them, then invert and store back and compare again, which should tell you if it's RAM or otherwise.  If otherwise, an executable cart should have 00 at $BFFC.

Edited November 16, 2019 by Rybags

[ascrnet]

21 hours ago, Rybags said:

TRIG3 is cartridge sense on all XL and later machines.  For a normal cartridge it should always be active (low), for some banked cartridges that allow access to all the Ram underneath, it should go inactive when the Ram window is selected (it's connected to RD5 which cartridges use to signify their presence in the $A000-$BFFF region)

 

For a double-check if it's Rom there, write a couple of bytes around $BFF0, compare them, then invert and store back and compare again, which should tell you if it's RAM or otherwise.  If otherwise, an executable cart should have 00 at $BFFC.

Thanks for the explanation, but I did it by detecting the OS if it is REV.A or REV.B of 1200XL

 

another thing i'm seeing how to pass it to .rom ?

According to the information I found I only have to add the following but the program leaves the altirra on a black screen

    org $2000
    opt c+
    opt f+h-
    
begin
;

; ----Cart--------
init
    rts 

    org $BFFA
    .word begin
    .by 0,4
    .word init

regards

[flashjazzcat]

52 minutes ago, ascrnet said:

According to the information I found I only have to add the following but the program leaves the altirra on a black screen

What are you trying to do? Jump into the cartridge ROM?

.proc StartROM
	lda $BFFC
	bne NoInit
	jsr InitCart
NoInit
	jmp ($BFFA)
InitCart
	jmp ($BFFE)
.endp

 

[Rybags]

A cartridge needs program content.  The run vector doesn't allow returning.

 

Just put something simple in like a colour change for testing purposes, then a jump instruction to itself.

[Chilly Willy]

1 hour ago, Rybags said:

Just put something simple in like a colour change for testing purposes, then a jump instruction to itself.

Yeah, that's one of the easiest (to program and to see) way to get feedback from a console on a WIP. I do that on the Genesis all the time... I usually change the background color since there's always a lot of that on any screen. I usually set a different color at different places in the code, so just a glance at the color tells you the last thing that got done.

 

Edited November 18, 2019 by Chilly Willy
nore info

[ascrnet]

3 hours ago, flashjazzcat said:

What are you trying to do? Jump into the cartridge ROM?

Generate a cartridge .rom file from the mads. since it is easy to generate a .xex but I don't find it generating a .rom ?

 

thanks guys for your directions i will keep trying.

Regards

[Chilly Willy]

5 hours ago, ascrnet said:

Thanks for the explanation, but I did it by detecting the OS if it is REV.A or REV.B of 1200XL

 

another thing i'm seeing how to pass it to .rom ?

According to the information I found I only have to add the following but the program leaves the altirra on a black screen

    org $2000
    opt c+
    opt f+h-
    
begin
;

; ----Cart--------
init
    rts 

    org $BFFA
    .word begin
    .by 0,4
    .word init

regards

That first org is $2000... which is a bit low for a cart. Try $A000 for a 8K cart, or $8000 for a 16K cart.

[ascrnet]

21 hours ago, Chilly Willy said:

That first org is $2000... which is a bit low for a cart. Try $A000 for a 8K cart, or $8000 for a 16K cart.

Thanks for the help, I had to disable letter switching since it is not supported in the memory address that I am using $3000.

The program shown does not detect anything as seen in the image, the same happens if it is 8k or 16k

Regards

Edited November 19, 2019 by ascrnet

[mikesk8]

I have just run the software on my physical Atari 800 (non XL) and the program did not detect 48k (is showing 64k) and did not detect OS ROM, which is NTSC B. Is it a known bug?

[Rybags]

I'm not sure it was written with the older machines in mind (though should have)

 

But it seems to have found you 've got a PAL Antic and NTSC GTIA.  Does that agree with what I suggested to try in your thread about the modded 800?

[ascrnet]

On 8/3/2020 at 2:08 PM, mikesk8 said:

I have just run the software on my physical Atari 800 (non XL) and the program did not detect 48k (is showing 64k) and did not detect OS ROM, which is NTSC B. Is it a known bug?

? Sorry I didn't get a notice for this post. That version doesn't have support for 400/800 since I don't have real hardware from that line.

 

now if you have patience and you want to test it I can add the support.?

 

8 hours ago, Rybags said:

I'm not sure it was written with the older machines in mind (though should have)

 

Exactly for XL/XE/XGS only at the moment.?

[Rybags]

Older machines are easy to detect.

 

Bit 0 of PORTB switches the OS in or out.  So regardless of version or aftermarket modification that should be a universal indicator.

PORTB on XL/XE by default will have all bits in output mode - though in a testing situation you'd probably want to do save/restore and put them in output mode to test the OS switchability.

[mikesk8]

8 hours ago, ascrnet said:

? Sorry I didn't get a notice for this post. That version doesn't have support for 400/800 since I don't have real hardware from that line.

 

now if you have patience and you want to test it I can add the support.?

 

Exactly for XL/XE/XGS only at the moment.?

I am very happy to help and test  It would be super have this software running on all 8bit Ataris  

[mikesk8]

16 hours ago, Rybags said:

I'm not sure it was written with the older machines in mind (though should have)

 

But it seems to have found you 've got a PAL Antic and NTSC GTIA.  Does that agree with what I suggested to try in your thread about the modded 800?

I will do your tests today after work and report back  im curious too

[mikesk8]

3 hours ago, mikesk8 said:

I will do your tests today after work and report back  im curious too

As mentioned in another tread:

1) first test got 1 = PAL GTIA

2) the timing was exactly the same even after 60 sec = seems to be PAL Antic

3) SALT shows TIA:PAL

 

This means HW-Detect potentially wrongly detected GTIA as NTSC (see screenshot earlier) or the other test was wrong

[ascrnet]

13 hours ago, mikesk8 said:

As mentioned in another tread:

1) first test got 1 = PAL GTIA

2) the timing was exactly the same even after 60 sec = seems to be PAL Antic

3) SALT shows TIA:PAL

 

This means HW-Detect potentially wrongly detected GTIA as NTSC (see screenshot earlier) or the other test was wrong

enable the 400/800 OS ROM detection there are 5 different versions some NTSC and some PAL.

hw-detect_test.xex

now try and tell me.

[mikesk8]

12 hours ago, ascrnet said:

enable the 400/800 OS ROM detection there are 5 different versions some NTSC and some PAL.

hw-detect_test.xex 3.69 kB · 3 downloads

now try and tell me.

I can confirm the same NTSC B OS detected by your tool, Salt and by PRINT PEEK(65528)  in Basic  

 

RAM is still 64k vs 48k, and GTIA reports in your tool as NTSC while in SALT and by PRINT PEEK(53268) in Basic it shows PAL one. 

[ascrnet]

12 hours ago, mikesk8 said:

I can confirm the same NTSC B OS detected by your tool, Salt and by PRINT PEEK(65528)  in Basic  

 

RAM is still 64k vs 48k, and GTIA reports in your tool as NTSC while in SALT and by PRINT PEEK(53268) in Basic it shows PAL one. 

thanks for the proof...?

if it detects 64k because it's by default, I still can't detect the 48k of the 800 well.?

On the TIA I have to change the text and memory position as I am using the XL/XE not the one defined for 400/800.?

[StickJock]

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.

 

Edited August 7, 2020 by StickJock

[mikesk8]

4 hours ago, ascrnet said:

thanks for the proof...?

if it detects 64k because it's by default, I still can't detect the 48k of the 800 well.?

On the TIA I have to change the text and memory position as I am using the XL/XE not the one defined for 400/800.?

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

[+MrFish]

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.