Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.sys.apple2.programmer > #2550 > unrolled thread

Project: 6th Edition Unix for the Apple IIe/IIc

Started bywssimms@gmail.com
First post2016-03-20 01:12 -0700
Last post2016-03-31 00:24 +0000
Articles 20 on this page of 28 — 8 participants

Back to article view | Back to comp.sys.apple2.programmer


Contents

  Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 01:12 -0700
    Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 01:17 -0700
      Re: Project: 6th Edition Unix for the Apple IIe/IIc Michael Pohoreski <michael.pohoreski@gmail.com> - 2016-03-20 10:59 -0700
        Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-20 19:10 +0000
          Re: Project: 6th Edition Unix for the Apple IIe/IIc remygibert63@gmail.com - 2016-05-09 07:14 -0700
      Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-30 12:04 -0700
    Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-20 19:14 +0000
      Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 12:29 -0700
        Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-20 19:34 +0000
          Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 12:48 -0700
        Re: Project: 6th Edition Unix for the Apple IIe/IIc Oliver Schmidt <ol.sc@web.de> - 2016-03-21 16:05 +0000
      Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 12:38 -0700
        Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-20 20:39 +0000
          Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 19:03 -0700
            Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-21 02:41 +0000
              Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 21:12 -0700
              Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 21:17 -0700
                Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-21 04:20 +0000
                  Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-21 02:57 -0700
            Re: Project: 6th Edition Unix for the Apple IIe/IIc Michael J. Mahon <mjmahon@aol.com> - 2016-03-21 01:40 -0500
        Re: Project: 6th Edition Unix for the Apple IIe/IIc Andy McFadden <thefadden@gmail.com> - 2016-03-20 13:45 -0700
          Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-20 18:55 -0700
    Re: Project: 6th Edition Unix for the Apple IIe/IIc Nicola <nvitacolonna@gmail.com> - 2016-03-25 07:52 +0200
      Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-25 01:38 -0700
        Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-30 18:29 +0000
          Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-30 11:55 -0700
            Re: Project: 6th Edition Unix for the Apple IIe/IIc wssimms@gmail.com - 2016-03-30 12:34 -0700
            Re: Project: 6th Edition Unix for the Apple IIe/IIc D Finnigan <dog_cow@macgui.com> - 2016-03-31 00:24 +0000

Page 1 of 2  [1] 2  Next page →


#2550 — Project: 6th Edition Unix for the Apple IIe/IIc

Fromwssimms@gmail.com
Date2016-03-20 01:12 -0700
SubjectProject: 6th Edition Unix for the Apple IIe/IIc
Message-ID<f0dafd35-586f-4881-8cbe-0109e030a5a0@googlegroups.com>
I've decided to reveal my project, for two reasons:

1) I want to share some things I am doing, but I can't both share and
   keep my project under wraps
2) I feel pretty confident I will finish the project. Fear that I
   would abandon it midstream is the main reason I have keep quiet so
   far.

I am porting 6th Edition Unix to the Apple IIe. I plan to port
everything: kernel, filesystem, and all of userland, including C,
Fortran, dc, nroff, etc.

I have chosen to port 6th Edition because it is quite a bit smaller
than 7th Edition and doesn't rely so heavily on the C compiler. 7th
Edition has major components such as the bourne shell, make, troff
written in C whereas 6th edition still has a lot of assembler code.
Furthermore, the 7th Edition kernel is probably almost twice the size
of the 6th Edition kernel.

The porting method I have chosen is to rewrite the 6th Edition kernel
in 65c02 assembler. User programs will be either rewritten in
assembler or compiled with the C compiler when it is working. I am
open to the idea of recompiling the legacy C kernel for 65c02, but
it will require an advanced optimizing pass for the compiler.

The current state of the project is as follows:

- I have mostly rewritten the 6th Edition Unix file system code in
  65c02 assembler, but it is not currently in working condition.

- I have modified pass 1 of the Dennis Ritchie's 6th Edition C
  compiler to remove PDP-11 dependencies and to produce output
  amenable to optimization. (Ritchie's compiler is almost completely
  non-optimizing). I considered the possibility of trying to use some
  other C compiler, but I don't there there are any that implement
  the ancient 6th Edition version of C, or can be hosted on an
  Apple IIe.

