<wpwrak>
hmm, i have one extra bit for ubb-vga. i could use it to upgrade one channel (R, G, or B) from 1 to 2 bits, or i could use it to resistively mix an offset to all channels. any idea what's better ?
<wpwrak>
maybe i should simulate the thing ...
<kristianpaul>
upgrade is good, no?
<wpwrak>
i wonder what would look better. in each case, you'd get twice the colors
<wpwrak>
upgrading one channel is easier ;-) for mixing to all, i'd probably have to get the difference vectors to all possible colors in RGB space and calculate their length. the pick the color that's closest.
<wpwrak>
DocScrutinizer: uh, that would require transistors
<DocScrutinizer>
really?
<DocScrutinizer>
hmm, yes, for batery it would
<wpwrak>
DocScrutinizer: i'd like to keep this very very simple. my idea for the one bit would be to connect it via a resistor to each channel, kinda like a "bright/dim pixel" switch
<DocScrutinizer>
rise that "GND" by 0.2V and your output volage rises from 0.7 to 0.9
<wpwrak>
aah, okay. that would be an option. couldn't get rid of the diodes then, though.
<wpwrak>
but i could try the same with Rs ...
<DocScrutinizer>
or, for schottky, it rises from 0.3 to 0.6V
<DocScrutinizer>
nope, with Rs you get crosstalk
<DocScrutinizer>
lots of
<wpwrak>
crosstalk is okay as long as i can calculate it :)
<DocScrutinizer>
lol
<wpwrak>
i would basically get 16 points in 3-dimensional RGB space and then have to try to find the one that's closest to the pixel value. even old pythagoras cuold have done that ;-)
<DocScrutinizer>
I'd do a weird thing ;-P
<wpwrak>
random() ? ;-)
<DocScrutinizer>
build an ultrasimple rather slow S&H strobed by the 4th bit, then add the value of the S&H to the 3 bits
<wpwrak>
hehe, nice :)
<wpwrak>
but that doesn't work. i'm already fighting with pixel timing
<DocScrutinizer>
yeah, but then you can have 9bpp and just a smaller resolution, for arbitrary areas of screen
<wpwrak>
oh, i see :)
<wpwrak>
well, i already kinda mix two pixels into one in "single" mode ..
<wpwrak>
may be able to disentangle them a bit, though. we'll see.
<wpwrak>
the main problem are the dreadfully slow GPIO updates. a set-clear pair takes 17 PCLK cycles. PCLK is 112 MHz.
<wpwrak>
when i try to change PCLK (even make it slower), the system freezes. not sure yet why.
<wpwrak>
another problem is memory bandwidth. also there, i'm close to the system's limits. not because i'd move so much data but because i need to squeeze it in the intervals in which i'm not busy pumping out pixels
<wpwrak>
and read-as-you-go is too slow
<DocScrutinizer>
yay, funny. Sounds like ZX81
<wpwrak>
oh yes, very :)
<wpwrak>
DocScrutinizer: of course, in the ZX80/ZX81, they cheated and had hw video acceleration, while my little ubb-vga does it all with brute gpio force
<DocScrutinizer>
you're sure about the hw accel?
<kristianpaul>
what is a hw accel for a Z80 btw...
<whitequark>
wpwrak: uh-oh, I'm talking with The Creator of pstree!
<wpwrak>
whitequark: heh, you found the man page ;-)
<dvdk>
whitequark: you mean with the author of the man page :)
<wpwrak>
dvdk: naw, the program as well :) i actually don't remember if i also wrote the man page or if this was someone else
<dvdk>
apt-get source psmisc
<dvdk>
:)
<dvdk>
Copyright (C) 1993-2002 Werner Almesberger
<dvdk>
wow they had computers back in 1993?
<dvdk>
wpwrak: did you see the mail about vga?  wondered why you had to use dats/datc , not just write to dat once per pixel
<wpwrak>
;-))) my first linux box was a i386dx with 25 MHz (or was it 20 MHz ?), 4 MB RAM and a "Hercules" video card. the hard disk had a whole 40 MB. that was so big that you had to split it into a 30 MB partition and a 10 MB partition.
<kristianpaul>
* pstree.c - display process tree
<kristianpaul>
*
<kristianpaul>
* Copyright (C) 1993-2002 Werner Almesberger
<kristianpaul>
:D
<kristianpaul>
* Copyright (C) 2002-2009 Craig Small
<kristianpaul>
yes seems they had dvdk ;)
<wpwrak>
i had my DOS on the 30 MB partition and have 10 MB to that new Linux thing (0.12). a bit later, Linux got the 30 MB and DOS had to content itself with 10 MB. again a little later, Linux got a 10 MB swap partition :)
<kristianpaul>
lol
<wpwrak>
ironically, back in those days (gcc 1.xx), compiling a kernel was faster than for many years afterwards (gcc 2.xx and beyond)
<kristianpaul>
how fast? (i want to wonder)
<wpwrak>
dvdk: (vga) yes, the problem is that you can't write to PxDAT. you can only write to the set/clear registers. it's a nice idea to make sure operations are atomic, but in this case, it's quite inconvenient.
<dvdk>
wpwrak: ah, you mean pxdat is read only?  didn't realize that
<wpwrak>
kristianpaul: ah, don't remember how long it took. just that it was fast. well, it also helped that linux had hardly any drivers back then :)
<wpwrak>
dvdk: yup
<dvdk>
wpwrak: but isn't there a 'toggle' register?
<kristianpaul>
wpwrak: yeah drivers... always the problem is there..
<kristianpaul>
well not always, but is not that the code that grown all days..?..
<dvdk>
wpwrak: no toggle register afaics.  uhh :(
<dvdk>
wpwrak: btw, creating ntsc/pal timiings would give higher resulution
<wpwrak>
dvdk: no toggle either
<dvdk>
(looking at the video drivers of the uzebox)
<wpwrak>
dvdk: oh, i'm already maxing out the timing. in fact, even in "single" mode, i'm taking about 110% of the "official" time
<kristianpaul>
heads to travel
<kristianpaul>
read you later
<wpwrak>
dvdk: the nice thing about digital monitors is that they try to re-interpret the timing on their own, so you can feed them pretty weird stuff and they'll still work
<dvdk>
wprwrak: i mean vga needs higher line clocks than ntsc/pal.  so going for vga approximately halves available resolutions.  the uzebox people have even slower i/o so they can only do ntsc/pal, as vga would not be usable
<dvdk>
wpwrak: used to write my own mode-lines for xservers, didn't know there was even a standard (that was on analog monitors, anyways).
<wpwrak>
dvdk: (slower pixel clock) ah, i see. yes, that's basically what i do in "double" mode. there, my effective pixel clock is something like 6 MHz
<wpwrak>
dvdk: mostof the time
<wpwrak>
oops ... ente too early
<wpwrak>
dvdk: most of the time, the monitor doesn't seem to care about the pixel clock (only when trying to figure out the phase), so what's really important are the vsync and hsync timings
<wpwrak>
dvdk: i also found that trying to send every line only once was met with disapproval
<Fusin>
is reflashing his ben
<Fusin>
well, I try and hope it will all function ;)
<dvdk>
wpwrak: that's the advantage of pal/ntsc, where sending each line once would work
<dvdk>
s/would/might
<dvdk>
wpwrak: can't one use the 4-bit sdio data lines to directly bit-stream each line at the mmc clock rate? (i.e. one block transfer per line)
<dvdk>
wpwrak: only handling vsync via bit-banging
<wpwrak>
dvdk: hmm. there's a "busy" handshake in SD. lemme see if i could get rid of that ...
<dvdk>
is looking up the datasheet
<Fusin>
flashing... flashing...
<Fusin>
takes a while coz connection to inet is per 3G
<Fusin>
is impatient ;)
<wpwrak>
dvdk: hmm. sending a block without first receiving a response isn't something SD/SDIO would do. makes one wonder what would happen if we asked the MMC controller to do it anyway.
<dvdk>
wpwrak: what about the stream transfer mode, the datasheet talks about?
<dvdk>
wpwrak: isn't mmc just a subset of sdio?
<dvdk>
so maybe it's ok for sdio?
<dvdk>
wow, just encoded an old 4:3 movie for nanonote.
<dvdk>
encoded for full-screen 320x240 , plays without problems so far
<wpwrak>
not quite sure yet what that stream mode is ...
<dvdk>
the datasheet is pretty bad.  the freescale imx datasheets have quite a number of details about sdio; maybe it's pretty close to the jz47xx hw?
<wpwrak>
dvdk: (vga) i was able to trick it into pumping out data. one problem is that i need to toggle CMD to fake a response from the MMC device. otherwise, it won't start the transfer.
<dvdk>
wpwrak: cool.  so can you toggle CMD automatically using just gpio control registers.  or is real hw needed?
<wpwrak>
rejon: just too bad VGA is slowly dying ...
<wpwrak>
dvdk: just the GPIO, it seems. i hope this are not just some unreliable internal effects. residual charges on tri-stated bus lines or such.
<rejon>
wpwrak I think we have a long time left on vga
<rejon>
wpwrak what resolution do you think that VGA can get cranked up too?
<wpwrak>
dvdk: i could perhaps still use CMD for VSYNC, with a little low-pass filter
<wpwrak>
rejon: (resolution) don't know yet. i think i need at least VGA to get the timing right. there's a lot of "MMC" traffic happening before the pixel data.
<dvdk>
wpwrak: if continuous transfers work, don't you have to toggle cmd only once, and then keep streaming forever?
<wpwrak>
dvdk: (continuous) ah, maybe. haven't tried that yet.
<rjeffries>
somebody needs to alert tuxbrian that Easter holidays are complete. back to work! <grin>
<rjeffries>
s/tuxbrian/tuxbrain
<wpwrak>
rjeffries: monday may still be a holiday in spain (as it is in most of europe)
<rjeffries>
wpwrak VGA is an analog display (I think) what parts would be required so (external to Ben) we have SPI input from Ben, and HDMI out (to display or TV)?
<rjeffries>
I know tehre are several USB to dsiplay adapters a similar idea I think?
<rjeffries>
actually... this takes me back to thoughts of external Propeller board. just a brain excercise is all
<rjeffries>
by the way I contacted a guy who is close to the whole Propeller/Parallax stuff and he says teh follow-on will happen this year, will have new name
<wpwrak>
rjeffries: i don't know HDMI. i would expect it to operate with a faster clock than what we can usefully provide
<wpwrak>
ah, minimum clock speed of DVI is ~25 MHz. that would work.
<wpwrak>
that is, if that's the link clock, not the pixel clock. looks like pixel clock, though
<dvdk>
wpwrak: looks like 25 mhz is the pixel clock :(
<wpwrak>
ah yes, data clock = 10 x pixel clock. that would be 251 MHz. no way.
<rjeffries>
wpwrak couldn't the clock originate external to Ben? (pardon my massive ignorance)
<rjeffries>
if the external widget has memory, copy our framebuffer to it, then all magic happens elsewehere
<wpwrak>
lekernel: what has the world come to ... nowadays a torturer can't even enjoy his easter holidays in peace. the inquisitors sure had it better.
<wpwrak>
rjeffries: trying to compete on low cost and high volume is a dangerous path for a high-overhead company like nokia. maybe they can beat apple, but they they're up to every single backyard CE fab in china. DVD players anyone ? ;-)
<wpwrak>
rjeffries: of course, a drowning man will cling to anything :)
<rjeffries>
IMO Nokia will make it, no question.  And they know how to manufacture in VERY high volume
<rjeffries>
back in the day when I worked for Ericsson one person explained how crucial software quaity is
<rjeffries>
as he put it, they were shipping a 747 worth of phone to China, per day
<rjeffries>
Nokia tablet that is NOT Microsoft would be a good idea IMO
<wpwrak>
rjeffries: i'm pretty sure those 747 are national flights today :)
<rjeffries>
yes indeed. nobody builds anything in quantity oustide of asia. sadly
<wpwrak>
rjeffries: nokia is now wed to M$, probably till death do them part
<rjeffries>
I am amazed at the uptake of iPhone in China. many rich people I guess
<rjeffries>
Intel so far is missing out on tablet wave
<wpwrak>
rjeffries: maybe they just plan to sit it out. tables have come and gone so many times before, expecting them to disappear after a while wouldn't be the worst conclusion to draw.
<kristianpaul>
wow 78905 :-)
<wpwrak>
rules ! :)
<wpwrak>
it's kinda surprising that ingenic implemented stream mode. this thing is as close to vapourware as one can imagine. some specs are full of hints yet nobody actually documents it.
<wpwrak>
ah, JEDEC JESD84-A441 has some more details.
<wpwrak>
grmbl. MMC specify stream mode only for a 1 bit bus and ingenic implement this restriction :-(
<rjeffries>
wpwrak when we have 4760 (it just a matter of time...;) will the increased CPU speed help with VGA hack?
<wpwrak>
rjeffries: maybe. if things go well, then i'll use mainly the MMC controller, so the CPU speed would be less important
<roh>
mmc isnt dead yet?
<wpwrak>
roh: they're still making new standards, it seems :)
<roh>
m-/
<roh>
.s
<roh>
hm. can somebody explain to me what i missed?
<roh>
why is vga so important for you?
<wpwrak>
oh, it fun :)
<wpwrak>
s/it/it's/
<wpwrak>
besides, it may actually be useful. imagine giving a presentation with a ben :)