RAMTOP & DM

[ac.tomo]

I recently performed this:

 

10 FNT=PEEK(106)-4

20 POKE 106,FNT

30 GRAPHICS 8

 

This won't actually work, I know why, it's just that I'm bringing it up because I don't recall having to do the solution to this in the past, the solution is:

 

10 FNT=PEEK(106)-16

20 POKE 106,FNT

30 GRAPHICS 8

 

If you protect less than 16 pages then the computer won't calculate the DM for GR.8 correctly, has it always been like this or is it me.

I've been programming since 1983 but can't recall ever having to do this.

 

[ivop]

What do you mean by DM? Do you mean DMASK (672/$2A0)?

 

I do see the bug though:

 

GR. 8

COLOR 1

PLOT 0,0

DRAWTO 319,191

 

 

POKE 106,PEEK(106)-4

REM AND THEN THE SAME CODE AS ABOVE

 

 

 

Edit: I think the reason is that the OS doesn't take into account that ANTIC needs its data aligned to 4kB boundaries. That's why -16 (16 pages is 4kB) works again.

 

Edited July 24, 2021 by ivop

[drac030]

I would guess that "DM" = Display Memory. It is calculated correctly regarding the RAMTOP. Just it is not regarding the Antic inability to cross a 4k boundary without the LMS. Thus if lowering RAMTOP for GR.8, one should always lower it by 4k (16 pages).

[ac.tomo]

DM - Display Memory.

 

Yes, as I said, I do understand whats going on, because if you only protect 4 pages, then 4 pages off ramtop makes ramtop then = 156 where 160 pages * 256 = the 4k boundary. The reason Im asking is has it always been like this, as I said I dont recall having this problem in the past. Obviously, protecting anything less than 16 pages will result in  no 4k or 8k mode DM being calculated correctly.

[baktra]

Yes, it is a known problem with all graphics modes that require more than 4kb of a framebuffer. It's always been like that.

[sanny]

The ROM code doesn't expect available memory to be in small (let's say 1K) steps. I guess the minimum steps (available RAM cards) are 8K.

 

See e.g. https://github.com/cc65/cc65/blob/62da869e49bee55b3f0d7dab2dc7bdf9721b6f07/libsrc/atari/xlmemchk.inc#L32

[Rybags]

The original OS checked memory size in 4K chunks (probably as the original plan was 4K for 400, 8K for 800).

 

It's somewhat annoying in Basic when you have to throw away a good portion of 4K just for the sake of using PMs and/or character set that's only using a fraction of it (though of course hires PM + a character set can potentially be 2.25K)

 

An alternative could be to allocate a large string array then embed your character set within it.  You'd need to reserve 2048 bytes to be guaranteed you have a 1K boundary to start it on though.

 

DIM CH$(2048) : A=ADR(CH$) : CHSET = INT(A/1024)*1024+1024

 

