My Ender 5 Plus came with a nice starter roll of white PLA to get the new 3D printist started, but for all the projects I had in mind I knew this would not be enough. Perusing the interwebs, I found a company called Xyltech, who offers an assortment of 11-pound rolls at a cost lower than buying the equivalent amount of traditional small rolls. This is great, right? Problem solved! Ehh... not so fast.
While the cost problem may have been resolved, the where-the-frosted-kitten-nuts-do-I-put-this-huge-thing problem was decidedly in full force. So where does one put a roll so big that it won't physically fit on the printer's built-in holder? One makes their own spool holder, of course!
6/3/2021 - How not to 3D print or, How I Learned to Stop Worrying and Love the Blue Silk PLA.
Shortly after I began my
//2021 - Quote of the day.
"It helps to be young to make breakthroughs because you don't know what's impossible."
- Bill Atkinson
11/28/2021 - "IT FREAKIN WORKS!"
It seems one of my 68000 Freerun Testers made it to a certain basement in Oregon! I have to give a shoutout to Adrian for taking the time to showcase the tester. Thank you!
While it was great to see one of my projects hit the big time, as it were, many folks pointed out that this original prototype has no current limiting resistors on the Address Bus between the CPU and LEDs. This design choice was made for a few reasons, namely:
The majority of the CPUs I tested prior to throwing together the schematic put out current low enough that resistors weren't, strictly speaking, necessary
This was a first revision board
Since the unit is not designed for extended burn-in testing, it's unlikely that any issues would crop up in the brief amount of time the tester would be running
So, while this is a known issue of sorts, the exposure the tester has received has inspired me to begin planning Revision B, which will address this and some of the unit's other shortcomings. One major hurdle, however, is the $50+ price tag attached to each (that's right, each ) of the ZIF sockets used in the design. As soon as I can find a more economic alternative, I can begin the new layout in earnest.
On a side note: A few folks expressed interest in obtaining materials related to the tester, such as unpopulated Revision A boards and schematics. Fear not! I will soon be creating a section for schematics on the Downloads page, and also providing a way to purchase leftover parts from my projects, the Mercury Store.
Wait, a store? This website is getting a store??
Yep. But... not in the traditional sense.
Instead of implementing some kind of storefront software - and paying the associated fee, overkill for a small-time niche market like this - I've decided to write my own code. The finished store page will showcase spare parts and materials I have left over from my various projects, and users will be able to submit their "shopping cart" contents as an order via email when they're finished. Work on it has already begun, and it should hopefully go live by the end of the year. Just in time for Christmas!
11/11/2021 - Quote of the day.
"één keer meten is weten, twee keer meten is zeker weten" "Measure once and you know, measure twice and you know for sure."
- Maarten Vermeulen, quoting a Netherlands proverb
10/11/2021 - A new blog feature!
Today, while tidying up the code which runs this blog, I found myself having to refresh the page multiple times over the course of my edits, and each time I needed to select the same tag once again. Then, I got an idea. "Wouldn't it be nice," I said to myself, "if the blog remembered the tag I was viewing across reloads so I don't have to keep selecting it every time?" And, since this was a good idea, I then said, "Yes, myself, I agree. Let's do it!" And so, it was done!
Now, every time you select a tag, the blog makes use of the Local Storage offered by all modern browsers to remember the tag you were on, and it will be selected automatically once again after you reload the page! Also, some other elements have been changed to better conform to established web standards, such as using the HTML 5 data- prefix for custom tag attributes, and relying more on CSS as opposed to directly setting style attributes on elements themselves.
//2021 - Quote of the day.
"It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat."
- Theodore Roosevelt, from his speech "Citizenship In A Republic" delivered in Paris on 23 April, 1910
10/1/2021 - New blog enhancements!
9/23/2021 - A guided tour of a project from 2017: the 68000 Freerun Tester.
Back when I was sourcing CPUs for the EPiC project, I decided I needed a way to verify they were all in good working order. Since the 68K can "free-run", I could wire up a breadboard to test the chips, but having to throw together a bunch of parts every time I needed to test would get old fast, and keeping a breadboard aside for this purpose would be too unstable of a solution since breadboards aren't exactly known for their integrity. No, I needed a test unit into which I could easily throw a CPU and see whether or not I had indeed cooked its goose.
The unit I ended up designing features a pair of oscillators (12 MHz and 16 MHz) coupled to a built-in frequency divider to facilitate testing at a range of clock speeds, and external clocks are supported via the mini coax connector. The tester utilizes a ZIF socket for quick swapping of chips without wear, can be powered by any basic ATX power supply (I use a Pico PSU), and has an array of LEDs to display the processor's activity during test. The accompanying adapter allows testing of smaller 1.78 mm pitch CPUs, as opposed to the standard 2.54 mm pitch.
Normal behavior of 68000 CPUs under test. Despite arriving horribly scratched, the larger CPU seems to work just fine! The smaller one consumes much less power than its larger counterpart, causing the LEDs to stay lit even after turning the unit off - the CPU is semi-functional merely from the residual power in the capacitors!
A brief rundown of the tester's main parts:
Address Bus LEDs
Increment in binary as the CPU executes. After an entire cycle through the Address Bus, any LED which did not illuminate at all can indicate a dead Address Bus line on the CPU.
Display the values of the FC lines of the 68000 CPU, which are used to notify external hardware of the type of access being performed on the address bus, e.g. supervisor/user code/data.
Activates the Halt line of the CPU, suspending all function. Upon release, the Address Bus LEDs resume counting from the state in which they were prior to Halt being asserted.
Resets the CPU to its initial state. After release, the Address Bus LEDs once again begin counting upwards from zero.
Frequency Select Switches
Allow the CPU to be driven at a variety of frequencies ranging from 750 kHz to 16 MHz. The 68000 supports changing its input clock on the fly while Halt is asserted. Note: Avoid turning more than one switch to the On position at once.
So cool! Now I have a tester for all my 68000 CPUs! Well... kinda. Not so fast. There are a few tweaks which need to be made for the future Revision B board:
Correct the labels for FC0 and FC2; they are currently transposed.
Install current-limiting resistors on all the LEDs. In cases of catastrophic CPU failure such as a severe short, full current could be passed directly through the processor to the LEDs, damaging them.
Replace the switch bank with a rotary switch to prevent multiple clocks from colliding in the event of two switches being set to the On position simultaneously in error.
USB power is sufficient; the ATX connector could be eliminated.
Revision B of this tester will incorporate these changes, feature additional adapters to allow testing of other members of the 68000 family, and will likely be smaller as well. One more thing added to my stack o' projects!
8/30/2021 - Quote of the day.
"Sometimes a little ignorance can be very motivating."
- Bill Atkinson
8/17/2021 - "It's not an addiction. I CAN STOP COLLECTING EMOJIS ANY TIME I WANT TO!"
American State Flags:
Canadian Territory Flags:
8/3/2021 - A LAVA update!
Well, it's been nearly a month since I mentioned a possible demo of LAVA's abilities, and I'm happy to say I do indeed have a demo! Ok, so it doesn't do much (yet) but I don't exactly have tons of free time these days. Or any days, for that matter. But before we get started, let's cover the basics of what LAVA is - and isn't.
LAVA is a small TSR written completely in assembly language which provides basic pixmap functionality to xDOS (MS-DOS, FreeDOS, et. al.) applications on the x86 platform. In addition, it will also provide a collection of very fast pixmap manipulation routines including blitting, rotozooming, shape drawing, color conversion, and more. LAVA does not handle any disk I/O - that can be done by other add-on applications at a later date. LAVA does not handle any UI elements - that will be the responsibility of a separate UI manager, which I will be working on after LAVA is functional at a basic level. Much like the ephemeral Zen-O-Matic, LAVA doesn't slice, dice, chop, or peel, but it does allow developers to give their applications the speed and power of assembly language graphics routines without being forced to spend the time and effort learning x86 assembly language or add a ton of extra code to their application, and that's a major strength which will only get better with time.
But alright, enough talk. You're here for a demo. So, to quote Adrian Black, without further ado, let's get right to it!
Okay, so what exactly are we seeing here? First, the user types LAVA to run the TSR. It lets us know it's already resident, because it's friendly like that (lol) and so we proceed to the next step - running LT, the LAVA Tester application, which is written in Watcom C. This program fills the screen with the colorful red, green, and blue bands seen next. Observe that these bands take a looong time to draw; that's because that they're drawn right to the VESA frame buffer one at a time in a pair of nested loops which repeatedly call LAVA's direct pixel writing code over and over again. After this, pressing a key will prompt the screen transfer routine to kick in and quickly blit an off-screen pixmap from XMS to the display, resulting in the pattern of dots seen after. Again, observe the speed at which this happens - nearly instantaneously! This is the power of LAVA in action - the ability to double-buffer graphics and rapidly update the screen at will. One more key press, and the normal DOS text mode is restored and LT gives us some stats about what occurred during execution. It's off to a good start!
"But wait," I hear you saying, "doesn't VESA already have built-in double-buffering?" Well, yes and no. The VESA VBE does offer the ability to redefine the width of the display so that it extends past the physical number of pixels shown on the screen, allowing a programmer to set a screen mode for twice the regular width with half hidden at any given time. This can be used as a double buffer by writing to the half of the screen which is hidden then rapidly swapping the two halves for seamless animation. However, there are caveats to this approach, the main one being that the newly widened screen mode is still obligated to keep all its pixels in video memory which can, depending how far the screen is widened, strain the limits of the video card's RAM - especially in the case of many older models. The approach used by LAVA is more flexible in that the extra off-screen pixmaps reside in extended memory instead of video memory, allowing for nice, roomy screen buffers for sprites, objects, and backgrounds. And, since most blits occur directly between pixmaps and the transfers are handled at top speed by the XMS driver itself, applications no longer need concern themselves with the small 64 KiB windows allotted by the VESA BIOS.
Right now this demo doesn't show off much of what LAVA will be able to do in the future, but now that these basics are in place, the real work can begin. My next steps will be to set up code to handle blitting between pixmaps and to add some shape drawing routines so that the next demo will be more graphical.
7/13/2021 - What manner of memory madness is this??
So there I was, coding my own business, when all outta the blue there was this wild memory error!
Okay, okay, maybe error is a bit of an overstatement. It was more of an inconsistency. A small one, but an annoying one nonetheless. I compiled the most recent version of LAVA, loaded it resident, then ran MEM /d to check its memory usage.
1,360 Kb - not bad! Thats... *does some quick math* 55 paragraphs, exactly as requested!
So all is well, then, eh? The TSR loads, it just barely sips memory, great stuff! Well, not quite. Because of this:
That's the correct interrupt vector... and yep, that's definitely LAVA's code. Hmm...
So, didja catch that? The interrupt handler is in segment 0x084A, but MEM reports the resident program section begins at segment 0x0849. Why the difference? Ok, so let's dump segment 0x0849 and see what's there.
Oh, ok. It's the MCB.
Ok, makes sense. DOS needs an MCB to track what memory is used by what programs, so it appearing right before the normal PSP (shown at 0849:0010 in this screenshot) is logical. Ok, so let's do another sanity check. Adding 55 paragraphs to segment 0x0849 would be 0849:550, giving my TSR everything up to 0849:54F to play with. Let's see what's around there, just for fun.
Well, that's not good.
At the end of LAVA's resident memory space I temporarily placed the string "endmarker!!!!!!!" to make sure it's plainly visible. As you can see here, the last two exclamation points extend past the 0x054F address we determined was safe for LAVA to use. So what gives?? Is this a bug in my code? Nope, I ran it through with the debugger a few times, just to be sure. A bug in FreeDOS, then? Perhaps, but doubtful. But just for kicks, let's load up an MS-DOS machine and see what happens there.
Left: Output of the MS-DOS MEM command. Right: Output of the FreeDOS MEM command.
Both of these particular screenshots were obtained on the same MS-DOS 6.22 virtual machine.
Interesting! The MS-DOS MEM command shows LAVA as using a different amount of RAM... exactly one extra paragraph, in fact. I think we just found the issue! Apparently there's a bug (or feature?) in the FreeDOS version of MEM which does not count the extra memory used by the MCB at the beginning of the block... but yet it does show the memory block as starting at the MCB instead of at the block itself which is located immediately after the MCB. For a moment I was wondering if it wasn't the MEM command, but maybe the kernel itself which was mis-reporting the amount of memory in use by programs, but I ruled this out by examining the MCB directly on both the FreeDOS and MS-DOS systems; both MCBs showed the block itself being 55 paragraphs long - exactly as LAVA requested, and enough to hold the resident portion. It's possible the FreeDOS folks intended the MEM command to function this way - perhaps the memory occupied by MCBs is accounted for elsewhere in the program - but on the surface, it appears to be an inconsistency.
7/10/2021 - New tools, the fruit of new projects.
In the process of creating LAVA, I found it necessary to have a dump of all VESA-related data from the video card of a given system. Yes, there are a couple utilities which come to mind and that already do this job, but none were well suited for my need of complete information in a long, flowing, report style. So, as is my custom, I made my own.
ListVESA, much like ListPCI before it, is a utility which performs a deep-dive of the screen modes supported by your system's video card. Upon running, it spits out so much data that it's best to redirect its output to a file for later browsing, but you'll then have access to all data for every single screen mode supported by the VESA implementation of your video card. If you'd like to study the code or take it for a spin on your own DOS system, you can find it in the DOS section of the Downloads page. Now, back to making more LAVA!
As I mentioned last time, I've got some ideas in the works for a few DOS applications. And since they will all be GUI apps - and therefore share a bunch of core code - I was considering making some kind of shared library architecture available on the platform to cope with this. However, some folks pointed out that all the basic functionality of a shared library could be implemented in the form of multiple TSRs; this is the path with which I've decided to go, despite initially trying to avoid the TSR-upon-TSR approach.
That decided, the day after releasing ListPCI, I put some thought into what resident applications would need created to make this happen. At this point, I've settled upon two: a "video helper" to provide a collection of commonly used graphics functions, and a "UI manager" to provide a consistent GUI across all my applications. And due to the inherently graphical nature of a Graphical User Interface, the video helper TSR will need to be finished first. It will function akin to a DOS version of QuickDraw, and will provide services such as pixmap creation/manipulation, shape drawing, text scaling, and much more, all using the high-resolution VESA screen modes offered by pretty much every video card sold since the '90s. I've already begun work on this component, dubbed "LAVA", and already it can load itself resident, service basic interrupt requests (a simple installation check is the most notable thing that's functional), and unload itself as well.
Speaking of unloading a TSR, many of you are undoubtedly aware of the technicalities of doing so under any DOS environment. Say you have a handful of TSRs - we'll call them A, B, and C, loaded in that order - which all hook the same interrupt, and you wish to unload B. One may think unloading it is as simple as making it remove itself from memory and restoring the interrupt vector to point back to whatever part of memory it pointed to at launch. This, however, would be a Bad Thing because another TSR, C, was loaded after B, meaning the chain of command will break if B simply restores the vector to point directly to A when it exits because then C will be left floating in memory with no way to be accessed. So what's an application to do?
Most TSRs get around this issue by giving the user a quick "Sorry, can't do that." message and refusing to unload themselves unless they were the most recent one loaded, in which case the user would need to unload C first, then unload B, then reload C once again. What a pain! Now imagine the trouble for users who have several TSRs in the chain instead of just three. Hopefully you remember the order in which you loaded them! If not, you'll need to go back through your system files to determine their load order so that you can reverse it. Or you could simply reboot the machine and completely interrupt your workflow. For someone playing a video game this may not be that bad of an option, but it's not so trivial for someone maintaining a DOS file server with expected levels of uptime. Both these solutions suck, and I believe we can do better - and indeed my code does, even at this early stage. In such a situation, you get a helpful message:
Ah! User friendliness abounds!
LAVA tells you the exact location from where the current top-level TSR was loaded; by simply running LAVA after another TSR is removed you'll be kindly pointed to the next one standing in your way, greatly easing the burden of unloading them all.
Ok now, back to Earth. In reality, is this a common situation? Of course not. But unlikely does not equal impossible, and if just one user finds themselves in these circumstances, I'm sure they'll appreciate LAVA going the extra mile.
Now that the basic loading/unloading mechanics of the TSR itself are complete, next I'm focusing on porting in code to the actual video services offered. Granted, this will have a longer development cycle than my previous endeavor, ListPCI, but hopefully within a month I can cobble together a small demo to illustrate its abilities. Stay tuned!
7/1/2021 - Everything old is new again.
I recently had a small chunk of time open up in my daily schedule which, after deliberation, I have decided to devote to bringing to life some ideas I've had on the back burner regarding bringing to regular DOS some features of the still-in-development Night Kernel. These include a mechanism to enable better driver loading and a few applications, among which will be a picture viewer/converter as mentioned on the FreeeDOS development wishlist, incidentally something which I've wanted to make for a long time now before I even realized it was on their wishlist. But more on that program later; we have other things to discuss.
Today, after approximately a whole three evenings in development, I give you ListPCI, a tool which scans the PCI bus of the system on which its running and displays data on all PCI devices it finds.
But it doesn't stop there! ListPCI is also versatile: using command line options, you may filter the devices it reports to only those of a specified vendor ID or of a specified class. It can also return the number of matching devices in the DOS system variable ERRORLEVEL, making it easy to integrate into batch scripts... such as the FreeOS installer itself. *hint hint*
"But wait!" I can hear you exclaiming now. "Aren't there already DOS apps that do that?" Well, yes. However, of those which I've come across, none were as verbose as ListPCI in their vendor and device descriptions, nor were they as flexible in their command line options. So has this been done before? Sure. Has it been done this way? I say nope. And at less than 53 kilobytes (UPX is miraculous, no?) it packs a lot of info into a small package.
Sample output from within a FreeDOS VirtualBox machine.
While I'm familiar with the C language, I've never been in a position to write an entire original application in it, so creating this program was a fun exercise for me; I both checked one idea off my list and learned the ins and outs of a very cool development tool- Watcom C. I'm already looking forward to using it in tackling my next idea!
5/30/2021 - Some more blog tweaks!
5/28/2021 - For your consideration...
For a long time now, I've been considering making a few key apps for the FreeDOS project. Among them would be an image processor like GIMP or Paint.NET, a disk tool like Gnome Disks, and a file manager. The drawback, however, was that doing these things involves a bunch of redundant code, especially with them all being GUI-based programs. If only DOS had a way of providing common code modules across multiple applications! That got me thinking... there ought to be a specification for that. And since there's not, I wrote up a short paper describing one possible method for doing so via TSR in hopes it will garner some feedback. Although it is a work in progress, feel free to check it out!
5/25/2021 - Oops
It looks like several of the most recent blog posts had the wrong date attached. Doh! It's not last year. (Though I kinda wish it were! lol)
The issue has been fixed!
4/5/2021 - Then and now: A HandPower comparison.
As previously promised, I give you the Handpower specs! This table gives a quick look at how the project's current specs compare to how it was designed to be back in the day. Also, try not to laugh too hard at some of the old design goals, like how I thought I would fit 16 SRAM chips into a palm-sized device. The original specs were thrown together very haphazardly and, since the project was canceled so quickly, they never got a final "smooth out". The refresh, though, should be fairly on point.
Up / Down butons, side-mounted (used to scroll among various options, pressing both simultaneously selects the option)
Write-protect slide switch for hardware-level protection from updating ROM, rear-mounted (possibly under battery door)
Possibly: Directional buttons, front-facing
Of course these specs are subject to change as always, but this is how the plan stands right now. And I can already hear the question; That's all cool, but why a 68K and not an ARM or RISC-V or something... modern? There's a long and a short answer to that. The short answer: because I have literally an entire bin of 68K processors in my parts collection and I gotta use them all somewhere! The long answer is yes, a shiny new Cortex-A34 would be an absolute phenom, but the whole point of this is to be a bit retro, although I do plan to eventually modernize the CPU in the future to something unencumbered by other companies' ISA IP (so nothing by ARM) or hampered by convoluted versioning (oops, looks like RISC-V is out)... maybe it'll be the 68HG000!
Although I do already have the CPU and most other components necessary for this endeavor, before any electronics work gets started in earnest I'll be making some mock-up case designs and will of course post them here. Knowing how large the device will be and its layout will help me decide where some of the components will be located (and if they will all actually fit!) and is a crucial first step. The aesthetic of the end product will roughly be part Palm Pilot, part GameBoy Color and a smattering of smart phone, with the overall look-and-feel brought up to modern design standards.
The following is a list of passwords for all existing levels in the game XiZhu for the Casio Pocket Viewer. Actually, that's a bit of a misstatement; there technically are more levels in the game, however it contains an algorithm which successively reduces the time allowed for each level in sequence to increase the difficulty, and it unfortunately has no lower limit. This means that by the time you complete level 40, the next level actually starts with zero seconds on the clock - an instant game over! It's a shame that what I can only conclude is an oversight was left in the shipping version of the game, because it's a fun little gem. Though it is nice to see that, much like Super Mario Brothers for the NES, XiZhu also includes a Minus World.
3/30/2021 - I did say, "more on that later..."
If you were to partake in one of the several guided tours I've given of my currently half-finished lab - into which I've coerced family, friends, and the occasional unsuspecting small animal - you'd notice that I have a small collection of old technology I've used over the years. While these devices were all the rage back in the day, they sadly reached the limit of their usefulness to me at the time and, instead of selling them or even tossing them in the trash (the horror!), they were squirreled away in hopes of further utility at a later date. And for one certain device, that day has come. But first, some background.
It was the early 2000's, and yours truly was in the employ of a large retailer who had a considerable electronics section. As one of the resident employee nerds, I was responsible for keeping said electronics area stocked and in order. During the course of that task, I often found myself having to memorize multiple item numbers for printing signage, looking up inventory and shipments for customers, and for other ancillary reasons. Then, one fine day, a sleek pocket-sized computer walked into our inventory. I didn't think much of it at first beyond a paltry "Oh, that's cool, I guess." until I had the chance to actually use one. And oddly enough, I forget how this occurred. Perhaps my store got one back as a return? Maybe it was a damaged container and I tested it out prior to us sealing it back up? I couldn't say. But suddenly I realized the power of this unit to drastically simplify my work life. The thoughts came to my brain swifter than lips to Steve Jobs' butt: with this, no longer would I have to remember item numbers! Or memorize key points in meetings! This was liberating! Nay, revolutionary!
Mind you, I was no stranger to digital organizers - I practically grew up with them. No, really. Some kids had imaginary friends; I had a Seiko personal organizer. Followed by another. Then by a Casio Digital Diary which, incidentally, I believe I still have somewhere here in storage. Wait, what? Why didn't I just write stuff down? Oh, please. A nerd like me? With a pen? And PAPER? No. Just no. The era of me carrying around a notebook had ended years prior to this, and there was no going back. Seriously. In my early years, I actually did carry a small notebook everywhere. Why, you ask? What data could possibly be so crucial that a child would need to carry a notebook everywhere? The answer to that, dear reader, is simple. Code. Good old computer code. That's right, I spent sufficient time writing code (BASIC was my language of choice back then) that I found it beneficial to carry a notebook everywhere so that no programming breakthrough I thought up would be forgotten. Besides, in the era of jet-setting executives with their car phones, laptop computers, and wireless pagers (Yes, pagers. The 90's hadn't faded quite that fast just yet.) what geek wouldn't wanna be that guy with a PDA? And this... this unit was different from the rest - its touchscreen meant no more laborious typing on those tiny keyboards with which I was all too familiar, and of which I was all too tired. This was pure direct-input bliss. I decided I had to pick up one of these units immediately. And if I could do it sooner, I'd appreciate it.
Indeed, I bought myself a shiny new Casio PV-S400 Plus shortly after. The handy little unit uses the V30MZ CPU (an x86 clone) by NEC, and has 4 MiB of RAM, an RS-232 port (albeit with a proprietary connector, but I don't really see how it could be otherwise given the form factor of the device) and a 160 pixel square dot matrix LCD. The unit shipped with a variety of applications, including XiZhu, a game vaguely reminiscent of Mahjong, which I used to play for hours, earnestly trying to match tiles in the specific order, although, truth be told, I never really got beyond the first handful of levels. The device served me well through many tasks over a number of years before finally being retired as I inevitably moved on to my first smart phone - a Palm Treo. Yes, I still have that, too.
And that pretty much brings us to present day where, after long being disillusioned with smart phones as a whole, I recalled fond memories of my old Pocket Viewer and thus set out to bring it back into active service. After a quick rummage in the storage bins - and a fresh pair of batteries - something amazing happened:
Just look at that turn of the century engineering!
Ah, the nostalgia! Once again I'm enjoying the convenience of jotting down handwritten notes (nowadays there's even a handwriting recognition package available ) and gaming with my old favorites. But this all got me thinking... what ever happened to the PDA? I mean, yes, smart phones basically replaced them, and that's all well and good. But since everyone and his brother in this modern era realizes the huge, gaping security hole that is the typical smart phone, why isn't there still a niche market for the PDA? I think there is.
I have gone on at length here in the past about the EPiC homebrew computer, but I've never mentioned what was once to be the original EPiC - the HandPower PDA. This idea predated EPiC by several years, but I abandoned it once smart phones became cheap, capable, and ubiquitous. Now, however, I believe this would make quite an interesting project, and result in a durable and compact unit to function as the hacker's friend, the worker's companion, and the everyman's tool. In an upcoming post, I'll list the specs of the ephemeral unit as it was originally slated, then compare that to the refreshed version, the course of which I will be charting over the next several days. Stay tuned!
3/27/2021 - I don't always come up with great CAD models the first time. (But when I do... )
Many of my 3D printing projects have gone through several iterations prior to them being just right, and my most recent was no exception. Here's a peek behind the curtain at a preliminary design I had for the wire spool.
Ew. Just ew.
As you can probably imagine, this design was a fail. Why? In testing, I found that the lack of structural rigidity in the connecting slot where the wheel meets the spindle made merely a small twist sufficient to crack off one of the two raised guides forming the slot in which the spindle was to rest. This weakness led me to go with the better and final design with four walls, as well as thickening the entire center connecting assembly to better withstand outward rotational force. The final design, therefore, is unsurprisingly much stronger than the first version.
Stay modeling, my friends.
3/25/2021 - Another 3D printing project.
In the time that's passed since my November post, I've been (among other things... but more on that later! ) cleaning up some scrap parts that came across my path thanks to one of my Dremel tools up and dying.
Side note: the Robert Bosch Company, owner of the Dremel brand, is one of the few companies left which you can call up and order replacement parts and actually have them sent instead of being told to go pound sand. Some other companies could take a lesson! Yeah, I'm looking at you, Cuisinart.
Anyway, I saved the wire which made up the dead motor which I replaced since I have a planned use for it as a possible antenna in another project (again... more on that later) and so I needed a convenient place to store feet upon countless feet of wire. If only I had a small spool upon which to wind it... oh, yeah! I have a 3D printer! You know where this is going.
The completed 3D model.
Left: Freshly-printed parts, pre-assembly. Right: The assembled product.
3/24/2021 - An oversight. Yep, those happen. lol
Regarding my last post, it seems I didn't add the video of the model's layers as they appear in Cura, my slicing software of choice. It's been revised now. Enjoy!
11/8/2020 - The first 3D printing project.
The first project I decided to tackle with my shiny new 3D printer is a simple one to get accustomed to the workflow. For a long time now, I've had an issue with a certain pipe in a certain remote dusty corner of my lab; the floor tile laid around it wasn't cut precisely, leaving a gap between pipe and tile. I've been wanting to fix this for quite a while, and decided a small plastic shroud of some sort would work perfectly but the project (along with many others) simply got pushed to the back burner since I didn't have a 3D printer at the time. But that changes now!
The initial problem.
The first issue at hand was to design the part model. This took some time and measuring with a digital caliper before I ever even sat down at my workstation, but once I had a rough idea of the shape I'd need the part to be and some appropriate dimensions, it was time to break out FreeCAD and get to work.
The finished part model in FreeCAD.
Now that I had a fully modeled object, it was time to run it through Cura, the slicing software which breaks the object up into layers which the printer can create individually, each atop the last, until the object is built.
The same model sliced into layers to be printed one-by-one.
I settled on a simple half-circle design, a pair of which would be snug enough to hug the pipe and large enough to hide the hole through which it runs. Both pieces of the pair can then be joined using cheap and readily-available #8-32 x 1/2" screws with accompanying nuts - the model's round hole accommodates the screw head, and the hexagonal one is designed to hold the nut in place for easier attachment. Then it was time to get printing.
The finished part, before and after webbing removal.
I'd say the finished part turned out pretty well for a first go! The model was printed in this orientation to both eliminate sagging of the overhangs which would exist at the screw and nut recesses if the part were to be printed flat, and to increase structural rigidity since FDM printed parts have higher strength when the force exerted on the layers - in this case the compression force of each screw/nut combo - runs perpendicular to them. After spending a couple minutes trimming off the stringing which occurred, the part was in its final form.
A quick look of how two of these identical printed parts fit together to make one whole finished ring.
The problem is solved!
One project down. Many, many more to go!
11/1/2020 - A new tool means new projects!
Although I've not yet mentioned them here, I have several projects which involve physical materials instead of just software. Naturally, these require the ability to design objects and then have them built or otherwise manufactured. At one point I was considering having a local machine shop make the parts I needed, but I found the price prohibitive for items which likely weren't going to be mass-produced. Once 3D printing hit the mainstream, however, my hope renewed; one could simply purchase a 3D printer and prototype all the parts they need! Perfect, right? Well... not so much. I quickly found the sheer number of options - and their associated price tags - quite daunting.
After some research, I pretty much narrowed it down to either the Lulzbot Taz Workhorse ($2,950 USD) due to it's larger-than-most build volume, or the Lulzbot Taz Pro ($4,950 USD) since it also has a large build volume and can also build parts with two colors of plastic at once, however the price tags on these two made me pretty much resign to the fact that I wouldn't be able to tackle my design projects for quite some time.
Fast-forward to present-day. Okay, more like last month. I find an online group for 3D printing enthusiasts, and I post a question: What's the cheapest large-format 3D printer available? More than one person mention the Creality Ender 3, a model of which I've never heard. I visit the manufacturer's website and, to my delight, I find they also make an even newer version - the Ender 5 Plus. It doesn't have the dual-color ability, but how often will I really need that anyway? For a sub-$600 machine, I can't complain, especially when it offers an auto leveling feature and dual Z-axis stepper motors. So I order it. It arrives. Giddiness ensues. Setup begins.
Since it's the only spot I currently have room for such a thing, I assembled the unit in an unfinished section of my lab:
The base before and after the corner support rails are attached.
The top gantry assembly, Z-axis screws, and heated bed bolted in.
Before and after wiring - and power on!
The first completed print - and just look at that precision! It's very telling that, in trying to get close enough to photograph the layer lines on the cube, I had to get so close to it that the grain of the cardboard box upon which it's sitting is also clearly visible.
My first test print was a calibration cube I found here. The print was prepared using Cura slicing software and printed using the Super Quality preset. The cube model itself measures 20 mm in each direction, and the cube output by my Ender 5 Plus measures 20.06 mm along the X axis, 20.09 mm along the Y axis, and 20.02 mm along the Z axis. Not being off by more than one tenth of a single millimeter in any given direction isn't bad at all, especially considering the price point of this machine. Crazy cool!
Now... what project shall I resurrect first?
7/27/2020 - A word on multitasking.
Gone are the days of needing a high-end Unix workstation to enjoy the pleasures of running multiple applications side-by-side; indeed, even smart watches now perform the feat. Nearly every digital device in our modern world is capable of multitasking, but there's a fine line between running a multitude of tasks simultaneously in high-performance fashion, and running a multitude of tasks simultaneously in such a high-performance fashion that the host system becomes nearly unresponsive.
Recently, I completed a round of stress-testing on the Night Kernel. The new soon-to-be-released version can dynamically spawn new copies of the Debug Menu using the F1 key, so I employed this ability to launch copy after copy after copy of it, ending up with a total of 255 tasks running at once before killing most of them once again. The result? Although it was completely stable through both adding and killing the extra 250ish tasks, it was still a total mess of lag, as one might expect from a plain round-robin scheduler.
So why does Night lag so badly when modern operating systems don't? The key difference is not in how many tasks are running, but in how they are switched. Right now, Night will perform a context switch even if a task has nothing logical to do; e.g. when a background task is waiting for input. This ends up pulling valuable CPU cycles away from the current foreground operation, and all for the newly-switched task to accomplish no meaningful work since it's in the background anyway and cannot accept input until it gains focus once again. Future tweaking of the Night scheduler will allow for this and prevent an application from being switched to if it's waiting for input and none exists, which should result in a massive speedup for all tasks involved.
7/15/2020 - An interesting comparison of various VPN services.
6/7/2020 - Quote of the day.
"Modern hardware has spoiled us and dulled our senses, so to speak ... you can't keep throwing gigs of RAM at every problem as if that's a valid solution."
- Rugxulo, FreeDOS-user mailinglist
5/10/2020 - A minor correction.
4/28/2020 - Quote of the day.
"Those who say it cannot be done should not interrupt the ones doing it."
4/26/2020 - A bit of a bug...
It seems the tag logic I added recently had a small bug - it matched against the entire text of blog entries instead of just the tags. It has since been fixed, and you may now continue in tag-clicking bliss.
4/25/2020 - An essay most interesting
This series of documents presents a fascinating look at what computers could become. Perhaps some of this can make it into whatever graphical shell runs atop Night.
4/17/2020 - FreeDOS contributions
Lately I've been working on bundling up some software for the FreeDOS project, and ran into compatibility issues with older unzip tools, even when using command examples from the official FreeDOS package site. The easiest way for me to pinpoint the issues I was experiencing was to create a cross reference of all the various packaging tools and see where their shortcomings lie to determine which would be the most compatible. And, behold! The result:
Zip tool used
Unzip tool used
7Zip 4.65 (DOS)
7Zip 16.02 (Linux)
InfoZip UnZip 6.00 (DOS)
InfoZip UnZip 6.00 (Linux)
PKUNZJR 2.04g (DOS)
PKUNZIP 1.1 (DOS)
PKUNZIP 2.04g (DOS)
7Zip 4.65 (DOS)
7Zip 16.02 (Linux)
ADVZIP 2.1 (DOS)
InfoZip 2.32 (DOS)
InfoZip 3.0 (Linux)
PKZIP 1.1 (DOS)
PKZIP 2.04g (DOS)
Y - Unzips perfectly
y - Unzips with line ending issues
N - Will not unzip
n - Unzipped some files but not all
From this we can determine that, since a "Y" is denoted as the best possible unzipping outcome, Linux Mint's native InfoZip 3.0 is the most compatible among the encoding methods. I had issues in the past with the plain ZIP command as listed here but that was likely because I was using version 2.3 under FreeDOS, which doesn't zip in such a way that either 7Zip or InfoZip 3.0 can unzip without running into line-ending errors. This led me to use the suggested 7za command, which led to problems for older zip tools. The newer InfoZip 3.0 turns out to be more compatible in this regard, so it shall by my packager of choice going forward.
3/25/2020 - More code at work.
3/11/2020 - My code at work. Literally.
Recently at work I was approached by management to tackle an ongoing problem they've had with crunching the tons of data generated daily in the course of certain business operations. Their need is to parse thousands of human-generated notes and catalog the basic intent of the note based upon certain groups of keywords. This issue was already brought up to the IT group, who I'm told promptly branded it impossible, in a feasibility sense, and since I have a bit of a coding reputation there, the issue was brought to me.
I found a handful of sites which break down various popular sorting algorithms visually to illustrate their principle of operation, but they lacked real-time timing information, making them useless for my purposes. So I did what I always do: I made my own.
The Sorting Algorithm Demo showcases the functions contained in Sorting.js, and allows several popular sorting algorithms sourced from a variety of places on the interwebs to compare their might against a randomly generated data set of whatever size the user desires. Running this on a data set of one million elements helped me pick the newest candidate for my sorting needs: the Quicksort algorithm with Hoare partitioning.
WE HAVE A WINNER!!
You may have noticed that Lomuto partitioning was actually the fastest listed here, and normally selecting the fastest contender in any race is the path to winning, right? But despite Hoare taking 8 milliseconds longer to sort this specific data set, overall it is consistently faster than Lomuto, which tends to vary a bit based on the data set presented. Both beat the pants off the Binary sort I'm currently using, which itself superseded the Bubble sort (don't laugh too loudly out there ) I initially used.
It's one thing to see your code fill whatever hobbyist gap you had at the time, but an entirely different thing to see it crunch real data in real world applications. Cool stuff!
3/9/2020 - About the recent downtime.
You may have noticed that everyone's favorite project site (that's this one ) was recently down for several hours yesterday. This occurred due to a switchover to a new hosting provider, and was minimized due to the excellent customer service of the new host.
The last time I switched hosts was a very time-consuming procedure, and I was anticipating a similar headache this time as well. Not so! Epik's awesome agents helped me get everything set up - via chat no less! - and spent a cumulative couple hours of their time making sure all was well. I really, really appreciate that.
It's not often you find this level of dedication in a large tech company, and I have to give credit where it is due. Thank you, Epik, for making what could have been a complicated process virtually painless. Kudos!
3/9/2020 - Blog condensing completed! (At least for now! )
As of today, I have finished retroediting the blog; it now includes all posts from the News section of my old Exelyx website, as well as all pertinent posts from the Warp OEM thread at AndroidForums and the EPiC thread at AnyCPU.
Will I add more? Do more even exist?
I guess you'll just have to stay with me on this ride to find out!
3/8/2020 - Quote of the day.
"The easiest way to distinguish a working engineer in industry from a hardware/software hacking hobbyist is by the clock. If it's after 5 PM, he's a hobbyist."
You may have noticed there is a lot more content on this blog now. Over the past three days I've retroactively added all the posts from the old Exelyx News section as well as a large number of development-related posts I made over at AndroidForums during making of the Warp OEM ROM. During the latter endeavor, I built a small collection of emojis scraped from the posts I (and others) made there. Below is said collection, mainly for my own future reference.
Edit: Here's some more from another forum!
3/4/2020 - Blog additions.
Since I have a shiny new blog, it's time to pack it full o' stuff! Over the coming weeks I'll be integrating updates I posted long ago at other locations; for example, much of the development progress I posted at AndroidForums during the making of WarpOEM and the now-ancient contents of the Exelyx News section. Why? I think it will be nice to have one central place where one can review the project-related posts I've made back through the years regardless of their age or original location.
3/3/2020 - Quote of the day.
"First, make it. Then make it better."
3/1/2020 - Quote of the day.
"The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague."
- Edsger Dijkstra
2/25/2020 - Something cool in the works.
This past week I've been working on copying the breadboard design off into KiCAD.
Progress on the EPiC sound board prototype.
There's still some work to go, but overall it's shaping up into a nice little prototype. It will be capable of playing 16-bit mono audio and will feature breakout connectors to interface it to a breadboard for further testing, much like the Freqbox project.
2/18/2020 - Lesson learned.
2/13/2020 - Volume issues and other miscalculations.
I finally received the new amplifier, replacing the previous OPA2277 and fired up the project. Would it push some major Watts? Perhaps blow out my speakers? Sadly, it did neither of those things. In fact, volume output seems to be on par with what it was before. But why? WHY? Well, I think I found the answer.
I mentioned before that the DAC8820 is a 16-bit part, and the EPROM to which I have it connected is an 8-bit one. Since there is no more than 8 bits worth of data entering into the DAC at any one time (and I have the EPROM wired to the lower 8 bits of the DAC's data bus) that theoretically limits the voltage output of the DAC to 1/256th of its possible output capacity. So my problem isn't poor amplification, it's inadequate use of the DAC!
I may end up making this audio experiment into a simple PCB to test its performance under better conditions and to be able to adequately test features such as full 16-bit samples, stereo placement and digital volume control using a MAX5161 or X9015.
2/7/2020 - You don't know DAC.
The original draft of EPiCs specs mentioned it was to have either dual SID chips or a custom audio controller. And since any great homebrew computer needs a great startup sound, I've decided to go with the latter - a set of parts capable of reproducing sound in sweet 16-bit stereo. No PSGs here, folks! Observe:
Roll that beautiful DAC footage!
So what are we seeing here? Allow me to expound. At left, you'll see my bench power supply - a PicoPSU. This connects into one of my earlier projects, the ATX to Breadboard adapter, which powers the rails of the breadboards shown. Getting to the breadboards themselves, the first component is a 6.144 MHz oscillator whose output is fed into a 74VHC4040 12-Stage Binary Counter to divide the 6.144 MHz down to some common audio frequencies: 192 kHz, 96 kHz, 48 kHz, 24 kHz, 12 kHz, etc. The 24 kHz output (since that's the frequency of the audio sample I'm using) is then sent to a bank of five SN74F161A 4-Bit Binary Counters which supply a 19-bit address to the M27C4001 EPROM holding an audio sample of up to 512KiB in size. The counters continually drive the EPROM to output a sequential stream of data to a DAC8820 which converts the digital data to sound. After the DAC, there's an OPA2277 High Precision Operational Amplifier (although it doesn't seem to do much and will soon be replaced by a TPA6211 amplifier) and finally, a standard headphone jack.
All that being said, why does it sound so bad? Don't get me wrong, it still blows away other homebrew computers with their simple beeps and bloops, but at the same time this setup isn't as good as it could be, and there's more than one reason for that:
1. In this demo configuration, the 8820 is vastly underutilized; the EPROM is an 8-bit part, and as such provides only half of the total 16-bits expected by the DAC.
2. For simplicity, I burned the EPROM with only an 8-bit mono sample.
3. I've not yet added a proper audio amplifier to drive a decent set of speakers. The impedance on these old Creatives happens to be low enough that they will play sound, but my modern higher-quality speakers refuse. The upcoming TPA6211 will hopefully change that.
4. Breadboards do not provide the most solid connection, leading to the high-frequency hiss which can be heard in the video.
The next step will be to swap to the new amp chip and see if I can then drive some normal speakers!
2/5/2020 - Hobbyist philosophy.
In the 1970s Steve Wozniak built a computer. Not in the modern sense, where one purchases a few off-the-shelf components and plugs them into a motherboard, but in the traditional sense; each component was individually selected and painstakingly soldered in place by hand to produce the final product. In Steve's case, this product would start a revolution. Later, Burrell Smith would build another computer. It, too, was created by carefully selecting discrete components and merging them together into a product which would change the world.
Why doesn't that happen anymore?
Are we not creative enough? Or do we perhaps simply lack the motivation given the constant stream of innovations leaving the doors of AMD and Intel? Sure, the homebrew scene is full of new machines, most cursed with no sound. No graphics. No life. There are some exceptions, but they are few and far between, and those which do step outside the norm usually do so by utilizing some obscure piece of period technology. On the other hand, EPiC is a throwback to a time when hobbyists created awesome devices with a few dozen parts and raw curiosity. The goal is one shared by the great computer designers of days gone by - create a powerful and easy to use computer from scratch using contemporary parts, to the enjoyment of fellow nerds everywhere.
With as many designs as exist out there, why build from scratch? Because I believe that only in wiping the slate clean can we slough off preconceived notions of what a homebrew should be and what it can achieve.
It has been said that if you always do what you've always done, you'll always have what you've always had. I want to expand all aspects of the typical computer system with my own unique touch, not simply rehash what's been done before.
This computer will be unique. This computer will be inspired. This computer will be EPiC.
2/3/2020 - How not to use counters.
So... yeah... remember that aforementioned 'other' problem with the Freqbox? That stemmed from an erroneous breadboard setup I did years ago at which time I observed that - since the counters are basically just a set of flip-flops chained together, each alternating at half the frequency of the one before it - tying the clock input to the most significant line of the previous counter is sufficient to make the counters... well... count. The only problem was that, while that's all well and good if all you need is to divide frequencies, viewing the output through a logic analyzer reveals this configuration is wholly inadequate for actual counting.
Considering the margin of error here increases exponentially for each successive stage of carry, no wonder the frequancy count is going way higher than it should! To fix this, I studied the datasheet and found that the ENP and ENT inputs control rollover to extend counting across multiple chips - however my finding the phrase 'The TC output is subject to decoding spikes due to internal race conditions and is therefore not recommended for use as a clock or asynchronous reset for flip-flops, counters or registers.' in a different datasheet seemed to indicate doing so was unreliable. Just for kicks, I tried connecting RCO (or TC, depending on which datasheet you read) to ENP (or CEP) and this actually worked flawlessly... for the first pair of counters only. Attempting to add a third produced a bunch of noise and unreliability at the end of each counting cycle.
Yeah, that's not right at all. So what do?
After a bit of Ducking, I found this article which described exactly the trouble I was having. It seems that the correct way to chain these counters is to feed RCO to ENT and keep ENP held high, which a quick breadboard rewire proved correct. Re-reading the original datasheet now, it does seem that configuration is what they were trying to convey by 'Both ENP and ENT must be high to count, and ENT is fed forward to enable RCO.', but for some reason I took 'fed forward' as a description of how the chip is configured internally. Oops.
2/2/2020 - Fun with Hot Air
Those of you who know the main project in which I'm involved are probably wondering why I haven't been working on it lately. The answer is simply that waaaaay back in (the year 2000?) 2018, I had a set of printed circuit boards made for the largest-scale (term used quite loosely) electronics project I've ever designed - the Freqbox. The only problem (or so I thought at the time) was that, to achieve the desired speeds, I had to go with surface-mount technology when selecting components. Why is that a problem? Your humble blogger (that's me! :D) had never soldered SMD parts before so, as far as I was concerned, SMD could quite literally SMD. I already hear you fine folks out there, too. 'But why did you design a board to use parts you didn't wanna mess with??' And that's an excellent question. It wasn't due to massive shortsightedness, but the fact that I had a fellow working with me at the time who was fairly proficient at soldering. My plan was to do what I had done before: design the schematic, have him use that to design the board layout, send the files off to the fab house and when my shiny new boards were delivered, have him do the soldering. Steps one through three went just fine, but upon getting them back he decided those pesky little SMD components were a little too fine pitch for even his experienced hand. The next year saw me file this project away, albeit with my intent to find someone else to solder it nestled safely in the back of my mind, before recently deciding to wrap up some projects which have been hanging around way too long. And here we are, at present day.
So what's an electronics newb to do when you can't find someone to do it and you can't do it yourself? Like many things in life, simply declare 'Pfffft! How hard could it be?' then get ready to learn. After all, videos like this made it look so easy. Really, how hard could it be? Well... on the other side of that learning, I've found the procedure itself is easy as can be: just set your hot air soldering station to 350°C and gently wave the nozzle back and forth across the pins. 'Huh? A hot air station?? You mean you have to buy something other than a soldering iron for this??' Yep. Well, if you want more easily achievable professional-looking results, that is. If you're daring, feel free to use a traditional soldering iron. That's more effort than I myself cared to put in, but hey, more power to you. Instead, I found that a good unit like the 852D+ can effortlessly shrink solder paster up into a nicely tinned joint. 'Wait, solder paste?' Yep, that's another thing you'll need. (I find the SRA syringes work best.) This is my roundabout way of bringing up the downside of this soldering method: buying new equipment. Don't get me wrong, it beats the pants off using an iron, but you do have to make the investment. Then again, like so many things in life, you get what you pay for.
But okay, enough storytelling. Time for some pictures!
The partially-assembled work. Little did I know what chaos was about to ensue...
I got about this far with my fancy new soldering technique (although I was using 500°C at the time... and somehow the parts miraculously survived!) when I decided, 'You know what? I should power this up before I go much further to see if all is well.' So I popped a 12 Volt power supply into the barrel jack, and flipped the switch. Within nanoseconds, I was greeted by a sharp pop accompanied by the acrid smell of burning electronics emanating from the four chips in the lower right corner. Upon closer inspection, I found that - whatever just happened - happened with enough punch to leave a scorched pit in the smooth plastic of the chip's carrier package. What could cause such a thing?? I dutifully checked the schematic...
Well, that's not good.
Can you see the problem there? Actually there's two, but the second one is a story for another time. See how the VCC lines and GND lines are all linked together on each chip? So far, so good. Now see where the VCC line ends up? And how about the GND? That's right, each one of the power connections for these chips are backwards. This was actually correct on the original schematic, however when it got rewritten as part of the PCB making process an error apparently crept in and nobody caught it. No wonder I had fried chips!
Let's try this again, shall we?
I omitted the chips in question and added a jumper to carry the oscillator output to its destination without the chips intervening - the frequency divider function isn't mission-critical at this stage. After that was done, the unit actually powered up (with no smoke, even!) and I was able to shift the display drivers into test mode using a debugging jumper wire to produce the results shown above. Allowing it to run normally, however, showed approximately 1.5 metric craptons™ of noise on the clock output line. Upon further investigation, however, I discovered it wasn't noise... there was yet another design flaw. I had assumed that the oscillators would not activate unless the enable pin is high. Sounds logical, right? Nope. A quick check of the datasheet revealed something I had managed to overlook: both the power and enable pins are internally linked, allowing the oscillator to function whether or not it's 'enabled' as long as it's getting power. Further testing uncovered that it can even partially power up from clock outputs from other oscillators back-feeding into its clock output pin! These errors led to utter cacophony as all the oscillators were essentially enabled at once. Simultaneously. On a shared clock line. (Yes, that's just as bad as it sounds.) I ended up clipping off the enable pin on each oscillator and then finally removing all but one altogether to reliably drive this prototype. Needless to say, I will be employing a much different method to power the oscillators of the next revision.
There's actually one other major problem, too. But we'll cover that next time!
Greetings! I'm Mercury Thirteen. Welcome to my blog! *Takes a bow.* I'm a coding and electronics hobbyist, Linux user, classic (pre-OS X era) Mac enthusiast, optimization freak, and occasional gamer. Feel free to kick back, look around, read some posts, and most of all enjoy your stay!
Protip: Click a tag on any post to filter by that tag!
I made the mistake of taking a vacation and ended up getting super behind on everything at work and at home. Just as I started to get a slight handle on things, my trusty old car finally retired so I had to go shopping for an upgrade. Soon as that was done, my girlfriend's car semi-retired as well. So shopping we went again! Now I've been drafted into a couple special projects at work and it seems that's all I've gotten done lately. I'm digging my way through the mess, though. Slowly, but surely.
I have a batch of parts sitting in my car waiting to go to my soldering and layout guy, I just haven't had the time to stop by the post office to send them. Can you believe that? Something so insignificant holding up progress! Well, it's not so much no time to go there, it's no time to wait in their long lines.
My problem is I have too many projects going on at once!
I recently got a new laptop which came with Windows 10 and decided Linux Mint would be better than that eyesore.
I liked it so much there that I swapped my desktop to it as well. I'm officially a Linux-only user!
A scary thought for me, but Mint has proven to be an excellent starting point for a Windows survivor like myself. Regardless, the migration has been occupying a lot of my time lately.
Today I got the Freerun Tester back from the assembler and fired it up. I'm happy to say it successfully tested out all the 68Ks I have lying around in both DIP and (with the adapter accessory) SDIP format. I also noticed no difference in heat output between under- and over-clocking the chips.
On a somewhat unrelated note, I got this ATX Adapter made as well. Now I can power my breadboard projects more effectively than wiring them up directly each time as I used to.
I've been sourcing 68000s from multiple places online, but it occurred to me I have no way to test them as they arrive, as I have no actual components to EPiC set up yet. To fix that, I needed a simple tester which could put the chips in "free run" mode.
The ideal tester would have a ZIF socket to allow you to painlessly swap multiple chips without wear and have a variety of clocks which would be selectable to test the chip's performance at varying speeds. An external clock connection would be helpful too, for future expansion. It would be able to be powered from a simple ATX power supply (since I have tons of those lying around and they do a great job of providing simple clean power at 3.3V, 5V and 12V) and would have an array of LEDs to show processor activity on the address bus, along with indicators for the FCx lines of the 68000.
In other words, something like this...
4/22/2017 - Hmm, it seems I got something in the mail...
...and with the components in place, awaiting soldering.
Ok, so this project is getting old. And, as is the case with many of my projects, I've bounced back and forth on the design specs at least a dozen times. This yearmonth week. So what am I going to do? Well, am I ever glad you asked...
As you all know, I originally wanted to go with the 68060, due to its technical advancement over the other chips in the 68K family. If I got a good mask revision (with appropriate sacrifices, of course, to the eBay gods) I could probably even push it up to, like, 100 MHz or so. Right? Yeah... turns out that magic mask revision is ever so hard to find. And trust me, I've looked - and priced - everywhere. I barely found one, let alone the several which I planned to make this project utilize in the end, so that approach is officially unfeasible. And finding enough to eventually make this a kit computer... forgeddabouddit.
During all this searching for 68060s, I came across the Apollo project and thought YES!! Thisis the future of the 68k line! This project shares the end goal of my own: the evolution of 68K computers! It wants to be what Motorola would likely have made after the 68060 if they hadn't "prematurely" killed it! All is kittens and rainbows once again! Right? Uh... nope. After some lurking on their forum, it seems that Apollo, for all the amazing achievements of Gunnar and pals, is destined to remain tied to the Amiga platform, with them going so far as to add the functionality of several Amiga support chips right into the FPGA. I inquired a little about making the chip available as a "stand alone" product already loaded onto an FPGA, and didn't get a super-enthusiastic response. Not to say that said response was unpleasant at all, I just didn't get the impression that my request was high on their priority list. And understandably so, with it being an Amiga-focused project. It's a great CPU to be sure, just not for this goal.
So what now? My only remaining option, really, is to do what the Apollo project has done for the 68060, but for the 68000 itself: create a completely tricked-out code-compatible soft core version. I could even bust the CPU wide open, theoretically, adding features guaranteed to give the original MACSS team a collective aneurysm, like 64 bit support, fast interrupt handling, multiprocessor intercommunication and SIMD abilities. And since I know most parts of the 68K way better than the '060 and (unlike the '060) resources are available for the parts that I don't, it may actually be feasible for me to eventually achieve my goal. As an added side-benefit, this approach would let me get started designing a system much more quickly based on a real 68000 CPU, then slowly upgrade it over time with FPGA tech as I learn it. So, "all" I have to do is learn FPGAs from the ground up and let the good times roll!
This all gives rise to my question: Do any of you here mess with them on a regular basis? Can you recommend a good starting point? I'm currently looking at the Justin Rajewski's Mojo or maybe a Mimas or Elbert dev board. Any advice?
The socket issue is finally resolved. Digi-Key told me the socket was built just as I ordered, so I went up the chain to Aries, who also said the socket is designed to be that way. When I asked for which processor the socket could ever possibly be intended, they simply noted that all of their processor footprints had been ordered and built before. I still wonder which CPU was ever made which happened to have a backwards footprint of a Motorola 68060, but no matter.
This is where the story takes a pleasant turn. Aries - unlike Digi-Key - took their time to correct the issue, remaking my socket into something I can now use at no charge - and even offered to fill the holes as well, which Digi-Key neglected to tell them. The representative I spoke with was (again, unlike Digi-Key) both polite and professional. Although, in the end the holes didn't get filled, I appreciate the excellent customer service offered by Aries. Kudos to you, folks!
08/30/2016 - Goodbye, Exelyx.
After essentially two decades in pre-release, this project is officially dead. Its final form, the Exelyx kernel, was authored in Watcom C and designed to run atop the CWSDPMI back-end. The completed components of the kernel formed a basic environment which probed the hardware available and structured its findings into a data table for applications to easily access. It also supported high resolution VESA graphics and included basic mouse support, but never reached much further into development due to complications encountered with sharing resources with the DPMI server at run time. When it became apparent that there was no efficient way to maximize performance in this manner, the decision was made to cancel the project. Although it may seem to have been a complete waste of resources, the time spent on the many internal iterations of this OS have provided valuable data from real-world field tests of feasible kernel builds which have helped immensely to determine what works well and what decidedly does not. This entire project can be seen as more of a proof of concept study: the goals to which it aspired were found to be appropriate - and the completed portions indeed functioned well - but the implementations of these features were not adequate. Despite this project's cancellation, however, all is not lost - no worries, we are far from finished. The lead programmer of PCOS/Exelyx has created a new kernel called "Night" which will incorporate features and techniques from Exelyx and recreate them in a "clean slate" Protected Mode environment with no DPMI, no background services... nothing. This kernel will be written completely from scratch in hand optimized Assembly using NASM and all testing will be done in VirtualBox throughout the development cycle. Just over a year into development, the Night kernel supports automatic high resolution video mode switching and basic hardware support for keyboards, three button wheel mice, the Programmable Interval Timer, Programmable Interrupt Controllers, etc. Future developments can be followed at the Night Kernel group and in the project's Git repository.
I have to say, I'm not too impressed with Digi-Key right now. They're trying to tell me that the socket they sent me is correct - the pins are laid out just as specified by the footprint. I don't think any other CPU in existence used a mirror image of the 68060's layout, so this has to be wrong.
Let the customer service battle begin
6/29/2016 - Okay, so the socket arrived today...
So far so good, right? Wait, it's a 19x19 grid instead of 18x18. Not cool... but ok, at least it's still usable, right?
Wait, really? How do you get that wrong??
I've got the ZIF socket arriving tomorrow, and I met with the board layout designer last week. He's made something super nice looking for a breakout card! I have to review the details of it (there's a couple weeks, given my schedule and get back to him to finalize, then it's off to the fab house for production. Once the breakout is assembled, I can start working on probing the behavioral details of the 68060.
6/17/2016 - Lookie what arrived!
Wow... long time no post, eh? Despite how it may seem (over a year with no posting?? Shame on me!) this project has not died yet.
So what have I been doing with the spare time I've had in the past year?
-Familiarized myself with PIC microcontrollers (and started work on a PIC PS/2 interface, should be done in the coming months)
-Read certain parts of the 68060 manual like a New York Times bestseller.
-Revised the specs yet again (and again, and...)
-Learned a little about 68060 bus timing (I may be able to make do with slower memory than I previously thought!)
-Sourced a relatively cheap '060! Now to wait not-so-patiently for delivery...
-Entered into talks with a local PCB manufacturer and their preferred design/layout person to start work on the breakout board
Hope everyone here is doing well!
Wow... it's been a long time since this ROM launched. I began typing this with intentions of officially retiring it, however (as always) I want to know what you guys think. Should I make one final update? Said update would consist of newer ad blocking, the latest app versions and maybe a couple minor graphical touch-ups, but nothing really substantial overall - just enough to hopefully prevent someone downloading it nowadays from having quite as massive an update storm upon first-run.
So... whatcha all think? Yay? Nay?
I'll wait awhile and see what happens here before proceeding. If everyone has moved on and nobody cares about this anymore, I'll close it and nobody need look back.
Ok... I think I answered my question with a little research and reading.
The EC model retains four registers needed to restrict access to regions of memory in 16 meg chunks. Good enough for me! I think I can work with that. On that note, the project is back to using the 68EC060. So far as clock speed, EPiC will support a variety of frequencies, all configurable on-the-fly.
I've been doing some more in-depth reading in the MC68060 manual, and learned a few interesting little tidbits. First, there is no such thing as an MC68060RC75 - the only 75MHz versions of this processor are the LC and EC models. So much for my previous post, eh? With this news, I'm once again up in the air about which CPU to go with. Some pros and cons:
68060: Complete version with MMU, FPU, everything you could possibly need.
68LC060: Fastest version made runs at 75MHz, but has successfully been run at 80 MHz with no issues.
68EC060: Fastest version made runs at 75MHz, but rumored to be even more easily overclocked without causing a thermal nightmare, making 100MHz within reach. Commonly available at very reasonable prices.
68060: Fastest version made runs at only 66MHz instead of 75.
68LC060: Harder to find and insanely expensive, around $650 per chip. No MMU may be an issue for protected memory.
68EC060: Again, no MMU.
Even though there is no MMU in the LC and EC, Appendix B of the manual states:
"Although the MC68EC060 has no paged MMU, the four TTRs (ITT0, ITT1, DTT0, and DTT1) and the default transparent translation (defined by certain bits in the TCR) operate normally and can still be used to assign cache modes and supervisor and write protection for given address ranges. All addresses can be mapped by the four TTRs and the default transparent translation."
Contrast that with the info found in section 4 regarding the MMU:
"The data transparent translation registers (DTTR0 and DTTR1) and instruction transparent translation registers (ITTR0 and ITTR1) are 32-bit registers that define blocks of logical address space that are untranslated by the MMU (the logical address is the physical address)."
I could care less about paging, but protected memory is still really high on my wish list. However, I don't see how these TTR registers can be used for memory protection when it seems all they do is control whether addresses are translated or not. What am I missing here?
I'm still doing some reading, so I may answer my own question eventually, but if there are any experienced Motorola guys following along, maybe one could point me in the right direction?
I've updated the project's design goals in the original post to eliminate the SD and MMC card slots (these can be added later via an add-on card or USB adapter), increased the ROM size and dropped the 68EC060RC75 in favor of the 68060RC75 to gain hardware-level memory protection.
4/14/2015 - Another little update to the project...
I learned that the entire PCxxx series of memory is set up to use a 64-bit data bus, so half the bandwidth would go unused without fancy memory controlling. Instead of PC100 or PC133, I'm considering moving to the 32-bit wide 72-pin SIMMs for the system RAM. Granted they're slower, but as was pointed out before, the 060 has a fairly sizable cache which should negate some of the penalty of going this route. Of course that entails using an additional CPLD programmed as a RAM controller, but that's a bridge to cross at a later date.
Nothing beats those lucid moments where just as you are about to throw your hands up in frustration, the project comes to life and the design aspect/feature/addition/baby step you've poured so many hours into snaps to life. Those moments make it all worthwhile.
As you've all undoubtedly noticed by now, my project is heavily influenced by the original Macintosh. In keeping with that fact, a never-ending source of motivation to me has been folklore.org. Reading the stories about how one of the greatest computers ever made came together and how the engineers' hard work and ingenuity paid off has been invaluable to me.
The moral of the story: don't lose hope! History has shown us that regardless of their training (or lack thereof) small groups - even individuals! - can work wondrous computing magic.
4/13/2015 - Just checking in.
I haven't forgotten about this project. Life has gotten a bit hectic, and it has become painfully obvious to me that I'll have to complete a couple of my software based projects before proceeding with this one, but I will return to this eventually. Since I was young, I've always wanted to code an operating system. At first, this was a simple DOS shell because that's all I knew at the time. Then, since I can never leave well enough alone when there's room for improvement, I decided to evolve it into a real 32-bit PC OS. Needless to say, this would be a major undertaking and - much as I hate to admit it - the likelihood of it catching on are about zero since we have Windows / Linux / MacOS out there these days. Even if the product did get made, it would have no beauty running on the ISA kludge which is the x86 processor. No, I think the 32 bit version needs to run on something sleek and efficient to produce a computer which - much like the original Macintosh - is a perfectly balanced mixture of software and hardware optimization. At least then I could say I achieved something. After all, nobody is going to remember a 32-bit homebrew OS in the already saturated PC market (which has mostly moved on to 64 bit code anyway), but a 32-bit homebrew OS running on all original hardware may make a memorable mark on the hobby scene.
As always, forgive my rambling. I'll return to this as soon as I can!
10/21/2014 - Halloween is nearly upon us...
...and we have some appropriately scary news. The PCOS project is no more! *GASP* What?? That's right, PCOS is officially gone. Well... in name only. As it turns out, there are a couple complications with using the "PCOS" name. It already was an operating system made in the early 1980s as well as the name of a current Linux distribution ("PC/OS") with neither of which this project needs to be confused. Since "PCOS" was always more or less a code name anyway (the finished product was never intended to actually be called "PCOS") we've changed the project's name to Exelyx - pronounced "Eck-sell-ix". Throughout this entire site and all documentation, we've attempted to update "PCOS" to "Exelyx" where appropriate, with notable exception of the screenshots. We have better things to do than go back and obtain updated versions of them. Besides, they can stand testament to the roots of the project, right?
8/5/2014 - Just to show I haven't been being lazy...
I must say, once you get accustomed to the style of Eagle, it's much easier to get work done! I'm liking this.
So here's the first revision of the dev board, in all it's Eagle goodness. I still need to flesh out the DUARTs, but the overall system structure is there. Anyone see any obvious mistakes I made? Feedback in general is appreciated!
7/16/2014 - There is such a thing as too slow...
It never occurred to me that this could even be a possibility. You can imagine my surprise when my new 10 mHz 68000 hung when I gave it a 1 kHz clock: all the address lines simultaneously gained in voltage until they reached logical high, then went low and stayed there. On 4 and 8 mHz, it runs fine.
Speaking of unsurprising, we-told-you-so announcements (lol) I had little positive progress while the site was down. I got a pair of EEPROMs burned containing a small assembly program which initializes the DUART then sits in a loop continually broadcasting a character repeatedly down the serial line. I wired up the components and threw the power. And of course, it didn't work. Applying my logic analyzer, I can see dozens of spurious pulses throughout what was otherwise a clean, perfectly synchronized address bus. Oh, interference! Why must you plague me so?
At this point I either buy a bunch of wirewrap equipment, redesign the breadboard using rigid wires and form them into straight runs similar to PCB traces or just move the whole thing to a PCB. I think I'm going with the latter. I searched a PCB design houses and - lo, and behold! - there's one right here in town! Talk about convenience! I've been using Fritzing to create a basic schematic which I'll post for you guys' review.
I did some work on two fronts today. First, the dev board is ready (in theory, at least) to accept it's first bit of test code! This will be a simple three or four lines of assembly I'll hammer out in the morning which will continuously output a character to the serial port so I can see if this thing is actually going to work.
Second, I did a bunch of research for the '060 board's timing system. Let me emphasize that. A BUNCH of research... literally most of my day was spent on this. I'm tired, it's now 4 AM... you get the idea.
Anyway, I searched through a TON of clock generating ICs on various sites. No dice. Either they don't run fast enough, or the voltage isn't right, or they're some funky kind of QFN, DFN or ZOMGBBQ packaging or, or, or...
Next, I tried oscillators. Again, no luck. Did you know they offer programmable oscillators? That's a new one to me.
Finally, after around five hours of searching, I found this (datasheet here) and I think my problems are solved. I can run this straight or through a variable divider to yield the desired clock rate. What do you all think?
For a direct pga-to-dip adapter, this is the reply I got:
"We can make just one, but the per unit cost to make 12 or more would be a lot cheaper if you have use for more. There is a fair bit of design time involved in a PGA to DIP adapter with that many pins, and it will require at least a 4 layer PCB, and a special surface mount PGA socket. For budgetary purposes, I would estimate a single adapter to cost around $1000, with 2-3 week lead time. If you needed 12 or more, the cost would be a lot less per unit, somewhere around $200."
Initially, I was thinking of the adapter having a male header on a small horizontal board at the bottom to directly plug into the breadboard, then having a vertical board mounted atop it to hold the processor, sort of like an inverted "T" shape. However, since this leads to a number of difficulties, I've narrowed it down to one of the two designs which I've attached below. I think adapter #2 will work better and lead to an easier breakout, but the first would be easier to tie into a project. What do you guys think?
68060 Adapter prototypes 1 and 2
I'm negotiating with a fab house for a quantity discount on a batch of 68060-to-breadboard adapters to facilitate the creation of low-speed prototypes using this chip. Would any of you here be interested in purchasing one? Once I've gauged the interest I can get a per-piece quote.
7/6/2014 - A small update.
As you can see from the attached picture, the dev board is starting to take shape. I've got the address decoder mounted and connected finally, so as soon as I get more wires - and a new CPU - I can once again proceed. The breadboard-mounted PS/2 ports came in and I got waveforms out of a keyboard using my logic analyzer, so I think I have a pretty good idea now of how I'm going to tie them into an additional 68681 to handle keyboard and mouse input. All the components are pretty much in place, until I add the parts necessary for onboard video.
Bad news... I shorted something out and fried my CPU. I noticed the address bus was dead and the chip was very hot, so I put it on its own separate breadboard and hooked nothing but power to it and once again the chip started burning up. More are on order, and things are on hold until they come in.
Okay, it's update time! My Saleae 16 channel logic analyzer came in as well as my bypass capacitors and ATX power adapter. I've finally got the dev board running off ATX power (no more cheap breadboard power supplies!) and the address bus is functional as expected. It seems when you feed the CPU directly off a PSU, the initial period of voltage instability messes things up for a bit. I'll have to implement a circuit which doesn't let power flow to the rest of the board until line 8 of the ATX PSU is high (the Power Good signal) to try to eliminate that. I do see a slight increase in stability after adding the bypass caps, and it's probably only a slight difference due to the fact that I can't get them very close to the CPU whilst on a breadboard - or at least whilst on the breadboards I own.
Next up: once my new batch of breadboard wires comes in, the address decoder goes in place.
I hooked a series of LEDs to the address bus and confirmed the processor is indeed running as it should! As soon as my ATX power supply breadboard adapter comes in, I'll power the board back up and post a pic or two.
6/21/2014 - It works! ...I think.
Well... it seems like the breadboard works thus far. I hooked everything up in open loop mode, grounding the data bus and holding the necessary signals in the appropriate manner, and fired up my makeshift power supply. On my meter (which is the best I can do until my shiny new Saleae arrives) I get the logic state alternating once every 8 seconds or so at 4 MHz at address line 23. Moving down to line 22 I get the same thing, but it alternates in roughly half the time as line 23. I move to line 22 and the trend continues until around about one third of the way down the bus when the slew rate gets too fast for the meter to pick up. So... it seems the address bus is counting as it should! Not bad for an afternoon.
Also, I was surprised I could get the thing to run (if it is in fact running! lol) at 4 MHz. I may still have to drop it down as the design gets more populated, but it works for now.
Warning: Some of you wire wrap guys will probably get a headache from looking at the attached picture... you've been warned! lol
The clock pulse generator arrived and - as you can see below - generates a nice simple stream of pulses. I measured it accurate to within a few thousandths of a MHz at 4 MHz. Not bad!
6/14/2014 - Small update
The EPROM programmer and eraser arrived today! I've tested my spare EPROMs and it performed multiple reads and writes just fine. The pair of DUARTs showed up a few days back.
I've sourced some more parts for the tester board project: a breadboard-compatible serial port, a dual voltage breadboard power supply, a tube of MAX232s to interface the serial port to the rest of the circuitry, a real time clock, a set of 3 27c4096 EPROMs (for only $1.29!) and a super-handy little clock pulse generator.
So far as the main project, I'm amazed I was actually able to find a place or two that still make the 206-pin ZIF sockets for the 68060!
More to come!
6/11/2014 - IT CAME!
Lookie what was on my desk when I got home today.
Has anyone noticed lag in WOEM, especially when running apps which need to run in the background?
12/22/2013 - Merry Christmas!!
So, it's Christmas time once again, and it's time for another update. There's been (yet) another major design change in the Exelyx kernel over the past months. We all know the history of this project has been less than mind-blowing. Its development has been stricken with a long series of starts and stops (more stops than starts) and has had its schedule slip repeatedly with no target release date in sight. Well, as the project nears its twentieth anniversary in 2015, it's time that all changed. We believe Exelyx still has the potential to fill an untapped niche in the low-end computer user base. Today there exists no viable option for users of older PCs to have a modern, elegant operating system which can breathe new life into their aging hardware as well as be a dependable, stable platform for everyday use. We also believe DOS is perfect for these users, but lacking the many features found in modern a desktop OS, its adoption will likely be slow and labored at best. There are several small GUI programs out there, however what they offer is just that - a GUI. When it comes to the demands of day-in and day-out use, they simply don't hold up. Sure, they may successfully put a friendly face on DOS and give folks something familiar to work with, but have they really changed anything? On the other hand, Exelyx was designed from the ground up to bridge this gap. It's not simply a GUI; it works on a fundamental level, interfacing with your PC's hardware to bring a user experience unrivaled by any simple DOS shell. Alas, to attempt perfection takes considerable time. At its heart, Exelyx has always been 16-bit. Talk was made of taking the platform to a true 32-bit base, but this was planned for later in the kernel's life cycle, and not as an introduction build. The main reason for this being the lack of a suitable DPMI server (and we tried several of them) and a good, solid tool set for the authoring of 32-bit code. After all, there's an awful lot you can do with 16 bits if you try. However, with our renewed focus on making this project ship, it became clear that we had no time to design a complete 16-bit kernel only to redesign it in a 32-bit flavor later on. Instead, it's time to do this once, do it right, and make this project happen. With that in mind, a few things are changing around here. You'll notice fewer regular updates here in the news section than usual when the project is under active development, but we're following what has been called the "open development model" for this project from this point on until it's completed. This gives you all the ability to follow along in real time with the evolution of the Exelyx kernel as we write it. This will be done via a Dropbox link which will contain all the code and resources we're using to do the job at hand. You'll be able to check the Dropbox folder and the accompanying development log at any given time to see exactly how things are going, and even submit bug fixes and features before the product is released. The Dropbox link is listed as the "Project Repository" on the home page. We're about to go down a long and winding road, but the end will be well worth it, friends. Well worth it. Now let's do this!
Okay, so since I can make the majority of the apps in my ROM easily uninstallable now, would you guys like to see Warp OEM once again come with a browser, music player and all that? Or are you all happy with the minimal app set it comes with?
I just realized something... Warp OEM turned 1 year old on the 4th!
Bring out the cake and light those candles! It's time to PAAAAAARRRRRRTYY!!!
Your homework assignment: Flash the original version, then the latest version just to see how far it's come in the past year.
It's that time again...
The new version of Warp OEM isn't groundbreaking, but does offer some nice amenities. You'll notice some slight theming on the loading spinners and text selection cursors, as well as all updated apps and ad-blocking, as usual. Under the hood, the Adreno tweaks have been integrated into the ROM as well as the ability to delete many of the included apps if you'd like, as they are no longer all loaded into /system by default. This means that I've finally broken my "don't touch /data" rule - the partition WILL get wiped now. This will not only make sure there's no wasted space when upgrading (as the partition gets wiped entirely, removing all traces of previous apps) but also will minimize any issues which may otherwise be noticed when dirty flashing.
So backup, backup, backup and enjoy!
In keeping with this theme, I have noticed there may be a bug in which the pre-built settings aren't applying. For example, right out of the box automatic brightness is supposed to be set and the option for non-market sources is supposed to be allowed also, but I don't think these things are happening in the latest build... I'll have to track this down.
06/02/2013 - What's this? A domain!
For the first time in Exelyx history, the project is being hosted under its own domain: www.mercurycoding.com. But then again, if you got here, there's a good chance you already knew that. Oh, well. It's still a tasty announcement :D
6/3/2013 - 'I'm also working on redesigning my existing website to contain all my projects, which will eliminate this kind of thing in the future. Stay tuned ' - Me, not long ago
On a loosely related note, I actually attempted to complete this recently and found my free hosting account unworthy. Okay, okay, more like not as full-featured as I'd like. Same difference lol
So I bought a domain name. And I'm in the middle of making this new project page come together. It will replace my Dropbox as the official download point for Warp OEM as well as any other ROMs and projects I make in the future and - since I now possess unlimited bandwidth ( YEAH!! ) it will eliminate embarrassing little issues like that Dropbox lock I had a few weeks back upon the release of WOEM 2.00. Sorry about that again, guys. *facepalm*
Check out the Warp OEM 2.51 to 2.53 Update patch! Now available in the download center
After an initial FC, Swipe-to-Clear is officially implemented and functioning on my dev unit!
It helps I guess if you copy the entire function body to the ROM... Android doesn't like only having half the story lol
Can't say that I blame it!
Development is rolling on, folks
Well, as you can see... WOEM now has working toggles! This is the typical LiDroid feature we're all familiar with here, with the exception that I removed the reboot and shutdown options since we already have those on the power menu - no need to duplicate things The title bar is removed as you can see, and the Notification Toggles option has been removed from the settings menu since the app-based version is removed.
Next up: swipe-to-clear!
You know what this means...
The first update of version 2.50... toggles are almost complete! I have some work to do on them, but almost all more or less function as intended. Now that the toggles are in place, it seems to me that the title bar of the ROM (the part that says "Warp OEM" when you pull down the menu) is taking up too much room, so I'm getting rid of it. This means the clear button is gone now too, but swipe-to-clear is getting implemented, so no worries
I'll keep you posted!
Warp OEM Version 2.50 is officially underway
Hey, guys I got an idea. Since everyone likes different apps for their music player, browser, etc., wouldn't it be better (in the interest of shrinking the ROM and minimizing now-I-have-to-remove-the-included-system-apps-I'll-never-use syndrome) to make the ROM without these things? No browser, no music player and the user loads their own. I don't think it's wise to remove all the apps, because there are several that are pretty well universally accepted for most of us (e.g. QuickPic, MXPlayer, etc.) so those could maybe stay. I don't know, this was just a thought. So how does this sit with you guys? Let me know
Okay... I know I've accomplished like ZIP on my ROM lately... but I haven't forgotten about you guys. Version 2.5 will be next, with the traditional toggles and swipe-to-clear as well. These two have been in the works for a while, but between working 14 hour days lately and having to replace my car, I've had no time to allocate to dev work. Here's hoping I can change that in the near future
Update time! I know it's been a while. Sorry!! But it's worth it.
Three cheers for jimsmith80! Thanks to him, WiFi tethering now works in Warp OEM!
There's also the usual updated apps (including Play Store 4.027!) and ad-blocking definitions too, along with a newly modified PowerNap (v2, available in the download section in the OP) script which doubles the low speed held during sleep to 245MHz to reduce on-wake lag. The only thing that didn't make it in is the new UI... figured I wouldn't make you guys wait that long. This edition still has One Browser, but I figured I'd give it another chance since they recently revamped almost everything about it. If you guys still hate it (lol) I'll swap it out later on for the poll winner, Boat.
Download link is in the OP. Have fun!
And as always, let me know if you have any issues!
Oh, and I've gotten permission from Guspeed to port his n00b themes to Warp OEM!
It's like Christmas all over again
4/18/2013 - PowerNap vs. SetCPU
Basically, PowerNap is a script to force your device to its lowest processor speed (this is the default, but it can be changed) when the screen shuts off, and restores the previous frequency upon screen-on. The same thing can be achieved with SetCPU (or any processor stepping app which supports power profiles) but this method entails adding an app and its various components (event listeners to detect when the screen goes off and on, an additional background-running task to actually do the work, etc.) into your system. PowerNap eliminates a lot of the overhead of this by instead using the already-existing init.d scripting function built into the Alien kernel to streamline execution. Think of it as a very specialized version of SetCPU running only one profile
Also - and I don't run SetCPU so I'm not sure - but I believe some apps of that ilk only support changing governors, not frequency. Again, I could be quite wrong there lol
Removing PowerNap on this or any other ROM is easy! Just use your root-enabled file browser to navigate to /system/ect/init.d2 and delete it from the folder. Done!
Just dropping in to say there's a new version in the works! I'm fed up with Angel, so expect a new browser and more UI refinements. Also, I found that many graphical elements don't retain their updated look when the ROM is run at alternate DPI settings, so there'll be a fix for that as well.
04/10/2013 - Progress update.
Development on the NextBASIC compiler has been slow due to a major lack of time and resources, but the project is still alive.
One other thing I thought of for you that were having SD card mounting problems! If I remember correctly, TWRP only works reliably with SDs formatted in Android.
I believe only Android itself has DOS/Windows/Linux filesystem drivers needed to mount these formats (FAT12, FAT16 or FAT32 for DOS, NTFS for Windows, or EXT3 or EXT4 for Linux/Android) TWRP (or CWM for that matter) does not.
Well, it's official... WOEM is formally released! In addition to removing the release candidate status from the current version, I also made a new minor update version (WOEM 2.01) including updated apps and hosts file
Okay... so it seems that everyone's pretty much having a good experience with this ROM, aside from the occasional known issues/installation method anomalies (clean install FTW! lol) so I think its time to finally release the final version
Would you guys agree?
For all you custom ROM devs who want to use the installer featured in Warp OEM... installer-script link in OP download center.
Bump for new OP goodies: a new flashable smoothness fix and instructions for devs on how to use PowerNap in a custom ROM.
Bump for OP updates: New version of App Pack and PowerNap script is now available separately.
So I just got back from a concert, walked in the door, and realized something. IT'S FRIDAY. Now, there was something I had to do today... something big. But what? Feed the dog? No, that can't be it. This is the twenty-first century, after all. They feed themselves, now, right? Right? Hmm... Milk the cows? ...no, I don't think I live on a farm yet... *looks out window* Nope, still not a farm... Hmm... What could it be? OH YEAH! It's ROM day! So, without grand flowing words or any other form of ado, I bring you:
BUT... before you all go flashing, remember to backup! This is only a release candidate, and there are a few known issues which I'm about to update in the OP.
So have fun and let me know what you think!
Tonight's update is... there will be no more updates! The final version is built - all updates included and features tested. I just loaded it on my dev unit and so far everything is kittens and rainbows
As long as everything checks out with the team, we're all ready for the launch date
That said, I'd like to take some time here to thank all five members of the beta testing team - bob-st, rickpcb, sb43, theminor19 and TimeofDeath. I know I've done this a few times via PM, but the time and effort you guys have put in seriously bears public mention. Everybody, three cheers for these guys!
And now, for some info on the ROM itself.
What can you expect from version 2.00? Speed. Stability. And most of all - features. In fact, many features and techniques here are unique to this ROM - you won't find them anywhere else
You all know this version has the extended power menu, and it has swap enabled this time around, and all that jazz... but the differences between this release and its predecessor go deeper than that. Some of the exclusive features include:
This is an original script which kicks into gear when your screen goes black. As your device enters its sleep state, this script activates and ramps your CPU maximum speed down to its minimum value, essentially forcing a more consistent, lower power usage than normal. Upon receiving a screen-on event, the script rapidly shifts your CPU back to its normal maximum setting to get all the power back to your fingertips before you even miss it. It's a little gem of a script, and you won't find it in any other Gingerbread-based Warp ROM.
pre-selected system settings
You know how it goes. You clean-install a new ROM, only to find you have to redo all your system settings, since the default Android ones usually aren't quite the best for our purposes. With WOEM 2.00, that all changes. Right out of the box, you're able to install non-market apps, automatic brightness is selected to conserve power when able, and WiFi now defaults to off, as it was in the older firmware versions - before Boost decided to off as much of their network traffic as possible to local networks by pre-enabling Wifi.
one heck of a modded settings menu
Gone is the old black-and-white drab of the default Android settings menu icons. Say hello to the new colorized cousin of that eyesore we're all familiar with. And Warp OEM doesn't stop there! Also ready to greet you are a plethora of new options, all integrated directly into the menu. Need to adjust your CPU speeds? Maybe you'd like to see what those speeds have been doing recently. Or perhaps you'd like to change the layout of your notification toggles. You can do all this - and more - without ever leaving the settings menu. Now there's a feature you won't find on any other Gingerbread-based Warp ROM.
built-in USB tethering
WOEM 2.00 supports tethering your PC or laptop to the internet through your Warp using a regular USB cable. On the Windows machine used for testing, no drivers were needed, no settings were necessary. Simply plug in your phone, and Windows detects your new "internet sharing device" automatically.
Another Warp OEM exclusive! You no longer need to do a two- or sometimes three-step process to access your Warp's internal storage via your computer. Activate the automounting feature, and when you connect your Warp to your PC it will mount itself with zero user intervention. Pure simplicity.
pre-loaded VM swapfile
Most modern, custom Gingerbread Warp ROMs come with the swap feature to give the device extra space in which to operate. Doing so requires setting up a swapfile of a pre-defined size, which is partially responsible for the extra-long time of the infamous first boot. In Warp OEM 2.00, the responsibility of creating this file has been offloaded to the installer script, which allows for an even faster first boot time.
platform verification protection
As an added safety measure, the Warp OEM 2.00 installer script also verifies you're installing on an actual Warp before continuing the install. That in itself may be nothing new, since some ROMs already do this, however each custom recovery returns different identifiers when performing this check. To allow for this, ROMs which perform this verification are forced to adapt to this condition, usually in one of two ways: 1) The dev will make a version bundled with CWM or with TWRP and you install the one you like, or, 2) the dev bundles the ROM with whichever recovery that allows the ROM to install properly, then you have to flash back to your preference afterward. At best this bloats the final ROM size, or at worst forces the user through some extra steps to get their phone the way they want it - or already had it. In contrast, the focus behind Warp OEM is on being as efficient and streamlined as possible, and to that end it contains an advanced installer-script which intelligently identifies which custom recovery you're using and adapts itself accordingly. This allows it to require no certain recovery to ensure a successful installation, saving ROM space, download time, and simplifying the installation process.
So... there you have it. A basic summary of just some of what makes Warp OEM, Warp OEM. I know parts of this were already common knowledge for those who have been following development for any length of time, but for the newcomers to the project, I figured a semi-rehash wouldn't hurt
I'm not trying to build unnecessary excitement here or anything like that, but I figured I may as well give you guys something to hold you over until the testers are done!
Oh, and the OP is also newly updated to reflect the changes made and steps taken, etc. Check out that OP and see a benchmark of Warp OEM's trademark speed for yourself!
Oh, Warp OEM... Y U NO DONE ALREADY?? Oh well... at least there's an update
Well, there's really nothing important to say here lol The majority of the ROM is done and running with - quite literally - flying colors. The latest beta had lag issues coming back from screen-off (no, not from zram. I hate zram lol) but I eliminated unnecessary wait states in speed restore routine, so that should be taken care of. I also did some general housekeeping and fixed up a couple icons - one of which looked downright shoddy - and am putting on some finishing touches as we speak. I think it's safe to say that most likely by the end of next week (Friday the 15th) Warp OEM 2.00 RC1 should be available for public download
Right now I need to accomplish these things to meet this timeframe:
- optimize ROM details and init.d scripting
- issue a final beta build for evaluation
- compress ROM files
- bundle it up and upload!
So, bring on the leftover Pizza Hut, pour a glass of and cue the Linkin Park.
Let's do this.
Okay, I seem to be hearing speed above smoothness, yes? Good, 'cause that's what I was inclined to do anyway
I could even make an add-on flashable which takes the speed hack back out, giving the user silky smoothness at their option.
I think that's the ticket
I have a question for you all:
If given the choice, would you rather have speed (an additional ~800 on your Antutu score) or graphical smoothness?
I ask because I have just such a tweak - but I'm not sure if I should include it or not, since it makes the graphics glitch 'n' twitch sometimes.
The new build was just uploaded for the testers, and I'm awaiting feedback
Speaking of tester feedback...
One reports that his wife doesn't like anything - but she likes this beta! lol
It has been used all day and upon returning home, the phone still had 80% battery remaining
I've heard reports of literally everything being thrown at it (wallpapers, widgets, multiple home screens, all kinds of background processes, various voice recognition apps, dialers, etc.) and the ROM hasn't slowed down a bit.
Battery life is reportedly excellent as well, and I'm looking into a way to possibly make it even better.
Granted, there are still bug reports, too. But we're working on that
If you folks would like to follow along with said bugs, here's a link to the list we've been working from:
In the newest build, the worst of the known issues of previous builds have been fixed and init.d scripting is re-enabled, as well as the swap subsystem which this time around is powered by a new script providing a true 512 meg swapfile.
Like most other mods I'm doing in this ROM, the CPU property setting script is as forward-looking as possible: in addition to setting a custom CPU speed, governor and scheduler like most scripts written for this purpose, the one in Warp OEM has an assistive logging feature which records the actual value back from the clocking system to determine the success or failure of the operation. Future devs using this script - especially on devices other than the Warp - may find this helpful if they find themselves needing to make changes to the core script itself, as well as the fact that all four settings can be accessed through global variables right in the beginning of the script, eliminating the need to sift through and change values line-by-line. A simple change in the file's start, and the rest is handled automatically, making edits not only convenient, but reducing the possibility for errors being introduced into the system as well.
Speaking of errors, this script does not have the "infinite log" bug seen in some ROMs in which the CPU property script fails to delete the log file created during the last boot and appends to the log instead of starting fresh. As you can imagine, over time this log grows larger and larger - and never gets removed unless the user is aware of this situation and removes it manually. This bug occurs because the script used by most ROMs is not designed specifically for the Warp (as most things aren't lol) and depends on having direct access the various binaries used for performing basic tasks (e.g. deleting files) whereas the Warp has symbolic links to a single Toolbox binary which does the jobs normally handled by the others, similar to the technique used by Busybox. The script in Warp OEM correctly utilizes this Toolbox to enable itself to operate properly and prevent /data from gradually shrinking.
How are you gentlemen!!! All your update is belong to me. Make your time.
...yes, I'm pretty tired... lol
I've gotten the worst of the bugs fixed; testers will be notified shortly.
I found the installation issue (wouldn't install on CWM) to be caused by differences in what the different recoveries return for getprop. What was needed was some way to have the script check for the appropriate responses based on which recovery it's running under. So I wrote a little Edify and, bang! Issue solved
The camera panorama FC issue was due to something in build.prop. I've temporarily reverted to a stock version for now. I've also temporarily taken out init.d, although it should be back soon.
Play Store problems all seemed to be stemming from the Dalvik configuration I was using. That's been removed for now, too.
All in all, progress was made
So after some rigorous testing, the beta team has identified several bugs which I want to fix before proceeding. I've made a summary list here, and as bugs get fixed I'll update this list. After they're all gone, development shall continue
- charging icon not displayed correctly (minor - known fix)
- browser icon in dock doesnt work unless used via app drawer first (minor - fix planned)
- ringtone selection screen is choppy, animation not smooth (minor - side effect of removing FPS cap)
- when installing different launcher (Next Launcher was used), it installs but when chosen as default it reboots phone and shows no home screen (fixed? needs tested)
- Play Store fc's (fixed - removed build.prop tweaks)
- changing wallpaper with QuickPic reboots phone
- ROM loads in TWRP but not CWM - fails device verification (fixed - major rewrite to updater-script to handle different recovery types)
- unable to register Google account (fixed - preinstalled Google services)
- ICS camera fc's in panorama (fixed - lib issue)
- no homescreen in beta_02-23-13 (fixed - Adreno lib issue)
- complete version not shown in settings about menu (fixed - data added)
At this point, I'd say development can continue after these fixes all get verified by the testers.
Well, it's just after 2AM and I'm at of my dev console yet again... must be time for another update!
Lately I've been having issues with the Play Store force closing and just acting very weird in general - spontaneous exits, FC's galore and tons of lag. But no more! I checked inside its dependee, Google Play Services, and found a lib that wasn't installed. Also (somehow ) Google Framework Services got deleted. I took care of these two things, and everything works better now - at least on my device!
I also got the ramdisk problems fixed, and init.d scripting finally works, so the current beta build has the default scripts from the Alien kernel in it for now until they're swapped out for others later on. That means swap is finally active - not just available-but-dormant, as in the WOEM 1.xx series! Having twice the normal amount of RAM available is always a good thing
After the super long initial boot, I clock Warp OEM at about 21 seconds from push-of-the-button to homescreen-shown-and-ready-to-run.
The build is assembled and uploading as we speak - er, uh - type. Links will be sent to the beta team shortly.
Okay, guys, you know what to do
The cause of the "no homescreen" issue was a set of Adreno libraries backported from Jellybean which I was going to give a trial run and forgot I had them included in the build.
They have been reverted to their Gingerbread counterparts and the build I make tonight should be totally functional
And speaking of annoyances and kinks, that last build seems to have had a bug with the launcher. But that's probably just as well since there was also a bug in the text messaging, too. Sorry testers
Okay, the fourth update for the night! That's right, count 'em - four! lol
Tonight's major update: MMS.APK IS COMPLETE!
The total confirmed, working (at least on my phone - still have to get input from the testers) features list is as follows:
changed "attached" to "attachment" in attachment actions menu
increased maximum message-per-thread limit to 65,536
increased number of slides allowed in slideshow to 1024
changed supported image size from 640x480 to native 2560x1920 (near QSXGA-level HD support)
made SMS automatically convert to MMS if greater than 160 chars to stop SMS split-up
increased default Text message limit and Multimedia message (limit before cleanup) settings to 8192 messages each
enabled sending to up to 64 recipients at a time
changed maximum number of lines to which text input window will scale to 8 - thanks to Difusal at XDA!
and... last, but certainly not least:
increased max attachment size to 8MB - that's right.... 8MEGS
In one of the initial builds I had the limit cranked to 9MB, so I sent myself an image to test out the new settings... the servers dutifully echoed my image back to me, and the data for the resulting image I received back is shown in the attached pic
Now, to get a build out to the testers...
Yes, that does say 79 megapixels. Welcome to text messaging on Warp OEM!
I already know what I want to do to the MMS app, but how to tell if what you want to do to it is actually supported by the network?
To begin my MMS modding, I look in res/xml/mms_config.xml. Inside, I find an identifier URL:
Entering this in a browser shows a big block of text that - if copied into a decent Unix-compatible text editor like Notepad++ - shows the hardware attributes of the device this copy of MMS expects to run on, and the limits of what it can support - which are not necessarily the limits imposed by your carrier. This helped me verify which of my plans would work and which would not
Okay, so being the detail-oriented guy I am, I really didn't wanna accept the hack-job method of just deleting files because they didn't work. So they're back! But fixed this time, so there's no more lost localizations
The first file was pretty straightforward, I just did exactly what the aforementioned error message said: In values-nl:
[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="other"[/COLOR]>[/COLOR]%1$s resultaten voor '%2$s'[COLOR=#8b008b]</item>[/COLOR]
[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="one"[/COLOR]>[/COLOR]%1$s resultaten voor '%2$s'[COLOR=#8b008b]</item>[/COLOR]
[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="other"[/COLOR]>[/COLOR]%1$s resultaten voor \'%2$s\'[COLOR=#8b008b]</item>[/COLOR]
[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="one"[/COLOR]>[/COLOR]%1$s resultaten voor \'%2$s\'[COLOR=#8b008b]</item>[/COLOR]
The second file was a bit tougher; I did some research into XML and substitution passing from Java, and found a solution. In values-ru:
Okay, sooo... init.d is on hold for a bit, cause I can't figure out why it's not kicking in when it should - although I may have a guess. More experimenting is in order. But who wants to wait for that?
Instead, I decompiled the MMS app, and am beginning to put the needed changes inside. Actually, this is the second time I've begun to do this - the first time I couldn't get it to recompile, but I finally figured out what was wrong there: Virtuous spit out several errors (shown in attachment) regarding syntax upon my intial attempt to compile - and I hadn't even changed anything yet! So I deleted the folders mentioned (values-nl and values-ru) from the APK structure, and tried again. This time, instant success. So you lose a couple localizations, but it does compile. Weird. But oh, well... so is the wonder of Android lol
From what I read, the MMS APK is one of the trickiest to work with so wish me luck! Please?
Tonight: Yet some more integration, begun implementing swap (and init.d in general) but it's not kicking in for some reason just yet...
Tonight's update: more integration work, cut fluff from the OP, replaced some icons I wasn't happy with (told you I'm OCD lol) and allocated an extra framebuffer as a test to try to cut down on flicker.
Oh, and finally deleted that freakin' USB driver CD image. Crap, was that thing annoying. Not to mention it was about 7 megs... and this ROM's on a diet!
Early this morning I put together a beta build of WOEM (around 60% completed) to be seeded to my main tester, and everything seems to be running smoothly. So far so good!
In the mean time, I'm putting together the next build which will include a couple bugfixes I have on my list, and maybe some early size optimizations. I'd like to keep this version under 100MB, making it the smallest version to date but if that proves to be impossible... I won't lose a whole lot of sleep over it lol
Like I said before, this version is all about optimization, optimization, optimization - I'm trying to apply every little tweak and trick I've learned to make this release an ultra-small, feature-packed ROM that will blow away its predecessor.
Here's the fruit of the last 11 hours I've spent in front of my monitor... a completed, 100% working and functional extended power menu
I know I said I was originally going to do away with the bootloader and put in something else... but I'd already made the icon! And that's as good as etched-in-stone to a dev
But seriously though, I opted to leave the bootloader in since what I was going to replace it with isn't going to work out at this point, and it turns out the Warp seems to have a 6 item maximum anyway. Plus it could come in handy for the rare instance of someone bricking their Warp. I'd hate to not include that one thing that could possibly fix someone's phone!
I decided to add a rapid reboot option to the list as well since I've come to heavily depend on it lately with all this modding going on. I also had the extreme pleasure of deleting Quick Boot from my system folder. Sorry, Quick Boot... nothing personal.
Next up, I'm focusing on integrating a couple more apps. I'll keep you all posted as always
The new extended power menu
*sings* I've got an uuuuupdate, another uuuupdate... [/singing]
The power menu works! After this long of a fight, I feel the need to repeat myself:
THE *expletives deleted lol* POWER. MENU. WORKS!!
There are probably some other devs out there who will facepalm after reading how elementary of a solution this was, but for me this was a big win. I've always felt completely out of my element when it comes to the internals of Android, but I'm starting to learn. And that gets me excited! So bear with me... lol
So my earlier conclusion was correct, framework.jar did need modified as well to complete the mod. After locating exactly what code would need imported, I did so and hit compile only to get an error message. The code compiled fine when my additions were commented out, but as soon as one of the two major chunks were reactivated, boom! Compile error. So I studied (or just stared dumbfoundedly at ) the code. And studied. And read, and learned. Smali assembly turns out to not be that far removed from the good old computer-based assembly I'm used to. So applying the logic I did know to the things I didn't know, I came to the conclusion that somewhere in what I was adding lie something that was conflicting with the existing code; judging from previous experience, I figured it was a line label. A quick search proved this correct - sure enough, there was a duplicate ":cond_0" label in one of the methods in ShutdownThread. Apparently the new changes that ZTE made in the B10G update caused their compiler to add a line label that seemingly wasn't present in the previous firmware versions. I gave all three line labels in the code I was including their own unique names and compiling was suddenly successful After a quick ADB push, victory was mine!
So, the basics are in place. As per the tutorials I've been following (attacking?) I now have Reboot, Recovery and Bootloader added to the menu, and all function perfectly. As you've probably come to expect with me, however, I'm not done with it yet - I think I'll remove Bootloader since it's really not something used on a daily basis, and I still need to add the Screenshot option as well. But this is a start! And it sure is nice to see some results after staring at code I began totally unfamiliar with.
And also, once everything's all said and done, I intend to write up some step-by-step detailed tutorials on how I did this and the settings menu mods. That way other beginners won't have to slough through all the stupid little details as I'm finding myself doing.
Until next time... goodnight, everyone
Tonight's update: I think I finally solved the power menu issue. Well, solved may be a little hasty... we'll go with "pinpointed."
Apparently I misconstrued the information in this post way back when, and have been focusing on editing only two of the needed three files ever since. The power menu mod does in fact use all three files to work properly, as it even says later in that very post! Duh.
Hopefully now I can get some interesting things going on this part of WOEM 2!
Oh! And I updated the OP for those who'd like to further examine the changelog
Nooo, no risk of that! This dev is alive and well!
...well, except for being severely time-pressed and sleep deprived lol
But enough about that. IT'S UPDATE TIME!!
Behold: WarpOEM's new settings menu and all its bundled features
Features?! New features, you say?? Why, yes indeed! I took all the commonly used settings across all the essential apps (No-Frills, the launcher, and a couple others) and rolled them into one easy to access place. Now you can do everything from fine tune your launcher to overclock your CPU, all right from the settings menu.
But wait! There's more! lol
As complete as it may look, I plan on adding another few features to it in the end, so look for a couple surprises in the finished product
Hey, it's better than the menu looked stock lol
The freshly-themed menu!
It's 2AM... I'm tired... it's bedtime... I'm going to bed... no... WAIT! One more edit! ONE MORE BUILD! Just one. I promise. Please?
Aaaaannnnnnnnywayyyyyy... here's the summary of tonight's APK editing and pushing session, A.K.A. "dev work" lol
The WOEM settings menu just got another overhaul. This time, I'm redoing the layout and adding options, more custom icons and hopefully some other fun things :)
I probably won't finish this until tomorrow night, but fear not - screenshots are to come!
This file is proving to be easier to work with, but I'm still having a slight issue. The power menu appears, along with icons and everything, but when you select something that was added, nothing happens in the case of the screenshot option, or you get a partial reboot for the other two.
You can has update!
The recompilation issue is solved!!! Because of that, half of the extended power menu mod is done - framework-res.apk is completed and working! YAY! Next up: android.policy.jar.
Wish me luck
Well, it took a complete rebuild - from scratch, no less! - but I finally got the bootloop fixed. I have a couple other tweaks, then I'll pretty much be down to just the mods which require recompiling APKs, which may take some time. Soon I'll post a partial changelog of features that have been implemented thus far.
Okay, since the last time I checked in here, I've completed several minor - but cool - features.
You know how the 3G icon turns to grayscale when your data isn't being synced with Google's servers? The Android framework system supports the same indicator difference with WiFi, It's just that the icons in WOEM were always set to the same images by default, so you can't tell the difference. I now implemented a set of grayed-out WiFi icons, so now you can tell if you're syncing or not.
I also got rid of the pre-loaded Boost contacts which the system places in your phone by default. That always was a personal annoyance of mine, so now it's finally gone. I also modded the installer-script to wipe /cache for you, making installation one step easier.
Many, many icons have been themed - some custom and some from ICS - and the Status bar is now slightly updated in appearance, complete with a new font as well. The battery icon (shown in the attached pic) is nearing completion, however I believe I'm going to turn the battery itself so that it faces the other direction. I just think it would look better that way.
Another thing about Gingerbread's look which always perturbed me is the gray spinning "loading" icons shown any time something is taking too long. Now they're sporting a blue gradient instead of being black-and-white. The thing that grinds my gears with this is even ICS has the old gray icons! Come on, Google! This isn't 1963 anymore... get with the times, already! lol
The alert and information dialog icons are now also colorized in yellow and blue, respectively, and the animated downloading icon has been redesigned. We also have new text selection handles and missing app icons as well, brought over from ICS.
Sorry I haven't shown screenshots of all these goodies, but there's two reasons for that:
1) It's been a very long day, and I'm one tired boy lol
2) I don't wanna spoil everything for you guys!
While I've been typing this, I had my latest test image installing on my dev Warp and I just fired it up for a test run. Suffice it to say... wow. Warp OEM is still smokin' fast.
And that's only at 1.4
Battery life indicator in blue
The battery indicator is completed and functional, however I've decided to tweak it a bit more before showing it. Overall, the new look of the WOEM UI is really starting to come together.
Ok, let's try this again, shall we? lol
The WOEM status bar has several refreshed icons.
I've personally never liked the vibrate mode icon in my ROM, so I modded it to look like what I consider a more traditional vibrate indicator.
The design for the signal meter came from ICS as I mentioned before, but this one wasn't a direct copy-and-paste, as I have been doing with many of the ICS icons since the phone I'm ripping from only had a 5-bar meter and we Warpers have 6. I kept the same general ICS style though.
And finally, the data service indicator... yeah, I still can't decide. I first did it in green, then thought maybe blue would better suited for this icon. Personally, I like the green... but the blue does seem to look more natural and also seems to fit both the phone and the overall look of Warp OEM...
Decisions, decisions... :p
Next up: the battery icon! I'm thinking of doing a two part icon for this one. Where most custom battery icons have a "fat battery" to accommodate the percentage number, I think I'm going to do a slim battery icon with the colored meter inside, then the numbers above. We'll see how it goes.
Signal meter in both green and blue
So I went to upload that screenshot last night, and our beloved site was down. (oh noes!)
But that worked out, because it gave me time to critique my work and decide to do some more tweaking. Maybe I'll hold off on that screenshot for a (lil? ) bit lol
I'm almost done with some more theming I've been working on. Warp OEM will now have a new ICS-inspired signal meter and a new set of data connection icons, e.g. the "3G" and "1X" indicators. These were again made custom for WOEM, done in the Nasalization font, expanded in layout size and anti-aliased. I'll up some screenshots as soon as it's done.
Have you ever in real life seen a blue micro SD card with only three contacts? Didn't think so. Neither have I. Again, Android's selection didn't impress me, so I handmade my own.
Pssst. Hey, there, art designer. SD cards arent little blue blobs.
I wasn't happy with how the icons just changed to a different shade of grey when selected, and ICS doesn't have any icons for this. So I made my own!
Before and after
I needed a break from all the power menu fail I've been experiencing, so I decided to do some light theming. I know this has been done before in other ROMs, but it's new to Warp OEM. The settings menu now sports ICS icons ripped shamelessly from my roommate's Samsung Galaxy SII.
Before and after pics below.
Before and after
Just a minor update:
I finally got a development Warp! This will make it much easier to do testing and such, as I depend on my main Warp almost constantly for one thing or another and it really puts me in a spot when I have to take it down for dev work.
Okay, I guess there's no signing needed for the two files in question. But I did a little test to see if what I'm putting in the files is causing the issue or the process I'm using to do it.
I flashed the stock B08C ROM, then took framework-res.apk from it, decompiled it in APKMultiTool, then changed nothing and directly recompiled it. I put the file back on the phone, and once again I have a bootloop. Something, therefore, is wrong in the way I'm compiling the file, not in its contents. I just don't know what yet. I tried chmod, using permissions 0755 and 0644 with the same results.
It just sucks, since this is really the only thing getting in the way of publishing a testing release - the rest of the complete B10 ROM is assembled and done. Except for theming. And that's best left to the experts! lol
Okay, so I got all the code in correctly - as far as I know. Got everything to compile. Yet every time I bootloop. I assumed it might be a difference in the way B10G was made, so just for an exercise in coding I attempted to modify a pair of files for B08C, just to see if I could get that to work. Same result. There's some small detail I'm missing here, I just can't put my finger on it. It may be the way framework-res.apk needs compiled, or maybe something needs signed to work with the system. I'm not sure.
But one thing's for sure... when the going gets tough, the tough call Mr. Bobo lol
Since he's been down that road before, I figure who better to ask than him? All the code is laid out, all the changes have been made... something's just not clicking. Frustrating, to say the least.
More on that tomorrow. Goodnight all.
Okay, what the f&*@ is up with ZTE and their insane numbering schemes?!?
Usually in most code I've looked over in the past, if there's a list of objects or ID numbers or what-have-you, they're in order!! Leave it to ZTE to screw something so fundamental up. *smh*
"Oh, yeah! I forgot I need to get bread too! I see number four is at the bottom of the list, so I'll just add a number five for bread... What? There's already a number five?? WHO DID THIS?!"
Now extend the logic problem in that example to a list of hundreds of objects.
I was indeed correct, the numbers were horribly off. I should've known better than to DWE - Develop While Exhausted. All fixed now, along with one other typo introduced since the tutorials I'm following aren't even for the Warp, let alone B10G. Compiling now, here goes nothing...
Edit: And fail! I think I need to take a step back and try to just introduce one feature at a time - which I technically should have done all along. Overzealous much? lol So, I'm starting from scratch, adding only the reboot options first.
You know, unfinished development issues make it difficult to sleep...
So I tried a few more things and figured it out. I didn't have an icon in the drawables folder to match the definition in the xml. Now compiles fine
About to test now...
Edit: The good news... it reboots! The bad news... it does it every time you hit the power button and doesn't even show the menu. But I think I know why. In my debugging efforts, I changed the ID numbers around to eliminate the possibility of duplicates and I think I forgot to change them accordingly in the other locations.
But it compiled! And booted! And I'm happy with that amount of progress for now, so I'm going to bed.
...and I mean it this time.
Perhaps I was a little ambitious when adding everything to the power menu. I'm adding the reboot, recovery and screenshot options. I get both files modified, go to compile, and there's an error. I've narrowed it down to the three lines in public.xml beginning with <public type="drawable" but can't figure out what's wrong with them. All I know is that when they're removed, it compiles fine. Go figure.
Yes, yes, I know it's not good programming practice to add in multiple things at once. But I was excited! *sigh*
Oh, well. It's 7AM. Time for bed I guess...
In light of the new B10G firmware update, I figured there's no better time to start working on the next step in Warp OEM development!
The bad news first... the 1.xx series is officially discontinued and will no longer be supported. All the old versions are still available, and I'll still be here to happily answer questions on it if I can, but further updates or extra flashables or fixes just aren't going to happen... I simply don't have the time.
Now for the good news! Development of 2.00 is underway and most of the basics are already in place. So far it's running with typical speed, lightweight and responsive. All the usual apps and things are there as you've come to expect in WOEM. I've trimmed bloat wherever possible and incorporated several new features which have been a long time coming, such as the flashlight fix, integrated ad-blocking and storage auto-mount as soon as you connect to your PC.
I'm a big fan of what has been called the "open development model" and I will be using it. This is the first of the regular updates I'll be posting while I do my work on this and get feedback from the testers.
With most of the ROM functioning, my next step is to begin integrating the extended power menu into B10G. I believe I'm the first to attempt this (unless Mr. Bobo's already started lol) so here goes... :D
Another new version is available... it's time for another update!
Version 1.55 isn't a groundbreaking release, but it includes several new tweaks, such as the Alien 3.0 kernel (thanks DM47021!) and updated apps, including the ICS camera. This release also marks the first to come in two parts. Most of the bloatware apps have been cordoned off into their own .zip, available in the downloads section, which you can flash after the ROM itself to add in all the extraneous apps which for many users only serve to bloat the system with things they don't use. The ROM proper now includes only the basic apps. My general rule for deciding what went where was: if I added it to replace a stock system app, then it's in the ROM. Otherwise, it's in the apps add on pack.
Overall, this is the fastest version available yet, and should prove plenty adequate to hold everyone over until the release of 2.0 later this year.
I hate to do this. But I think it would be in the best interest of the project if I closed it down temporarily for a bit. My spare time has been dwindling more and more and as I look over the version history of WarpOEM, I'm seeing that my lack of extra time is showing in my releases. This isn't the kind of product I want to put out, and it's not fair to you, the users, either.
I will continue periodically visiting the forum, and therefore will still be here to answer questions on the ROM and steer people in the right direction if I can.
To everyone who took WarpOEM for a test drive, I say a very sincere thank you.
So until I get things a little more together, and a little more things ironed out... this will be the end of WarpOEM's regular updates.
So what's everyone's thoughts on the apps I bundle with this ROM? In the next release, I plan to trim the bloat, but I'd like some input on what you guys would like to see gone.
I have a question for you guys. Is everyone happy with the apps I bundled in Warp OEM, or do you think I should cut down on them? I could even put them in their own folder and let the end users decide what gets installed and what gets erased.
Post here, PM me, or whatever... let me know what you think!
Okay, I just flashed downthemachine's 1.7GHz overclocked VM kernel with Warp OEM 1.50, and all I can say is... WOW.
Oh f&*#ing b*#&s is this thing fast. And I'm not even running it with the performance governor yet!
Version 1.55 will definitely have this kernel.
...and about four hours of dev work later, it's finally time for another sitting-here-waiting-for-my-dropbox-to-sync update!
First off, my apologies for the long delay in getting this one out. The good news is all the more serious issues that Warp OEM had are fixed! In fact, I was just pulling a Dropbox upload while I browsed Google while having full data signal, so WiFi appears to be working well, too. Also, the camcorder and camera actually do what they're supposed to now... imagine that! lol All the apps (like 20 of them!) got an update so enjoy the new Google Maps and YouTube! I also added some new apps, so enjoy!
Hmm... I think that about covers it.
So, testers, you know what this means... bug squashing time
9/30/2012 - Update
Okay, I officially got the camera and camcorder fixed. I still haven't had time to revise and re-release the ROM, but if you are having issues, restore your original system sounds in system/media/audio/ui and all should be well.
Sorry about that
9/26/2012 - Update
In other news, I tested out 1.42 on my phone and I have the camera issue on it as well... about to see if the issue goes further back than 1.42. If anyone gets a chance to try the older versions before me, please let me know your results.
Also, I added installation instructions to the OP. Hope that helps everyone!
And I updated the changelog to show even more stuff that'll be rolled into the next release.
So I swapped out the build.prop for the original file and the camera and camcorder still are not responding. Something got messed up somewhere...
Is anyone on 1.42 having this issue?
Okay, all, time for a little status update. I've gotten the latest release built with the new hybrid build.prop, which incorporates mholloway's Super Phone III. Everything works fine, except the camera and camcorder are unresponsive. One of these d*#% tweaks is apparently to blame. I've spent most of my weekend working on this, and it will get fixed, but unfortunately what this means for you all is that there will be no release for this weekend. I apologize, I know several of you were looking forward to 1.45, but I never have released software with severe known bugs before and I have no intention of starting now. As soon as I get the new hybrid working properly, I'll upload as soon as possible.
Okay, after getting feedback from all you wonderful testers out there (thanks ) and getting some info from Dm47021 in reference to the topic, I've decided to officially incorporate MHolloway's SuperPhone III into the next build of WarpOEM. Hopefully this will weed out the last remaining annoyances from the ROM. Version 1.45 should be out this weekend, provided all goes well.
Here I am, waiting for Dropbox to upload my file, so I figured I'd give a little info about things while I wait.
First off, thank you to everyone who's tried my ROM. There are tons of ROMs out there you could run, but you took the time to run mine. Thank you. This means a lot to me
Second, I changed the version numbering scheme for Warp OEM. Instead of doing build numbers, I'll be changing the version number now. I changed all the existing version numbers to reflect this.
Third, due to the large number of downloadable versions of Warp OEM there has been some understandable confusion among users as to what they should be downloading. I'll be updating the OP to clarify this, but I'll summarize it here. The stable builds are the main, current version of Warp OEM. If you'd like to try out my ROM, you should download the highest version number under this category. If you do so, and something fails miserably/crashes and burns/hangs/bootloops/forgets to do the dishes/gives you a cold/causes drowsiness, coughing, rash or sometimes even death (lol) or any other medical or non-medical mishap, then (and only then - the debug builds are not meant to be "daily drivers") you should see what the highest debug build version is that you can successfully run. Whatever that number is, let me know and I'll see what I can do to help.
Fourth, in all versions of my ROM, /data was not supposed to be being touched at all. Upon reviewing the updater-script, I think this might not have been the case. I guess these are the things you don't notice when you do your testing on your own device In version 1.42 this issue should finally be fixed. Also fixed is the QuickPic closing issue, and the ads are removed from Root Browser. We also have some build.prop tweaks added back in, so... yay!
Thanks again, everyone, and enjoy Warp OEM 1.42!
I've made the original Warp build.prop available and updated the OP with the link. Overwriting the Warp OEM build.prop with the original one will do away with the "zoomed" look and make your screen the same size as the Warp's stock ROM.
Debug build 2 has been assembled and available (link added to OP) so guys let me know how it works for you. I need as much feedback as possible to make sure everything's running smoothly. Build 2 takes Debug Build 1 and adds the Warp OEM theming, the throttling fix and init.d support.
Lets see how things go...
Edit: Like its predecessor, Debug Build 2 seems solid. I'm wi-fi tethering as I write this, and everything is running smoothly. I do notice what is perhaps a bit of the wi-fi sleep issue, maybe someone else can confirm.
Edit to the edit: I think the wi-fi sleep issue I thought I was having was just the Task Killer being over-zealous. I terminated it and it doesn't seem to be happening anymore. So, on to build 3... and that's where things will get tricky. It will add to #2 the OC kernel and have all the bloatware removed.
I saved this for last, since these two steps are most likely to break things. Here goes...
Edit to the edit to the... well, you get the idea
Okay, so I built #3 and lo and behold, wi-fi issues. I swapped kernels (1.7 to 1.6GHz) and the issue is solved. This is actually a null change since the 1.7 kernel always maxed out at 1.6GHz anyway, at least on my phone. So I can officially say the wi-fi issues are fixed! And I must give a big thank you to whitefiretiger for recommending the 1.6GHz version of Shin's kernel (which he said he's never had a problem using) over the one I was using. I didn't know there even was a 1.6 version, and had it not been for him suggesting it and providing me with the file from which to extract it, I most likely would've switched to a non-OC kernel. Thanks again. You rock!
Success at last
Now, on to adding all those fancy features like Mr. Bobo and the rest have
I've been running debug build 1 for a bit now, and the only problem I notice is QuickPic not working. Other than that, everything's solid... wi-fi, tethering and all. On to debug build 2
9/4/2012 - So, okay, guys... there it is
I really was kinda hesitant to release it just yet because, frankly, there's still a lot about this ROM I don't like; there are several apps included in the ROM that I'm just not happy with. I'll be replacing several of the apps in my ROM with better ones as I get time to test them.
Once you install Warp OEM and get through the initial boot in which all the fun stuff gets rebuilt (the data partition, Dalvik cache, etc.) you can look forward to some speedy load times. The highest I clocked was around 28 seconds; the lowest was 17.
I'm eventually going to complete my study on how long the stock battery will last on a full charge while doing different activities while running Warp OEM. When all the data's in, I'll update the post.
If you're not a big fan of the chance of having wi-fi issues or need Bluetooth like you need air to breathe, the stock Warp kernel can be flashed atop the default one and the ROM will still run, albeit without its signature speed.
EDIT: Thanks to the Alien kernel, all issues with wi-fi, Bluetooth and RIL have been resolved.
And speaking of speed, the internet access in Warp OEM is pretty swift, thanks in part to the included ad blocker. In my experience, pages load so much faster when you're not wasting half your bandwidth on transferring crap you don't wanna see anyway. So use it. No exceptions.
EDIT: Ad blocking is now integrated into the ROM - no need to explicitly use it.
Warp OEM is extremely stable, but bugs do still exist and it will help to have more bug testers on the project than just me.
The installer script doesn't touch /recovery and won't format /data, therefore using it is quite safe. So download it, take it for a test drive, and feel free to let me know what you think and how it performs for you.
I had lots of help from you all in making this ROM, not only in helping me fix things, but in giving me ideas and inspiration and steering me in the right direction when I was frustrated with how things were going. And for that, I say a very sincere thank you to you all. And also, thanks to all my future bug testers.
3/1/2012 - Progress report on NextBASIC compiler.
We are pleased to report that development on the NextBASIC compiler is off to an impressive start. We have decided to tackle the most complex items first, such as nested mathematical function evaluation and complex IF / THEN parsing. At this point in time, the compiler is barely functional but as you can see in the Screenshots section, the basis of its ability to parse and calculate the more intricate algorithms found in some programs is already operational. The goal of this project is to provide the highest degree of compatibility with QBASIC possible while still producing fast and efficient object code. What this means for developers is when using NextBASIC they will be able to directly import the majority of their existing QBASIC code and have it compile to Exelyx native instructions with absolutely ZERO modification, regardless of the complexity of the program, as long as the code uses standard BASIC language commands. Tricks like direct screen writing and manipulation of memory addresses may break due to the fundamental differences in the underlying architecture of the Exelyx kernel versus DOS, but the majority of normal programs should run just fine.
2/21/2012 - Development of NextBASIC language and accompanying compiler.
The Exelyx kernel has long been plagued by a lack of active application development. And what good is an awesome operating system if nobody's writing code for it? The first attempt to fix this issue was PBASIC, which was simply a Exelyx native compiler for the classic BASIC language. After minor development, the compiler was shelved. The next attempt was to give the kernel the ability to run binaries targeted to other platforms. This approach is also uncompleted, but is still under development and is scheduled to be implemented later in the kernel's life. All this considered, however, these solutions are not the best way to solve this issue, as several developers and users have pointed out. The new solution? NextBASIC. This is not only a new dialect of the traditional BASIC language targeted to the Exelyx platform, but the program will also cross-compile for the Motorola 68000 family and the Intel x86 family as well. The ability to compile native DOS applications means that the Exelyx kernel will no longer have to rely on the obscure and expensive PowerBASIC compiler in which it was originally designed. What's more, since it's a stand-alone application, the NextBASIC compiler can be used with an existing IDE such as QBASIC by replacing the bundled compiler. Since most of the folks doing development on the Exelyx kernel have a stronger QBASIC background as opposed to PowerBASIC, this will open up development to more people, considering not everyone has access to (or wants to spend $100 for) PowerBASIC. Of course NextBASIC will be released as free software, and using an open source compiler will more strongly emphasize the Exelyx project's free software identity.
1/17/2012 - Preliminary results on execution core... and why there's an Easy68k icon on the homepage. Oh, yeah... and happy new year!
The execution core of the new series 2 kernel has undergone several refinements and enhancements over time as new features were added, designs were optimized and methods and throughput speed were increased. What's more, the latest iteration of this core – literally the heart of the Exelyx operating system – includes even more new optimizations. After the initial round of stress testing, the new features present in the core seem to be solid overall, however there are a few minor issues with instruction accuracy and the like. While these will be overcome with some good old fashioned bug squashing, a more serious problem lies in the core's inherent design. Previously, the designers of the kernel chose to go with the x86 instruction set for it's ubiquitous nature and widespread availability. This design choice was known to impose a tangible loss in execution speed, but with several new optimizations, it was believed that this could be balanced out once again. After speed testing the new core, however, it is apparent that this will be more significant problem than initially believed. The obvious solution would be to choose a different native instruction set which is more highly orthogonal, which would lend itself to shorter opcode-decoding times. However, after further consideration, a different approach was chosen which will retain [and ideally even further] the speeds achieved with former kernel cores, and yet retain the high level of instruction set compatibility with the widely available code base of the x86 family of processors. This new direction will start with a refined, highly orthogonal update of the previous Exelyx instruction set as it was used in the series 1 kernels. This will allow for the highest available execution speeds and easy tweaking and updating of the kernel and its native opcodes. "But wait! Isn't this totally undoing the point of the last several months of development and the big deal you guys made about picking a new instruction set?" you say? This humble webdude's answer is: "Well, not really." Stopping at this would in fact negate the direction the developers are trying to go with the new kernel... and pretty much leave you with just a new release of the old series 1 kernel. Definitely not how things should go; you'll be glad to hear that - thankfully - there's more. To keep the goal of being able to reuse the masses upon masses of already-existing code, the series 2 kernel will utilize a recompiler to translate existing object code into highly optimized Exelyx object code. This will allow developers to continue to use the language they currently use and whichever IDE, compiler, disassembler, debugger, et cetera they have in use now, and at the same time eliminate the critical speed hit incurred from having to decode all the complexities of the instructions on-the-fly. The aim is eventual 100% support for already-written executables. And, if the programmer is so inclined, existing applications could be modified to check for the Exelyx environment and then act accordingly. It this way, programs could be made which act in a traditional manner when in DOS and become full fledged, windowed applications when in Exelyx. Recompilation opens up other interesting avenues, as well. It would be theoretically possible to expand the horizons of the recompilation software as well, allowing translation of more than just one flavor of machine code. This means it would be possible to run multiple programs which were originally written for different processors – not just one specific family – all as native Exelyx applications at the same time. A user could run an application originally written with Intel x86 machine code right alongside a program initially coded for a Motorola 68k chip - as long as the dynamic recompiler is familiar with both instruction sets. And while we're on the topic of the 68k processor, the decision was made to make 68000 machine code the first target platform for the dynamic recompiler, for two reasons. First and foremost, it is highly orthogonal to start with, which will contribute greatly to reducing the coding time of the recompiler. Second, it will allow the adoption of a standard development platform for simple initial applications: enter Easy68k. Written and developed by Professor Chuck Kelly, Tim Larson and Paul McKee, this is an excellent 68000 emulator with an assembly code editor and an accompanying debugger, and can produce .bin files which contain 68k object code. This will, in turn, be able to be executed in the Exelyx environment after recompilation. Using Easy68k as a standard IDE will also allow more people to contribute to the project as they will now be able to write assembly code to run under Exelyx from within Windows, without having to boot to DOS or download and configure a DOS emulator. Implementing these things will be a demanding and time consuming process, but the goal of the Exelyx project does not allow for sloppy, patched, poorly written code. Bear with us as the new developments unfold...
5/2/2011 - Code execution core completed!
The heart of the new series 2 is at long last complete! Today the code execution module was finished and will now begin the customary rigorous round of bug testing. Provided everything tests with positive results, the kernel will be poised on the very brink of release to developers for the start of development of the initial batch of Exelyx applications. This module will be directly responsible for quite literally everything that happens in the Exelyx environment and will be the very center of all work that gets done inside the OS. Stand by for updates regarding stability and feature testing of this new addition to the series 2 kernel's code base!
4/28/2011 - Questions on functionality and MIDI demo.
Over the past few months we have received inquiries about the functionality of the Exelyx software and accessories and figured it would be helpful to clarify some things. First off, many are coming to the site and downloading Exelyx software and reporting that it does not work. This usually occurs when attempting to run the operating system software directly under Windows. Although past versions have striven to maintain Windows compatibility, the Series 2 kernels are becoming more advanced than their predecessors and therefore break this custom. If you need to run Exelyx or any of the demo programs [CD player demo, video demo, etc.] under Windows, you will most likely need a DOS emulator to do the job. An excellent example of one such emulator is DOSBox which you can get here. And this is the actual DOSBox config file we use on one of our Windows XP development machines if you need a guide to setting DOSBox up to run Exelyx software [although you will need to alter the drive letters and/or paths at the end of the file to suit your particular setup]. In development we also use a pair of very old drivers for sound and MIDI support, which can be obtained here as well as in the Downloads section. It is important to note that the proper execution order and settings are necessary to ensure the system is properly configured, as shown at the end of the aforementioned DOSBox config file. In other news, another piece of the retooled sound kit is showcased: the MIDI demo. Just to make life easier, we included both the sound and MIDI drivers, as well as the DOSBox config file and a collection of sample MIDI files to test it out. You can check it out in the Downloads section.
3/18/2011 - New look for the Exelyx HQ site.
Everyone's favorite project HQ is undergoing several small layout updates as we switch over to OpenOffice web publishing software. We hope everyone enjoys the new design!
1/7/2011 - More additions to the CD catalog and an added feature to the Display Module in the works.
Contributions to the CD catalog continue to come in! The CD interface demo contains the latest update of the file, and is available as always in the Downloads section. Also, support for reading .png format graphics is being added to the Display Module.
10/4/2010 - Sound Module CD interface demo.
The basic functions of the sound module have been written, all that remains is further optimization and integration. The audio CD interface is complete, and could not have been possible without contributions from Marco Koegler and Toshihiro Horie. A demo of the audio disk interface has been compiled and is available in the Downloads section. If you'd like, feel free to take it for a spin! Keep in mind it is only a demo, but the basics are there. You can use the arrow keys to change tracks and seek within a track. When you're done, press escape to leave the demo with music playing, or enter to stop the track and end the demo. The coders of the demo have also added a rudimentary disk checksum system, which creates a file called "checksum.txt" containing the hexadecimal identifier for the disk currently playing. When you begin playing a disk, the demo will automatically check the included catalog file ["catalog.txt"] to see if data for this CD exists and if so, it will load and display the track names, album name, year, and artist as found in the catalog file. We're also trying to grow the CD catalog as much as possible, so we invite you to add listings for all the CDs in your personal collection and email the resulting catalog files back to us! For an idea of how the demo stores this information, you can check out the existing CD catalog file which contains information for a handful of CDs. In final version of this system, fields will be added to hold the name of the person who contributed the album information to the official database, so if you'd like credit please include your name or other identifier so that we can give credit where it's due. We're looking forward to your contributions!
9/15/2010 - Work underway on Sound Module.
A new module was announced which is to become part of the new kernel release. The Sound Module will add support for asynchronous playback of standard 8-bit wave sounds in mono or stereo with complete volume and mixer functionality as well, including panning and fading of sounds. Despite the limitations to sound quality one would assume the 8-bit format would impose, the clarity of the demo was surprisingly crisp and had decent bass response as well. The module demo also showed a test of MIDI synthesizer support, and a collection of routines to interface with the CD playback features of CD-ROM drives will be added soon.
8/26/2010 - Display Module set to be split.
Plans were made today to split the Display Module code into a series of individual managers. Instead of having a single (quite large) module which handles all color depths, there will be the 8-bit Display Module [DM8], the 16-bit Display Module [DM16] and the true-color module which can handle 24-bit pixmaps [DM24]. The first of these to be completed will be DM8, which will provide a basic stable graphics platform for Exelyx. Afterward, focus will shift to DM24 since it will be the most widely used, followed by DM16 at last.
3/23/2010 - Update to the Display Module in the works.
It was announced today that some additional features of the Display Module are scheduled to become a reality sooner than planned. Thanks to the JPEG Encoder version 2, coded by Artelius, the ability to save and load images in JPEG format will be added to the module. The provisions in the JPEG format for saving at differing quality levels will be available. Work is also underway on an inverse rotation/scaling transform routine, giving the module capability to do smooth spinning and zooming on pixmaps.
2/21/2010 - X86 disassembler still in progress.
Updates have been few, but work is still underway on the x86 disassembly application.
10/26/2009 - Progress made on x86 disassembler.
Before any major work can be accomplished on the Exelyx instruction execution core, a comprehensive disassembler must be completed which can take x86 object code and translate it into assembly code, similar to the old DEBUG tool included with many DOS systems. A working model of this has been developed, and is being pushed toward completion. Images are available in the Screenshots section. As you can see, most of the basic instructions have already been implemented but some work remains before completion.
10/5/2009 - Decision on future Exelyx instruction set.
A conclusion has been reached on the issue of the Exelyx kernel instruction set. Although, due to the speed hit which is incurred, the authors of the kernel initially wanted to stay away from instruction sets which involved manipulating individual bits to execute instructions, they settled on using the Intel x86 architecture due to several reasons, the foremost being the reusability of code compiled for other x86 platforms such as DOS. This means that development of fully functional applications for the Exelyx platform will not be held up by the lack of an adequate compiler as has happened with the kernel series 1 releases. The move to x86 will, in essence, turn the Exelyx kernel into a DOS multithreader of sorts, allowing developers can reuse code they have already compiled with their favorite language and IDE and have the programs execute directly on the Exelyx kernel with the added benefits of multitasking, virtual memory and other trademarks of a modern operating system. Under this premise, traditional DOS apps will run as originally coded and programs designed to exploit the GUI and other features of Exelyx will be able to do so as well. Since all interfacing with the Exelyx GUI will be done via memory and/or interrupt calls, an application could also be designed in such a way so as to allow it to behave one way under plain DOS and behave as a Exelyx app while running with Exelyx.
9/7/2009 - Instruction set changes.
Recently the developers of Exelyx have agreed that it may be beneficial to change the Exelyx instruction to a clone of that a specific microprocessor or processor line. This would not only streamline developing, but would eliminate the need for a specific compiler since anything compiled for that chip would run natively in Exelyx. The instruction set that will be adopted will be from a platform which uses whole bytes to describe registers, memory locations, and the like. Among the platforms being considered are the DragonBall processor, the ARM series, and Motorola's 68K family. We are initially not researching the Intel 8088 and others which would involve splitting the instructions into individual bits in order for the kernel to determine what to do. So in short, we want your vote. Which instruction set should become the standard for Exelyx development? Let us know what you think.
5/22/2009 - The Exelyx Development HQ moves again!
Well, not only has the Development HQ moved its physical location, but now its web location is changing as well. Due to Yahoo's decision to shut down Geocities, the project's site has been moved here to Tripod.
3/14/2009 - Rewrite of Memory Module scheduled.
The Memory Module, in its past design, had little more to do than keep track of which memory blocks were allocated to which applications, and depended on the underlying memory driver to perform the actual allocating, releasing, and compacting. In the scheduled rewrite of the Memory Module, it will take over all these jobs, allowing a multitude of extra handles to be allocated. Even under pure DOS with the standard XMS driver, handles eventually reach a short supply. The first release may have an upper memory limit of 64MB, but this will quickly be changed to the full 3.5GB that Exelyx kernels past could work with.
2/14/2009 - New instruction set released.
Today marks another significant step in the development of the series 2 kernel. The new instruction set list has been completed and added to the Kernel 2 Series Specifications Document. The 61 instructions currently listed are definite at the time of this writing, but more may be added as development continues.
2/8/2009 - Work on the kernel resumes.
Even though the Exelyx Development HQ is not yet settled into its new location, this hasn't stopped everything. Work began again recently on the Memory Module for the new series 2 kernel, and is scheduled to be completed by the end of the month.
1/9/2009 - The move begins...
The Exelyx Development HQ has begun the moving process. Oh, for a simple MOV instruction to work in this case! After taking the majority of the month of December off for holiday activities, the staff will begin to assemble a collection of new hardware which will form the backbone of the new testing and development environment. Granted having to move the entirety of the Exelyx HQ will take some time, especially since it's being done in the middle of Winter, (good timing on our part, eh?) but the end result should be well worth it. On completion, some time in the next few months, development will get up to speed, and return to the regular schedule.
11/1/2008 - Exelyx Development HQ upgrades.
Some changes are in the wintry air! Over the next month the HQ will be relocating, so if updates to this site become a little sparse, don't worry, we're not disappearing! After the move, the HQ will be getting some new hardware for the explicit purpose of creating a more diverse environment for software testing. New test machines will be added to the existing ones already in use, allowing developers to test the upcoming series 2 kernel on desktops and laptops both new and old. So stay tuned!
10/21/2008 - We have a winner!
Just over two weeks after its release, the message has been cracked! We congratulate an obviously capable programmer known as Artelius, for being the first to obtain the solution to the ESEA encrypted text posted earlier this month. Of course, the challenge was not to see if the algorithm can be cracked, but to see how long it takes to start from scratch and hack the encryption, and the initial run of the Encryption Module fell horribly short. In an email, Artelius states that it took him a mere week to research the code, come up with several algorithms to do the job, refine them, write the final C language implementation, and come up with the winning text, running 12,884,901,888 combinations on three different computers simultaneously before achieving his solution. His findings, as well as those of the other testers will be rolled into the final implementation of the Encryption Module, which will support a more random means of generating keys, using a pass phrase to generate a key, and a key length four times that of the preliminary version, as well as more variance on the encryption algorithm. This should make it a tad more difficult to hack, so the challenge isn't over yet!
10/18/2008 - Yet another module added to the series 2 lineup.
That's right, another feature is added to the mix. This new module, currently known as "ascmath" is a system by which the computer will be able to work with extremely huge numbers. The API accomplishes this by treating numbers as ASCII strings, and mathematically manipulating them one digit at a time, much as one would do if performing the calculation by hand with the good old-fashioned pen-and-paper method. To date, the module supports addition, subtraction, multiplication, finding powers of numbers, all with negative, and floating point numbers as well as the obligatory positive ones. Bugs are being worked out which crop up if mathematics are performed on a negative floating point number, and of course division will be included as well. Upon completion, the current code will be speed optimized before being incorporated into the kernel. The code was found to be spot on under a variety of numerical conditions in recent tests. So much so, in fact, that the preliminary code was used to accurately calculate the total number of possible combinations required to crack the ESEA encryption method's key strength of 512 bits, as mentioned in the news article below.
10/12/2008 - ESEA remains uncracked.
Here we are, one week after the release of the info on the series 2 kernel's debut encryption technique, and there has yet to be a successful attempt in cracking the message! During this time, however, we have not been resting idly by. The creators of the ESEA technique state that the security of its keys is such that a brute force (trying every possible key in sequence) attempt at a crack would require 256 ^ 64 combinations. How secure is that, you ask? Well, 256 ^ 64 is equivalent to 65,536 ^ 8, or 4,294,967,296 ^ 4. The final implementation of ESEA for Exelyx will support these 512 bit keys, which raises the bar from it's current form to the ESEA standard, which comes out to a very huge number. What? You want to know how huge? What is this, math class? OK, here goes. The expression 4,294,967,296 ^ 16 equates to 13, 407, 807, 929, 942, 597, 099, 574, 024, 998, 205, 846, 127, 479, 365, 820, 592, 393, 377, 723, 561, 443, 721, 764, 030, 073, 546, 976, 801, 874, 298, 166, 903, 427, 690, 031, 858, 186, 486, 050, 853, 753, 882, 811, 946, 569, 946, 433, 649, 006, 084, 096. Seriously. We literally did the math on this one. Which, needless to say, is far beyond the sphere of computational feasibility.
10/5/2008 - Series 2 kernel to support data encryption- your help is requested!
A new module has been added to the list for the series 2 kernel. The new Encryption Module will enable basic encryption support for any block of data in an XMS handle using the ESEA (Enhanced Security Encryption Algorithm) method. The details were laid out in an introductory cryptography text written by Mercury0x000D:
"Normally when you use a password, the computer just stores it and sees if what you enter next time matches what you told it the password should be. But things would be much more secure if the computer actually encrypted the plaintext data based on the password you enter, morphing it into a different piece of data entirely. So if I have a special message, like THE WORLD IS FLAT, and I have a password, like BOB, the computer could do a mathematical formula on the letters to make a numeric password from it. In this case we'll use the number of letter, so BOB would be 2-15-2. Then we do a formula on the numeric password, so 2-15-2 would maybe become 2 - 15 + 2, which would give us -11, so we strip the sign, and get plain old 11, and 11 in binary is 1011. Next we could rotate the bits left once just to confuse prying eyes further, getting 0111. Now we take the rotated binary sum of the numeric password and get 7, then finally we go through every letter of the message and perform a math function with that letter's number and the password. So THE WORLD IS FLAT might become something like BRW MDPOE VP MUOE. Then, since we have everything down to numbers, we could checksum the final message and give this checksum back to the user. So if you typed in the password BOB, the software would work its magic and give you back a number, like a confirmation password, and you'd need the original password and the number generated by the software to unlock the message. Just to make things harder still, the checksum given back could include other information, like the length of the original message, things only its intended recipient would know. So then I was thinking... what if this still wasn't enough somehow? The software could be set to run the message through encryption several times, making it further from what it originally was each pass through, maybe even using a different password and checksum set each time. We could even perform math on the encrypted message too, and include that information in the checksum also. This method would have no stored password to be discovered by anyone. The message becomes its own password, of sorts. You may think nobody has things on their computer that need that much protection, but what if it's the other way around? Maybe nobody has things on their computer that need that much protection because they know that much protection isn't available. Until now, that is. This could be used down to the file system level, also, so it could not be bypassed. Another thing to consider is the fact that most systems will give you an error if you enter the wrong password and this software will not. So if someone tries to enter a bunch of passwords to guess their way through your security, they'll all simply work just fine, producing garbage if wrong. So yes, the hacker would get a plaintext message, but would be unable to tell if they got the correct one."
Okay, so it's not 1024 bit private key encryption, but it's complex enough to be useful. And to test it out, we are asking for your help. Interested? Here is a message that's been encrypted using a preliminary version of ESEA which does not yet implement password based encryption. The hexadecimal values in the message file represent the bytes of the encrypted data. If you're into cryptography, or know someone who is, and you think this cipher can be cracked without the key being provided, give it a try! We will be listing the results of any successes on the site in the near future, and using this information to further refine the algorithms used. If you need help, here is the source code for this pre-production version of the Cryptographic Module.
10/1/2008 - New function calling method in series 2.
All of you who have researched the original kernels are probably familiar with the KINT functions. Short for kernel interrupt, these functions comprised the Exelyx API, and will still be included in the series 2 kernel so that previous apps won't break. However, the new kernel will support having its internal functions called directly by a program executing a direct jump to it's code. The functionality for direct address jumping will be accomplished through a new opcode, DJMP. And how will application programmers know where the kernel's routines lie? After all, their internal location will vary widely from version to version. The Exelyx Function Header, a small .asm file that can be included in any program that calls kernel functions, will be created to address this issue. When the compiled app is run, the header's code will execute before the program containing it, at which time it will determine which version of the kernel it's running atop of and set the proper addresses to a set of standard pointers, thereby enabling programmers to only concern themselves with the function labels (actually variables that point to the function's address in base RAM) and bypass the old procedure of calling software interrupts that slow down program execution. If the program is being run on a version of the kernel that does not support direct address jumps (e.g. the entire series 1), it will trigger an error message.
9/18/2008 - Text Module finished today.
Today one more feature module is added to the downloads, marking one step closer to the series 2 kernel's completion. After performing a (somewhat lengthy) debug on the source (remember, kids, always check for nil handles! :]) the module is available for your review in the Downloads section. The Text Module provides routines for searching strings, returning certain words from text blocks, replacing entire ranges of characters and more. Next up: completion of the Memory Module.
9/15/2008 - Low memory sluggishness be gone!
The Text Module nears completion, and the Memory Module has seen several improvements, which bears mention of a major new feature announcement for the next release of the Memory Module: VRAM allocation. With this feature in place, the Exelyx kernel will automatically use excess memory on the system's graphics card to function as usable application-accessible RAM. For users with higher-end video cards, that could mean a quite sizeable chunk of extra memory to have available. Also, if anyone finds themselves needing to run programs on a machine with no XMS at all, the kernel will be able to adapt to that, too, by using this feature which is slated to debut in the second release of the series 2 kernel.
9/2/2008 - Hardware Module finished.
The Hardware Module was completed this week, bringing the overall project development to roughly 40%. It includes mouse support, and some other handy routines for querying the disk drives and such. The source for this module has been made available in the downloads section, along with that of the File Module, which has been done for some time.
8/31/2008 - First look at a piece of the Kernel 2.00 source code!
There have been several requests for a sneak peek at the innards of the new Exelyx kernel, so beginning today a new section is available in the Downloads area. Right now only the new Display Module code is available, which provides complete VESA support, shape drawing, and pixmap manipulation for the series 2 kernel. As more modules are completed they will be posted in this section, so check it out and get your hands on the latest in Exelyx development!
8/26/2008 - Kernel series 2 specifications document released.
The past months have seen a host of changes to roll into kernel 2.00, as well as vast progress on the kernel's inner workings. So how do you keep up with all the latest developments without having to sift through the News section all the time? You simply check out the newly released Kernel 2 Series Specifications Document, which is available here.
8/22/2008 - Text Editing Module announced.
As if there weren't already enough features in the new series 2 kernel to render it superior over its predecessor, now it has been announced that a collection of text editing routines will be included as well. The previous kernel series had nothing of the sort, so this is a welcome addition to the kernel 2.xx plans by developers and users alike.
7/30/2008 - File Module completed.
The File Module was completed today, and awaits its addition into the series 2 kernel's source. The demo is able to open multiple files, associating each with the thread ID of the process that opened it. When the thread closed, the File Module simply closes all its associated files with a single function call. No error messages, no lost file pointers, nothing of the sort. On a more impressive note, the module created and manipulated assigned drives (e.g. as you would with DOS's subst command) and its most special feature yet- the ability to rename open files. This may sound pointless at first, but its value becomes apparent when you're wanting to rename a file or folder while the system's using it without bringing everything to a grinding halt.
7/17/2008 - Progress update on the Display Module.
After approximately three months of coding, the Exelyx Display Module is finished! The result? A full-featured, double buffered, fast blitting image machine. Every promised feature in the video category is now a reality, making the visual capabilities of Exelyx rival those "other" operating systems. The testing demo was more than impressive, showing off images loaded from files in three formats (BMP, GIF, and PCX) being scrolled, blitted and color cycled. The time for the image to get from a pile of data on the hard drive to a coherent picture on the screen was decent for PCX files, much better for GIFs, and absolutely phenomenal for BMPs. The demo effortlessly loaded a 45 megabyte uncompressed BMP at 8000x6000 resolution in about seven tenths of a second. It then proceeded to allow the user to scroll about the image, with frame rates topping out at 54 fps at 640x480, 35 fps at 800x600, and 21 fps at 1024x768. The heart of all this is a highly efficient blitter routine which allows Exelyx to manipulate pixmaps entirely in XMS, breezing through millions of pixels per second. Although it currently only supports 8 bit color, future releases of the series 2 kernel will support 16 and 24 bit color as well.
You've seen it mentioned in the Black Ice screenshot. You've wondered what new code powered the multiple operations shown in the Red Delicious pic. And now, brought directly to your computer monitor, is the straight info on the new piece of work known as the Asynchronous Operations Manager. The AOM works by hooking the kernel functions used to copy files and folders, and activating itself only when there's some file operation that needs performed. It is important to note that it does not stay resident in memory, consuming precious CPU cycles while it waits for you to need it. Instead, it uses a new mode of program loading introduced in the kernel 2 series in which a program is loaded, does a job, then terminates but leaves its code still accessible. This is nearly identical to the old DOS method of loading a TSR program, but thanks to the Exelyx kernel's totally protected memory architecture, there aren't any of the hang ups commonly associated with the methods of yore. Ok, now for the real world break down: You're happily using your AOM equipped Exelyx workstation one day, when suddenly you realize that you forgot to do a backup lately. No problem, you think, I'll just do it right now. You drag your documents folder to your backup drive, and a small window pops up indicating that the AOM has sprung into action. No pointless little animations, no perpetually incorrect estimates of exactly how many years it'll be before this procedure's done, just a simple window with a progress bar that begins ticking away as your files are copied to their destination. Suddenly you remember that you need to backup another folder too. Will you have to wait until the current copy operation is completed? What is this, 1983? Of course not! You drag the other folder to its new home, and notice that no new window appears to tell you that the second folder is copying also. Instead, the existing copy progress window is lengthened, and the new copy process is added to it. Clean and simple. Two massive folder copies, two progress bars, one little window. Then you reason, I guess I can delete my old backup folder, so you go to your backups folder, select your old folder, and click delete. Once again, no new window appears, only another line in the existing AOM window. Pleased with the capabilities of your computer, you decide to proceed writing the new BASIC compiler that you intend to contribute to the Exelyx project (hey, give me credit for trying, okay? :D) then you smack yourself on the forehead for forgetting to add the date on the folder you're copying your backup to. Here's one other small detail that would give other operating systems a headache. You navigate to the target folder, and click rename, then add the date. As you hit the enter button, you realize that, since the OS is copying to this folder while you're attempting to rename, you'll probably be greeted by an error message. To your surprise, though, no error window appears, and the system pleasantly accepts your name change. Why? The trusty AOM not only hooks the functions for file copying, but also the renaming functions, so that it can use the new name you specify seamlessly without losing step. Awesome, huh? Yeah, we thought so too.
6/30/2008 - New windowing environment unveiled.
At last, the Screenshots section has some new pics! Of what, you ask? A new windowing environment whose details were released today. It's called "Black Ice," and not only will it help you get the most out of your computer, just like its namesake implies it'll look pretty slick while it does the job. Most impressive is the new 'open desktop' approach, which leaves your entire monitor virtually free and uncluttered of any menus, task bars, and any other desktop ornaments, save one solitary tab in the upper left corner of the screen. Park your mouse over it for a moment, and it expands outward to show you all currently running tasks, all open windows, the date, time, and other vital stats about your system, such as background tasks and the like, all grouped by classification. Our overall impression... awesome. Even more awesome, it's been scheduled to be included in Exelyx Package 1 upon its release.
6/20/2008 - Release date of new kernel pushed back.
The long awaited Exelyx kernel version 2.00 is nearing completion, however the brains at Exelyx HQ are pushing back the deadline for release to further test and optimize its internal workings. Changes have also been announced concerning one of the basic capabilities of the new kernel. The first version of kernel 2.00 to be released (now scheduled for an unspecified date in 2009) will be a complete implementation of the kernel, sans multitasking. The reason for doing this is to aid developers who wish to test the basic structure of their applications in a single task environment. Shortly thereafter, version 2.01 will be released in its final form.
4/19/2008 - Code modules in place in kernel 2.00.
So far, the Hardware Module is completed, which takes care of interacting with the computer's devices. The Display Module is almost complete, only needing some minor tweaks, as are the Memory Module and the Resource Module.
It is being announced that the series 2 kernel will support the same opcodes as its predecessors. What this means for developers is that the existing code they have running under the kernel betas will work without modification under the new kernel specification. However, the instruction set will be modified to include new opcodes to support more versatile memory handling and some other features which will result in more efficient and compact code.
Specs were released today for the kernel 2.00 Display Module. It will support some pretty cool stuff, such as long-promised VESA support, multiple display pages which can be used as a double buffer for smoother scrolling, creating and manipulating pixmaps in XMS or even VM, saving and loading individual palettes, and the ability to save and load BMP, GIF, or PCX images. The ability to load JPG images will be added in a future release of the kernel 2 series, as well as the ability to quickly rotate and zoom pixmaps.
3/28/2008 - Memory Module near completion.
Work on the Memory Module for kernel 2.00 is almost done. It will now support virtual memory and auto release for all allocated handles. The Memory Module accomplishes this by keeping notes on which threads allocate which handles, and when a thread terminates it only takes the system one simple call to have the Memory Module release all the handles in use by that thread automatically. This approach will help reduce the occurrence of memory leaks and the like.
3/16/2008 - Details of new kernel released.
Work on the next Exelyx kernel is well underway, and approximately half of the development plan is completed. The Resource Module specs have been determined, as well as those of the new Memory Module and Display Module, complete with a set of functions for drawing lines, circles, loading images from files, pixmap manipulation, and more.
1/15/2008 - No more betas... the official first release of the kernel announced for next year release!
It's official! The next kernel released for download will be the finished product... the official first release of the Exelyx microkernel. Yes, to answer your question ahead of time, that means that development has proceeded to the point of near completion at Exelyx HQ. Within the next year, the current (and final!) kernel beta is expected to become obsolete, and be replaced with the long anticipated kernel version 2.00, bringing an end to the "Step One" phase of development. An updated version of the kernel technical manual is scheduled to follow the new kernel's release shortly thereafter. This kernel release will incorporate all the features long promised by past betas, will have the beginning of an application development API, and will most likely achieve its target speed of over 200,000 loops per second, as measured by the Speed applet. Currently, the kernel is undergoing further optimization and debugging of the thread execution core, which will be followed by a brief bug testing period. So, in short, the wait is almost over ... the countdown begins today!)
1/3/2008 - New kernel model announced... the kernel 2 series!
Development of the Exelyx kernel has seen sweeping changes in recent weeks, pressing it far beyond its humble beginnings. The current kernel version is the closest it has come to being a solid work, but at the same time the successive developments rolled into each new beta release have proved its inadequacies. Now is a time for change. With pleasure, we present to you a new design for the official release of the Exelyx kernel, which will allow developers more room for making awesome software for Exelyx. The next release of the Exelyx kernel will utilize this new model, which calls for the addition of floating point and integer registers, expansion of the universal registers already existing in the kernel, improved memory handling, as well as the implementation of several features not yet offered by the current kernel betas, namely fully protected memory, a drastically increased thread limit (breaking the current beta's 32 thread barrier) and virtual memory. Also available will be a fully redesigned code instruction core which will implement a set of new instructions for more efficient code, and optimize thread execution by using a large object code buffer in base RAM to execute hundreds of instructions per cycle, as opposed to the method used by today's betas, which run each instruction out of XMS directly as the thread does its work. This alone should provide even more speed out of the kernel due to the simple elimination of all the overhead incurred by constantly reading instructions out of XMS. One sorely missed feature, however, will be the built-in command prompt, which will be added once again to the project in the future as a stand-alone Exelyx application.
12/20/2007 - Instabilities found in kernel 1.40.
After a short round of testing, kernel version 1.40 has been found to have problems associated with the call and mov instructions. This is a result of the major modifications to the kernel's inner workings, which allowed it to achieve the phenomenal speeds that it was created to run at. The problems are scheduled to be fixed in the next release, which is expected to be completed soon.
12/16/2007 - Benchmark results: New kernel version hits record speeds.
The Exelyx kernel may be pretty stable, but speed has historically not been its strongest point... until now. The newest kernel beta, version 1.40, has far surpassed its predecessors, as shown in the following benchmark table. Kernel 1.40 boasts a speed gain of slightly over 75% compared to the previous release. It also weighs in as the largest kernel to date, with over 6,700 lines of source code... that's approximately 91 pages! Moreover, future releases are expected to push the envelope even further, resulting in a kernel that can execute well over 150,000 loops per second. The following results were achieved by running Speed under each kernel version to determine how many loops per second it can process on a mid range PC:
1/20/2007 - Exelyx goes totally open source with the GNU GPL License!
If you've been following this website for any length of time, you probably already know that the Exelyx project has always been open source when it comes to all applications written for it, but the kernel itself and the PAC compiler have always been closed source. Well, to mass approval, the kernel .zip packages now include the PowerBASIC source code for the kernel itself. Now you, too, can contribute on a deeper level to the Exelyx project... just download the source and have some fun! The move to license the Exelyx Kernel with the GPLv3 provides the general public with a means to get involved with the project and (hopefully!) further its development. The full text of the GPL is now included in every package downloaded from this site, but if you're curious the text of the GNU GPL is also available here at the Free Software Foundation's website.
1/1/2007 - New look for the Exelyx website.
The web wizards in the Exelyx design group got together one day over lunch and, having exhausted all other valid points for conversation, decided to contemplate revamping this, the project's humble homepage. Yes, they were really, really, really bored. With that said, they hope you like the new, streamlined look which now includes a "Screenshots" section, the best-selling (okay, maybe not quite) Exelyx back-story, and this wonderful new "News!" area, among others.
12/15/2006 - PBASIC compiler under development.
Due to slow progress of someone completing a BASIC compiler, I have decided to finally resume development of mine. While not much has been done yet on it, progress is being made, so feel free to download it and see what you think and/or contribute your ideas and efforts to it.