New VGA 1024x768 4-Color Tile Driver
cgracey
Posts: 14,206
Here is a new VGA Tile Driver that displays 64x48 tiles of 16x16 pixels each, with 4 colors per tile. Its combination of resolution and color blows away all prior drivers. It can be used to show the internal font at 64x24 characters with the 3D bevels, or it could be used for a hi-res tile-based video game. I'll make more examples soon, but the driver is now complete.
This is something that I did not think was possible a week ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/8/2006 11:37:25 AM GMT
This is something that I did not think was possible a week ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/8/2006 11:37:25 AM GMT
Comments
Out of curiosity (and in 10 words or less please
-Parsko
Chip, you are right! This is more than I thought possible!
Regards,
·· Attila
Would this improved tile driver allow enhancements of the graphics routines, such as greater pixel resolution?
Just stack up some of the tiles to form a bitmap and draw pixels into it. It's 256 bytes per full horizontal line though. Not enough ram to do this full screen, with every tile being unique.
So a mixed mode screen is possible. Some text, some graphics, depending on available RAM.
I see this useful for some really neat propeller based appz.
Like for a prop-basic IDE or something.
The coding and idea that makes this work is amazing!
It's the props biggest prop!
The hardware assist really only boils down to timing and pixel data generation. The rest is software, that's what makes innovation in this area possible. We've not seen it all just yet. That's what makes the prop really cool, IMHO.
The smarter we are and the more we learn, the more the chip will do!
One aspect of this, I plan to tinker with, is the ability for multiple COG's to build the image. Should be able to create dedicated video kernels that do very interesting things. Coupla ideas I think are possible...
Lower resolution background graphics with high color depth running on one COG, higher resolution sprite or tile graphics with lower color depths running on another COG, text running on a third. All three overlay to form the final video image!
In short, the general purpose drivers we are seeing here are only the tip of the iceberg. It will be possible to build a video system specifically for the target application, thus making the most of the on-chip RAM resources. For games, this will mean varied and interesting displays. For other applications it means custom displays that really exploit the chip for the application in question. Totally flexible --it's just gonna take some learning about video, timing and planning the display elements and their layout in RAM.
And ironically, your avatar represents the opposite approach: using specialized hardware to solve problems that software can't (at the time).
The Wheel of Reincarnation keeps turning; we'll do it in software for a while again, and then someone will introduce a new whizbang coprocessor. Rinse, repeat.
We saw how this worked out for SGI. Oh, well -- at least their buildings are nice.
Don't laugh, but I like to call this "Dynamic Hardware". ^^;
*I made that term up*
If you don't like your video co-processor then just reload some new firmware into a COG or two!
*tada!* It's a new video-coprocessor. (lol)
I also like how it keeps cost down as well.
I was hung up with a critical scan-line-building loop containing one too many instructions to be executed within the requisite 6 hub cycles, blowing the timing out to 7 hub cycles, which made it too slow. I looked and looked at this loop and tried to find a way to cut one instruction, but I couldn't:
build·· ··············· rdword· tile,tile_ptr·········· 'get·next word from the tile array
······················· add···· tile_ptr,#2············ '(need 6, not 7·inst's between rdword and
······················································· 'rdlong to keep hub pace, else big penalty!!)
······················· movs··· col,tile······ ········ 'get color bits from tile word
······················· andn··· col,#$1C0
······································
······················· andn··· tile,#$3F·············· 'strip color bits and add tile line offset
······················· add···· tile,tile_line
··································
col ··················· mov···· colors,palettes·· ····· 'get tile color
······················· add···· col,d1
pix0··················· rdlong· pixels0,tile·········· ·'get line +0 tile pixels
······················· add···· pix0,d0·················'(note·4n+2 instr's between·rdlongs/rdwords,
······················· add···· tile,#4·················'this·keeps us locked to the hub for speed)
········································································
pix1··················· rdlong· pixels1,tile····· ····· 'get line +1 tile pixels···········
······················· add···· pix1,d0
······················· add···· tile,#4
········································································
pix2··················· rdlong· pixels2,tile· ········· 'get line +2 tile pixels···········
······················· add···· pix2,d0
······················· add···· tile,#4
········································································
pix3··················· rdlong· pixels3,tile· ········· 'get line +3 tile pixels···········
······················· add···· pix3,d0
······················· djnz··· count,#build··········· 'loop for next tile (need 24 cycles/loop!!)
This is where I was stuck, resigned to the notion that it was not possible, as every instruction was performing some non-reducible function. Over the·last couple months, I took a few fresh·looks at the problem (which usually helps), and finally realized that instead of doing a rdword to get a tile, I could do a rdlong to get two tiles at once, and then use a 'shr tile,#16' to get the second tile, and a single 'add tile_pointer,#4' to increment by two tiles. This even left one unused cycle in the loop. Here it is now, (ab)using special-purpose registers to save ram:
build_2x··············· rdlong· vscl,ctrb·············· 'get pair of words from the tile array
······················· movs··· col0,vscl·············· 'get color bits from even tile·········
······················· andn··· col0,#$1C0······································
······················· andn··· vscl,#$3F·············· 'strip color bits and add tile line offset
······················· add···· vscl,tile_line··································
col0··················· mov···· colors+0,palettes······ 'get even tile color
······················· add···· col0,d1
pix0··················· rdlong· pixels0+0,vscl········· 'get line +0 even tile pixels
······················· add···· pix0,d1·································
······················· add···· vscl,#4·································
········································································
pix1··················· rdlong· pixels1+0,vscl········· 'get line +1 even tile pixels···········
······················· add···· pix1,d1·································
······················· add···· vscl,#4·································
········································································
pix2··················· rdlong· pixels2+0,vscl········· 'get line +2 even tile pixels···········
······················· add···· pix2,d1·································
······················· add···· vscl,#4·································
········································································
pix3··················· rdlong· pixels3+0,vscl········· 'get line +3 even tile pixels···········
······················· add···· pix3,d1················ '(9 instr's between rdlong's, could be 10!)
······················· add···· ctrb,#2 * 2············ 'point to next pair of tile words
······················· shr···· vscl,#16··············· 'shift odd tile word into position
······················· movs··· col1,vscl·············· 'get color bits from odd tile
······················· andn··· col1,#$1C0
······················· andn··· vscl,#$3F·············· 'strip color bits and add tile line offset
······················· add···· vscl,tile_line········
col1··················· mov···· colors+1,palettes······ 'get odd tile color···············
······················· add···· col1,d1···················································
··························································································
pix4··················· rdlong· pixels0+1,vscl········· 'get line +0 odd tile pixels······
······················· add···· pix4,d1···················································
······················· add···· vscl,#4···················································
··························································································
pix5··················· rdlong· pixels1+1,vscl········· 'get line +1 odd tile pixels······
······················· add···· pix5,d1···················································
······················· add···· vscl,#4···················································
··························································································
pix6··················· rdlong· pixels2+1,vscl········· 'get line +2 odd tile pixels······
······················· add···· pix6,d1···················································
······················· add···· vscl,#4···················································
··························································································
pix7··················· rdlong· pixels3+1,vscl········· 'get line +3 odd tile pixels······
······················· add···· pix7,d1
······················· djnz··· inb,#build_2x·········· 'loop for next tile pair (48 inst/loop)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/8/2006 6:25:06 PM GMT
That's exactly the optimization I'm prototyping in my Forth kernel. Nice work!
This is not to say SGI did not do a lot of custom hardware however. They did and still do.
The reason the icon is there as an avatar is that I loved the machines in general, for reasons other than lower level hardware.
IRIX is a fantastic OS in terms of overall stabilty, scalabilty and interactive response. The IRIX machines were the first that I used that didn't bog down in terms of elementary user interaction. On these boxes, it's possible to bury the CPU complely, ask for a shell and get one that's interactive with low latency right away. Same with 3D modeling and rendering. Interactive graphics, picking, etc... always ran at near real-time speed no matter what the box was doing.
Coupla SGI stories that moved me to really love the machines:
(And I use an O2 and an Octane to this day)
-upgrading a batch of indys to expand my render pool, ran outta space. Used the built in package manager to remove about half the software while installing a ton of new software. This took about 10 minutes to setup, then once I hit go, the machines were ready to render about a half hour later, no hassles. Pegged those machines for a full coupla days to complete some video render for a demo tape. After it was all done, I reversed the software install, moved a file or two for configuration and there was basically no evidence I was ever there! All done remotely with nice network aware GUI tools built in the box. This all done from an X enabled PC in the next building, alongside another SGI running compositing software.
-multi-user MCAD setup on an Origin class machine. 20 users, shared copies of program code, smart file caching, virtual swap, allowed for all users to remain interactive on their PC X servers all on one copy of the software and database. This machine served it's users for about 6 years while never losing any part of it's half terrabyte managed filesystem. In place upgrades could happen while users were working to boot. Average system load was 60 percent with 90 percent peaks. In the box backup system allowed for live, on filesystem backups and restores of any file within an hour... No downtime for backups, or most all in place upgrades to the core OS. Model sizes ranged from a coupla GB to sometimes 20! The beauty of this setup was the scheduler keeping things interactive no matter how hammered the machine was, and the file handling that self-managed multiple copies of code to a single system image. Once one user had started the program, others could then run it almost instantly as the system cached nearly all the run-time code.
-I once upgraded a set of SGI machines from one software version to another. Left a couple of them running their application. After the upgrade, the older version of the application remained in file cache until the last user of it logged out! That level of caching and file semantics is not found on most all machines in use today. It was running the older version perfectly despite there being no binaries on the disk!
-The window manager allows for just about as many virtual desks as you can stand. I've often left one logged in for a coupla weeks with 20 or so applications in different states, all running in their own virtual desktop space.
-Upgraded my first filesystem from Indy, to O2, to Octane, then back to O2. Applications, user settings and data intact...
-nice open multi-media system. Out of the box, one can rip CD's, capture professional quality video and mix those to a fairly high quality production. Audio inputs featured 90Db S/N ratios to boot! The SGI CD player featured save track as, right off the menu!
The graphics systems on the SGI's were damm cool. The desktop holds it's own today. Really, my fave was the underlying OS and engineering that went into that. I never used anything but the in the box tools for some very complex administration, scaling and backups. The online documentation provided a complete course on high-end true multi-user computing, complete with administrative templates and use cases for the daring admin. This has never been topped by any vendor I'm familiar with to date. That made the easy stuff easy, but the really hard stuff possible and often quite easy as well!
The IRIX stuff is nearly dead now, of course, but it was frankly the best computing experience I've ever had. The baddest win32 machine you can point your finger at remains a toy where hardcore, high impact computing is concerned. Try deleting a program while it is running on a win32 box. Primitive file locking and caching is one of many areas currently holding win32 systems back. Don't even get me started on the true multi-user aspects that an integrated OS and hardware platform can provide outta the box... Low latency graphics and precision kernel task scheduling is another. These areas alone are a big part of why win32 machines do not currently scale. Today, SGI has Linux running on 1024 CPU shared memory systems, just as they did with IRIX years ago. That's one OS with 1024 CPU's running together to solve problems. Scaling and engineering is really where they were at, thus the avatar.
My overall point being there is time for fairly well focused solutions. This is what SGI was all about. The engineering was aimed at not only solving a problem, but totally nailing it. That remains true today with large scale single image big memory computing. There are people who will pay any price to solve their problems and that's who SGI serves. Pricey, but literally the best if you really need it.
The prop is at the other end of the scale. Really the utility of the chip lies in the fact that its resources can be repurposed at will. If you scale down, embedded systems are really dedicated pieces of hardware in the same way an SGI would be. Having to deal with high component count, or multiple software toolchains is a hassle the prop will essentially eliminate for a significant number of design requirements. This is cool --very cool.
For the interested layperson, such as myself, it's an excellent platform for prototyping and learning that will have significant practical application down the line.
The real innovation is the multi-processing. It's gonna take some effort to grok this, but for anybody that does, whole classes of tough problems are gonna get easier and more interactive in general. For some things it's gonna be harder. No brainer tradeoff given the potential benefits, IMHO.
We should take this off board if you want to continue the conversation... Not really prop related beyond the comparisons of scale.
SGI sounds like an awesome company from what you've said about the design of their machines and operating systems. I had no idea that ANY company had come up with such complete and elegant solutions to what are probably the eternal difficulties in computing, and they did it a relative while·ago.·I'm feeling like I wish I had grown up in that better-mannered neighborhood. Having languished in the Wintel projects, I've slowly developed a·deep pessimism towards modern computing, seeing how its promulgators are far more interested in stratagems to keep their hands in your pockets than they are in giving you almost any proper solution, let alone an enduring one. In fact, they take away·your freedoms at every turn.·The SGI way, in contrast,·is like a futuristic Star Trek world,·focused·on·providing what's foundationally needed, rather than just extracting tribute·from·kept minions. I'm so weary of the soap-opera formula·of perpetual-phony-carrot,·with·a hidden-stick twist. I've been living in a feudal system, hanging on as a serf. For years, I've felt increasingly like a 'guest' on my own PC's.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
Post Edited (Chip Gracey (Parallax)) : 11/9/2006 2:39:55 AM GMT
These ideas go back much further. Two examples come to mind:
1) There was an operating system called Tenex (10X) done for the Digital Equipment PDP-10 in the early 1970's that could do many of the same things as SGI's system. All files were versioned with the newest being the default, but you could explicitly reference any version, either by absolute version number or a relative number (like -2). The OS kept references to all versions, even if they were archived on backup (tapes!). If the version you wanted wasn't on-line, you could queue a request to have it reloaded from backup whenever the system administrator got around to it (a day or so usually). Clearly, a user could be running a version of a program and have the program replaced by an update, yet still keep running (and with the entire context kept until the program was done). The user's resource privileges determined when old versions would be archived. Backup clearly was seamless and ongoing automatically by the system. The entire file system could be recreated to its state at any time in the past (files had to be closed to be backed up).
2) Datapoint had a networked operating system (in the late 1970's) using Arcnet (a deterministic token-passing high speed network system comparable to the Ethernet) running on a proprietary CPU similar to the Intel 8080 with memory on the order of 128K. Minimum workstation hardware was a keyboard, text display, CPU and memory, and an Arcnet interface. It could boot up off the network from any available computer (all machines were servers in a sense) and the user at the keyboard could initiate programs from any local or networked storage. The program could be run locally or on another machine with just keyboard and display attached over the network and all I/O devices including serial I/O, printers, disk storage, scattered over a wide area network physically arranged over several square miles and linked by coaxial cable, IR wireless links, and microwave links. The program would have no idea (unless it inquired) where its resources were located and, except for communications delays, it made no difference.
Amazing how much we've progressed.
Mike
The same things apply to computers. On a real OS, or hardware platform, like the prop, the computer does exactly what you ask it to. With the good comes the bad, of course. Great power means the ability to do really clever things comes with the ability to do serious damage too. (been there, done that.)
On win32 systems today, there are processes that run with a privledge level lower than your administrator account. These are the ones that deny you some actions depending on the will of the OS creator / maintainer. It's only gonna get worse. Open computing is not as elegant as the SGI stuff is, but it's pretty damn good given you are willing to do some learning and administration to make the box comfy. The beauty is that you own the machine in all respects. It's tough, but completely possible to fully know what the machine is doing for you and change that if necessary. This is not possible, but for indirect inference, on a win32 box. I'm not sure it's possible on a Mac either, but at least the core is BSD. If you really want to, you can bring up an open desktop environment, ignore the Apple stuff and still own the machine.
IBM, SGI and Sun have all contributed some great stuff to Linux. We've got Exabyte filesystems (XFS) with almost all of the magic capabilities found on the SGI machines. (SGI contribution) IBM has ported a whole ton of it's messy middle ware, and sun is gonna let Java go and has contributed good quality NFS.
These days I'm quite happy to run a nice XP machine, given somebody else foots the bill. Nice environment, but not one that I own. Necessary though for a lotta things today. So I deal. I do run every last open thing I can though. Most of the good stuff is ported and just an install away. Nice skill transfer should the need arise.
Sorry all for the OT. Love this stuff as much as I do the prop!
Mike: Totally! The SGI's do not have revisioning. What keeps them going in cases like the one I described above is just really great filesystem caching capabilities. One reboot and you are left with what was on the disk. Filesystems are journaled though.
One more thing and I'll quiet down. Multi-user computing is really sweet. I'm not sure most people really grok the X Window system and what it means. (Yes I still have my tattered copy of BYTE where this was first reviewed!) With X, applications can run on the local box, or some remote networked box. It's possible to have one machine serving graphics locally, another managing your windows, another serving files --even the entire filesystem for diskless operation, another serving an application, yet another doing name resolution, etc....
An entire group of machines, all running whatever X enabled OS and applications can be woven into one largely seamless desktop environment for the user. They double click something and five machines all combine to do their thing. The pure client server model we see today just does not allow for those kinds of choices without a lot of work on the developers part. It's in the box with X.
Both the Mac and win32 machines have a multi-user kernel, but lack multi-user graphics engines. The result is a sharp limit on the number of options we have for using our computers together.
Sadly, the demand for these kinds of things has all but gone away, largely do to the majority of applications being developed in the single user environment we have today. I can't but wonder if we might see some of it come back if (when?) multi-processing takes off on a smaller scale.
Fortunately for us Mac-ites, the Mac OS comes with X built-in (an optional install, but check the box and it's there). Most stuff written for Linux or Unix will re-compile and run under the Mac OS although there is the big-endian vs. small-endian stuff that can get in the way. With the Intel-based Macs, even that goes away. For example, I have a copy of Eagle-X11 to play with. It installs just like under Linux. I can start up X11 with a double click and run Eagle, ChSciTE, or xterm with a menu choice.
Mike
I'm pretty sure the X in XFS is not for Exabyte. The unit wasn't in common usage back then, and the filesystem won't scale that far. (It's also not mentioned anywhere in the early papers.) XFS is a lovely filesystem, particularly considering its age.
Computers have become so inexpensive (in the more developed areas of the world) that the original notion of multi-user computing -- multiple humans running jobs on the computer -- has become pretty quaint. However, you'll notice that all the successful desktop operating systems these days have multi-user roots (yes, even NT was once a solid multi-user OS). Nowadays, it's not the users that need to be partitioned from one another -- it's the applications, and hardened multi-user OSes are perfectly suited.
(To describe a multiple-machine X environment as "pretty seamless" is a bit iffy by today's standards. If you're just running some xterms, sure, but without network transparency for sound or those lovely USB keys we all carry these days, a desktop is pretty limited. At least we have displayserver-side font rendering now.)
We are way the hell off topic. Sorry Chip.
You must be thinking of it's younger brother EFS.
Applications, properly written on top of an OS that is really multi-user, have no need to be partitioned. This is a win32 artifact. It comes from two things: one the whole GDI drawing structure is local and not multi-user and not network aware, two the registry structure that does not scale beyond one user without kludges. A real OS handles these things, leaving the application free to manage its own self. Multi-user happens by default, not design on the applications part, unless somehow it's data structures require it.
There remain valid reasons for these kinds of environments today. The biggie is security. UNIX systems allow for something called suid. This means a program can be run by a user, yet assume the permissions granted by it's real owner, say joe. Bob does not have permission to even view the data the program operates on. Joe, the admin does. Thus the only way the user can interact with the data is through the program owned by Joe. Thus, the user gets to do only what Joe permits. Run this over an X session and the user cannot even view the application, or access any of it's tempoary data structures. This is in the box stuff, supported by the OS. It only requires an application developer to consider the problem. The tools are already there. With client server, basically the user must have a copy of the data, or all operations run over the network. The former is a problem with security, the latter is a problem with speed on larger datasets where moving the display data is smaller than the dataset itself.
As for the sound, in the box on SGI's. (KDE will do this too) Will run right over the network, along with video if you have a fast enough network. The USB key is something only recently added to the IRIX world. My boxes do not have hardware support --I use a Linux box for my main desktop, for that reason and others. It's got the cool SGI stuff and some higher end applications woven into it's desktop environment. Problem easily solved however. Have the machine mount the KEY, then symbolic link the filesystem into the users home directory space, right along with all other shared resources. Linux by default links the key to a public area viewable by all users on the machine.
To the user, they just click on a file browser and don't care where the data actually is. Make a second link to a public writable area and suddenly keys become public by name. Pop in your key, give bob a phone call for a file request, bob puts it right on your key while you watch! Would be fairly easy to have the script prompt the user for a "make key public?" answer. Put said script on a script server, then have it linked into local filesystems. One script, all users, minimal admin.
Seamless in the X environment comes with a bit of scripting. It's not difficult to simply build the scripts necessary for the user to request applications from either the system menu (running on any of the machines, BTW, so you only need to do it once), or from scalable icons on their local desktop. Done properly, the average joe again knows nothing other than they click on something, an application runs, they save their data don't know where it really goes, etc...
All a matter of administration. This is why you see so many UNIX admins not running around any more than they have to. With the proper foundation, the only reason to visit a desk is to address hardware issues, or deliver support and or mentoring to the user. All other things are done via network. And if you are a senior admin, that's what lackeys are for! All installations I worked with, had remote connections via modem or internet, depending on the level of security the place required. I drove a tenth of the miles I do now with win32 PC's all over the place. Things like RDP, VNC help a lot, but are checked by the permissive environment being dangerous too. Lots of admins won't allow the better tools because of the security issues. --so that means getting in the car..
Ok, that's really it for me on this topic.
Can't wait to try out that higher resolution driver. I'm stuck on TV mode for the rest of the week!
Post Edited (potatohead) : 11/9/2006 3:03:25 PM GMT
I believe we're having some disconnects in terms. I don't consider artsd's remote sound support to be in X, since it won't work with non-KDE, non-arts sources. I'm not aware of a remote block device protocol that will allow me (in a reasonably compatible way) to mount a USB key on my X server (the display) and access it from processes on my application server. I would love to be proven wrong on either of these, as I work with large X applications on a day-to-day basis; please PM me with the details.
And no, XFS will not scale that far, I assure you. ZFS is the only public file system that stands a chance there.
So, how about that 1024x768 tile driver? Eh? Eh? Lots of pixels there.
Did some digging on large byte units. From what I can tell, with current 64 bit implementations on a kernel capable of addressing the file, It's petabyte sized files, not exabyte. My bad. On disk size of the entire filesystem does reach Exabyte levels though. Big *** files.
If warranted, let's take this off board. PM me, otherwise it's back to the prop and little teeny, but really fun problems.)
Yep. Driver looks excellent. Big pixel pimpin for sure! I can't wait to try it. For this week, I'm running my prop broadcast on hotel room TV's. First time I've had to really start programming it. Potential projects are already starting to hit me...
If we use the tile driver, we can't draw text to the VGA screen right?, since only one VGA driver is allowed at any one download to the propeller.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer
Parallax, Inc.
The practical limit for running multiple instances of this driver is THREE. That would take 6 cogs, 24 I/O pins, and 24K of ram.
Where have·you been, anyway? You disappeared for several months and came back a week ago.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chip Gracey
Parallax, Inc.
I was a bit busy with the SX......
Now that I got my hands on some Propellers, I am trying to think of some project for it.
The learning curve is a bit steep though.
With the SX, I am like a lecturer using assembly.
With the Propeller and spin, I feel like a 1st year student.
How come Guenther doesn't get involved with the Propellers?
Since when did Paul Baker become part of Parallax?
Are you working on a new, faster Propeller?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.fd.com.my
www.mercedes.com.my
Paul Baker
Propeller Applications Engineer
Parallax, Inc.