There's also Portable Python, and I cx_freezed (cx_froze?) a copy of binpac8x 1.0 a while ago, which should work without a Python interpreter installed.

Meh, going to put BinPac8x back in there will be painful, considering I have it working now anyways (actually, now that I remember correctly, I'm not using annoying but brass to output the 8xp binary, so I cut out the separate linker entirely)

somehow I think there was an issue with its linker, I can't remember exactly what, that prompted me to make binpac8x. Hopefully it works well for you or that I'm misremembering.

Well, it seems to work for now at least; if anything breaks, I'll be sure to post about and then somehow get python.

Well, finished 80% of my homework for the weekend, might as well go play around with this some more and post results within the next hour

...or just use the stock compile.bat script with the two options that Tari showed you. Cool, I look quite forward to this promised progress, but don't get frustrated if z80 doesn't go as fast as you anticipated.

Well, things are going smooth right now I went back through ASM in 28 days to refresh myself of all the instructions and different tricks, since the last time I wrote any serious z80 code was early last spring, and even then I wasn't very proficient. Feel like I know it better than ever before!

With that being said, I got all string based stuff, buffering input, blinking cursor, etc. all working pretty much normally now, and I gave this a name: "DoorBell CLI", play on words of "Doors CS7"

Some progress Typing routines done up to the letter 'H' (I mean, I really just have to fill in values, but I'm lazy and it'll take like 15 minutes out of my life -- I'll do it tomorrow ) and fixed stack errors (did I mention that I spent 3 hours trying to figure out why after 3 characters input into the console, this thing crashed? After stepping through in a debugger, I realized that I pushed af one time too much in the DrawString routine )

Hotness! I'd suggest wrapping a DSC Large Window around it for S&G, but that's not necessary at all.

Probably not a bad Idea to tell the truth I'll see if I can get that added in the next few minutes and load another screenshot.

EDIT: actually no I won't seems as though the GUI stack uses SafeRAM locations I need, and it makes it have a GUI feel when it shouldn't. Good idea though, maybe I'll try it later once higher-priority stuff is done, and see how it looks.

I was actually thinking of using OpenGUIStack, PushGUIStack, RenderGUI, CloseGUIStack, and then continuing with the rest of your program, which would give you the interface without any SafeRAM locations being used. As I said, though, it's up to you.

Oh, I didn't know you could do it all in one shot -- maybe I'll try it out

You certainly can! One thing I don't recommend you use is the deprecated LargeWindow call, as I might remove it one day for general uselessness.

Does it happen to mess with interrupts at all? If not, I'll implement it right now.

The GUIstack does some manipulation of interrupts, but on in the MouseHook, if I remember correctly. I don't see anything that you should be using interrupts for anyway, though...?

I actually use it to do things like delayed tab completion check, event handling keypresses, keeping track of the blinking cursor, etc.

If it affects the "usual" jump table, I could perhaps call that all up for the window first, then overwrite 168 of the bytes on the table to correspond to my interrupt.

The way I was envisioning, as part of your setup you could just use the GUI API to throw the large window onto the screen, then get the rest of your code and interface going and not have to worry about it. Doors CS's rectangle-drawing routines could help with "clearing" the window for scrolling and such. But regardless, I'm getting you distracted with a fairly trivial aspect of the interface, for what I apologize.