The Mercury Letters
A blog. About things.
Home
Select a topic/tag:


1/12/2025 - Additional double-buffered goodness.

Now that Easiest68K has double-buffering, the EASy68K demo programs Flames.S68 and Swarm3D.S68 are now fully functional. Woot! We're on a roll now! spin.gif

It is so nice to see the last three months of work starting to really come to life. fantasy-frankenstein.gif

1/10/2025 - Some fireworks for the new year!

I managed to get Easiest68K migrated over to my new CinnGL library, finally enabling me to easily implement the double-buffered effect that EASy68K offers. And, I don't know about you, but I certainly cannot think of a better way to ring in the new year than some double-buffered fireworks!

1/9/2025 - Introducing CinnGL!

What was previously codenamed "Pxl.js" is now the Cinnabar Graphics Library, or CinnGL, for short. And, because I know people will wonder, it's pronounced "single". idea.gif

Now, with that outta the way, it's time for news! lol

About mid-way into development of my new JavaScript graphics library, I paused to take stock of the progress. I had all the basic primitives working, such as points, lines, rectangles, circles, ellipses, roundrects, and triangles. Not bad! But there was something missing...

Filled shapes! I needed filled shapes. Making code to draw filled rectangles is easy, so I did that one myself. I was able to locate code in an open-source graphics library which illustrated the principles used to draw filled circles and roundrects, and code for doing ellipses wasn't too hard to find either. But triangles. Triangles! That was a tough one. I couldn't wrap my head around which method would be best suited to the task, and online examples were seemingly sparse... until I found the blog of Gabriel Gambetta.

He has a method for drawing filled triangles which is both powerful and elegant, which was a great find. It sorts the three defining points of the triangle in top-to-bottom order, then uses an interpolation function to get a list of points for both the left and right boundaries between them, all the way down the triangle. After those steps, drawing the shape is as simple as rendering each line subsequently from top to bottom. At less than 40 milliseconds for 1000 triangles on my machine, its speed was good - but I knew I could improve it further. While drawing each line to the screen, the algorithm was drawing each pixel one by one. yikes.gif That's a lot of function overhead, which simply will not do.

The straightforward nature of Gabriel's code made my optimization path fairly direct, and the basis lies in this: when drawing a line on a cardinal or intercardinal axis (that is, horizontal, vertical or diagonal) it becomes unnecessary to perform many of the calculations which would otherwise be required. Drawing in such a manner means you no longer have to worry about either interpolation or rounding; from the start of the line to its end, you can simply add a constant amount to the address of the previous pixel with no recalculations between them, allowing performance to improve dramatically. Using this principal, I had already created a pair of functions, CGLLineHorizontal() and CGLLineVertical() which can draw such lines with blinding speed, two to nearly four times as fast as the general Bresenham algorithm, depending on conditions, and optimizing the filled triangle algorithm was a perfect application for this kind of efficiency. What previously took 37.2 ms for those 1,000 filled triangles now takes only 6.8 ms - less than a fifth of its former duration!

While I was on an optimization bender (lol) I decided to continue with another sore spot: filled circles. The code I had already employed to do the job turned out to be far from efficient, and I needed a better solution. In my search, I came across this page on Stack Overflow, featuring a nice collection of possible replacements for my slow code. But which was the fastest? (Cue my cover of Tenacious D: "This is the fastest and best filled circle drawing algorithm method in the world. Tribute." lol) User AlexGeorg had already done a speed comparison, but those numbers don't reflect JavaScript performance and, logically, his chart does not include all the algorithms posted by users after he made it. I decided, therefore, to benchmark some the most promising candidates myself. I began by converting their code to JavaScript. Next, I benchmarked them by drawing 1,000 circles each, logged the best times I observed, and then began looking for areas for potential optimization.

In JavaScript, much like any other programming language, it sometimes helps to pre-calculate an operation and save the result in a variable to avoid having to recalculate it repeatedly... though not always. The overhead of saving the result of a calculation to a memory area, as opposed to just making the calculation and directly using the result, must be less than the effort required to generate the value in the first place to be effective. My general rule for speed-critical sections of JavaScript code is, if you're going to use the result of a calculation more than once, and it's a CPU-expensive operation, then it makes sense to save the result to a variable for re-use. If, on the other hand, you only need to use the value of the calculation a single time, or it is an extremely simple operation like, for example, a shift, it is often more efficient to simply use the calculation directly in the spot it's needed without saving it to a variable first. Why? I guess that's just one of the quirks of JavaScript being an interpreted language and some of the undoubtedly convoluted hoops through which browser authors need jump in order to optimize their code. I used these optimizations sparingly, therefore, only adding them when it resulted in a measurable impact to the final performance. I also took advantage of the above-mentioned speedup from using CGLLineHorizontal() and CGLLineVertical(). Additionally, instead multiplying a value by two, I used a single left shift. The result? Here's the rundown:

Original Optimized
User AlexGeorg's refinement of Daniel Earwicker's "DrawCircleBruteforcePrecalc" algorithm.
Original Optimized
User Arphimigon's method
Original Optimized
The algorithm by kmillen.
Original Optimized
User palm3D's contribution.
Original Optimized
A method by Daniel Earwicker.

And, at last, the timing results for the 1,000 circle test:

Name Time, Initial (ms) Time, Optimized (ms)
AlexGeorg 39.79999971 7.59999990
Arphimigon 71.59999990 7.29999971
kmillen 75.09999990 7.40000010
palm3D 44.40000010 7.89999962
Daniel Earwicker 41.79999971 7.6.80000019

First off, I gotta say... wow. What a collection of clever implementations! It was hard to pick a winner in such a neck-and-neck race, especially when factoring in the timing variance due to multitasking in modern systems. It is worth noting that Daniel Earwicker's algorithm actually managed to pull test results as low as 6.7 milliseconds on occasion, however it also got results above the average I posted as well, far into the 8.x millisecond range. And since it gave higher-than-average results more consistently than lower-than-average ones, I had to base my judgement upon the numbers which I observed most often. The fact that it was able to yield a result under 7 milliseconds at all was curious, though, since JavaScript's built-in Math.sqrt() function is used, and calculating square roots is not a fast undertaking on most CPUs. I suspected JavaScript internally uses a lookup table to perform its square root calculations, so I modified Daniel's code to create its own lookup table and use that instead of Math.sqrt(), which indicated that my assumption is likely correct when it actually performed slightly worse than the original. While a lookup table may be in play here in JavaScript, this most certainly will not be the case on other systems, namely the one which this technology will ultimately drive - the Handpower PDA. For this reason, I decided against choosing this algorithm to replace my existing one. Since Arphimigon's method is the only one which was able to consistently achieve the low speeds that it did, I have chosen it to be the algorithm powering CinnGL's circle drawing. Nice work, man!

If you'd like to benchmark CinnGL on your own machine, feel free to play with the new CinnGL Demo!

1/4/2025 - A deep red new year! winking51.gif

I wrote last year (Still sounds odd, no? lol) about Vermilion, a virtual machine of sorts, which is to serve as the foundation for several subsequent projects to come after it. In the time since then, I've been busy working away on this key piece of technology, and have some exciting news to share.

Initially, I planned to design Vermilion around the 68000 instruction set and, to that end, I began work on a simulator which could run that processor's object code. If you've ever used EASy68K, that is roughly for what I was aiming. I had started a similar project over a decade ago, back in the PCOS days, and the basics of that code served as the basis of this new simulator. Back then, however, I had only my own observations of EASy68K's behavior to guide me. Now, there exists the 680x0 Testing suite by Tom Harte which provides over 8,000 tests for each of the 68000's instructions - an invaluable resource when trying to nail down all of the processor's intricacies.

I worked through October and November to build out instruction compatibility, with the testing suite helping me make quick work of implementing each one. All was going smoothly until I came upon an instruction for which I couldn't quite get the logic: ABCD. Its function is to add two BCD numbers and store them in the destination. The only problem was that one of the tests in the suite specified a certain result should be 0x397C7104 but, just like EASy68K, the result obtained by my code was 0x397C71A4. What gives? Enter the AnyCPU Forum. Some long-time readers may remember this place as where I made the initial announcement of the EPiC project, and I am happy to say that it has proven to be just as much of a valuable resource now as it was back then. I started a thread there about my issue and waited, hoping someone would be able to shed some light on what was going wrong. And that they did! One of the long-time members, known as BigEd, re-posted my issue on another social media site where it was picked up by a fellow from Hamburg, Germany who ran the test on his Amiga (thanks!), which also got the result of 0x397C7104. Armed with the knowledge that my code (and, by extension, that of EASy68K) was definitively in the wrong, I set out to find a correct implementation. That turned out to be harder than expected.

After becoming fed up with troubleshooting on my own, I started scouring the internet for all the existing open-source 68000 emulators I could find, poring over their source code to see how they implemented this instruction. I was able to determine that each used one of only three basic implementations for the ABCD instruction:
Easier68k n/a https://github.com/Chris-Johnston/Easier68k
Moira Method B https://github.com/dirkwhoffmann/Moira
Moo68k n/a https://github.com/dd86k/Moo68k
Musashi Method B https://github.com/kstenerud/Musashi
Sim68K Method A https://github.com/ProfKelly/EASy68K
Tricky68k n/a https://github.com/shysaur/Tricky68k
WinUAE Method C https://github.com/tonioni/WinUAE
n/a = Instruction does not appear to be implemented

I compared each of these three prevailing implementations, converting the algorithm used in the original code to JavaScript, my language of choice for this project. Here are the results:

Method Tests Run Tests Failed Success Percentage
A 8064 20 99.752%
B 8064 58 99.281%
C 8064 0 100%

These results surprised me: Method B, by far the most popular method used among the projects I evaluated, actually performed worse than EASy68K's own technique, Method A. And the only method to successfully nail each and every one of the test cases supplied in the suite was that used by WinUAE, Method C. This means that my simulator will pretty much be second only to WinUAE in 68000-accuracy. Not bad!

With instruction compatibility out of the way, it was time to move on to other features, like running actual programs. I began work on the API used in EASy68K so that some of their example programs could be run. After a few more weeks, I had most of the most commonly-used text and graphics functions implemented and working - but then ran into yet another issue: smearing.

Oh, JavaScript... you're such a powerful language, yet sometimes so... so... obtuse.

HTML offers an element called a canvas, which is great for drawing arbitrary shapes in a window - perfect for simulating the output window a'la EASy68K. As it turns out, however, drawing with JavaScript leaves a bit to be desired. Most of its drawing functions work just fine, but lines... hooo, boy. Lines.

When animating simple objects on screen, a common technique used in the old days was to draw the object twice - once in the background color to effectively erase the object from its old position, and once in the new location. Much like the cel-animated cartoons of yore, this gives the impression of movement when done rapidly. Now, since I'm replicating a classic simulator here, I was counting on this effect still being doable through JavaScript's drawing calls. After all, why wouldn't it be? JavaScript is capable of much more advanced animation techniques than those used in the old days. But What I found, however, was not very encouraging.

It seems that this technique only works on lines drawn on a strictly straight axis, be it horizontal, vertical or diagonal. The instant this is deviated from, telltale "ghosting" occurs. You can observe this phenomena here:

A line is drawn in green on a strictly diagonal axis... then redrawn again in black to 'erase' it. A line is again drawn in green on an axis which deviates slightly from diagonal... ...but redrawing it again in black fails to erase all of it.
So, what do? There's gotta be some way to get around this, right?

Nope.

Browsing the interwebs, I stumbled across many suggestions for disabling this "feature", everything from adding a half-pixel to every coordinate in every draw command (didn't work) to the ctx.imageSmoothingEnabled = false method which, although looking promising at first, proved to also be a fail in the end. There was, however, a glimmer of hope.

As it happens, JavaScript has a pair of functions - getImageData() and the complimentary putImageData() which allows the graphical data of an HTML canvas to be captured to an object containing an array of pixel color values which can be written to and read from, much like a graphical memory buffer common to many desktop applications. This would allow one to directly manipulate the image's pixel data, but integrating this with the built-in drawing functions would involve a lot of function overhead which I was not happy with. Avoiding that overhead would require me to create my own suite of drawing functions specifically designed to work with this pixel data array instead of a canvas image context like JavaScript's native functions expect. That would be a slog, yes, and I wasn't planning to get this deep into the inner workings of JavaScript's graphics functions until I begin work on PRIM Online (yep, another project, TBA) but doing this much now would also assist with implementing the double-buffered graphics functions offered by EASy68K. So that's exactly what I did.

It's been temporarily titled "Pxl.js", and it supports a variety of graphics commands including setting individual pixels, drawing lines (Bresenham's algorithm ftw), circles, ellipses and roundrects. While I can't take credit for all of these myself - I gathered snippets of code from around the internet to make some of this a reality - I did tailor all the code used to working directly with these pixel arrays. Heck, there's even a blazing fast flood-fill algorithm based on the code from this page, which is an interesting discussion unto itself.

While the algorithm William details in his article is great (like really great), it does have a couple drawbacks. First and foremost, it's designed to run on a server, not in an individual webpage. I was initially planning to use the code as-is and give credit to William, but this alone stymied that effort. I instead decided to adapt his algorithm as I had with the others in my new library and see how it performed. And, as it was able to easily flood a majority chunk of a 1 megapixel image in as little as 21.5 milliseconds, perform it did! But you know me by now. smiley.png Fast is never fast enough! I set out to optimize the code even further.

I noticed from the get-go that William chose to refer to the current pixel being evaluated by its starting address in the array as opposed to its x-y coordinates. This seemed messy to me at first glance, but then it occurred to me that this was likely done for a very good reason: to speed pixel access by not having to calculate the pixel's memory address from its coordinates thousands upon thousands of times over. Smart! With this shrewd optimization in mind, I looked for other similar areas of opportunity, and found that at three separate points in his code, William uses a multiplication operation to determine the number of bytes in one line of the image. That may seem relatively innocuous at first, however when you allow for the fact that this calculation is performed millions of times over the course of filling the average image, the latency of performing this operation over and over adds up. I added a constant to the function to pre-calculate the value, and ran the tests again. Wow! An average of 300 to 500 milliseconds saved over the course of a hundred runs of the function. Not bad at all! But I wasn't done.

One other thing I noticed was that William uses a two-dimensional array to store the x and y coordinates of each pixel on the function's stack of pixels waiting to be processed. Again, this may seem like no big deal, but given the extra overhead JavaScript adds to an array for each dimension it possesses, I decided to see if there would be any savings from splitting this into two separate arrays - one for the x coordinates and one for the y coordinates. Lo, and behold, there was another 100 to 200 milliseconds shaved off over the course of one hundred runs. Satisfied that there were no remaining sources of major lag, I called the function complete.

While the pixel library is working well thus far, I do have a few more tweaks to do and some graphics primitives to add before it's deployable, so stay tuned!

10/16/2024 - The path forward.

Long-time readers of this blog have no doubt noticed the plenitude of projects discussed here. They doubtless will also have noticed the equally surfeit amount of incomplete projects. Always faced with more ideas than I have time to implement, this is something I have considered on numerous occasions. How does one balance an ever-growing projects list with the amount of time one has to dedicate to them? After some recent pondering (orb not included) I think I have some details worth sharing.

