Well, this one is marked RC1, but it's got a bug, and I'm done for the evening. The bug is a missing pixel on each character displayed. It's missing a pixel! I'll be tracking that one down. If you have time for a look-see, I would appreciate it. Arrgh... I had no idea until I completed the redefine command.
In the mean time, I've cleaned up the code and wrote some very basic SPIN procedures to control things. Here is the basic info.
Some parameters are live. Driver will respond next frame max, they are:
TEXT.CharsPerLine(32) This can be 16, 32, 40, 64, 80. It sets a value used by other functions, so run it before doing things like TEXT.ClearColors.
TEXT.Interlace(0) 0 = interlace, 1 = no interlace.
TEXT.ColorMode(0) 0 = use color cells, non zero defines two color per screen mode. $00_00_02_07, would define bright white chars on black background.
Use color mode on 80Mhz boards to get 80 character text. The max with color cells is 64. Or use it, to just not do color cells.
The following things are not live. They just operate on the font, text screen, color screen.
TEXT.ClearColors(07, 02) = Sets all the color cells to the values given. This would define dark characters on white background. If one value is a zero, then no change will occur. This permits changing the background color of some characters, without having to change the foreground also.
TEXT.Redefine ($81, $ff, $F0, $0F, $F0, $FF, $F0, $0F, $FF) == The first parameter is the character number, the other 8 values are binary data for that character definition. OBC asked for this.
TEXT.SetTextAt(0,0, $84) = Sets a given screen location to a given character value.
TEXT.RedefineDat($81, @Line) = This redefines a character from DAT data.
TEXT.PrintStringAt(3,1, string("In Line Text String [noparse]:)[/noparse]")) == Prints a zero terminated string at screen x, y.
TEXT.SetColorCell(1,0,$cb, 02) = Sets the color values for a specific color cell located at screen x and y.
Archive attached. If you've an idea about the missing pixel, let me know. If you use some of the functions, let me know. If it fails to display on your device, let me know.
Getting closer!
BTW: After hammering my brain in PASM, SPIN was fun! Imagine that!
**I've no idea why the forum will no longer let me upload a .zip, but that appears to be the case for a while now. Rename .safe to .zip to unpack the archive.
Minor feature request: (While you are hunting for the pixel you misplaced.)
Could you include a "set it and forget it" color command?
Something along the lines of .setcolor(FG,BG) which keeps that color until it is called again?
Already working on a PropDOS update.. [noparse]:)[/noparse]
For now though, it appears as if we have a 7x8 NTSC driver. WTF?!? I'm up this morning going to run older revisions to see where it goes away... I'm laughing this morning, but man, I was hot last night. Jim had all kind of trouble with the Apple driver and 7 pixels, and here I get it easy cheezy... I suppose this is a great example of why it's a good practice to keep code revision history. Maybe it's still 8 pixels, but shifted.
I figured you were in the mood to start bolting things together, which is why I went ahead and posted this up.
Potatohead - yes I see your revision history implies you keep older code. Great practice to get into. I have all my old code filed away in steps. I have never had to prove authorship, but this too is useful. In the early CPM days, I lost a significant debugged piece of code (vedit bug) and did not discover it until months later. Old revisions saved my bacon!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Whew!! It was the pixel table. Some bits got lost when I flipped it. Bad Excel string expression.
So, it's an 8x8 driver with no core ugly problem after all. Most of the bit patterns were fine. I might not have found this, but for redefining characters. Thanks go to OBC on that one, for asking in the first place.
I'm going to attach the archive to the top post.
"set it and forget it" color function added. It's only active with the PrintTextAt method at present. Maybe that's the only one that makes sense, I don't know. At some point, I figured this would get bolted on, or under the same kinds of things AiGeneric was. I was not part of that, so... there you go. Example code provided.
If you all have time to bang on this a bit, or write a library function, or have a display issue, etc... let me know. I'm going to go back and work on the TODO list.
That's:
C64 video output option (Interlaced horizontally, but not vertically)
Mouse Pointer
Border graphics tweaks
S-video (next weekend probably)
Whatever comes up.
When changing resolutions, screen_width is updated. All that is needed for the changes to work is to maintain a few variables that know the state of the display. Routines that are display state dependent just need to use those variables, or store a few.
IMHO, the only one needed so far is screen_width. That determines how much RAM to clear, or set color / character values. It can do scroll too.
Scroll can probably be a bytemove and maybe add clear line.
Scroll is extremely simple. But there are a few options which would be nice.
* Optionally allow for 24 line display and not touch the 25th line as it is often used for a status line.
* The whole screen can be done extremely fast in one set of moves if done in pasm.
* The scroll can be done using longs (much faster)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I knew you were headed that way Heater. Didn't somebody have a Propterm program at one point? Seems to me, that could be bolted onto this pretty darn easy. Just need to add a few more primitives to the set developing here, along with a palette already setup for the common color definitions. Maybe a single chip VT100 would be handy for a lot of things.
Scroll deffo needs the 24 line option, I had that one in mind as line 25 is a status line for a whole lot of things. Happens with line 0 too. The text screen is currently byte aligned. Maybe a small buffer takes care of the alignment issue that's going to come with using words to scroll. Truth is, I think SPIN will nail it in less than a frame either way. With text, it's basically down to the frame. Anything faster boils down to tearing and more eye fatigue than even the TV display brings.
Did some display testing today and I think I figured out what Eric was telling me above. On NTSC, the color interlace, or AKA "shimmer" depends on the relationship between the length of a scan line, and the free running color clock. I ran several displays today, non-vertically interlaced, and shortened the front porch timing. Bingo! Got exactly what I was looking for, which is the 30Hz shimmer on a non-vertically interlaced display signal.
Now, if there is some bad effect to that, somebody let me know. I'll have to code up some display tests this week to refine this option. On a side note, that puts a SIMPLE_NTSC signal back on the table, which is useful for generating lots of colors on NTSC. I wanted that for reasons unrelated to this driver effort, which will remain text + mouse.
Heater, et al. you CP/M guys can tell me. Did CP/M programs ever use a memory mapped screen, or is the whole works just serial I/O? Secondly, assuming you do use the text driver, how would you use it? If sound is not required, nor the better color Eric's sprite driver makes use of, only three pins are required for a nice signal. Unless I'm mistaken, this signal can be S-video or composite as well, with only the three pins being necessary. From what I can see, triggering S-video simply moves the color signal from start_pin + 1 to start_pin+3, so then, if somebody wanted an S-video connection, I see no reason why they couldn't just wire up the standard three pin video circuit and provide a switch to either run the color with the rest of the signal, or run it on it's own line.
VT100 has already been done by someone.·It is in Bean's Vince Briel?? Terminal propeller board.
Drac can answer better than I, but CPM uses a serial VT100 terminal by default. Probably only a subset is used. Originally, only monochrome was used (white or green on black) with the top bit used for inverse. Later some basic colors were used. The edit programs (Wordstar and Vedit kept their own screen copy within the CPM Ram, but still used a remote VT100 terminal, which at the time (before VT100 terminals became readily available - they were about $3000 a piece originally) we used to build our own terminals - and I mean 3-4 pcbs + motherboard·with logic and memory chips (1Kx1)·chips before the advent of the 6845 etc.
My RamBlade (final announcement shortly) for ZiCog/CPM/PropDos will have 2 build options...
* Prop, Ram and microSD with 2pin serial connection to a second prop such as the ProtoBoard or DemoBoard, etc
* Standalone·will use a PS2 keyboard and the 1-3 pin version of TV, requiring only a keyboard, TV and powerpack, in about a matchbox size
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Personally I have never used a CP/M that had anything more than a monochrome VT100 terminal screen. Specifically the Intertec Superbrain. As far as I know these class of machines never used memory mapped video.
However there have been many machines with memory mapped displays. For example the Amstrad "Joyce" had a monochrome pixel display controller using up to 22.5k bytes of the standard RAM as screen refresh memory. It also supported 2MB of bank switched RAM. The Amstrad CPC were colour.
Then there was the MSX standard.
These machines used the GSX graphics interface standard.
I think all of this is out of scope for what you are up to.
That Amstrad Joyce is within the Prop limits easily. Would consume one Propeller though.
You are right, that is out of scope. The core idea for this project was to get a solid text display that could do ANSI, and do early 8 bit redefinable character graphics. Think most of a VIC 20, with a hardware mouse pointer. That level of functionality consumes some Propeller RAM, and is a nice balance between the need to display, RAM consumed, and that required for a simple and effective GUI.
The idea of a terminal really was secondary. Now it makes perfect sense. The capability here is ANSI / VT100+ so that's actually going to be quite useful. I may well build a terminal, just because. I've got a very nice, spare LCD, and some other goodies. Frankly, I've not done hardly anything with serial I/O based systems, but for some big Unix iron, and where I could, I did X window to largely avoid that.
Finally, for my own project work to come, having simple text output is a must for debugging, etc... A memory mapped screen is quite useful for a lot of these things, particularly if a hex font is used. (where each character simply displays it's hex value)
I'll make sure the monochrome options are clear, so the colors data can be omitted. That's perfect for where you guys are going right now.
So this is a quick post, just to update people interested.
I'm working on debug tasks in the simple library commands to be included, renaming and commenting some things, and in general, cleaning up the functions achieved so far. I've a bit of an interesting challenge with the mouse. There is time in the text cog, but the order of things is trouble for the fast loop built last major re-write. Am thinking on that, and any suggestions welcome. Might hack on it this weekend.
The other thing is some useful demo code, instead of some random Smile. I added a color lookup table in SPIN, so that colors are nice and sane. Screenie attached. Basically intensities run from 0 to 8, with the higher ones duplicated a time or two to round things out. For each hue, I've sorted the nice, in spec, low saturation colors into the lower intensities, then sorted the out of spec, high saturation colors so they match the base hue closely. The result is an easy way to specify colors, without having to worry about hitting one of the Propeller dead spots, where it outputs sync, or something other than just a simple color. If you are writing to the screen and color RAM, you have to maintain your color space. If you use the functions that come with this thing, you don't.
The "set it and forget it is done", as is the basic functions all working with whatever screen resolution is selected. The major debug is between the text cog and the TV cog and stuff occurring in the borders. Once that is sorted, it will be time for the mouse. I'll post up an archive sometime this weekend. Ideally, this will be RC2.
Cool. Thanks Mike! This will be a lot of help. I never really looked at this driver, beyond some video / cog sync stuff. Wow! 128 characters too. I had forgotten it did that. Well, if the TV does 80 on a good set, life is good.
Frankly, I think I'm going to leave the functions OBC asked for, and whittle down the remaining ones to be that set required to support the ANSI codes, and control the driver modes. That will put the mouse off for a bit, but that's fine. My intent was good TV text, no matter what, and add things from there.
Next post won't be RC, but another Rev to vet the ANSI library. Feature creep... [noparse]:)[/noparse] Never mind on this. It's just RC2, because the core stuff is gettin' close. ANSI / VT and other things will be add-ons, that can have their own tracking for eventual posting in the OBEX.
@Jazzed: Sorting the colors makes a world of difference, doesn't it? I've still got to hook up an S-video circuit, or cut a trace somewhere... There is probably time tomorrow to go pick up some resistors. I'm really curious to see how the color plays out.
Lots of little issues fixed yesterday. Archive in top post. Got the border graphics and basic control / screen text options all sorted out. Found out that an 8 character display works, for a simple, color cell fat pixel kind of driver, or probably lower clock speed text driver.
For color, all the functions but the TEXT.SetColorMode one operate with the color look up table for a nice color space. Intensity is 0-7. Every hue then is a multiple of 8. I've moved a few entries around so the color set is more consistent. There might be a little more of that, depending. The high-saturation colors are always 8*HUE+6 and +7, for easy reference. Nice, in spec colors are 8*HUE+0-5. There are 16 hues, making a fairly sane and easy to use Propeller color space. I've struggled with this, and like this scheme a lot.
Border graphics are fixed now in multi-color mode. Those were causing some display issues on some devices. The Palette Demo code should now run on all devices, all character resolutions (8, 16, 32,40, 64, 80), and both clocks. Let me know if your display has trouble with a given mode. I tested through each, at both 80Mhz and 96Mhz clocks. Looks good here.
I'm going to look the ANSI code that Mike posted over. One question about that: As things are right now, everything needed for a nice text display is included and working nicely, I think. If things like ANSI / VT-100 happen, should those go into the driver start SPIN program where the basics are right now, or be contained in their own SPIN file? Just wondering how people do or prefer those kinds of things.
Does anyone else find themselves unable to upload a .zip file all of the sudden? It's bizzare, having to rename. That never used to be the case.
Well, I thought I'd give this a try. Works for me after some tinkering. Too bad we can't paint individual pixels with any one of 64 colors. I don't use Demoboard, HYBRID, or HYDRA, so auto-detect as is was helpful to show me examples of how to make it work [noparse]:)[/noparse] Too bad there is not a more generic way. Separating objects into functional units is programmer friendly. VT100 is useful, but not to everyone.
@Jazzed, the next version of this will be a multi-color tile. Text has special memory requirements; namely, that it all be rather small. For graphics, some stuff can be changed. I've got to stay focused on this to see it finished however. The core conflict that prevents the "one size fits all" graphics happens to be RAM consumption, both run time, and driver start foot print. The other one is just complexity overall. Better to just do drivers that nail a niche and call it good, or go full on and dedicate a prop to it, like PropGFX does.
After the text, some graphics oriented stuff will happen. In between projects, I've went back and explored some of the old 8 bit computer hi-color tricks. One of those is in the Propeller Wiki. PAL has the ability to do this kind of a thing at higher resolutions, and NTSC has some variations that make more sense than that method did. It's possible to get a nice, full byte of color on this chip, without special circuits. Then there is the great color Eric has produced as well. There are lots of possibilities and I like working through them. For text though, it's just best to stick with the native Propeller colors. There are plenty of those --more than enough.
Yeah, board configuration is always a PITA. The only thing I know to do is get better at docs, and compute more things so people have less to manage when configuring. The auto-detect is kind of limited. Doesn't work on all boards. Might be able to extend it some. Frankly, I just used the code Coley worked up, and that Eric merged with his core video template. It's a great starter, as most of the common boards out there fire up without a hitch. At least that gives people a check to work from. I find doing this the hardest when there isn't a known good check 'n test scenario.
BTW: On this one, you can do simple graphics. What you do is stack up a bunch of the characters in a square grid, then redefine them to show images. Good for simple charts, graphs, etc... Really the focus is for simple GUI, data output, etc... All of those things one would use the tv_text and AiGeneric for. tv_text is useful, but fonts and such are kind of big and complex. AiGeneric is actually sweet, but limited by the poor signal output quality. That all came from my earlier "Atari Style" video output. Not enough color resolution there to really do text proper. I struggled with the Parallax driver, and found the scan line template Eric did just excellent. Most all the good signal characteristics are easy to do, and with TV, that matters. Maybe it's worth doing simple, plot, line, etc... for that. Would not take a ton of spin. Could just put that in a seperate file, so if it's not needed, then it just doesn't happen.
I'm thinking DrawGraphicsAt([noparse][[/noparse]screen start x], [noparse][[/noparse]screen start y], [noparse][[/noparse]number of chars used x], [noparse][[/noparse]number of characters used y], [noparse][[/noparse]start char]). Say 128 characters are in use for general communication. There are 256 total, so one could do a 16x8 grid with those and locate it somewhere on the screen. That's a 128x64 graphics window. Done in the 40, 32, or 16 column mode, it would occupy a nice fraction of the screen. So, one could have text output of data, prompts, and some basic graphical feed back. Use the color cells to color that feed back, and get a nice little chart, data plot, indicator, etc... Could run a little pong game, or something in there too. Plain old SPIN is plenty fast enough to do those things. Another COG could be writing to that window, as well, showing some kind of feed back. Think like what Chip did with the higher resolution VGA driver, only with a smaller footprint overall.
Breaking into files is a good thing then. One core set to just throw up the driver. Comment a thing or two for mono, small memory CP/M quality stuff. Include very basic functions coded so far, then separate files for things like ANSI, VT-100, TV_TEXT, GRAPHICS. Reference what is needed, forget the rest. That way, a minimum of fuss is required to operate it at the functionality appropriate for the task at hand. This means others can contribute stuff, without having to tear into the core wad of code. So, that's some work exposing the right vars to other programs, and being somewhat picky about the core library of functions included in the base driver set. I'm feeling really good about those right now. Just enough, but no more. Might find there is one that is needed, so it will get added. That then, is the API, so to speak. Write to that with few worries, and read the DAT area for run-time info. A lot of this stuff is new ground for me, so I'm happy to plug away and see where it all goes.
@counterrotatingprops, he's referring to the color cells. As it stands right now, any 8x8 area can have two colors. That's really good on RAM, but not so good for pictures and such.
Doug (PotatoHead)> he's referring to the color cells
OK - thanks - it makes more sense now.
> Breaking into files is a good thing then. ...
> ... separate files for things like ANSI, VT-100, TV_TEXT, GRAPHICS.
Yes! This is a good idea, generally.
I enjoyed the old-school ANSI graphics. And VT-100 is pretty powerful for the kinds of things folks might do screen wise.
Kind of a kick to have the Prop run an old Big-Iron looking green screen, eh?
> There are 256 total, so one could do a 16x8 grid with those and locate it somewhere on the screen.
> That's a 128x64 graphics window. Done in the 40, 32, or 16 column mode
Because it would be a 16x8 grid, does that mean max col width is 40? (E.g. an 8x8 could give 80, so 16x8 is half as much) Or is having an 80 col line make too big a mem. footprint?
Keep up the good work, this is geeky, but cool stuff!
The limit is actually the number of redefinable characters.
There are 256 of those. Let's say half get used for GFX. That means 128 8 pixel x 8 pixel cells. You can stack them up all in one place, so 8x16 or maybe use them in a few places: 8x8 and another 8x8 group, or just use them as custom characters.
So, in Firefox, you put your cursor on the link to the file, right click and select "save link as" and select a place to deposit the file. For Internet Explorer, you do the same thing, only you choose "save target as".
Either way, you get a file on your computer.
Right click on that, select "rename", then remove the .safe from the file.
You may actually have file extensions turned off on your computer. If, when renaming the file, you don't see the full name, this is the case. So then, in windows explorer, you would do the following:
Select "tools", then "folder options", then view. Here is where you see all the file view options. The windows default is to hide system files and extensions. Look through that list until you find "hide extensions for known file types". Uncheck this, then hit the "Apply to all folders" button. Go examine the file you downloaded and it should then display as "something.zip.safe" Rename it, to something.zip, then you can un-compress it to view the archive.
Hidden file extensions are a major league PITA.
If you are not seeing these things, let's talk about that to fix the problem, not cure a symptom of it. That way, it's done then, and you are better for it!
Comments
In the mean time, I've cleaned up the code and wrote some very basic SPIN procedures to control things. Here is the basic info.
Some parameters are live. Driver will respond next frame max, they are:
TEXT.CharsPerLine(32) This can be 16, 32, 40, 64, 80. It sets a value used by other functions, so run it before doing things like TEXT.ClearColors.
TEXT.Interlace(0) 0 = interlace, 1 = no interlace.
TEXT.ColorMode(0) 0 = use color cells, non zero defines two color per screen mode. $00_00_02_07, would define bright white chars on black background.
Use color mode on 80Mhz boards to get 80 character text. The max with color cells is 64. Or use it, to just not do color cells.
The following things are not live. They just operate on the font, text screen, color screen.
TEXT.ClearColors(07, 02) = Sets all the color cells to the values given. This would define dark characters on white background. If one value is a zero, then no change will occur. This permits changing the background color of some characters, without having to change the foreground also.
TEXT.Redefine ($81, $ff, $F0, $0F, $F0, $FF, $F0, $0F, $FF) == The first parameter is the character number, the other 8 values are binary data for that character definition. OBC asked for this.
TEXT.SetTextAt(0,0, $84) = Sets a given screen location to a given character value.
TEXT.RedefineDat($81, @Line) = This redefines a character from DAT data.
TEXT.PrintStringAt(3,1, string("In Line Text String [noparse]:)[/noparse]")) == Prints a zero terminated string at screen x, y.
TEXT.SetColorCell(1,0,$cb, 02) = Sets the color values for a specific color cell located at screen x and y.
Archive attached. If you've an idea about the missing pixel, let me know. If you use some of the functions, let me know. If it fails to display on your device, let me know.
Getting closer!
BTW: After hammering my brain in PASM, SPIN was fun! Imagine that!
**I've no idea why the forum will no longer let me upload a .zip, but that appears to be the case for a while now. Rename .safe to .zip to unpack the archive.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 10/11/2009 10:35:25 AM GMT
Thank you for this release!
Minor feature request: (While you are hunting for the pixel you misplaced.)
Could you include a "set it and forget it" color command?
Something along the lines of .setcolor(FG,BG) which keeps that color until it is called again?
Already working on a PropDOS update.. [noparse]:)[/noparse]
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
For now though, it appears as if we have a 7x8 NTSC driver. WTF?!? I'm up this morning going to run older revisions to see where it goes away... I'm laughing this morning, but man, I was hot last night. Jim had all kind of trouble with the Apple driver and 7 pixels, and here I get it easy cheezy... I suppose this is a great example of why it's a good practice to keep code revision history. Maybe it's still 8 pixels, but shifted.
I figured you were in the mood to start bolting things together, which is why I went ahead and posted this up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 10/3/2009 4:10:28 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
So, it's an 8x8 driver with no core ugly problem after all. Most of the bit patterns were fine. I might not have found this, but for redefining characters. Thanks go to OBC on that one, for asking in the first place.
I'm going to attach the archive to the top post.
"set it and forget it" color function added. It's only active with the PrintTextAt method at present. Maybe that's the only one that makes sense, I don't know. At some point, I figured this would get bolted on, or under the same kinds of things AiGeneric was. I was not part of that, so... there you go. Example code provided.
If you all have time to bang on this a bit, or write a library function, or have a display issue, etc... let me know. I'm going to go back and work on the TODO list.
That's:
C64 video output option (Interlaced horizontally, but not vertically)
Mouse Pointer
Border graphics tweaks
S-video (next weekend probably)
Whatever comes up.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I've started adding some routines to the ...Start_RC1.spin
Is there any chance we could get you to add a Scroll routine?
Use of the added routines might limit someone from changing resolution on the fly,
but would provide pretty much a drop-replacement for AiGeneric
The added parts are remarked. (and untested at this point)
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
When changing resolutions, screen_width is updated. All that is needed for the changes to work is to maintain a few variables that know the state of the display. Routines that are display state dependent just need to use those variables, or store a few.
IMHO, the only one needed so far is screen_width. That determines how much RAM to clear, or set color / character values. It can do scroll too.
Scroll can probably be a bytemove and maybe add clear line.
I'll take a look at those on the next run.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 10/4/2009 4:13:18 PM GMT
* Optionally allow for 24 line display and not touch the 25th line as it is often used for a status line.
* The whole screen can be done extremely fast in one set of moves if done in pasm.
* The scroll can be done using longs (much faster)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
Scroll deffo needs the 24 line option, I had that one in mind as line 25 is a status line for a whole lot of things. Happens with line 0 too. The text screen is currently byte aligned. Maybe a small buffer takes care of the alignment issue that's going to come with using words to scroll. Truth is, I think SPIN will nail it in less than a frame either way. With text, it's basically down to the frame. Anything faster boils down to tearing and more eye fatigue than even the TV display brings.
Did some display testing today and I think I figured out what Eric was telling me above. On NTSC, the color interlace, or AKA "shimmer" depends on the relationship between the length of a scan line, and the free running color clock. I ran several displays today, non-vertically interlaced, and shortened the front porch timing. Bingo! Got exactly what I was looking for, which is the 30Hz shimmer on a non-vertically interlaced display signal.
Now, if there is some bad effect to that, somebody let me know. I'll have to code up some display tests this week to refine this option. On a side note, that puts a SIMPLE_NTSC signal back on the table, which is useful for generating lots of colors on NTSC. I wanted that for reasons unrelated to this driver effort, which will remain text + mouse.
Heater, et al. you CP/M guys can tell me. Did CP/M programs ever use a memory mapped screen, or is the whole works just serial I/O? Secondly, assuming you do use the text driver, how would you use it? If sound is not required, nor the better color Eric's sprite driver makes use of, only three pins are required for a nice signal. Unless I'm mistaken, this signal can be S-video or composite as well, with only the three pins being necessary. From what I can see, triggering S-video simply moves the color signal from start_pin + 1 to start_pin+3, so then, if somebody wanted an S-video connection, I see no reason why they couldn't just wire up the standard three pin video circuit and provide a switch to either run the color with the rest of the signal, or run it on it's own line.
Finally, what use of color was there in CP/M?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
It's on my list if someone doesn't beat me to it.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
Drac can answer better than I, but CPM uses a serial VT100 terminal by default. Probably only a subset is used. Originally, only monochrome was used (white or green on black) with the top bit used for inverse. Later some basic colors were used. The edit programs (Wordstar and Vedit kept their own screen copy within the CPM Ram, but still used a remote VT100 terminal, which at the time (before VT100 terminals became readily available - they were about $3000 a piece originally) we used to build our own terminals - and I mean 3-4 pcbs + motherboard·with logic and memory chips (1Kx1)·chips before the advent of the 6845 etc.
My RamBlade (final announcement shortly) for ZiCog/CPM/PropDos will have 2 build options...
* Prop, Ram and microSD with 2pin serial connection to a second prop such as the ProtoBoard or DemoBoard, etc
* Standalone·will use a PS2 keyboard and the 1-3 pin version of TV, requiring only a keyboard, TV and powerpack, in about a matchbox size
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade, RetroBlade,·TwinBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: Micros eg Altair, and Terminals eg VT100 (Index) ZiCog (Z80) , MoCog (6809)
· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBladeProp is: www.bluemagic.biz/cluso.htm
Post Edited (Cluso99) : 10/5/2009 3:54:30 AM GMT
Vince used the core in his Propeller Based Terminal board.
IIRC, didn't Mike Green do a cleaner VT100 emulation? I can't remember, but I thought
he was working on it as well.
At any rate, shouldn't be that hard to adapt.
OBC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
New to the Propeller?
Visit the: The Propeller Pages @ Warranty Void.
However there have been many machines with memory mapped displays. For example the Amstrad "Joyce" had a monochrome pixel display controller using up to 22.5k bytes of the standard RAM as screen refresh memory. It also supported 2MB of bank switched RAM. The Amstrad CPC were colour.
Then there was the MSX standard.
These machines used the GSX graphics interface standard.
I think all of this is out of scope for what you are up to.
Amstrad Joyce - www.chiark.greenend.org.uk/~jacobn/cpm/pcwio.html
GSX - www.seasip.demon.co.uk/Cpm/gsx.html
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.
You are right, that is out of scope. The core idea for this project was to get a solid text display that could do ANSI, and do early 8 bit redefinable character graphics. Think most of a VIC 20, with a hardware mouse pointer. That level of functionality consumes some Propeller RAM, and is a nice balance between the need to display, RAM consumed, and that required for a simple and effective GUI.
The idea of a terminal really was secondary. Now it makes perfect sense. The capability here is ANSI / VT100+ so that's actually going to be quite useful. I may well build a terminal, just because. I've got a very nice, spare LCD, and some other goodies. Frankly, I've not done hardly anything with serial I/O based systems, but for some big Unix iron, and where I could, I did X window to largely avoid that.
Finally, for my own project work to come, having simple text output is a must for debugging, etc... A memory mapped screen is quite useful for a lot of these things, particularly if a hex font is used. (where each character simply displays it's hex value)
I'll make sure the monochrome options are clear, so the colors data can be omitted. That's perfect for where you guys are going right now.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
I'm working on debug tasks in the simple library commands to be included, renaming and commenting some things, and in general, cleaning up the functions achieved so far. I've a bit of an interesting challenge with the mouse. There is time in the text cog, but the order of things is trouble for the fast loop built last major re-write. Am thinking on that, and any suggestions welcome. Might hack on it this weekend.
The other thing is some useful demo code, instead of some random Smile. I added a color lookup table in SPIN, so that colors are nice and sane. Screenie attached. Basically intensities run from 0 to 8, with the higher ones duplicated a time or two to round things out. For each hue, I've sorted the nice, in spec, low saturation colors into the lower intensities, then sorted the out of spec, high saturation colors so they match the base hue closely. The result is an easy way to specify colors, without having to worry about hitting one of the Propeller dead spots, where it outputs sync, or something other than just a simple color. If you are writing to the screen and color RAM, you have to maintain your color space. If you use the functions that come with this thing, you don't.
The "set it and forget it is done", as is the basic functions all working with whatever screen resolution is selected. The major debug is between the text cog and the TV cog and stuff occurring in the borders. Once that is sorted, it will be time for the mouse. I'll post up an archive sometime this weekend. Ideally, this will be RC2.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Frankly, I think I'm going to leave the functions OBC asked for, and whittle down the remaining ones to be that set required to support the ANSI codes, and control the driver modes. That will put the mouse off for a bit, but that's fine. My intent was good TV text, no matter what, and add things from there.
Next post won't be RC, but another Rev to vet the ANSI library. Feature creep... [noparse]:)[/noparse] Never mind on this. It's just RC2, because the core stuff is gettin' close. ANSI / VT and other things will be add-ons, that can have their own tracking for eventual posting in the OBEX.
@Jazzed: Sorting the colors makes a world of difference, doesn't it? I've still got to hook up an S-video circuit, or cut a trace somewhere... There is probably time tomorrow to go pick up some resistors. I'm really curious to see how the color plays out.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 10/12/2009 12:26:54 AM GMT
For color, all the functions but the TEXT.SetColorMode one operate with the color look up table for a nice color space. Intensity is 0-7. Every hue then is a multiple of 8. I've moved a few entries around so the color set is more consistent. There might be a little more of that, depending. The high-saturation colors are always 8*HUE+6 and +7, for easy reference. Nice, in spec colors are 8*HUE+0-5. There are 16 hues, making a fairly sane and easy to use Propeller color space. I've struggled with this, and like this scheme a lot.
Border graphics are fixed now in multi-color mode. Those were causing some display issues on some devices. The Palette Demo code should now run on all devices, all character resolutions (8, 16, 32,40, 64, 80), and both clocks. Let me know if your display has trouble with a given mode. I tested through each, at both 80Mhz and 96Mhz clocks. Looks good here.
I'm going to look the ANSI code that Mike posted over. One question about that: As things are right now, everything needed for a nice text display is included and working nicely, I think. If things like ANSI / VT-100 happen, should those go into the driver start SPIN program where the basics are right now, or be contained in their own SPIN file? Just wondering how people do or prefer those kinds of things.
Does anyone else find themselves unable to upload a .zip file all of the sudden? It's bizzare, having to rename. That never used to be the case.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
hope I can find time to fiddle with this soon.
Steve, why not?
[noparse][[/noparse] DQOTD·
(dumb question of the day [noparse]:)[/noparse] ]
- H
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
After the text, some graphics oriented stuff will happen. In between projects, I've went back and explored some of the old 8 bit computer hi-color tricks. One of those is in the Propeller Wiki. PAL has the ability to do this kind of a thing at higher resolutions, and NTSC has some variations that make more sense than that method did. It's possible to get a nice, full byte of color on this chip, without special circuits. Then there is the great color Eric has produced as well. There are lots of possibilities and I like working through them. For text though, it's just best to stick with the native Propeller colors. There are plenty of those --more than enough.
Yeah, board configuration is always a PITA. The only thing I know to do is get better at docs, and compute more things so people have less to manage when configuring. The auto-detect is kind of limited. Doesn't work on all boards. Might be able to extend it some. Frankly, I just used the code Coley worked up, and that Eric merged with his core video template. It's a great starter, as most of the common boards out there fire up without a hitch. At least that gives people a check to work from. I find doing this the hardest when there isn't a known good check 'n test scenario.
BTW: On this one, you can do simple graphics. What you do is stack up a bunch of the characters in a square grid, then redefine them to show images. Good for simple charts, graphs, etc... Really the focus is for simple GUI, data output, etc... All of those things one would use the tv_text and AiGeneric for. tv_text is useful, but fonts and such are kind of big and complex. AiGeneric is actually sweet, but limited by the poor signal output quality. That all came from my earlier "Atari Style" video output. Not enough color resolution there to really do text proper. I struggled with the Parallax driver, and found the scan line template Eric did just excellent. Most all the good signal characteristics are easy to do, and with TV, that matters. Maybe it's worth doing simple, plot, line, etc... for that. Would not take a ton of spin. Could just put that in a seperate file, so if it's not needed, then it just doesn't happen.
I'm thinking DrawGraphicsAt([noparse][[/noparse]screen start x], [noparse][[/noparse]screen start y], [noparse][[/noparse]number of chars used x], [noparse][[/noparse]number of characters used y], [noparse][[/noparse]start char]). Say 128 characters are in use for general communication. There are 256 total, so one could do a 16x8 grid with those and locate it somewhere on the screen. That's a 128x64 graphics window. Done in the 40, 32, or 16 column mode, it would occupy a nice fraction of the screen. So, one could have text output of data, prompts, and some basic graphical feed back. Use the color cells to color that feed back, and get a nice little chart, data plot, indicator, etc... Could run a little pong game, or something in there too. Plain old SPIN is plenty fast enough to do those things. Another COG could be writing to that window, as well, showing some kind of feed back. Think like what Chip did with the higher resolution VGA driver, only with a smaller footprint overall.
Breaking into files is a good thing then. One core set to just throw up the driver. Comment a thing or two for mono, small memory CP/M quality stuff. Include very basic functions coded so far, then separate files for things like ANSI, VT-100, TV_TEXT, GRAPHICS. Reference what is needed, forget the rest. That way, a minimum of fuss is required to operate it at the functionality appropriate for the task at hand. This means others can contribute stuff, without having to tear into the core wad of code. So, that's some work exposing the right vars to other programs, and being somewhat picky about the core library of functions included in the base driver set. I'm feeling really good about those right now. Just enough, but no more. Might find there is one that is needed, so it will get added. That then, is the API, so to speak. Write to that with few worries, and read the DAT area for run-time info. A lot of this stuff is new ground for me, so I'm happy to plug away and see where it all goes.
@counterrotatingprops, he's referring to the color cells. As it stands right now, any 8x8 area can have two colors. That's really good on RAM, but not so good for pictures and such.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
Post Edited (potatohead) : 10/11/2009 9:27:51 PM GMT
OK - thanks - it makes more sense now.
> Breaking into files is a good thing then. ...
> ... separate files for things like ANSI, VT-100, TV_TEXT, GRAPHICS.
Yes! This is a good idea, generally.
I enjoyed the old-school ANSI graphics. And VT-100 is pretty powerful for the kinds of things folks might do screen wise.
Kind of a kick to have the Prop run an old Big-Iron looking green screen, eh?
> There are 256 total, so one could do a 16x8 grid with those and locate it somewhere on the screen.
> That's a 128x64 graphics window. Done in the 40, 32, or 16 column mode
Because it would be a 16x8 grid, does that mean max col width is 40? (E.g. an 8x8 could give 80, so 16x8 is half as much) Or is having an 80 col line make too big a mem. footprint?
Keep up the good work, this is geeky, but cool stuff!
- Howard
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
There are 256 of those. Let's say half get used for GFX. That means 128 8 pixel x 8 pixel cells. You can stack them up all in one place, so 8x16 or maybe use them in a few places: 8x8 and another 8x8 group, or just use them as custom characters.
I'll have to knock up a little demo of this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Computers are microcontrolled.
Robots are microcontrolled.
I am microcontrolled.
But you·can·call me micro.
Want to·experiment with the SX or just put together a cool project?
SX Spinning light display·
So, in Firefox, you put your cursor on the link to the file, right click and select "save link as" and select a place to deposit the file. For Internet Explorer, you do the same thing, only you choose "save target as".
Either way, you get a file on your computer.
Right click on that, select "rename", then remove the .safe from the file.
You may actually have file extensions turned off on your computer. If, when renaming the file, you don't see the full name, this is the case. So then, in windows explorer, you would do the following:
Select "tools", then "folder options", then view. Here is where you see all the file view options. The windows default is to hide system files and extensions. Look through that list until you find "hide extensions for known file types". Uncheck this, then hit the "Apply to all folders" button. Go examine the file you downloaded and it should then display as "something.zip.safe" Rename it, to something.zip, then you can un-compress it to view the archive.
Hidden file extensions are a major league PITA.
If you are not seeing these things, let's talk about that to fix the problem, not cure a symptom of it. That way, it's done then, and you are better for it!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
Chat in real time with other Propellerheads on IRC #propeller @ freenode.net
Safety Tip: Life is as good as YOU think it is!