- I have written a compatibility layer that implements almost all
  of the 6th Edition system calls on top of ProDOS. This code provides
  a working environment for userland work. It does not provide
  time sharing, but it does allow the use of the fork and exec
  system calls to chain programs together.

- I have written a simple shell. The Unix compatibility layer is
  now complete enough to run the actual 6th Edition Unix shell (the
  thompson shell), but I haven't ported that over yet.
 
- I have ported the 5th Edition Unix version of ed. It is feature
  complete and works well. I chose to port the 5th Edition version
  of ed because it is written in PDP-11 assembler and I find it easier
  to rewrite assembler code than to hand-compile C code. The plan is
  to switch over to the 6th Edition Unix ed when the C compiler is
  working.

- I have ported various other utilities that I find useful such as
  cp, cat, od, tr

- I am deep into the port of the Unix assembler. Pass 1 is complete.
  As expected, I ended up having to completely rewrite (rather than
  just translate) most of it, because of the differences between
  the PDP-11 and the 65c02, but the organization is quite similar to
  the Unix assembler and it retains the same flavor

Plans for the near future:

- Finishing the assembler is my #1 priority right now. I estimate it
  will be working before the end of April.

- After finishing the assembler I will port the 6th Edition Unix
  shell and support programs such as glob. After this, I will
  publically release the Unix compatibility environment. I expect
  this release to occur in June.

- After the release of the Unix compatibility environment, I will go
  all-in on the kernel. I expect the filesystem to be up around the same
  time I release the compatibility environment. The rest of   the kernel
  will probably take a couple of months to get going, so I'm expecting
  to first run a full Unix kernel in the early fall. As soon as I have
  a basic functional system, I will make a public release.

- After that, I will be working on userland until it is done, while
  fixing bugs.

Possible FAQ answers:

- I am not interested in using the ProDOS filesystem as the Unix
  filesystem. The compatibility layer provides a Unix-lite
  experience on top of ProDOS.

- I am not particularly concerned about using floppy disks with
  Unix. It can be done of course, but it won't be a great experience
  because of the need to disable interrupts for a long period of time.

- Yes I expect this port of 6th Edition Unix to the Apple IIe to
  provide a full multi-user, time sharing system, functionally
  identical to a PDP-11 running 6th Edition Unix, within the limits
  of what is physically possible.

- I am calling it Unix, because it is a direct rewrite/port of the
  original 6th Edition Unix source code. If you don't think I should
  call it Unix, you can call it Charles. I will continue to call it
  Unix.

[toc] | [next] | [standalone]


#2552

Fromwssimms@gmail.com
Date2016-03-20 01:17 -0700
Message-ID<ebd7bba4-d089-4ded-98b6-929f04db119a@googlegroups.com>
In reply to#2550
On Sunday, March 20, 2016 at 5:12:36 PM UTC+9, wss...@gmail.com wrote:
> I've decided to reveal my project, for two reasons:

https://youtu.be/OdVGZLiiUjw

[toc] | [prev] | [next] | [standalone]


#2554

FromMichael Pohoreski <michael.pohoreski@gmail.com>
Date2016-03-20 10:59 -0700
Message-ID<de9df09d-b97d-47a7-993e-86a5c3a13462@googlegroups.com>
In reply to#2552
On Sunday, March 20, 2016 at 1:17:01 AM UTC-7, wss...@gmail.com wrote:
> On Sunday, March 20, 2016 at 5:12:36 PM UTC+9, wss...@gmail.com wrote:
> > I've decided to reveal my project, for two reasons:
> 
> https://youtu.be/OdVGZLiiUjw

Awesome!!

Seems like OS's are popular this year.  Whoops. Said too much. :)

[toc] | [prev] | [next] | [standalone]


#2557

FromD Finnigan <dog_cow@macgui.com>
Date2016-03-20 19:10 +0000
Message-ID<dog_cow-1458501235@macgui.com>
In reply to#2554
Michael Pohoreski wrote:
> On Sunday, March 20, 2016 at 1:17:01 AM UTC-7, wss...@gmail.com wrote:
>> On Sunday, March 20, 2016 at 5:12:36 PM UTC+9, wss...@gmail.com wrote:
>> > I've decided to reveal my project, for two reasons:
>> 
>> https://youtu.be/OdVGZLiiUjw
> 
> Awesome!!
> 
> Seems like OS's are popular this year.  Whoops. Said too much. :)
>

