Compiling a new Atari OS...

[invisible kid]

Not sure, but I think Cat misunderstood and thought this was a stand-alone program to run, and simply tried running it. Could be wrong though...

[flashjazzcat]

RAM test appears to be inadvertently banking the self-test ROM out when testing a machine with a 1MB expansion (after writing $6F to PORTB) and thereby crashing. Haven't checked out why this is yet. No other problems noted so far.

[tzok]

RAM test will also crash with Compy Shop 576kB expansion.

[flashjazzcat]

It might be worth considering that generic routine I linked to previously to build a table of PORTB values, but that's just a suggestion (I realise it would complicate the display side of things and then how far do you go with it: support for 4MB, etc? Although 1MB would probably be 'sufficient for anyone').

Edited April 7, 2023 by flashjazzcat

[w1k]

testing on real HW, looks like its freeze.. ramdisk hell led is activated.

[reifsnyderb]

6 minutes ago, w1k said:

testing on real HW, looks like its freeze.. ramdisk hell led is activated.

Hello,

 

I see that your computer is an 800XE.  With the extra LED and your mention of a RAM disk, I am assuming more memory is installed.  If there is more memory, what sort of expansion is installed?

 

Thanks!

 

Brian

 

[reifsnyderb]

1 hour ago, tzok said:

RAM test will also crash with Compy Shop 576kB expansion.

I just tested with Compy Shop 576 in Altirra.  It looks like the self test bank is being banked out with Compy Shop.  This makes sense. 

[w1k]

i have u1mb, 1mb was set

[reifsnyderb]

1 hour ago, flashjazzcat said:

It might be worth considering that generic routine I linked to previously to build a table of PORTB values, but that's just a suggestion (I realise it would complicate the display side of things and then how far do you go with it: support for 4MB, etc? Although 1MB would probably be 'sufficient for anyone').

The other issue is that I am down to 39 bytes available in the self-test bank.  With all of the possible memory configurations, I don't see a way to handle them.

 

That being said, having the memory test crash is unacceptable.

 

So, as a thought for discussion...

 

Maybe it's best to omit testing of extended memory altogether for the following reasons:

 

1.  There are a huge number of possible memory expansions to handle.

2.  There's only 39 bytes of free space left.

3.  Testing only 64k, as per the current test, does not give an accurate indication of whether the extended memory is good or not.

4.  A crash, due to an unexpected extended memory banking scheme, is unacceptable.

5.  There are programs available that are designed to handle the extended memory, handle most if not all extended memory schemes, and they take up a lot of space to do so.

6.  Testing only the base memory will allow for troubleshooting and repairs to the point that a specialized memory test program will now function.

 

Thoughts?

[flashjazzcat]

Good points. I know only too well how things get when feature requests meet available code space.

 

1. If we confine ourselves to PORTB memory, the aforementioned generic test (which is quite small), will spit out a list of PORTB masks for all common expansions.
2. Totally understood!
3. True. A slight extra level of complexity is required to re-use a 16K bank test with the base RAM test.
4. Yes, and - critically - I'm not even certain off the top of my head whether the generic test I mentioned as a matter of course happens to toggle the self-test ROM as it goes.
5. Not necessarily. As mentioned: once the short generic test has produced a table (up to 64 bytes) of PORTB masks, the enumerated banks work the same regardless of expansion scheme (caveat: RAMBO models which bank the base memory into the extended RAM window the test ignores such banks)
6. Well, extended memory isn't a pre-requisite for a booting computer, so testing it is hardly essential

 

Edited April 7, 2023 by flashjazzcat

[+kheller2]

I suggest sticking to the base 64K and maybe 130XE 128K testing.

All other RAM testing can be handled by external testers or tools.

Remember KISS.  This is supposed to be similar to what Atari provided and once we start getting into every type of RAM expansion and bit testing routines you start writing an entire diagnostic suite.  Speaking of which... one can always write a new SALT

 

 

Also, remember this thread from a few years back:  

 

 

[reifsnyderb]

After some thought, I removed the extended memory test.  Leaving the memory test in, for an XE, would only result in the self test failing with other systems.  Here's 6.00, Beta 2:

 

testos.rom

 

 

 

 

