Mad Pascal

[bocianu]

1 hour ago, tebe said:

update https://github.com/tebe6502/Mad-Pascal

- {$UNITPATH filename} is equivalent {$LIBRARYPATH filename}
- USES unit_name in 'filename'
  
uses crt, vector in '..\3d\vector.pas';

 

[tebe]

new version, fixed https://github.com/tebe6502/Mad-Pascal/issues/122

 

doc update

https://mads.atari8.info/doc/en/types/#untyped

[tebe]

new version MP

 

- SYSTEM: GetMem(a:size): pointer;
- CRT_ATARI: TextBackground
- OVERLOAD block allocation rewritten

 

example using new features QRCLI (can be compiled using the FPC or MP)

 

QRCLI.obx QRCLI.pas

[roeoender]

Hi, many thanks for this great tools (MP & MADS).

 

I noticed a compilation bug at asm stage when using

function Atascii2Antic(s: string):string;

from b_crt.pas (Bocianu lib):

 

lda @FORTMP_0357_0::#$00
mycode.a65 (811) ERROR: Extra characters on line

 

function Atascii2Antic(s: string):string;overload;
var i:byte;
begin
    result[0]:=s[0];
    for i:=1 to byte(s[0]) do // <- Here
        result[i]:=char(Atascii2Antic(byte(s[i])));
end;

The offending line is marked with // <- Here

I solved it by introducing a variable:

function Atascii2Antic(s: string):string;overload;
var i:byte;
	k : byte;
begin
    result[0]:=s[0];
	k := byte(s[0]);
    for i:=1 to k do
        result[i]:=char(Atascii2Antic(byte(s[i])));
end;

 

As  this function is used internally by some CRT_Write wariants it is quite important.

So glad if this would be sorted out either on the compiler side (as oryginal code looks ok) or by patching b_crt.

 

Another tiny thing such code creates compilation error:

{commented out}//and event more

it requires space between } and // - not that important - just to let you know.

 

[tebe]

1 hour ago, roeoender said:

I noticed a compilation bug at asm stage when using

function Atascii2Antic(s: string):string;

from b_crt.pas (Bocianu lib):

Apparently you are not using the latest version of Mad-Assembler

 

https://github.com/tebe6502/Mad-Assembler

[roeoender]

20 hours ago, tebe said:

Apparently you are not using the latest version of Mad-Assembler

 

https://github.com/tebe6502/Mad-Assembler

Thank you for your quick reply - I used 2.1.5 which I thought was latest stable.

I tried latest git master and indeed it works, so I understand at this stage it is ok to simply keep using the latest commit version.

Thank you.

[pirx]

https://en.wikipedia.org/wiki/Niklaus_Wirth died few days ago, but Pascal lives!

[Gury]

Legend, rest in peace! You invented a language which followed me in my personal and bussiness life.

Thank you!

 

[drunkeneye]

my port is getting too big.

is there any way to 'dynamically' load code+data?

i have several locations which do not need to reside in memory at the same time.

so i'd like to have something like this

 

var
  playerHealth: byte;
  fname: String = "ALOCATION.APL";

procedure showLocation(a: char);
begin;
  fname[1] := a;
  unAPL(fname, Pointer($9000));
  asm;
     jsr $9000 
  end;
end;

 

this could technically work if i had assembler code, even the access to

playerHealth could be performed by making playerHealth absolute at say $e000,

so no real 'transfer' would be necessary between pascal and assembler.

however, the location code is all pascal and needs libraries like b_crt.

has anyone an idea how to perform this kind of loading in madpascal?

thanks a lot!

 

 

[tebe]

1 hour ago, drunkeneye said:

'dynamically' load code+data?

 I read somewhere that there was something like this in the days of the Apple II

 

have you tried ?

{$define romoff}

 

the lowest possible address $0980, if you use FoxDOS, xBOOT

-code:address   Code origin hex address
-c address      Code origin hex address

Edited January 18 by tebe

[drunkeneye]

37 minutes ago, tebe said:

 I read somewhere that there was something like this in the days of the Apple II

 

have you tried ?

{$define romoff}

 

the lowest possible address $0980, if you use FoxDOS, xBOOT

-code:address   Code origin hex address
-c address      Code origin hex address

 

thanks, yes, i have xboot running. since xboot must reside for loading ops,

i start my code at $0c00.

right now the code+data ends around $9800, and i use already $b000-$d000.

i can move few things to $e000, but still have the feeling this could be very tight.

code can be space-optimized, i am sure, but i am now in development phase,

and optimizing for space now could mean re-optimizing the code several times.

thus, i would prefer a dynamic solution, also because i want to show large bitmaps

and would need another 16k for that

 

