HyperXDB On the Web
patching HyperCard to make it faster and stacks smaller
| DSoftware | |
| Yahoo HyperCard Group | |
| Inside Mac | A must |
| Hard to find G5 specs (and comparisons) | |
| CHASM really interesting. take a look if you've haven't seen it. the guy who developed it wants you to (he thanked me for putting creysoft on the board - if you call this crappy project a board) Also: Sphere oohhhohohhhhhh...... let's see what this button does... |
4/27
If you could tell, a risky backup copy of the project (including a whole version of HyperXDB - not a patcher) was uploaded... it wasn't supposed to be available that way.
My externals are better than certain (or all) Rinaldi externals. they are very compact (tiny), fine tuned, and powerful for their size. Even some utilities and code fail to meet the performances they can give..... well, for 680x0 code. 68K programs can run on MacOS X using a newer port of Basilisk II through emulation.
4/21
Because it takes work to actually get anything available over the internet (and I'm an idiot that can't manage a project because I'm a beginner when it comes to CVS)... I won't say anything more. Expect a new patcher, etc., soon.
4/18
Things are moving slowly, but eventually 1.7 will be finished. A large number of older externals have been obsoleted, so the HC Compatibility stack will now come with a back-ward compatibility tester. It will point you to scripts that use the obsoleted externals.
I have recently developed a text editor, using an XFCN adapted from the source code from the TinyEdit XCMD in the Double-XX LITE stack (came with CompileIt!). I'm developing an assembler with it. XWindoids offer much more than text fields. I'm hoping I can develop a text editor (from scratch), that can edit more than 32K, so you don't even need to run another program to edit text files... just HyperXDB. All of this will be freeware.
3/23
Writing code for a spin-off!
12/6
Small progress has been made. I'm trying to fix the SetHandleSize bug in an external...
5/6
'Updated the DResources stack. An update for the patcher is pending (too many instances of the "Debugger" trap. I must fix those externals, and get rid of the Debugging residue left over.
5/1
I've uploaded the last HyperCard patcher for HyperXDB (updated yesterday), and DResources (from February)... I'd recommend waiting until I the more updated version of the DResources stack, if I were you... you've been warned.
4/27
Exactly three months into the future... in order for this project to continue, whatsoever, I will have to rewrite the whole program. Because of the heap bug in HyperCard 2.4 (and 2.3 - I think), I will have to start from scratch by writing my own version of HyperCard, packaged HyperXDB (the small improvements would be built-in). Over the countless clones, I will become another, faster, more compatible one --- or what would supposed to be!
1/27
It’s official (I think), the name has been changed to HyperXDB, from... old name... Dumbit.
Boy, was that humiliating.
I might detach from HyperCard one of these days because of a number of problems it has. It gradually slows down over time (you must restart in order to bring back the speed), due to a continuous expansion of blocks in the heap. Even debugging with MacsBug can be hell, when it comes to testing out new externals. Each instruction in disassembly takes almost a third of a second...
Maybe if I helped CHASM... I could distribute something better... who knows.
Things are going so far, so developed, so out of control.
Still writing in in machine code. A number of externals have been obsoleted, and some can be used for other functions. Destructive ones were taken out or renamed.
I've decided my compiler, and even an Operating System will be done with my project - yes, I'm a nutbag. Once I get 1.7 done, there will be this whole DB genre... or a piece of coal (or somethin' brown) in my stalking- easter basket - whatever.
If you're nice, I'll give you a peek by E-mail.
The new optimized file system externals written in hex, the sDrawPort XCMD is unimaginably fast compared to the CompileIt! version. Not meant to make CompileIt! look bad; CompileIt! is far better than pascal when it comes to externals. Combined it with the ColorGWorld XFCN, and you can draw directly to the offscreen port -- NO MORE BLACK & WHITE GRAPHICS IN HYPERTALK!!!!!! Another major breakthrough, after being able to execute inline code. Yet, almost no one is listening.... seems like a waste to start my own Yahoo Group, since there are too many HyperCard groups.
A new resource format, and info. of the new language, based on C, with sample code, will be put up soon.
I'm re-writing pretty much everything (even the "Flash" XCMD), to make everything faster and less memory hungry. I am not, however, going to change any of the HyperCard CODE, for Copyright reasons. A "patcher" is enough of a risk of getting sued.
From an E-mail in late 2003: > > C is easier. I might try to develop a new hybrid > > language based on C, that's also self- > > programmable (you can translate other languages > > using preprocessing directives). > Now *THAT* would be *AWESOME.* 'Mostly what C left out in what it was supposed to accomplish; putting common instructions on multiple platforms into a single computer language: C. They left out bit rotation, the certain pre-processed commands were limited to just a few, like define's, and include's. So I'll develop the language myself to make sure that no other language after it is needed to be built. I'm not sure what I'll call it. I was thinking of "bare", as of, "bare" structures -- without the brackets, so it becomes sort of a, cross between assembly, C, and HyperTalk. It'll be so complex that you can create the entire language using preprocessing directives. For now, I'll stick to my HyperCard project in writing the program as a stack to generate REAL 68k opcodes, and a new resource-fork format to go with it. I wasted my life using the method, I did (to learn 68k opcodes). Basically reading ResEdit disassembly, and modifying code to get the results, until I researched some documentation and got THINK C. THINK C is a must-have for low-level 68k writers. 68k code is one of the easiest, by my understanding -- especially when the byte order is in the Right order, when it comes to numbers, unlike the Intel chips. Fortunatly, the PowerPC processor used in modern PowerMacs does both endians. On a re-write of one of my externals, I used the fastest method of parsing -- maybe faster than any other external in existance. The HyperCard developers used certain techniques to accomplish speeds with the hell of the language it was written in; the[y] wrote it in Pascal, judging on the bulky code, and constant stack usage. Judging by looking at the data fork [of the stack format], it appears to be some kind of WAD format, with the size of the chunk and a tag, starting with "STAK" as the main, and starting, chunk, and ending with "TAIL", with a special line (not in English). If I had the full format, then I'd be able to add objects manually, and be able to translate stacks into other customizable formats.