Locking up now.. running out of memory, or poor memory management.??

Started by stiggity, January 08, 2011, 11:41 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

stiggity

Anyone..
What is the size of the biggest BASIC program that can be loaded in bank 15.
My main body is 41blocks (stays in memory the entire duration), and my biggest module is 42blocks.
My BBS has been locking up.. almost like its running out of memory. It cant be variables, becuase I
use alot of the same ones. If i go from my jump table in ML, LDA#$OE, STA $FF00, JMP $9000 is the
module @ $9000 in bank15? i load each module like bload"module.o",b0,p36864,u8 , should i call a bank0
before i enter my jumptable @ $1300?? BANK0:sys4864+xx then when the module @ $9000 has ended, do
a BANK15?

I'm sorry if this is starting to sound confusing. When my BBS did not have the 42block file transfer section module,
all users would participate in the Message Boards. and that module is only 28blocks, and theBBS would stay up for weeks
upon weeks, with no issues. When my file transfer section loads in the protocols @ $9000 is that bank15?

-Steve


Hydrophilic

Whatever your ML program does to $FF00 won't affect the BASIC BANK statement.  So if you issue BANK0:SYS 4864 and that module changes $FF00, then when BASIC regains control it is still in BANK 0.  Only you can know if your program needs to change to a different BANK later.

If your ML program is at $9000 in RAM, that is not BANK 15.  BANK 15 is all ROM above $4000 (except I/O region).

It sounds like you are doing things correct...

BANK 0: SYS 4864
.1300 lda #$0e
.1302 sta $ff00
.1305 jmp $9000

A faster way might be...

BANK 0: SYS 36864
.9000 lda #$0e
.9002 sta $ff00
.9005 ...

The configuration value you are using, $0e, does not correspond to any standard BANK number.  A shame because it is very useful for most software programmers.  Most of the BANK configs seem designed for firmware programmers (function ROM, cartridge, or the KERNAL / BASIC authors).

If your BASIC program starts at $1c00 (which is normal unless you use VIC-II bitmap), and it limited to $9000 by your ML module, then you have about 29 kiByte or 116 blocks available.

If your ML program starts at $9000, and it is limited by KERNAL/Editor ROM at $C000 (using mem.config. $0e), then you have 12 kiByte or about 48 blocks available.

Good luck!
I'm kupo for kupo nuts!

BigDumbDinosaur

Quote from: stiggity on January 08, 2011, 11:41 AMWhat is the size of the biggest BASIC program that can be loaded in bank 15.
Programs don't load into bank 15.  They load into RAM-0 or RAM-1.