You still waste 1K there (though potentially you could use some of it for something else) and have the added disadvantage that if adding to your program the string will move and corrupt your graphics (not really a problem once the program's finished, only during the develop/debug state)

 

In theory you could probably use some trickery to reserve a string and only waste the amount of memory needed to get it near/on a 1K boundary - probably best done right at the start of the program.

[+MrFish]

I never touched RAMTOP; I just use memory below the display data & list, and watch FRE(0).

 

I think I initially picked up the idea from Compute's First Book of Atari Graphics: Protecting Memory

 

[thorfdbg]

23 hours ago, ac.tomo said:

If you protect less than 16 pages then the computer won't calculate the DM for GR.8 correctly, has it always been like this or is it me.

I've been programming since 1983 but can't recall ever having to do this.

 

The trouble is that there is not really much of "calculation" going on in the S: handler. It is "hard-coded" in the S: driver where a 4K wrap-around (in terms of display lines) is taking place, and this assumes alignment to 16 pages. Actually, with the line width not being a divisor of a power of two, you can at most have two LMS instructions in a display list if you want a continuous playfield, so it is not only a shortcoming of the current S: handler, but pretty much a requirement.

[ClausB]

18 hours ago, Rybags said:

The original OS checked memory size in 4K chunks (probably as the original plan was 4K for 400, 8K for 800).

Yes, the first few machines were built with 4K RAM boards:

 

 

[ClausB]

8 hours ago, thorfdbg said:

The trouble is that there is not really much of "calculation" going on in the S: handler. It is "hard-coded" in the S: driver...

 

Yes, it's a lookup table in the 800 OS ROM.

Edited July 26, 2021 by ClausB

[ac.tomo]

The string method:

 

10 DIM CC$(1024)

12 MTOP=PEEK(106)-4

14 POKE 106,MTOP-4

16 GRAPHICS 0

18 D=PEEK(140)+256*PEEK(141)

20 R=PEEK(134)*256+PEEK(135)

22 Q=MTOP*256-D

24 R1=INT(Q/256)

26 T=Q-R1*256

28 POKE R+2,T:POKE R+3,R1

 

This is a routine from P6/NAU iss.#29 by Les Howarth, I haven't altered or touched it in any way except for the line-numbers. It changes the address of CC$ to start at a 1k boundary, only thing you need to know is that CC$ needs to be the very first variable in your program.

 

[stepho]

11 hours ago, ac.tomo said:

10 DIM CC$(1024);REM Must be first var

Always document caveats.

Otherwise someone will modify it later and it will crash for an unfathomable reason.

[ac.tomo]

what is 'caveats'?

[OldSchoolRetroGamer]

5 minutes ago, ac.tomo said:

what is 'caveats'?

ca·ve·at
noun
a warning or proviso of specific stipulations, conditions, or limitations.
"there are a number of caveats which concern the validity of the assessment results"

[ivop]

16 minutes ago, OldSchoolRetroGamer said:

ca·ve·at

As a non-native speaker, it took me years to realize it was CA-ve-at, instead of cav-EAT.

 

Miscellaneous. In the 90's, I thought it was mis-CEL-la-nus. Nope, it's mis-cel-LA-ne-ous

[OldSchoolRetroGamer]

2 hours ago, ivop said:

As a non-native speaker, it took me years to realize it was CA-ve-at, instead of cav-EAT.

 

Miscellaneous. In the 90's, I thought it was mis-CEL-la-nus. Nope, it's mis-cel-LA-ne-ous

Don't feel bad, I am a native speaker and in my youth I had never seen some words spelled out even though I had used them so I totally mispronounced "Phenomena"  which was a movie title, an old horror movie with Jennifer Connelly, both my friend and I pronounced it "Fee-no-me-na" which was close but we had not clued into to it being the actual word we know knew so well, we mentioned it to his girlfriend the move pointing at the VHS box and she just stared at us and started laughing "it's Phenomena you idiots!", she was not wrong  ?. Worse then that, I read a lot of novels but oddly I had never encountered the simple word "genre" spelled out, I would therefore pronounce it something like "Ja-near", I pointed the word out to someone in a book I was reading asking "What is this word Ja-near? When they replied "Rob, that's genre" I was so embarrassed. ?

Edited July 27, 2021 by OldSchoolRetroGamer

[Wrathchild]

4 hours ago, ivop said:

Nope, it's mis-cel-LA-ne-ous

I find its more mis-cel-lane-ee-ous

[stepho]

13 hours ago, ac.tomo said:

what is 'caveats'?

Using different words: If there is something in the code that is very easy to break, then it should be documented in the code itself - ie right next to the part that breaks easily.

I've lost count of the number of times that the previous programmer just "knew" that certain things had to be done or not done.
But the knowledge wasn't passed on to me and I broke things that needlessly took me ages to find out why.
When I eventually fixed them I put a comment in the code about why something had to be done in a certain way.

 

Thinking ahead for the next guy to modify the code is what separates the hackers from the professionals.

[ac.tomo]

On 7/26/2021 at 5:20 PM, ac.tomo said:

The string method:

 

10 DIM CC$(1024)

12 MTOP=PEEK(106)-4

14 POKE 106,MTOP-4

16 GRAPHICS 0

18 D=PEEK(140)+256*PEEK(141)

20 R=PEEK(134)*256+PEEK(135)

22 Q=MTOP*256-D

24 R1=INT(Q/256)

26 T=Q-R1*256

28 POKE R+2,T:POKE R+3,R1

 

This is a routine from P6/NAU iss.#29 by Les Howarth, I haven't altered or touched it in any way except for the line-numbers. It changes the address of CC$ to start at a 1k boundary, only thing you need to know is that CC$ needs to be the very first variable in your program.

 

It's ok in this instance, I've made sure that everything is the same, as I said the only thing you need to know is that CC$ must be the very 1st variable setup in the final program. The program doesn't matter what line numbers are used as there are no line-number addresses. I do note that Les Howarth has taken 8 pages off RAMTOP as there used to be a bug to do with clearing memory below RAMTOP, but even though that doesn't happen on the XL/XE I've left it in.

Edited July 28, 2021 by ac.tomo