MaxCoderz

CompWiz wrote:

tr1p1ea wrote:have you tried plugging it into a PC and seeing what happens?

well, I don't think that that would work, as the calculator seems to be not turning on. But, it certainly is worth a shot.

The LCD can be completely dead, but the OS may be booting fine and will respond to silent linking requests.

If you were using the OS properly, you'd use PutAway and the other monitor vectors for cleanup code in cases like turning off from GetKey.

You have to give the OS some credit...horrible as it can be under the hood, it does its job well.

When you _InsertMem at 9D95h, you're stealing that RAM temporarily. You can do with it as you like, then when you're done, _DelMem at 9D95h the same amount you inserted. It can also be used on the data area of variables, so you can _DelMem from the data area of the variable, and _InsertMem the same ...

Yeah, it's swapped in 768 bytes at a time to userMem by repeated calls to _InsertMem and _DelMem, to relocate it to userMem.

Shells can pull this off with virtually no memory left because they swap the contents of the program from wherever it is to 9D95h in pieces (768-byte pieces, conveniently the size of one of the screen buffer saferam areas). What you'd be doing is requiring that much user RAM be free. If you're dead ...

You can steal space from there using _InsertMem and _DelMem. But don't return back to the OS like that...create a variable and use its space or delete what you insert before you quit. You can never guarantee how much user RAM is available, though...a user can run a Flash application (from the OS) wi...

ramStart EQU 8000h appData EQU 8000h ramCode EQU 8100h ramCodeEnd EQU 822Fh baseAppBrTab EQU 8230h bootTemp EQU 8251h appSearchPage EQU 82A3h tempSwapArea EQU 82A5h appID EQU 838Dh ramReturnData EQU 83EDh arcInfo EQU 83EEh savedArcInfo EQU 8406h appInfo EQU 8432h appBank_jump EQU 843Ch appPage EQU ...

I have no idea what this thread's about, but there is 1087 bytes of contiguous scratch memory at 8000h, as long as you're careful. I wouldn't rely on this for some sort of really generic library that others can use, if I read you correctly, but it's there if you _really_ need contiguous memory.

DarkAuron wrote:Can't afford to go see a movie.

But you can afford to download one!

I didn't really like it. I hate to say that, I really do, and it was pretty entertaining, but I think it fell apart by the end.

I remember hooking PC's together will null modem cables to play Duke3D. If you set yourself up right, you could see your opponents screen in the mirror. Those were the days. That was me in freshman typing class, only it was Doom. Only one computer had it, so I had to span it across multiple floppie...

They're serial ports. If your laptop doesn't have serial ports (and it probably doesn't), you can either buy a USB<->serial adapter, which may or may not work (more than likely not), or you could form some sort of bridge between one of the COM ports and something else. I can't really give any advice...

... I don't really like the general attitude and impatience of people towards ambitious projects like these. Of course it's a difficult thing to write, of course you need experienced coders and a good design, but if you just take it slowly you can get there eventually. You can't express the success...

Like on the other four forums you posted to, I'll say that there's nothing wrong with Joe's ionRandom routine, and you don't want to read from a random port in register C in the second routine, which could throw off the link assist, USB counter and 0Axh ports, and who knows what else. How far along ...

The interrupt starts at 0038h, very low on page 0. If you put the stack pointer at something like 0FFCDh (like Ben says), and then you write a zero over the upper byte, you've changed it to 00CDh, which is deep into the interrupt. It's just blind luck that you can jump to a spot where the cursor hoo...

Basically, he's swapping the same RAM page into both of the last two banks, and pointing SP to near where OP1 is (which is possible because of port 5). Then he's jumping to a part in CheckOSValidated which will read a byte (always a zero) to OP1, which will corrupt the stack and throw you down into ...