I'm busy running the EX program on a real Z80 so while I wait for that...
Both you and the hairy monster are combining more and more code into less cogs. Ram plus SD etc. That can free up cogs. The VT100 code can do 'pre processing' on an escape sequence with its little 7 byte buffer and that can be done seperate to the VGA driver. Maybe even in a different cog? Maybe combine with the keyboard cog or another cog? Or maybe the LMM idea where you only bring in code when you need it (how often are some VT100 codes really used anyway?).
So could it be done as a LMM but in a different cog?
Dr_Acula said...
So could it be done as a LMM but in a different cog?
Yes, that's possible. I think it will be shorter in Spin, though.
Attached is my tv80 driver that does abt. 1/3rd of the VT100 escape sequences that a Linux terminal does.
BTW Wordstar is emitting strange escape sequences. There are cursor positionings with non-numeric characters!? <esc>[noparse][[/noparse]x,yH is the format, but I see <esc>[noparse][[/noparse]1:;1*H and the like. That could be a bug in Z80 arithmetic that isn't detected by EX or that I did not yet see.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I suspect that Wordstar is doing that on my version as well, using backspace to correct a mistyped filename shifts the rest of the display down one line, very odd. So it may be a bug in wordstar rather than the emulator. Some of my problems are to do with the UK keyboard I'm using which isn't producing the keys I'd expect but backspace or ctrl-H should work, they do in edit mode.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr said...
I suspect that Wordstar is doing that on my version as well, using backspace to correct a mistyped filename shifts the rest of the display down one line, very odd. So it may be a bug in wordstar rather than the emulator. Some of my problems are to do with the UK keyboard I'm using which isn't producing the keys I'd expect but backspace or ctrl-H should work, they do in edit mode.
Hmm.. if I remember that correctly from ancient times, then Wordstar had some patch areas where the code to generate e.g. a cursor position string representation could be placed. Since it is set to VT100, it should emit valid VT100 sequences and not the garbage I'm seeing. It looks like it is set to always emit two digits x and y, and since the 1s position is going higher than 9, I suspect that some comparison/subtraction isn't setting a flag right.. or perhaps a flag is lost in another opcode that should really preserve it. I'll have a look at the patch area and how it's done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Orginal WordStar on CP/M had one Install file to initialise what terminal type it will emulate.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Nothing is impossible, there are only different degrees of difficulty. For every stupid question there is at least one intelligent answer. Don't guess - ask instead. If you don't ask you won't know. If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Orginal WordStar on CP/M had one Install file to initialise what terminal type it will emulate.
Yep. I/we know, because wschange.com is on Dr_A's disk. I remember you could manually patch it for unknown terminals. I once had to do this for a strange almost VT52 terminal which had minor differences. But it's all so long ago... The patch area seems to begin at $280 and extends until $4xy something in WS.COM. There you can find the various strings to control the cursor etc. but I have not yet found the function that actually generates the cursor address sequence.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
You can see commands like ESC[noparse][[/noparse]02;01H
See attachment - this is a version patched for a VT100 display. Not all the files are there as some don't change - I think it is ws.ovr and ws.com that are patched. Anyway I've just tested this one.
I've done it!! Finally. It's been a long evening of trying to find particularly confusing and well hidden bugs. However, here is my current version of the DracBlade tree with FSRW2.6
There's no noticeable speedup in running wordstar etc. as far as I can see, there's a lot of optimisation to be done though.
This version doesn't do any of the delayed write etc. that we've been discussing, it works exactly as the old one did but with the new FSRW and SPI routines. It's a fair bit bigger but a lot of the FSRW stuff can be trimmed out since it's not being used. It should now support HCSD and FAT32, but it doesn't seem to be working properly yet.
There are quite a lot of changes in the Main_Dr_Acula.spin to accommodate the new version of FSRW hopefully I've not broken too many of the extra features I can't test (LCD, wireless etc.)
I've also not bothered with the high latch at all, it's left where ever it is at startup. This shouldn't matter as we'll get a 64KB RAM space on the lower latches whatever it is set to. That's coming in a later version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
LCD works
Xmodem file transfer works
Mbasic works
Wordstar works
Wireless transfers work
Hey this is great! Well done.
New code uploaded to page 1 first post. I made just one minor change and commented out this bit
' little debugging routines to see if can read a byte back from the sram
{
vgatext.hex(long[noparse][[/noparse]buffcog],8) ' this should print C3
vgatext.out(13)
vgatext.out(10)
long[noparse][[/noparse]buffcog]:=1 ' this changes it to 01
vgatext.hex(long[noparse][[/noparse]buffcog],8) ' this should print 01
vgatext.out(13)
vgatext.out(10)
memm.readram(buffcog, 0, 3) ' read 3 bytes in buff array to address 0
vgatext.hex(long[noparse][[/noparse]buffcog],8) ' this should print C3 again
vgatext.out(13)
vgatext.out(10)
}
as this is now proved and working.
What are you going to rewrite next?!
Addit: heater was saying on one of these threads about the minimum files size. I just checked that - it seems to be 2k if the disk image is a floppy image, but 4k if it is a hard drive image like the ones we use.
Yeah, I'd figured the 4K thing when I wrote that disk image browser in Python the other day.
Scratch what I said about not doing HCSD, looks like it was dirty contacts or something because I've just tried it again and it's working.
I'm currently running CP/M on my DracBlade on a FAT32 formatted 4GB HCSD card!!
Next I plan to sleep, then go and do some of the paid research I'm meant to be doing, then maybe start tidying up some of the mess in the PASM that I wrote to get this far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr: I disabled the read ahead feature of fsrw2.6 and I cannot recall what I did regarding the writing of 128 bytes. ZiCog was buffering the 512 to 128 byte transfers. You can check my fsrw2.6 code on the RamBlade or TriBlade.
FAT32 access is slower than FAT16 but once you get into CPM emulation there should be no difference since we are just reading/writing 512 byte sectors directly at the low level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
hairymnstr said...
Yeah, I'd figured the 4K thing when I wrote that disk image browser in Python the other day.
Scratch what I said about not doing HCSD, looks like it was dirty contacts or something because I've just tried it again and it's working.
I'm currently running CP/M on my DracBlade on a FAT32 formatted 4GB HCSD card!!
Next I plan to sleep, then go and do some of the paid research I'm meant to be doing, then maybe start tidying up some of the mess in the PASM that I wrote to get this far.
Congratulations!
I'll have a look at what you did and will try to incorporate this for the Dracblade.
One cog saved - hooray! I can use it, because I had none left.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Dr_Acula said...
That does not sound right with wordstar. The escape sequences should be numerical. This is a dump of a wordstar startup.[noparse][[/noparse]/code]
I've been doing some thinking about bugs on the bus this morning. I have come to two realisations:
1) The reason HCSD was not working was that I hadn't burned the EEPROM and was letting the old sdspi routines try and initialise the card then using F10 to run the new version from RAM. This meant that the HC card was not getting the right startup sequence for a high capacity capable host initially and it turns out this locks the card in "busy" mode until you power-cycle it rather than until the next reset CMD0. Once I've bothered to press F11 this bug should be fixed.
2) The reason it appears slower is because I've inadvertently broken the read-ahead feature (I'll have to double check my code on that). By accessing the RAM inbetween card reads the last command flag is changed which marks the cache as dirty even though I've been careful not to actually alter it. This basically means that it's fetching two blocks every time (and blocking access to the RAM while it fetches the second as the RAM control cog is busy) and since the next command is always a write RAM it is throwing away the pre-cached block when it is needed. I'm guessing it was something along these lines that got you to disable it Cluso? It would block access to your RAM as well while you waited for a "z" command to complete I guess.
I'll do a couple of experiments on this tonight and see if I can preserve the cache, I think it might be faster if we can use it, otherwise I'll disable it and stop hammering the card so much. Hopefully I'll get the LED access back tonight too. Have to see.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
hairymnstr: Your comment reminded me that there is another change I made to the fsrw routine. Normally when the SD card is deselected it does not release the DO line and this causes a corruption of the bus. lonesock put a commented set of instructions (labelled cluso's mod or similar) that force the release of DO.
My reasoning for disabling the read-ahead is that firstly we are accessing 128 bytes records so it is buffered anyway and any further buffering I thought may indeed slow the access. I also thought that later I would check to see if writes actually changed the sector and if not, do not performa write. However, you guys are out of memory so maybe you cannot do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Yes, SD cards aren't fully SPI compliant devices, you have to give them a few clocks after you've release CS before they tristate DO. I saw some code to do this in the old sdspiFemto with your name on to do this, but I don't think I've spotted it in ms_small_spi that I've been working on. Maybe I just haven't noticed it.
To be honest I think it would be good practice to do this whatever the hardware layout there's not a lot of point in only half tristating the SPI bus.
I'm not quite sure about what you mean about whether the sector was changed and not doing a write. Are you suggesting checking the sector number or is this a byte-wise comparison of the whole data block before and after the write?
I think the DracBlade has more RAM spare than it might at first appear I can see at least another kilobyte I can free up with a little careful tweaking.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Here's the latest. I've taken Cluso's approach and disabled read-ahead caching for now, it was not helping really as it is sharing the cog with the RAM control on the DracBlade (and the bus on other blades) concurrent access to RAM and SD isn't possible so doing a read ahead while we're off doing something else doesn't work.
Also included:
- I've added access to the high latch again. (Now with flashy LED on disk access again [noparse]:D[/noparse])
- I've put #ifdef DracbladeProp around all the dracblade specific code, basically the high latch bits and the readbyte/writebyte RAM functions, if someone with one of the other platforms wants to try a port then feel free (I have no particular interest in seeing it ported as I don't have any other Blades and have no idea what their cog/hub/spin memory/processing restrictions and bottlenecks are.)
Next (after eating some sort of food) I plan to take a meat cleaver to the FSRW code. It's very feature rich, and we simply don't need all of it. Hopefully I can cut several hundred longs (aiming at 300!!) without removing any functionality that I just added (i.e. the FAT32 support etc.)
Just out of curiosity I tried the FAT32 HCSD card and it runs at exactly the same speed as the 1GB FAT16 once ZiCOG is running (as you'd expect really) so an extra few milliseconds while it finds the disk images is a small price compared with the hassle of getting hold of small SD cards these days.
Cluso: I see, is that really going to be much quicker? I guess hub ram operations are still a lot quicker than SD access.
EDIT: Some idiot forgot the attachment. It's been a long week
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Post Edited (hairymnstr) : 3/30/2010 6:38:05 PM GMT
- I've put #ifdef DracbladeProp around all the dracblade specific code, basically the high latch bits and the readbyte/writebyte RAM functions, if someone with one of the other platforms wants to try a port then feel free (I have no particular interest in seeing it ported as I don't have any other Blades and have no idea what their cog/hub/spin memory/processing restrictions and bottlenecks are.)
I may try the RamBlade, as Cluso99 sent me one. Only decouraging thing is that I was not yet able to run any of my code on that board - and without help I'm stuck *hint* *hint*
The code is shorter than that needed for the DracBlade, so it should fit anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Turns out my target of 300 longs was overly cautious. Here's the latest (and probably last for a while) with just over 500 longs less code.
I had to remove some of the file reading/writing code to get rid of one of the disk buffers in FSRW. This means that I altered the code for opening/reading MyName.txt I think it's working now gets the right name off the card on mine. Worth testing though.
So this version has 900+ longs free and a spare cog. There's some more that could be trimmed I think it'll depend on how much we need the extra memory how much extra hassle it's worth.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
I might have to give up my day job to spend more time on this! Well done, 500 longs is (in the language I speak) 2 kilobytes! And a spare cog. I've been thinking of all the good things we can do with that, and also thinking that it might be good to keep things flexible with #ifdefs on any code for that new cog. So you might have an #ifdef for bell modem code, and an #ifdef for an audio driver etc.
There is a lot of code Juergen has already written that should save even more code by moving things into pasm. Possibly even with overlays loaded in from the ram chip for infrequntly needed code eg obscure VT100 codes that are only used once in wordstar. If a lot of hub ram is free, one could think about using that for a graphics buffer for vga. I know propbasic can do some cool graphics, and it is a fairly simple equation - more hub ram = more pixels and more colours.
I fear you will start to run out of memory very quickly if you try other things with this. The code I've put together (with all those longs saved) is saving longs by relying on CP/M to do the filesystem stuff. If you're planning on running some other sort of Prop-resident command interpreter/OS then you're probably going to be needing the full FSRW.
I don't really know what to put in the new cog, there are some addons like you suggest, I'd wondered about strapping a real-time clock piggy-backed onto the EEPROM on my board which would need some I2C drivers but I'm not sure how much value that would be. I think the I/O would be sped up a lot by having a cog monitoring the ZiCOG I/O mail-box address and doing the command dispatching direct to hub mail-boxes for other peripherals.
I don't know it it is going to be possible to do the no-hub version of the combined SD/RAM driver as there are only about 10 longs free in that cog now, so there's still got to be a whole bunch of hub transfers there.
I'm going to be away for a bit over the bank-holiday weekend so may get some inspiration when I come back to it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
@heater: CP/M can have allocations of less than 2K but would be for a small device like old floppy drives. Take a look at the tables on page 34 of the CPM Programmer's Handbook. It is allowed but given the sizes we are using probably not practical.
Now that the hardware is stable (and the software is shrinking - thanks ++ to everyone), I'm working on the problem of networking. Networking seems such a simple idea, but it is only recently that even PCs had easy ways to network (remember conflicts between ethernet and sound cards on windows 95/98?) and even now blue cat6 cables are not that common in homes. So networking is not a simple problem.
I've got some simple programs that allow remote login via wireless to CP/M boards and file transfer, and a very simple packet protocol for bouncing messages round wirelessly. What would be great is to have this network interface with the wider internet.
Back last year I had a N8VEM board on the internet and people were able to telnet in from the other side of the world. But the connection was one way - the N8VEM could not connection out to other boards. Partly this was because it only had one serial port, and partly it is because the TCP/IP software is incredibly complicated. We got around the latter problem using Lantronix units that translated cat6 ethernet to RS232 and with dyndns it was possible to create a static IP address anyone could connect to.
But the propeller now has some of the hardware to do cat6 connections (and possibly some of the software too).
I'm thinking about this more after receiving an email from Mr Roche in France and I'll reproduce it below:
[code]
Hello, James!
Just received, a few minutes ago, a message from Ralf K
hairymnstr: While doing a compare to save writing if no changes were made would save time providing the write was not executed, another gain is ensuring we do not wear out the card. A long time ago it was discovered that a lot of writes by computers actually did not change anything.
I am not sure I want to use a non-standard (i.e. heavily modified) fsrw driver. This just makes it so much harder to accept updates and this driver will be the basis of SphinxOS (at least my incarnation of it) as the current Sphinx uses 3 cogs for this.
My aim is to have SphinxOS load the various drivers into cogs, so that ZiCog just uses the drivers without knowing where the data is going. This way we can substitute serial, 1pin TV, 1pin keyboard, vga, or whatever without having ZiCog necessarily being aware of changes. This then permits the off-loading of the I/O to a second prop easily.
FYI My 1pin TV driver re-uses it's hub code space (which is loaded into the cog) as the screen space.
pullmoll: I have the hint. If I get a chance I will email you over the Easter w/e although I first have to drive 800km home (I am on the boat interstate) and we have visitors.
I have discovered a problem that my 1pinTV driver blocks my 1pinKeyboard driver when the TV is on P6/P14/P22/P30 and Kbd is on P7/P15/P23/P31 respectively. Hopefully I can post a stripped down piece of code for other eyes to look at today. Specifically I see the problem on P22 & P23 and can reverse the pins and still have problems. If I disable the TV the keyboard is fine. I need this for my RamBlade to run standalone. Originally I had thought it was just a timing bug for 6.5Hz operation of the keyboard but I have confirmed it is not this :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I had a thought yesterday that I want to share. In short: cog loading from SD.
Instead of having the images of all the code that is run in the cogs in hub RAM too, with the image range possibly not re-used as a buffer, wouldn't it be neat to have just one 512 longs (2K) region where the main code that has to be resident to do this could load the remaining cog code from small files? You would need the SPI SD code and some minimal FSR (without W) code to do that. Then you could load e.g. the UART code and start it in a free cog, the VGA object, the Keyboard driver etc. Of course the pre-configuration Spin code for these objects would have to be run to start them, and I don't know if that works out. Most objects have a start method, but also different parameters to that function. If there is a way to get around this, it should in the end leave a lot of contiguous hub RAM one could use as e.g. buffer for VMM pages.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I tried to do this about 2 months ago and the first step was to condense all the objects into one file in order to find any conflicts between variable names. That took a whole day and I still hadn't made any progress. Indeed, the code now would not run. It is not simple and one thing that is needed is to remove as much of the supporting spin code as possible. Also all variables need to be passed via common locations.
Cluso is also working on a similar concept with Sphinx - portable objects that can be stored as independent blocks of code and loaded as required. How is progress on that?
BUT with your new code, and hairmnstr combining pasm objects together, maybe it is time to revisit the idea?
There is the cog running spin.
Then you need the cog to load all the other cogs, and for the dracblade this is now the combo ram and sd card cog.
So - portable keyboard code. Portable vga code (2 cogs). Portable serial port code. TV cog etc. It could save quite a lot of precious hub ram which could be reused in other ways.
Dr_Acula said...
So - portable keyboard code. Portable vga code (2 cogs). Portable serial port code. TV cog etc. It could save quite a lot of precious hub ram which could be reused in other ways.
That was the idea, yes. I look at my own code which fills up the hub RAM and the various pieces of unused cog images. I could modify the objects to return their location, but then I've got fragmented hub space of some 1-2K bytes here and there. With loading from external media the fragmentation would be less.
I think the spin code for the start method of an object could be loaded and be called somehow using a temporary 2nd interpreter. That means you can't load all 8 cogs, except if you don't have to execute a Spin method for the last cog. This could be done by adding that module's start code to main.
That would also offer easy flexibility to what modules to load. Just define a list with the names and choose with or without LCD, with or without TV, with or without VGA etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Many interesting thoughts there. I totally agree that there's no point in you using the stripped down FSRW Cluso, since you can offload a lot of the I/O onto a second Propeller, but in the DracBlade every long counts.
As far as networking is concerned there are some excellent things for the propeller, look at the YBox2 for example. I've got a Microchip ENC28J60 Ethernet chip in big dip format in my parts box but have never got around to using it. I think, however, you need a supplementary processor of some sort there is no way you'll find room in the DracBlade to do all the ethernet stack. I think the new Parallax ethernet/web server app uses an external TCP (or UDP?)/IP controller, not sure what it is though.
Loading pasm from disk sounds quite reasonable, we need a way to encapsulate the PASM in a single file without any of the spin surrounding it, then it's just a case of allocating a 2K buffer in hub and loading objects up one at a time. Some sort of python script that can strip the PASM out of an eeprom image perhaps?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Comments
I'm busy running the EX program on a real Z80 so while I wait for that...
Both you and the hairy monster are combining more and more code into less cogs. Ram plus SD etc. That can free up cogs. The VT100 code can do 'pre processing' on an escape sequence with its little 7 byte buffer and that can be done seperate to the VGA driver. Maybe even in a different cog? Maybe combine with the keyboard cog or another cog? Or maybe the LMM idea where you only bring in code when you need it (how often are some VT100 codes really used anyway?).
So could it be done as a LMM but in a different cog?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Attached is my tv80 driver that does abt. 1/3rd of the VT100 escape sequences that a Linux terminal does.
BTW Wordstar is emitting strange escape sequences. There are cursor positionings with non-numeric characters!? <esc>[noparse][[/noparse]x,yH is the format, but I see <esc>[noparse][[/noparse]1:;1*H and the like. That could be a bug in Z80 arithmetic that isn't detected by EX or that I did not yet see.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Hmm.. if I remember that correctly from ancient times, then Wordstar had some patch areas where the code to generate e.g. a cursor position string representation could be placed. Since it is set to VT100, it should emit valid VT100 sequences and not the garbage I'm seeing. It looks like it is set to always emit two digits x and y, and since the 1s position is going higher than 9, I suspect that some comparison/subtraction isn't setting a flag right.. or perhaps a flag is lost in another opcode that should really preserve it. I'll have a look at the patch area and how it's done.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
Orginal WordStar on CP/M had one Install file to initialise what terminal type it will emulate.
Regards
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.
Sapieha
Yep. I/we know, because wschange.com is on Dr_A's disk. I remember you could manually patch it for unknown terminals. I once had to do this for a strange almost VT52 terminal which had minor differences. But it's all so long ago... The patch area seems to begin at $280 and extends until $4xy something in WS.COM. There you can find the various strings to control the cursor etc. but I have not yet found the function that actually generates the cursor address sequence.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
You can see commands like ESC[noparse][[/noparse]02;01H
See attachment - this is a version patched for a VT100 display. Not all the files are there as some don't change - I think it is ws.ovr and ws.com that are patched. Anyway I've just tested this one.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/29/2010 9:59:15 PM GMT
There's no noticeable speedup in running wordstar etc. as far as I can see, there's a lot of optimisation to be done though.
This version doesn't do any of the delayed write etc. that we've been discussing, it works exactly as the old one did but with the new FSRW and SPI routines. It's a fair bit bigger but a lot of the FSRW stuff can be trimmed out since it's not being used. It should now support HCSD and FAT32, but it doesn't seem to be working properly yet.
There are quite a lot of changes in the Main_Dr_Acula.spin to accommodate the new version of FSRW hopefully I've not broken too many of the extra features I can't test (LCD, wireless etc.)
I've also not bothered with the high latch at all, it's left where ever it is at startup. This shouldn't matter as we'll get a 64KB RAM space on the lower latches whatever it is set to. That's coming in a later version.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Xmodem file transfer works
Mbasic works
Wordstar works
Wireless transfers work
Hey this is great! Well done.
New code uploaded to page 1 first post. I made just one minor change and commented out this bit
as this is now proved and working.
What are you going to rewrite next?!
Addit: heater was saying on one of these threads about the minimum files size. I just checked that - it seems to be 2k if the disk image is a floppy image, but 4k if it is a hard drive image like the ones we use.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
Post Edited (Dr_Acula) : 3/29/2010 10:56:14 PM GMT
Scratch what I said about not doing HCSD, looks like it was dirty contacts or something because I've just tried it again and it's working.
I'm currently running CP/M on my DracBlade on a FAT32 formatted 4GB HCSD card!!
Next I plan to sleep, then go and do some of the paid research I'm meant to be doing, then maybe start tidying up some of the mess in the PASM that I wrote to get this far.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
FAT32 access is slower than FAT16 but once you get into CPM emulation there should be no difference since we are just reading/writing 512 byte sectors directly at the low level.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Congratulations!
I'll have a look at what you did and will try to incorporate this for the Dracblade.
One cog saved - hooray! I can use it, because I had none left.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
On mine the data is
Yours is
hope this helps
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
1) The reason HCSD was not working was that I hadn't burned the EEPROM and was letting the old sdspi routines try and initialise the card then using F10 to run the new version from RAM. This meant that the HC card was not getting the right startup sequence for a high capacity capable host initially and it turns out this locks the card in "busy" mode until you power-cycle it rather than until the next reset CMD0. Once I've bothered to press F11 this bug should be fixed.
2) The reason it appears slower is because I've inadvertently broken the read-ahead feature (I'll have to double check my code on that). By accessing the RAM inbetween card reads the last command flag is changed which marks the cache as dirty even though I've been careful not to actually alter it. This basically means that it's fetching two blocks every time (and blocking access to the RAM while it fetches the second as the RAM control cog is busy) and since the next command is always a write RAM it is throwing away the pre-cached block when it is needed. I'm guessing it was something along these lines that got you to disable it Cluso? It would block access to your RAM as well while you waited for a "z" command to complete I guess.
I'll do a couple of experiments on this tonight and see if I can preserve the cache, I think it might be faster if we can use it, otherwise I'll disable it and stop hammering the card so much. Hopefully I'll get the LED access back tonight too. Have to see.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
My reasoning for disabling the read-ahead is that firstly we are accessing 128 bytes records so it is buffered anyway and any further buffering I thought may indeed slow the access. I also thought that later I would check to see if writes actually changed the sector and if not, do not performa write. However, you guys are out of memory so maybe you cannot do this.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
To be honest I think it would be good practice to do this whatever the hardware layout there's not a lot of point in only half tristating the SPI bus.
I'm not quite sure about what you mean about whether the sector was changed and not doing a write. Are you suggesting checking the sector number or is this a byte-wise comparison of the whole data block before and after the write?
I think the DracBlade has more RAM spare than it might at first appear I can see at least another kilobyte I can free up with a little careful tweaking.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Also included:
- I've added access to the high latch again. (Now with flashy LED on disk access again [noparse]:D[/noparse])
- I've put #ifdef DracbladeProp around all the dracblade specific code, basically the high latch bits and the readbyte/writebyte RAM functions, if someone with one of the other platforms wants to try a port then feel free (I have no particular interest in seeing it ported as I don't have any other Blades and have no idea what their cog/hub/spin memory/processing restrictions and bottlenecks are.)
Next (after eating some sort of food) I plan to take a meat cleaver to the FSRW code. It's very feature rich, and we simply don't need all of it. Hopefully I can cut several hundred longs (aiming at 300!!) without removing any functionality that I just added (i.e. the FAT32 support etc.)
Just out of curiosity I tried the FAT32 HCSD card and it runs at exactly the same speed as the 1GB FAT16 once ZiCOG is running (as you'd expect really) so an extra few milliseconds while it finds the disk images is a small price compared with the hassle of getting hold of small SD cards these days.
Cluso: I see, is that really going to be much quicker? I guess hub ram operations are still a lot quicker than SD access.
EDIT: Some idiot forgot the attachment. It's been a long week
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Post Edited (hairymnstr) : 3/30/2010 6:38:05 PM GMT
I may try the RamBlade, as Cluso99 sent me one. Only decouraging thing is that I was not yet able to run any of my code on that board - and without help I'm stuck *hint* *hint*
The code is shorter than that needed for the DracBlade, so it should fit anyway.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I had to remove some of the file reading/writing code to get rid of one of the disk buffers in FSRW. This means that I altered the code for opening/reading MyName.txt I think it's working now gets the right name off the card on mine. Worth testing though.
So this version has 900+ longs free and a spare cog. There's some more that could be trimmed I think it'll depend on how much we need the extra memory how much extra hassle it's worth.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
There is a lot of code Juergen has already written that should save even more code by moving things into pasm. Possibly even with overlays loaded in from the ram chip for infrequntly needed code eg obscure VT100 codes that are only used once in wordstar. If a lot of hub ram is free, one could think about using that for a graphics buffer for vga. I know propbasic can do some cool graphics, and it is a fairly simple equation - more hub ram = more pixels and more colours.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
I don't really know what to put in the new cog, there are some addons like you suggest, I'd wondered about strapping a real-time clock piggy-backed onto the EEPROM on my board which would need some I2C drivers but I'm not sure how much value that would be. I think the I/O would be sped up a lot by having a cog monitoring the ZiCOG I/O mail-box address and doing the command dispatching direct to hub mail-boxes for other peripherals.
I don't know it it is going to be possible to do the no-hub version of the combined SD/RAM driver as there are only about 10 longs free in that cog now, so there's still got to be a whole bunch of hub transfers there.
I'm going to be away for a bit over the bank-holiday weekend so may get some inspiration when I come back to it.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."
Now that the hardware is stable (and the software is shrinking - thanks ++ to everyone), I'm working on the problem of networking. Networking seems such a simple idea, but it is only recently that even PCs had easy ways to network (remember conflicts between ethernet and sound cards on windows 95/98?) and even now blue cat6 cables are not that common in homes. So networking is not a simple problem.
I've got some simple programs that allow remote login via wireless to CP/M boards and file transfer, and a very simple packet protocol for bouncing messages round wirelessly. What would be great is to have this network interface with the wider internet.
Back last year I had a N8VEM board on the internet and people were able to telnet in from the other side of the world. But the connection was one way - the N8VEM could not connection out to other boards. Partly this was because it only had one serial port, and partly it is because the TCP/IP software is incredibly complicated. We got around the latter problem using Lantronix units that translated cat6 ethernet to RS232 and with dyndns it was possible to create a static IP address anyone could connect to.
But the propeller now has some of the hardware to do cat6 connections (and possibly some of the software too).
I'm thinking about this more after receiving an email from Mr Roche in France and I'll reproduce it below:
[code]
Hello, James!
Just received, a few minutes ago, a message from Ralf K
I am not sure I want to use a non-standard (i.e. heavily modified) fsrw driver. This just makes it so much harder to accept updates and this driver will be the basis of SphinxOS (at least my incarnation of it) as the current Sphinx uses 3 cogs for this.
My aim is to have SphinxOS load the various drivers into cogs, so that ZiCog just uses the drivers without knowing where the data is going. This way we can substitute serial, 1pin TV, 1pin keyboard, vga, or whatever without having ZiCog necessarily being aware of changes. This then permits the off-loading of the I/O to a second prop easily.
FYI My 1pin TV driver re-uses it's hub code space (which is loaded into the cog) as the screen space.
pullmoll: I have the hint. If I get a chance I will email you over the Easter w/e although I first have to drive 800km home (I am on the boat interstate) and we have visitors.
I have discovered a problem that my 1pinTV driver blocks my 1pinKeyboard driver when the TV is on P6/P14/P22/P30 and Kbd is on P7/P15/P23/P31 respectively. Hopefully I can post a stripped down piece of code for other eyes to look at today. Specifically I see the problem on P22 & P23 and can reverse the pins and still have problems. If I disable the TV the keyboard is fine. I need this for my RamBlade to run standalone. Originally I had thought it was just a timing bug for 6.5Hz operation of the keyboard but I have confirmed it is not this :-(
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Links to other interesting threads:
· Home of the MultiBladeProps: TriBlade,·RamBlade,·SixBlade, website
· Single Board Computer:·3 Propeller ICs·and a·TriBladeProp board (ZiCog Z80 Emulator)
· Prop Tools under Development or Completed (Index)
· Emulators: CPUs Z80 etc; Micros Altair etc;· Terminals·VT100 etc; (Index) ZiCog (Z80) , MoCog (6809)·
· Prop OS: SphinxOS·, PropDos , PropCmd··· Search the Propeller forums·(uses advanced Google search)
My cruising website is: ·www.bluemagic.biz·· MultiBlade Props: www.cluso.bluemagic.biz
Instead of having the images of all the code that is run in the cogs in hub RAM too, with the image range possibly not re-used as a buffer, wouldn't it be neat to have just one 512 longs (2K) region where the main code that has to be resident to do this could load the remaining cog code from small files? You would need the SPI SD code and some minimal FSR (without W) code to do that. Then you could load e.g. the UART code and start it in a free cog, the VGA object, the Keyboard driver etc. Of course the pre-configuration Spin code for these objects would have to be run to start them, and I don't know if that works out. Most objects have a start method, but also different parameters to that function. If there is a way to get around this, it should in the end leave a lot of contiguous hub RAM one could use as e.g. buffer for VMM pages.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
I tried to do this about 2 months ago and the first step was to condense all the objects into one file in order to find any conflicts between variable names. That took a whole day and I still hadn't made any progress. Indeed, the code now would not run. It is not simple and one thing that is needed is to remove as much of the supporting spin code as possible. Also all variables need to be passed via common locations.
Cluso is also working on a similar concept with Sphinx - portable objects that can be stored as independent blocks of code and loaded as required. How is progress on that?
BUT with your new code, and hairmnstr combining pasm objects together, maybe it is time to revisit the idea?
There is the cog running spin.
Then you need the cog to load all the other cogs, and for the dracblade this is now the combo ram and sd card cog.
So - portable keyboard code. Portable vga code (2 cogs). Portable serial port code. TV cog etc. It could save quite a lot of precious hub ram which could be reused in other ways.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller
That was the idea, yes. I look at my own code which fills up the hub RAM and the various pieces of unused cog images. I could modify the objects to return their location, but then I've got fragmented hub space of some 1-2K bytes here and there. With loading from external media the fragmentation would be less.
I think the spin code for the start method of an object could be loaded and be called somehow using a temporary 2nd interpreter. That means you can't load all 8 cogs, except if you don't have to execute a Spin method for the last cog. This could be done by adding that module's start code to main.
That would also offer easy flexibility to what modules to load. Just define a list with the names and choose with or without LCD, with or without TV, with or without VGA etc.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
He died at the console of hunger and thirst.
Next day he was buried. Face down, nine edge first.
As far as networking is concerned there are some excellent things for the propeller, look at the YBox2 for example. I've got a Microchip ENC28J60 Ethernet chip in big dip format in my parts box but have never got around to using it. I think, however, you need a supplementary processor of some sort there is no way you'll find room in the DracBlade to do all the ethernet stack. I think the new Parallax ethernet/web server app uses an external TCP (or UDP?)/IP controller, not sure what it is though.
Loading pasm from disk sounds quite reasonable, we need a way to encapsulate the PASM in a single file without any of the spin surrounding it, then it's just a case of allocating a 2K buffer in hub and loading objects up one at a time. Some sort of python script that can strip the PASM out of an eeprom image perhaps?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nathan
"Free as in freedom, beer gratefully accepted though."