Yeah, someone else is working on a multitasking OS with a TCP/IP stack too.

(not me)

[toc] | [prev] | [next] | [standalone]


#2713

Fromremygibert63@gmail.com
Date2016-05-09 07:14 -0700
Message-ID<4874cda6-013d-4f05-bdbe-3d4e0d629686@googlegroups.com>
In reply to#2557
Le dimanche 20 mars 2016 20:13:56 UTC+1, D Finnigan a écrit :
> Michael Pohoreski wrote:
> > On Sunday, March 20, 2016 at 1:17:01 AM UTC-7, wss...@gmail.com wrote:
> >> On Sunday, March 20, 2016 at 5:12:36 PM UTC+9, wss...@gmail.com wrote:
> >> > I've decided to reveal my project, for two reasons:
> >> 
> >> https://youtu.be/OdVGZLiiUjw
> > 
> > Awesome!!
> > 
> > Seems like OS's are popular this year.  Whoops. Said too much. :)
> >
> 
> Yeah, someone else is working on a multitasking OS with a TCP/IP stack too.
> 
> (not me)

Hello All,

i may be the "someone" form France...or not..but if yes,

Thanx to David to talk about it!

visit : https://github.com/burniouf/A2osX

development appears to be a bit ... lazy, because a MAJOR kernel rewrite is in progress, and not yet commited...to many modifications here and there.

TCP stack is working, i did not take the direction to use Uthernet II "embedded TCP stack" because it appears to me much more like a limitation....i prefer more "general purpose" sockets available.
 btw, i'm working in a "hybrid mode" for U2 with IP RAW. 
(eh David, look at the latest "ultimate optimized U2 Mac RAW Driver" at GitHub ;-)

the main guideline for A2osX is NOT to implement "state of the art" Unix API, like berkeley Sockets, etc...but to implement simplified subsets that is enough to write applications on this platform, in other words, just enough to write HTTPD or NFSD, TELNETD...but seriously, is there any practical interest to implement all TCPIPv6 functionalities in a 8bit Apple II?
another example : i choosed to write a simplified Editor instead of porting vi,that's enough to edit few etc/.conf files...

Multitasking is implemented as "collaborative", code is relocated "on the fly" by kernel (on top of ProDOS 2.0.3, loaded in AUX LC)

to system I/O "freeze" during Disk ][ I/Os, a system like the old MSDOS SMARTDRIVE is currently investigated...

...and many other things...

idea behind this project was to collect all pieces of code here and there in the same distribution, to avoid having a disk for TCPIP, another one for a GUI, another one for .... formatting a diskette....for printing...etc...
 

next objective is to finish moving kernel to next version of its file I/O API to finish implementing NFS Client....

sorry for my poor english.

Thanx,
Rémy

[toc] | [prev] | [next] | [standalone]


#2616

Fromwssimms@gmail.com
Date2016-03-30 12:04 -0700
Message-ID<9626fa5b-f346-443a-a8c6-a3002ad03e92@googlegroups.com>
In reply to#2552
On Sunday, March 20, 2016 at 5:17:01 PM UTC+9, wss...@gmail.com wrote:
> On Sunday, March 20, 2016 at 5:12:36 PM UTC+9, wss...@gmail.com wrote:
> > I've decided to reveal my project, for two reasons:
> 
> https://youtu.be/OdVGZLiiUjw

Here is my second video demonstration. I want to be clear that what is being demonstrated here is not yet Unix, but rather a Unix compatibility layer that uses Prodos for file I/O. It is considerably more limited than Unix will be, but provides a comfortable environment for porting user programs before Unix is ready. I have included the explanation text from the Youtube video below the link.

Also, in this video I am running Virtual ][ at the 1Mhz setting, so it gives a good indication of the speed to be expected on a real Apple IIe (assuming the real Apple IIe has a reasonably fast mass-storage device)


https://youtu.be/GK2RMh7wpjQ


This is another demonstration of my Unix Compatibility Layer for Apple IIe and Apple IIc computers. In this video, I am demonstrating multiple processes being chained together with the use of the fork and exec system calls.

When the UCL is started, a very simple init program is run by the UCL kernel and init runs a shell. When the original shell created by init exits, then init also exits, which causes the UCL kernel to execute the Prodos QUIT MLI call.

Up to 15 processes can be alive at the same time, although only one is memory resident at any given time. Non-running processes are written out to files and then loaded back in when it is their turn to run.

There is currently no timer interrupt, so processes tend to run in a stack-like manner (i.e. a child process runs to completion, then returns to its parent). It is, however, possible for a process to voluntarily give up the CPU by executing the following sequence:

        sys     fork
        sys     exit
        sys     wait

The child process runs first and immediately exits, the scheduler then picks another process to run, which will probably not be the parent. When the parent eventually runs again, it will call wait, which will find and clear out the zombie child and then immediately return.

[toc] | [prev] | [next] | [standalone]


#2558

FromD Finnigan <dog_cow@macgui.com>
Date2016-03-20 19:14 +0000
Message-ID<dog_cow-1458501486@macgui.com>
In reply to#2550
wssimms wrote:
> 
> I am porting 6th Edition Unix to the Apple IIe. I plan to port
> everything: kernel, filesystem, and all of userland, including C,
> Fortran, dc, nroff, etc.
> 
> 
> Possible FAQ answers:
>

Ok, here are my FAQs:

1.) Are you using a RAMWorks card?

