Jump to content

atari 800 - where does address start for graphics 8 mode


Recommended Posts

That's kind of a trick question because it can vary depending on the amount of memory installed and whether on not the programmer moved the beginning of screen memory from a default location. Graphics 8 is an 8k mode, so one simple answer is that you peek the values in memtop and subtract 8k from it. The most reliable way to to find the beginning of screen memory is to retrieve the screen location from the display list while the program is running. If it's not obvious, the beginning or screen memory in any mode is fully relocatable on the Atari.


A fun trick is to poke values into the display list's screen pointer so that you can scroll through memory a screen at a time and see what locations in the computer are doing while the computer is running. Have a look at the book Mapping the Atari to see the locations of interesting memory locations like system timers and even some of the custom chips.

Link to comment
Share on other sites

You don't need to pull it from the display list. The base of screen memory is stored in SAVMSC ($58,59 / 88,89).


MEMTOP holds the highest address usable below the screen. It shouldn't be used to find screen data and there's no reason to, as SAVMSC and SDLSTL/SDLSTH will directly point to whatever you need and will work regardless of OS or if anything has allocated memory above the screen. Subtracting from the allocation ceiling (RAMTOP) is not reliable as the allocation layout is an internal OS detail and for some graphics modes it has to apply additional offsets for hardware alignment requirements.

Link to comment
Share on other sites

It depends on the system and is subject to change. Here is some code that I wrote in BASIC which will pull the current value from a live NTSC system. Basically, it goes to the Display List and reads the instruction which tells Antic where video memory is stored. (I hard-coded the offset, though, rather than looking for the exact bits being set. I don't know how non-NTSC formats differ, so I can't say if it'll work in those cases.)


10 GRAPHICS 8:P=PEEK(560)+PEEK(561)*256
20 O=PEEK(P+4)+PEEK(P+5)*256

My result:




Link to comment
Share on other sites

The address of the display list is stored in 560/561, so it would be PEEK(560)+PEEK(561)*256.


The display list usually starts with a couple of 8 blank lines encoded by a sequence of 112s.


The next byte encodes the graphics mode and is followed by the address of the first screen line.


So you should be able to use the following code.

10 DISPLAYLIST = PEEK (560)+PEEK(561)*256
30 Y=PEEK(X)
40 IF Y/16 = INT(Y/16) THEN X=X+1:GOTO 30

Line 40 checks whether the lower nibble of the display list byte is empty, which means it's a "blank lines" command.


Be aware that screen memory need not be contiguous. The memory for every "logical" screen line can be stored in a different place. The standard graphics modes will have contiguous memory, however.

Link to comment
Share on other sites

hhhhhmmm the name Lee Geissler has popped into my head...

If that's concerning my screen name Geister, that is a reference to a web comic, Girl Genius. There is a tribe of underground dwelling women in the comic called the GeisterDamen which I loosely translate as ghost women. I thought Geister was more interesting than "Ghost". The connection for me is that the Geisterdamen were albino like, pale skinned and white haired. That pretty much describes me these days!

Link to comment
Share on other sites

I was a member of ABE's ACEs before the great 8-bit/16-bit schism. That's part of the reason I got out of Atari computers although it's fair to say that my job and family life were more of a wedge. My job pushed me into getting a PC and my wife often wondered out loud why I kept all that old junk around, so I offered it to a club member that was still very involved in the 8-bit scene, Of all the stuff I gave away, I miss the MIO and 20 meg hard drive the most. Seems silly when you can get a 20-gig SD card for next to nothing these days.


I never had much to do with LVAUG because they didn't seem too interested in 8-bit computers at the time. When my wife and I organized TV coverage of computer clubs back in the day, LVAUG sent a guy with a lug-gable 286 with tons of expansion boards installed, and he blew the fuses just before the camera crew was ready to start filming. The guy's attitude was our computers would have blown the circuits too if they were "real" computers. I did hear that some people from the the Aces went to LVAUG after the schism including a guy I thought was a real genius with Sparta dos extensions.


So I'm guessing that you were a member of one or both groups? Are you still in the valley?

Link to comment
Share on other sites

Yes, and Yes,

Are you sure the guy lugging the messed up PC with the boards hanging out wasn't a LVCUG member?

I was invited to one of their meetings and they were all about linux and x86 machines.


LVAUG was Atari 8 bit and Lynx with a little ST here and there.

ABE's ACE's went ST crazy.

but.... there was still an underground 8 bit scene within the organization...


Both were fun to visit, good people.


Ed Bachman and the crew were all about SpartaDos...

Edited by _The Doctor__
Link to comment
Share on other sites

It think you are right, I was thinking about LVCUG. LVAUG didn't exist yet when that show was filmed.


Yup, Ed was the man. I was studying the Spartados directory structure and though it would be easy to move files anywhere on a harddisk just by moving the file table entry to a new location. Before I had my proof of concept basic program finished, Ed had created move.com. I haven't seen him in years.


Did you know Bob Tune? He was the guy that got all my Atari equipment...at least the stuff I didn't give to my nephew. I wouldn't mind getting my prototype 816 board back though if only to remind me that there was a time when I did more than just use computers


I'm sorry I didn't hear about LVAUG or I might have kept my old stuff. Maybe I did hear about them and confused them with LVCUG back then?

Edited by Geister
Link to comment
Share on other sites

Technically, 7.5KB ;) 320x192/8 = 7680 bytes


it would be 8000 bytes if it was 320x200, like a lot of other computers. (which I guess when divided by 1024 is still 7.8124 KB )


It's actually more than 8000 bytes once you take into account overhead and OS allocation quirks. The OS always allocates the 160 byte split-screen window and the display list is also sizable in that mode, plus there is some unused space between the display list and the framebuffer. It all comes out to 8112-8138 bytes.


Never try to second-guess the OS with regard to screen memory allocation. There are a bunch of odd rules used and it is not as straightforward as framebuffer+display list.

Link to comment
Share on other sites

Using Div/Mul maths is a poor way to do lines.


Look up the Bresenham algorithm - https://en.wikipedia.org/wiki/Bresenham%27s_line_algorithm

He was working for IBM and it was used to do lines on printed paper output likely using ASCII characters and overtyping.

It's such a good algorithm that it's been used ever since and even modern graphics cards use it.


There's optimizations to be had for old computers, generally things like table lookup for part of the pixel address calculations, and improved draw methods that do 2 pixels at once that meet in the middle.

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

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.


  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...