Jump to content
Sign in to follow this  
ac.tomo

RAMTOP & DM

Recommended Posts

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.

 

Share this post


Link to post
Share on other sites
Posted (edited)

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

 

atari001.png.d05c37a47b911b2caef736daf19a1b7a.png

 

POKE 106,PEEK(106)-4

REM AND THEN THE SAME CODE AS ABOVE

 

atari000.png.c807ab4e25b40d6d3dbc2549a01c78b0.png

 

 

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 by ivop

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
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:

 

 

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by ClausB
  • Like 1

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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"

  • Like 1

Share this post


Link to post
Share on other sites
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 :)

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
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 by OldSchoolRetroGamer
  • Haha 1

Share this post


Link to post
Share on other sites
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.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
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 by ac.tomo

Share this post


Link to post
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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...