I've had so many projects over the years. Remember PCOS? Exelyx? The Night Kernel? Not to even mention the newer ones, such as Vermilion, Cinnabar, the Weapon Keyboard, Kirbyte, Prim, and LAVA. Or even classics like the nameless handheld computer project which became a desktop computer project (EPiC) which then got rolled back into a handheld (Handpower)?

Yeah. About all those. As disparate as they all may seem, they all share a common thread - they're all incomplete. Some, like Weapon, were lucky enough to at least get brought forth to prototype form, but the majority are still a heap of notes and code snippets, a clutter of half-finished experiments left in disarray. What do I do with that? How do you move forward when, if you dedicate some of your attention to each of your projects daily, you still would be spread too thin to be effective?

You prioritize.

To that end, then, I have been musing as of late upon the major outstanding projects on which I have to work. What constitutes a major project and what constitutes a minor one? For my purposes, I have decided that a major project is one which was borne of a long-standing personal goal of mine, or one which will be significantly useful that it warrants priority completion. All others are minor. That leaves us with:

Major: Vermilion, Handpower, Cinnabar, Weapon Keyboard
Minor: Kirbyte, Prim, LAVA, Night Kernel

But wait, you may say, what are all those projects even for? I haven't even heard of lots of those!

And you wouldn't be wrong. There's a lot that I've come up with that I haven't even announced here. So let's take some time to do that now! But first, a little explanation is in order about my... well... ordering. The major projects are all mainly so designated due to the simple fact that they, once complete (or at least functional), will help me complete the remaining ones.

The first project on the list is one I've never even formally announced - Vermilion. What is it? Let me tell you a little story.

Waaaaay back in the old days, there was a fairly popular little computer. You may have heard of the company who made it, Apple Computer. This cool little machine - the Macintosh - had at its heart a Motorola 68000 processor, which served it well, even evolving into several later iterations to power the latest and greatest version of the Mac. But eventually, Motorola ran into a proverbial wall when it came to upgrading their flagship processor to handle the ever-increasing demands of their largest client when it came to managing the chip's power draw and heat generation. It became clear over the years that a new way forward would be necessary.

That way forward came in the form of the PowerPC processor, an absolutely beastly new chip which could handily beat the venerable old 68K in every metric that mattered: power, heat, and raw performance. But all these benefits came at a price; the shiny new chip would not run the 68000 code upon which the Mac was built, leaving Apple asking the question, What are we going to do? This thing won't run our old code!

Their solution to the dilemma was to write a compatibility layer into newer versions of their operating system to allow the re-use of old code, completely unmodified. Was this a kludge? Sure. Did it work? Yes, it did. And it bought Apple precious time to wean themselves off the old codebase, writing new functions to incrementally modernize MacOS away from the old 68K code, Ship of Theseus style.

Now, one might think that something so bold, so drastic, had to be a once-in-a-corporate-lifetime kind of problem, right?

Nope. Not even close.

Later on, long after migrating all their old 68K code to the PowerPC, Apple again decided to jump ship on their processor, opting this time to go to Intel chips. And once again, found themselves firmly in What are we going to do? This thing won't run our old code! territory.

Later still, they jumped ship again, this time to ARM processors. What are we going to do? This thing won't run our old code! We need an emulator!

The last example - at least that I'll be sharing here - did not, for once, happen at Apple. Palm, maker of the legendary PalmPilot personal organizer, jumped from the 68K-based DragonBall processor to ARM. What are we going to do? This thing won't run our old code! We need an emulator!

These are just four instances of this kind of thing which jump to my mind, and I'm sure there are many more examples of highly paid engineers at real companies with actual jobs finding themselves in the midst of this kind of paint-yourself-into-a-corner problem. So what does all this have to do with my project?

Vermilion is the solution to a problem which doesn't exist yet.

Instead of writing a custom OS for the Handpower personal organizer which directly targets the hardware I am designing - and brings along the undesirable consequence of inextricably linking the two until the heat death of the universe - I will instead be abstracting the underlying hardware out of the picture preemptively. That's a lot of work for a problem which isn't even presently present, but it will be worth it in the end; the device will never find itself painted into the corner of only running on a specific hardware platform. Applications, and even the OS itself, simply need to be written to run on the Vermilion Virtual CPU, and if I ever find myself needing to abandon one platform for another, all I need to do is recompile the virtual CPU core to run on the new one. All other components continue to chug along seamlessly, completely unaware that the digital rug was just yanked from beneath them, only to be replaced with a cool new one.

If all this sounds a bit familiar, it should. It's basically the same thing I was doing way back in the mid-2000s with the virtual CPU I made for PCOS / Exelyx. All the experimentation which led to that platform will live on in Handpower. I guess everything old really is new again.

And as for those other projects? I guess you'll just have to stay tuned. smiley.png

8/27/2024 - Now... why could one possibly need to make a list of all this? Hmm...

It's a secret to everybody.

8/9/2024 - Hey, y'all! Been awhile, eh?

Just a quick update on how that whole #WeaponKeyboard thing's been going, nearly three and a half million keystrokes later... :)

3.5 million!

5/12/2024 - Iterate! Iterate! Iterate!

I've done so many iterations on the Weapon Keyboard firmware that I think this is the longest uptime I've had yet! lol

Two. Point. Three. MILLION!
Side note: 2.3 million total keystrokes FTW :D

4/27/2024 - So, how fast can your keyboard click? biggrin.png

