Potatotext being revised & Bean Embedded Basic WIP
potatohead
Posts: 10,261
I've got the first working copy up on my blog, here: http://forums.parallax.com/entry.php?129-16-Color-Potatotext-8x8-NTSC-TV-Driver
The big feature changes on this one are:
Smaller HUB memory foot print, byte color instead of word color. 16 color operation. Much simpler configuration, though I still need to code up the counter number needed to get the colorburst.
There are some plans in the TO DO part of the file. I'll post as I go along. Mainly this one was to get color text for TV to a much smaller foot print, and allow for old school 8x8 definable characters for Bean's basic, which I can't wait to try!
It's pretty easy to kick out a render COG that does not do text, but just does a bitmap. Two colors per 8 pixels, 16 color screen total with the same format. One byte colors, one byte pixels. Anyone interested in that?
The big feature changes on this one are:
Smaller HUB memory foot print, byte color instead of word color. 16 color operation. Much simpler configuration, though I still need to code up the counter number needed to get the colorburst.
There are some plans in the TO DO part of the file. I'll post as I go along. Mainly this one was to get color text for TV to a much smaller foot print, and allow for old school 8x8 definable characters for Bean's basic, which I can't wait to try!
It's pretty easy to kick out a render COG that does not do text, but just does a bitmap. Two colors per 8 pixels, 16 color screen total with the same format. One byte colors, one byte pixels. Anyone interested in that?
Comments
You've got my attention..
OBC
It takes two cogs. They are currently somewhere under 2.5K RAM in the HUB, if included the usual way in a SPIN program. Binary versions will be produced that can be loaded from SD card, into the screen buffer. If that is done, or the COG HUB memory footprint is used as the screen after the driver is started, there is no HUB memory cost
A 128 character font takes 1K HUB RAM.
Screens are one word per character, and they range from 20x25 to 80x25, which equals 1000bytes to 4000 bytes. There is a small HUB buffer area needed, which varies from 80 bytes to 320 bytes, depending on the screen chosen.
40x25 screen, which many people will likely prefer on TV would then be 160 bytes+2000+1024 = ~3.5K
Have you thought about handling flashing or character, so that VT100 could be emulated?
--trodoss
Flashing would have to give up some color attribute bits, and would take a counter, branch and test in the render cog loop. It's possible, though that would probably keep it at 64 chars at 80Mhz. For composite, no big deal. Few displays will render 80 well. But, with S-video, that changes, so I'm really torn on giving up the 80@80.
The options I am seriously considering are:
- 50 line display, interlaced. Would work sweet on a older composite monitor, or a s-video running monochrome, or some color. Not sure how practical that is, but I kind of want it, and who knows? Maybe a few folks out there have older composite displays, or will run on a PC capture, both of which would display that very nicely.
- s-video output. I'm gonna wire up my PPDB to explore this. There are a coupla S-video capable boards out there, Propcade is one. S-video mono rocks. 80 reads easily on my displays running that way.
- put first 128 chars into the render COG. There is room for them. That too would probably cost the 80@80, but freeing up 1K of RAM in the HUB is probably worth it. That's the one real downside to 8x8 displays. Gotta pack a font into the HUB. I think we heard a 8x8 will be in the Prop II though.
- Other render cogs that do bitmaps and such. That might need to just be another driver entirely, depending on how far the TV COG can be pushed.
- VGA port of the TV COG.
- Documentation, easy config, one, two, three kind of thing. If that code base gets done, future works, or bringing older driver code forward will be easier to do and easier for people to use. Currently, it uses the Coley autoconfig, which probably could be expanded for some new boards. I've a couple now that I didn't have before. That probably deserves a look.
The immediate plan is to make sure what's here is as clean and small as possible. Add S-video and internal font, easy configure options, and document. That will be the OBEX release to support Bean's BASIC, which I'm eager to take for a spin! It will supersede the old potatotext thats in there, though I won't delete the one that is in there right now. Always add code, never remove is my mantra on those things. Because of that, and time overall, I'm gonna keep the focus pretty tight on just completing a well executed text driver.
I think a lot of people will want to jam on the BASIC, so the configure options and documentation is very high priority right now. Maybe go "Gold", heh
From there, maybe do some of that other stuff.
The old ZX Spectrum TV driver used indexed colors and handled this. I haven't looked at that driver in a long time though so I don't know if they contained the fore/back in a single byte, or if there was a separate byte for fore, back, attribute, char. Maybe that would be something worth looking at?
I will work on getting this incorporated into Embedded BASIC tonight.
I'll add a command to select the screen width, and enable/disable the colorburst.
Should have it working in a couple days.
Memory is a concern, every K used for the display is a K lost to program space.
Do you think 80 @ 80MHz is going to happen ? It might not look too good for text, but might be cool for games (same with 50 row display).
Bean
Are you going to do a .redefine command so that folks can pass character changes on the fly like this? http://forums.parallax.com/showthread.php?98984-FemtoBASIC_COLOR-Updated-with-cursor-string-support
With the speed of Bean's basic compared to my old Femto mod, games should actually be possible.
OBC
From that you can POKEB the values, but a REDEFINE command might be nice to make it easy.
The one hang-up now is there is no way to get code in or out. It only saves and loads to the EEPROM.
Not enought space for SD card routines... maybe a custom PC program to communicate via serial for save/load...
Bean
Seems to me a secondary program can fetch code from eeprom. Do whatever needs to be done in BASIC, then load the EEPROM management program to fetch code for storage on SD card, and do the reverse later on.
Also seems to me a smaller font definition could be used at the higher screen densities.
I have not seriously explored stuffing the lower 128 chars into the render cog. Could free up ram but will require another config option or two. I'm pretty sure the renderer won't be quick enough to do 80 chars that way though. Could be wrong. Won't know until that gets looked at.
The old speccy driver was at a lower resolution. That's probably enough time to do those things. I think VT100 is a interesting project, though it's not one I can do right now.
Coupla thoughts: One is to manage the blinking at the terminal emulation layer. A few longs could represent the flashing status of the display characters, and could be scrolled with the screen. Done that way, it's just a loop every VBLANK, that toggles the attributes every so many frames, maybe 20 or so. That could be done with no changes to this code.
Another one is Cluso stuffed a nice chunk of a VT100 into one of his mono TV drivers. I think that's a one COG solution, and if so, there is a TON of room in the render COG. Could copy paste that and get a nice emulation with this driver, no blinking though, without some tricks!
It seems to me, a really solid VT100 would be a application that occupies the Propeller more fully, along with SD card, serial, keyboard, etc...
The color are in the wrong order, but I wanted to get it out so people could try it.
Comments welcome.
Bean
P.S. Read the EmbeddedBasic.TXT file
NOTE: Please get the updated version further down in this thread...Bean
@all: In my blog, comment #4, there is a easy fix for the color that will get folded into the next driver release.
@Bean: That was quick! (thumbs up!)
@All: Please post video issues to either this thread, or the blog posting. I've got another version in progress, and will fold those in where possible. Thanks!
' Fixed colors
' Fixed SAVE and LOAD going beyond program area
' Enhanced DISPLAY command (multi parameters, value 10 moves to next line)
P.S. You need to use BST with this code...
The binary is for the Demo Board
Bean
YAY!
You are a very creative coder potatohead.
You'll need a PS/2 keyboard and NTSC (TV) display to use it.
Also you can use CNT to time things in embedded BASIC.
This program takes 28 milliseconds for 1000 for...next loops. Or 28 microseconds per loop.
Bean
I have just done the basic screen control characters. You are welcome to the code
BTW, did you reverse the font to speedup the code? IIRC I also have the font in the cog ram.
I didn't get anywhere near the time I wanted to play, but I will soon. Good grief, screen output speed alone is insane. It's in my demoboard eeprom now, so I can play a little. Need to find some old basic games with keyboard, or something. OBC will probably love this thing. It blasts through little programs like the one in the capture in seconds.
Fat fingered my way to a bug though. Typed "for ==" on a new line with no number, and got "Not implemented", and it hangs. Guess we just don't do that right now. Everything else worked a treat. Again, nicely done. I was not expecting the speed at all. You did this thing in PBASIC? Nice! I'm looking at the LONG PASM listing just kind of checking it all out. Cool beans!
Did anyone determine program code size yet?
@Cluso: Thanks! The HUB font is not reversed. Actually, if it was, I think getting 80 columns would work right now. It's not though. The render cog reverses it on the way to the TV cog. Coupla things improved on this pass. (one of these days I'll quit mashing together video drivers)
Color can be table driven in the TV COG. That means just fetching the color, and self-modifying a waitvid directly. Works great, and could be done with 4 color mode, limited palettes though. Anyway, the other big boost was Eric coming up with a great loop that does two characters worth of scan line data in one HUB fetch. That one rocks, and the TV cog can actually do well over 640 pixels at 80Mhz. Speedy.
A double buffer helps with the render (text) cog considerably. I need to apply some of what you guys have shown me and squeeze a little more out of it to get 80 columns. I think it will do it without having to reverse the font. Haven't tested, but I suspect it's fine right now at 96 and above. The basic is awesome at 64 though. Perfect and I just want to play a little.
Wouldn't mind looking at the "font in COG" code, because that would allow for a color text display, 20 chars by 25 lines to fit in just over 1K of HUB RAM, assuming somebody either binary loads the drivers, or reclaims their HUB footprint for the screen.
There is 4K of code space, but I would like to offer 8K.
The code needs a MAJOR clean-up. It was an on-going project so things have just been bolted-on as I went.
After a cleanup there should be more code space and maybe even a little more speed.
If reversing the font makes life easier for you...Go ahead and do it...It's not a big deal.
Bean
It seems that this version embeddedBasic_0_12.zip only complies with the ntsc option, version 11 compiles fine with all 3 options terminal, telnet and ntsc
But whenever I change it to anything but pins 12-14 I don't get the same signal out. What am I missing?
Thanks. Nice catch. I am just about finished with the next revision. I will add this fix. For now, I guess the right thing to do is edit the private ivcfg, found in the DAT section of the TV driver. Let me know, if that does not work, and I'll squeeze in some time to deal with it ASAP.
And what I was trying to do was save passing another parameter, just for the 2 color region.
In 18_potatotext2_TV.spin
'------------------------------------------------------------- ' Board Specific Parameters '------------------------------------------------------------- ivcfg LONG %0_10_1_0_1_000_00000000000_010_0_00000111 'par +4 ' ASC | (this needed to be changed to a 0)--+