Omnimaga
Calculator Community => Discontinued => Major Community Projects => KnightOS => Topic started by: SirCmpwn on November 28, 2010, 08:55:53 pm
-
Hello,
Please review and discuss this document:
-
The end of the "handshake" and the start of the transfer require different line states. Since both lines have to be pulled low, shouldn't that just be part of the handshake?
-
No, because the lines are pulled low by a different calculator.
-
This might be a stupid question, but how does this third calculator connect to the other two if the sending and receiving calculators are connected by a cable?
-
No, it is done by the sending calculator. They need to be aware of when each one is ready. Keep in mind that the transfer portion of the protocol loops.
-
Okay, that makes more sense.
-
Looks really complicated. I didn't check your math, but it sounds pretty good. Why does this repeat 4 times though? What speeds can you get? When can I discuss usb with you?
-
It repeats four times per byte because I can only send two bits at a time.
-
It repeats four times per byte because I can only send two bits at a time.
Oh, that's right. That's the whole shifting mess. Okay, I get it.
-
But, this protocol doesn't work at all because "pulling the lines high" is not possible. You can stop holding the lines low, but you cannot force them high if the other calc is holding them low.
-
But, this protocol doesn't work at all because "pulling the lines high" is not possible. You can stop holding the lines low, but you cannot force them high if the other calc is holding them low.
Oh, that's because of the pull-up resistors, isn't it. Forgot about that.
-
What do you mean by "holding them low?". I thought that both sides read the last value written on either side. If that is true, that is all that really matters, no?
-
What do you mean by "holding them low?". I thought that both sides read the last value written on either side. If that is true, that is all that really matters, no?
My guess is that one calc is going to have to mess with one line, and the other, with the other. So calc A messes with Line A and calc B with line B.
-
I thought I made this clear on IRC. If either calculator is holding the line low, the line is low. If neither is holding it low, the line is high. The calculator will continue to hold a line low until you tell it to release.
-
Okay, so I write 1 to port 0 and it stays that way until I write 0?
-
Correct. In fact, bits 4 and 5 of input from port 0 read the last bits you wrote to 0 and 1.
Edit:
In general, if A is the last value written to the port on one calc and B is the last value written to the port on the other calc, the read value from bits 0 and 1 on both calcs is (~A & ~B), or ~(A | B), whichever you like better.
-
Thank you for the help. I will revise the protocol with this in mind later.
-
Did you ever finish this protocol? Is there a revised document up somewhere?
-
Yes, but I've long lost it. The protocol doesn't apply to USB, though, and I have to think of a better way to do it asyncronously. CalcNet may also be ported.
-
I think you should be able to simply have one line be the clock and the other be the actual data. That seems very fast in my opinion. You could have the calcs fight over control, or you could have packets with a request to send or something. I guess you would just have to know which one did the clock and who was supposed to be reading.
-
Graph, the clock and data line setup you suggest is the basis of what I2C uses. Only problem with I2C is that the standardized speeds are too high for our calcs. :(
A slowed-down version would be feasible, though.
-
Yay for the calcnet support! I wonder if Axe could get ported too :P not likely, unless you recreate all the bcalls, right?
-
No, Quigibo has expressed interest in porting Axe. And TI-Basic support is planned.
-
Major necropost I know, but I was bored so I made up a File Format for the computer that KOS could use.
-
Thanks Binder News, but the great thing about KOS is that you don't need to define a file format - you could transfer any file whatsoever to your calculator as if it were a flash drive.
-
Really? That is pretty cool. Well, I'm still waiting for the main release... :)
-
I am presently unable to work on it, but I promise I'll get more progress as soon as I can.
-
That's sad that you can't work on int, but I hope you will be able to soon.
-
Thanks Binder News, but the great thing about KOS is that you don't need to define a file format - you could transfer any file whatsoever to your calculator as if it were a flash drive.
Is that planned, or already finished? I need to work on that, since I can't work on TAO, atm. (Technically I am working on it, just not coding the massive amounts of USB fun stuff.)
-
Well, the ability to have any file is done, but the flash drive interface is planned.
-
In other words, guys, with KOS, think of your calc as a TI-Nspire when it comes to file formats. You could even send Gameboy ROMs without converting them. (Although I don't know if a TI-Boy SE version with a ROM menu and the emu not integrated in each ROM would be easier or harder)
-
Actually, TI-Boy for KnightOS would be great, and would probably allow user's without extra RAM pages to enjoy the same great games.
And you can transfer anything you like. Download this page as an HTML file and send it to KnightOS if you want.
-
Btw, is there any format you would like? Is the FLASH+RAM memory all under 2GB?
-
Well under. It's just under 2MB for calculators with missing RAM, and just over for those with. However, I refuse to include any code whatsoever that requires use of the entire calculator's memory. And KFS is already a well thought out format that I will be using.
-
Well under. It's just under 2MB for calculators with missing RAM, and just over for those with. However, I refuse to include any code whatsoever that requires use of the entire calculator's memory. And KFS is already a well thought out format that I will be using.
Excellent. I look forward to getting the protocol information. And the code shouldn't use the entire calcs memory. I can't remember from the specs, but I'm thinking a little over 200 bytes of RAM to use, and then whatever the USB code takes. I'll try and get some test thing working later. I'll still need the Filesystem to do for KOS, but I'll go use one of the earlier file revisions that you've posted or something.
-
I can easily give 200 bytes of RAM to the cause. However, here's what you should know about making/reading files (preliminary):
All error codes for these routines are returned in L. I'll let you know when I get definitive values.
To open a read stream:
ld hl, FileName ; File name, including directory, such as "/os/boot.kxe"
call OpenStream ; Returns a stream ID in A. Use this to pass into ReadStream
call ReadStream ; Takes A = stream ID, returns B is next byte
call SeekStream ; Takes A = stream ID, takes BCH = location in stream (24-bit (0xFFFFFF is EoF))
call FileInfo ; Takes A = stream ID, returns size in BCH (other details to be added later)
call CloseStream ; Takes A = stream ID
To open a write stream:
ld hl, FileName ; Filename is the full name
call CreateFile ; Takes HL is file name, returns stream ID in A
call WriteStream ; Takes A is stream ID, B is value to write
call SeekStream ; See above
call CloseStream ; See above
-
I might say, that is fairly well thought out. However, with the flash Chip, are you going to make it where files can be fragmented? So that way, you don't have to move stuff around a whole lot and writes are faster?
-
Why do you think I'm using streams instead of letting programs handle it on their own? ;)
-
Why do you think I'm using streams instead of letting programs handle it on their own? ;)
Ohhh... I thought you loved Java so much that you wanted to imitate it. j/k
That makes sense. Slightly more difficult for the routine I had in mind, but yes, that should work.
-
That's not a Java standard :P that's a computing standard.
-
That's not a Java standard :P that's a computing standard.
Oh, I know. I was just messing with you. Send all complaints to /dev/null. :)
-
KnightOS doesn't have /dev/null :D
-
KnightOS doesn't have /dev/null :D
lol, it should. And /dev/random, and such. Does it have a /dev folder? That would be useful for... stuff.
-
No, it doesn't. There is little point. The random generator is built into the kernel, and it updates the seed every interrupt.
-
But does it have any kind of folders at all? In other words, how is the KOS Filesystem organized? (maybe i missed a thread about this?)
Oh yea as for the protocol, did you revise it already?
-
It has folders, yes.
And I have yet to revise the protocol, but I will soon. It won't cover USB, though.