2.) Will we be able to attach terminals with a Super Serial Card?

[toc] | [prev] | [next] | [standalone]


#2559

Fromwssimms@gmail.com
Date2016-03-20 12:29 -0700
Message-ID<3ae97da7-fc69-4b0f-a7e4-e9b7bd4b2d27@googlegroups.com>
In reply to#2558
Yes, the Ramworks card will be supported but not necessary.
Most existing Unix programs will probably require about 16k
or less and the system will swap as necessary.

Yes, any number of serial cards will be supported. I will
probably also support multiplexing several terminal sessions
over one serial card, although that will require some external
assistance in the form of some sort of multiplexer. A raspberry
pi or such would be a good candidate to receive multiple
telnet connections and multiplex them onto a single
serial card.

Lastly, there is no TCP/IP stack in 6th Edition Unix.
There is, in fact, no networking whatsoever. UUCP
first appeared in 7th Edition unix

[toc] | [prev] | [next] | [standalone]


#2560

FromD Finnigan <dog_cow@macgui.com>
Date2016-03-20 19:34 +0000
Message-ID<dog_cow-1458502662@macgui.com>
In reply to#2559
wssimms wrote:
> Yes, the Ramworks card will be supported but not necessary.
> Most existing Unix programs will probably require about 16k
> or less and the system will swap as necessary.
> 

Only one program will be resident in RAM at a time? 

[toc] | [prev] | [next] | [standalone]


#2562

Fromwssimms@gmail.com
Date2016-03-20 12:48 -0700
Message-ID<c956f6bf-b165-4e1f-983c-732b8668bce2@googlegroups.com>
In reply to#2560
Not at all. A basic 128k system should support 4-8 resident programs at a time. It depends somewhat on how big the
kernel is and of course how big the user programs are.

However the standard 6th Edition userland consists of
very small, very memory-stingy programs. They were
originally written for a 16-bit machine with 128k-256k
core memory after all.

For example, the tr I posted is about 2k, ed is about 8k,
as pass 1 is about 14k (most of that is symbol table),
etc.

The biggest program I could imagine wanting to port
over (although it is not a 6th edition program) is vi --
that might be difficult to fit. It barely fit on a PDP-11
back in the day, although I'm not sure how big a segment
BSD 2 was providing.

[toc] | [prev] | [next] | [standalone]


#2578

FromOliver Schmidt <ol.sc@web.de>
Date2016-03-21 16:05 +0000
Message-ID<ncp63u$jak$1@news.albasani.net>
In reply to#2559
Hi,

> Yes, any number of serial cards will be supported. I will
> probably also support multiplexing several terminal sessions
> over one serial card, although that will require some external
> assistance in the form of some sort of multiplexer. A raspberry
> pi or such would be a good candidate to receive multiple
> telnet connections and multiplex them onto a single
> serial card.

In case one wants to avoid that "external assistane" one might want to
consider an Uthernet II card. It comes with its own TCP/IP stack and allows
for four incoming TCP connections. So the only thing missing to allow up to
four Telnet clients to log in would be some Telnet IAC handling.

One might want to look at
https://github.com/a2retrosystems/mxp/blob/master/w5100/demo/tcp.s to see
how large (or rather how small) code doing TCP with the Uthernet II is.

Regards,
Oliver

[toc] | [prev] | [next] | [standalone]


#2561

Fromwssimms@gmail.com
Date2016-03-20 12:38 -0700
Message-ID<7c2362f5-0887-4601-8dce-e40a5a0cffc1@googlegroups.com>
In reply to#2558
One other thing regarding multiuser operation.
Although Unix will fully support multiuser operation,
the lack of segmentation hardware means that
anyone trying to do development work in a shared
system risks catastrophically bringing the system
down in a way that would be very unkind to the other
users.

If anyone wants to develop a card that offers basic
basic segmentation registers I'm all ears. (Might as
well put a programmable interrupt source and RTC
on there too while you're at it so a mouse and/or
clock card aren't absolutely necessary.)

[toc] | [prev] | [next] | [standalone]


#2565

FromD Finnigan <dog_cow@macgui.com>
Date2016-03-20 20:39 +0000
Message-ID<dog_cow-1458506554@macgui.com>
In reply to#2561
When you eventually move beyond ProDOS, will you write your own disk driver
that interfaces with any SmartPort device?

[toc] | [prev] | [next] | [standalone]


#2570

Fromwssimms@gmail.com
Date2016-03-20 19:03 -0700
Message-ID<df6d79c2-18dd-4552-b002-7d42250ec0e6@googlegroups.com>
In reply to#2565
Yes. In fact I have already written it.

Unfortunately smartport isn't really fantastic since, as far as I
know, it is completely synchronous. The disk packs used
on the PDP-11 were very slow, but at least you had DMA and
disk interrupts. I think the ideal mass storage device for Unix
on the Apple IIe is probably a DMA capable sdcard drive or
something like that. But it will just have to turn off interrupts
and take what it gets.

[toc] | [prev] | [next] | [standalone]


#2571

FromD Finnigan <dog_cow@macgui.com>
Date2016-03-21 02:41 +0000
Message-ID<dog_cow-1458528268@macgui.com>
In reply to#2570
wssimms wrote:
> Yes. In fact I have already written it.
> 
> Unfortunately smartport isn't really fantastic since, as far as I
> know, it is completely synchronous. The disk packs used
> on the PDP-11 were very slow, but at least you had DMA and
> disk interrupts. 

That's the same problem I encountered when I was designing a Unix system for
Apple IIe back in 2010. And doubtless the same problem others had when they
also designed Apple Unix systems in 1990.


> I think the ideal mass storage device for Unix
> on the Apple IIe is probably a DMA capable sdcard drive or
> something like that. But it will just have to turn off interrupts
> and take what it gets.

Hum-ho. I wonder how many years it will be until we get an interrupting,
DMA-capable solid-state disk for the Apple II.

We just got an interrupting Ethernet card last year, so miracles do
happen… :-)

-- 
]DF$
The Marina IP stack for Apple II--
http://marina.a2hq.com/

[toc] | [prev] | [next] | [standalone]


#2572

Fromwssimms@gmail.com
Date2016-03-20 21:12 -0700
Message-ID<ef34b3b8-da32-4eaa-af0d-1f4e000bd713@googlegroups.com>
In reply to#2571
On Monday, March 21, 2016 at 11:44:30 AM UTC+9, D Finnigan wrote:
> wssimms wrote:
> > Yes. In fact I have already written it.
> > 
> > Unfortunately smartport isn't really fantastic since, as far as I
> > know, it is completely synchronous. The disk packs used
> > on the PDP-11 were very slow, but at least you had DMA and
> > disk interrupts. 
> 
> That's the same problem I encountered when I was designing a Unix system for
> Apple IIe back in 2010. And doubtless the same problem others had when they
> also designed Apple Unix systems in 1990.

Back in the 80s and 90s it was a real problem for two reasons:
1) The intent would have been to produce a production OS
2) the disks were really slow.

Nowadays even without DMA, a solid-state drive is low-latency enough
that I don't expect disk latency to be a significant problem. The Unix
buffer cache will also help reduce latency issues, especially in the usual
case where the system isn't hosting more than 1 or 2 users.

[toc] | [prev] | [next] | [standalone]


#2573

Fromwssimms@gmail.com
Date2016-03-20 21:17 -0700
Message-ID<7fe6e8a2-00d4-418f-a991-d5d28b54eb49@googlegroups.com>
In reply to#2571
On Monday, March 21, 2016 at 11:44:30 AM UTC+9, D Finnigan wrote:
> Hum-ho. I wonder how many years it will be until we get an interrupting,
> DMA-capable solid-state disk for the Apple II.
> 
> We just got an interrupting Ethernet card last year, so miracles do
> happen... :-)

I should add that a DMA-capable solid state disk probably wouldn't need to
interrupt. After all, there's no rotational or seek latency, and DMA should
keep transfer latency under a millisecond.

[toc] | [prev] | [next] | [standalone]


#2574

FromD Finnigan <dog_cow@macgui.com>
Date2016-03-21 04:20 +0000
Message-ID<dog_cow-1458534236@macgui.com>
In reply to#2573
wssimms wrote:
> On Monday, March 21, 2016 at 11:44:30 AM UTC+9, D Finnigan wrote:
>> Hum-ho. I wonder how many years it will be until we get an interrupting,
>> DMA-capable solid-state disk for the Apple II.
>> 
>> We just got an interrupting Ethernet card last year, so miracles do
>> happen... :-)
> 
> I should add that a DMA-capable solid state disk probably wouldn't need to
> interrupt. After all, there's no rotational or seek latency, and DMA
> should
> keep transfer latency under a millisecond.
>

Good point. Next question: how long have you been working on this project so
far? :-)

(At least since February 13th, I see…)

[toc] | [prev] | [next] | [standalone]


#2577

Fromwssimms@gmail.com
Date2016-03-21 02:57 -0700
Message-ID<93a4e404-cd84-4e20-b591-92d516110482@googlegroups.com>
In reply to#2574
On Monday, March 21, 2016 at 1:23:58 PM UTC+9, D Finnigan wrote:
> wssimms wrote:
> > On Monday, March 21, 2016 at 11:44:30 AM UTC+9, D Finnigan wrote:
> >> Hum-ho. I wonder how many years it will be until we get an interrupting,
> >> DMA-capable solid-state disk for the Apple II.
> >> 
> >> We just got an interrupting Ethernet card last year, so miracles do
> >> happen... :-)
> > 
> > I should add that a DMA-capable solid state disk probably wouldn't need to
> > interrupt. After all, there's no rotational or seek latency, and DMA
> > should
> > keep transfer latency under a millisecond.
> >
> 
> Good point. Next question: how long have you been working on this project so
> far? :-)
> 
> (At least since February 13th, I see...)

I started on the compatibility layer in December, 2014, but there have been a couple of lengthy pauses due to various things intruding on my time. Most of the work has been done in the last 4-5 months.

[toc] | [prev] | [next] | [standalone]


#2576

FromMichael J. Mahon <mjmahon@aol.com>
Date2016-03-21 01:40 -0500
Message-ID<SZ6dnTS6yeTcCnLLnZ2dnUU7-VVQAAAA@giganews.com>
In reply to#2570
<wssimms@gmail.com> wrote:
> Yes. In fact I have already written it.
> 
> Unfortunately smartport isn't really fantastic since, as far as I
> know, it is completely synchronous. The disk packs used
> on the PDP-11 were very slow, but at least you had DMA and
> disk interrupts. I think the ideal mass storage device for Unix
> on the Apple IIe is probably a DMA capable sdcard drive or
> something like that. But it will just have to turn off interrupts
> and take what it gets.
> 

Yes, the Apple II has essentially no I/O concurrency. 

DOS and ProDOS only work if each I/O operation is completed in order and
before proceeding. That no doubt accounts for the scarcity of DMA disk
controllers, and, when DMA is used, it only replaces a software copy loop. 

The concept of I/O queueing and overlap is completely missing from the
Apple's OSs. 

It's one of the reasons that NadaNet integrates easily with the Apple. ;-)

Now, UNIX could support some *real* I/O, given proper hardware...  ;-)
-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]


Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.sys.apple2.programmer


csiph-web