Re: Virtual serial drive

[David Schmenk <dschmenk@gmail.com>]

On Sunday, September 16, 2012 7:02:30 PM UTC-7, schmidtd 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!
> 
> 
> 
> 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.

Since you're on a roll, here, I'd like to add some feature requests:

Get kid ready for school in the morning & take dogs out for their "business".  This would make ADTPro the true jack-of-all-trades in my opinion.  In fact, you could probably charge for such additions.  Can you get these in the next version?  Thanks!

Dave...