OH THE SPEED!!
(Results courtesy of http://cpstest.org and http://arealme.com.)

4/21/2024 - The latest firmware update for #WeaponKeyboard!

0.7.0 - 2024-04-20
New:

Changed:
Fixed:

4/13/2024 - ASCII Art video game references in source code.

'Tis a sad thing indeed!

Because I can. lol

4/11/2024 - A new Weapon Keyboard firmware update!

0.6.0 - 2024-04-11
New:

Changed:
Fixed:

1/14/2024 - Greetings, and happy new year!

In the space since my previous major update to you all, so much has happened in the Weapon Keyboard world.

When I was designing the original Revision A, I was beginning to get to the point I often reach in my projects where tiny details were beginning to stand in the way of getting a physical object in my hands. I mean, technically all this detail work does need done, and I could sink many more hours into it and make every detail perfect... but over the years I've learned to recognize that this drive to dwell on the minutiae ultimately stems from the fear of moving forward.

What if the design doesn't work? What if it fails miserably? What if this entire endeavor turns out to be a complete waste of time, money and materials?

Sometimes it's easier to wrap oneself up in some nice warm busy work and avoid the cold icy wind of progress, but it is times like those where you must push forward and make it happen, and it makes no sense to pour all your time and effort into your first prototype when you are nearly certain there will need to be a second one close behind it. You can always attend to the finer details as time goes on - it's better to get that first step taken care of as soon as feasibly possible and get a physical, tangible object in your hands to provide you the necessary motivation to proceed, not to mention the invaluable things you'll learn from that first prototype.

But, enough ruminating. It's time for the announcement: The Revision B PCB is complete!

To quote myself from a while back, Human designers are plagued with shortsightedness, and it's quite impossible to account for every detail until you get at least some of your project down in prototyped form. I've found that to be all too true with Weapon, such as the issue I discovered where the signal diodes on most stabilized keys - those wide enough to need a stabilizer bar beneath them such as Backspace, Enter, Shift, etc. - are placed too close to the stabilizer base, allowing it to force the diode off of its solder pad. I was able to glob on more solder to work around this in Revision A, but that's a bit of a hack and a more suitable solution is in order for Revision B, where all the signal diodes have been moved to the back of the PCB.

Other errors were fixed on the new revision, such as reversed polarity on a handful of LEDs (they also now have a nice thick border around the main pin!) and the entire LED backlight array has been moved to the proper microcontroller output, eliminating the ugly bodge wire I had to use in order to be able to even get the LEDs to kick on at all.

Apart from the typical key and mouse events already supported, one of my upcoming plans is to add a "function" event type to the Weapon firmware which will allow certain specialized little jobs to be performed - one being to send the current date, time, or both at the press of a key. To this end, there's now a spot for a CR2032 battery which will allow Weapon to keep time while disconnected.

The mishaps with the OLED display have been addressed by moving it to the I2C bus as opposed to the more pin-hungry SPI bus which was planned for Revision A, as well as cutting out the PCB area which was to be beneath the display on Revision A. The extra room this frees up will be used to accommodate the adjustment mechanism for the OLED screen to make for easy viewing... once a case gets made, that is.

All in all, I've had enough time now - over 400,000 keystrokes worth! - to put Weapon through its paces, and was able to gather information and think up new ways of doing things which never would have occurred to me had I not taken the leap and got that crucial first board finished. Revision B will be better still, and I'm looking forward to taking you all along for the ride.

P.S.: Speaking of the ride ahead, I'd like to start posting an update on this project on a weekly basis... but such a thing should have a proper name. How does Weapon Wednesdays sound? smiley.png

Weapon - Rev B - PCB front.png Weapon - Rev B - PCB back.png

12/30/2023 - Is it really even turbo if it isn't at least four thousand presses per second?

Have you ever been playing a game on your computer and thought to yourself, Man I wish I had a turbo controller? The Weapon Keyboard has ya covered.

Woah. That's fast.

12/28/2023 - Hey Mercury! Where ya been?

So. It's been a bit, yeah? But you know how it goes. Projects, and life, and projects, and life. And there's some sleeping and stuff in there too, I think. Or, at least there's supposed to be. I'm still not sure about that.

Anyway, I just wanted to stop by and freshen up the blog with some posts on what I've been up to over the past year. There's a new project! Or there was. (It's not so new anymore.) But, as you can see in the backlog of posts I put up here, it's coming along nicely! It's actually one of the first projects I've started in a long time where I have some tangible, usable thing as a result of the process, and that is a very nice feeling. I recognize, however, that I've been away for quite a while, though, and in the future I'll try to not get wrapped up in my work so much that I do that again. The soldering and layout and planning can be so time consuming, if you let it, and I don't always do the best job of balancing everything that life throws at me. But I'm back! And I'm working almost daily on bringing more and more projects to life.

As I always say... stay tuned! smilie.png

12/27/2023 - Quote of the day.

"I think that talent is a little... it's overrated. Because I remember growing up playing music, and I remember I was always worst at all the tests in schools and I tried to get into fancy music schools in Sweden and I was the only one of my friends who couldn't get in because I got zero points on the tests. And I was like, Oh, music might not be anything for me and I have no talent. That's why (this is) a little bit personal for me. And then I realized that, if you put the hard work in, you will get there. Let's say you are talented. Then you also need to be lucky if you're gonna succeed from that. But if you're hard working, you don't need to be lucky. You eliminate that "luck" thing in the whole situation by just taking control of the situation yourself. Don't think that you can't do anything because you feel that you have no talent."

- Wintergatan musician Martin Molin on a question about hard work versus talent

12/25/2023 - joy.png Merry Christmas from Mercury Coding! joy.png

Nothing says 'Merry Christmas' like a red and green alternating color Weapon Keyboard!

12/24/2023

Today marks ten days - and over 131,000 keystrokes! - into me using Weapon Keyboard as my daily driver.

Despite me having never made a keyboard before and, until just recently, never even knowing the details of their inner workings, I've found it's usability to be surprisingly solid and its macros to be infinitely useful.

Aside from an intermittent connectivity problem on the Backspace key (the stabilizer seats right up against the signal diode, which leads to it sometimes becoming briefly separated from its pad on the PCB) the hardware works! The keys have a nice, crisp feel, the unit overall feels nimble and responsive, and the firmware finally does almost everything I want it to, to the extent possible on the Rev A board... although perhaps not yet fully the way I want it to.

The firmware is subject of ongoing refinement on nearly a daily basis, each version incrementally more capable and functional than the last. After working my way through an ever-shortening wish list of features and fixes, Weapon's firmware will finally arrive at version 1.0.0, and it will be time to officially commence designing Revision B.

We've got some mileage under our belts, now, lads!

12/22/2023 - The latest Weapon Keyboard firmware changelog.

0.5.0 - 2023-12-22
New:

Changed:
Fixed:

12/18/2023

It just occurred to me that, despite being admonished by several folks here to keep y'all posted, I have not been keeping y'all posted!

So, here ya go! The Weapon Keyboard changelog, to-date:



0.4.0 - 2023-12-14
New:

Changed:
Fixed:



0.3.0 - 2023-12-06
New:
Changed:



0.2.0 - 2023-11-21
New:
Changed:
Fixed:



0.1.0 - 2023-11-16
New:


I'll post an update when the next version is released. Stay tuned! smilie.png

12/18/2023

A new Weapon Keyboard feature: the odometer.

Also, tell me you're a gamer without telling me you're a gamer. lol

It's alive!

12/16/2023

Now that I've had a couple days to daily drive the Weapon Keyboard, I've found that the macro keys are positioned in a way that interferes with my muscle memory when typing. Thus, for the next version, I decided to move the macro keys a bit leftward to match the spacing of the Function key banks. This entails moving every single component over by 9.31 mm. Now, what do you do when you find yourself having to repeat the same calculation over and over again for a bunch of discreet components?


You let Revision A help engineer Revision B. joy.png

In the video, the only input I'm giving is selecting the component with the mouse and pressing the appropriate macro key. Weapon does the rest. :)

12/14/2023

Today is a milestone. This is my first post composed exclusively on the Weapon Keyboard.

I recently received the final shipment of Cherry MX Red key switches and was finally able to fill those last 20-odd footprints on the PCB.

As you can see, it's working just fine. I was a little concerned that I wouldn't like the feel of these switches once the keyboard got to this point, but I have to say they have a very smooth and decisive feel, making them a perfect fit for the overall aesthetic of the project.

The hardware is officially done - or at least as done as it's ever going to be for Revision A.

The firmware continues to be improved as we speak.

The future is bright! :D

It's alive!

12/13/2023 - Just a few more lines... just one more feature... then I'll be done... honest... lol

It never ends, does it?.

12/10/2023

A Weapon Keyboard update!

Rev A, Firmware 0.4.0

•Can record keystrokes into macros and play them back.
Working.

•Can type on it.
Done, although some key switches haven't yet shipped. No number pad or media keys yet!

•Key caps installed.
Waiting for all key switches to be installed before this happens.

•Key matrix scanning.
Works. Implemented as an interval function; entire keyboard is scanned at a default rate of 100 times per second in the background as other functions run. Interval can be adjusted to scan many many more times per second if need be.

•Large macro handling
Working. Additional memory is allocated on-the-fly to handle events being queued into the macro's event stream if the existing capacity is exceeded. This means macro size is only limited by available memory - no arbitrary size limits imposed because the programmer was lazy! lol

•Multiple simultaneous macro playback
Working. Macros are "multithreaded" so that any macro can play in parallel with other macros.

•OLED display.
Will not be completed in Rev A due to an oversight in pin assignment on the microcontroller.

•Per-key LED lighting
Mostly working; the Rev A boards have a few LEDs connected with reversed polarity which, as they are diodes, they do not like very much. Also, the logic level shifter for the LEDs needs upgraded to a faster version in Rev B.

•Persistent macros
Working. Macros are saved to SD card upon recording and automatically reloaded again at next boot, fully transparent to the user.

•PS/2 ports
Port A will not work in Rev A due to bodge wire which is necessary for LED data transport but unfortunately also results in a signal conflict with the PS/2 port. Port B not yet tested pending refinement of PS/2 Output library.

•UI
Not yet working, waiting on OLED issue to be fixed in Rev B. Extremely minimal UI implemented via serial port for now

•Volume encoder
Volume up, volume down, and push-to-mute all working.

12/8/2023

Okay, so this is gonna sound super basic, but... you can now delete previously recorded macros on the Weapon Keyboard.

I know, I know.

Hey, not every update can be for some fancy new feature! lol

12/7/2023

Macros recorded on the Weapon Keyboard are now automatically exported to an SD card if one is present when saving.

Now, to program it to reload them automatically at boot time for a truly persistent configuration... smiley.png

A saved macro, as viewed from within my text editor of choice.

12/6/2023

Tonight I optimized the matrix scanning code for the Weapon Keyboard. Because what if scanning the keys 100 times per second just isn't enough? joy.png

Before. After.

11/23/2023

As assembly of the prototype Weapon Keyboard nears completion, I started getting curious exactly how much money I have wrapped up in this project. After sifting through some invoices and drawing up an up-to-date BOM, the grand total is just over three hundred thirty dollars! And that's just revision A! Wow.

The most expensive components are the keyswitches themselves ($64.64), the PCBs ($60.68) the OLED Display ($39.95), the Corsair key cap kit ($37.39) the key stabilizers ($35.87), the Teensy microcontroller ($34.11) and the LEDs ($27.90).

Back when I started this project over a year ago, I was much newer to the whole electronics scene than I am now, and I've thankfully found places to get some of the components much cheaper in the time which has passed since then, namely the PCBs (JLCPCB as opposed to PCBWay) and LEDs (5 cents each instead of nearly 28!). Revision B should be a little more economic. cool.png

11/21/2023 - Oh, yeah! Per-key RGB baby!

11/16/2023 - Weapon progress

To my immense surprise, everything worked on the first try!

The switches all register (save for two which needed a teeny bit more solder to make proper contact), and no ghosting occurs at all - a true nKRO design! :D

Now that the macro keys are in place and fully readable by the microcontroller, it looks like I'm ready to build out the rest of the keyboard.

Time for more diodes and switches!!!

Switch soldering has begun!

11/15/2023 - The diodes!! WhY mUsT tHeY bE sO sMaLl?!1?

Soldering Mercury is seriously questioning Design Mercury's judgement right now.

Don't let tiny diodes happen to you.

2/19/2023 - It seems something cool recently arrived in the lab...

Roll that beautiful PCB footage!

1/31/2023 - Irony encountered while submitting my design to the PCB fab house

Uh, well technically...

Oh, it's a weapon alright. Just not the kind you're referring to.

1/30/2023 - The day has come.

After countless hours - I quite literally lost track of how many workdays I spent on this - designing, redesigning, routing, rerouting, re-rerouting, and re-re-rerouting... the prototype circuit board design is finally complete.

The funny thing about projects like this is that you always underestimate the sheer amount of work which goes into them and the level of attention they will demand. In the beginning, long before the Weapon Keyboard was even a schematic diagram, I remember thinking to myself, How hard could it be? It's only a keyboard! Now I know.

Human designers are plagued with shortsightedness, and it's quite impossible to account for every detail until you get at least some of your project down in prototyped form, be it a schematic, a PCB layout, or what-have-you. To get to this point took me no less than three major layout revisions, along with innumerable small changes to the positions of even the smallest components, each change giving new insight into the most efficient use of board space and new opportunities to further optimize. It was exhausting, but, thanks to a lot of patience and a wife more understanding of my hours on end of slaving away in front of my computer than I deserve, it's done. It's finally done.

As tempting as it is to do so, I'm not submitting it to the fabrication house just yet. Why? Because now that the stress of getting it to this point has vanished, my brain will now be free to think of any things I may have overlooked and double check anything which may pop into mind. I know this because this has happened once already! I thought I had achieved this milestone a few days ago, but taking a step back for the evening helped me notice that I had made a rather serious error in the footprint I created for the SK6812 LEDs; electrically the connections were sound, but I had mistakenly placed a chamfer not on the pin indicating the LED's ground connection as the datasheet shows, but on pin one instead. Had the board been fabricated this way and I were to have blindly followed the silkscreen markings without checking the schematic, I would have suddenly had a ton of dead LEDs. Not cool! Thankfully this was caught and fixed before production, despite it also meaning I had to rework the tedious placement of these components yet again, cursing my own foolishness as I did so.

But enough of this novel I type - it's time for this tired dev to rest his head. Goodnight, folks!

It's finally done.

1/28/2023

A little specs table I threw together for the Weapon Keyboard:

Backlighting Fully customizable per-key SK6812 Mini-E RGB LEDs with individual bypass capacitors
Case Prototype: None
Final: Custom machined aluminum, designed and fabricated in America
Dimensions PCB: 20.7878 x 6.5902 inches, 528.010 x 167.390 mm
Display 128 x 64 monochrome dot matrix OLED (SPI Mode)
Interfaces USB-C (Micro USB for prototype), PS/2 Out combo port, PS/2 In (Passthrough) combo port
Key Count 128
Key Sizing Return: ANSI
Shift (Left): 2.25u
Shift (Right): 2.75u
Spacebar: 6.25u
Keycaps Prototype: Corsair PBT Double-Shot Pro Kit, Onyx Black (typical 104 keys), Corsair K95 RGB (Macro keys)
Final: Custom designed double-shot
Layout Format 100% with Macro keys
Macro Keys 16 individual keys with an infinite number of configurable “pages”
Matrix Signaling Isolation Method Individual per-key 1N4148WS diodes
PCB Prototype: Custom designed and assembled in America, manufactured in China
Final: Custom designed, manufactured and assembled in America
Processor Prototype: Teensy 4.1
Final: 600 MHz IMXRT1062
Software Custom Weapon Firmware (encrypted)
Special Features
  • Key backlight LEDs can be used for UI input hints
  • Macro record, playback and storage using SD card
  • PS/2 Passthrough allows using a physical PS/2 mouse in addition to Weapon's built-in mouse emulation
  • PS/2 splitters available separately in both Input and Output orientations
  • Scriptable mouse emulation
  • Zero software installation - all features are accessible directly through Weapon's built-in software
Stabilizers Smokey Clear Durock V2, Screw-In
Switches Cherry MX Red RGB Clear, PCB Mount

1/26/2023 - The cost of product development

It's times like these I try to be mindful of how many countless dollars large corporations have the privilege of sinking into their R&D departments and be thankful that I can do even the little amount of work that I do without those kinds of resources.

It costs <i>how much</i>?? But yeah, thanks for that $4.53 off, though.

1/19/2023 - It's beginning to look a lot like PS/2 biggrin.png

So, what are we seeing here? (Other than a desk sullied by the clutter and debris of renovation. I'm not looking forward to cleaning up all that drywall dust when everything's over!)

This is the serial terminal output of a Teensy 4.1 microcontroller running custom code which helps it serve as a PS/2 device. The microcontroller is fixed to a breadboard along with a pair of PS/2 ports, a set of level shifters and a trio of LEDs representing Num Lock, Caps Lock and Scroll Lock, respectively. The breadboard is connected to my lab computer via a PS/2-to-USB adapter and appears to the PC, for all practical purposes, just as any other PS/2 keyboard would.

Since multiple keyboards plugged into any computer all share modifier key states, a press of Caps Lock, for example, on one keyboard will elicit LED responses from all connected keyboards in unison, and that's what we're seeing here; the computer not only recognizes the breadboard as a valid PS/2 keyboard, but does so to the point that it properly gets LED status updates when I press Caps Lock or Num Lock on my actual keyboard. As you can see, the LED state is updated with every keypress, just as a regular store-bought keyboard would do.

Now, you may have some questions, like, Why are you bothering with such an old standard when building up a modern keyboard? or, Why does the orange LED on the microcontroller keep flashing? and What's that funky music you've got on in the background?

I'll answer that last one first, because it's the simplest. That's some good old-fashioned GameBoy music. I like rocking out 8-bit style as I work! (Bonus points if you can name the game it's from! smiley.png)

The orange light it flashing as a "heartbeat" of sorts; it lets me know the PS/2 state machine is still running. Such debug indicators always help when running super beta code like this!

And finally, why am I bothering to even add PS/2 support to a modern keyboard? Two reasons: 1. because I want it to be usable even on bare-bones systems, such as DOS or hobby computers and, 2. because my work PC requires it. Allow me to elaborate.

One of the main reasons I started work on this project is to create a keyboard which can help me in the day-to-day functions of my day job. Most macro and gaming keyboards have been locked out by our admins, and even plugging in a microcontroller masquerading as a keyboard simply won't cut it - the system sees right through that. Yes, I checked. lol

As a test, then, I grabbed an old PS/2 keyboard and a PS/2-to-USB adapter to see if the system allowed this and - lo, and behold - it did! At that moment I knew I needed to bless the Weapon Keyboard with PS/2 protocol support sooner than later, and - fun fact - this is one of the reasons behind my choice of microcontroller. I need something with enough horsepower to easily handle running two (or maybe even four!) PS/2 ports while maintaining concurrent playback of multiple macros (if the user so desires) and handling the UI on the OLED screen and will still have enough leftover oomph to maintain thousands of scans per second of the keyboard matrix. The 600 MHz powerhouse which is the Teensy 4.1 should be able to do all this and more, in addition to being what I happened to have laying around.

The PS/2 code is a little more mature than I'm showing here; it's already able to type long predefined sentences at the touch of the trigger button on the breadboard over PS/2 without missing a beat.

My work computer won't know what hit it. cool.png

1/19/2023

Soooooo close!

Getting there!

1/19/2023

Oh, autorouter. You're so funny.

Autorouting fail.

1/19/2023

POV: Your new keyboard. cool.png

A 3D render of the Weapon Keyboard PCB.

1/18/2023 - Meeting Meditations

At the second or third meeting, Burrell presented an intricate blueprint of the PC board layout, which had already been used to build a few working prototypes, blown up to four times the actual size.

Steve started critiquing the layout on a purely esthetic basis. "That part's really pretty", he proclaimed. "But look at the memory chips. That's ugly. The lines are too close together".

George Crow, our recently hired analog engineer, interrupted Steve. "Who cares what the PC board looks like? The only thing that's important is how well that it works. Nobody is going to see the PC board."

Steve responded strongly. "I'm gonna see it! I want it to be as beautiful as possible, even if it's inside the box. A great carpenter isn't going to use lousy wood for the back of a cabinet, even though nobody's going to see it.""
- Happenings at one of numerous management meetings surrounding the design of the original Macintosh, as retold in the story PC Board Esthetics at folklore.org


My current board design for the Weapon Keyboard is basically that story, except I'm both Burrell Smith and Steve Jobs.

sigh

1/15/2023

Will my board get banned from Amazon? laugh.gif

The Right Alt key? Or the Alt Right key?

12/26/2022 - Theoretical Questions...

Which is the better layout?

Model 1: The one with the small "A" and "B" macro buttons scattered across the board and space for a screen in the upper left corner.

Model 2: Is slightly more narrow, has uniform button sizes, three LEDs tilted at a 45 degree angle and a small monochrome OLED display.

EDIT: Ignore the numbers on the front face of each key, those are merely matrix assignments.

Decisions, decisions...

Model 1 Model 2

12/17/2022 - New Project Hint

02:14:16.758 -> Half-period: 30 microseconds (Bus speed: 16666 Hz)
02:14:16.759 -> Bus was IDLE for 262747 microseconds, now changing to RTS
02:14:16.759 -> Bus was RTS for 1 microseconds, now changing to UNDEFINED
02:14:16.759 -> Bus was UNDEFINED for 113 microseconds, now changing to RTS
02:14:16.759 -> Tx: 2 Rx: 1
02:14:16.759 -> COMMAND 0xF3
02:14:16.759 -> Data: 0
02:14:16.759 -> Bus was IDLE for 4 microseconds, now changing to INHIBITED
02:14:16.759 -> Bus was INHIBITED for 105 microseconds, now changing to UNDEFINED
02:14:16.759 -> Bus was UNDEFINED for 115 microseconds, now changing to RTS
02:14:16.759 -> Tx: 4 Rx: 3
02:14:16.759 -> COMMAND 0xED
02:14:16.759 -> Bus was IDLE for 4 microseconds, now changing to INHIBITED
02:14:16.759 -> Bus was INHIBITED for 96 microseconds, now changing to UNDEFINED
02:14:16.759 -> Bus was UNDEFINED for 115 microseconds, now changing to RTS
02:14:16.759 -> Tx: 5 Rx: 4
02:14:16.759 -> COMMAND 0x02
02:14:16.759 -> Bus was IDLE for 5 microseconds, now changing to INHIBITED
02:14:16.759 -> Bus was INHIBITED for 47 microseconds, now changing to IDLE
02:14:25.538 -> Bus was IDLE for 12394852 microseconds, now changing to UNDEFINED
02:14:25.794 -> Bus was UNDEFINED for 270737 microseconds, now changing to INHIBITED
02:14:25.794 -> Bus was INHIBITED for 1 microseconds, now changing to IDLE
02:14:25.826 -> Bus was IDLE for 13418 microseconds, now changing to RTS
02:14:25.826 -> Bus was RTS for 1 microseconds, now changing to UNDEFINED
02:14:26.501 -> Bus was UNDEFINED for 700699 microseconds, now changing to RTS
02:14:26.501 -> Tx: 6 Rx: 5
02:14:26.501 -> COMMAND 0xFF
02:14:26.533 -> Bus was IDLE for 3 microseconds, now changing to INHIBITED
02:14:26.533 -> Bus was INHIBITED for 110 microseconds, now changing to UNDEFINED
02:14:26.533 -> Bus was UNDEFINED for 114 microseconds, now changing to RTS
02:14:26.533 -> Tx: 9 Rx: 6
02:14:26.533 -> COMMAND 0xFF
02:14:26.533 -> Bus was IDLE for 4 microseconds, now changing to INHIBITED
02:14:26.533 -> Bus was INHIBITED for 114 microseconds, now changing to UNDEFINED
02:14:26.533 -> Bus was UNDEFINED for 115 microseconds, now changing to RTS
02:14:26.533 -> Tx: 12 Rx: 7
02:14:26.533 -> COMMAND 0xF3
02:14:26.533 -> Data: C8
02:14:26.533 -> Bus was IDLE for 5 microseconds, now changing to INHIBITED
02:14:26.533 -> Bus was INHIBITED for 113 microseconds, now changing to UNDEFINED
02:14:26.533 -> Bus was UNDEFINED for 115 microseconds, now changing to RTS
02:14:26.533 -> Tx: 14 Rx: 9
02:14:26.533 -> COMMAND 0xF3
02:14:26.533 -> Data: 64
02:14:26.533 -> Bus was IDLE for 4 microseconds, now changing to INHIBITED
02:14:26.533 -> Bus was INHIBITED for 114 microseconds, now changing to UNDEFINED
02:14:26.533 -> Bus was UNDEFINED for 115 microseconds, now changing to RTS
02:14:26.533 -> Tx: 16 Rx: 11
02:14:26.533 -> COMMAND 0xF3
02:14:26.533 -> Data: 50
02:14:26.533 -> Bus was IDLE for 4 microseconds, now changing to INHIBITED
02:14:26.533 -> Bus was INHIBITED for 114 microseconds, now changing to UNDEFINED
02:14:26.533 -> Bus was UNDEFINED for 115 microseconds, now changing to RTS
02:14:26.533 -> Tx: 18 Rx: 13
02:14:26.533 -> COMMAND 0xF2
02:14:26.533 -> Bus was IDLE for 4 microseconds, now changing to INHIBITED
02:14:26.533 -> Bus was INHIBITED for 121 microseconds, now changing to UNDEFINED
02:14:26.533 -> Bus was UNDEFINED for 115 microseconds, now changing to RTS
02:14:26.533 -> Tx: 20 Rx: 14

12/11/2022 - Hmmmm... What could it be?

It's time for everyone's favorite game show... Name That Waveform!

jumping-0044.gif

11/6/2022 - It sure has been quiet around here lately...

...and the long-time readers among you likely know that usually means only one thing: there are new projects afoot!

Many of the projects on which I work were birthed out of necessity - or purely out of a because I can spirit - but this project actually began on a whim. I have a certain computer system which, due to its current state of operation, has no reliable way to get data in or out. That, naturally, got me thinking. What constitutes a data path, anyway? We're all used to using flash drives, hard disks or the internet itself nowadays, but who says those are the only options? Now, realistically, one could easily add a USB card or CD drive to a PC that is data-challenged, but... where's the fun in that? So okay, if one does not use the "conventional" means of data transfer, then what? What other options are there?

The average computer - even an old or broken one - has a couple facilities which might not jump to mind when you think of transferring data, but they are usable for the job nonetheless: sound and light. And while data transfer using sound is possible, that's already been done. Remember dial-up internet? No, I wanted to do something which isn't a simple rehash of old consumer-level technology, and that left me with light-based transmission. Initially, I tested out the concept using a couple LEDs connected to a Teensy 4.1 microcontroller and, while this experiment was sufficient to determine feasibility, it left a lot to be desired in execution. I have around a hundred plain white LEDs and as much as I would've loved to put some of those into a new project, something like this needed the right tool for the job. Enter the Light Dependent Resistor (commonly called a photoresistor) - a convenient little device which, when coupled with a microcontroller like the Teensy I'm using here, can provide surprisingly sensitive resistance values based on the light and shadow around it. With feasibility now tested, I did a bit of research to see if anyone had done a project like this before and - lo, and behold! - I found this video from Mike Szczys where he transmits data fairly well simply by letting the photoresistor read ambient light refraction from his computer monitor. Aha! So this was indeed feasible! party-0042.gif

While Mike's example was a great attempt, it only transmits a single bit at a time, and that at a fairly slow pace. While the slow timing is understandable for the prototyping phase of a project, I wanted - as I usually do - to evolve the main points of the concept to the next level. Instead of simply reading ambient light pulses from the room itself, what if one mounted multiple photoresistors to a circuit board, hooked it to a microcontroller, and then aimed the whole shebang directly at the monitor? Ah, yes, now we're on to something! biggrin.png And then, what if one maxed this concept out, creating an entire sheet of photoresistors, synchronized with a clock pulse, and used that to transmit a ton of bits in parallel? And maybe even added headers so that multiple units could be connected to each other for even more parallel data collection goodness? Well, that might look a little something like my latest project - Kirbyte:

Kirbyte Rev A - Top Kirbyte Rev A - Bottom

That prototype looks pretty awesome, eh? It's equipped to process 32 bytes at a time and even has a convenient status LED to indicate what it's doing at any given time. What's not to love? Well, a lot, actually. For one thing, it's huge in comparison to what it could be. Its inefficient layout leads to a lot of wasted board space, particularly vertically between each group of eight photoresistors. Speaking of layout, some crucial traces have few other choices but to be run in such a roundabout manner that signal integrity may be called into question for some of the faster buses like I2C, which the device uses to communicate with each analog-to-digital converter (ADC) reading its own group of eight photoresistors. No, this simply wouldn't do, and so a remake was in order. Behold:

Kirbyte Rev B - LDR Board - Top Kirbyte Rev B - LDR Board - Bottom Kirbyte Rev B - Processor Board - Top Kirbyte Rev B - Processor Board - Bottom

Now... this. This will surely fit the bill, right? Its revamped design splits the processor and ADCs onto their own board, separate from the photoresistors and other components which make up the voltage dividers of which each is a part. Thanks to this separation, it can more tightly pack the photoresistors, resulting in a more compact unit with much less wasted space. But... did you notice something about this version? Namely the photoresistors themselves. They aren't exactly positioned in the most space-saving orientation, are they? Up to this point I reasoned that the vertical space they occupy would be sufficiently packed and that their "sideways" orientation would allow for a more narrow unit which more readily lends itself to packing multiple units together on a monitor. However, after this revision, I could see that the width was good enough and that more vertical space could be saved if they were rotated 90 degrees. No, even this revision still wasn't quite there. I decided to iterate once more.

Kirbyte Rev C - ADC Board - Top Kirbyte Rev C - ADC Board - Bottom Kirbyte Rev C - LDR Board - Top Kirbyte Rev C - LDR Board - Bottom Kirbyte Rev C - Processor Board - Top Kirbyte Rev C - Processor Board - Bottom

The final (so far!) revision brings a host of improvements to the table - not just the cool new Mercury Blue color! For starters, the LDR board has been reduced to one simple group of eight photoresistors coupled to the ADC board by a quartet of SMD headers, and the processor board is now its own separate entity as well. This board is host to the microcontroller, the clock photoresistor, and a pair of I2C bus multiplexers which allow Kirbyte to easily juggle reading from all those LDRs. The new modular design allows units to be assembled with a variety of heights and widths, perfect for prototyping - just chain multiple boards to each other. There's now a 5-to-3.3 volt regulator which will allow power to flow to devices on the I2C buses and other boards directly from the USB connection, bypassing the paltry 250 mA emitted from the microcontroller's onboard regulator. And speaking of other boards, quick connection of multiple units is a breeze thanks to the new Magsafe (oops, that's copyrighted) *ahem* spring-loaded magnetic expansion connectors.

The theory of operation behind Kirbyte can be summarized in a few simple steps. First, the user chooses how many Kirbyte units they wish to use. This can be anywhere from a single unit to several units to fill most of the width of the target system's monitor. The more units, the more data will be transferred at a time, and the faster the transfer will complete. At this point, the PC software shall be in its idle state, and will thus be flashing a test pattern on the screen to assist with the calibration process, which will be detailed shortly. After all units are connected to each other via the magnetic side connectors, power will be applied via USB to only one of the units; voltage will then be supplied from the USB connected device to any other units present. At power up, the status LED will turn red as all units probe the I2C buses to see how many individual ADC/LDR boards are attached to each and send commands to any neighboring units to determine how many are present. After this, the status light will blink yellow, indicating the start of the calibration process - a short period of time during which each Kirbyte unit will repeatedly measure the values from the photoresistors and compare them with those last received. Over the duration of the calibration process, logical low and high light levels will be established for each individual LDR, allowing for consistent operation across many different types and quality levels of photoresistors. After calibration is complete, the status LED will turn green, and the units are ready to begin receiving data from the PC software. This data may be saved to an internal SD card, if one is present, or streamed via the USB port to be received by the user's choice of serial terminal application.

All that being said, this is still just a prototype. That being the case, there is still more work to be done in both the hardware and software departments - the firmware which will run Kirbyte hasn't even been written yet! At the time of this post, I have the first batch of ADC and LDR boards coming back from my supplier and will be testing them out upon arrival with a bare microcontroller just to establish a baseline for functionality. If all goes well, I'll next have the processor boards sent out and, when they arrive back here at the lab, the first working Kirbyte prototype will be fully operational. I started this project as a "side quest" of sorts on the way to making another new electronics project which I'll unveil in early 2023. That project will help me in the realization of a few software-based projects which have been on the back-burner for quite some time now. Intriguing, you say? A piece of hardware which can assist in the creation of software? Hmmm... what could it be? biggrin.png

Keep an eye out for updates as progress goes on!

8/12/2022 - A new Strings.js feature.

Today I found myself having to create an account at a site I frequent, and found that the usual site I use to generate strong passwords is offline. Oh noes! What will you do??

Malden spoofs aside, I decided to do what I usually do... I built my own! The Mercury Strong Password Generator can quickly throw together random passwords based on a variety of specified criteria. Need a password with strictly letters only? No problem! Need some all-out Fort Knox security? Go Insane! Use it for all your random password needs. Enjoy!

8/5/2022 - A new Calendar.js feature.

In a recent blog entry, I detailed the new Calendar.js library as a help to an ongoing work projects in which I'm involved. As it happens, I had an idea on how to enhance that project with custom greetings, and now when you check out the demo, it will automatically greet you with a time-of-day-appropriate phrase. Cool!

Good evening!

7/26/2022 - Colors, colors everywhere!

What would I do without work projects to keep me coding? lol

This time around, my concern is yet another part of a work project featuring a text box whose background color is dynamically selectable. The problem users will inevitably have is that, when selecting some of the darker background colors, the default black text will show up very poorly - if at all. Now, the reason the color of the background is user-selectable in the first place is beyond simple aesthetics, so the solution is not as easy as simply prohibiting them from changing the background color to begin with. No, I'll have to implement some custom code that recolors the text based upon the selected background color. But, hey, what am I saying? This is JavaScript! I likely won't have to write anything from scratch if I search the interwebs just right!

Sure enough, after a bit of ducking, I came across this site, which showcases the exact functionality I needed. Great! I tweaked this code to be more my style, and was off to the races. But wait - there's one other thing!

The funny thing about using the HTML color picker to set the background color of a text box is that the color can look a little off due to how the human eye perceives color. In the case of this project, the user will be choosing a color from one of a series of other objects on screen, each occupying a sizable amount of screen real estate. When that same color gets assigned to a much smaller area (e.g. the background of a text box) it tends to take on a darker appearance since there's less visible area of that color - even though the colors are identical. My solution is to gently lighten the selected color automatically after the user makes their choice, and the code I found here was a perfect fit for the job. And so JSColors was born!

You can see a demo here, or visit the JavaScript Library on the Downloads page to download your very own copy. Enjoy!

7/20/2022 - A calendar for all occasions.

As part of my ongoing work projects, I recently found it necessary to integrate a calendar into another piece of code on which I am working. Sure, there's lots of those available on the interwebs, but I don't need anything fancy - just a basic calendar to add to an existing project with a simple look that I can easily tweak to match the existing theme.

I found code at this website but it has an annoying dependency on JQuery which, per a company security policy forbidding dependence on external libraries, had to go. After the JQuery was gutted and replaced with good old-fashioned vanilla JavaScript, my next quest was to alter the code to dynamically add the elements which made up the calendar as opposed to having them hard-coded into the HTML. This makes it easier to spawn calendars, as all the coder needs to provide is a single DIV element and the function will do the heavy lifting of building the calendar elements themselves. Alright, so far, so good, but... the thing was just too dang big! I shrunk the element sizes in the CSS code and finally things were starting to look like a good fit to my existing project! Only one thing remained - to put it through its paces.

I wrote some code which generated calendars for a specific set of dates, which would test its ability to correctly plot day ranges for any given combination of month and year. It was during this phase that I noticed something off about the existing code - it assumed every year was a leap year! That's right - a duration of 29 days was hard-coded into the month of February. I changed this to the proper 28 days and then added a function from here, which properly detects leap years, and integrated it into the mix. As a final bit of polish, I added the year on to the month name at the top of the calendar and, at long last, the result is Calendar.js.

There's some other functions included for general date handling, so check out a demo of it here, or visit the JavaScript Library on the Downloads page to get a copy for yourself!

It is a calendar, my dudes!

5/4/2022 - Quote of the day.

"It helps to be young to make breakthroughs because you don't know what's impossible."

- Bill Atkinson

3/4/2022 - Friends don't let friends buy from Digi-Key.

Recently I placed an order with Digi-Key for some parts to begin working on a new project I've begun.

I'll let these email screenshots speak for themselves.

Woohoo! An order is placed. I have a habit of signing my initials for most everything these days. Apparently Digi-Key has a problem with that. You can has contact info! Just to make sure they're not up to their old incompetence, I figured I better get confirmation that the order would not be interrupted. The response I received... what, did they not get my first reply? You can has contact info II - the sequel! Good, all seems well. Thanks, Shirley! Time sure flies when you're waiting for parts that never arrive. Oh, lovely. Thanks for the heads-up. Once again, better confirm... Oh, well, at least the rest of the order will still be coming! More time passes... I think Kasia missed the point. Clarification of said point. Um. What? WE WENT OVER THIS! Y'all done goofed. Again.

2/11/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

1/17/2022 - Rollback of LocalStorage use for remembering tags.

Previously, I announced that this blog would begin using the LocalStorage function of modern browsers to remember the tag you were viewwing between page loads. This, however, has been abandoned in favor of simply using the URL to specify a tag to view as it quickly became more trouble than it was worth.

12/25/2021 - A Christmas gift, from me to you.

A few days back I announced changes to how the blog handles images and I'm happy to say that those changes are now complete! As you browse about, you'll notice images across the entire Mercury Coding website no longer open in a separate window when clicked, but open in an overlay instead. What's more, if the image you clicked is part of a group of images, you can now scroll among the other related pictures without having to close one photo to proceed to the next. Much more convenient!

While it would have been easier to implement this in a manner tightly coupled to this specific website, I took the path less traveled. Enter my newest JavaScript creation, JSOMG - the JavaScript One-shot Media Gallery. That's right, one-shot; this new functionality is all supplied by a single file, and putting it to work for you is as simple as including JSOMG.js in your HTML file and designating any desired DIV elements as a class JSOMGContainer in which you can place your IMG or VIDEO (yep, it works with both!) tags. That's it. No custom CSS or additional scripting necessary. Take, for example, this newly retrofitted code snippet from an earlier blog entry:

<div class = "JSOMGContainer">
    <img src = 'media/blog/2020-11-01/IMG_0004.JPG' alt = "The base by itself.">
    <img src = 'media/blog/2020-11-01/IMG_0005.JPG' alt = "The base with corner support rails attached.">
    <img src = 'media/blog/2020-11-01/IMG_0006.JPG' alt = "The top gantry assembly attached.">
    <img src = 'media/blog/2020-11-01/IMG_0007.JPG' alt = "The Z-axis screws and heated bed bolted in. Also, the spool holder attached in the wrong place!">
    <img src = 'media/blog/2020-11-01/IMG_0008.JPG' alt = "Before wiring.">
    <img src = 'media/blog/2020-11-01/IMG_0010.JPG' alt = "After wiring - and power on!">
    <img src = 'media/blog/2020-11-01/IMG_0042.JPG' alt = "<img src = 'media/emojis/woohoo.gif' alt = 'woohoo.gif'><br>The first completed print - and just look at that precision!">
</div>

Easy, eh? But it gets even better. See all those ALT tags in the code? They normally exist to provide greater accessibility for visually impaired users but, if they are present, JSOMG will automatically use them as captions for your images, and you don't even have to ask nicely. Oh, and in the process, JSOMG utilizes the innerHTML attribute instead of innerText, so if your ALT strings happen to contain HTML code, such as the last IMG in the code above, that will work too, just as intended. Additionally, JSOMG is smart enough to dim the scrolling arrows when the user's mouse pointer is not hovering over them, or to eliminate them entirely if there is but a single image in the JSOMGContainer. And, just to kick the ease-of-use up another notch, JSOMG also responds to keystrokes while the overlay is open, allowing the user to navigate the media using the left and right keyboard arrows, or to exit the gallery using Escape.

This explanation is all well and good, I suppose, but I know you. You want some hands-on testing, don't you? Oh, ok. Get ready. Here we go!

First, a replica of the creaky old way:

And now, a demo of the shiny new JSOMG way:

The base by itself. The base with corner support rails attached. The top gantry assembly attached. The Z-axis screws and heated bed bolted in. Also, the spool holder attached in the wrong place! Before wiring. After wiring - and power on! <img src = 'media/emojis/woohoo.gif' alt = 'woohoo.gif'><br>The first completed print - and just look at that precision!

See how much more efficient that is? Feel free to check it out in the Downloads section if you think JSOMG may be right for your next project.

Ok. Are we done? Is that it? This is Christmas! Of course that's not it! Aside from JSOMG, other changes include an auto-dim feature for the Home button site-wide and <P> tags are now used across this blog to replace the multitude of <BR> tags left over from my early days of HTML coding. Oh, the things you learn over the years!

Alright, now that's it. Have a Merry Christmas!Christmas-santa3.gif

12/19/2021 - THE MERCURY STORE IS GO!

Behold! At long last, I have a way to offload some of my surplus parts. All proceeds from sales in the Mercury Store will help further all the projects you've come to know and love. But how does it work? I'm glad you asked!

On the surface, the Mercury Store is much like any other storefront, with one main difference: orders are submitted via email instead of directly through the site. After selecting the items you wish to purchase, click on the cart icon in the upper right corner and click Send Order button and the contents of your cart will be sent to your email client. After sending, you'll receive a reply which both confirms the order and provides a method of payment.

But the store isn't the only thing that's new! You'll notice that every page now has a "Return to home" button in the top left corner to provide a quick path back to the index page, the tiles on the projects page are larger and more readable, and there are several under-the-hood improvements as well, such as more streamlined CSS and more consistent and modern coding techniques across some of the site's older files. And there's more to come! Currently, clicking on an image will allow a larger view in a new browser tab, but to see the next image in the group you must close this tab, go back to the first, then click on the next image to open its enlarged view. No more! In the near future, the site's image handling code will be modified to allow easy scrolling among other images in a group, as seen on other modern sites.

12/14/2021 - New JavaScript libraries for your coding pleasure.

Along the journey of coding the new Mercury Store, I had need for a few new JavaScript functions, which are now available in the Downloads section: Strings.js contains more versatile versions of the inbuilt TrimLeft() and TrimRight() functions, courtesy of code written in 2012 by Aurelio De Rosa, and DOM.js contains the singular but useful function DOMChildrenRemoveAll() which, as its name implies, removes all children of an object in the document. Enjoy!

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! biggrin.png

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:

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 eye-popping.gif) 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. cool.png 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!

Santa.png

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.

10/1/2021 - New blog enhancements!

Once again, improvements have landed. Your favorite blog (spoiler alert: it's this one wink.png) now sports a list of all tags at the top, not only allowing fast navigation amongst them, but also giving a quick, at-a-glance tally of how many times each tag appears in the blog. BUT WAIT, THERE'S MORE! Under the hood improvements include merging of multiple similar JavaScript functions, clarified comments, better performance from tidying up ancillary code, and some new features: you can finally click an image to launch it full-size in a separate tab (About time!), and tags and images now show the pointer cursor on hover to better signify they are clickable.

Enjoy!

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.

FCx LEDs
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.

Halt Button
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.

Reset Button
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. oops.png There are a few tweaks which need to be made for the future Revision B board:

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! rolleyes.png

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!" symbols-lifepreserver.gif

Animals:
animals-alligator.gif animals-ant.gif animals-badger.gif animals-baldeagle.gif animals-bat.gif animals-bear.gif animals-beaver.gif animals-bookworm.gif animals-boxer.gif animals-bulldog.gif animals-bumblebee.gif animals-bunny.gif animals-butterfly.gif animals-cat.gif animals-chameleon.gif animals-chicken.gif animals-chihuahua.gif animals-chimpanzee.gif animals-chinchilla.gif animals-clownfish.gif animals-cow.gif animals-crab.gif animals-cricket.gif animals-deer.gif animals-doberman.gif animals-dog.gif animals-dolphin.gif animals-donkey.gif animals-dove.gif animals-dragonfly.gif animals-duck.gif animals-elephant.gif animals-emu.gif animals-ferret.gif animals-flamingo.gif animals-fox.gif animals-frog.gif animals-giraffe.gif animals-goat.gif animals-goldfish.gif animals-greyhound.gif animals-groundhog.gif animals-hamster.gif animals-hedgehog.gif animals-hippo.gif animals-horse.gif animals-horseshoe.gif animals-kangaroo.gif animals-kiwibird.gif animals-ladybug.gif animals-lion.gif animals-lizard.gif animals-llama.gif animals-lobster.gif animals-loon.gif animals-mallard.gif animals-mole.gif animals-monkey.gif animals-moose.gif animals-mouse.gif animals-octopus.gif animals-orcawhale.gif animals-orly.gif animals-owl.gif animals-panda.gif animals-parrot.gif animals-pawprint.gif animals-penguin.gif animals-pig.gif animals-poodle.gif animals-pug.gif animals-raven.gif animals-rhinoceros.gif animals-saanendairygoat.gif animals-seahorse.gif animals-shark.gif animals-sheep.gif animals-slug.gif animals-snail.gif animals-snake.gif animals-squirrel.gif animals-starfish.gif animals-stork-baby.gif animals-stork-boy.gif animals-stork-girl.gif animals-sugarglider.gif animals-swan.gif animals-teddybear.gif animals-tiger.gif animals-tropicalfish.gif animals-turkey.gif animals-turtle.gif animals-wolf.gif animals-worm.gif animals-zebra.gif

American State Flags:
us-alabama.gif us-alaska.gif us-arizona.gif us-arkansas.gif us-california.gif us-colorado.gif us-connecticut.gif us-delaware.gif us-districtofcolumbia.gif us-florida.gif us-georgia.gif us-hawaii.gif us-idaho.gif us-illinois.gif us-indiana.gif us-iowa.gif us-kansas.gif us-kentucky.gif us-louisiana.gif us-maine.gif us-maryland.gif us-massachusetts.gif us-michigan.gif us-minnesota.gif us-mississippi.gif us-missouri.gif us-montana.gif us-nebraska.gif us-nevada.gif us-newhampshire.gif us-newjersey.gif us-newmexico.gif us-newyork.gif us-northcarolina.gif us-northdakota.gif us-ohio.gif us-oklahoma.gif us-oregon.gif us-pennsylvania.gif us-rhodeisland.gif us-southcarolina.gif us-southdakota.gif us-tennessee.gif us-texas.gif us-utah.gif us-vermont.gif us-virginia.gif us-washington.gif us-westvirginia.gif us-wisconsin.gif us-wyoming.gif

Canadian Territory Flags:
ca-alberta.gif ca-britishcolumbia.gif ca-manitoba.gif ca-newbrunswick.gif ca-newfoundland-labrador.gif ca-northwestterritories.gif ca-novascotia.gif ca-nunavut.gif ca-ontario.gif ca-princeedwardisland.gif ca-quebec.gif ca-saskatchewan.gif ca-yukon.gif

National flags:
aboriginal.gif afghanistan.gif albania.gif algeria.gif andorra.gif angola.gif antigua-barbuda.gif argentina.gif armenia.gif australia.gif austria.gif azerbaijan.gif bahamas.gif bahrain.gif bangladesh.gif barbados.gif belarus.gif belgium.gif belize.gif benin.gif bermuda.gif bhutan.gif bolivia.gif bosnia-herzegovina.gif botswana.gif brazil.gif brunei.gif bulgaria.gif burkinafaso.gif burundi.gif cambodia.gif cameroon.gif canada.gif capeverde.gif caymanislands.gif centralafricanrepublic.gif chad.gif cherokeenation.gif chile.gif china.gif colombia.gif comoros.gif congo-brazzaville.gif congo-kinshasa.gif cornwall.gif costarica.gif cotedivoire.gif croatia.gif cuba.gif cyprus.gif czechrepublic.gif denmark.gif djibouti.gif dominica.gif dominicanrepublic.gif easttimor.gif ecuador.gif egypt.gif elsalvador.gif england.gif equatorialguinea.gif eritrea.gif estonia.gif ethiopia.gif europeanunion.gif faroeislands.gif fiji.gif finland.gif france.gif gabon.gif gambia.gif georgia.gif germany.gif ghana.gif gibraltar.gif greece.gif greenland.gif grenada.gif guam.gif guatemala.gif guernsey.gif guinea.gif guinea-bissau.gif guyana.gif haiti.gif honduras.gif hongkong.gif hungary.gif iceland.gif india.gif indonesia.gif iran.gif iraq.gif ireland.gif isleofman.gif israel.gif italy.gif jamaica.gif japan.gif jersey.gif jordan.gif kazakhstan.gif kenya.gif kiribati.gif kuwait.gif kyrgyzstan.gif laos.gif latvia.gif lebanon.gif lesotho.gif liberia.gif libya.gif liechtenstein.gif lithuania.gif luxembourg.gif macedonia.gif madagascar.gif malawi.gif malaysia.gif maldives.gif mali.gif malta.gif marshallislands.gif mauritania.gif mauritius.gif mexico.gif micronesia.gif moldova.gif monaco.gif mongolia.gif montenegro.gif morocco.gif mozambique.gif myanmar.gif namibia.gif nato.gif nauru.gif nepal.gif netherlands.gif netherlandsantilles.gif newzealand.gif nicaragua.gif niger.gif nigeria.gif northernireland.gif northernmarianas.gif northkorea.gif norway.gif oman.gif pakistan.gif palau.gif palestine.gif panama.gif papuanewguinea.gif paraguay.gif peru.gif philippines.gif poland.gif portugal.gif puertorico.gif qatar.gif romania.gif russia.gif rwanda.gif saintlucia.gif samoa.gif sanmarino.gif saotome-principe.gif saudiarabia.gif scotland.gif senegal.gif serbia.gif seychelles.gif sierraleone.gif singapore.gif slovakia.gif slovenia.gif solomonislands.gif somalia.gif southafrica.gif southkorea.gif southvietnam.gif spain.gif srilanka.gif stkitts-nevis.gif stvincent-grenadines.gif sudan.gif suriname.gif swaziland.gif sweden.gif switzerland.gif syria.gif taiwan.gif tajikistan.gif tanzania.gif thailand.gif tibet.gif togo.gif tonga.gif trinidad-tobago.gif tunisia.gif turkey.gif turkmenistan.gif tuvalu.gif uganda.gif ukraine.gif unitedarabemirates.gif unitedkingdom.gif unitednations.gif unitedstates.gif uruguay.gif uzbekistan.gif vanuatu.gif vaticancity.gif venezuela.gif vietnam.gif virginislands.gif wales.gif yemen.gif yugoslavia.gif zambia.gif zimbabwe.gif

Other flags:
jollyroger.gif redcross.gif

Holidays:
birthday.gif Christmas-12.gif Christmas-candycane.gif Christmas-candycane2.gif Christmas-cc.gif Christmas-christmas3.gif Christmas-christmascandle.gif Christmas-christmastree.gif Christmas-christmaswreath.gif Christmas-elf.gif Christmas-frosty.gif Christmas-gingerbreadhouse.gif Christmas-holidaylight.gif Christmas-mistletoe.gif Christmas-ornament.gif Christmas-rudolph.gif Christmas-santa2.gif Christmas-santa3.gif Christmas-santaclaus.gif Christmas-santahat.gif Christmas-snowball.gif Christmas-snowman.gif Christmas-snowman2.gif Christmas-snowman3.gif Christmas-stocking.gif Christmas-tree.gif Christmas-wreath.gif Christmas-xmas.gif Christmas-xmas3.gif Christmas-xmasnorthpole.gif Christmas-xmas-smiley4.gif Christmas-xmastree.gif Christmas-xmasunwrap2.gif cincodemayo.gif clover.gif dreidel.gif easteregg.gif firecracker.gif flagday.gif Halloween-bat.gif Halloween-evilpumpkin.gif Halloween-halloween.gif Halloween-haloweencat.gif Halloween-haloweenpumpkin.gif Halloween-pumpkin2.gif Halloween-witch.gif Halloween-witching.gif jack-o-lantern.gif menorah.gif pinata.gif present.gif redpoppy.gif

Miscellaneous:
3dglasses.gif 16tons.gif afro.gif airplane.gif ambulance.gif amish.gif anchor.gif arrowthruhead.gif ashamed.gif ashamed2.gif ashamed3.gif ashamed4.gif ashamed05.gif ashamed6.gif ashamed7.gif ashamed_smilie.gif babybonnet.gif bat.gif bawling.gif beady.gif begging.gif beret.gif bigmouth.gif bigwheels.gif bitelip.gif biting.gif blimp.gif blindfold.gif blockhead.gif blonde.gif blush.gif boat.gif boggled.gif bored.gif bowtie.gif boxedin.gif braces.gif brainiac.gif bullwhip.gif burp.gif bus.gif business-americanexpress.gif business-applecomputer.gif business-ballpointpen.gif business-battery.gif business-briefcase.gif business-cellphone.gif business-clipboard.gif business-clock.gif business-computer.gif business-computermouse.gif business-discover.gif business-envelope.gif business-floppydisk.gif business-fountainpen.gif business-keyboard.gif business-laptop.gif business-mastercard.gif business-notebook.gif business-paperclip.gif business-papershredder.gif business-pencil.gif business-pushpin.gif business-scissors.gif business-telephone.gif business-trash.gif business-visa.gif butthead.gif cap.gif car2.gif censored.gif cheeky.gif cold.gif conehead.gif conicalhat.gif convertible.gif cool-0001.gif cool-0002.gif cool-0003.gif cool-0004.gif cool-0005.gif cool-0006.gif cool-0007.gif cool-0008.gif cool-0009.gif cool-0010.gif cool-0011.gif cool-0012.gif cool-0014.gif cool-0015.gif cool-0016.gif cool-0017.gif cool-0018.gif cool-0019.gif cool-0020.gif cool-0021.gif cool-0022.gif cool-0023.gif cool-0024.gif cool-0025.gif cool-0026.gif cool-0027.gif cool-0028.gif cool-0029.gif cool-0030.gif cool-0031.gif cool-0032.gif cool-0033.gif cool-0034.gif cool-0035.gif cool-0036.gif cool-0037.gif cool-0038.gif cool-0039.gif cool-0040.gif cool-0041.gif cool-0042.gif cool-0043.gif cool-0044.gif cool-0045.gif cool-0046.gif coonskincap.gif covereyes.gif crazy.gif crowded.gif cryingeyesout.gif curlers.gif devil.gif disguise.gif dizzy.gif dopey.gif dreadlocks.gif drool.gif drunk2.gif duck.gif duh.gif dumptruck.gif dunce.gif evil-grin0001.gif evil-grin0002.gif evil-grin0003.gif evil-grin0004.gif evil-grin0005.gif evil-grin0006.gif evil-grin0007.gif evil-grin0008.gif evil-grin0009.gif evil-grin0010.gif evil-grin0011.gif evil-grin0012.gif evil-grin0013.gif evil-grin0014.gif evil-grin0015.gif evil-grin0016.gif evil-grin0017.gif evil-grin0018.gif evil-grin0019.gif evil-grin0020.gif evil-grin0021.gif evil-grin0022.gif evil-grin0023.gif evil-grin0024.gif evil-grin0025.gif evil-grin0026.gif evil-grin0027.gif evil-grin0028.gif evil-grin0029.gif evil-grin0030.gif evil-grin0031.gif evil-grin0032.gif evil-grin0033.gif evil-grin0034.gif evil-grin0035.gif evil-grin0036.gif evil-grin0037.gif evil-grin0038.gif evil-grin0039.gif evil-grin0040.gif evil-grin0041.gif evil-grin0042.gif evil-grin0043.gif evil-grin0044.gif evil-grin0045.gif evil-grin0046.gif evilpumpkin.gif expressionless.gif eyebrow.gif eyebrows.gif eye-popping.gif faint.gif fantasy-alien.gif fantasy-blackcat.gif fantasy-broomstick.gif fantasy-cyclops.gif fantasy-darkside.gif fantasy-dragon.gif fantasy-fairy.gif fantasy-flyingspaghetti.gif fantasy-frankenstein.gif fantasy-genie.gif fantasy-ghost.gif fantasy-gnome.gif fantasy-gnome-female.gif fantasy-goodwitch.gif fantasy-medusa.gif fantasy-mummy.gif fantasy-ogre.gif fantasy-skull.gif fantasy-troll.gif fantasy-ufo.gif fantasy-unicorn.gif fantasy-vampire.gif fantasy-vulcan.gif fantasy-werewolf.gif fantasy-wickedwitch.gif fantasy-zombie.gif f-bomb.gif fever.gif fez.gif fiery.gif fight.gif fighting-0001.gif fighting-0002.gif fighting-0003.gif fighting-0004.gif fighting-0005.gif fighting-0006.gif fighting-0007.gif fighting-0008.gif fighting-0009.gif fighting-0010.gif fighting-0011.gif fighting-0012.gif fighting-0013.gif fighting-0014.gif fighting-0015.gif fighting-0016.gif fighting-0017.gif fighting-0018.gif fighting-0019.gif fighting-0020.gif fighting-0021.gif fighting-0022.gif fighting-0023.gif fighting-0024.gif fighting-0025.gif fighting-0026.gif fighting-0027.gif fighting-0028.gif fighting-0029.gif fighting-0030.gif fighting-0031.gif fighting-0032.gif fighting-0034.gif fighting-0035.gif fighting-0036.gif fighting-0037.gif fighting-0038.gif fighting-0039.gif fighting-0040.gif fighting-0041.gif fighting-0042.gif fighting-0043.gif fighting-0044.gif fighting-0045.gif fighting-0046.gif fighting-0047.gif fighting-0049.gif fighting-0050.gif fighting-0051.gif fighting-0052.gif fighting-0053.gif fighting-0054.gif fighting-0055.gif fighting-0056.gif fighting-0057.gif fighting-0058.gif fighting-0059.gif fighting-0060.gif fighting-0061.gif fighting-0062.gif fighting-0063.gif fighting-0064.gif fighting-0065.gif fighting-0066.gif fighting-0067.gif fighting-0068.gif fighting-0069.gif fighting-0070.gif fighting-0071.gif fighting-0072.gif fighting-0073.gif fighting-0074.gif fighting-0075.gif fighting-0076.gif fighting-0077.gif fighting-0078.gif fighting-0079.gif fighting-0080.gif fighting-0081.gif fighting-0082.gif fighting-0083.gif fighting-0084.gif fighting-0085.gif fighting-0086.gif fighting-0087.gif fighting-0088.gif fighting-0089.gif fighting-0090.gif fighting-0091.gif fighting-0092.gif fighting-0093.gif fighting-0094.gif fighting-0095.gif fighting-0096.gif fighting-0098.gif flamed.gif flattop.gif footinmouth.gif fryingpan.gif gasp.gif geezer.gif glasses.gif glasses-rose.gif glasses-slip.gif gloomy.gif gnasher.gif graduate.gif grandma.gif grandpa.gif greedy.gif grumpy.gif guilty.gif half.gif happy-angel.gif happy-applause.gif happy-awesome.gif happy-bouncy.gif happy-chat.gif happy-cheerful.gif happy-cloud9.gif happy-crackup.gif happy-cutie.gif happy-fluffy.gif happy-goodvibes.gif happy-highfive.gif happy-hyper.gif happy-innocent.gif happy-jump.gif happy-laughing.gif happy-number1.gif happy-optimist.gif happy-rotfl.gif happy-slaphappy.gif happy-tearsofjoy.gif happy-thumbsup.gif happy-veryhappy.gif happy-wave.gif happy-whistling.gif happy-yes.gif happy-yummy.gif headache.gif headband.gif headbanger.gif headinsand.gif heartthrob.gif heavybreathing.gif helicopter.gif hissyfit.gif hot.gif hotairballoon.gif huge.gif hypnotized.gif idea.gif ill.gif indifferent.gif irked.gif jaded.gif jaw-dropping.gif jekyll-hyde.gif jumping-0001.gif jumping-0002.gif jumping-0003.gif jumping-0004.gif jumping-0005.gif jumping-0006.gif jumping-0007.gif jumping-0008.gif jumping-0009.gif jumping-0010.gif jumping-0011.gif jumping-0012.gif jumping-0013.gif jumping-0014.gif jumping-0015.gif jumping-0016.gif jumping-0017.gif jumping-0018.gif jumping-0019.gif jumping-0020.gif jumping-0021.gif jumping-0023.gif jumping-0025.gif jumping-0026.gif jumping-0027.gif jumping-0028.gif jumping-0029.gif jumping-0030.gif jumping-0032.gif jumping-0033.gif jumping-0034.gif jumping-0035.gif jumping-0036.gif jumping-0038.gif jumping-0039.gif jumping-0040.gif jumping-0041.gif jumping-0042.gif jumping-0043.gif jumping-0044.gif jumping-0045.gif jumping-0046.gif jumping-0048.gif jumping-0049.gif jumping-0050.gif jumping-0051.gif knockout.gif lei.gif liar.gif listen.gif lookaround.gif loser.gif love-0001.gif love-0002.gif love-0003.gif love-0004.gif love-0005.gif love-0006.gif love-0007.gif love-0008.gif love-0009.gif love-0010.gif love-0011.gif love-0012.gif love-0013.gif love-0014.gif love-0015.gif love-0016.gif love-0017.gif love-0018.gif love-0019.gif love-0020.gif love-0021.gif love-0022.gif love-0023.gif love-0024.gif love-0025.gif love-0026.gif love-0027.gif love-0028.gif love-0029.gif love-0030.gif love-0031.gif love-0032.gif love-0033.gif love-0034.gif love-0035.gif love-0036.gif love-0037.gif love-0038.gif love-0039.gif love-0040.gif love-0041.gif love-0042.gif love-0043.gif love-0044.gif love-0045.gif love-0046.gif love-0047.gif love-0048.gif love-0049.gif love-0050.gif love-0051.gif love-0052.gif love-0053.gif love-0054.gif love-0055.gif love-0056.gif love-0057.gif love-0058.gif love-0059.gif love-0060.gif love-0061.gif love-0062.gif love-0063.gif love-0064.gif love-0065.gif love-0066.gif love-0067.gif love-0068.gif love-0069.gif love-0070.gif love-0071.gif love-0072.gif love-0073.gif love-0074.gif love-0075.gif love-0076.gif love-0077.gif love-0078.gif love-0079.gif love-0080.gif love-0081.gif love-0082.gif love-0083.gif love-0084.gif love-0085.gif love-0086.gif love-0087.gif love-0088.gif magnify.gif marsrover.gif masked.gif meditate.gif melodramatic.gif melting.gif military-camouflage.gif military-coastguard.gif military-drillsergeant.gif military-eagleglobeanchor.gif military-flag-airforce.gif military-flag-army.gif military-flag-coastguard.gif military-flag-marines.gif military-flag-navy.gif military-m1helmet.gif military-marine8point.gif military-medalofhonor.gif military-officer1.gif military-officer2.gif military-officer3.gif military-officer4.gif military-officer5.gif military-officer6.gif military-officer6n.gif military-officer7.gif military-officer8.gif military-officer9.gif military-officer10.gif military-pow-mia.gif military-ranka-cpl.gif military-ranka-msg.gif military-ranka-pfc.gif military-ranka-pv2.gif military-ranka-sfc.gif military-ranka-sgm.gif military-ranka-sgt.gif military-ranka-spc.gif military-ranka-ssg.gif military-ranka-wo1.gif military-ranka-wo2.gif military-ranka-wo3.gif military-ranka-wo4.gif military-ranka-wo5.gif military-rankf-a1c.gif military-rankf-amn.gif military-rankf-cmsgt.gif military-rankf-msgt.gif military-rankf-smsgt.gif military-rankf-sra.gif military-rankf-ssgt.gif military-rankf-tsgt.gif military-rankm-cpl.gif military-rankm-gysgt.gif military-rankm-lcpl.gif military-rankm-msgt.gif military-rankm-pfc.gif military-rankm-sgt.gif military-rankm-sgtmaj.gif military-rankm-ssgt.gif military-rankm-wo1.gif military-rankm-wo2.gif military-rankm-wo3.gif military-rankm-wo4.gif military-rankm-wo5.gif military-rankn-cpo.gif military-rankn-mcpo.gif military-rankn-po1.gif military-rankn-po2.gif military-rankn-po3.gif military-rankn-sa.gif military-rankn-scpo.gif military-rankn-sn.gif military-rankn-wo1.gif military-rankn-wo2.gif military-rankn-wo3.gif military-rankn-wo4.gif military-rankn-wo5.gif mind-blowing.gif mischievous.gif misspeak.gif mohawk.gif moped.gif moptop.gif mullet.gif muted.gif muttering.gif nailpolish.gif nature-acorn.gif nature-bubble.gif nature-cactus.gif nature-earth.gif nature-eye.gif nature-female.gif nature-fire.gif nature-flower.gif nature-greenthumb.gif nature-leaf.gif nature-log.gif nature-male.gif nature-moon.gif nature-palmtree.gif nature-saturn.gif nature-shootingstar.gif nature-star.gif nature-tree.gif nature-tumbleweed.gif nature-violet.gif neenerneener.gif no.gif nosy.gif oath.gif occupation-astronaut.gif occupation-balletdancer.gif occupation-blacksmith.gif occupation-chef.gif occupation-clown.gif occupation-construction.gif occupation-cop.gif occupation-cowboy.gif occupation-cowgirl.gif occupation-crocheter.gif occupation-detective.gif occupation-doctor.gif occupation-firefighter.gif occupation-flightattendant.gif occupation-fortuneteller.gif occupation-gangster.gif occupation-gardener.gif occupation-janitor.gif occupation-jester.gif occupation-judge.gif occupation-king.gif occupation-knight.gif occupation-madhatter.gif occupation-magician.gif occupation-miner.gif occupation-ninja.gif occupation-nurse.gif occupation-pirate.gif occupation-princess.gif occupation-privateeye.gif occupation-queen.gif occupation-reporter.gif occupation-scubadiver.gif occupation-shepherd.gif occupation-shipcaptain.gif occupation-stripper.gif occupation-teacher.gif occupation-wizard.gif ouch.gif oxygentank.gif paperbag.gif party2.gif party-0001.gif party-0002.gif party-0003.gif party-0004.gif party-0005.gif party-0006.gif party-0007.gif party-0008.gif party-0009.gif party-0010.gif party-0011.gif party-0012.gif party-0013.gif party-0014.gif party-0015.gif party-0016.gif party-0017.gif party-0018.gif party-0019.gif party-0020.gif party-0021.gif party-0022.gif party-0023.gif party-0024.gif party-0025.gif party-0026.gif party-0028.gif party-0029.gif party-0030.gif party-0031.gif party-0032.gif party-0033.gif party-0034.gif party-0035.gif party-0036.gif party-0037.gif party-0038.gif party-0039.gif party-0040.gif party-0041.gif party-0042.gif party-0043.gif party-0044.gif party-0045.gif party-0046.gif party-0047.gif party-0048.gif party-0049.gif party-0050.gif party-0051.gif party-0052.gif party-0053.gif pearlclutching.gif peepingtom.gif pessimist.gif picknose.gif pierced.gif pilgrim.gif pioneerbonnet.gif pray2.gif profile.gif propeller.gif proposetoast.gif psst.gif pullinghair.gif pumpkin2.gif punch.gif puzzled.gif raspberry.gif razz.gif reading.gif redhead.gif relieved.gif roadblock.gif rocket.gif rollingeyes.gif romance-bouquet.gif romance-bride.gif romance-brokenheart.gif romance-candyheart.gif romance-couple.gif romance-cupid.gif romance-diamondring.gif romance-flirt.gif romance-groom.gif romance-heart.gif romance-heartbeat.gif romance-hug.gif romance-hugonwings.gif romance-iloveusign.gif romance-kiss.gif romance-loveatfirstsight.gif romance-lovestruck.gif romance-puckerup.gif romance-rose.gif romance-smooch.gif romance-valentine.gif romance-weddingbells.gif romance-weddingcake.gif rottentomato.gif sad0001.gif sad0002.gif sad0003.gif sad0004.gif sad0005.gif sad0006.gif sad0007.gif sad0008.gif sad0009.gif sad0010.gif sad0011.gif sad0012.gif sad0013.gif sad0014.gif sad0015.gif sad0016.gif sad0017.gif sad0018.gif sad0019.gif sad0020.gif sad0021.gif sad0022.gif sad0023.gif sad0024.gif sad0025.gif sad0026.gif sad0027.gif sad0028.gif sad0029.gif sad0030.gif sad0031.gif sad0032.gif sad0033.gif sad0034.gif sad0035.gif sad0036.gif sad0037.gif sad0038.gif sad0039.gif sad0040.gif sad0041.gif sad0042.gif sad0043.gif sad0044.gif sad0045.gif sad0046.gif sad0047.gif sad0048.gif sad0049.gif sad0050.gif sad0051.gif sad0052.gif sad0053.gif sad0054.gif sad0056.gif sad0057.gif sad0058.gif sad0059.gif sad0060.gif sad0061.gif sad0062.gif sad0063.gif sad0064.gif sad0065.gif sad0066.gif sad0067.gif sad0068.gif sad0069.gif sad0070.gif sad0071.gif sad0072.gif sad0073.gif sad0074.gif sad0075.gif sad0076.gif sad0077.gif sad0078.gif sad0079.gif sad0080.gif sad0081.gif sad0082.gif sad0083.gif sad0084.gif sad0085.gif sad0086.gif sad0087.gif sad0088.gif sad0089.gif sad0090.gif sad0091.gif sad0092.gif sad0093.gif sad0094.gif sad0095.gif sad0096.gif sad0097.gif sad0098.gif sad0099.gif sad0100.gif sad0101.gif sad0102.gif sad0103.gif sad0104.gif sad0105.gif sad0106.gif sad0107.gif sad0108.gif sad0109.gif sad0110.gif sad0111.gif sad0112.gif sad0113.gif sad0114.gif sad0115.gif sad0116.gif sad0117.gif sad0118.gif sad0119.gif sad0120.gif sad0122.gif sad0123.gif sad0124.gif sad0125.gif sad0126.gif sad0127.gif sad0128.gif sad0129.gif sad0130.gif sad0131.gif sad0132.gif sad0133.gif sad0134.gif sad0135.gif sad0136.gif sad0137.gif sad0138.gif sad0139.gif sad0140.gif sad0141.gif sad0142.gif sad0143.gif sad0144.gif sad0145.gif sad0146.gif sad0147.gif sad0148.gif sad0149.gif salute.gif scared.gif scared-0001.gif scared-0002.gif scared-0003.gif scared-0004.gif scared-0005.gif scared-0006.gif scared-0007.gif scared-0008.gif scared-0009.gif scared-0010.gif scared-0011.gif scared-0012.gif scared-0013.gif scared-0014.gif scared-0015.gif scared-0016.gif scared-0017.gif scratchchin.gif semitrailer.gif shades.gif shhh.gif shield.gif shiftyeyes.gif shocked.gif shy.gif sick-0001.gif sick-0002.gif sick-0003.gif sick-0004.gif sick-0005.gif sick-0006.gif sick-0007.gif sick-0008.gif sick-0009.gif sick-0010.gif sick-0011.gif sick-0012.gif sick-0013.gif sick-0014.gif sick-0015.gif sick-0016.gif sick-0017.gif sick-0018.gif sick-0019.gif sick-0020.gif sick-0021.gif sick-0022.gif sick-0023.gif sick-0024.gif sick-0025.gif sick-0026.gif sigh.gif sly.gif smirk.gif snaggletooth.gif sneeze.gif snooty.gif soapbox.gif sombrero.gif sorry.gif sour.gif spaceshuttle.gif spin.gif spit.gif splat.gif starry-eyed.gif steeringwheel.gif stinkyfeet.gif stirthepot.gif stopsign.gif stretch.gif swami.gif sweatdrop.gif swirl.gif symbols-abcblock.gif symbols-alert.gif symbols-anchor.gif symbols-arrow.gif symbols-balletslipper.gif symbols-balloon.gif symbols-ban.gif symbols-bandaid.gif symbols-blueribbon.gif symbols-bomb.gif symbols-bone.gif symbols-book.gif symbols-boxershorts.gif symbols-broom.gif symbols-bullhorn.gif symbols-camera.gif symbols-candle.gif symbols-candlestick.gif symbols-checkmark.gif symbols-chillpill.gif symbols-circustent.gif symbols-comedy.gif symbols-crossfingers.gif symbols-crystalball.gif symbols-cubist.gif symbols-cuckooclock.gif symbols-dollarsign.gif symbols-down.gif symbols-emoticon.gif symbols-fan.gif symbols-ferriswheel.gif symbols-filmstrip.gif symbols-flask.gif symbols-forbidden.gif symbols-gavel.gif symbols-hammer.gif symbols-hourglass.gif symbols-house.gif symbols-hypnodisk.gif symbols-ipod.gif symbols-jigsaw.gif symbols-key.gif symbols-lifepreserver.gif symbols-lightbulb.gif symbols-lock.gif symbols-magicwand.gif symbols-magnet.gif symbols-magnifyglass.gif symbols-mailbox.gif symbols-mallet.gif symbols-money.gif symbols-moneybag.gif symbols-newspaper.gif symbols-nosmoking.gif symbols-pacifier.gif symbols-paintbrush.gif symbols-paintcan.gif symbols-palette.gif symbols-peace.gif symbols-plug.gif symbols-point.gif symbols-prescription.gif symbols-purse.gif symbols-quillpen.gif symbols-reminder.gif symbols-remotecontrol.gif symbols-school.gif symbols-scroll.gif symbols-sewmachine.gif symbols-shoppingcart.gif symbols-shovel.gif symbols-slipper.gif symbols-socks.gif symbols-sonar.gif symbols-spool.gif symbols-stop.gif symbols-sword.gif symbols-thumbsdown.gif symbols-thumbsup.gif symbols-toiletpaper.gif symbols-tombstone.gif symbols-tragedy.gif symbols-treasure.gif symbols-tv.gif symbols-twocents.gif symbols-up.gif symbols-washingmachine.gif symbols-wrench.gif symbols-x.gif symbols-yarn.gif symbols-yinyang.gif symbols-yo-yo.gif talktothehand.gif tartanberet.gif thumbsdown.gif tilt.gif timebomb.gif tinfoilhat.gif tiny.gif tire.gif tired.gif titanic.gif tongue.gif tongue-tied.gif toothache.gif tophat.gif trafficcone.gif trafficlight.gif turban.gif umbrella.gif uninvolved.gif upsidedown.gif uvula.gif vomit.gif warped.gif wart.gif weather-cloud.gif weather-hurricane.gif weather-lightningbolt.gif weather-moon.gif weather-partlycloudy.gif weather-rainbow.gif weather-raincloud.gif weather-raindrop.gif weather-smallcraftwarning.gif weather-snowflake.gif weather-stormwarning.gif weather-sun.gif weather-sunrise.gif weather-tornado.gif weather-tropicalstorm.gif weather-umbrella.gif weather-windy.gif weepy.gif wheelchair.gif whistleblower.gif wide-eyed.gif winking01.gif winking02.gif winking03.gif winking04.gif winking05.gif winking06.gif winking07.gif winking08.gif winking09.gif winking10.gif winking11.gif winking12.gif winking13.gif winking14.gif winking15.gif winking16.gif winking17.gif winking18.gif winking19.gif winking20.gif winking21.gif winking22.gif winking23.gif winking24.gif winking25.gif winking26.gif winking27.gif winking28.gif winking29.gif winking30.gif winking31.gif winking32.gif winking33.gif winking34.gif winking35.gif winking36.gif winking37.gif winking38.gif winking39.gif winking40.gif winking41.gif winking42.gif winking43.gif winking44.gif winking45.gif winking46.gif winking47.gif winking48.gif winking49.gif winking50.gif winking51.gif winking52.gif winking54.gif winking55.gif winking56.gif winking57.gif winking58.gif winking59.gif winking60.gif winking61.gif winking62.gif winking63.gif winking64.gif winking65.gif winking66.gif winking67.gif winking68.gif winking69.gif winking70.gif winking71.gif winking72.gif winter.gif witch.gif witching.gif wolfwhistle.gif worried.gif yawn.gif yell.gif yikes.gif yuck.gif ziplip.gif zorro.gif zzz.gif

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!

A journey of a thousand miles... blah, blah, blah. smilie.png

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?? banghead.gif

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! thumbsup.gif

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...
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.
Oh, ok. It's the MCB.

Ok that makes sense, right?. 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.
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.

Output of the MS-DOS MEM command. Output of the FreeDOS MEM command.
Output of the MS-DOS MEM command compared to 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!

7/5/2021 - With apologies to Bill Atkinson...

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!
Ah! User friendliness abounds! hello.gif

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* biggrin.png

"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.
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!

I never really was happy with how tags were handled on this blog, and the mechanism for resetting the tag filter (clicking the title at the top of the page, if you didn't remember) is just plain janky. Alas, it was a quick hack to add functionality until I had more time to write the additional JavaScript needed to make things better. Well that day is today! Now tags are added to each blog entry dynamically using a custom attribute in the HTML code of each, as oppose to the old way of manually writing a detailed series of HTML for each and every tag. Also, there's now a reset option which appears automatically above the entries when any filtering is active. Enjoy!

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 oops.png

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.

Mid-2011 Original 2021 Refresh
Fingertip OS Fingertip
32-bit Motorola 68000 processor @ 8 MHz CPU 32-bit Motorola 68000 CPU

variable clock generator 100 kHz - 68 MHz (I2C 0x16 or 0x17)

clock buffer (if needed)
8 MiB, 55 ns - 16 @ 512 KiB each

8 MiB I/O space 		Memory 4 MiB Flash, 70 ns (0x000000-0x3FFFFF)
ROM for bootloader, OS, and applications

4 MiB I/O space (0x400000-0x7FFFFF)
Will eventually be grouped into the existing 4 MiB ROM space, freeing up address space for more SRAM

8 MiB SRAM, 55 ns (0x800000-0xFFFFFF)
4.3" 480x272 24-bit color LCD

4.3" Touch Screen 		Display 5" 800x480 24-bit color LCD with integrated touch panel
120.8 mm x 75.9 mm
SD memory card slot Storage Dual micro SD memory card slots
Built-in microphone

Built-in stereo speakers

Combo stereo headphone/microphone jack 		Audio Audio jack (3.5mm headphone / mic combo, side-mounted)

Audio recording & playback

16-bit ADC

16-bit DAC
8 AA batteries
(2 banks of 4 @ 2.5 amps per bank, 5 amps total) 		Power 4 AA batteries
(2.5 amps total)

Battery contacts: linkage, positive, negative

3.3V regulator

5V regulator

ADC
For measuring battery power (connected to output of 5V regulator)
Bluetooth capability

Cellular modem

FM radio receiver

FM radio transmitter 		Communications AM/FM transceiver

Bluetooth 5.2 transceiver

IR transceiver

RF transceiver
High intensity white LED for camera flash / flashlight

IR LED in back for night recording

Tri-color LED controllable by software (red, green and yellow) 		Indicators High-intensity flashlight (white, top-mounted)

LED Controller (I2C 0xE0)

Tri-color status LED, top-mount and side-mount
Hardware cellular disable switch

Ambient temperature and humidity sensor

Compass

GPS receiver

High resolution camera/video recorder

Light sensor (front-mounted)

Magnetic field sensor

Orientation sensor 		Extra Hardware / Features Ambient Light & proximity sensor (I2C 0x60)

GPS receiver

Gyroscope & Temperature sensor (I2C 0x68 or 0x69)

Humidity sensor (I2C 0x27)

I2C Controller

Micro USB connector

Pressure Sensor (I2C 0x5D)

RTC (I2C 0x52)

Stylus
PLA plastic

Single-color FDM

0.28 mm layer process 		Case PLA plastic

Multi-color FDM

0.08 mm layer process
Power Buttons On/off slide switch, top-mounted

Up / Down buttons, 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! laugh.gif 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.

Stay tuned! popcorn.png

3/31/2021 - What were you expecting, Lorem Ipsum? looney.gif

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 43, 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.

-1 XXXXXX
00 XXXVLL
01 XXXBBF
02 XXCCFG
03 XXCDDM
04 XXCOGX
05 XXMVML
06 XXMBCF
07 XXVCXG
08 XXVGOM
09 XXVLLX
10 XXGMFL
11 XXGFDF
12 XXDXGG
13 XXDGVM
14 XXDLMX
15 XXFMXL
16 XXFDOF
17 XXFOLG
18 XXBVBM
19 XXBBFX
20 XXLCGL
21 XXLDVF
22 XXLOMG
23 XXOVCM
24 XXOBXX
25 XCXXLL
26 XCXGBF
27 XCXLFG
28 XCCMDM
29 XCCFGX
30 XCMXML
31 XCMGCF
32 XCMLXG
33 XCVCOM
34 XCVDLX
35 XCVOFL
36 XCGVDF
37 XCGBGG
38 XCDCVM
39 XCDDMX
40 XCDOXL
41 XCFMOF
42 XCFFLG
43 XCBXBM

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. lol.png

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 <i>look</i> at that turn of the century engineering!
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 thumbsup.gif) 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... laugh.gif)

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.
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. wink.png

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! biggrin.png) 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. laugh.gif

The completed 3D model. Freshly-printed parts, pre-assembly. The assembled product. Voila!

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 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. And once I had a fully modeled object, it was time to run it through Cura, 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 initial problem.

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. cool.png


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!
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 by itself. The base with corner support rails attached. The top gantry assembly attached. The Z-axis screws and heated bed bolted in. Also, the spool holder attached in the wrong place! Before wiring. After wiring - and power on! <img src = 'media/emojis/woohoo.gif' alt = 'woohoo.gif'><br>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? biggrin.png

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.

But, as we say when approaching a tall piece of cheddar, better start from the top.

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.

https://thatoneprivacysite.net/#simple-vpn-comparison

7/2/2020 - New JavaScript files. No pun intended. laugh.gif

I recently decided to add a feature to an existing work project to allow users to save and load preferences as will, and as such needed a small library to allow easy saving and loading of files from within JavaScript. I happened upon this post by Tobias Amdahl which provided almost exactly the code I needed. After a few tweaks, I whipped up Files.js and the associated Files Demo.html available in the JavaScript section of the Downloads page.

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.

While working on a coding project at work today, I came across a small oversight in WordSplit.js - the code will throw an error if the input string is undefined. I made a correction to the code and the new version is available in the JavaScript section of the Downloads page.

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. five.gif

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. thinking.png

