The reason I am asking is I need to decide where to place the "physical memory" for the working set of pages used by VMCOG, and I don't want to overwrite areas used by SphinxOS.
Tentatively, I am thinking that VMCOG will use 8+ pages, $7Cxx down. I am going to enforce a minimum of 8 pages (2KB) as even that will swap like crazy, but it will be fun for stress tests and benchmarks [noparse]:)[/noparse]
I am considering making the default configuration be $4000-$7CFF for the working set, which would give VMCOG 61 pages to use as a working set, and leave the low memory for screen buffers etc.
What do you guys think?
Cluso99 said...
Here is a proposal for a new Hub memory layout for Sphinx.
Hopefully I have reserved enough space to allow enough base drivers. Of course others can be added by sub-programs but I thought a number of fairly standard/common devices may be in order.
I have added space for an SD buffer. I am not sure if this is necessary. We could just allocate it in the run-code and provide this address on calls to the SD routines. The latter way would allow re-use of hub space if cog(s) are loaded, so it could be better not to allocate an SD buffer.
Any thoughts??
P.S. Actually I think it would be better to swap the IN & OUT interfaces. Why? Because I am used to SI being P31 and SO being P30, so to me the input should be the higher one.
Consider this scenario...
<UL>
<LI>StdIN & StdOUT = Keyboard In, TV Out
<LI>AuxIN & AuxOUT = PC Serial
<LI>DbgIN & DbgOUT = Keyboard2 (1-pin), TV2 Out (1-pin) (debug terminal - 2 pin connection)
* spare & spare = Mouse In, Sound out
</UL>
I have been working on 1-pin TV and 1-pin Keyboard drivers for SphinxOS.
Part of my dilema is the size of the display and whether the screen buffer should be in cog or hub. I have the same issue for the fonts. It is not possible to have a large screen buffer in cog.
I suspect by current calculations it may be possible to have a screen buffer of 64 cols x 16 rows, but the code speed is an issue forcing me to drop to 40x16 currently (at 5MHz xtal). It may be possible to also squeeze 5x7 fonts by 96 characters as well. However, little room is left for basic screen manipulation (<cr>, <bs>, <up>, <down>, <left>, <right>, <clear>, <scroll>). Full VT100 is not possible with screen & font in cog.
So, do we reserve 2048 bytes (80x25=2000) for the screen buffer in hub ? What about color for other drivers ???
So, do we place an 8x8 font (1024 bytes) in hub ???
Or do we just allocate what is required at the top of hub memory and calcualte the upper limit and store that in a fixed location (say user5_rendezvous) that we can read ???
Possibly the same method could be used for the SD buffer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I'd suggest a 2K screen buffer for 80x25 in the hub, with a small font and as much useful vt100 subset emulation as feasible in the driver cog.
Cluso99 said...
I have been working on 1-pin TV and 1-pin Keyboard drivers for SphinxOS.
Part of my dilema is the size of the display and whether the screen buffer should be in cog or hub. I have the same issue for the fonts. It is not possible to have a large screen buffer in cog.
I suspect by current calculations it may be possible to have a screen buffer of 64 cols x 16 rows, but the code speed is an issue forcing me to drop to 40x16 currently (at 5MHz xtal). It may be possible to also squeeze 5x7 fonts by 96 characters as well. However, little room is left for basic screen manipulation (<cr>, <bs>, <up>, <down>, <left>, <right>, <clear>, <scroll>). Full VT100 is not possible with screen & font in cog.
So, do we reserve 2048 bytes (80x25=2000) for the screen buffer in hub ? What about color for other drivers ???
So, do we place an 8x8 font (1024 bytes) in hub ???
Or do we just allocate what is required at the top of hub memory and calcualte the upper limit and store that in a fixed location (say user5_rendezvous) that we can read ???
Possibly the same method could be used for the SD buffer.
Here is an external hub definition file and a hardware definition file. This way, we can have multiple definition files, or use the #define method.
I have placed a 2K screen buffer and a 1K 128 char 8x8 font in hub. These are of course·optional and can be commented out (or just overwritten) if not required.
how about something shorter like RZ? RENDEZVOUS is a lot to type!
Cluso99 said...
Next installment...
Here is an external hub definition file and a hardware definition file. This way, we can have multiple definition files, or use the #define method.
I have placed a 2K screen buffer and a 1K 128 char 8x8 font in hub. These are of course optional and can be commented out (or just overwritten) if not required.
Bill, I did not want to change the basics of what Michael had done. It is only a quick indirect reference so it is not typed except for passing the parameter to the drive.
Maybe just _StdIn etc would be better ? See below.
Cluso99 said...
Bill, I did not want to change the basics of what Michael had done. It is only a quick indirect reference so it is not typed except for passing the parameter to the drive.
Maybe just _StdIn etc would be better ? See below.
Are you trying to do 1pinTV and 80x25 at the same time? Does that actually look decent?
If you are doing 1pin tv, you could scale down to 40x25, or 1000bytes and put it in a cog...and if you are ambitious, you might be able to fit your 1 pin keyboard in the same cog.
hinv: Yes, I am trying to do 80x25 as an option. It looks OK. 64x16 (centre of screen looks good). Probably 80x25 is no worse than the original VDU's (visual display units) we had in the 70's, but we now expect better. I have only tried it on CRT TV's, not an LCD as I don't have access currently.
No, the 1-pin keyboard and 1-pin TV are too timing sensitive to work together in 1 cog. The 1-pin keyboard is also doing the bufering internally to the cog and decoding the keystrokes. The 1-pin TV hopefully will implement some subset of the VT100 code.
I am trying to understand the actual display method of the 1-pin TV. As far as I can tell, when a display pixel =1, white is displayed. When the pixel =0, black is displayed, and this is done by CTRB in PWM mode. I am wondering if the PWM width could be changed to provide multiple grey scales.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I think that SphinxOS can be compiled with a reasonable set of drivers inbuilt. This would allow for runtime deployment of the relevant drivers into cog.
So, for instance, if a screen of 80x25 was supported, then the screen buffer and font would be loaded into the space in upper hub ($7FFF downwards). The various rendezvous mailboxes would be used. Various cogs would be loaded as required for SD, TV, Keyboard, Serial, etc.
So, to do this, we need a config.sys type file or similar... It could contain something like...
I still like Ariba's idea of keeping system parameters in RAM. When I run ed, it has to find out which pins are used for video. Currently there's a hack where it asks the Sphinx video driver, but that'll fail if some other device is stdout.
If system info is in RAM, ed can easily look it up. If we go with the config.sys, what happens? Does ed have to parse config.sys?
The simple sxtv driver doesn't do cursor control and other stuff that ed needs, so ed uses its own driver (tv_text + a few mods).
That was just an example anyway. A program might want to start a bitmap driver or whatever. The point is it would be nice for programs to be able to find out pin assignments at run time.
I struck a few problems in trying to relocate the fixed upper hub memory in Sphinx. I think the problem is related to what files reside on the uSD. I need to look a little deeper.
Anyway, here is an updated SphinxOS v006e. It uses the serial I/O pins on the prop connected to a PC (via PropPlug or equiv). No video or keyboard in place yet.
Anyone wishing to compile will need to change the hwdef.spin to their hardware. It is at present set to TriBlade (Blade #2) with a 6MHz xtal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
The dependencies are because there are other programs running behind the scenes. You need to compile and load the latest binary to your SD card as "SPHINX.BIN". When you type "DIR" and enter, a directory will appear (I have used PST for this on the PC) and then it returns to Sphinx.
So you understand what is happening (it got me!!)...
You run SPHINX.BIN and you get the messages and then the SD> prompt.
You type "DIR" followed by Enter. This runs the program on SD called "DIR.BIN".
When DIR is complete, it runs "SPHINX.BIN" which now just displays a quick message followed by the prompt.
@mpark: I am having trouble recompiling DIR. Since the Sphinx will be corrupt (different hardware) on my SD/prop I tried to recompile on the PC. It compiled OK but will not run when copied to the SD. Am I missing something??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
mpark: Yes I compiled DIR on the pc and copied it to the SD along with Sphinx.bin. Sphinx ran ok but dir locks. However, the old dir works provided i dont move anything (the $8000 down blocks).
I did save to eeprom although my preferred method is for the eeprom to only have a minimal boot program in it so that reprogramming is not required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
I have SphinxOS working with serial I/O to the pc and 1-pin Keyboard & TV concurrently. · I am using it on a TriBlade #2 with the TV on P12 and keyboard on P13 and serial on P30/31. This means I cannot access the SRAM at the moment even though it is still in circuit (which is OK).
However, there are a few issues. Firstly, I am going to need to change the program loader as it clobers the upper hub ram when loading a new binary (like a DIR command) which is where my screen buffer for the 1-pin TV lives. BTW it is 40x25.
The cogs remain running when a new binary is loaded. It is also simple to switch drivers on the fly. So I can have a pc driver doing the output and then switch to the TV driver doing the output. Same with the input from pc or keyboard.
I am using the same drivers (two copies) for the input interface to pc and keyboard, and likewise for the output interface to pc and TV. This means that your code is now removed from the physical driver.
The hardware is also specified in a hx.spin file.
The TV driver has timing issues when you drive it flat out (continuous scrolling) so I have to break it into segments and switch tasks back to the display. Not a major issue and I was expecting this.
I haven't included this code yet as I want to get it working better. It's a bit rough around the edges, if you know what I mean!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Cluso99 said...
...I am going to need to change the program loader as it clobers the upper hub ram when loading a new binary (like a DIR command) which is where my screen buffer for the 1-pin TV lives.
Sorry about that. At the time, I was under the impression that I had to clear all hub RAM. My current understanding is that clearing just the var area should suffice.
mpark: As soon as I can get all the code to use relocatable hub locations (the rendezvous and SD buffer - something is still amiss and will not allow it to be moved) I will use the location long $7FFC to hold the bottom of this area. Then we will know how much is available, even if it moves. We can use that to set the clear limit if need be. And if its set then we know the drivers are loaded.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Here is an alpha release. I understand from mpark that there is a bug which corrupts the SD file system occasionally. I have a few corupt filenames on my SD that may have been caused by this, so beware.
This version supports 2 sets of terminals, one via serial (to the PC) and the other via 1-pin Keyboard & 1-pin TV. You require an SD interface too. Change the _hwdef.spin to select your hardware. It should work fine on a ProtoBoard with and SD connected. The standard keyboard and TV will work just fine with the 1-pin code·- the unused pins are just ignored. You will get B&W of course.
The other change you may need to do is the OPTION setting in CON in SphinxOS_rr006s.spin.· This sets whether to use the keyboard/tv or the pc for normal Sphinx I/O.
You will also need to follow the directions for installing Sphinx on the SD card. Then you will need to copy the newly compiled·sphinx.bin to the SD card to overwrite the old version.
The TV display currently tears when the screen scrolls fast (as when a DIR is done). I will fix this later.
@mpark: I found a bug in execute in sxfs2.spin where the filesize is checked against 32KB. It needs to also check the c flag. I have changed the load & clear to limit it to 56 * 512 = 28KB so that the upper hub is preserved. No check is made for larger programs so they will react abnormally.
I can now basically change the output device on the fly.
Question:
I have implemented·Standard Input and Standard Output device drivers. They can also be used as Auxilliary I & O drivers. These implement such functions as out, hex, dec, str and in, peek.
This is how I currently do this...
stdout.out("A") 'send character A to the standard output port
stdout.dec(x) 'send the decimal characters for value x
auxout.out("B") 'send character B to the auxilliary output port
c := stdin.in 'get an input character from the standard input port
c := auxin.in 'get an input character from the auxilliary input port
However, if I make the standard I/O routine able to handle multiple I & O devices, I could do...
std.out("A") 'as above to std out port (port1)
std.out1("A") 'same as prev line - to std out port (port1)
std.out2("B") 'as above to aux out port (port2)
std.out3("C") 'to another aux2 port (port2)
std.outall("d") 'to all ports !!!
c := std.in 'get input char from port1
c := std.in1 'same as prev line
c := std.in2 'get input char from port2
c := std.inall 'get input char from any port
By using the second method, it is extremely easy to add a call std.setio(xxxx) to change the input routines on the fly, so your code does not need to cater for this. We can also output to multiple ports concurrently, and receive from any port concurrently.
The reason for having .out and .out1 is that existing programs should be able to run with .out, so probably we should just use out to mean out1.
Another alternative is to use .outx(port, "A") where port is the port number, although we would need to keep .out("A" for the first port to be compatible with existing software.
Any comments or alternative ideas ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@Cluso99,
Looks great!
One minor thing that I noticed was that the "GET" command is in the command parser. If you are wanting to save a few extra longs, GET/PUT commands would be good canditates for utilities (like "DIR" is currently).
Re: Questions
I would recommend going with the [noparse][[/noparse].outx(port, "A")] implementation, over defining .out1, out2, etc., and reserve a port value (possibly 0) for your "all" out/in. If CON's were defined at the top of one's code ("TV_PORT = 1", "SER_PORT_1 = 2") it would make it easier to change the code, or if more ports are added in the future.
trdoss: The size of Sphinx is actually not a problem as it gets overwritten when any program/module is loaded. It is, as you say, better to keep them in seperate programs.
That way, we can replace or update get & put with later versions easily. That is what I liked about Sphinx when I saw it. DIR, ECHO etc were seperate programs, just like CPM was.
Thanks for your feedack [noparse][[/noparse].outx(port, "A")] Unfortunately spin does not allow optional calling parameters so we cannot have a default port. So,we will still need to support .out("A") so it will be compatible with a lot of objects already out there.
re the ports...
I have just needed to add options 2 & 3 because RamBlade only has 2 pins. So it cannot of course have an auxillary port(s).
I would like to remove the _hwdef.spin file into a readable file on the SD card (like CONFIG.SYS) and this could also then have the port configuration in it as well. I am discovering these things as I go, because I am operating two sets of different hardware here... TriBlade and RamBlade. I can of course cater for this with #define, but it makes more sense to be able to configure this without recompiling. Then we can have binaries available which makes things so much easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
@Cluso99,
I also liked having the utilities separated out from the shell when I saw Sphinx.
Supporting .out("A") would be important for what you describe (ease of making an object "Sphinx aware").
Eventually having a CONFIG.SYS would be helpful for interchangability with hardware configurations without having to recompile. Being able to distribute pre-compiled binaries would be nice. Otherwise, it is not that difficult to select the correct configuration in the _hwdef.spin.
I am talking about a simple file transfer mechanism that mpark has done. It is no Xmodem, but it is simple and could be used within any·spin or pasm program, and on programs on the PC end. Before anyone asks, I think we will get an Xmodem Sphinx·program in the future and this can be used with the many full-blown terminal programs out there. Xmodem is quite complex and needs to be standalone in the Sphinx concept, not embedded.
@trodoss: Yes, I think we are fast approaching the need for a CONFIG.SYS so that the binary for Sphinx does not have to change for differing hardware configurations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Links to other interesting threads:
Below is a text description of the xmodem protocol and this was all I needed to write xmodem from scratch in vb.net. It is a very simple protocol and would be an extremely handy addition to the growing list of sphinx programs. Pretty much all terminal programs have xmodem.
Possibly the hardest part is the building blocks - open a file, read/write a packet, close the file, find the length of a file.
That was pretty easy in vb.net and ought to be in spin, given the sd card drivers work like this anyway.
And the final bit that took a bit of tweaking was the timeout delays - eg it resends 10 times if a packet gets lost, and gives up after about 10 seconds. You don't want 10 secs to be 0.01 seconds, or 10000 seconds. Just a matter of adjusting some variables.
The xmodem protocol:
Perception presents:
Understanding The X-Modem File Transfer Protocol
by Em Decay
This has to be one of the most internationally accepted protocols for upload-
ing and downloading binary and text files. It is fairly straight-forward as
to how it is set up and there are some error checking capablities.
--- Before you begin ---
Things you need to know beforehand...
The following terms are simply ascii codes:
SOH = chr(1) = CTRL-A =
EOT = chr(4) = CTRL-D = End of Transmission
ACK = chr(6) = CTRL-F = Positive Acknowledgement
NAK = chr(21) = CTRL-U = Negative Acknowledgement
CAN = chr(24) = CTRL-X = Cancel
In order to send the file, you must first divide it into 128 byte sections
(packets). Bytes 0-127 of the file make up the first packet, bytes 128-255
make up the second packet, etc.
The packet number sent is simply the number of the packet. If the packet
number is greater than 255, then subtract 256 repeatly until the number is
between 0 and 255. For example, if you were sending packet 731, then you
would send 731 - 256 - 256 = 219.
The 1's complement of a byte (to make life easy) is simply 255 minus the
byte. For example, if you had to take the 1's complement of 142, the answer
would be 255 - 142 = 133.
The checksum is the value of all the bytes in the packet added together. For
example, if the first five bytes were 45, 12, 64, 236, 173 and the other 123
bytes were zeroes, the checksum would be 45+12+64+236+173+0+0+...+0 = 530.
However, to make each block one byte smaller, they repeatly subtract 256
from the checksum until it is between 0 and 255. In this case, the checksum
would be 530 - 256 - 256 = 18.
The first byte the downloader sends is referred to as the NCGbyte.
Provided that you aren't lost already, here is what happens next. The steps
below describe who sends what when [noparse]:)[/noparse]
--- The Actual Transfer ---
The uploader waits until the downloader sends a NAK byte. The NAK byte
is the signal that the downloader is ready to start. This byte is referred
to as the NCGbyte. If the downloader takes too long or an error occurs then
the uploader will stop waiting or "Time Out". If this happens, then the
file transfer must restart.
With each packet sent...
The uploader sends:
1. an SOH byte {1 byte}
2. the packet number {1 byte}
3. the 1's complement of the packet number {1 byte}
4. the packet {128 bytes}
5. the checksum {1 byte}
The above five things are called the block.
The downloader:
1. ensures that the packet number sent matches the actual packet number
that it is (If the third block send has a '4' as the second byte,
something is wrong --> CANCEL TRANSFER (send CAN byte))
2. adds the packet number and the 1's complement of it together to make
sure that they add up to 255. if they don't --> CANCEL TRANSFER
3. adds up all the bytes in the packet together --> THE SUM
4. compares the last two significant digits of THE SUM with the checksum
5. if everything looks ok (sum=checksum), then the downloader appends the
bytes in the packet to the file being created (sent). The down-
loader then sends an ACK byte which tells the uploader to send the
next block.
if the sums do not match then the downloader sends an NAK byte which
tells the uploader to send the same block it just sent over again.
When the uploader sends an EOT byte instead of an SOH byte, the downloader
sends a NAK byte. If the uploader sends another EOT immediately after that,
the downloader sends an ACK byte and the transfer is complete.
Another thing, the downloader can cancel the transfer at any time by sending
a CAN byte. The uploader can only cancel between blocks by sending a CAN
byte. It is recommended that you send anywhere between 2 and 8 consecutive
CAN bytes when you wish to cancel as some programs will not let you abort if
only 1 CAN byte is sent.
--- Wrap Up ---
Hopefully, you were able to follow along. [noparse]:)[/noparse] If not, you can e-mail me at
em_decay@norlink.net and I will try to clarify it for you. Have fun [noparse]:)[/noparse]
Perception: Em Decay -- Mark Korhonen
Cmf
Chris Fillion
Comments
The reason I am asking is I need to decide where to place the "physical memory" for the working set of pages used by VMCOG, and I don't want to overwrite areas used by SphinxOS.
Tentatively, I am thinking that VMCOG will use 8+ pages, $7Cxx down. I am going to enforce a minimum of 8 pages (2KB) as even that will swap like crazy, but it will be fun for stress tests and benchmarks [noparse]:)[/noparse]
I am considering making the default configuration be $4000-$7CFF for the working set, which would give VMCOG 61 pages to use as a working set, and leave the low memory for screen buffers etc.
What do you guys think?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
So, yes for now reserve $7D00-7FFF and use $4000-7CFF.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Part of my dilema is the size of the display and whether the screen buffer should be in cog or hub. I have the same issue for the fonts. It is not possible to have a large screen buffer in cog.
I suspect by current calculations it may be possible to have a screen buffer of 64 cols x 16 rows, but the code speed is an issue forcing me to drop to 40x16 currently (at 5MHz xtal). It may be possible to also squeeze 5x7 fonts by 96 characters as well. However, little room is left for basic screen manipulation (<cr>, <bs>, <up>, <down>, <left>, <right>, <clear>, <scroll>). Full VT100 is not possible with screen & font in cog.
So, do we reserve 2048 bytes (80x25=2000) for the screen buffer in hub ? What about color for other drivers ???
So, do we place an 8x8 font (1024 bytes) in hub ???
Or do we just allocate what is required at the top of hub memory and calcualte the upper limit and store that in a fixed location (say user5_rendezvous) that we can read ???
Possibly the same method could be used for the SD buffer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Here is an external hub definition file and a hardware definition file. This way, we can have multiple definition files, or use the #define method.
I have placed a 2K screen buffer and a 1K 128 char 8x8 font in hub. These are of course·optional and can be commented out (or just overwritten) if not required.
Comments welcome...
Hub Definition... (extract)
Hardware Definition... (extract)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
how about something shorter like RZ? RENDEZVOUS is a lot to type!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Maybe just _StdIn etc would be better ? See below.
I have reposted the hwdef which uses baudticks and clkfreq
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 2/16/2010 6:07:50 AM GMT
Gracias Senor
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.mikronauts.com E-mail: mikronauts _at_ gmail _dot_ com 5.0" VGA LCD in stock!
Morpheus dual Prop SBC w/ 512KB kit $119.95, Mem+2MB memory/IO kit $89.95, both kits $189.95 SerPlug $9.95
Propteus and Proteus for Propeller prototyping 6.250MHz custom Crystals run Propellers at 100MHz
Las - Large model assembler Largos - upcoming nano operating system
Are you trying to do 1pinTV and 80x25 at the same time? Does that actually look decent?
If you are doing 1pin tv, you could scale down to 40x25, or 1000bytes and put it in a cog...and if you are ambitious, you might be able to fit your 1 pin keyboard in the same cog.
Doug
No, the 1-pin keyboard and 1-pin TV are too timing sensitive to work together in 1 cog. The 1-pin keyboard is also doing the bufering internally to the cog and decoding the keystrokes. The 1-pin TV hopefully will implement some subset of the VT100 code.
I am trying to understand the actual display method of the 1-pin TV. As far as I can tell, when a display pixel =1, white is displayed. When the pixel =0, black is displayed, and this is done by CTRB in PWM mode. I am wondering if the PWM width could be changed to provide multiple grey scales.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I think that SphinxOS can be compiled with a reasonable set of drivers inbuilt. This would allow for runtime deployment of the relevant drivers into cog.
So, for instance, if a screen of 80x25 was supported, then the screen buffer and font would be loaded into the space in upper hub ($7FFF downwards). The various rendezvous mailboxes would be used. Various cogs would be loaded as required for SD, TV, Keyboard, Serial, etc.
So, to do this, we need a config.sys type file or similar... It could contain something like...
I have included SD, but SphinxOS must already know this or else it would not have been able to load the file!
Do we include pins and baud to override the hwdef.spin file ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
If system info is in RAM, ed can easily look it up. If we go with the config.sys, what happens? Does ed have to parse config.sys?
As far as ed is concerned, it could just update the screen buffer directly if it is in hub.
As for config.sys, I am not even sure if we need this complexity. I just thought I would throw it out for discussion.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
That was just an example anyway. A program might want to start a bitmap driver or whatever. The point is it would be nice for programs to be able to find out pin assignments at run time.
Anyone with suggestions/comments ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Anyway, here is an updated SphinxOS v006e. It uses the serial I/O pins on the prop connected to a PC (via PropPlug or equiv). No video or keyboard in place yet.
Anyone wishing to compile will need to change the hwdef.spin to their hardware. It is at present set to TriBlade (Blade #2) with a 6MHz xtal.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
The dependencies are because there are other programs running behind the scenes. You need to compile and load the latest binary to your SD card as "SPHINX.BIN". When you type "DIR" and enter, a directory will appear (I have used PST for this on the PC) and then it returns to Sphinx.
So you understand what is happening (it got me!!)...
You run SPHINX.BIN and you get the messages and then the SD> prompt.
You type "DIR" followed by Enter. This runs the program on SD called "DIR.BIN".
When DIR is complete, it runs "SPHINX.BIN" which now just displays a quick message followed by the prompt.
@mpark: I am having trouble recompiling DIR. Since the Sphinx will be corrupt (different hardware) on my SD/prop I tried to recompile on the PC. It compiled OK but will not run when copied to the SD. Am I missing something??
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
> You need to compile and load the latest binary to your SD card
What about saving to EEPROM as well?
I did save to eeprom although my preferred method is for the eeprom to only have a minimal boot program in it so that reprogramming is not required.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I've taken a quick peek at some of the new SphinxOS stuff but haven't tried it yet.
I have SphinxOS working with serial I/O to the pc and 1-pin Keyboard & TV concurrently.
However, there are a few issues. Firstly, I am going to need to change the program loader as it clobers the upper hub ram when loading a new binary (like a DIR command) which is where my screen buffer for the 1-pin TV lives. BTW it is 40x25.
The cogs remain running when a new binary is loaded. It is also simple to switch drivers on the fly. So I can have a pc driver doing the output and then switch to the TV driver doing the output. Same with the input from pc or keyboard.
I am using the same drivers (two copies) for the input interface to pc and keyboard, and likewise for the output interface to pc and TV. This means that your code is now removed from the physical driver.
The hardware is also specified in a hx.spin file.
The TV driver has timing issues when you drive it flat out (continuous scrolling) so I have to break it into segments and switch tasks back to the display. Not a major issue and I was expecting this.
I haven't included this code yet as I want to get it working better. It's a bit rough around the edges, if you know what I mean!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Sorry about that. At the time, I was under the impression that I had to clear all hub RAM. My current understanding is that clearing just the var area should suffice.
That is great!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
This version supports 2 sets of terminals, one via serial (to the PC) and the other via 1-pin Keyboard & 1-pin TV. You require an SD interface too. Change the _hwdef.spin to select your hardware. It should work fine on a ProtoBoard with and SD connected. The standard keyboard and TV will work just fine with the 1-pin code·- the unused pins are just ignored. You will get B&W of course.
The other change you may need to do is the OPTION setting in CON in SphinxOS_rr006s.spin.· This sets whether to use the keyboard/tv or the pc for normal Sphinx I/O.
You will also need to follow the directions for installing Sphinx on the SD card. Then you will need to copy the newly compiled·sphinx.bin to the SD card to overwrite the old version.
The TV display currently tears when the screen scrolls fast (as when a DIR is done). I will fix this later.
@mpark: I found a bug in execute in sxfs2.spin where the filesize is checked against 32KB. It needs to also check the c flag. I have changed the load & clear to limit it to 56 * 512 = 28KB so that the upper hub is preserved. No check is made for larger programs so they will react abnormally.
I can now basically change the output device on the fly.
Question:
I have implemented·Standard Input and Standard Output device drivers. They can also be used as Auxilliary I & O drivers. These implement such functions as out, hex, dec, str and in, peek.
This is how I currently do this...
stdout.out("A") 'send character A to the standard output port stdout.dec(x) 'send the decimal characters for value x auxout.out("B") 'send character B to the auxilliary output port c := stdin.in 'get an input character from the standard input port c := auxin.in 'get an input character from the auxilliary input portHowever, if I make the standard I/O routine able to handle multiple I & O devices, I could do...
std.out("A") 'as above to std out port (port1) std.out1("A") 'same as prev line - to std out port (port1) std.out2("B") 'as above to aux out port (port2) std.out3("C") 'to another aux2 port (port2) std.outall("d") 'to all ports !!! c := std.in 'get input char from port1 c := std.in1 'same as prev line c := std.in2 'get input char from port2 c := std.inall 'get input char from any portBy using the second method, it is extremely easy to add a call std.setio(xxxx) to change the input routines on the fly, so your code does not need to cater for this. We can also output to multiple ports concurrently, and receive from any port concurrently.
The reason for having .out and .out1 is that existing programs should be able to run with .out, so probably we should just use out to mean out1.
Another alternative is to use .outx(port, "A") where port is the port number, although we would need to keep .out("A" for the first port to be compatible with existing software.
Any comments or alternative ideas ???
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Post Edited (Cluso99) : 2/22/2010 12:22:56 PM GMT
Looks great!
One minor thing that I noticed was that the "GET" command is in the command parser. If you are wanting to save a few extra longs, GET/PUT commands would be good canditates for utilities (like "DIR" is currently).
Re: Questions
I would recommend going with the [noparse][[/noparse].outx(port, "A")] implementation, over defining .out1, out2, etc., and reserve a port value (possibly 0) for your "all" out/in. If CON's were defined at the top of one's code ("TV_PORT = 1", "SER_PORT_1 = 2") it would make it easier to change the code, or if more ports are added in the future.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
That way, we can replace or update get & put with later versions easily. That is what I liked about Sphinx when I saw it. DIR, ECHO etc were seperate programs, just like CPM was.
Thanks for your feedack [noparse][[/noparse].outx(port, "A")] Unfortunately spin does not allow optional calling parameters so we cannot have a default port. So,we will still need to support .out("A") so it will be compatible with a lot of objects already out there.
re the ports...
I have just needed to add options 2 & 3 because RamBlade only has 2 pins. So it cannot of course have an auxillary port(s).
I would like to remove the _hwdef.spin file into a readable file on the SD card (like CONFIG.SYS) and this could also then have the port configuration in it as well. I am discovering these things as I go, because I am operating two sets of different hardware here... TriBlade and RamBlade. I can of course cater for this with #define, but it makes more sense to be able to configure this without recompiling. Then we can have binaries available which makes things so much easier.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
I also liked having the utilities separated out from the shell when I saw Sphinx.
Supporting .out("A") would be important for what you describe (ease of making an object "Sphinx aware").
Eventually having a CONFIG.SYS would be helpful for interchangability with hardware configurations without having to recompile. Being able to distribute pre-compiled binaries would be nice. Otherwise, it is not that difficult to select the correct configuration in the _hwdef.spin.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Game(s) Mythic Flight
Utilities Font Editors (AIGeneric, Potato_Text, etc.)
I am talking about a simple file transfer mechanism that mpark has done. It is no Xmodem, but it is simple and could be used within any·spin or pasm program, and on programs on the PC end. Before anyone asks, I think we will get an Xmodem Sphinx·program in the future and this can be used with the many full-blown terminal programs out there. Xmodem is quite complex and needs to be standalone in the Sphinx concept, not embedded.
@trodoss: Yes, I think we are fast approaching the need for a CONFIG.SYS so that the binary for Sphinx does not have to change for differing hardware configurations.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
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
Below is a text description of the xmodem protocol and this was all I needed to write xmodem from scratch in vb.net. It is a very simple protocol and would be an extremely handy addition to the growing list of sphinx programs. Pretty much all terminal programs have xmodem.
Possibly the hardest part is the building blocks - open a file, read/write a packet, close the file, find the length of a file.
That was pretty easy in vb.net and ought to be in spin, given the sd card drivers work like this anyway.
And the final bit that took a bit of tweaking was the timeout delays - eg it resends 10 times if a packet gets lost, and gives up after about 10 seconds. You don't want 10 secs to be 0.01 seconds, or 10000 seconds. Just a matter of adjusting some variables.
The xmodem protocol:
Perception presents:
Understanding The X-Modem File Transfer Protocol
by Em Decay
This has to be one of the most internationally accepted protocols for upload-
ing and downloading binary and text files. It is fairly straight-forward as
to how it is set up and there are some error checking capablities.
--- Before you begin ---
Things you need to know beforehand...
The following terms are simply ascii codes:
SOH = chr(1) = CTRL-A =
EOT = chr(4) = CTRL-D = End of Transmission
ACK = chr(6) = CTRL-F = Positive Acknowledgement
NAK = chr(21) = CTRL-U = Negative Acknowledgement
CAN = chr(24) = CTRL-X = Cancel
In order to send the file, you must first divide it into 128 byte sections
(packets). Bytes 0-127 of the file make up the first packet, bytes 128-255
make up the second packet, etc.
The packet number sent is simply the number of the packet. If the packet
number is greater than 255, then subtract 256 repeatly until the number is
between 0 and 255. For example, if you were sending packet 731, then you
would send 731 - 256 - 256 = 219.
The 1's complement of a byte (to make life easy) is simply 255 minus the
byte. For example, if you had to take the 1's complement of 142, the answer
would be 255 - 142 = 133.
The checksum is the value of all the bytes in the packet added together. For
example, if the first five bytes were 45, 12, 64, 236, 173 and the other 123
bytes were zeroes, the checksum would be 45+12+64+236+173+0+0+...+0 = 530.
However, to make each block one byte smaller, they repeatly subtract 256
from the checksum until it is between 0 and 255. In this case, the checksum
would be 530 - 256 - 256 = 18.
The first byte the downloader sends is referred to as the NCGbyte.
Provided that you aren't lost already, here is what happens next. The steps
below describe who sends what when [noparse]:)[/noparse]
--- The Actual Transfer ---
The uploader waits until the downloader sends a NAK byte. The NAK byte
is the signal that the downloader is ready to start. This byte is referred
to as the NCGbyte. If the downloader takes too long or an error occurs then
the uploader will stop waiting or "Time Out". If this happens, then the
file transfer must restart.
With each packet sent...
The uploader sends:
1. an SOH byte {1 byte}
2. the packet number {1 byte}
3. the 1's complement of the packet number {1 byte}
4. the packet {128 bytes}
5. the checksum {1 byte}
The above five things are called the block.
The downloader:
1. ensures that the packet number sent matches the actual packet number
that it is (If the third block send has a '4' as the second byte,
something is wrong --> CANCEL TRANSFER (send CAN byte))
2. adds the packet number and the 1's complement of it together to make
sure that they add up to 255. if they don't --> CANCEL TRANSFER
3. adds up all the bytes in the packet together --> THE SUM
4. compares the last two significant digits of THE SUM with the checksum
5. if everything looks ok (sum=checksum), then the downloader appends the
bytes in the packet to the file being created (sent). The down-
loader then sends an ACK byte which tells the uploader to send the
next block.
if the sums do not match then the downloader sends an NAK byte which
tells the uploader to send the same block it just sent over again.
When the uploader sends an EOT byte instead of an SOH byte, the downloader
sends a NAK byte. If the uploader sends another EOT immediately after that,
the downloader sends an ACK byte and the transfer is complete.
Another thing, the downloader can cancel the transfer at any time by sending
a CAN byte. The uploader can only cancel between blocks by sending a CAN
byte. It is recommended that you send anywhere between 2 and 8 consecutive
CAN bytes when you wish to cancel as some programs will not let you abort if
only 1 CAN byte is sent.
--- Wrap Up ---
Hopefully, you were able to follow along. [noparse]:)[/noparse] If not, you can e-mail me at
em_decay@norlink.net and I will try to clarify it for you. Have fun [noparse]:)[/noparse]
Perception: Em Decay -- Mark Korhonen
Cmf
Chris Fillion
Written on Dec.28/95
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
www.smarthome.viviti.com/propeller