128 bytes

[danwinslow]

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.

[flashjazzcat]

People usually resort to the bottom of the stack, but since people resort to the bottom of the stack, even that's not safe...

[+Stephen]

Could you declare a small block for PM/G and use the "free" unused space in that window?

[+David_P]

He's writing driver code for the ethernet cart, so it has to play nice with other apps.

Could it be a relocatable block, or would that introduce too much complexity?

[flashjazzcat]

Looking for RAM in this way is something you usually have to do when patching the OS, but if your software runs under DOS... as David suggests, the best and usual thing to do is to relocate it immediately above MEMLO.

[danwinslow]

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.

[Synthpopalooza]

The printer buffer (I think it's at around the 900-1000 range?) might be of use here

[ricortes]

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.

[Rybags]

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.

[danwinslow]

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.