search

Pinacolada64 / ImageBBS

A bulletin board system (BBS) for the Commodore 64.
15 stars 5 forks source link

Lack of memory available in the subs for writing messages #21

Closed x-tec2017 closed 6 years ago

x-tec2017 commented 6 years ago

The amount of free memory available for writing messages in the subs is inversely proportional to the number of directory entries. This can limit the user to only a few lines for posting or replying to messages.

x-tec2017 commented 6 years ago

Reduced the maximum number of directory entries to 30 in the subs by modifying +.MM.sb-post line 4084 and +/NM.netsub3 line 4058. Changed >59 to >29 in both program modules.

Pinacolada64 commented 6 years ago

While that works for now, I'd really lke to investigate loading the sub-board directories (SB, UD and UX) into structs. They're stored in a different area of memory (currently not sure where), unlike arrays which are stored in the limited amount of free RAM past the end of im and the top of BASIC.

If my hunch is correct, while using the subs, if something gets modified (file download count incremented, new post/response written), that particular directory entry could be written back to the respective d.* file at quit to maintain backwards compatability.

Maybe, maybe this could be used to break the 60 entry limit - rather than load the entire directory into RAM, keep the d.* file open on disk and query it instead. This would be slower, but everything is a trade-off. Faster scans from RAM mean fewer entries, slower scans means holding the disk file open (perhaps only until a post got read; you have to juggle internal disk buffers on a 1541 at least, I think there's a limit of 2 REL files open at once? no clue about more modern drives like CMD/LTK. Will have to research.)

x-tec2017 commented 6 years ago

The CMD could probably handle it but the Lt.K, not. The Lt.K can only open one rel file at a time.

On Sat, Jul 7, 2018, 4:11 PM Ryan Sherwood notifications@github.com wrote:

While that works for now, I'd really lke to investigate loading the sub-board directories (SB, UD and UX) into structs. They're stored in a different area of memory (currently not sure where), unlike arrays which are stored in the limited amount of free RAM past the end of im and the top of BASIC.

If my hunch is correct, while using the subs, if something gets modified (file download count incremented, new post/response written), that particular directory entry could be written back to the respective d.* file at quit to maintain backwards compatability.

Maybe, maybe this could be used to break the 60 entry limit - rather than load the entire directory into RAM, keep the d. file open on disk and query it instead. This would be slower, but everything is a trade-off. Faster scans from RAM mean fewer entries, slower scans means holding the disk file open (perhaps only until a post got read; you have to juggle internal disk buffers on a 1541 at least, I think* there's a limit of 2 REL files open at once? no clue about more modern drives like CMD/LTK. Will have to research.)

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Pinacolada64/ImageBBS/issues/21#issuecomment-403240203, or mute the thread https://github.com/notifications/unsubscribe-auth/AganobtjcocbI3rQrtKshqOsiKIB0cpsks5uERXrgaJpZM4U7a0I .

Pinacolada64 commented 6 years ago

The Lt.K can only open one rel file at a time.

Good to know. I'm honestly a bit surprised.

rather than load the entire directory into RAM

I meant "...as a RAM-hogging string array."

It would be nice to also re-think how scanning for new posts is done; this is a common complaint on an Image BBS with no SuperCPU. Other BBSes use "message pointers" instead. Each method has its benefits and drawbacks. I realize you have to scan each thread, message by message, to compare "last call date" as being older than the post or reply date. That takes time.

I think the old SEQ subs had the first/last post dates on a per-post basis, saved directly in the d.* SEQ file, didn't they? It's been so long, I forget.

jayctheriot commented 5 years ago

As a "quick fix" I drop to local mode FG and get back to responding. After garbage collection, 253 lines are available.

If there was a way to force garbage collection prior to opening the editor, it may provide a fix.

x-tec2017 commented 5 years ago

Jay, you will only see 253 lines available if you are in local or pseudo-local (zz) mode. You don't really have that many lines available but the amount of memory available will be displayed in bytes in the editor. If you're not in local or zz mode, the editor will display the actual number of lines available. Still, your method of doing a FG will provide more lines usually. There is a gosub in the im file that can be called prior to loading the editor or simply insert &,40 into the basic file just prior to entering the editor.

On Sun, Apr 21, 2019, 11:32 PM jayctheriot notifications@github.com wrote:

As a "quick fix" I drop to local mode FG and get back to responding. After garbage collection, 253 lines are available.

If there was a way to force garbage collection prior to opening the editor, it may provide a fix.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Pinacolada64/ImageBBS/issues/21#issuecomment-485314403, or mute the thread https://github.com/notifications/unsubscribe-auth/AIDKPIMO3KHSL5BMSFDPR2TPRUWWNANCNFSM4FHNVUEA .