Ideal OS: An Epic Tale of Irrationality
Ideal OS Part II: The User Interface
Ideal OS Part III: User Attention Is Sacred

Ideal OS: Rebooting the Desktop Operating System Experience

4/18/2020 - Some blog tweaks

For a long time now, I've wanted to add the ability to automatically filter based on a tag name or date specified at the end of this blog's URL. Finally, I added a little JavaScript to do just this; you can now add '?tag=value or ?date=date at the end, and the blog will show only what matches! This will make it handy to link specific posts or tags to others, or to bookmark specific tags for those who only want to follow progress on one topic. Additionally, you no longer need to reload the page entirely to reset the filter and show all posts again; instead you can now simply click the title at the top of this blog.

Enjoy! cool.png

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) Y y Y y Y N N
7Zip 16.02 (Linux) Y Y Y Y N N N
ADVZIP 2.1 (DOS) Y y Y y Y N Y
InfoZip 2.32 (DOS) Y y Y y Y N Y
InfoZip 3.0 (Linux) Y Y Y Y N N Y
PKZIP 1.1 (DOS) Y y Y y n Y Y
PKZIP 2.04g (DOS) Y y Y y Y N Y

Legend:
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.

Alas the work projects stretch on, and once again I find myself needing a function not easily offered in bare JavaScript itself. My day job offers us our choice of browser (Chrome, IE, Edge, Firefox) however, for my purposes, Chrome has easily proven itself the most responsive and versatile - not to mention I use Chromium exclusively on my home systems - therefore I program exclusively to it out of both convenience and familiarity. "But wait!" the astute among you may exclaim, "Isn't it bad practice to not support a wide as possible user base?" It sure is. However, since I write most of my code in between my other assignments, I will dutifully choose whatever route proves most conducive to my work. cool.png Enter BrowserGet.js (demo available here) - a quick way to ascertain which browser is running my (and now, if you so desire, your!) code. Now perhaps I can stop dealing with IE-loving co-workers complaining that my tools don't work!