There is a location called MAXMEM0 ($1212-$1213) that defines the highest address-1 that BASIC is allowed to use in RAM-0 (not bank 15â€"a bank is merely an arbitrary combination of RAM, ROM and I/O).  Following a normal reset, MAXMEM0 is initialized to $00 $FF, which means that a BASIC program can use RAM up to $0FEFF inclusive.  An attempt to load a program that would overrun that address will fail with an out-of-memory error.

If you wish to protect some memory in RAM-0 from being overwritten by BASIC, such as for an M/L program, store an appropriate address into MAXMEM0.  Following that, if you were to PRINT FRE(0) you would see that the total space for a BASIC program has been reduced.  The change to MAXMEM0 will remain undisturbed until the next reset.

QuoteMy main body is 41blocks (stays in memory the entire duration), and my biggest module is 42 blocks.
You should refer to a program's size in bytes, not blocks, as blocks (sectors) are a concept limited to disk storage.  What matters in memory is the number of bytes occupied by code and data.  In this case, 41 + 42 blocks would be equivalent to 21,248 bytes.  Assuming BASIC starts at the normal $01C01 address, your usage would extend up to $06F01.

QuoteMy BBS has been locking up.. almost like its running out of memory. It cant be variables, becuase I
use alot of the same ones.
Reuse of integer and floating point variables doesn't affect RAM-1 memory consumption, but reuse of string variables, especially string arrays, can trigger frequent bouts of garbage collection.  While GC isn't nearly the issue on the C-128 that it was on the C-64, it can occasionally result in an apparent cessation of activity while BASIC reorganizes string storage.  Be that as it may, unless you have a huge number of variables in use, GC should take but a few seconds.

QuoteIf i go from my jump table in ML, LDA#$OE, STA $FF00, JMP $9000 is the
module @ $9000 in bank15?
No.  As I said above, programs don't load into a bank.  It's either RAM-0 or RAM-1.  The MMU mask $0E (%00001110) selects RAM-0 from $0400 to $BFFF, the screen kernel from $C000 to $CFFF, I/O from $D000 to $DFFF, and the rest of the kernel from $E000 to $FFFF.  Measuring from the start of BASIC at $1C01, that's 43K of contiguous RAM.

Quotei load each module like bload"module.o",b0,p36864,u8 , should i call a bank0
before i enter my jumptable @ $1300?? BANK0:sys4864+xx then when the module @ $9000 has ended, do
a BANK15?
I can't answer that question for you, as I have no idea what sort of memory map your module(s) requires to function.  Assuming you are writing %00001110 into the MMU configuration register ($FF00), you have contiguous RAM in RAM-0 from $1300 to $BFFF.  Unless your module that is being loaded at $9000 extends above $BFFF, you should be okay with SYSing to the jump table at $1300 with BANK 0.  However, exactly what purpose does the jump table at $1300 serve if all it does is JMP $9000?

QuoteI'm sorry if this is starting to sound confusing. When my BBS did not have the 42block file transfer section module,
all users would participate in the Message Boards. and that module is only 28blocks, and theBBS would stay up for weeks
upon weeks, with no issues. When my file transfer section loads in the protocols @ $9000 is that bank15?
Yes it is confusing.  At the risk of being crass and offensive, it sounds to me as though you didn't properly organize your program before pounding code into the machine.  You need to thoroughly read and comprehend the documentation on C-128 memory management.  This is all old stuff that has been around for decades.
x86?  We ain't got no x86.  We don't need no stinking x86!

stiggity

BDD:Thanks.. always enjoy reading your replies... Are you working on any other projects, other than the date & time calendar?

Hydro:
When you reply, it gives me faith. I have a question. Let's say i have "STEVE" store in BUFFER, and the BUFFER's length in BUFLEN.
How could i assign the length of the BUFFER to a variable length? like, if i take the contents of BUFFER (which is simply "STEVE") and use INDSTA to loop the BUFFER
contents, into "a$", it works fine, but the varaible "a$", it's length is all messed up. I know the BUFFER length, which is stored in BUFLEN. How can i make BUFLEN point to "a$"'s length?

-Steve

Hydrophilic

You need to update the string descriptor for a$.  Unlike string data (stored at top memory), the descriptor is stored near the bottom with normal (floating-point) variables like x and y.

Here is an example a$
>10400 41 80 04 FA FE XX XX

The $41 $80 is the name, $04 is the length, and $FEFA is the address of the string data.  (The XX are wasted bytes.)  The quick and dirty method would be to simply change the $04 length to whatever BUFLEN is.  But you should know that you can't make a string any longer (you would have to re-allocate memory).  An easy trick is to have BASIC make a$ be 255 chars long at the start of the program, and then the ML program can change the length without worry.

Have fun!
I'm kupo for kupo nuts!

BigDumbDinosaur

Didn't we just go over this variable creation thing the other day?
x86?  We ain't got no x86.  We don't need no stinking x86!

stiggity

Hydro:
If i used the $7b0b STRFIN routine, how would i change the string (a$) length, too whatever BUFLEN is?
Or, would there be anohter approach, without using $7b0b? Im sure id need to get hi/lo byte of where a$
is, and _then_ start fiddling around. If this sounds like something you could assist me on, that would be great.

-Steve

stiggity

BDD:
If, in fact we _did_ already cover this tidbit of information, and you dont feel like reading/participating, then you probably should check out another thread, eh?
Hydro, is smart, and knows what he's doing! If _anyone_ asks me any kind of question, regardless what its about.. cars, computer, woman, etc.. i try to give them
the best answer possible. And thats what individuals like Lokalhorst, Wagner, Hydrophilic, do. If you dont feel like helping, then..... don't.

HYDRO!!
This is kind of an Off the wall question, but here goes. In my BBS i am constantly performing a "gosub10" which checks for carrier, carrier loss, boot user, and several other tasks, and once everything is all done, and the user has not dropped carrier, it RETURNS to wherever i called the subroutine @ line 10. Here's the question, _If_ someone drops carrier, or i boot them, the bbs flows too a drop dtr routine, then resets. Leaving, a gosub command on the stack. Would there be any method of "stripping" all the gosub pointers from the stack. And, if there arent any, just RTS, or if there are some un-answered pointers on the stack, clear them out, and then RTS?

     I have an equivalent of this i use on the 64. but... im not using that machine anymore. If you understand what im saying, let me know. Much THanks!! :) :) :)

-Steve

Hydrophilic

Yeah we did discuss variables already.  I thought that example might have been helpful... guess not...

Anyway, $7b0b will return a pointer directly to the descriptor (beyond the name).  Maybe something like...

LDA #$49 ;pointer returned by $7b0b
STA $2b9 ;update INDSTA
LDX #1 ;bank
LDY #0 ;index length in descriptor
LDA fnlen ;new length
JSR INDSTA


For the gosub issue, the "clean" way would be to use some kind of flag so you don't leave junk on the stack in the first place.

But then you end up spending resources for flag manipulation that is *almost* never needed... I've always wished BASIC (and C for that matter) had a RETURN n function to pop off those unneeded layers (um, I guess you could throw an exception in C).

Anyway you can try BANK15:SYS20570,5

That will remove 5 bytes from the BASIC stack.  It doesn't check to make sure it is a GOSUB entry.  So if you have other stuff active (like FOR or DO), it will probably crash!

Have fun!!

I'm kupo for kupo nuts!

airship

BDD is always helpful. He just expects people to use the standard resources at hand before asking questions. I don't think that's unreasonable. It's how we learn. Think of him as a curmudgeonly old professor who expects you to do your own research before you come asking questions. :D
Serving up content-free posts on the Interwebs since 1983.
History of INFO Magazine

stiggity

Airship,
You know.. i have never typed any kind of harsh words towards anyone, and yes, I do own the 128 PRM, and have Mapping the 128 in .pdf, and of course i read them both. But there are times, when you read something over and over, and it _still_ doesnt make sense.. then i try to look for 128 assem source examples, and you two might be able to find them, but i never get lucky. I usually return to this forum, ask a question.. (thats how i learn) and usually, some person, (i always end up envying them, becuase there brain works right) responds, with a little assistance, instead of ... "ohh.. read 2000 pages, and then read anohter 300.." and i usually do.. to no avail. I dont mean to sound nasty and BDD _has_ helped me in the passed. Anywayz.. BDD, if i came out at the fingertips, just consider me an arrogant, ignorant troll..

-Steve

BigDumbDinosaur

Quote from: stiggity on January 12, 2011, 03:54 AMBDD:
If, in fact we _did_ already cover this tidbit of information, and you dont feel like reading/participating, then you probably should check out another thread, eh?

I am participating when I suggest you research the problem.  You shouldn't use the welfare recipient mentality around me because I have a real short fuse when it comes to people expecting help without doing at least some of the legwork.  :)

Anyhow, take a look at this.
x86?  We ain't got no x86.  We don't need no stinking x86!