[MVladimir]

Excuse, my 2 cents.....

In the XE | XL series, we have only 4 (as far as I know) INITIALLY installed versions of the base memory from ATARI: 8 chips - 64K; 16 chips - 128K; 2 chips - 64K; 4 chips - 128k.
All other additional memory, DRAM or Static, are handmade extensions.
I see for this project as an improvement on the existing base BIOS, adding functionality and removing unnecessary code in order to insert the new required one, while also fixing bugs found over the years.
I think it's enough to leave in the BIOS testing only these 4 variants of base memory. All other must be checked using other soft/hardware.....
But I want to see not only 48 squares or letters (or 4 more rectangles or 8 letters with 128K memory. I would like to see all the base memory, 64K or 128K, more clearly and a little more visual detailed.
I'm comparing with CO30717, which are currently installed on my several ATARI.
Also, I read somewhere that the part of 128K RAM (if present) in currently available XE|XL BIOSes is actually not checked due to a bug. Is this fixed in the OS being developed or is there no such bug? How to see the size of RAM without opening the case - is it 64K or 128K? Or if the computer have extended/expanded and untestable by this OS  additional RAM?

This project is great, thanks that autor have time and skills to do it.

I'm not a programmer, so here is my view how and what I want see in redesigned SELF TEST of new OS.

[reifsnyderb]

10 minutes ago, MVladimir said:

Excuse, my 2 cents.....

Your input is very welcome!

10 minutes ago, MVladimir said:

In the XE | XL series, we have only 4 (as far as I know) INITIALLY installed versions of the base memory from ATARI: 8 chips - 64K; 16 chips - 128K; 2 chips - 64K; 4 chips - 128k.

That sounds right.

10 minutes ago, MVladimir said:

All other additional memory, DRAM or Static, are handmade extensions.

For the most part, yes.

10 minutes ago, MVladimir said:

I see for this project as an improvement on the existing base BIOS, adding functionality and removing unnecessary code in order to insert the new required one, while also fixing bugs found over the years.

My thoughts exactly.  That's why I scoured all XL/XE versions of the OS and turned this OS into a major bug fix revision that also adds some additional functionality.

10 minutes ago, MVladimir said:

I think it's enough to leave in the BIOS testing only these 4 variants of base memory. All other must be checked using other soft/hardware.....

This was the original thought.  However, testing XE memory turned out to result in the computer crashing if the memory banking scheme was other than something completely compatible.

10 minutes ago, MVladimir said:

But I want to see not only 48 squares or letters (or 4 more rectangles or 8 letters with 128K memory. I would like to see all the base memory, 64K or 128K, more clearly and a little more visual detailed.

Ideally, yes, this would be a great feature.

10 minutes ago, MVladimir said:

I'm comparing with CO30717, which are currently installed on my several ATARI.

What's a CO30717?  I did a search and didn't find anything.

10 minutes ago, MVladimir said:

Also, I read somewhere that the part of 128K RAM (if present) in currently available XE|XL BIOSes is actually not checked due to a bug. Is this fixed in the OS being developed or is there no such bug?

Before I removed the XE testing, I had this fixed.  It's really kind of odd, actually.  Atari's XL/XE OS R. 3 has support for testing all of the XE memory but has the exact bug you are talking about.  Atari's source code even has a comment, from an Atari developer, explaining the bug and how to fix it.  But it was never fixed.  It doesn't make sense, really.  But Atari knew about it but never bothered to fix it.  Even Atari's XL/XE OS R. 4 still has this bug and still has the comment about how to fix it.

10 minutes ago, MVladimir said:

How to see the size of RAM without opening the case - is it 64K or 128K? Or if the computer have extended/expanded and untestable by this OS  additional RAM?

I'd like to see this, too.  I'll explain at the end.

10 minutes ago, MVladimir said:

This project is great, thanks that autor have time and skills to do it.

🙂

10 minutes ago, MVladimir said:

I'm not a programmer, so here is my view how and what I want see in redesigned SELF TEST of new OS.

Thanks!

 

Ideally, having the self test and/or the OS report the exact memory size would be great.  The biggest problem is space related.  I can think of at least 8 different XL/Xe memory expansion configurations and believe there to be many more.  Right now, I have 207 bytes to use to test for these configurations, test the correct configuration, and report the results.  Before I removed the XE bank testing code, I was down to 39 bytes available.  Realistically, I might be able to find more ways to re-claim more memory without sacrificing anything in the self test code.  Maybe.  Right now, I think I am at the point of diminishing returns.  Even if I were to be able to re-claim another 100 bytes, I still wouldn't have enough to do the job. 

 

When the XE bank testing code was in place, it was immediately discovered and reported that a Compy Shop memory expansion caused the system to crash.  Another 1MB memory expansion also failed.  I believe the solution is to copy the self test code into the base memory prior to testing a memory bank.  Performing such a copy may be possible with 39 bytes.  However, I don't see any realistic way to both copy the self test to another location and to test and report within only 39 bytes.  Having a scan of the memory to discover how much memory is installed, would result in the exact same problem.

 

So, the current resolution is to consider the memory self test as a "stepping stone", of sorts, to getting the computer to the point whereby a dedicated memory testing program could be loaded to test the remainder of the memory.

 

Also, having the memory test crash the computer, due to an incompatibility with a memory expansion, would not only be a poor outcome but would also not instill confidence in the system.

 

Thanks!

 

Brian

 

 

 

 

 

 

 

 

[tzok]

12 minutes ago, reifsnyderb said:

What's a CO30717?  I did a search and didn't find anything.

I think, he meant C300717 (ROM XL OS, ver. BB 1 rev. 3).

[MVladimir]

11 minutes ago, tzok said:

I think, he meant C300717 (ROM XL OS, ver. BB 1 rev. 3).

Yes, sure! My apologies, typo....

[MVladimir]

32 minutes ago, reifsnyderb said:

I believe the solution is to copy the self test code into the base memory prior to testing a memory bank.  Performing such a copy may be possible with 39 bytes.  However, I don't see any realistic way to both copy the self test to another location and to test and report within only 39 bytes.  Having a scan of the memory to discover how much memory is installed, would result in the exact same problem.

It seems to me that in the first post of this thread there are hints of a possible solution/way, if it is feasible in the new BIOS.

First check first part of memory, if OK copy there test code for rest of memory and test it for serviceability and performance.

And I'm only talking about standard 64K or 128K memory, without any extensions. On unmodified machines this should work without problems, but with extended memory it will show the health of the base memory.

 

In notes to revision 5.99:

Quote

 

;*                Control-Help sets left screen margin to 0.

.....
;*                Left margin set to 0.

 

This is permanent change or we can toggle left margin? I check on my unmodded 130XE - left margin is always 0 after boot.

[reifsnyderb]

11 minutes ago, MVladimir said:

First check first part of memory, if OK copy there test code for rest of memory and test it for serviceability and performance.

Yes, this is a possibility.  However, I have not figured out what the trade-offs are of doing so.  It's entirely possible the entire self-test code would have to be re-written so as to be relocatable.  There may be other options, of course.  I suppose it would be possible to copy a function to the tested base memory and have the function test banking to ensure the self-test bank is not affected by changes to bit 7 of PORTB.  I'd have to test this, of course.

11 minutes ago, MVladimir said:

And I'm only talking about standard 64K or 128K memory, without any extensions. On unmodified machines this should work without problems, but with extended memory it will show the health of the base memory.

Understood.  If a reasonable solution is found, I'll put the XE bank testing code back in.

11 minutes ago, MVladimir said:

 

In notes to revision 5.99:

This is permanent change or we can toggle left margin? I check on my unmodded 130XE - left margin is always 0 after boot.

On the Atari OS's I've seen, the left margin is at 2.  Setting this to zero helps to get a little more space on the screen.  Control-Help only sets the left margin to 0.  Because DOS resets the left margin to 2, it's just a quick way to set the left margin back to 0.

[reifsnyderb]

Version 6.0, Beta 3

 

Hopefully, this will be the last Beta release.  This release only adds "BASIC" to the self test screen and the video type detected by the OS.

 

testos.rom

 

source.zip

 

 

[MVladimir]

36 minutes ago, reifsnyderb said:

Version 6.0, Beta 3

Hopefully, this will be the last Beta release.  This release only adds "BASIC" to the self test screen and the video type detected by the OS.

Visually looks better! 

 

Time to time Break key don't interrupt tests. Don't know why, but sometime.... On keyboard test this key work well.

And - when we're on a keyboard test, we can forget where we are (the memory test has a visible ending, so does the sound).

There is no indication that our computer is still alive or already die when we don't press any keys.

In the original OS, we have all the tests running continuously in a circle, and this shows us that the computer is working.

Maybe it possible put somewhere a flashed point which show us the computer state? For example a dot, right of color system indicator, under same place where BASIC version?

[_The Doctor__]

but the word keyboard is inverse video to show we selected it... so how you don't see that?

did you hold down the break key? give it a quick press? or repeated press?

Edited April 8, 2023 by _The Doctor__

[reifsnyderb]

2 hours ago, MVladimir said:

Visually looks better! 

 

Time to time Break key don't interrupt tests. Don't know why, but sometime.... On keyboard test this key work well.

And - when we're on a keyboard test, we can forget where we are (the memory test has a visible ending, so does the sound).

There is no indication that our computer is still alive or already die when we don't press any keys.

In the original OS, we have all the tests running continuously in a circle, and this shows us that the computer is working.

Maybe it possible put somewhere a flashed point which show us the computer state? For example a dot, right of color system indicator, under same place where BASIC version?

I see your point with the time from when you pressed the break key until something happens.  For example, if you press the break key during a test and when there is a delay, you have to wait until the end of the delay.  The change isn't instantaneous.  It took a few more bytes, but I just changed the code so the break key will now terminate the test during the delay.  I'll skip a beta release and just put that change in Version 6.00.

 

If you think the computer is not responding, press the break or select key.  With the keyboard test, just press a key.  In Atari's keyboard test, it will just sit and wait.  I don't think it automatically exits or anything.  (Unless is the auto test....which doesn't really test the keyboard.)  Also, I didn't disable the attract mode.

 

Thanks!

 

Brian

[MVladimir]

Thank you for reply, I understand reasons.

 

SIO path is implemented? I don't find it in notes for sources.

You write only that Shift-Control-Delete cold starts the computer.

Quote

 

Highspeed SIO patch V1.33 for Atari XL/XE OS and MyIDE OS
Copyright (c) 2006-2020 Matthias Reichl <hias@horus.com>

.........

Highspeed SIO patch can be controlled in original with various keystrokes:

SHIFT+CONTROL+S    Clear SIO speed table and enable highspeed SIO
SHIFT+CONTROL+N    Disable highspeed SIO (normal speed)
SHIFT+CONTROL+H    Enable highspeed SIO
SHIFT+CONTROL+DEL  Coldstart Atari

.........

 

If path is in OS so I want to know:

All of this keystrokes are implemented? Or only one for coldstart?

How to boot without highspeed?

[reifsnyderb]

2 hours ago, MVladimir said:

Thank you for reply, I understand reasons.

 

SIO path is implemented? I don't find it in notes for sources.

You write only that Shift-Control-Delete cold starts the computer.

If path is in OS so I want to know:

All of this keystrokes are implemented? Or only one for coldstart?

How to boot without highspeed?

Hello,

 

I implemented Atari's high speed SIO upgrade that was in some versions of their operating system.  Basically, I used Notepad++ to compare the Atari OS with the high speed SIO and the Atari OS that came immediately before it.  Then, I patched in the SIO changes for 38,400 baud.  This is not to be confused with Hias's high speed SIO patch, which is a different implementation.

 

Atari's high speed SIO patch interrogates the SIO device and, if high speed SIO is supported by the device, communications at 38,400 baud as opposed to 19,200 baud.

 

Only the shift-control-delete is implemented...which really isn't related to SIO.  Atari didn't have any speed controls for their high speed SIO implementation.

 

Unfortunately, I don't have any high speed SIO devices to test with.

 

Thanks!

 

Brian

 

 

 

 

 

 

 

Edited April 8, 2023 by reifsnyderb

[MVladimir]

Thank you, Brian!

Nice to read so qualified answers.

This project is great, waiting for stable release.