3/11/2020 - My code at work. Literally. laugh.gif

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.

So... wait. This involves parsing blocks of text? Generated by humans, and therefore non-uniform? IT may be quite right about the impossibility of this... if you cling only to JavaScript's built-in offerings. But me? I have a secret weapon - a certain piece of code I wrote long ago. Count me in!

Here we are weeks later, and WordSplit (the JavaScript port of my aforementioned code - demo available here) proved the perfect fit for the job. But what good is it to parse all this data if you can't sort it? I therefore found myself needing to quickly collate the resultant thousands of words, leading me on a search for the fastest sorting algorithm available.

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. smilie.png

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!!
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 stickouttongue.png) 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! cool.png

3/9/2020 - About the recent downtime.

You may have noticed that everyone's favorite project site (that's this one biggrin.png) 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! relaxed.png

3/9/2020 - Blog condensing completed! (At least for now! mrgreen.png)

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! driver.gif

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."

- DTACK Grounded, Issue 1

3/7/2020 - All your emojis are belong to me.

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.

PNGs:
angry.png biggrin.png confused.png cool.png eek.png frown.png lol.png oops.png popcorn.png rolleyes.png smileflower.png smilie.png stickouttongue.png thinking.png wink.png

GIFs:
accordion.gif akomjiis.gif AmericanFlagWave.gif angeldemon.gif banannadance.gif banannadancelong.gif banannadancelove.gif banannadanceparty.gif band.gif band2.gif banghead.gif beer.gif bsflag.gif bump.gif car.gif cheer.gif cheers.gif colorcyclebar.gif couple.gif crapfan.gif crying.gif dancing.gif driver.gif drunk.gif dunno.gif explode.gif five.gif fivestarpost.gif flowerskiss.gif goodnight.gif goodpost.gif grouphug.gif guitarist.gif happybirthday.gif harp.gif hattip.gif headbang.gif heartcircle.gif hello.gif hiding.gif knuddel.gif laugh.gif looney.gif monster.gif nospam.gif party.gif peace.gif pepsi.gif piano.gif pray.gif questionmark.gif reaper.gif rimshot.gif rock.gif rofl.gif rofl2.gif rose.gif SantaClaus.gif shark.gif thisthreadisworthlesswithoutpics.gif thumbsup.gif transmit.gif violin.gif winner.gif woohoo.gif