is there any way to force mad pascal to relocate a given function to a certain

location? like procedure location(a: byte; b:byte); absolute $e000; ?

this could solve all my problems

 

 

[drunkeneye]

i think i have a solution, but would be very eager to know if there are other, more flexible ones.

in my case, as said, the location has only few dependencies on the main code (at least at this

stage i believe so). so i create a new main_location.pas and add everything that i need to make

the location work, e.g. routines from b_crt. there are player variables that will be modified within

the location, but these are located at specific addresses at $e000, so this is no real dependency.

then i can compile this with say addresse $8000. mad pascal will create the binary, and somewhere

there will be a main programm (with some init code i dont care about) and then the call to start the

location (say jsr $9403). in my main_location i can call this (to force mad pascal compiling it),

and after that i use xbios to dump all $8000-$c000 (this would be the maximal range) to a file in

the ATR. now (in theory) this code is now complete and does not need any other code from the main

program. this dump i could now compress and then load it from my 'real' main program to $8000.

then i can call the location routine using $9403. thats all. this should work fine, since, as said all

dependencies are within the $8000 block and the variables to modify the player are at $e000 (so are

not cleared by the location code, just modified as needed). the only caveat, however, is that all routines

i use from e.g. b_crt would be duplicated. yet, i think thats a small price to pay. it will would work

very nice i think with the bitmaps i wanted to load, because i can use this memory area to

first load the bitmap then load dynamically the location. the 'only' other thing is that loading times

will be high. in my emulator everything is fast, and i hope the SIDE3 cartridge i have, will also

load quickly, but perhaps real atari users will have a lot of time to brew coffee

 

thats theory right now, i have to relocate all player variables to $e000 first and then

test it, will take some time. i will report back, in case anyone is interested if it works.

 

and if anyone else has another solution, i'd appreciate to hear about it!

 

[Atlan_Roland]

2 hours ago, drunkeneye said:

i think i have a solution, but would be very eager to know if there are other, more flexible ones.

in my case, as said, the location has only few dependencies on the main code (at least at this

stage i believe so). so i create a new main_location.pas and add everything that i need to make

the location work, e.g. routines from b_crt. there are player variables that will be modified within

the location, but these are located at specific addresses at $e000, so this is no real dependency.

then i can compile this with say addresse $8000. mad pascal will create the binary, and somewhere

there will be a main programm (with some init code i dont care about) and then the call to start the

location (say jsr $9403). in my main_location i can call this (to force mad pascal compiling it),

and after that i use xbios to dump all $8000-$c000 (this would be the maximal range) to a file in

the ATR. now (in theory) this code is now complete and does not need any other code from the main

program. this dump i could now compress and then load it from my 'real' main program to $8000.

then i can call the location routine using $9403. thats all. this should work fine, since, as said all

dependencies are within the $8000 block and the variables to modify the player are at $e000 (so are

not cleared by the location code, just modified as needed). the only caveat, however, is that all routines

i use from e.g. b_crt would be duplicated. yet, i think thats a small price to pay. it will would work

very nice i think with the bitmaps i wanted to load, because i can use this memory area to

first load the bitmap then load dynamically the location. the 'only' other thing is that loading times

will be high. in my emulator everything is fast, and i hope the SIDE3 cartridge i have, will also

load quickly, but perhaps real atari users will have a lot of time to brew coffee

 

thats theory right now, i have to relocate all player variables to $e000 first and then

test it, will take some time. i will report back, in case anyone is interested if it works.

 

and if anyone else has another solution, i'd appreciate to hear about it!

 

Hi, 

I’m doing pretty much the same in my (Ultima5) project:
Compile my 'overlay' function for a certain address; at bootup they get loaded consecutively and copy themself into extended RAM (my minimum target is a 128K machine);

when calling such an outsourced procedure, i move that memory area into the 'overlay area' and JMP there (which JMPs back to a defined space in the 'main' program afterwards)
 

:: ----------------------------------------------------------------
:JMP_OVL
set PRG=OVERLAY
REM call checkage.bat %PRG%.PAS
REM start OVERLAY.XEX in framebuffer SCR2
mp.exe -code:A6F0 -ipath:c:\mp\lib %PRG%.pas -define:%PRG%
if ERRORLEVEL 1 goto :EOF
c:\mads\mads.exe %PRG%.a65 -x -i:c:\mp\base -o:%PRG%.xex
if ERRORLEVEL 1 goto :EOF

:: ----------------------------------------------------------------
:JMP_TALK_OVL
set PRG=TALK_OVL
mp.exe -code:A6F0 -ipath:c:\mp\lib %PRG%.pas -define:%PRG%
if ERRORLEVEL 1 goto :EOF
c:\mads\mads.exe %PRG%.a65 -x -i:c:\mp\base -o:%PRG%.xex
if ERRORLEVEL 1 goto :EOF

