The SD card speed thread spurred me on to check my SD driver routines in V4 and since it has a bit more room in the kernel cog I've made a couple of adjustments to it and I am now getting sector read times of 1ms, that's over 500kB/sec. There are some other overheads I am trimming before I start testing multiblock mode for fast back to back sector reads which should result in around 1MB/sec read speeds without using a dedicated cog.
I've overlapped the traces in this capture to keep the view tight. Yellow is clock, blue is CS, magenta is MOSI to card and cyan is MISO data from card.
Latest SD card sector read takes 833us, that's around 615k bytes/sec. The latency from a read sector command until the data is ready is the biggest holdup here at around 150us. The data is being read at half the instruction clock rate, or 12MHz and takes just over 500us to read.
I'm quite impressed peter Just to be clear, since you say "half the instruction rate, or 12 MHz", does that mean you're running overclock, and we'd therefore see a slight decrease in performance on 80 MHz systems?
Hello Peter, I found your conversation with Proplem concerning KS0108 and yes, mapping the linear buffer to the display is a way to go, more simple than changing PLOT etc. Anyway 0 0 PLOT sets the first pixel, how do I reset it and is there a way to xor a bit? I do not feel able to change the PLOT RUNMOD routine ;-)
I'm quite impressed peter Just to be clear, since you say "half the instruction rate, or 12 MHz", does that mean you're running overclock, and we'd therefore see a slight decrease in performance on 80 MHz systems?
Thanks David, these tests are running on a board at 96MHz using the PHSx method for reading the data which we can set to half the instruction rate so that a pair of test/rcl instructions can "clock" and read as fast as possible. I know this method has been used in other SD card drivers but those ones dedicated a cog for the PASM part whereas I had to squeeze my code into the Tachyon cog. Now with V4 I have more room in the cog due to the flexibility of the 16-bit wordcodes so I have been able to allow more room for RUNMODs, up to 23 longs in fact which is just enough room for a fast SDRD routine to read the data.
Running on a 80MHz system would normally take 20% longer but the 150us or latency is fixed so overall probably closer to or just under 1ms @80MHz. Many of my systems use a tiny 6MHz oscillator these days so that's the stuff I normally test on.
BTW, I might be able to speed up the command/response phase a little but I'd be doing well to trim another 100us and I doubt I would be able to do much better than 700us due to the latency plus clocking speed.
Latest SD card sector read takes 833us, that's around 615k bytes/sec. The latency from a read sector command until the data is ready is the biggest holdup here at around 150us. The data is being read at half the instruction clock rate, or 12MHz and takes just over 500us to read.
Nice numbers.
How does this vary with brand and age, and do 'tired old' SDs do worse here ?
Hello Peter, I found your conversation with Proplem concerning KS0108 and yes, mapping the linear buffer to the display is a way to go, more simple than changing PLOT etc. Anyway 0 0 PLOT sets the first pixel, how do I reset it and is there a way to xor a bit? I do not feel able to change the PLOT RUNMOD routine ;-)
There's no need to use a PLOT RUNMOD while testing so you are free to handle it any which way. A plot routine can run faster and draw lines over lines and text if it only sets bits so this is the reason for the default but of course we can add features to an "EPLOT" RUNMOD but that would also run slower too, plus it would still have to fit within 23 longs. I've found it is easier to clear all or part of the buffer before drawing, hence the optimized PLOT.
BTW, this LCD driver should be very simple, or should I say, it should end up being very simple. I know this is a learning experience but if it is too frustrating please just let me know as I'm sure I could whip up one to suit the Lamestation in which case it is still a good learning experience
Latest SD card sector read takes 833us, that's around 615k bytes/sec. The latency from a read sector command until the data is ready is the biggest holdup here at around 150us. The data is being read at half the instruction clock rate, or 12MHz and takes just over 500us to read.
Nice numbers.
How does this vary with brand and age, and do 'tired old' SDs do worse here ?
That's right about "tired old" SDs but also Flash in general including the Flash memory in phones and tablets. Everybody complains how their zippy device is not so zippy anymore but very rarely do you hear about wear leveling and "TRIM". However the truth is that even then they try to compensate for Flash wear but latency creeps in with wear. Oh if only we have something better than Flash that didn't wear out or imagine if we could replace the internal eMMC chip, then your 2014 device would be zippy again! I doubt the manufacturers would like that!
Anyhow, these cards are new 8GB Sandisk Ultra micro SDHC so they are fairly typical of a card we would use in an embedded system. But FAT32/16 is not at all that friendly to Flash as it crams all the directories together and if the file size and FAT were continually updated on a log file it would lead to premature wear. Hence the reason I don't update them like that for log files either plus I like to preallocate memory so that there is no need to tamper with the FAT. However I have never found any files fragmented when SD cards are used on the PC despite the warnings I hear since my virtual memory layer treats the card and each file as contiguous sectors rather than traversing the FAT. Besides I have routines that check for fragmentation just in case, but I haven't found one yet unless I perhaps threw hundreds of files onto a card including PC system files and left that thrashing and trashing long enough.
To answer you question though I will try to dig up some old cards and try them out.
Hello Peter, I found your conversation with Proplem concerning KS0108 and yes, mapping the linear buffer to the display is a way to go, more simple than changing PLOT etc. Anyway 0 0 PLOT sets the first pixel, how do I reset it and is there a way to xor a bit? I do not feel able to change the PLOT RUNMOD routine ;-)
I think (as I wrote in the other thread ?) it is simpler to change the PLOT word (not RUNMOD) to write into a buffer set up to suit the KS0108 display. Plot only has to handle a single bit. So this requires just a little bit of address arithmetic.
Converting standard buffer which is organized in rows into columns as required by the display needs reading 8 bytes and doing a transpose.
Easier to set up a transposed buffer so the copying of buffer to display get's really straight forward .. and much faster.
All higher level plotting commands just go via a single bit PLOT.
Just redo this.
AFAIK currently there is no REVECTOR so this new PLOT needs to b loaded before the higher level plot code which will use it.
@ErNA @MJB - PLOT is just the name of a function, one that can be written any which way or called something else. If the primitive graphics LCD in question could benefit from a fast refresh rate then it would be wise to make PLOT do all the work finding the pixel. But since the LCD is very slow there just isn't any point in trying to run it too fast although you may get a half-tone of sorts through frame rate modulation at a higher frame rate. This LCD is very cheap and nasty so that sadly the "Lame" in Lamestation has its more mundane rather than geeky connotation. There are so many cheap TFT displays that offer a whole world of color and shades that I would use instead but perhaps back when it was designed this was not so. However, I would rather spend time on a new design that does much the same thing if that were so.
.... Oh if only we have something better than Flash that didn't wear out or imagine if we could replace the internal eMMC chip, then your 2014 device would be zippy again!
I have been using SanDisk "Ultra" 8GB microSDHC but for a change I tried an older plain black SanDisk 4GB. Wow, what a difference! I have latencies >1ms which slows down the sector read to 1.8ms.
Images for slow SandDisk vs "Ultra" where the latency is around 150us. The area between the AB cursors in the first image is the constant polling of the SD card data line waiting for a "data token" to indicate that the data is ready to be read as you can see the data in the cyan trace.
@ErNA @MJB - PLOT is just the name of a function, one that can be written any which way or called something else. If the primitive graphics LCD in question could benefit from a fast refresh rate then it would be wise to make PLOT do all the work finding the pixel. But since the LCD is very slow there just isn't any point in trying to run it too fast although you may get a half-tone of sorts through frame rate modulation at a higher frame rate. This LCD is very cheap and nasty so that sadly the "Lame" in Lamestation has its more mundane rather than geeky connotation. There are so many cheap TFT displays that offer a whole world of color and shades that I would use instead but perhaps back when it was designed this was not so. However, I would rather spend time on a new design that does much the same thing if that were so.
As MJB says in regards to PLOT, "just redo this".
I adapted @Peter's QVGA-LCD driver for a ILI9341_QVGA a while ago to show an Arduino user how easy it is with Tachyon. Those color displays do not require a buffer, you can just draw directly an save the memory.
But you can just have fun with the Lamestation and learn on the way ;-)
Maybe as a stretch goal - implement it in both ways and run some comparisons - could be interresting.
The dictionary can take up to 10k of hub RAM and in V3 I had a COMPACT method that moved the dictionary into EEPROM into "blocks" but which block depended upon a 6-bit hash index. This worked well as it also allowed for a normal hub dictionary with a cached entry at the end of it but was also a bit more complicated than I wanted and also took up a bit of upper EEPROM. There was always the possibility that a block could run out of room although that never happened with the hashing I used. Still, it meant that if a word wasn't found in hub RAM including the cache then the target block of 192 byte would be read in from EEPROM and the entry extracted from there into the cache.
For V4 I intended to have a sorted list in EEPROM with fixed 16-byte entries so that a binary search could find a match quickly. However I thought about it and building and maintaining a sorted list is a bit of a pain. Now I think I have hit on a very good solution, a minimum of fuss and very fast and compact. On compacting or archiving eligible entries to EEPROM they will be moved complete up to 16 bytes without sorting and in the same order they were created. But this would be too slow to search in EEPROM, very slow in fact. So I create an additional hash byte dictionary array comprised of a single hashed byte whose byte index in this array corresponds with the 16 byte entry in EEPROM. So a hash byte would be generated from search string and then we compare this byte with any matches in the hash byte dictionary array. If we find a match we then start comparing the counted strings in hub RAM and EEPROM. As soon as the byte by byte compare fails it will continue searching the hash dictionary until a hash byte match and string match. The EEPROM compare would use sequential byte read to begin a string compare rather than reissuing EEPROM address for each read.
DICTIONARY ENTRY "DUP"
03 44 55 50 80 00 31 00
In EEPROM becomes:
03 44 55 50 00 00 00 00 00 00 00 00 80 00 31 00
with a hash byte in the same order left in hub RAM hash-byte dictionary.
Now when the dictionary is being searched it should be even faster than the complete dictionary in hub RAM since only a single byte is being compared per entry and it simply advances to the next location etc. So a 1,000 entry dictionary will only occupy less than 1k of hub RAM and will be very fast to search. Now that it's so simple I will get it working very quickly.
The dictionary can take up to 10k of hub RAM and in V3 I had a COMPACT method that moved the dictionary into EEPROM into "blocks" but which block depended upon a 6-bit hash index. This worked well as it also allowed for a normal hub dictionary with a cached entry at the end of it but was also a bit more complicated than I wanted and also took up a bit of upper EEPROM. There was always the possibility that a block could run out of room although that never happened with the hashing I used. Still, it meant that if a word wasn't found in hub RAM including the cache then the target block of 192 byte would be read in from EEPROM and the entry extracted from there into the cache.
For V4 I intended to have a sorted list in EEPROM with fixed 16-byte entries so that a binary search could find a match quickly. However I thought about it and building and maintaining a sorted list is a bit of a pain. Now I think I have hit on a very good solution, a minimum of fuss and very fast and compact. On compacting or archiving eligible entries to EEPROM they will be moved complete up to 16 bytes without sorting and in the same order they were created. But this would be too slow to search in EEPROM, very slow in fact. So I create an additional hash byte dictionary array comprised of a single hashed byte whose byte index in this array corresponds with the 16 byte entry in EEPROM. So a hash byte would be generated from search string and then we compare this byte with any matches in the hash byte dictionary array. If we find a match we then start comparing the counted strings in hub RAM and EEPROM. As soon as the byte by byte compare fails it will continue searching the hash dictionary until a hash byte match and string match. The EEPROM compare would use sequential byte read to begin a string compare rather than reissuing EEPROM address for each read.
DICTIONARY ENTRY "DUP"
03 44 55 50 80 00 31 00
In EEPROM becomes:
03 44 55 50 00 00 00 00 00 00 00 00 80 00 31 00
with a hash byte in the same order left in hub RAM hash-byte dictionary.
Now when the dictionary is being searched it should be even faster than the complete dictionary in hub RAM since only a single byte is being compared per entry and it simply advances to the next location etc. So a 1,000 entry dictionary will only occupy less than 1k of hub RAM and will be very fast to search. Now that it's so simple I will get it working very quickly.
will this still work on 32k EEPROM systems?
While sure 64k EEPROM is preferable, there are still a lot of 32k boards around.
@MJB - anyone with a 32k EEPROM system that doesn't know how to swap in a new chip will just have to make do with the standard Tachyon without ROMS and standard dictionary in RAM. Such a system wouldn't be used for a full install anyway which is what the new EEPROM method is for, much the same as we used COMPACT in V3 only when we were squeezing in file system and network servers.
The new method has been changed slightly, the EEPROM entries look exactly like they did in RAM except of course each entry is indexed on 16 byte boundaries.
That method of having a table of hash bytes index into the EEPROM seems to work well. I've loaded EASYFILE then COMPACTed the dictionary, then loaded EASYNET and if I compact that again I would have around 8kB free. The COMPACTing and EEPROM searching code takes up around 350 bytes itself and there is 1kB reserved for the hash byte table but other than another 32 bytes or so for buffers there isn't any other memory required by this method. I need to add methods for appending and listing too. The old V3 block method took over 24kB of EEPROM but the V4 method is much simpler and maintains the order that they were created in as well as well as supporting vocabularies etc.
Here EASYNET has just been loaded on top of a compacted dictionary. Name space used with EASYNET words is 3510 while free space is 4384, so after further compacting that should make around 8kB available.
@MJB - anyone with a 32k EEPROM system that doesn't know how to swap in a new chip will just have to make do with the standard Tachyon without ROMS and standard dictionary in RAM. Such a system wouldn't be used for a full install anyway which is what the new EEPROM method is for, much the same as we used COMPACT in V3 only when we were squeezing in file system and network servers.
that's fine. Not always a full system with SD/Filesystem etc. is needed.
Just wanted to make sure we need not fall back to V3 for 32k boards.
thanks
Hi there,
i'm still alive and eager. I wrote - oh man how time is running - six years ago a propeller (spin) mode for emacs and posted it in the forum. Recently I took the sources and patched them a bit for tachyon and now I have a really fine customizable development environment for tachyon.
With 600 lines I have syntax highlighting, sending a buffer with line delay out of the emacs buffer to a tachyon device - seeing reaction in minicom this is really cool.
I know with the highlighting settings I overshoot a bit. It's very colory but I coudn't resist - will tame it again when I know how to use the power.
This is the first picture of my own graphics driver on the lamestation with tachyon. Hoooray.
Thanks to all (especially @Peter) who helped me doing this!!!
@proplem - great news indeed! Love to see some games written for it, maybe a simple pong first off?
I use medit with custom syntax highlighting and minicom is just set to 5ms line delay but of course I am still using the old copy text and paste into minicom method.
I've been working on the wireless interface to Tachyon via the ESP8266 boards. Can you explain or clear up the RX/TX from the tachyon console port. How are the responses terminated i.e. .words is much different that qwords Any tips.
And is tachyon expecting a CRLF pair for the console entries?
I've been working on the wireless interface to Tachyon via the ESP8266 boards. Can you explain or clear up the RX/TX from the tachyon console port. How are the responses terminated i.e. .words is much different that qwords Any tips.
And is tachyon expecting a CRLF pair for the console entries?
Differences in V3/V4 regarding the console port?
dp
I was trying to compile EASYNET the other day to run it which is why I have added a suitable EEPROM method and only started to play with networking in V4 just a couple of days ago. But it didn't work and one of the reasons was the way that the console interface is used by FTP and HTTP in that it needs to be QUIET, not prompting, not echoing, and certainly not printing line numbers etc. So I've updated my internal 4.2b which also includes RECLAIM to strip out all the private headers. Now have a look at the QUIET mode word taken from the updated EASYNET.
pub QUIET
IF
OFF ECHO ' NOOP prompt W! --- Non-interactive mode - just accept "commands"
ELSE
ON ECHO prompt W~
THEN
;
So the main thing is to turn off echo and disable PROMPT via its control vector "prompt" with a high level "no operation" NOOP. I may take a look at the ESP interface myself although I am rather busy building a multi-channel portable power analyzer at present.
Okay, more things to try. I'm using websockets to support the web console via javascript and now we have found some ESP docs that allude to the interrupts (async serial) being disabled during a websocket call. Well the docs also say be patient and wait for the next release of the RTOS that will make this all better! I've heard this story before, I'm just trying to offload the UI stuff to ESP so we can use tablets/phones/laptops with javascript/html5/jquery to build out the user experience.
I was trying to compile EASYNET the other day to run it which is why I have added a suitable EEPROM method and only started to play with networking in V4 just a couple of days ago. But it didn't work and one of the reasons was the way that the console interface is used by FTP and HTTP in that it needs to be QUIET, not prompting, not echoing, and certainly not printing line numbers etc. So I've updated my internal 4.2b which also includes RECLAIM to strip out all the private headers. Now have a look at the QUIET mode word taken from the updated EASYNET.
pub QUIET
IF
OFF ECHO ' NOOP prompt W! --- Non-interactive mode - just accept "commands"
ELSE
ON ECHO prompt W~
THEN
;
So the main thing is to turn off echo and disable PROMPT via its control vector "prompt" with a high level "no operation" NOOP. I may take a look at the ESP interface myself although I am rather busy building a multi-channel portable power analyzer at present.
Okay QUIET helped but still not 100%, must be the interrupts in the ESP getting blocked by websockets, so close for a stand alone dev system, just need a browser (ha stand alone). I'll try UDP sockets and ditch the websockets if I can't figure this interrupt issue out.
Thanks Peter
UPDATE: Fixed. Found the 200ms timeout in the current websocket library causing missed async serial RX from the prop. Switched to the async websocket and web server implementations. Almost done now
@Peter+Jakacki,
it seems you are busy with v4.3. There have been many changes in the kernel.
As far as I tried v43 isn't yet ready for release on iot5500. Am I right?
Best regards,
proplem
@Peter+Jakacki,
it seems you are busy with v4.3. There have been many changes in the kernel.
As far as I tried v43 isn't yet ready for release on iot5500. Am I right?
Best regards,
proplem
I'm just checking through fixes and optimizations I have done to EASYFILE V4r3 which include virtual file memory handlers. There were some problems with EASYNET on 4.3 so I will be checking that again next.
I'm just checking through fixes and optimizations I have done to EASYFILE V4r3 which include virtual file memory handlers. There were some problems with EASYNET on 4.3 so I will be checking that again next.
Fine I reanimated V3 Juno and thanks git it's working properly. So there is no need to hurry.
@Peter Jakacki,
thank your for the effort with v4.3 and iot5500.
I tried to create for iot5500 with V4.3 and there's still a hopefully small problem with EASYFILE-V4r3.FTH. The build output follows:
Propeller .:.:--TACHYON--:.:. Forth V4.3 DAWN 430170415.0000
Cold start - no user code - setting defaults
--------------------------------------------------------------------------------
( 0001 $1A40 ok ) TACHYON V4
Propeller .:.:--TACHYON--:.:. Forth V4.3 DAWN 430170415.0000
( 1652 $2F90 ok ) OPY ROMS from $24F0 for 3,196
End of source code, 0000 errors found Load time = 1771174256 cycles at 96MHz = 18c
Code bytes used = 5456
CODE:$2F90 =11664 bytes NAME:$5CA6 =5978 bytes DATA:$76D4 =196 bytes =11542 by)
( 1653 $2F90 ok )
( 1654 $2F90 ok ) AUTORUN BOOT
?BACKUP
BACKUP |
( 1655 $2F90 ok )
( 1656 $2F90 ok ) .STATS
CODE:$2F90 =11664 bytes NAME:$5CA6 =5978 bytes DATA:$76D4 =196 bytes =11542 by)
( 1657 $2F90 ok ) lsroms
*** ROMS ***
0,848 VGA32x15
0,388 HSUART
1,900 F32
0,196 MONO16
1,900 F32
( 1658 $2F90 ok )
( 1659 $2F90 ok )
( 1660 $2F90 ok ) TACHYON V4
Propeller .:.:--TACHYON--:.:. Forth V4.3 DAWN 430170415.0000
( 1560 $3E3E ++ ) ??? in ?AUTOLOAD at (LOADROM)
( 1672 $3F0E ok )
End of source code, 0001 errors found Load time = 1669724160 cycles at 96MHz = 17c
Code bytes used = 3966
CODE:$3F0E =15630 bytes NAME:$5486 =8058 bytes DATA:$7921 =785 bytes =5496 byt)
Can you give an additional tip to your naming convention ...v4r2, V4T, V4S etc.?
Thank you very much, best regards
proplem
@proplem - I've been using those files without any problems but since V4 started off as a testing version it developed lots of different but temporary sub-versions which I hadn't cleaned up. So now I've moved all the earlier stuff into sub-folders and kept the main stuff in the root V4 folder. The suffixes are just test variations so for now I only have anything compatible with V4r3 in the main folder although I may end up removing the version number from the file name just as I did with V3.
btw, I'm using minicom with a 5ms line delay @921600 baud but once I COMPACT before loading EASYNET I need to set it to 50ms at present since the EEPROM search can be a little slow. This I hope to improve as much as possible but neither do I want to complicate this simple scheme. Besides, I FLOAD EASYNET from the SD card mostly anyway but I think it would be nice if I could download a text file normally but have it saved to a temporary (or not) file so that it could perform an automatic FLOAD from there. That way the line delay could even be set to zero.
I'm also exploring how I might implement a practical screen editor that uses the SD card and ANSI terminal as a screen. Not having large amounts of RAM precludes the luxury of manipulating it that easily and while I can use virtual memory it needs to hold off updating the file too frequently as in the case of inserting characters. Maybe at the end of a line will do. I can see why the early Forth systems organized everything in 1k blocks as you didn't have to worry about anything more than that. Perhaps I could do something similar except I don't need to deal with horrible block numbers, I would just use the file system and have it insert "virtual blocks" although the file would still be a standard text file albeit with trailing "blanks" for each line to suit. I would probably make those blocks so that there wasn't any implied "new line" unless a CR was encountered so the trailing blanks would have to be a neutral character too as I would still want to be able to handle these files over FTP.
Anyway, a screen editor using the SD card and ANSI terminal should be very fast and smooth to use plus I could always dedicate another Prop over a single-wire PPNET as the terminal with hires 128x50 text and PS/2 keyboard or joy of joys, a USB keyboard finally (although I would just use a Logitech Unifying receiver).
Comments
I've overlapped the traces in this capture to keep the view tight. Yellow is clock, blue is CS, magenta is MOSI to card and cyan is MISO data from card.
Thanks David, these tests are running on a board at 96MHz using the PHSx method for reading the data which we can set to half the instruction rate so that a pair of test/rcl instructions can "clock" and read as fast as possible. I know this method has been used in other SD card drivers but those ones dedicated a cog for the PASM part whereas I had to squeeze my code into the Tachyon cog. Now with V4 I have more room in the cog due to the flexibility of the 16-bit wordcodes so I have been able to allow more room for RUNMODs, up to 23 longs in fact which is just enough room for a fast SDRD routine to read the data.
Running on a 80MHz system would normally take 20% longer but the 150us or latency is fixed so overall probably closer to or just under 1ms @80MHz. Many of my systems use a tiny 6MHz oscillator these days so that's the stuff I normally test on.
BTW, I might be able to speed up the command/response phase a little but I'd be doing well to trim another 100us and I doubt I would be able to do much better than 700us due to the latency plus clocking speed.
How does this vary with brand and age, and do 'tired old' SDs do worse here ?
There's no need to use a PLOT RUNMOD while testing so you are free to handle it any which way. A plot routine can run faster and draw lines over lines and text if it only sets bits so this is the reason for the default but of course we can add features to an "EPLOT" RUNMOD but that would also run slower too, plus it would still have to fit within 23 longs. I've found it is easier to clear all or part of the buffer before drawing, hence the optimized PLOT.
BTW, this LCD driver should be very simple, or should I say, it should end up being very simple. I know this is a learning experience but if it is too frustrating please just let me know as I'm sure I could whip up one to suit the Lamestation in which case it is still a good learning experience
That's right about "tired old" SDs but also Flash in general including the Flash memory in phones and tablets. Everybody complains how their zippy device is not so zippy anymore but very rarely do you hear about wear leveling and "TRIM". However the truth is that even then they try to compensate for Flash wear but latency creeps in with wear. Oh if only we have something better than Flash that didn't wear out or imagine if we could replace the internal eMMC chip, then your 2014 device would be zippy again!
Anyhow, these cards are new 8GB Sandisk Ultra micro SDHC so they are fairly typical of a card we would use in an embedded system. But FAT32/16 is not at all that friendly to Flash as it crams all the directories together and if the file size and FAT were continually updated on a log file it would lead to premature wear. Hence the reason I don't update them like that for log files either plus I like to preallocate memory so that there is no need to tamper with the FAT. However I have never found any files fragmented when SD cards are used on the PC despite the warnings I hear since my virtual memory layer treats the card and each file as contiguous sectors rather than traversing the FAT. Besides I have routines that check for fragmentation just in case, but I haven't found one yet unless I perhaps threw hundreds of files onto a card including PC system files and left that thrashing and trashing long enough.
To answer you question though I will try to dig up some old cards and try them out.
I think (as I wrote in the other thread ?) it is simpler to change the PLOT word (not RUNMOD) to write into a buffer set up to suit the KS0108 display. Plot only has to handle a single bit. So this requires just a little bit of address arithmetic.
Converting standard buffer which is organized in rows into columns as required by the display needs reading 8 bytes and doing a transpose.
Easier to set up a transposed buffer so the copying of buffer to display get's really straight forward .. and much faster.
All higher level plotting commands just go via a single bit PLOT.
Just redo this.
AFAIK currently there is no REVECTOR so this new PLOT needs to b loaded before the higher level plot code which will use it.
As MJB says in regards to PLOT, "just redo this".
Like Nuclear Fusion, 'something better than flash' has been promised as being real-soon-now, many times.
I saw this recent news around MRAM
http://www.eetimes.com/document.asp?doc_id=1331447
QuadSPI versions are quite small, and the DDR3 ones seem to have no prices ?
Quick Card ID
Images for slow SandDisk vs "Ultra" where the latency is around 150us. The area between the AB cursors in the first image is the constant polling of the SD card data line waiting for a "data token" to indicate that the data is ready to be read as you can see the data in the cyan trace.
I adapted @Peter's QVGA-LCD driver for a ILI9341_QVGA a while ago to show an Arduino user how easy it is with Tachyon. Those color displays do not require a buffer, you can just draw directly an save the memory.
But you can just have fun with the Lamestation and learn on the way ;-)
Maybe as a stretch goal - implement it in both ways and run some comparisons - could be interresting.
For V4 I intended to have a sorted list in EEPROM with fixed 16-byte entries so that a binary search could find a match quickly. However I thought about it and building and maintaining a sorted list is a bit of a pain. Now I think I have hit on a very good solution, a minimum of fuss and very fast and compact. On compacting or archiving eligible entries to EEPROM they will be moved complete up to 16 bytes without sorting and in the same order they were created. But this would be too slow to search in EEPROM, very slow in fact. So I create an additional hash byte dictionary array comprised of a single hashed byte whose byte index in this array corresponds with the 16 byte entry in EEPROM. So a hash byte would be generated from search string and then we compare this byte with any matches in the hash byte dictionary array. If we find a match we then start comparing the counted strings in hub RAM and EEPROM. As soon as the byte by byte compare fails it will continue searching the hash dictionary until a hash byte match and string match. The EEPROM compare would use sequential byte read to begin a string compare rather than reissuing EEPROM address for each read.
DICTIONARY ENTRY "DUP"
In EEPROM becomes: with a hash byte in the same order left in hub RAM hash-byte dictionary.
Now when the dictionary is being searched it should be even faster than the complete dictionary in hub RAM since only a single byte is being compared per entry and it simply advances to the next location etc. So a 1,000 entry dictionary will only occupy less than 1k of hub RAM and will be very fast to search. Now that it's so simple I will get it working very quickly.
While sure 64k EEPROM is preferable, there are still a lot of 32k boards around.
The new method has been changed slightly, the EEPROM entries look exactly like they did in RAM except of course each entry is indexed on 16 byte boundaries.
Here EASYNET has just been loaded on top of a compacted dictionary. Name space used with EASYNET words is 3510 while free space is 4384, so after further compacting that should make around 8kB available.
Some dictionary in upper EEPROM.
FIrst 64 entries in the hashtag table
Just wanted to make sure we need not fall back to V3 for 32k boards.
thanks
i'm still alive and eager. I wrote - oh man how time is running - six years ago a propeller (spin) mode for emacs and posted it in the forum. Recently I took the sources and patched them a bit for tachyon and now I have a really fine customizable development environment for tachyon.
With 600 lines I have syntax highlighting, sending a buffer with line delay out of the emacs buffer to a tachyon device - seeing reaction in minicom this is really cool.
I know with the highlighting settings I overshoot a bit. It's very colory but I coudn't resist - will tame it again when I know how to use the power.
This is the first picture of my own graphics driver on the lamestation with tachyon. Hoooray.
Thanks to all (especially @Peter) who helped me doing this!!!
I use medit with custom syntax highlighting and minicom is just set to 5ms line delay but of course I am still using the old copy text and paste into minicom method.
And is tachyon expecting a CRLF pair for the console entries?
Differences in V3/V4 regarding the console port?
dp
I was trying to compile EASYNET the other day to run it which is why I have added a suitable EEPROM method and only started to play with networking in V4 just a couple of days ago. But it didn't work and one of the reasons was the way that the console interface is used by FTP and HTTP in that it needs to be QUIET, not prompting, not echoing, and certainly not printing line numbers etc. So I've updated my internal 4.2b which also includes RECLAIM to strip out all the private headers. Now have a look at the QUIET mode word taken from the updated EASYNET.
So the main thing is to turn off echo and disable PROMPT via its control vector "prompt" with a high level "no operation" NOOP. I may take a look at the ESP interface myself although I am rather busy building a multi-channel portable power analyzer at present.
Thanks Peter
UPDATE: Fixed. Found the 200ms timeout in the current websocket library causing missed async serial RX from the prop. Switched to the async websocket and web server implementations. Almost done now
it seems you are busy with v4.3. There have been many changes in the kernel.
As far as I tried v43 isn't yet ready for release on iot5500. Am I right?
Best regards,
proplem
I'm just checking through fixes and optimizations I have done to EASYFILE V4r3 which include virtual file memory handlers. There were some problems with EASYNET on 4.3 so I will be checking that again next.
thank your for the effort with v4.3 and iot5500.
I tried to create for iot5500 with V4.3 and there's still a hopefully small problem with EASYFILE-V4r3.FTH. The build output follows:
Can you give an additional tip to your naming convention ...v4r2, V4T, V4S etc.?
Thank you very much, best regards
proplem
btw, I'm using minicom with a 5ms line delay @921600 baud but once I COMPACT before loading EASYNET I need to set it to 50ms at present since the EEPROM search can be a little slow. This I hope to improve as much as possible but neither do I want to complicate this simple scheme. Besides, I FLOAD EASYNET from the SD card mostly anyway but I think it would be nice if I could download a text file normally but have it saved to a temporary (or not) file so that it could perform an automatic FLOAD from there. That way the line delay could even be set to zero.
I'm also exploring how I might implement a practical screen editor that uses the SD card and ANSI terminal as a screen. Not having large amounts of RAM precludes the luxury of manipulating it that easily and while I can use virtual memory it needs to hold off updating the file too frequently as in the case of inserting characters. Maybe at the end of a line will do. I can see why the early Forth systems organized everything in 1k blocks as you didn't have to worry about anything more than that. Perhaps I could do something similar except I don't need to deal with horrible block numbers, I would just use the file system and have it insert "virtual blocks" although the file would still be a standard text file albeit with trailing "blanks" for each line to suit. I would probably make those blocks so that there wasn't any implied "new line" unless a CR was encountered so the trailing blanks would have to be a neutral character too as I would still want to be able to handle these files over FTP.
Anyway, a screen editor using the SD card and ANSI terminal should be very fast and smooth to use plus I could always dedicate another Prop over a single-wire PPNET as the terminal with hires 128x50 text and PS/2 keyboard or joy of joys, a USB keyboard finally (although I would just use a Logitech Unifying receiver).
Ah, decisions, decisions.