*fistbump*
Code: Page 0 is 15610 bytes long (774 bytes to spare)
Page 1 is 15931 bytes long (453 bytes to spare)
Page 2 is 16034 bytes long (350 bytes to spare)
Page 0 had 376 bytes to spare, so this complex change, at the cost of plenty of effort and almost no clock cycles, saved just shy of 400 bytes on Page 0! Go team! Now, if I moved the 430-byte SortAlph.asm from Page 0 to Page 1, that would leave 1204 bytes on Page 0, 23 bytes on Page 1, and 350 bytes on Page 2, or 303/23/350 after adding CALCnet2.2. I think it behooves me to try to do a few more (more minor) optimization passes, especially on Page 1.
That's great news, Kerm! I'm very excited for this.
There, twenty minutes of examination and I saved 10 bytes in guimouse.asm, so now I'll have 33 bytes free on Page 1.
Thanks for the enthusiasm, Merth and Souvik.
*bump* Huzzah, it's in! Here's the final results below; it's a tight squeeze, but it's all put together. Now I just need to test it by pulling CALCnet2.2 out of NetPong and seeing if it works under DCS.
Code: -Page 0----------------------
> Page 0: vectors.asm is 1133 bytes long
> Page 0: ionlibsp0.inc is 614 bytes long
> Page 0: dcslibsp.inc is 1181 bytes long
> Page 0: fonts.inc is 1107 bytes long
> Page 0: basicprg.inc is 425 bytes long
> Page 0: detecttype.inc is 600 bytes long
> Page 0: vatfind.asm is 534 bytes long
> Page 0: runprog.asm is 2176 bytes long
> Page 0: progchain.asm is 224 bytes long
> Page 0: calcnet22.asm is 916 bytes long
> Page 0: ap.asm is 244 bytes long
> Page 0: easteregg.asm is 590 bytes long
> Page 0: mouse_p0.asm is 640 bytes long
> Page 0: fldsv.asm is 480 bytes long
> Page 0: main.asm is 5106 bytes long
-Page 1----------------------
> Page 1: moslibs.asm is 1566 bytes long
> Page 1: ionlibsp1.inc is 495 bytes long
> Page 1: guitools.inc is 2636 bytes long
> Page 1: guimouse.asm is 4219 bytes long
> Page 1: mouse_p1.asm is 684 bytes long
> Page 1: startmenu.inc is 1297 bytes long
> Page 1: cedit.asm is 431 bytes long
> Page 1: apguis.asm is 1774 bytes long
> Page 1: propstring.asm is 115 bytes long
> Page 1: sortalph.inc is 430 bytes long
> Page 1: datap1.inc is 2668 bytes long
-Page 2----------------------
> Page 2: vectorsp3.asm is 24 bytes long
> Page 2: ionlibsp2.inc is 614 bytes long
> Page 2: parserhook.inc is 228 bytes long
> Page 2: c3_hook.asm is 987 bytes long
> Page 2: c3_std.asm is 1021 bytes long
> Page 2: c3_util.asm is 3481 bytes long
> Page 2: c3_xfn.asm is 2471 bytes long
> Page 2: c3_pfn.asm is 1628 bytes long
> Page 2: c3_cfn.asm is 2716 bytes long
> Page 2: dcsblibs.asm is 2855 bytes long
Page 0 is 16101 bytes long (283 bytes to spare)
Page 1 is 16318 bytes long (66 bytes to spare)
Page 2 is 16034 bytes long (350 bytes to spare)
[quote]
Code: ...
Page 0: easteregg.asm is 590 bytes long
...
Has anyone found that yet? I mean, outside of what I just found?
comicIDIOT wrote:
Code: ...
Page 0: easteregg.asm is 590 bytes long
...
Has anyone found that yet? I mean, outside of what I just found? Only SilverShadow so far, and only then because I told him how to find it.
I know about the easter egg too and how to trigger it.
Is there any particular reason you've drawn the graphs inverted, Kerm? Open collector (or open drain) I/O pins are relatively common, as are active-low inputs, and I've never seen them drawn this way (compare with the 1-Wire, I²C or RS-232 specifications, for example).
benryves wrote:
Is there any particular reason you've drawn the graphs inverted, Kerm? Open collector (or open drain) I/O pins are relatively common, as are active-low inputs, and I've never seen them drawn this way (compare with the 1-Wire, I²C or RS-232 specifications, for example).
No particular reason other than for the sake of putting logical 1 above logical 0, since I was planning to word the description in terms of logical rather than electrical values. Do you find that extremely incongruous? If so, I'd be happy to flip and re-word.
It seems a little unusual. Do I take it then that transmitted bits are inverted as well? (So a 1 bit appears on the bus as 0V?)
Edit: I guess it does; it may be worth making that clearer in the bit level protocol documentation. (Or maybe my reading comprehension isn't too good).
Out of interest, was there an advantage to inverting the signal?
benryves wrote:
It seems a little unusual. Do I take it then that transmitted bits are inverted as well? (So a 1 bit appears on the bus as 0V?)
Edit: I guess it does; it may be worth making that clearer in the bit level protocol documentation. (Or maybe my reading comprehension isn't too good).
Out of interest, was there an advantage to inverting the signal?
Actually, I invert the byte before it's sent, so logical 1s become electrical highs. On the receiving end, I or the bit directly into the receiving byte, as per the annoying vagaries of link port reading and writing.
Ah, OK, that's sensible. The need to invert before writing is a fairly conventional "problem" due to the nature of open collector outputs, so I personally think it would be easier to follow if you documented the protocol in terms of the electrical levels. Terms like "holding/pulling the clock line low" and "releasing the data line" tend to be used.
(Of course, this is all my personal opinion).
benryves wrote:
Ah, OK, that's sensible. The need to invert before writing is a fairly conventional "problem" due to the nature of open collector outputs, so I personally think it would be easier to follow if you documented the protocol in terms of the electrical levels. Terms like "holding/pulling the clock line low" and "releasing the data line" tend to be used.
(Of course, this is all my personal opinion).
It should be fairly straightforward to rewrite the description and images in those terms, and I think that you have presented more than sufficient arguments for me to do so, so I shall.
*bumpity-bump* I reworded the descriptions and flipped the images as per Ben's suggestion. I removed the in-image titles (one of which is wrong, as you can see in the first post of this topic), added captions, and started writing the section about how to use CALCnet in your programs. Would you guys like me to post a rough draft of the current PDF in this topic, or wait until it's closer to completion?
Rough draft would be good, and then we can read through it and see if there's anything that is unclear.
merthsoft wrote:
Rough draft would be good, and then we can read through it and see if there's anything that is unclear.
As requested, here's what I have so far; please excuse all the blank sections:
http://www.cemetech.net/projects/techreports/tech004_calcnet22.pdf
KermMartian wrote:
I just uploaded the latest version with all my work from today. Merth, I've almost finished the work I need to do on it to explain everything that you need to know.
*bump* Draft completed! 14 pages of CALCnet2.2 bliss in my humble opinion. Please read and enjoy and proofread, if possible:
http://www.cemetech.net/projects/techreports/tech004_calcnet22.pdf
page 1: "GUI developed by calculators by the author"
Also, feel free to list me as Thomas "elfprince13" Dickerson in the acknowledgments.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum