Re: Virtual serial drive

[BLuRry <brendan.robert@gmail.com>]

Holy cow, I'll take two of those please!

-B

On Monday, September 17, 2012 9:35:23 AM UTC-5, David Schmenk wrote:
> 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...