Re: Virtual serial drive

[Michael J. Mahon <mjmahon@aol.com>]

David Schmidt <schmidtd@my-deja.com> wrote:
> 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!


I figured you already had a code path for "checksum OK", so no additional
path would be necessary. 

> 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.

Very nice!

-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahon