Jump to content
IGNORED

Atari 800+52KB: New OS/b bug?


Faicuai

Recommended Posts

Or maybe not?

 

Either way, this one got my head scratching to a pulp. I am posting this in case someone else has seen this, because I simply could not find ANYTHING about what I am seeing here. The HARDWARE comfog. is COLLEEN + 52KB + 1024KB AXLON ram expansion. It should be the same with 512 KB. etc.

 

To put it short-and-simple, It looks like Atari OS/b embedded E: driver is INOPERABLE in the entire $C000-$CFFF hi-RAM range. Not a few bytes beyond the text buffer. No, the ENTIRE 4KB range beyond $BFFF. Even Newell's OS/N OS fails there. Altirra Colleen OS, on the other hand,  works  beautifully there. 

 

Just Take a look at the simple yet conflicting piece of code, in Altirra Basic (RAMT holds the target page where we want the OS to relocate Antic's DL+Text buffer, 992 bytes backward from there. you can change it to ANY other higher page, it will not matter):

 

EEFA651B-8A2A-4D76-AC36-1B703B5408FC.thumb.jpeg.68a803708d96e9cbb3d41d6fc56f5ee2.jpeg

 

First problem arises as soon as you list something else and hit SHIFT-CLEAR screen. ONLY and ALWAYS first 256-bytes of the screen buffer will be erased, REGARDLESS where the base screen buffer vector points in the $C000-$CFFF range. It looks like this:

 

1F4C5490-1BF1-4EB9-8947-BC50CECDD27A.thumb.jpeg.b494656ba74cf99bbbe306287001cf85.jpeg

 

Now, if you keep listing past the LAST line and char of the screen, system crashes and locks up instantly:

 

92905F8F-FFB3-469D-8272-47679D9F7801.thumb.jpeg.144ec80a22eff9b6c95931adc14b4ae5.jpeg

 

Even a simple DIR command (if you booted from SDX, for instance) that scrolls past the end of the screen, crashes the session. It is as if somehow the E: editor is attempting to write somewhere outside the designated ram space, maybe past $CFFF (there's AXLON control register), or somewhere else.

 

Does not matter where the screen buffer ends up located in the $C000-$CFFF range. Switching to Atari Basic vC yields the exact same problem.

 

The INTERESTING part is that it I load XEP80 drivers in that range and make them default E: console driver, then problem disappears even on OS/b. Which means the problem is likely related to OS/b E: code. This is on real HW, have not jumped yet into Altirra's debugger, though...

 

Has anyone seen this before?  Or am I missing something here about the OS memory-management that has been already discussed and I am just slept-at-the-switch?

Link to comment
Share on other sites

Its a known bug in OSB that E: writes past memtop on clear screen, and will start writing into GTIA registers at least if you clear screen for instance. To make it worse, isnt $CFFF the banking control register for axlon? Clearing screen would write into that register too and maybe switch banks on you?

 

The writing above memtop bug is why RAM based distributions of text based carts like BASIC and asm/ed put the screen buffer another 4K below the start of the cartridge "rom"  area that is ram....

  • Like 2
Link to comment
Share on other sites

9 minutes ago, Nezgar said:

Its a known bug in OSB that E: writes past memtop on clear screen

That is exactly what is confusing.

 

It writes 32 (Thirty-two) bytes above it...  not 4,096 !!!

 

In the above test we start at $C500 backwards, which will being us to $C020, which leaves exactly 32 bytes up-front free above $BFFF.

 

And above $C500 we still have $3A00 of empty address space to add, and yet anywhere you place it (as well as memtop) it crashes no matter what....

 

That's what it does not compute to me.

Edited by Faicuai
Link to comment
Share on other sites

Here's a relevant excerpt from Mapping:

 

When you normally PRINT CHR$(125) (clear screen), Atari sends
     zeroes to the memory starting at locations 88 and 89. It continues to
     do this until it reaches one byte less than the contents of RAMTQP
     (location 106; $6A). Here is a potential source of conflict with your
     program, however: CHR$(125)--CLEAR SCREEN--and any
     GRAPHICS command actually continue to clear the first 64 ($40)
     bytes above RAMTOP!

     It would have no effect on BASIC since BASIC is a ROM
     cartridge. The OS Source Listing seems to indicate that it ends at
     RAMTOP, but Atari assumed that there would be nothing after
     RAMTOP, so no checks were provided. Don't reserve any data
     within 64 bytes of RAMTOP or else it will be eaten by the CLEAR
     SCREEN routine, or avoid using a CLEAR SCREEN or a
     GRAPHICS command. Scrolling the text window also clears 800
     bytes of memory above RAMTOP.

 

Link to comment
Share on other sites

5 minutes ago, Nezgar said:

Here's a relevant excerpt from Mapping:

 


When you normally PRINT CHR$(125) (clear screen), Atari sends
     zeroes to the memory starting at locations 88 and 89. It continues to
     do this until it reaches one byte less than the contents of RAMTQP
     (location 106; $6A). Here is a potential source of conflict with your
     program, however: CHR$(125)--CLEAR SCREEN--and any
     GRAPHICS command actually continue to clear the first 64 ($40)
     bytes above RAMTOP!

     It would have no effect on BASIC since BASIC is a ROM
     cartridge. The OS Source Listing seems to indicate that it ends at
     RAMTOP, but Atari assumed that there would be nothing after
     RAMTOP, so no checks were provided. Don't reserve any data
     within 64 bytes of RAMTOP or else it will be eaten by the CLEAR
     SCREEN routine, or avoid using a CLEAR SCREEN or a
     GRAPHICS command. Scrolling the text window also clears 800
     bytes of memory above RAMTOP.

 

Correct, I read it!

 

But here is the problem: there is nothing (nada), zero lala-land, above $C500 (adjusted ramtop vector) and yet, it crashes...

 

Not to mention the fact that there is no explanation for ONLY the frst 256-bytes being cleared, and then nothing else (this suggests the problem is different....)

 

See?

Edited by Faicuai
Link to comment
Share on other sites

I beleive ramtop can only be set at 4KB boundaries below RAM you want to protect from screen handler destruction. Hence for ram based BASIC, ramtop would be set at 36K, not 40K mark...

 

So yeah that would mean the highest ramtop you could safely specify is 48K mark - and trashing will extend 800 bytes up from there.

 

This may be another relevant passage:

A display
     list may not cross a 1K boundary without a jump instruction, and
     the screen display RAM cannot cross a 4K boundary without an
     LMS instruction to point to the proper byte(s).

 

Link to comment
Share on other sites

1 hour ago, Nezgar said:

I beleive ramtop can only be set at 4KB boundaries below RAM you want to protect from screen handler destruction. Hence for ram based BASIC, ramtop would be set at 36K, not 40K mark...

 

So yeah that would mean the highest ramtop you could safely specify is 48K mark - and trashing will extend 800 bytes up from there.

 

This may be another relevant passage:


A display
     list may not cross a 1K boundary without a jump instruction, and
     the screen display RAM cannot cross a 4K boundary without an
     LMS instruction to point to the proper byte(s).

 

Seems like I found the problem (your input motivated new questions on my end):

 

In my example above, setting $6A to $C5 (which was first used to compute relocation vector of E: buffer and D/L), then EVERYTHING works fine! There is a resulting discrepancy, however, between the resulting values of $6A and $02E4, which should match, in principle (which is what my sample code initially attempted after relocation E: buffer into hi-ram). When setting $6A BELOW and AWAY from actual E: buffer address, it seems the OS crashes.

 

Now, I actually set up a simple trace, by first filling ALL of $C000 to $CFFE with $11, and then running E: relocation example, and inducing crash as described above.

 

Then I proceeded with soft-reset, and loaded Assembler Editor, and start dumping memory content from $C000 to $CFFF. It turns out that the system crashed after writing TWENTY FOUR bytes after $C500 (which was its ceiling). Can't tell what happened at the top-end, because E: buffer got relocated, yet again, to $CC20 right after the crash, when hitting reset. But everything else between $C518 and $CC20 held the $11 trace-byte (which means, untouched).

 

So what I take from all this is that we are in the presence of another problem, here, being that E: is actually using $6A as basis for its E-buffer vector computation, and not just operating values left at $58 and $59.

 

If this is the case, we are in the presence of a different problem, one I never knew about (or could not find) anywhere.

Edited by Faicuai
Link to comment
Share on other sites

20 hours ago, Faicuai said:

So what I take from all this is that we are in the presence of another problem, here, being that E: is actually using $6A as basis for its E-buffer vector computation, and not just operating values left at $58 and $59.

I don't see why this is a problem. This is what the OS manual says:

 

Quote

A4 RAMTOP* [006A,1] -- Display Handler top of RAM address (MSB)

RAMTOP permanently retains the RAM top address that was contained in TRAMSZ (as described in N1) for the Display Handler's use. The value is set up as part of Handler initialization.

This is a Display Handler variable and thus it is reasonable for it to use it for its clear operations. The test program is changing this variable after the GR.0 screen is set up without reinitializing the Display Handler, and thus corrupting the handler state. That this works with AltirraOS is purely by chance and not supported. If you want to try to have a screen above the cartridge ROM and just prevent BASIC from trying to use addresses above $A000, then you should only modify MEMTOP [02E5,2] and not RAMTOP.

Link to comment
Share on other sites

On 2/6/2021 at 5:05 PM, phaeron said:

I don't see why this is a problem.

Well, the problem seems evident: because of the implicit equivalence between $6A and $02E4 (which will hardly ever be different, during OS computation of those values),  it basically means the E: driver assumes $6A implies a contiguous address space, instead of a non-contiguous one, which is what we will always get in a 52K range, with the cart smashed in somewhere between $8000 and $BFFF.

 

The definitions of $6A and $02E4 seem to be clear (neither should be below the other), per Mapping the Atari:

 

$006A (RAMTOP): "RAM size, defined by powerup as passed from TRAMSZ (location 6), given in the total number of available pages (one page equals 256 bytes (...) This is initially the same value as in location 740."

 

$02E4 (RAMSIZ): "(...) This is the same value as in RAMTOP, location 106 ($6A), passed here from TRAMSZ, location 6. Space saved by moving RAMSIZ or RAMTOP has the advantage of being above the display area. (...)"

 

In my humble opinion, there is no practical reason to base CHR$(125) clear-screen operations on $6A, when the screen buffer is not being displaced or relocated during such operation. That is what vectors $58 and $59 are computed and maintained for. It does make sense to resort to $6A when relocating the buffer, however (such as issuing a Gr. 0 command).


The implications of all the above become clear when any given application makes memory-allocation decisions based on... who? RAMTOP? RAMSIZ? When these two are equal, which is what is expected (and exactly what my sample code aims to preserve) there is no problem choosing between either. However, when they are different, that's when things get iffy. 

 

And lo and behold, SDX's RCGR8.SYS fails to properly allocate its RAM screen-buffer as soon as I set $6A above $02E4, which is what you (reasonably) suggest, on how I got E: working well after relocating everything to $C120-$C4FF range.

 

So I would conclude OS's E: driver does not track memory with the necessary flexibility or abstraction to freely operate in non-contiguous address space (this is unfortunate).

 

 

Edited by Faicuai
Link to comment
Share on other sites

sounds almost like a problem that happened with shrinking memory of a boot manager I used for the BBS back in 89 or 90... sparta and the manager would slowly eat up memory as the pointer slowly drifted during continued non power cycled use, I think there was a two byte fix that was done to it and solved the issue. I don't remember if it pulled the bytes from some other area or if it was just to lie to it and set them at some default value... but it definitely did not track properly before the fix.

Link to comment
Share on other sites

10 minutes ago, Faicuai said:

Well, the problem seems evident: because of the implicit equivalence between $6A and $02E4 (which will hardly ever be different, during OS computation of those values),  it basically means the E: driver assumes $6A implies a contiguous address space, instead of a non-contiguous one, which is what we will always get in a 52K range, with the cart smashed in somewhere between $8000 and $BFFF.

Sure, but the whole OS is built around this. The memory scan is ascending from address 0 and stops at the first non-RAM location, and the variables regarding memory allocation for the display handler and guarding against overrun against application memory are also designed around this assumption.

 

In practice, BASIC is one of the few programs that cares, since it does dynamic memory allocation and bothers to maintain APPMHI. The majority of programs don't and can simply initialize the display handler where they want the display, which will do so in blissful ignorance of the memory hole.

 

Also, 52K is not a supported configuration for OS-B, and in fact one of the changes in the modified OS-B that everyone knows as ATARIOSB.ROM is to block the memory scan at $D000 to prevent it from blowing up on a 52K configuration.

 

10 minutes ago, Faicuai said:

The definitions of $6A and $02E4 seem to be clear (neither should be below the other), per Mapping the Atari:

$006A (RAMTOP): "RAM size, defined by powerup as passed from TRAMSZ (location 6), given in the total number of available pages (one page equals 256 bytes (...) This is initially the same value as in location 740."

 

$02E4 (RAMSIZ): "(...) This is the same value as in RAMTOP, location 106 ($6A), passed here from TRAMSZ, location 6. Space saved by moving RAMSIZ or RAMTOP has the advantage of being above the display area. (...)"

 

In my humble opinion, there is no practical reason to base CHR$(125) clear-screen operations on $6A, when the screen buffer is not being displaced or relocated to such operation. That is what vectors $58 and $59 are computed and maintained for. It does make sense to resort to $6A when relocating the buffer, however (such as issuing a Gr. 0 command).

 

Mapping the Atari is not official OS documentation. It is third-party documentation that is occasionally wrong and also frequently documents internals of the OS that you are not supposed to rely on and can be different in different versions, especially between OS-B, the 1200XL OS, and the XL/XE rev. 2 OS. Notice that MtA fails to mention that RAMTOP is a Display Handler variable, which would be the first clue as to the rules around when it can be modified and when changes take effect. There are plenty of reasons for multiple variables like this to exist, including page zero access optimization and modularization. It may be possible to optimize them out in an alternate implementation, but there are often tradeoffs.

 

Please, if you are trying to figure out how things were designed to work in the OS, use the official Atari OS manual.

 

  • Like 3
Link to comment
Share on other sites

On 2/8/2021 at 10:10 PM, phaeron said:

Mapping the Atari is not official OS documentation.

 

(sorry for the Hiatus, been distracted on other pressing matters...)

 

Well, imagine what we should do then about the large pile of undocumented Atari perks currently embedded and actively supported in Altirra (for instance). 

 

I think the key essence of all this is programming intent. I am more interested in how a given implementation actually performs at the limits (more than what it is "supposed" to do). Changing "ideal", comfy-conditions is when you can learn what things really are. To this extent (and at the urgency of your request), I felt compelled to re-visit my OS-manual hard-copy, and what I found was... disappointing, to say the least:

 

C1DE6D3A-A92F-4499-8863-DD6B88995300.thumb.jpeg.bf77bcffcb722293c5523b83392b493d.jpeg04F0690A-F0C7-4A78-ACA6-762328AB1719.thumb.jpeg.dc55251c4d11c7839ec94ba084abb5d7.jpeg

 

But on the bright / funny side, I actually found ironic that the "unofficial / misguiding" Mapping-the-Atari source explained (with good clarity) the massive memory-management holes that, for some reason, the actual official-source seems to miss (?) Or maybe my older eyes got tired of manually seeking that info. page-by-page...

 

In any case, I for one am grateful for I. Chadwick's work on Mapping-the-Atari. It was never meant to be an OS-manual replacement (to begin with) and it is much more operational, hands-on in nature. Plenty of sample code that can be downloaded for immediate testing... The extensive $6A address coverage makes look the official OS-manual look like... a joke, in comparison. 

 

The OS-manual strengths, however, are others...

 

I think the main problem with all this is that  multiple graphics modes are meant to be supported, at any time (the OS never knows which in advance) with varying degrees of buffer-size requirements. And while it perfectly Ok. to conceive hosting the E: driver buffer in upper 4KB RAM, it may instantly fail as soon as issuing a Gr.8 command, for which memory allocation requires a much larger place, and that will never work based of $6A already pointing in high-ram (most likely what is happening with Sparta Commander in SDX). Additional intelligence will need to be embedded for memory management in the OS, making things bulkier than they are.

 

Therefore, it seems that $6A and $02E4 should, in reality, never drift apart, with the understanding that E. driver performs even simple clear-screen commands based of $6A address (which makes its location unnecessarily inflexible, at least in OS/b).

 

 

 

Link to comment
Share on other sites

The OS manual was riddled with mistakes and many were corrected and updated over time... let's not forget the missing addendums and the like that have slowly been folded back in to the current repositories. How much of the PBI OS manual is ... too say the least... incomplete or not entirely how it appears?

 

I can see both points of view, but in the end a combination of all these documents need to be brought together and correct each others errata ... what looks good on paper didn't always translate to what was or is... even at the timing and signal level... unless you go for the very best chips and parts that would fit the bill, even though in oem manufacture that did not always happen.

 

I think avery/phaeron has done an excellent job of doing this to date, and with good reasoning and discussion other fix ups and documentation will be added to handle the current issue at hand and other discussions around it.

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

3 hours ago, Faicuai said:

In any case, I for one am grateful for I. Chadwick's work on Mapping-the-Atari. It was never meant to be an OS-manual replacement (to begin with) and it is much more operational, hands-on in nature. Plenty of sample code that can be downloaded for immediate testing... The extensive $6A address coverage makes look the official OS-manual look like... a joke, in comparison. 

Don't get me wrong, Mapping the Atari is useful, but I see many programmers get into trouble using it because it makes no distinction between what exists in a specific OS version and what was stable and supposed to be used by programs. For instance, it list tons of internal entry points and data structures that, if you use them, you will blow up on the XL/XE OS unless you are using the revised version and remember to look at the XL/XE addendum. And even then you are likely to blow up on the 1200XL, since everyone seems to forget that model exists and has its own OS versions. Or OS-A. Or third-party OSes like QMEG, including ones that were released back in the day and not recently.

 

2 hours ago, _The Doctor__ said:

The OS manual was riddled with mistakes and many were corrected and updated over time... let's not forget the missing addendums and the like that have slowly been folded back in to the current repositories. How much of the PBI OS manual is ... too say the least... incomplete or not entirely how it appears?

I'm not sure why people are saying that the Parallel Bus Interface is undocumented. It isn't. There's plenty of both first-party and third-party documentation available:

 

http://www.atarimuseum.com/computers/8BITS/XL/xlperipherals/1090/sw_implementation_of_parallel_devs-drvrs.pdf

https://www.atarimagazines.com/v3n9/Parallel_Bus.html

 

Maybe this wasn't as available at the time, but I also had zero official documentation back then.

 

And it's not like the PBI is complicated on the software side. Each device has a pair of select and interrupt bits in $D1FF, and swaps in its firmware at $D800-DFFF on top of the math pack. Active PBI devices get polled on startup and for SIO/CIO/interrupts. That's it. The Screen Editor is more complex and arguably has more undocumented behaviors than the PBI. Not to mention that there are multiple implementations of both the host and devices to verify against, with the OS and SpartaDOS X on one side and the BlackBox and MIO on the other.

 

  • Like 4
Link to comment
Share on other sites

I didn't say it was undocumented, I say in so many words it wasn't documented well, but furthermore it certainly wasn't widely available and it varied based on machine as to what is available at the interface itself.

The information that has come since then and the archeology of Curt, Myself, and Others in an attempt to bring the expansion box to life for all sure makes it look great now. It certainly hadn't been since it's roll out and introduction...

Edited by _The Doctor__
Link to comment
Share on other sites

Is this relevant? It’s from a patch set Curt supplied with OS version 5. 

 

;****
; PATCH to fix clear screen write over RAMTOP

PATCHL  =       $C000

        ORG     PATCHL

PCLRSCR
        LDY     ADRESS          ;Y get current bias w/i memory page
        LDA     #0
        STA     ADRESS          ;make low byte of indirect ptr = 0
        RTS
 

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