On 9/14/2012 2:21 PM, Michael J. Mahon wrote:
David Schmidt <schmidtd@my-deja.com> wrote:On 9/14/2012 1:35 PM, Michael J. Mahon wrote:David Schmidt <schmidtd@my-deja.com> wrote:On 9/13/2012 6:19 PM, Sean Fahey wrote:On Thursday, September 13, 2012 1:34:20 PM UTC-5, Michael J. Mahon wrote:Be careful--the next logical step is having your IIc just be a terminal for an emulator running on the PC. And the serial link is too slow for graphics! I do like the idea of getting the time/date with each vdisk access...Well... let's toy with this idea. Why not a small form factor machine, like a Raspberry Pi or similar mini 'PC' that could provide HD partitions (and/or disk serving), clock functions (at least date and time stamping) and serial to ethernet connectivity at the same time? That's the kind of love the //c (and IIc+) could benefit from. Until the SPVHD is shipping again (it's supposed to be getting a clock driver too), a serial solution may be the only viable option for a long time.Is there a protocol for transporting the date/time somewhere I can look at? Is there maybe a status request I can implement or something?I'd suggest putting it into every vdisk protocol packet from the host in 4-byte ProDOS format. Then the client could just copy it to the ProDOS global page.That's straightforward. Does it have to be every disk access - or could it happen at initialization time and be done?Ideally every block read. Then the time-date stamps would all be accurate to the second, and any program wanting the info could just pick it up from the global page. I suppose the frequency of transferring the date bytes could be reduced, but it's only two bytes--and then there's the conditional code to deal with midnight,,, Better to keep it trivial. ;-)
Ok, I implemented a protocol change that sets the date/timestamp on every block read. Works quite nicely, as you suggested. I'm not going to re-benchmark, because I again don't want to know. :-) there's some more code going on - more checksum computation, more conditionals (only update time when checksums match), so it'll be a little slower. But it's a pretty neat feature to have. Good job, all!
Oh, and I fixed the processor status bit pollution I was getting on the Uthernet side. Your medical and financial records are once again as safe on UDP as they are on Serial. Which is to say not very. ;-)
You'll get these updates on the next release, which may be next year, or may be next weekend. Let's see what else you come up with.