Edit: Here's some more from another forum!
angry.png anguished.png astonished.png bawling.png blush.png coldsweat.png confounded.png confused.png cookie.png cry.png disappointed.png dizzy.png expressionless.png fearful.png flushed.png frowning.png greyquestion.png grimace.png grin.png heart.png heartbreak.png hushed.png innocent.png joy.png kiss.png kissingclosedeyes.png kissingheart.png kissingsmilingeyes.png lol.png love.png mask.png mrgreen.png naughty.png neutral.png nomouth.png openmouth.png pensive.png persevere.png rage.png relaxed.png relieved.png scream.png sleeping.png sleepy.png smile.png smiley.png smirk.png star.png sunglasses.png sweat.png sweatsmile.png thumbdown.png thumbup.png tiredface.png tongue.png triumph.png trollface.png unamused.png warning.png weary.png wink.png worried.png yum.png

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."

- Me

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.
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.

Enough said.
Enough said.

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.

Zero... one... two... three... four... five... six... seven... twenty four?
Zero... one... two... three... four... five... six... seven... twenty four?

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?
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.

<b>YEAH!</b> Finally!!
YEAH! Finally!!

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...
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.
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?
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!

2/1/2020

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!

10/20/2017

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! laugh.gif 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! oops.png

8/18/2017

