Usually free memory areas

[marquisor]

for a simple basic program (a mapgen) i need to know what memory areas are free and usually used for storing data.

i would need 20.000B of space for a map of 200x100 cells. i don't know much about the MMU yet and the c128 manual is too compact for this - i guess - simple answer...

so what memory ranges in which banks can i usually use safely? and do i have to switch to that bank always if i want to access the data there? furthermore i maybe want to copy/draw some parts out of this 20.000B RAM to the screen at $0400-


in C64 mode:
i would store precalculated data for chars at least in $C000-$CFFF. i want to do that in C128 mode, but which banks and which areas?

[airship]

You really need a copy of "Mapping the Commodore 128" for questions like this. There's a free PDF at Bombjack.

[BigDumbDinosaur]

As airship said, it's too complicated a subject for a forum post.  In any case, doing all this from BASIC is going to be a challenge because BASIC keeps the ROMs mapped in except when reading program text or access variable storage in RAM-1.  You best bet is to throughly read Mapping the Commodore 128.  I will give you a hint though: look at the GRAPHIC commands for a way to open up lots of space below BASIC in RAM-0.

[LokalHorst]

Why think so complicated ?
Move the basic-start up to $2800 ($2801) to store the custom charset @ $2000.
(you'll have an additional buffer from $1c00 to $1fff then)
For the map create a two-dimensional array with dim A$ (200,100) and let the basic manage the bank switching.

[BigDumbDinosaur]

Why think so complicated ?

What's so complicated about using GRAPHIC to open up storage below BASIC?  You don't have to tinker with any pointers and when you're done and your disable the graphic area, everything moves back where it belongs.

[marquisor]

hello thanks for your answers so far.

i can understand at least the half of what you're saying or meaning. got two book recommendations of total about 1000 pages. will take me lots of time i guess, but i don't come around it, that's fact.

so now i thought the DIM A(X,Y) would be a good advise, to let basic manage the pointers, too... theoretically.. i started a basic program just for displaying and later scrolling a map, just a startup, which later will be a subroutine of the main game/program.

f.e. for M(80,50) i get an ?OUT OF MEMORY ERROR yet. even if i swtich banks 0,1 before... i don't want the graphic area as i want to poke it via charset on $0400 resp. 1024-2023 in a window with variable offset and size.

the map should be of course larger as that window, which could be maximum size of 40,25 (each -2 for the borders) so 38,23 is the are to display the char map. all with pokes... i don't know yet a method converting screencodes to CHR$ ascii yet too...

so i thought for simple as i would do on C64 using the $C000 RAM area for lets say 80x50 map = 4000 Bytes = 4000 chars in screencode. maybe 2 bytes for pointing what size it is in x and y, f.e. 49152,100 ; 49153,80 to know how to read it. then comes the mapdata.

i may attach the basic code resp. .prg file if you like. we are here to share but it only contains the window drawing routine yet, as the DIM failed, so i have to stop there now.


regards
marquisor

[LokalHorst]

Aloa,
regarding the 'out of memory' error, if I'm not mistaken each integer array element takes up 5 bytes, thus 20,000 x 5 is larger than the available mem.
I'm not sure, but maybe the use of a string array is better if it uses only 3 byte (lengh, ptr to str).

[marquisor]

@lokalhorst

yes, so my method of filling the map ram is least wasting memory, as i only need 1 byte per cell. even string is 3x more RAM usage.
i won't need color RAM as i can define different colors per char code, f.e. bricks, grass, swamp, mountain etc.

tried to use

DIM M(80,50)
DIM M%(80,50)
DIM M$(80,50)

all work, but i don't get any CHAR output anymore if i DIM'ed the memory area. basic program hangs then. weird.

unfortunately for using a string, i don't know how to convert screencodes to ascii codes and vice versa.

[LokalHorst]

you wouldn't need to convert screen<->ascii if you don't print (char) them and use the old fashioned poke to screen ram.

[marquisor]

i know, it was only in fact i would use strings, then i would have to convert... but i don't want that.

btw. here's the basic program so far... if of any use.