Mad Pascal - How to manage memory requirements for display lists, etc?

[starfighter]

Hello,

I am a long time Atari-User (my first computer was the 800XL back in 1985) and a retro computing fan. It is very fascinating to see that new technology and software is still being developed for these machines. I am especially impressed by tools like MADS/WUDSN IDE and Mad Pascal. Therefore I decided to start learning Mad Pascal (with a little bit of Assembler). I am not a very active forum writer in general, it is not my thing really, but I decided to write my very first post nevertheless.

My question is related to memory management in MadPascal.

I would like to understand if there is a smart or "clean" way to cover specific memory requirements of the Atari, such as 1K-Border restrictions for Display Lists or 4K-Border restrictions for screen memory? For example,  I am thinking of something similar like the ".align" directive in MADS?

 

Here is an example of my problem:

 

Imagine a simple display list configured as an array:   

//Custom Display List for Playfield Screen
PlayfieldDisplayList: array [0..98] of byte
= (
   $70, $70, $70,                                                             //3 x 8 blank lines             (24 Scanlines)
   $42, lo(PlayfieldHeaderMem), hi(PlayfieldHeaderMem),                       //2 x Mode 2: Playfield Header  (16 Scanlines)
   $02,
   $4D, lo(PlayfieldGraphicsMem), hi(PlayfieldGraphicsMem),                   //84 x Mode D: Playfield        (168 Scanlines)
   $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D,
   $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D,
   $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D,
   $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D,
   $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D,
   $0D, $0D, $0D, $0D, $0D, $0D, $0D, $0D,
   $42, lo(PlayfieldFooterMem), hi(PlayfieldFooterMem),                       //1 x Mode 2: Playfield Footer   (8 Scanlines)
   $41, lo(word(@PlayfieldDisplayList)), hi (word(@PlayfieldDisplayList))   //JVB: Wait for vertical blank + jump to Display List Memory Location
);        

 

I am facing in my program now two problems:

1. The array was placed into the memory at location $57DD, thus breaking the 1K-boundary at $5800.

2. The address for the JVB is not correctly set to the start address of the display list. Maybe due to a "chicken egg problem", that the array does not know its own location at initialization?

 

For reference, see the memory dump of the array:

 

I can surely find some workarounds for these issues, especially the second one, by just updating the last two array items with the correct memory location for the JVB AFTER the initialization of the whole array. I have to think about the first issue yet. Probably by just reorganizing or growing the code, the problem might get solved by itself. 

 

However, I am curious if there is a better way to manage the memory in MadPascal without "hacking" or hardcoding memory locations into the code? 

 

Many thanks in advance and kind regards,

starfighter

 

[explorer]

You can try the same trick with BASIC: allocate 2 K buffer, get address of this buffer, and calculate the next 1 K barrier within this buffer.

[snicklin]

7 minutes ago, explorer said:

You can try the same trick with BASIC: allocate 2 K buffer, get address of this buffer, and calculate the next 1 K barrier within this buffer.

Seems a valid but somewhat wasteful solution, though I guess if align doesn't exist, all solutions would be a bit wasteful. I am not a MAD Pascal user, but could the data be copied from the code here to a known unused memory area? Or loaded in from file to a certain location?

[ggn]

Like @snicklin says, people on the 8 bits are much more aggressive about RAM usage compared to modern programmers. Since the memory map is more or less fixed you can simply copy your data over to an aligned location and be wary not to write anything else above that.

 

Another trick I remember many people using in BASIC listings is to simply take the RAMTOP value, which holds the last free page in RAM, subtract 4 from it, adjust the value, and then use those 4 pages to hold your data. Then at least the system will be aware of your buffer. Of course this is moot if you don't plan to keep the O/S running.

[starfighter]

Thank you for your answers!

It would be good if I could reserve a specific memory area for the array, but how can I achive this in Mad Pascal?

 

The array and its content is defined in the var section of the code and I would like to leave it this way for code readibility reasons.

 

Of course, I could define the DL and the memory location in assembler and include the code via the ASM tag. I have done this e.g. for including a character font file. But if there is a cleaner way to do all this in Mad Pascal directly, this would be my preferred choice.

[tebe]

program test;
const    table: array [0..3, 0..1] of byte = ( (2,3), (4,5), (8,9), (0,1) );

 

"TABLE" at the begining the code (CONST)

 

table = CODEORIGIN + N-bytes

CODEORIGIN (default = $2000)

 

Edited July 20, 2019 by tebe

[starfighter]

Hello Tebe,

awesome! That solved both problems at once, thank you very much! Sometimes the solution is so simple 

 

If I remember correctly I had the DL arrays once defined as constants, but then moved them to var, bc I thought about changing them on the fly.

 

I don't know what other developers think, but generally being able to specify certain memory locations or border alignments for arrays, variables, procedures,  might be a useful native feature for Mad Pascal or what do you think?

 

By the way, do you know, why the other issue occured when the array was defined as variable (i.e. that the pointer after the JVB command was not stored during array initialisation):

PlayfieldDisplayList: array [0..98] of byte
= (
   ...
   ...
   $41, lo(word(@PlayfieldDisplayList)), hi (word(@PlayfieldDisplayList))   //JVB: Wait for vertical blank + jump to Display List Memory Location
);        

 

How should this be handled properly other than just overwriting it afterwards? 

 

 

Many thanks and kind regards,

starfighter

Edited July 20, 2019 by starfighter

[tebe]

i'ts some compiler bug, i check it

 

p.s.

Graph2Font (http://g2f.atari8.info)

Mode=DLI, Save As... , *.PAS

 

G2F creates display list, resource file, DLI program

[starfighter]

Ah, okay, thanks for checking!

 

I know about Graph2Font! it is also an awesome tool, but I haven't used it yet. But I have put it on my list of cool Atari stuff to check out

 

If anyone is interested, I have compiled the latest versions of Mad Pascal and MADS for Mac OS:

 

Mad Pascal 1.5.8:

https://github.com/starfighter06/Mad-Pascal-for-Mac-OS

 

MADS 2.0.8:

https://github.com/starfighter06/MADS-for-Mac-OS

 

I did it for my own purposes as I am a Mac OS user, but maybe it is useful to other people as well.

[tebe]

solution

var
PlayfieldDisplayList: array [0..2] of byte = ($41, 0,0 );

begin
PlayfieldDisplayList[High(PlayfieldDisplayList)-1 ] := lo(word(@PlayfieldDisplayList));
PlayfieldDisplayList[High(PlayfieldDisplayList) ] := hi(word(@PlayfieldDisplayList));

Edited July 21, 2019 by tebe

[starfighter]

Hi Tebe,

thanks, updating the array after initialisation is is exactly what I did as a workaround. So I assume, there is no other way than doing this. Thank you for the clarification!

[danwinslow]

I thought that some pascal or other I've used in the past allowed pointers - like this below. Does Mad Pascal not support that?

Cptr = ^char

[tebe]

1 hour ago, danwinslow said:

I thought that some pascal or other I've used in the past allowed pointers - like this below. Does Mad Pascal not support that?

Cptr = ^char

pointers, typed pointers are allowed

 

var cptr: ^char;

 

mp_pointers.7z