:: ----------------------------------------------------------------
:JMP_STAT_OVL
set PRG=STAT_OVL
mp.exe -code:A6F0 -ipath:c:\mp\lib %PRG%.pas -define:%PRG%
if ERRORLEVEL 1 goto :EOF
c:\mads\mads.exe %PRG%.a65 -x -i:c:\mp\base -o:%PRG%.xex
if ERRORLEVEL 1 goto :EOF

 

pretty crude and the worst is that there is so much redundancy and wasted RAM for often same dependencies on libraries and functions..     

 

like you also mentioned: in lack of other options, for some redundant functions i started coding them directly in ASM and store them at a certain location to JSR call them..  but i' lack so much experience in ASM coding 😕 

   

i'm thinking that maybe someday we'll get the possibility of a mad pascal directive to define the compile location of certain procdures, so these can be addressed from different independed executables; but that’s up to Tebe plans.

Edited January 18 by Atlan_Roland

[drunkeneye]

2 hours ago, Atlan_Roland said:

Hi, 

I’m doing pretty much the same in my (Ultima5) project:
Compile my 'overlay' function for a certain address; at bootup they get loaded consecutively and copy themself into extended RAM (my minimum target is a 128K machine);

when calling such an outsourced procedure, i move that memory area into the 'overlay area' and JMP there (which JMPs back to a defined space in the 'main' program afterwards)
 

:: ----------------------------------------------------------------
:JMP_OVL
set PRG=OVERLAY
REM call checkage.bat %PRG%.PAS
REM start OVERLAY.XEX in framebuffer SCR2
mp.exe -code:A6F0 -ipath:c:\mp\lib %PRG%.pas -define:%PRG%
if ERRORLEVEL 1 goto :EOF
c:\mads\mads.exe %PRG%.a65 -x -i:c:\mp\base -o:%PRG%.xex
if ERRORLEVEL 1 goto :EOF

:: ----------------------------------------------------------------
:JMP_TALK_OVL
set PRG=TALK_OVL
mp.exe -code:A6F0 -ipath:c:\mp\lib %PRG%.pas -define:%PRG%
if ERRORLEVEL 1 goto :EOF
c:\mads\mads.exe %PRG%.a65 -x -i:c:\mp\base -o:%PRG%.xex
if ERRORLEVEL 1 goto :EOF

:: ----------------------------------------------------------------
:JMP_STAT_OVL
set PRG=STAT_OVL
mp.exe -code:A6F0 -ipath:c:\mp\lib %PRG%.pas -define:%PRG%
if ERRORLEVEL 1 goto :EOF
c:\mads\mads.exe %PRG%.a65 -x -i:c:\mp\base -o:%PRG%.xex
if ERRORLEVEL 1 goto :EOF

 

pretty crude and the worst is that there is so much redundancy and wasted RAM for often same dependencies on libraries and functions..     

 

like you also mentioned: in lack of other options, for some redundant functions i started coding them directly in ASM and store them at a certain location to JSR call them..  but i' lack so much experience in ASM coding 😕 

   

i'm thinking that maybe someday we'll get the possibility of a mad pascal directive to define the compile location of certain procdures, so these can be addressed from different independed executables; but that’s up to Tebe plans.

hi, thanks for sharing, and also for the source code of your ultima5 project! 

i already downloaded it, but didnt quite look at the code yet.

so, basically you are doing the same, but you are using extended memory instead of disk,

like i plan to do, right? i also thought about 128kb, it would solve all my problems 'immediately',

but 64kb it is, it should be enough for everyone, as we all know

 

 

[tebe]

in general, your description suggests LIBRARY

 

https://www.freepascal.org/docs-html/prog/progse55.html

[Atlan_Roland]

12 minutes ago, tebe said:

in general, your description suggests LIBRARY

 

https://www.freepascal.org/docs-html/prog/progse55.html

yes, like LIBRARY (which i remember from turbo pascal).

though i was rather thinking about the proposed 'ORIGIN' directive, that would - i think - act like a 'RAM based' LIBRARY: https://github.com/tebe6502/Mad-Pascal/issues/119

 

 

[drunkeneye]

16 hours ago, tebe said:

in general, your description suggests LIBRARY

 

https://www.freepascal.org/docs-html/prog/progse55.html

sorry, i dont get this. is library supported in mad pascal?

like i could define all my locations in different libraries and then

just write loadLibrary('pub.loc')? and mad pascal would generate

the pub.loc? and i would just unload the library before loading

another library? this would be excellent. my loading routine

seems to work now, but it is not that very nice given that i

