No props to Kerm for coming up with the hardware design for you?  Anyway, I made my own version based on the design I gave you, pix below, program video coming in a few minutes.  I of course wrote my program in pure z80 ASM.

I need to work through getting SourceCoder to be able to post here (it's an SMF board), so here's a topic for it.  Please excuse any excess posts I accidentally generate.

http://sc.cemetech.net/?xpi=2327410ffd0737bf86b18515107bf4c6

Thanks schoolhacker, I've been trying to reproduce it, but it's hard to trigger a Garbage Collect on a calc with 1.5MB of ROM.

So I *finally* figured out a nice reliable way to handle the Stop token.  After much thinking and experimentation, I added a section of code to the BASIC parser hook used for Celtic/XLib interception that specifically watches for the Stop token.  Because that token causes Doors CS to never regain control (only from Homerun! The App can regain control when run from the Apps menu), it normally crashes the calculator.  Therefore, I bjump into the system error handler context with a=%01111111, effectively triggering the nonexistent error number 127.  The OS helpfully cleans up all the running programs and hands over command to Doors CS' error handler, which deals with deleting and cleaning up remaining items, then recognizes this special error and silently quits without reporting it.  Just to be on the safe side, I use this as one of the cases to bjump(_JForceCmd) from the Homerun Parser Hook, the other being when a program was edited because of a Goto event after execution.  When Celtic III / XLib compatibility is disabled, however, it simply uses a much much smaller Parser Hook during BASIC program execution that just looks for Stop, and does all the same things.  Huzzah!

Quote from: KermMartian on June 06, 2010, 10:02:01 pm

Quote from: Deep Thought on June 06, 2010, 09:14:35 pm

Wow, that is definitely worth two flash pages. Can't wait.

When's it coming out?

If you check out my signature, on or before September 1, 2010.   And yes, it's actually three pages.  Doors CS 5 was one page, Doors CS 6 added a page for all kinds of GUI subsystem stuff, hooks, and such, and Doors CS 7 adds another page for about 12KB of Celtic / XLib libraries.

Sorry, didn't see that.

That's still worth it, though.

And DCS8: another page for Axe-style parsing?

EDIT: Wow, three smilies in three quote zones.

EDIT2: What does CS stand for, anyway?

It's CS for Calculator Shell.  Back in the days of v1.0 and v2.0, which were laughable BASIC shells, I called it Doors XP instead of Doors CS.

You know, it is actually possible to make an Axe interpreter, but it would necessarily be so much slower than if it were compiled.

Love the update by the way.

Just so you know, only the period followed by a capital letter/theta is an axe header, I think you mentioned something about allowing other symbols to show up as source.

Well, I figured that the only kinds of programs that would start with '.' that are not Axe source would be starting with a decimal, ie, .0..... through .9.... Therefore, if the first character of the program is ',' and the second is not in the set of [0,9], inclusive, I assume that it's an Axe source file.  I could make it specifically look for A-Z and theta, but that would take more space, as theta is not contiguous in the token table with A-Z.

That would be nice, altough I would recommend that it's not implemented until Axe is finished, in case changes are done to Axe syntax itself. It could be nice, though, altough as Quigibo said, it would be much slower. Think for example of BBC Basic speed.

I would certainly at least wait until Axe is finished.  Perhaps I could figure out a way to call into the Axe application to compile and run the program on-the-fly? I think this would/will be a discussion for Doors CS 8, though.

In case anyone is an Axe fan, a simple 90-byte-ish addition that lets Doors CS (1) identify Axe source code (2) edit said code instead of trying to execute this.  The left screenshot shows it identifying code, while the right screenshot demonstrates a variety of execution scenarios, including DCS and Homerun, archived and RAM, locked and unlocked.

*bump*

Doors CS 6.5 Beta is the first DCS7 beta to contain one of the biggest feature additions to Doors CS 7, alongside Homerun, Folder Backup, and Runprog Chaining: built-in support for XLib / Celtic III / PicArc / Omnicalc compatibility.  Building off Iambian's generous donation of the Celtic III code base, this version of Doors CS adds many improvements, bug fixes, and optimizations to that code base.  In addition, it provides many core Doors CS bug fixes and optimizations, including repair of a graphics glitch with FileOpen/FileSaveAs, fixes for malfunctions when copying and renaming programs, repair of an issue where deleting the DCS7 appvar without a RAM reset could cause duplicate folders to be created, and many more.

You guys have been invaluable in providing feedback and comments.  As always, testing, bug reports, suggestions, and comments are solicited and welcomed.  I would particularly appreciate if authors of XLib and Celtic programs would try out their programs and let me know of any issues, including whether Doors CS properly handles incorrect syntax or arguments to Celtic III and XLib functions.  Please take note of the known and fixed XLib / Celtic III compatiblity issues and the usual To-Do list.

Download
Doors CS 6.5 Beta

You mean Real(1), right? Real(2) is the tilemapping command

Nice to hear, though

My error, thanks for that.

I'm trying to plow through these bugs, and I have to say, I think that XLib has it wrong in the case of Metroid II Expansion, the screenshot we were discussing last night.  Here's the command that draws the lava:
real(1,0,8P-8,12,71-8P,2,0,8,3,0,0

For P=7, for example, top-left is (0,48), width=12[bytes], height=15.  48+15=63, so the last row of the display shouldn't be drawn from that command.  The remaining stuff is take it from Pic2 starting at (0,8), don't flip it, don't update LCD.