That's more or less everything. This falls under your one-byte load, although it's slightly more complex:


Code:


Part of the reason that there's only four main types is the simplicity of the microprocessor's internal architecture, and what exactly occurs when you execute an instruction.

I've finally finished the autosave, it saves before quitting, before starting a new file, and before opening a new file. If you quit before saving, it'll bring up the save window just in case.Here an intertwined image of ProgPad paired with DocDE...



Tell me what you think...

Very nicely done, Anakclusmos! Now the hard part, adding your assembling. Besides the actual mechanism of turning text into opcodes, have you figured out how you'll create the programs yet? IE, one pass to figure out size, createprotprog, second pass to write contents, or what?

Yes, like I said before there will only be one pass.I'm using a new direct method where any forms of data are searched for as they are being parsed.This way, since I don't need to store label values and whatnot, people can create larger documents and compile from the archive to a program as large as what can fit in the RAM.

Ah, that's most excellent. Well, keep us posted; what's the first piece that you're going to work on now?

Well, I already have a routine to parse the usable lines out of a multiline text, so really I have to figure out the hard part first, the instr commands...

I think I might add that chartable now.What large is the SmallWindow DCS creates?I need to make an image that fits.

Here's dimension diagrams of the small window:



EDIT: Here's a LargeWindow too:

Old Post:

Code:


New post:
The only bug in the GUI part comes from the FileOpen/Save/SaveAs error I told you about.The cool thing with my routine is that I can use it in a table comparison to parse Basic commands like this...

Table:
.db "sum(7,*,*,*)",0
.dw PushBasicStack
.db "ClrHome",0
.dw ClearBasicHome
...

Can you store Basic commands to an appvar and call the _ParseInp command to run them, or am I off?

Nice one, Anak, aalthough I really don't appreciate the constant nagging on SAX. You could certainly put the BASIC code in an AppVar and _ParseInp it, except that the parserhook wouldn't be active. A better alternative would be to make a temporary program and use Doors CS's RunProg entrypoint, which for some baffling reason I failed to document (it's at $4131). The most BASIC thing you need is just the first byte of the program's VAT entry in HL, and you should also have its name in Op1. Doors CS will do all its normal convenicen things, including starting the Parser Hook if necessary.

I guess i forgot to explain I was needing this for one of my other projects not using DoorsCS.I was considering using my routine to make a Basic parser in my shell.I thought it would be easier to just parser with own routine after finding the data rather using a parser hook.

I think I'm still a tad confused about this. You want to use the Doors CS libraries without Doors CS itself? Or you just want a general method of running programs?

A general method, nothing to do with DoorsCS.

Not to further complicate things, but could you give me an explanation of how the memory swap DoorsCS uses is supposed to work?

Relatively simple, and not too differently then most other shells do memory swapping. You basically just need to copy from RAM to $9d95 in (sizeof(Your_SafeRAM_Area))-sized chunks for RAM programs, or from ROM to $9d95 all in one shot for archived programs, then do the same thing in reverse for RAM programs (or just delete the area for archived programs unless you need to do writeback).

didnt you say something about DCS using some weird method to allow the running of larger sized programs?

No, it can only run programs up to the size of free RAM. Therefore, if you archive everything and have 23K of RAM free, you can run programs that are up to about 23K in size (less 200 or so bytes for GUI overhead).

I heard from the contest explanation that TI-83+'s can't run code after $C000 (or something like that), does this same restriction apply to running code say, in ROM since RAM starts at $8000?I'd like to see if you could copy a flash page and run that way and run in ROM, which would completely demolish the size restriction.

Just a suggestion, but might it be possible to use the _CopyFlashPage bcall to write back to the DCS appvar to save yourself some hassle?

You can execute anywhere in $0000 to $7FFF (ie, any ROM page that can be mapped in). You can only execute in the first RAM page slot ($8000 to $BFFF), but not in the second slot ($C000 to $FFFF).

How would that be an improvement over my current method?

*bump*

Anak, just so you know, the FileOpen and FileSaveAs now do what you suggested as far as limiting the files that they display when their input a=0.