have to start the compiled .xex to obtain the memory dump.

 

[drunkeneye]

15 hours ago, Atlan_Roland said:

yes, like LIBRARY (which i remember from turbo pascal).

though i was rather thinking about the proposed 'ORIGIN' directive, that would - i think - act like a 'RAM based' LIBRARY: https://github.com/tebe6502/Mad-Pascal/issues/119

 

 

yes, the origin directive would be very cool to have since i have to move all my 50+ variables to $e000 by hand

hope to see this feature soon.

 

[scttgs]

Hi @tebe

 

Mad-Pascal Essential Libraries docs had not been translated to English, so i spent a few days doing the conversion.  Pull request submitted.

 

Thanks

[tebe]

https://olimex.wordpress.com/2024/02/05/did-you-ever-hear-for-mad-pascal-now-you-can-program-neo6502-with-this-32-bit-turbo-pascal-for-atari-xl-xe-compiler/?fbclid=IwAR0v7ydDopAoDN0BBRfwLGsT_EkpEbFLGxHwXudLgnRe8TCq-yqR8zM03tQ

[Gury]

I have to point out that Mad Pascal is the most polished cross-compiler language for Atari 8-bit machines. Adding great support from the author in nearly daily basis, hats down!

Such thing occupies lots of personal life, so it must be timed and balanced.

 

Language of my choice...

Thank you!

 

[neuling]

Hi good afternoon. At 75 years old, I can no longer manage compiling for the C64 and MadPascal with windows

 

Please download the latest version of madpascal. The mads is from 2020.

I can't find a new one that's compiled for it.

what is please > mp-build-c64 .......?  "mp-build-c64 main.pas r" .  is it for windows?

I do not find it. I have madcascal the folder.

 

What do I have to put where so that I can compile a C64 program?

 

Unfortunately I can't handle it.

 

Thanks.

 

for windows and winvice c64

--------------------------------

mp="$HOME/Programs/MadPascal/mp"
mads="$HOME/Programs/mads/mads"
base="$HOME/Programs/MadPascal/base"

if [ -z "$1" ]; then
  echo -e "\nPlease call '$0 <argument>' to run this command!\n"
  exit 1
fi

name=${1::-4}

$mp $name.pas -t c64 -z 10 -o

if [ -f $name.a65 ]; then
  [ ! -d "output" ] && mkdir output
  mv $name.a65 output/
  $mads output/$name.a65 -x -i:$base -o:output/$name.prg
else
  exit 1
fi

if [ ! -z "$2" ]; then
  x64 output/$name.prg
fi

----------------------------------------------

 

Edited February 15 by neuling

[tebe]

8 hours ago, neuling said:

I can't find a new one that's compiled for it.

https://github.com/tebe6502/Mad-Pascal

 

exe binary for Windows https://github.com/tebe6502/Mad-Pascal/tree/master/bin/windows

 

minimum requirements for a directory with MP, files and subdirectories

 

MadPascalPath\
  mp.exe
     base\
     rtl_default.asm
     rtl6502_a8.asm
     rtl6502_c4p.asm
     rtl6502_c64.asm
     rtl6502_neo.asm
     rtl6502_raw.asm
          atari\
          c4p\
          c64\
          common\
          neo\
          raw\
          runtime\
     lib\
     aplib.pas
     atari.pas
     blowfish.pas
     c64.pas
     ...
     src\
         targets\
         crt.inc
         graph.inc
         system.inc

MP compile, target c64

mp.exe -t c64 filename.pas
mads.exe filename.a65 -x -i:<MadPascalPath>\base

Edited February 15 by tebe

[neuling]

hello thanks for help.

 

greeting

[roeoender]

Hi Tebe seems I stumbled upon some strange MP behaviour (bug?).

Attached code doesn't update variable via pointer as expected - on line 18:

g_sim_objPtr^.action := 20;

as output is:

PTR^.A 7 SI.A 7
UPD VIA PTR 20:
PTR^.A 7 SI.A 7
UPD VIA INST 25:
PTR^.A 25 SI.A25

But when in mg.pas you simply remove/comment out "initialization" keyword in mg.pas on also line 18,

the output is as expected:

PTR^.A 7 SI.A 7
UPD VIA PTR 20:
PTR^.A 20 SI.A 20
UPD VIA INST 25:
PTR^.A 25 SI.A25

 

Of course RL code in which I got this bug is much more elaborate, but this is a good example.

 

It seems that following assembly code causes it (ony difference):

 

@UnitInit

	rts

 

I first tested it on 2024-02-01 version and today tested it on current:

Mad Pascal Compiler version 1.7.1 [2024/02/16] for 6502

 

initialize_prob.zip