I recently got a new laptop which came with Windows 10 and decided Linux Mint would be better than that eyesore. laugh.gif
I liked it so much there that I swapped my desktop to it as well. I'm officially a Linux-only user! cool.png

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.

7/1/2017

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.

6/3/2017

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... biggrin.png

...and with the components in place, awaiting soldering.

2/2/2017

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 year month week. So what am I going to do? Well, am I ever glad you asked... wink.png

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?

8/30/2016

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.

7/1/2016

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 angry.png

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?? <img src = 'media/emojis/large/flushed.png' alt = 'flushed.png'>

6/28/2016

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 bawling.png 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. biggrin.png

6/17/2016 - Lookie what arrived!

5/27/2016

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. biggrin.png

So what have I been doing with the spare time I've had in the past year?

Hope everyone here is doing well! smilie.png

[/checkin]

5/9/2015

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.

4/29/2015

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.

4/27/2015

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:

Pros:
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.

Cons:
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?

4/16/2015

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.

4/14/2015

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. smilie.png

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...

laugh.gif

7/28/2014

I must say, once you get accustomed to the style of Eagle, it's much easier to get work done! I'm liking this. smilie.png

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! smilie.png

EPiCDevBoardRevision1.png

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.

7/13/2014

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. neutral.png

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?

7/8/2014

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."

$1000.00?!? eek.png

7/8/2014

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 prototype 1. 68060 Adapter prototype 2.

7/7/2014

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.

7/4/2014

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. frown.png

7/2/2014

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. biggrin.png

Next up: once my new batch of breadboard wires comes in, the address decoder goes in place.

6/28/2014

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. smilie.png

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

6/21/2014

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! smilie.png

6/11/2014 - IT CAME!

Lookie what was on my desk when I got home today. smilie.png

2/25/2014

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!

9/11/2013

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?

9/9/2013

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!!!

party.gif

Your homework assignment: Flash the original version, then the latest version just to see how far it's come in the past year. biggrin.png

9/9/2013

It's that time again... biggrin.png

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! smilie.png

8/14/2013

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 smilie.png' - 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 stickouttongue.png 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 (rock.gif YEAH!! rock.gif) 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*

Stay tuned!

And now, a word from my late-night HTML coding playlist!

5/31/2013

Check out the Warp OEM 2.51 to 2.53 Update patch! Now available in the download center smilie.png

5/24/2013

After an initial FC, Swipe-to-Clear is officially implemented and functioning on my dev unit!

party.gif

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! smilie.png

Development is rolling on, folks biggrin.png

5/22/2013

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 smilie.png 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!

5/22/2013

You know what this means... smilie.png

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 smilie.png

I'll keep you posted!

5/20/2013

Warp OEM Version 2.50 is officially underway smilie.png

5/19/2013

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 smilie.png

5/18/2013

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 eek.png

5/8/2013

Update time! I know it's been a while. Sorry!! eek.png But it's worth it.

Three cheers for jimsmith80! Thanks to him, WiFi tethering now works in Warp OEM!

party.gif

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!

4/18/2013

Oh, and I've gotten permission from Guspeed to port his n00b themes to Warp OEM!

It's like Christmas all over again cool.png

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 smilie.png

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!

4/18/2013

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.

Stay tuned smilie.png

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.

4/7/2013

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.

4/6/2013

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 smilie.png

4/5/2013

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 smilie.png

Would you guys agree?

3/28/2013

For all you custom ROM devs who want to use the installer featured in Warp OEM... installer-script link in OP download center.

3/19/2013

Bump for new OP goodies: a new flashable smoothness fix and instructions for devs on how to use PowerNap in a custom ROM.

Enjoy smilie.png

3/16/2013

Bump for OP updates: New version of App Pack and PowerNap script is now available separately.

3/15/2013

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:

WARP OEM 2.00 RC1

Enjoy! Any and all feedback is welcome!

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!

3/10/2013

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 smilie.png

As long as everything checks out with the team, we're all ready for the launch date smilie.png

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!

party.gif

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 smilie.png

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:

PowerNap
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.

USB automounting
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 smilie.png

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!

Goodnight, all smilie.png

3/9/2013

Oh, Warp OEM... Y U NO DONE ALREADY?? Oh well... at least there's an update smilie.png

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 biggrin.png

Right now I need to accomplish these things to meet this timeframe:

So, bring on the leftover Pizza Hut, pour a glass of pepsi.gif and cue the Linkin Park.

Let's do this. cool.png

3/9/2013

Okay, I seem to be hearing speed above smoothness, yes? Good, 'cause that's what I was inclined to do anyway biggrin.png

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 smilie.png

3/7/2013

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.

3/5/2013

The new build was just uploaded for the testers, and I'm awaiting feedback smilie.png

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 smilie.png

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 smilie.png

If you folks would like to follow along with said bugs, here's a link to the list we've been working from:

https://www.dropbox.com/s/zlpvjplgvfftqw9/bugs.txt?m

G'night! goodnight.gif

3/4/2013 - And now... Mini update time!

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.

Goodnight, all smilie.png

3/2/2013

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 smilie.png

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 smilie.png
Goodnight.

3/1/2013

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 smilie.png

bugs reported:

issues completed:

At this point, I'd say development can continue after these fixes all get verified by the testers.

2/28/2013

Well, it's just after 2AM and I'm at of my dev console yet again... must be time for another update! biggrin.png

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 thinking.png) 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 smilie.png

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 cool.png

2/26/2013

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.

*facepalm*

They have been reverted to their Gingerbread counterparts and the build I make tonight should be totally functional smilie.png

2/23/2013

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 eek.png

2/23/2013

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 biggrin.png

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 smilie.png

Now, to get a build out to the testers...

Yes, that <i>does</i> say 79 megapixels. Welcome to text messaging on Warp OEM!
Yes, that does say 79 megapixels. Welcome to text messaging on Warp OEM!

2/23/2013

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:

http://device.sprintpcs.com/ZTE/ZTEN860ABC-BST/N860V1.0.0B09.rdf

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 smilie.png

2/23/2013

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 smilie.png

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]
became:

[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:

[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="other"[/COLOR]>[/COLOR]&#1056;&#1077;&#1079;&#1091;&#1083;&#1100;&#1090;&#1072;&#1090;&#1086;&#1074; &#1087;&#1086; &#1079;&#1072;&#1087;&#1088;&#1086;&#1089;&#1091; \"%s\": %1$s[COLOR=#8b008b]</item>[/COLOR]

[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="one"[/COLOR]>[/COLOR]&#1056;&#1077;&#1079;&#1091;&#1083;&#1100;&#1090;&#1072;&#1090;&#1086;&#1074; &#1087;&#1086; &#1079;&#1072;&#1087;&#1088;&#1086;&#1089;&#1091; \"%s\": %1$s[COLOR=#8b008b]</item>[/COLOR]
turned into:

[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="other"[/COLOR]>[/COLOR]&#1056;&#1077;&#1079;&#1091;&#1083;&#1100;&#1090;&#1072;&#1090;&#1086;&#1074; &#1087;&#1086; &#1079;&#1072;&#1087;&#1088;&#1086;&#1089;&#1091; \"%1$s\": %2$s[COLOR=#8b008b]</item>[/COLOR]

[COLOR=#8b008b]<item [COLOR=#ff0000]quantity[/COLOR][COLOR=#0000ff]="one"[/COLOR]>[/COLOR]&#1056;&#1077;&#1079;&#1091;&#1083;&#1100;&#1090;&#1072;&#1090;&#1086;&#1074; &#1087;&#1086; &#1079;&#1072;&#1087;&#1088;&#1086;&#1089;&#1091; \"%1$s\": %2$s[COLOR=#8b008b]</item>[/COLOR]

And voila! Compile errors begone biggrin.png

2/23/2013

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? biggrin.png

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? eek.png smilie.png

2/20/2013

Tonight: Yet some more integration, begun implementing swap (and init.d in general) but it's not kicking in for some reason just yet...

2/19/2013

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!

2/17/2013

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! smilie.png

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.

2/14/2013

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 smilie.png

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 stickouttongue.png

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 smilie.png

Goodnight.

The new extended power menu
The new extended power menu

2/14/2013

UPDATE!!!
*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!!

dancing.gif party.gif dancing.gif

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 stickouttongue.png) 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 biggrin.png 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 smilie.png

2/14/2013

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!

2/13/2013

Oh! And I updated the OP for those who'd like to further examine the changelog smilie.png

2/13/2013

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 biggrin.png

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 smilie.png

Hey, it's better than the menu looked stock lol

The freshly-themed menu!

2/13/2013

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!

2/11/2013

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.

Hmm...

2/10/2013

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 biggrin.png

1/31/2013

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.

Goodnight, all!

1/30/2013

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. smilie.png

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! stickouttongue.png

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 cool.png

Goodnight, folks!

Battery life indicator in blue
Battery life indicator in blue

1/29/2013

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.

1/26/2013

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

1/26/2013

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? wink.png ) bit lol

1/26/2013

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.

1/22/2013

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.

Before After
Pssst. Hey, there, art designer. SD cards arent little blue blobs.

1/22/2013

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 After
Before and after

1/21/2013

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 After
Before and after

1/20/2013

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.

1/19/2013

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

HELP!!!stickouttongue.png

1/17/2013

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.

1/17/2013

Okay, what the f&*@ is up with ZTE and their insane numbering schemes?!?

banghead.gif

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*

It's like making a grocery list like this:

1. eggs
2. milk
5. paper towels
3. cheese
4. carrots

"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.

Enough said. angry.png

[/rant]

1/16/2013

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.

1/16/2013

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 biggrin.png

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. stickouttongue.png

1/16/2013

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...

1/16/2013

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

1/13/2013

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.

Enjoy! :)

10/11/2012

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.

...for now. wink.png

10/4/2012

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.

9/30/2012

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!

9/30/2012

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.

9/30/2012

...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 smilie.png

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 eek.png

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! smilie.png

And I updated the changelog to show even more stuff that'll be rolled into the next release.

/Update

9/25/2012

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?

9/24/2012

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.

9/21/2012

Okay, after getting feedback from all you wonderful testers out there (thanks smilie.png) 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.

9/15/2012

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 smilie.png

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 stickouttongue.png 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!

9/11/2012

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.

9/8/2012

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 biggrin.png
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!

headbang.gif

Success at last five.gif

Now, on to adding all those fancy features like Mr. Bobo and the rest have smilie.png

9/8/2012

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 smilie.png

9/4/2012 - So, okay, guys... there it is smilie.png

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. stickouttongue.png
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.

Enjoy! smilie.png

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.

7/3/2008 - Exelyx background file copying utility announced.

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.

4/12/2008 - Code execution core opcodes won't change.

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.

4/5/2008 - Display Module specifications released.

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:

Beta
Version 		Average
Speed
1.33 64,559
1.34 65,462
1.35 80,389
1.40 142,077

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.