@proplem - Earlier I referred to the KS0108 as a kludge of a kludge, so should it come as any surprise that interfacing to it is a bit of a kludge? The geometry indicates that a byte of pixels are written as a vertical column with 64 columns with another 64 columns in the other "chip". Then after traversing the chips to draw 128 columns of 8 pixels high you then go on to the next line. That's messy and we just need to find a nice simple way to map a conventional raster buffer where a byte of pixels is displayed horizontally rather than how the KS0108 expects it.
So the BitBlit routine actually has to do a bit more than just read from memory, it needs to translate that on the fly. A byte would normally represent 8 horizontal pixels for monochrome so we would actually need to read 8 bytes extracting the same bit from each to build up a byte that we could write as 8 vertical pixels. If we were simply drawing a font that was 8 pixels high there would not be any problem as the font table would be arranged as 5 bytes for each column for a 5x7 font.
Now if we assume we have a conventional monochrome pixel buffer where a byte is 8 horizontal pixels then we would need 16 bytes per line for 128 pixels by 64 lines, that's our 1,024 bytes. You can choose to address this buffer in two ways, either as a linear xy array and remap when you write to the LCD, or define the PLOT primitive to address the correct bit in the correct byte. But drawing is more important than writing to the display which can not handle a high frame update rate anyway, so I would choose a simple linear xy buffer and remap the pixels when I write to the LCD.
You can also write a very short routine that displays this buffer on your terminal screen, mapping a * for a pixel and a dot or space for none. That would be a quick way to confirm it is working too.
BTW, there is a PLOT module in V3 that you could use, just setup the buffer address and pixels/line as a binary shift of 7 bits for 128 pixels at 3 COGREG! and 4 COGREG! for the address.
This would draw a sloped line from top left to the bottom center.
0 64 ADO I I PLOT LOOP
' PLOT ( x y -- )
_PLOT shl tos,pixshift ' n^2 bytes/Y line
mov X,tos+1
shr tos+1,#3 ' byte offset in line
add tos,tos+1 ' byte offset in frame
add tos,pixeladr ' byte address in memory
and X,#7 ' get bit mask
mov tos+1,#1
shl tos+1,X
jmp #SET
PLOT is a RUNMOD so you initially need to load it with [PLOT] and then either use RUNMOD to execute it or it may be more convenient to make an ALIAS of RUNMOD called PLOT
@proplem - just to demonstrate what I mentioned above, here is some "test" code
: SHOW
lcdmem lcdmemlen ADO
CR I 16 ADO I C@ 8 FOR DUP 1 AND IF '*' ELSE '.' THEN EMIT 2/ NEXT DROP LOOP
16 +LOOP
;
ALIAS RUNMOD PLOT
word X
word Y
: !LCD
lcdmem lcdmemlen ERASE
lcdmem 4 COGREG! 4 3 COGREG! [PLOT]
X W~ Y W~
;
--- dummy CR & LF for test
: VCR ;
: VLF DROP ;
--- Draw a Propeller font character on the graphics screen at X,Y
: LCDCH ( ch -- )
DUP 2/ 7 SHL $8000 + --- Calculate address of font character ( ch addr )
Y W@ #32 --- 32 lines
ADO DUP @ --- Next 16 pixels (2 sets)
3RD 1 AND IF 2/ THEN --- If it's an odd character then adjust font pixels
X W@ #16 --- 16 pixels/line
ADO DUP 1 AND --- Next pixel in font set?
IF I J PLOT THEN --- Plot each pixel
2/ 2/ --- shift to next pixel (every second one)
LOOP
DROP 4 + --- next long (line)
LOOP
2DROP 16 X W+! --- Advance X cursor 16 pixels to the right
X W@ 120 > IF VCR #32 VLF THEN --- but move to the next character line down if needed
;
: LCD ' LCDCH uemit W! ;
: DEMO !LCD 0 64 ADO I I PLOT LOOP LCD PRINT" HELLO" CON SHOW ;
Running it on the console
( 0004 $2D4E ok ) TACHYON V4
Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
( 0083 $2ED2 ok )
End of source code, 0000 errors found Load time = 66289504 cycles at 96000000Hz or 690.515ms
Code bytes used = 388
CODE:$2ED2 =11474 bytes NAME:$5C90 =6000 bytes DATA:$76D8 =200 bytes =11710 bytes free Data Stack (0)
( 0084 $2ED2 ok )
( 0085 $2ED2 ok ) DEMO
*...............................................................................................................................
.*..............................................................................................................................
..*.............................................................................................................................
...*............................................................................................................................
....*...........................................................................................................................
..****......***...*************...***.............***.................*****.....................................................
..***.*.....***...*************...***.............***...............*********...................................................
..***..*....***...*************...***.............***..............***********..................................................
..***...*...***...***.............***.............***..............***.....***..................................................
..***....*..***...***.............***.............***.............***.......***.................................................
..***.....*.***...***.............***.............***.............***.......***.................................................
..***......****...***.............***.............***.............***.......***.................................................
..***.......***...***.............***.............***.............***.......***.................................................
..***.......***...***.............***.............***.............***.......***.................................................
..*************...*********.......***.............***.............***.......***.................................................
..**************..*********.......***.............***.............***.......***.................................................
..*************.*.*********.......***.............***.............***.......***.................................................
..***.......***..****.............***.............***.............***.......***.................................................
..***.......***...***.............***.............***.............***.......***.................................................
..***.......***...***.............***.............***.............***.......***.................................................
..***.......***...***.............***.............***.............***.......***.................................................
..***.......***...****............***.............***.............***.......***.................................................
..***.......***...***.*...........***.............***.............***.......***.................................................
..***.......***...***..*..........***.............***..............***.....***..................................................
..***.......***...*************...*************...*************....***********..................................................
..***.......***...*************...*************...*************.....*********...................................................
..***.......***...*************...*************...*************.......*****.....................................................
...........................*....................................................................................................
............................*...................................................................................................
.............................*..................................................................................................
..............................*.................................................................................................
...............................*................................................................................................
................................*...............................................................................................
.................................*..............................................................................................
..................................*.............................................................................................
...................................*............................................................................................
....................................*...........................................................................................
.....................................*..........................................................................................
......................................*.........................................................................................
.......................................*........................................................................................
........................................*.......................................................................................
.........................................*......................................................................................
..........................................*.....................................................................................
...........................................*....................................................................................
............................................*...................................................................................
.............................................*..................................................................................
..............................................*.................................................................................
...............................................*................................................................................
................................................*...............................................................................
.................................................*..............................................................................
..................................................*.............................................................................
...................................................*............................................................................
....................................................*...........................................................................
.....................................................*..........................................................................
......................................................*.........................................................................
.......................................................*........................................................................
........................................................*.......................................................................
.........................................................*......................................................................
..........................................................*.....................................................................
...........................................................*....................................................................
............................................................*...................................................................
.............................................................*..................................................................
..............................................................*.................................................................
...............................................................*................................................................
( 0086 $2ED2 ok )
The complete LCD code the graphics driver ready to add those drawing routines to. The BitBlt needs to translate into the correct register address but at least you can check what it is supposed to look like using SHOW on the console.
TACHYON V4
: KS0108.fth PRINT" KS0108 128x64 Graphic LCD " ;
$3FC == *lcd
$3F == lcdon
#P0 == *rs
#P1 == *lcdce
#P10 == *CS1
#P11 == *CS2
*CS1 MASK *CS2 MASK + == *BOTH
1,024 == lcdmemlen
$7C00 == lcdmem
--- Output a byte to the LCD as a character
pri LCDDAT ( ch -- )
*rs HIGH
pri WriteLCD ( data -- )
--- write data (set after clear)
*lcd OUTCLR 2* 2* OUTSET
--- min 450ns pulse chip enable
H H L
;
--- Output a byte to the LCD as an instruction
pri LCDCMD ( cmd -- )
*rs LOW WriteLCD
;
pub LCDCS ( address -- ) *BOTH OUTSET $40 AND IF *CS1 LOW ELSE *CS2 LOW THEN ;
pub LCDPAGE ( address -- ) *BOTH OUTCLR 7 >> $B8 OR LCDCMD ;
pub LCDADR ( address -- ) DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ;
--- transfer buffer to LCD
--- start from upper left corner and move down to bottom right and set ch
pub LCDBITBLT ( -- ) *lcdce PIN L *BOTH OUTCLR lcdon LCDCMD 0 lcdmemlen ADO I LCDADR *rs HIGH I lcdmem + 64 ADO I C@ WriteLCD LOOP 64 +LOOP ;
{
Optimize BitBlt by setting address once every 64 columns as the KS0108 6-bit "Y" address autoincrements
Also during writing 64 bytes of data skip having to set *rs HIGH, just select it at the start of the loop
Reduce write pulse to KS0108
( 0034 $2DB2 ok ) LAP LCDBITBLT LAP .LAP
847744 cycles at 96000000Hz or 8.830ms
}
ALIAS RUNMOD PLOT
word X
word Y
: !LCD
lcdmem lcdmemlen ERASE
lcdmem 4 COGREG! 4 3 COGREG! [PLOT]
X W~ Y W~
;
: VCR X W~ ;
: VLF Y W+! ;
--- Draw a Propeller font character on the graphics screen at X,Y
: LCDCH ( ch -- )
DUP 2/ 7 SHL $8000 + --- Calculate address of font character ( ch addr )
Y W@ #32 --- 32 lines
ADO DUP @ --- Next 16 pixels (2 sets)
3RD 1 AND IF 2/ THEN --- If it's an odd character then adjust font pixels
X W@ #16 --- 16 pixels/line
ADO DUP 1 AND --- Next pixel in font set?
IF I J PLOT THEN --- Plot each pixel
2/ 2/ --- shift to next pixel (every second one)
LOOP
DROP 4 + --- next long (line)
LOOP
2DROP 16 X W+! --- Advance X cursor 16 pixels to the right
X W@ 112 > IF VCR 32 VLF THEN --- but move to the next character line down if needed
;
: LCD ' LCDCH uemit W! ;
--- console render of graphics buffer
: SHOW
lcdmem lcdmemlen ADO
CR I 16 ADO I C@ 8 FOR DUP 1 AND IF '#' ELSE $20 THEN EMIT 2/ NEXT DROP LOOP
16 +LOOP
;
: DEMO !LCD 0 64 ADO I I PLOT LOOP LCD PRINT" HELLO WORLD" CON SHOW ;
END
@Proplem
the LCDBITLBT uses a 1 bit bitmap to send to the LCD.
why don't you start simple with a 1-bit memory bitmap.
If / when it works make it more complicated.
pub DRAWPIX ( x y 0/1 .. ) ...
locate the byte \
merge in the bit \ OR / ANDN ...
;
hi mjb, you are right. I could do this and reinvent all the work Peter has already done in less quality. Do you really recommend this and why?
All the high level drawing routines for line/box/circle/character ... are based on setting a single pixel in the bitmap.
So if you have this 'DRAWPIX' draw a single pixel routine all the rest can be reused.
Just substitute the existing pixel drawing routine.
This was based on the assumption you have the memory bitmap format and the CopyMemoryBitmapToLCD routine ready.
But Peter's suggestion to do the adaptation on the CopyMemoryBitmapToLCD side is absolutely right. Then the front end can stay as it is.
Both versions have their pros & cons.
Doing the adaption on writing might be simpler to do. (I have it ready in my head ..)
The complete LCD code the graphics driver ready to add those drawing routines to. The BitBlt needs to translate into the correct register address but at least you can check what it is supposed to look like using SHOW on the console.
...
[/code]
Hi @Peter,
in order to follow I had to switch to tachyon v4.
After downloading from your dropbox I tried to compile and got:
ln -sf "Tachyon V4.1.spin" tachyon.spin
iconv -f utf-16 -t utf-8 "tachyon.spin" > "tachyon.spin.utf-8"
/usr/local/bin/bstc.linux -b "tachyon.binary" "./tachyon.spin.utf-8" -Ox -DDEF80MHz
Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object tachyon
tachyon(2040,34) Error : Not a Long Address
jmp #SET
_________________________________^
tachyon - Error at (4666,15) Expected Spin Method, Unique Name, Assembly Conditional, BYTE, WORD, LONG or Assembly Instruction
byte 0[varram-(@romend+s)]
______________^
Compiled 3402 Lines of Code in 0.088 Seconds
( killall -qw minicom || true )
/usr/local/bin/bstl.linux -d /dev/ttyUSB0 -p 2 "./tachyon.binary"
Brads SpinTool Loader v0.05 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 09:34:58 on 2009/07/03
Found a USB Serial Device
Could not load Binary
Makefile:90: recipe for target 'tachyon.binary.dl' failed
make: *** [tachyon.binary.dl] Error 2
Probably the code is so new that you didn't save the current version to dropbox :-(
Downloading EXTENDv4.FTH does compile with errors and doesn't sometimes finish.
I can enter some commands but one time system freezes after loading KS0108.FTH and LCDBITBLT and there are obscurities pointing to erroneous baudrate settings.
Because I have automated the build process via Makefile it would ease up things to be able to switch the baudrate after the first build step, downloding the kernel.
CONBAUD should be part of the spin file - so one could play with it without having to change the source file.
I'm aware that setting the baudrate on kernel level wouldn't be possible if the communication isn't safe. But I wished it earlier and so I wanted to mention it here. Also it would ease up testing with different baudrates.
I would appreciate it really much.
Thanks for your time, best regards
proplem PS: Even hardware reset isn't working.
@proplem - not sure what your setup is there. I run Linux Mint 18 Cinnamon, minicom in a preferred xfce4 terminal, and line delay set to 5ms. Everything works very snappily.
CONBAUD can't be changed when running the precompiled kernel because that would require EEPROM access which is defined in EXTEND and although it could be written in a form that runs precompiled, it is easier to let Forth compile these extensions. Can't you just vary the default baud rate in the source?
btw - new line delay of 50ms is way over the top, as you see everything works fine with 5ms.
@Peter
Here a detailed problem report on Tachyon V4.1:
Still the same hw-config as mentioned before (LameStation), 115200 Baud.
I compiled like this:
make clean ttydev=/dev/ttyUSB1 nldly=30 base
which results in
rm -f ./*.binary.dl
( killall -qw minicom || true )
/usr/local/bin/bstl.linux -d /dev/ttyUSB1 -p 2 "./tachyon.binary"
Brads SpinTool Loader v0.05 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 09:34:58 on 2009/07/03
Found a USB Serial Device
Propeller Version 1 Found!
touch tachyon.binary.dl
make minicom
make[1]: Entering directory '/home/schmidt5/prj/tachyon/git/TF-P1'
sleep 1
gnome-terminal -e "minicom tachyon -b 115200 -D /dev/ttyUSB1 --color=on"
sleep 1
make[1]: Leaving directory '/home/schmidt5/prj/tachyon/git/TF-P1'
continue make? [y/n]: n
Exiting.
Makefile:93: recipe for target 'tachyon.binary.dl' failed
make: *** [tachyon.binary.dl] Error 1
This step compiled well. The error message is because I stopped continuation manually. After a hardware reset which always has to be done V4 comes up with:
Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
Cold start - no user code - setting defaults
--------------------------------------------------------------------------------
( 0001 $1900 ok ) TACHYON V4
Propeller .:.:--TACHYON--:.:. Forth V4.1 DAWN 410170214.0000
( 1562 $2DE0 ok )
This is fine so far. Hardware reset is ok. After every hardware reset the tachyon kernel comes up cleanly.
Now EXTEND.FTH (which is a renamed EXTEND-V4.FTH) has to be written:
make clean ttydev=/dev/ttyUSB1 nldly=100 EXTEND.FTH.dl
I used extra long nldelay and 115200 Baud.
This results in:
rm -f ./*.binary.dl
ascii-xfr -s -l 100 EXTEND.FTH > /dev/ttyUSB1
ASCII upload of "EXTEND.FTH"
Line delay: 100 ms, character delay 0 ms
In minicom/tachyon this happens:
End of source code, 0000 errors found Load time = 543921728 cycles at 80000000Hz
Code bytes used = 5344
CODE:$2DE0 =11232 bytes NAME:$5D82 =5758 bytes DATA:$76D4 =196 bytes =12194 byt)
( 1563 $2DE0 ok )
( 1564 $2DE0 ok )
( 1565 $2DE0 ok ) roms $1F00 $FF EFILL
( 1566 $2DE0 ok ) SAVEROMS
( 1567 $2DE0 ok ) ---
( 1568 $2DE0 ok ) 0 U@ DROP
( 1569 $2DE0 ok ) FORGET SAVEROMS
( 1570 $2D4E ok )
( 1571 $2D4E ok ) ?BACKUP
BACKUP /
( 1572 $2D4E ok ) AUTORUN BOOT
.STATS
CODE:$2D4E =11086 bytes NAME:$5D8E =5746 bytes DATA:$76D4 =196 bytes =12352 byt)
( 1573 $2D4E ok ) lsroms
NO ROMS
( 1574 $2D4E ok )
( 1575 $2D4E ok )
( 1576 $2D4E ok )
If I do hardware reset now tachyon v4 hangs completely. Even power off doesn't help any more.
@proplem - the only difference I can see is that your system doesn't have a 64kB EEPROM but that only means that there are "NO ROMS". However I will check this on a 32kB board if I can find one just to make sure that there are no new bugs. I did move console and pingnet parameters into a fixed area in the header area. The console baud rate is now stored as system ticks.
Check the youtube video I did of a V4 build in my previous post.
@Peter - started a build for IoT5500 with this 96 MHz device I didn't have problems to write EXTENDV4.FTH and hardware resetting afterwards. So it seems having to do with the hardware that writing EXTENDV4.FTH on LameStation (with propplug) hangs/fails.
Sorry that I'm such a source of work for you :-(
@proplem - I haven't tried this on a standard 32kB EEPROM system but I will try to do this soon. Any work that is enjoyable is hardly work, it's play, but we say it's work so we get paid
Are there any terminal emulators that we could set to look for the 'ok' (or other ?) response(s) when pasting code to Tachyon? Then we could turn the end-of-line delay down to zero and get faster compile times.
I suppose the easiest (?) way would be to implement X-on, X-off protocol in the Prop's serial driver.
Are there any terminal emulators that we could set to look for the 'ok' (or other ?) response(s) when pasting code to Tachyon? Then we could turn the end-of-line delay down to zero and get faster compile times.
I suppose the easiest (?) way would be to implement X-on, X-off protocol in the Prop's serial driver.
It seems pretty quiet around here ... no posts in almost two months! Has something happened that I'm yet aware of?
Just loaded Juno V3 onto a Proto Board. It seems to be the basic word set. Is there a particular EXTEND I should be using for Juno?
Thanks,
Michael
K6MLE
I think we are all too busy doing stuff with Tachyon to spend time chatting about it on the forum The forum seems to be mostly about those asking for help or about "P2 dreams"
(btw, however much I can "fly" in my dreams, if P2 was available in silicon then there is no need to dream and I would be right in the middle of the P2 feeding frenzy)
In answer to your question there is only one EXTEND.FTH in the V3 directory, just use that. I will have to load V3 onto a board and check all the files and maybe update the binaries folder as well although I may place a simple extended V3 binary into the V3 folder itself to make it easier to evaluate.
Now some ramblings....
The two most immediately practical threads I've seen lately are Heater's RISC-V and also the outworking of the SD card speed thread in respect not so much to working out what the OP was trying to say but in the response to the challenge. I did however find that whole compiler problem was amusing as I had a very simple copy&paste solution very early on that runs extremely fast without any optimization and without implementing multiple-block read modes either. The trouble was my easy solution was not in C.
What is the observation I make from this alone? That to most people being productive and effective is not as important as being orthodox, even if you are desperate for a solution and pulling your hair out. What does it mean for people who can and may prefer to code in Forth? Nothing of course, we can still write C or any other method if we have to but we are free to choose the best solution. Talking about the best solution in regards to hardware many of us on this forum favor the esoteric Parallax Propeller, a chip that the masses know little about or view with disdain as they compare benchmarks and "features". Yet we are free and empowered to use the Propeller or some other chip. Just the other day I used a tiny little XMC1100 for an encoder application written in Forth as this solution was the best for a one-off. I benefit because I haven't limited myself to any one solution. I see the general inability of the masses to grok Forth as a limitation in finding the best solution just as anyone who is limited to Arduino and unable to grok other architectures will be limited in finding the best solution and thereby pulling their hair out.
Just tried the load of EXTEND.FTH from the V3 directory and got an error at line 2224 "error in .TIMERS at RUNTIME @ 0 PRINTDEC *error*.
I for one, though I'm retired, would much rather program in FORTH and seek it out for the platform I'm compelled to use at a given time. I've always appreciated the assistance received by you and others on the forum, but also understand that most of you are working and not retired! Being patient is one of my virtues!
Just tried the load of EXTEND.FTH from the V3 directory and got an error at line 2224 "error in .TIMERS at RUNTIME @ 0 PRINTDEC *error*.
I for one, though I'm retired, would much rather program in FORTH and seek it out for the platform I'm compelled to use at a given time. I've always appreciated the assistance received by you and others on the forum, but also understand that most of you are working and not retired! Being patient is one of my virtues!
Hmm, that's strange, it seemed to load perfectly although I'm trying to upload a binary in the meantime. I set my line delay to 15ms in minicom but try increasing to 20ms. I guess you are using teraterm or minicom.
Hi Peter,
I am using Teraterm and have the line delay set to 25ms, per the readme.txt file in the V3 folder. I use the 'upload raw file' feature to sent it to the Propeller.
I tried both the paste text method and the [File} [Send file] command with binary ticked option and both worked fine. Which version of TeraTerm do you have that has an "upload raw file" feature?
I'm using Ubuntu and the GtkTerm program to communicate with the Prop. The data is being sent as ASCII, the only other choice being HEX. The Tachyon file I'm using is "Tachyon V3.0 JUNO.spin". There's also a "V3.0-S" file ... not sure how they differ. There's also a "V3.1 JUNO testing" file, which I imagine is not what I want. The EXTEND file says "160818-1400" on the 8th line. Have I got the correct files? It appears to me that I do. Barring a problem there, I'll give it another try and see what happens.
Is there any reason to stay with Tachyon-V3 over V4
after you spent so much time on V4 now?
Anything major still missing?
My recent little uses of V4 were all fine.
Well I still need to polish the hubcaps with such little things such as being able to backspace properly on interactive entry but otherwise I find that it all works very nicely. I can also compact the dictionary to EEPROM as regular dictionary entries although I'm still looking at improving the search time and also I must try adding vocabularies but none of these things are stopping me from using V4.3 with my commercial projects.
V4 has been able to utilize the cog memory better since it can now use wordcode to directly address cog or hub code and also encode literals and branches. Each Tachyon cog maintains its data stack in cog memory now so there is no need to allocate stack memory for each cog. Also V4 has proven itself in overall memory savings and speed, so yeah, if you don't mind a few quirks in the meantime then use V4.
Thanks!
I'll try minicom tomorrow and see how it flies.
I patched the minicom sources a while ago and pasted the dpkg here in this thread. That version saves the line delay in the settings.
I also created a makefile to ease up building. If you're interested I could post it.
@k6mle i figured out further tricks to send files from the linux command line.
Btw: nice to hear from all of you :-)
Comments
So the BitBlit routine actually has to do a bit more than just read from memory, it needs to translate that on the fly. A byte would normally represent 8 horizontal pixels for monochrome so we would actually need to read 8 bytes extracting the same bit from each to build up a byte that we could write as 8 vertical pixels. If we were simply drawing a font that was 8 pixels high there would not be any problem as the font table would be arranged as 5 bytes for each column for a 5x7 font.
Now if we assume we have a conventional monochrome pixel buffer where a byte is 8 horizontal pixels then we would need 16 bytes per line for 128 pixels by 64 lines, that's our 1,024 bytes. You can choose to address this buffer in two ways, either as a linear xy array and remap when you write to the LCD, or define the PLOT primitive to address the correct bit in the correct byte. But drawing is more important than writing to the display which can not handle a high frame update rate anyway, so I would choose a simple linear xy buffer and remap the pixels when I write to the LCD.
You can also write a very short routine that displays this buffer on your terminal screen, mapping a * for a pixel and a dot or space for none. That would be a quick way to confirm it is working too.
BTW, there is a PLOT module in V3 that you could use, just setup the buffer address and pixels/line as a binary shift of 7 bits for 128 pixels at 3 COGREG! and 4 COGREG! for the address.
This would draw a sloped line from top left to the bottom center.
' PLOT ( x y -- ) _PLOT shl tos,pixshift ' n^2 bytes/Y line mov X,tos+1 shr tos+1,#3 ' byte offset in line add tos,tos+1 ' byte offset in frame add tos,pixeladr ' byte address in memory and X,#7 ' get bit mask mov tos+1,#1 shl tos+1,X jmp #SETPLOT is a RUNMOD so you initially need to load it with [PLOT] and then either use RUNMOD to execute it or it may be more convenient to make an ALIAS of RUNMOD called PLOT
: SHOW lcdmem lcdmemlen ADO CR I 16 ADO I C@ 8 FOR DUP 1 AND IF '*' ELSE '.' THEN EMIT 2/ NEXT DROP LOOP 16 +LOOP ; ALIAS RUNMOD PLOT word X word Y : !LCD lcdmem lcdmemlen ERASE lcdmem 4 COGREG! 4 3 COGREG! [PLOT] X W~ Y W~ ; --- dummy CR & LF for test : VCR ; : VLF DROP ; --- Draw a Propeller font character on the graphics screen at X,Y : LCDCH ( ch -- ) DUP 2/ 7 SHL $8000 + --- Calculate address of font character ( ch addr ) Y W@ #32 --- 32 lines ADO DUP @ --- Next 16 pixels (2 sets) 3RD 1 AND IF 2/ THEN --- If it's an odd character then adjust font pixels X W@ #16 --- 16 pixels/line ADO DUP 1 AND --- Next pixel in font set? IF I J PLOT THEN --- Plot each pixel 2/ 2/ --- shift to next pixel (every second one) LOOP DROP 4 + --- next long (line) LOOP 2DROP 16 X W+! --- Advance X cursor 16 pixels to the right X W@ 120 > IF VCR #32 VLF THEN --- but move to the next character line down if needed ; : LCD ' LCDCH uemit W! ; : DEMO !LCD 0 64 ADO I I PLOT LOOP LCD PRINT" HELLO" CON SHOW ;Running it on the console
TACHYON V4 : KS0108.fth PRINT" KS0108 128x64 Graphic LCD " ; $3FC == *lcd $3F == lcdon #P0 == *rs #P1 == *lcdce #P10 == *CS1 #P11 == *CS2 *CS1 MASK *CS2 MASK + == *BOTH 1,024 == lcdmemlen $7C00 == lcdmem --- Output a byte to the LCD as a character pri LCDDAT ( ch -- ) *rs HIGH pri WriteLCD ( data -- ) --- write data (set after clear) *lcd OUTCLR 2* 2* OUTSET --- min 450ns pulse chip enable H H L ; --- Output a byte to the LCD as an instruction pri LCDCMD ( cmd -- ) *rs LOW WriteLCD ; pub LCDCS ( address -- ) *BOTH OUTSET $40 AND IF *CS1 LOW ELSE *CS2 LOW THEN ; pub LCDPAGE ( address -- ) *BOTH OUTCLR 7 >> $B8 OR LCDCMD ; pub LCDADR ( address -- ) DUP LCDPAGE DUP LCDCS $3F AND $40 OR LCDCMD ; --- transfer buffer to LCD --- start from upper left corner and move down to bottom right and set ch pub LCDBITBLT ( -- ) *lcdce PIN L *BOTH OUTCLR lcdon LCDCMD 0 lcdmemlen ADO I LCDADR *rs HIGH I lcdmem + 64 ADO I C@ WriteLCD LOOP 64 +LOOP ; { Optimize BitBlt by setting address once every 64 columns as the KS0108 6-bit "Y" address autoincrements Also during writing 64 bytes of data skip having to set *rs HIGH, just select it at the start of the loop Reduce write pulse to KS0108 ( 0034 $2DB2 ok ) LAP LCDBITBLT LAP .LAP 847744 cycles at 96000000Hz or 8.830ms } ALIAS RUNMOD PLOT word X word Y : !LCD lcdmem lcdmemlen ERASE lcdmem 4 COGREG! 4 3 COGREG! [PLOT] X W~ Y W~ ; : VCR X W~ ; : VLF Y W+! ; --- Draw a Propeller font character on the graphics screen at X,Y : LCDCH ( ch -- ) DUP 2/ 7 SHL $8000 + --- Calculate address of font character ( ch addr ) Y W@ #32 --- 32 lines ADO DUP @ --- Next 16 pixels (2 sets) 3RD 1 AND IF 2/ THEN --- If it's an odd character then adjust font pixels X W@ #16 --- 16 pixels/line ADO DUP 1 AND --- Next pixel in font set? IF I J PLOT THEN --- Plot each pixel 2/ 2/ --- shift to next pixel (every second one) LOOP DROP 4 + --- next long (line) LOOP 2DROP 16 X W+! --- Advance X cursor 16 pixels to the right X W@ 112 > IF VCR 32 VLF THEN --- but move to the next character line down if needed ; : LCD ' LCDCH uemit W! ; --- console render of graphics buffer : SHOW lcdmem lcdmemlen ADO CR I 16 ADO I C@ 8 FOR DUP 1 AND IF '#' ELSE $20 THEN EMIT 2/ NEXT DROP LOOP 16 +LOOP ; : DEMO !LCD 0 64 ADO I I PLOT LOOP LCD PRINT" HELLO WORLD" CON SHOW ; ENDAll the high level drawing routines for line/box/circle/character ... are based on setting a single pixel in the bitmap.
So if you have this 'DRAWPIX' draw a single pixel routine all the rest can be reused.
Just substitute the existing pixel drawing routine.
This was based on the assumption you have the memory bitmap format and the CopyMemoryBitmapToLCD routine ready.
But Peter's suggestion to do the adaptation on the CopyMemoryBitmapToLCD side is absolutely right. Then the front end can stay as it is.
Both versions have their pros & cons.
Doing the adaption on writing might be simpler to do. (I have it ready in my head ..)
Hi @Peter,
in order to follow I had to switch to tachyon v4.
After downloading from your dropbox I tried to compile and got:
ln -sf "Tachyon V4.1.spin" tachyon.spin iconv -f utf-16 -t utf-8 "tachyon.spin" > "tachyon.spin.utf-8" /usr/local/bin/bstc.linux -b "tachyon.binary" "./tachyon.spin.utf-8" -Ox -DDEF80MHz Found a USB Serial Device Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved Compiled for i386 Linux at 08:17:46 on 2009/07/20 Loading Object tachyon tachyon(2040,34) Error : Not a Long Address jmp #SET _________________________________^ tachyon - Error at (4666,15) Expected Spin Method, Unique Name, Assembly Conditional, BYTE, WORD, LONG or Assembly Instruction byte 0[varram-(@romend+s)] ______________^ Compiled 3402 Lines of Code in 0.088 Seconds ( killall -qw minicom || true ) /usr/local/bin/bstl.linux -d /dev/ttyUSB0 -p 2 "./tachyon.binary" Brads SpinTool Loader v0.05 - Copyright 2008,2009 All rights reserved Compiled for i386 Linux at 09:34:58 on 2009/07/03 Found a USB Serial Device Could not load Binary Makefile:90: recipe for target 'tachyon.binary.dl' failed make: *** [tachyon.binary.dl] Error 2Probably the code is so new that you didn't save the current version to dropbox :-(@Peter - thank you very much 6:20 in the morning, v4 up and running.
At KS0108.FTH: SHOW works, display not yet, have to investigate what fails.
Thank you very much!
BTW: cause I use git locally I can now switch between branches v3 and v4 easily.
I have some trouble with my setup running v4:
- lamestation
- 80 MHz
- Baudrate 921600 (default)
- nldelay 50 ms
Downloading EXTENDv4.FTH does compile with errors and doesn't sometimes finish.
I can enter some commands but one time system freezes after loading KS0108.FTH and LCDBITBLT and there are obscurities pointing to erroneous baudrate settings.
Because I have automated the build process via Makefile it would ease up things to be able to switch the baudrate after the first build step, downloding the kernel.
CONBAUD should be part of the spin file - so one could play with it without having to change the source file.
I'm aware that setting the baudrate on kernel level wouldn't be possible if the communication isn't safe. But I wished it earlier and so I wanted to mention it here. Also it would ease up testing with different baudrates.
I would appreciate it really much.
Thanks for your time, best regards
proplem
PS: Even hardware reset isn't working.
CONBAUD can't be changed when running the precompiled kernel because that would require EEPROM access which is defined in EXTEND and although it could be written in a form that runs precompiled, it is easier to let Forth compile these extensions. Can't you just vary the default baud rate in the source?
btw - new line delay of 50ms is way over the top, as you see everything works fine with 5ms.
Here a detailed problem report on Tachyon V4.1:
Still the same hw-config as mentioned before (LameStation), 115200 Baud.
I compiled like this: which results in This step compiled well. The error message is because I stopped continuation manually. After a hardware reset which always has to be done V4 comes up with: This is fine so far. Hardware reset is ok. After every hardware reset the tachyon kernel comes up cleanly.
Now EXTEND.FTH (which is a renamed EXTEND-V4.FTH) has to be written: I used extra long nldelay and 115200 Baud.
This results in:
In minicom/tachyon this happens:
If I do hardware reset now tachyon v4 hangs completely. Even power off doesn't help any more.
Check the youtube video I did of a V4 build in my previous post.
Sorry that I'm such a source of work for you :-(
I suppose the easiest (?) way would be to implement X-on, X-off protocol in the Prop's serial driver.
@ceptimus - I think also it would be a great improvement to have control flow and so I searched the thread about the string "XON" and found at least:
http://forums.parallax.com/discussion/comment/1114281/#Comment_1114281
http://forums.parallax.com/discussion/comment/1119585/#Comment_1119585
http://forums.parallax.com/discussion/comment/1124323/#Comment_1124323
http://forums.parallax.com/discussion/comment/1282018/#Comment_1282018
http://forums.parallax.com/discussion/comment/1282062/#Comment_1282062
http://forums.parallax.com/discussion/comment/1331956/#Comment_1331956
http://forums.parallax.com/discussion/comment/1331983/#Comment_1331983
http://forums.parallax.com/discussion/comment/1332061/#Comment_1332061
http://forums.parallax.com/discussion/comment/1332063/#Comment_1332063
I thought it would be helpful to find this collected.
Best regards, proplem
It seems pretty quiet around here ... no posts in almost two months! Has something happened that I'm yet aware of?
Just loaded Juno V3 onto a Proto Board. It seems to be the basic word set. Is there a particular EXTEND I should be using for Juno?
Thanks,
Michael
K6MLE
I think we are all too busy doing stuff with Tachyon to spend time chatting about it on the forum
(btw, however much I can "fly" in my dreams, if P2 was available in silicon then there is no need to dream and I would be right in the middle of the P2 feeding frenzy)
In answer to your question there is only one EXTEND.FTH in the V3 directory, just use that. I will have to load V3 onto a board and check all the files and maybe update the binaries folder as well although I may place a simple extended V3 binary into the V3 folder itself to make it easier to evaluate.
Now some ramblings....
The two most immediately practical threads I've seen lately are Heater's RISC-V and also the outworking of the SD card speed thread in respect not so much to working out what the OP was trying to say but in the response to the challenge. I did however find that whole compiler problem was amusing as I had a very simple copy&paste solution very early on that runs extremely fast without any optimization and without implementing multiple-block read modes either. The trouble was my easy solution was not in C.
What is the observation I make from this alone? That to most people being productive and effective is not as important as being orthodox, even if you are desperate for a solution and pulling your hair out. What does it mean for people who can and may prefer to code in Forth? Nothing of course, we can still write C or any other method if we have to but we are free to choose the best solution. Talking about the best solution in regards to hardware many of us on this forum favor the esoteric Parallax Propeller, a chip that the masses know little about or view with disdain as they compare benchmarks and "features". Yet we are free and empowered to use the Propeller or some other chip. Just the other day I used a tiny little XMC1100 for an encoder application written in Forth as this solution was the best for a one-off. I benefit because I haven't limited myself to any one solution. I see the general inability of the masses to grok Forth as a limitation in finding the best solution just as anyone who is limited to Arduino and unable to grok other architectures will be limited in finding the best solution and thereby pulling their hair out.
Just tried the load of EXTEND.FTH from the V3 directory and got an error at line 2224 "error in .TIMERS at RUNTIME @ 0 PRINTDEC *error*.
I for one, though I'm retired, would much rather program in FORTH and seek it out for the platform I'm compelled to use at a given time. I've always appreciated the assistance received by you and others on the forum, but also understand that most of you are working and not retired! Being patient is one of my virtues!
Hmm, that's strange, it seemed to load perfectly although I'm trying to upload a binary in the meantime. I set my line delay to 15ms in minicom but try increasing to 20ms. I guess you are using teraterm or minicom.
I am using Teraterm and have the line delay set to 25ms, per the readme.txt file in the V3 folder. I use the 'upload raw file' feature to sent it to the Propeller.
This is with 25ms line delay and no char delay.
If you're using Linux, do you suggest a different comm program?
Thanks!
I'll try minicom tomorrow and see how it flies.
just wondering you do not recommend to use V4.
Is there any reason to stay with Tachyon-V3 over V4
after you spent so much time on V4 now?
Anything major still missing?
My recent little uses of V4 were all fine.
Well I still need to polish the hubcaps with such little things such as being able to backspace properly on interactive entry but otherwise I find that it all works very nicely. I can also compact the dictionary to EEPROM as regular dictionary entries although I'm still looking at improving the search time and also I must try adding vocabularies but none of these things are stopping me from using V4.3 with my commercial projects.
V4 has been able to utilize the cog memory better since it can now use wordcode to directly address cog or hub code and also encode literals and branches. Each Tachyon cog maintains its data stack in cog memory now so there is no need to allocate stack memory for each cog. Also V4 has proven itself in overall memory savings and speed, so yeah, if you don't mind a few quirks in the meantime then use V4.
I also created a makefile to ease up building. If you're interested I could post it.
@k6mle i figured out further tricks to send files from the linux command line.
Btw: nice to hear from all of you :-)
you commented out ERASE$ in (V3) EXTEND.FTH
pub ERASE$ ( str -- \ Fully erase the string - reads max len from header ) DUP 3 - C@ ERASE ;Is something wrong with it?