Jump to content
IGNORED

128 bytes


Recommended Posts

I need 128 bytes in a static, known location. I need it to be safe from molestation by DOS's and ordinary user programs. Does not have to be contiguous.

I thought CASBUFF might be ok, but a couple dos's walk all over it. I know page 6 is supposed to be free, but so many people use it as 'free' that it's probably not really any more.

I realize this is probably a fruitless quest, but I thought I'd ask before resorting to more drastic measures.

Link to comment
Share on other sites

Yeah, relocatable is what I was trying to avoid. It's config data coming from the loader, and I wanted to avoid having to thread indirect references everywhere. What I'll do is just burn 128 bytes at the top of each bank, and have the handler init copy the data into each bank at init time. That will give fixed addresses and it's mostly static data anyway. I was also using it as a fast way to have dynamic data visible to all banks, but I can put in some other way to handle that.

Link to comment
Share on other sites

Another vote for the stack here. I've never seen the stack go more then ~15 bytes deep except where I did it myself, passing 40 bytes via the stack. Even at that, everything is free from $100 to ~$1A0. If I have it right, the task you have at hand is so taxing, it is not like there will be enough room or processing power left over for other programs.

Link to comment
Share on other sites

There's various parts of Page 3 that are free but the potential is that a nonstandard OS might use some of them which could cause compatability issues.

Another problem is page 2 and 3 are wiped on warmstart which means anything you put there won't be persistent.

Link to comment
Share on other sites

Another vote for the stack here. I've never seen the stack go more then ~15 bytes deep except where I did it myself, passing 40 bytes via the stack. Even at that, everything is free from $100 to ~$1A0. If I have it right, the task you have at hand is so taxing, it is not like there will be enough room or processing power left over for other programs.

 

I'll give that a try. Actually, there's plenty of room/time left over for other programs. I thought the same as you did until I started experimenting. UDP especially is extremely light. TCP is kind of heavy but with proper throttling and enough buffers it works fine. TCP has features to handle slow endpoints, and winds up working about like a fast modem. I have had to really go through the whole process and optimize, though. Currently transitioning entirely to no-copy handling of the data (as long as the application is ready).

Graphics intensive games that rely on a lot of vblank and DLI's are probably out of scope, but otherwise things seem to run fine.

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...