Fixing XINU for Apple II

[D Finnigan]

I've decided to take a stab at fixing the version of XINU which was written
for Apple II over 10 years ago.

The problem with it is a real twist of fate: the guy who wrote it had an
Apple II clone (the "CAT") which had 256 KB of memory and a non-standard way
of bank-switching it. Here's how it worked:

The micro had 256 kilobytes of RAM which were sub-dived into 16 banks of 16K
each, and they were called $1, $2, ... $E, $F. Bank $F had the monitor,
Applesoft, and other utilities. All of the other banks were essentially
"user-land."

Now, there was a method of switching any 4 of these 16 banks of RAM into 4
"blocks" as they were known. Each block was 16k, of course. Block 1 was the
zero page, stack, input buffer, and text screen. Blocks 2 and 3 were
graphics screen as well as user storage space. Block 4 was typically the
monitor, Applesoft, and other utilities as mentioned in bank $F.

How one switched different banks into the 4 blocks was to write either a $1,
$2, ... $F into one of 4 special I/O locations, $C07C, $C07D, $C07E, and
$C07F, which corresponded to blocks 1, 2, 3, and 4, respectively.


.. So now that I've got that explained, on to how it relates to the
standard Apple ....


As you should well know, the standard Apple relies on 64k banks, with the
exception of the 16K Language card bank. This version of Xinu is written
such that block 2 ($C07D) was substituted for either User memory or Kernel
memory, as needed.

What I plan to do is go over the source and remove the instances where this
strange block/bank-switching is done, and place the System memory up in high
memory, and the user-memory below.

Then once I've got that working, I can implement standard Apple II 64k
bank-switching and see if I can get that to work.

Here's a .zip archive of the ASCII sources, as de-tokenized from the LISA
v2.5 files:
http://dserver.macgui.com/XINU_for_Apple_II.zip

Look for SBANK2.

Also, two or three of the files are not sources, but rather are notes on
implementation.

Anyway, I have a feeling that there's a rather interesting little system
beneath this troublesome problem. I'm also going to see about getting a copy
of the XINU book which was used to write this code.

[D Finnigan]

I haven't had any time to work on this since I wrote the original post, but
hopefully I will in the coming weeks.

As an aside, is there anyone interested in this project? The complete lack
of replies had me doubtful.

[Michael J. Mahon]

Post by D Finnigan
I haven't had any time to work on this since I wrote the original post, but
hopefully I will in the coming weeks.
As an aside, is there anyone interested in this project? The complete lack
of replies had me doubtful.

If you're having fun, do it!

Utility, or even shared interest, is getting to be a pretty high
bar for fun Apple II pursuits.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."

[D Finnigan]

Post by Michael J. Mahon

Post by D Finnigan
I haven't had any time to work on this since I wrote the original post, but
hopefully I will in the coming weeks.
As an aside, is there anyone interested in this project? The complete lack
of replies had me doubtful.

If you're having fun, do it!
Utility, or even shared interest, is getting to be a pretty high
bar for fun Apple II pursuits.

Indeed, it is. I hope that I can build a system which makes it (fairly) easy
to run existing programs, but I have doubts. The same problem with making a
new operating system on today's hardware is about 10 times magnified on
yesterday's hardware-- the lack of software and authors.

[mdj]

Post by D Finnigan
I haven't had any time to work on this since I wrote the original post, but
hopefully I will in the coming weeks.
As an aside, is there anyone interested in this project? The complete lack
of replies had me doubtful.

As Michael said, do it because you love it, but if you want
suggestions... ;-)

I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

That's the fun part. Unfortunately you need a shell and a suite of
utilities that get gradually less fun to develop over time, and the
distant hope that other developers will jump in and help out is *very*
distant is communities the size of ours :-(

Do let us know how you get on though.

Matt

[D Finnigan]

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

Post by mdj
That's the fun part. Unfortunately you need a shell and a suite of
utilities that get gradually less fun to develop over time, and the
distant hope that other developers will jump in and help out is *very*
distant is communities the size of ours :-(

I'm hoping to have the kernel and such written in assembly, and then have
user programs written in C or Pascal or some-such. I've been checking out
and reading books on operating systems, so I'm learning as I'm going.

Post by mdj
Do let us know how you get on though.

I will. Even if I give up and fail, I will be sure to post what I've gotten
so far so that maybe some one else can take a look or help.

[mdj]

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

Almost everyone. I'd recommend implementing a POSIX style call layer
and 'proxy' the disk calls to ProDOS in main memory.

Post by D Finnigan

Post by mdj
That's the fun part. Unfortunately you need a shell and a suite of
utilities that get gradually less fun to develop over time, and the
distant hope that other developers will jump in and help out is *very*
distant is communities the size of ours :-(

I'm hoping to have the kernel and such written in assembly, and then have
user programs written in C or Pascal or some-such. I've been checking out
and reading books on operating systems, so I'm learning as I'm going.

That'd be fine for a lot of them.

Matt

[D Finnigan]

Post by mdj

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

Almost everyone.

Except for me. :-0

I need to get with the times. But I've still got my emulator, so that's a
start.

One of the crazy ideas I had awhile back to get more memory was to put a
Super Serial Card in the Apple and use it as the terminal interface. That
is, you wouldn't use the Apple II keyboard or video; all user interface
would go through the SSC card to your own terminal/terminal emulator.

The reason behind this setup would be that we could utilize additional
memory by way of the text and graphics screens which are normally reserved.
Also, there'd be no AppleSoft, so we could use zero-page locations and other
memory locations which would normally be reserved for AppleSoft.

Any comments on _this_ idea?

[Michael J. Mahon]

Post by D Finnigan

Post by mdj

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

Almost everyone.

Except for me. :-0
I need to get with the times. But I've still got my emulator, so that's a
start.
One of the crazy ideas I had awhile back to get more memory was to put a
Super Serial Card in the Apple and use it as the terminal interface. That
is, you wouldn't use the Apple II keyboard or video; all user interface
would go through the SSC card to your own terminal/terminal emulator.
The reason behind this setup would be that we could utilize additional
memory by way of the text and graphics screens which are normally reserved.
Also, there'd be no AppleSoft, so we could use zero-page locations and other
memory locations which would normally be reserved for AppleSoft.
Any comments on _this_ idea?

While the Apple II provides excellent capabilities for redirecting
normal character-stream I/O to other devices/ports, there are still
many programs that directly poll the keyboard. These programs cannot
be used "remotely" without sometimes extensive patching.

In addition, the non-visible parts of the primary text buffer--the
"screen holes"--are used extensively to hold various types of I/O state,
and must be reserved to do so. This makes the primary buffer (only
2KB) quite difficult to use, since it is rendered non-contiguous.

And there is no capability to "redirect" graphics operations at all.

So, bottom line, if you intend to use software that already exists,
you will need to stick with the Apple keyboard and Apple video.

There are bank-switching techniques that have been used to expand
the Apple II physical memory significantly, but, of course, the
address space remains exactly 64K, limited by the processor.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."

[D Finnigan]

Post by Michael J. Mahon

Post by D Finnigan

Post by mdj

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system
will
be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

Almost everyone.

Except for me. :-0
I need to get with the times. But I've still got my emulator, so that's a
start.
One of the crazy ideas I had awhile back to get more memory was to put a
Super Serial Card in the Apple and use it as the terminal interface. That
is, you wouldn't use the Apple II keyboard or video; all user interface
would go through the SSC card to your own terminal/terminal emulator.
The reason behind this setup would be that we could utilize additional
memory by way of the text and graphics screens which are normally reserved.
Also, there'd be no AppleSoft, so we could use zero-page locations and other
memory locations which would normally be reserved for AppleSoft.
Any comments on _this_ idea?

While the Apple II provides excellent capabilities for redirecting
normal character-stream I/O to other devices/ports, there are still
many programs that directly poll the keyboard. These programs cannot
be used "remotely" without sometimes extensive patching.

Yes, I realized that this system would require completely new software
written to work with it. Which is why it was just a crazy idea that I had.

Post by Michael J. Mahon
And there is no capability to "redirect" graphics operations at all.

Sure, so that would be another limitation, unless we had our ImageWriter II
on the other SSC card. ;-)

Post by Michael J. Mahon
So, bottom line, if you intend to use software that already exists,
you will need to stick with the Apple keyboard and Apple video.

But I still wonder if the Apple's CPU is fast enough to service additional
terminals and still keep everyone at a decent speed. Perhaps with an
accelerator.

Post by Michael J. Mahon
There are bank-switching techniques that have been used to expand
the Apple II physical memory significantly, but, of course, the
address space remains exactly 64K, limited by the processor.

And thus the fun challenge. It's great to talk about the theory, though,
even if we do never get around to implementing the whole thing.

I would program for the IIgs, but I have about 0 technical documentation on
it. All of my stuff is on the original II+ and IIe series. However, that
just speaks for the interests of its former owner, my grandfather. He
switched to the Mac, as far as I can tell, the year it was released and
didn't look back.

[Michael J. Mahon]

Post by D Finnigan

Post by Michael J. Mahon

Post by D Finnigan

Post by mdj

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system
will
be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

Almost everyone.

Except for me. :-0
I need to get with the times. But I've still got my emulator, so that's a
start.
One of the crazy ideas I had awhile back to get more memory was to put a
Super Serial Card in the Apple and use it as the terminal interface. That
is, you wouldn't use the Apple II keyboard or video; all user interface
would go through the SSC card to your own terminal/terminal emulator.
The reason behind this setup would be that we could utilize additional
memory by way of the text and graphics screens which are normally reserved.
Also, there'd be no AppleSoft, so we could use zero-page locations and other
memory locations which would normally be reserved for AppleSoft.
Any comments on _this_ idea?

While the Apple II provides excellent capabilities for redirecting
normal character-stream I/O to other devices/ports, there are still
many programs that directly poll the keyboard. These programs cannot
be used "remotely" without sometimes extensive patching.

Yes, I realized that this system would require completely new software
written to work with it. Which is why it was just a crazy idea that I had.

OK. I thought that by expressing it here, you were soliciting
comments.

Post by D Finnigan

Post by Michael J. Mahon
And there is no capability to "redirect" graphics operations at all.

Sure, so that would be another limitation, unless we had our ImageWriter II
on the other SSC card. ;-)

Well, that could be used to print a copy of a hi-res screen,
but it would still require the hi-res graphics to be rendered
to the hi-res buffer, so that wouldn't free it up.

Post by D Finnigan

Post by Michael J. Mahon
So, bottom line, if you intend to use software that already exists,
you will need to stick with the Apple keyboard and Apple video.

But I still wonder if the Apple's CPU is fast enough to service additional
terminals and still keep everyone at a decent speed. Perhaps with an
accelerator.

Like everything else, "it depends".

If the users were doing line-oriented interaction, without too much
computation required before responding, then I think it could handle
several users.

For example, a point-of-sale cash register application could
probably handle at least a half-dozen users. If all the users are
doing different things, then it *really* depends. ;-) If a user
transaction requires some disk accesses, then throughput goes downhill
in a hurry.

Post by D Finnigan

Post by Michael J. Mahon
There are bank-switching techniques that have been used to expand
the Apple II physical memory significantly, but, of course, the
address space remains exactly 64K, limited by the processor.

And thus the fun challenge. It's great to talk about the theory, though,
even if we do never get around to implementing the whole thing.

Certainly.

To simplify the programming model while preserving all the Apple II
capabilities, it might be best to reserve the first two banks of
memory ("main" and "AUX 1") as OS resources, and banish all user code
to higher AUX banks, where memory can be seen as contiguous with a
little fiddling.

Post by D Finnigan
I would program for the IIgs, but I have about 0 technical documentation on
it. All of my stuff is on the original II+ and IIe series. However, that
just speaks for the interests of its former owner, my grandfather. He
switched to the Mac, as far as I can tell, the year it was released and
didn't look back.

For a number of reasons, I prefer the 8-bit Apple II's.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."

[mdj]

Post by Michael J. Mahon
Certainly.
To simplify the programming model while preserving all the Apple II
capabilities, it might be best to reserve the first two banks of
memory ("main" and "AUX 1") as OS resources, and banish all user code
to higher AUX banks, where memory can be seen as contiguous with a
little fiddling.

Agreed. This also makes it possible to do a relatively cheap system
call, say a jsr into high language card space, which could then
context switch cheaply with a hardwired write to the paddle strobe. If
you assume a 65C02, you can do this without destroying a register,
making parameter passing to system calls relatively cheap too.

Of course this assumes that much of the kernel resides in the LC of
Auxiliary bank zero (as in, the normal bank) which seems the logical
place for it.

Matt

[DaveSchmenk]

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

The issue I have using RamWorks is that you have isolated the audience
to those with RamWorks cards - no better off than were the project
started IMO. Working with standard hardware would be a requirement to
get excited about this. Again, hard disks should make it work better,
but shouldn't be a requirement.

Post by D Finnigan

Post by mdj
That's the fun part. Unfortunately you need a shell and a suite of
utilities that get gradually less fun to develop over time, and the
distant hope that other developers will jump in and help out is *very*
distant is communities the size of ours :-(

I'm hoping to have the kernel and such written in assembly, and then have
user programs written in C or Pascal or some-such. I've been checking out
and reading books on operating systems, so I'm learning as I'm going.

I had the honor of taking the final class Doug Comer taught on Xinu.
My all-time favorite class. We used LSI-11s in the lab (small
PDP-11s). In order simplify development, everything was statically
linked at build time. The kernel can simply be a library you link
to. This is a fairly easy way to get things going. Once you get all
that working, writing a loader would be a little easier. For
instance, building the kernel with a statically linked shell, then
putting all the code for a relocating loader in the shell would keep
your kernel simple.

Post by D Finnigan

Post by mdj
Do let us know how you get on though.

I will. Even if I give up and fail, I will be sure to post what I've gotten
so far so that maybe some one else can take a look or help.

I would recommend using cc65 as your development environment as it
gives you great flexibility in writing assembly and configuring the
memory layout (and has a flexible I/O architecture you could modify
for your kernel). Others can use their platform of choice if they
decide to help out. You will have a lot of debugging to do so an
emulator will give you an advantage during development. Start simple
and work yourself up to the more complex tasks. Tackling the
development of such a system is as educational as writing the code and
learning about kernels.

Good luck,

Dave...

[D Finnigan]

Post by DaveSchmenk

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

The issue I have using RamWorks is that you have isolated the audience
to those with RamWorks cards - no better off than were the project
started IMO. Working with standard hardware would be a requirement to
get excited about this. Again, hard disks should make it work better,
but shouldn't be a requirement.

Then you'll probably see the irony in the fact that I possess neither a
RamWorks card, nor a hard disk system! :-0

However, those are certainly on my wish list, along with an AppleMouse II
card! (Anyone have a spare for sale?)

Post by DaveSchmenk

Post by D Finnigan

Post by mdj
That's the fun part. Unfortunately you need a shell and a suite of
utilities that get gradually less fun to develop over time, and the
distant hope that other developers will jump in and help out is *very*
distant is communities the size of ours :-(

I'm hoping to have the kernel and such written in assembly, and then have
user programs written in C or Pascal or some-such. I've been checking out
and reading books on operating systems, so I'm learning as I'm going.

I had the honor of taking the final class Doug Comer taught on Xinu.
My all-time favorite class.

Which reminds me, I need to get the XINU book on loan. I was going to do
that about 3 weeks ago, but it was too close to holiday break, so I should
do it now.

Post by DaveSchmenk

Post by D Finnigan

Post by mdj
Do let us know how you get on though.

I will. Even if I give up and fail, I will be sure to post what I've gotten
so far so that maybe some one else can take a look or help.

I would recommend using cc65 as your development environment as it
gives you great flexibility in writing assembly and configuring the
memory layout (and has a flexible I/O architecture you could modify
for your kernel). Others can use their platform of choice if they
decide to help out. You will have a lot of debugging to do so an
emulator will give you an advantage during development. Start simple
and work yourself up to the more complex tasks. Tackling the
development of such a system is as educational as writing the code and
learning about kernels.

Yeah, I definitely need to get a good environment set up, which is why I
posted a thread about a month ago asking for suggestions. The Virtual II
emulator for Mac OS X will really help, but I would need to pay the $20
"limited" or (gasp) the $50 "full" shareware fee to be able to make the best
use of it. And the $20 limited license doesn't allow a virtual 8 MB RamWorks
card, so I'm stuck shelling out that fee for the emulator, or buying a real
RamWorks card, which could cost up to twice that amount. What to do? :-/

[Michael J. Mahon]

Post by DaveSchmenk

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

The issue I have using RamWorks is that you have isolated the audience
to those with RamWorks cards - no better off than were the project
started IMO. Working with standard hardware would be a requirement to
get excited about this. Again, hard disks should make it work better,
but shouldn't be a requirement.

If it is satisfactory that the system run only programs developed
specifically to run on it, then a standard 128KB system could work.

But the RAMworks-style bank-switched memory extension is a solid
_de facto_ standard--essentially all AUX slot memory extenders use
that interface--so if more than 128KB is desired, that's really the
only game in town. (Code can't be executed from "Slinky"-style cards.)

Taking the bank-switched approach offers the posibility of being able
to load an existing application (with some restrictions) into a 64KB
bank and run it.

As for hard disks, they present a quantum leap in what an OS can
aspire to do.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."

[DaveSchmenk]

Post by Michael J. Mahon

Post by DaveSchmenk

Post by D Finnigan

Post by mdj
I rather like the idea of using a RamWorks card as a set of isolated
'processes' that could communicate UNIX style; essentially adding a
calling interface to ProDOS and pipes for IPC.

As do I, and that's what I want to work up to. One of the big problems is
that ProDOS isn't meant to be called from AUX RAM. There are definitely some
hurdles to get over, but it should be possible. Having a disk system will be
the best in the long run, IMO. How many people here have hard disks for
their Apple?

The issue I have using RamWorks is that you have isolated the audience
to those with RamWorks cards - no better off than were the project
started IMO.  Working with standard hardware would be a requirement to
get excited about this.  Again, hard disks should make it work better,
but shouldn't be a requirement.

If it is satisfactory that the system run only programs developed
specifically to run on it, then a standard 128KB system could work.

or 64K system.

Post by Michael J. Mahon
But the RAMworks-style bank-switched memory extension is a solid
_de facto_ standard--essentially all AUX slot memory extenders use
that interface--so if more than 128KB is desired, that's really the
only game in town.  (Code can't be executed from "Slinky"-style cards.)

No, but it makes a reasonable swap device - see below.

Post by Michael J. Mahon
Taking the bank-switched approach offers the posibility of being able
to load an existing application (with some restrictions) into a 64KB
bank and run it.

This sounds more like a program switcher than a multitasking kernel.
How many existing programs could live well in such an environment?
Probably very few.

Post by Michael J. Mahon
As for hard disks, they present a quantum leap in what an OS can
aspire to do.

So does a 4GHZ CPU, 8 GB RAM, 512 MB GPU, 1 GB ethernet.... ProDOS
actually does a very good job at managing and abstracting storage
devices (and extended RAM). With a little foresight, a dual drive
system would be doable for a reasonable complex environment. Systems
containing RAM drives and hard drives that show up as ProDOS volumes
can be used as used as swap devices without requiring hardware
specific code. But now I'm getting ahead of myself and will expand
upon this in another thread shortly ;-)

Post by Michael J. Mahon
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page:http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."

Dave...

[mdj]

So does a 4GHZ CPU, 8 GB RAM, 512 MB GPU, 1 GB ethernet....  ProDOS
actually does a very good job at managing and abstracting storage
devices (and extended RAM).  With a little foresight, a dual drive
system would be doable for a reasonable complex environment.  Systems
containing RAM drives and hard drives that show up as ProDOS volumes
can be used as used as swap devices without requiring hardware
specific code.  But now I'm getting ahead of myself and will expand
upon this in another thread shortly ;-)

Swapping is a *lot* slower that having multiple programs in different
memory banks ...

Then again, if your system hosts a virtualised environment with
homogenised memory allocation, a few possibilities open up ...

Matt

[D Finnigan]

Post by mdj

So does a 4GHZ CPU, 8 GB RAM, 512 MB GPU, 1 GB ethernet.... �ProDOS
actually does a very good job at managing and abstracting storage
devices (and extended RAM). �With a little foresight, a dual drive
system would be doable for a reasonable complex environment. �Systems
containing RAM drives and hard drives that show up as ProDOS volumes
can be used as used as swap devices without requiring hardware
specific code. �But now I'm getting ahead of myself and will expand
upon this in another thread shortly ;-)

Swapping is a *lot* slower that having multiple programs in different
memory banks ...

Which is why we'd want a hard disk system, or even better, a flash storage
device, as opposed to a Disk ][.

Post by mdj
Then again, if your system hosts a virtualised environment with
homogenised memory allocation, a few possibilities open up ...

Indeed, such as if 2 instances of the same program are running, they need
only 1 set of static code to be loaded, not two.

[DaveSchmenk]

Post by mdj

So does a 4GHZ CPU, 8 GB RAM, 512 MB GPU, 1 GB ethernet....  ProDOS
actually does a very good job at managing and abstracting storage
devices (and extended RAM).  With a little foresight, a dual drive
system would be doable for a reasonable complex environment.  Systems
containing RAM drives and hard drives that show up as ProDOS volumes
can be used as used as swap devices without requiring hardware
specific code.  But now I'm getting ahead of myself and will expand
upon this in another thread shortly ;-)

Swapping is a *lot* slower that having multiple programs in different
memory banks ...

Of course, but you wouldn't need to swap the entire address space.
Just on-demand managed memory blocks. A real memory manager is
required for such functionality.

Post by mdj
Then again, if your system hosts a virtualised environment with
homogenised memory allocation, a few possibilities open up ...
Matt

Which is where my earlier comments about static linking first and
later, a relocating loader comes in. This behaves more like an OS
rather than a program switcher. A much more interesting exercise,
too. This is also how Xinu is written. This requires programs to be
ported to such an environment instead of running existing programs -
which I don't think would be very successful anyway. Then, I think
adding separate programs running their own banks would make an
excellent follow-up exercise. I always take the "start small"
approach and build up.

Dave...

[mdj]

Post by DaveSchmenk
Which is where my earlier comments about static linking first and
later, a relocating loader comes in.  This behaves more like an OS
rather than a program switcher.  A much more interesting exercise,
too.   This is also how Xinu is written.  This requires programs to be
ported to such an environment instead of running existing programs -
which I don't think would be very successful anyway.  Then, I think
adding separate programs running their own banks would make an
excellent follow-up exercise.  I always take the "start small"
approach and build up.

Right. I was coming at it from a start from scratch point of view. A 1
bank is 1 process approach actually makes it simpler IMO, as programs
can be statically linked to fixed locations and have essentially the
entire memory space (including the zero page) to themselves. A 1mb
card would give you 15 processes which is more than enough to keep a
1Mhz system busy and while it's a wasteful design it's simple to
implement and should have pretty good performance characteristics,
which is essential for being usable on such modest systems.

For bonus points, a patched Applesoft image and basic.system could run
a large number of BASIC programs unmodified, and provide a Rolls Royce
development environment for Applesoft programs.

Such as it is with software development... The smaller the target
audience the more like a herd of cats it becomes ;-) We all seem to be
on quite different 'pages', so to speak ...

Matt

[D Finnigan]

Post by mdj
Such as it is with software development... The smaller the target
audience the more like a herd of cats it becomes ;-) We all seem to be
on quite different 'pages', so to speak ...
Matt

Well the important part is that even if we don't come up with a working
system, at least we've left plenty of documentation around for future users
to read over. I've been reading literally 20 years of posts by people who
have all wanted the same thing: a Unix-like / multi-tasking system for their
8-bit Apple.

Someone's got to do it, one of these days. Better to try and fail rather
than never try at all, that's what I say. :-)

[Michael J. Mahon]

Post by D Finnigan

Post by mdj
Such as it is with software development... The smaller the target
audience the more like a herd of cats it becomes ;-) We all seem to be
on quite different 'pages', so to speak ...
Matt

Well the important part is that even if we don't come up with a working
system, at least we've left plenty of documentation around for future users
to read over. I've been reading literally 20 years of posts by people who
have all wanted the same thing: a Unix-like / multi-tasking system for their
8-bit Apple.

Though I've seen occasional posts in this category--and I expect
there were more during the GNO era--I certainly would question
how much demand there is for a system that doesn't run any of the
tools that most developers have become accustomed to.

Put another way, how useful would a Unix-like system be if it could
not run one's preferred editors, compilers, or assemblers?

A really minimal multitasking enviromnent for an unadorned Apple II
environment is Contiki, but it is focused on running a micro-TCP/IP
stack, and seems otherwise to be rather limiting.

If the point is education and experimentation with a multitasking OS,
then whatever excites you is the right thing to work on.

But if the point is to provide a useful tool for others, then the first
order of business is to consider the requirements for such a system to
be useful--and I suspect that anything that can be done on a minimal
Apple II system would have a hard time meeting the "useful" criteria.

But, for example, a small multitasking OS could be quite useful for
realtime control applications being written from scratch (using tools
that do not run under the system).

As near as I can tell, most current Apple II users are not very
interested in systems that require them to write their own programs.
And those who are interested in writing their own programs tend to
have relatively "extended" Apple II systems.

Complicating the matter, a fair number of those programmers prefer
that the results of their efforts be runnable on minimal Apple II's.

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."

[D Finnigan]

Post by Michael J. Mahon
If the point is education and experimentation with a multitasking OS,
then whatever excites you is the right thing to work on.

That is my primary point here. Just to learn about and experiment, and see
if it can be done.

Post by Michael J. Mahon
As near as I can tell, most current Apple II users are not very
interested in systems that require them to write their own programs.

Yeah, the "laziness factor" certainly is a big draw-back. What do people
even do with their Apples today? I thought that was the whole point: to
write your own programs. Maybe it's just a waste of time because we've got
better computers to actually do useful work on.

[Michael J. Mahon]

Post by D Finnigan

Post by Michael J. Mahon
If the point is education and experimentation with a multitasking OS,
then whatever excites you is the right thing to work on.

That is my primary point here. Just to learn about and experiment, and see
if it can be done.

Post by Michael J. Mahon
As near as I can tell, most current Apple II users are not very
interested in systems that require them to write their own programs.

Yeah, the "laziness factor" certainly is a big draw-back. What do people
even do with their Apples today? I thought that was the whole point: to
write your own programs. Maybe it's just a waste of time because we've got
better computers to actually do useful work on.

Experimentation through programming was, perhaps, the major motivation
during the very early days of the Apple II. But success brought, first
a trickle, then a hoard of "users" whose primary interest was in running
programs written by others.

It's hard to complain about this, since the users made the Apple II, and
indeed Apple Computer, Inc., successful and long-lived (and then doomed
the Apple II as a product). But there's no doubt that the number of
neurons focused on learning to program and on innovative programming has
declined over the years.

Programming has now become largely an industrial practice, dominated by
various kinds of groupthink and dedicated to getting version 14.7 out
the door in time to generate revenue.

There are still truly innovative programmers, but they are frequently
regarded as troublemakers--until they start their own company. ;-)

Of course, the upside is uniform interfaces, only a few, similar ways
to accomplish common tasks, and a general reduction in skill level
required to use a computer, leading to increased average productivity.

The downside is that computers are a commodity, and are about as
beguiling to most kids as toasters. ;-(

-michael

NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page: http://home.comcast.net/~mjmahon

"The wastebasket is our most important design
tool--and it's seriously underused."

[mdj]

Post by Michael J. Mahon
The downside is that computers are a commodity, and are about as
beguiling to most kids as toasters.  ;-(

I more or less agree with this, but the commodity market is changing,
and becoming increasingly more embedded, 'smart phones' and tablets,
etc. I see this as a good thing as it serves to return the 'real
computer' to its previous role as a workstation or creative tool.

It would certainly help though if we gave the younger generation
beguiling languages and tools with which to be creative. This is where
the groupthink does the most damage, IMO

Matt

[Oliver Schmidt]

Hi,

Post by Michael J. Mahon

Post by D Finnigan
I've been reading literally 20 years of posts by people who
have all wanted the same thing: a Unix-like / multi-tasking system for their
8-bit Apple.

Put another way, how useful would a Unix-like system be if it could
not run one's preferred editors, compilers, or assemblers?

From that perspective LUnix (http://lng.sourceforge.net/) might be a
much more promising starting point than XINU:

- The ca65 assembler (from the cc65 toolchain) can be used to create
LUnix programs.

- There's alpha-state code for a cc65 C library for LUnix. With that
the cc65 C compiler can be used to create LUnix programs.

Post by Michael J. Mahon
A really minimal multitasking enviromnent for an unadorned Apple II
environment is Contiki, but it is focused on running a micro-TCP/IP
stack, and seems otherwise to be rather limiting.

Contiki obligates programs to follow its event handling paradigm and
offers relatively little memory to programs as it is itself written in
C.

LUnix on the other hand is written in assembly and allows programs to
be written in the classic approach - but without the programs
cooperating in the task switching in requires some IRQ source for
preemptive task switching.

Post by Michael J. Mahon
But, for example, a small multitasking OS could be quite useful for
realtime control applications being written from scratch (using tools
that do not run under the system).

Like cc65...

Post by Michael J. Mahon
Complicating the matter, a fair number of those programmers prefer
that the results of their efforts be runnable on minimal Apple II's.

Like intended by LUnix...

Maybe way more important: LUnix already runs on the C64 - and that
machine has a much larger community actively developing programs. So
in my opinion every effort building on others to use it by writing
programs for it should make sure to be a multi-target effort including
the C64, simply because then chances are much better to create enough
momentum.

As a typical example might serve Contiki 2.x being a framework for
creating internetworking programs (i.e. for the Apple2, C64 and C128).
The only 3rd party 6502 program created so far is BREADBOX64 for the
C64:
http://www.vandenbrande.com/wp/2009/06/breadbox64-a-twitter-client-for-the-c64/

BTW 1: You can imagine that I'm very happy that this program exists
because it shows that Contiki 2.x really works as intended.

BTW 2: Porting BREADBOX64 to the Apple2 (using Uthernet or LANceGS) is
quite easy. An example for the best bet to get new Apple2 programs.

Best, Oliver

[DaveSchmenk]

Post by Michael J. Mahon

Post by D Finnigan

Post by mdj
Such as it is with software development... The smaller the target
audience the more like a herd of cats it becomes ;-) We all seem to be
on quite different 'pages', so to speak ...
Matt

Well the important part is that even if we don't come up with a working
system, at least we've left plenty of documentation around for future users
to read over. I've been reading literally 20 years of posts by people who
have all wanted the same thing: a Unix-like / multi-tasking system for their
8-bit Apple.

Though I've seen occasional posts in this category--and I expect
there were more during the GNO era--I certainly would question
how much demand there is for a system that doesn't run any of the
tools that most developers have become accustomed to.
Put another way, how useful would a Unix-like system be if it could
not run one's preferred editors, compilers, or assemblers?
A really minimal multitasking enviromnent for an unadorned Apple II
environment is Contiki, but it is focused on running a micro-TCP/IP
stack, and seems otherwise to be rather limiting.
If the point is education and experimentation with a multitasking OS,
then whatever excites you is the right thing to work on.
But if the point is to provide a useful tool for others, then the first
order of business is to consider the requirements for such a system to
be useful--and I suspect that anything that can be done on a minimal
Apple II system would have a hard time meeting the "useful" criteria.
But, for example, a small multitasking OS could be quite useful for
realtime control applications being written from scratch (using tools
that do not run under the system).
As near as I can tell, most current Apple II users are not very
interested in systems that require them to write their own programs.
And those who are interested in writing their own programs tend to
have relatively "extended" Apple II systems.
Complicating the matter, a fair number of those programmers prefer
that the results of their efforts be runnable on minimal Apple II's.

Well, I would say more like targeting a guaranteed baseline. You have
to consider how your hardware requirements alienate those that don't
have that specific hardware. If there is to be much participation,
you have to address the audience. Scaling back the project in order
to appeal to a greater number of programmers and users seems logical.
Maybe everyone else has a full RamWorks II card in their Apple II but
me. I think if they were readily available for a reasonable price, I
guess I wouldn't have an objection. Since flash drives are easy to
come by, that isn't be much of a barrier. Personally, everything I
write for the Apple II has to run from my Wiligal Rev 0 Integer BASIC
machine to the 8 MHz IIc+. Just part of the challenge, I suppose.
Quite honestly, having a requirement of being able to run existing
programs and tools under such an OS seems much more complicating to
me. But, nobody is going to get rich off such a project so it should
be a matter passion, not practicality.

Post by Michael J. Mahon
-michael
NadaNet and AppleCrate II: parallel computing for Apple II computers!
Home page:http://home.comcast.net/~mjmahon
"The wastebasket is our most important design
tool--and it's seriously underused."

Dave...

[mdj]

Well, I would say more like targeting a guaranteed baseline.  You have
to consider how your hardware requirements alienate those that don't
have that specific hardware.  If there is to be much participation,
you have to address the audience.  

True, but we're talking about a UNIX, which while interesting to non-
programmer end users is ostensibly a programmers tool.

To me, if it's not going to be built as a development environment,
it's not really worth doing. There's already tons of great development
tools for the 64k Apple II platform, and you've added another great
one (which I love btw), but there's very little out there to exploit
the 'extended' 8-bit Apple II. An extended VM02 is one great way to do
it. A UNIX approach would be another way. Turning it into a LISP
machine would be yet another...

As I alluded to in an earlier post, there's likely to be as many
opinions on what to build as there is people who are willing to build
it at this point. If we get lucky, we might see *all* the ideas, but I
think it's well past the point where we can think of the Apple II
community as any kind of market, at least in terms of its ability to
influence what should or shouldn't be made.

Matt

[DaveSchmenk]

Post by mdj

Well, I would say more like targeting a guaranteed baseline.  You have
to consider how your hardware requirements alienate those that don't
have that specific hardware.  If there is to be much participation,
you have to address the audience.  

True, but we're talking about a UNIX, which while interesting to non-
programmer end users is ostensibly a programmers tool.

Agreed. And that means C. The only self hosted version of C that
seems to have any support is Aztec C. Bill? Where are you? Bill?

Post by mdj
To me, if it's not going to be built as a development environment,
it's not really worth doing. There's already tons of great development
tools for the 64k Apple II platform, and you've added another great
one (which I love btw),

(thanks!)

but there's very little out there to exploit

Post by mdj
the 'extended' 8-bit Apple II. An extended VM02 is one great way to do
it. A UNIX approach would be another way. Turning it into a LISP
machine would be yet another...

OK, I confess that I have a RamWorks III in a drawer somewhere. I'll
go dig it out and scavenge a slinky board's memory. Anyone have a
programmers spec for it? I'll be a willing tester.

Post by mdj
As I alluded to in an earlier post, there's likely to be as many
opinions on what to build as there is people who are willing to build
it at this point. If we get lucky, we might see *all* the ideas, but I
think it's well past the point where we can think of the Apple II
community as any kind of market, at least in terms of its ability to
influence what should or shouldn't be made.
Matt

In this case, the market *would* be the developers. We are the only
ones, except for the retro-gamers, still using these dinosaurs.
Nobody in their right mind would still be developing hardware and
software for a 30 year old computer.

Dave...

[mdj]

Post by mdj

Well, I would say more like targeting a guaranteed baseline.  You have
to consider how your hardware requirements alienate those that don't
have that specific hardware.  If there is to be much participation,
you have to address the audience.  

True, but we're talking about a UNIX, which while interesting to non-
programmer end users is ostensibly a programmers tool.

Agreed.  And that means C.  The only self hosted version of C that
seems to have any support is Aztec C.  Bill?  Where are you?  Bill?

Indeed. Although the first UNIX (or was it then Unics as a pun on
Multics ?) was written in assembler, and I'd be happy enough with an
assembler and editor that ran on it for a start. That, plus a port of
VM02 would be more than enough. I'll leave C support to the C fans ...

Post by mdj
To me, if it's not going to be built as a development environment,
it's not really worth doing. There's already tons of great development
tools for the 64k Apple II platform, and you've added another great
one (which I love btw),

(thanks!)
but there's very little out there to exploit

Yeah :-(

Post by mdj
the 'extended' 8-bit Apple II. An extended VM02 is one great way to do
it. A UNIX approach would be another way. Turning it into a LISP
machine would be yet another...

OK, I confess that I have a RamWorks III in a drawer somewhere.  I'll
go dig it out and scavenge a slinky board's memory.  Anyone have a
programmers spec for it?  I'll be a willing tester.

I do somewhere, but from memory all there is to it is the bank select
register which is overloaded with the paddle strobe ($C073). Bank $00
is the standard AUX bank and a one meg card also gives you $01 to $0F.
If you're lucky enough to have more than that the bank layout becomes
non-linear above 1mb so you need to 'poll' the card to determine its
layout.

The only real 'gotchas' are than AUX cards can't detect a reset, so
you need to write your own reset routine so you can recover into a
known state. Of course, if you have the AUX language card switched in
you have the same potential worries with interrupts as you do with a
single AUX bank, only slightly trickier.

All in all, it's a *very* simple addition.

Post by mdj
As I alluded to in an earlier post, there's likely to be as many
opinions on what to build as there is people who are willing to build
it at this point. If we get lucky, we might see *all* the ideas, but I
think it's well past the point where we can think of the Apple II
community as any kind of market, at least in terms of its ability to
influence what should or shouldn't be made.
Matt

In this case, the market *would* be the developers.  We are the only
ones, except for the retro-gamers, still using these dinosaurs.
Nobody in their right mind would still be developing hardware and
software for a 30 year old computer.

Yep :-) And yet we get just enough new stuff each year to keep it
interesting and fun above and beyond our own personal projects.

Apple II Forever!

[D Finnigan]

Post by DaveSchmenk
OK, I confess that I have a RamWorks III in a drawer somewhere. I'll
go dig it out and scavenge a slinky board's memory. Anyone have a
programmers spec for it? I'll be a willing tester.

Slightly off-topic, but does anyone have the difference between a RamWorks
II and a RamWorks III? I searched, but couldn't find anything that seemed to
make sense.

[Greg Buchner]

Post by D Finnigan

Post by DaveSchmenk
OK, I confess that I have a RamWorks III in a drawer somewhere. I'll
go dig it out and scavenge a slinky board's memory. Anyone have a
programmers spec for it? I'll be a willing tester.

Slightly off-topic, but does anyone have the difference between a RamWorks
II and a RamWorks III? I searched, but couldn't find anything that seemed to
make sense.

The RamWorks III was a board redesign of the RamWorks II so it would fit
into European Apple IIEs. The Aux slot was in line with Slot 3 and I
believe it also may have been closer to the back.

Greg B.

[mdj]

Post by Greg Buchner
The RamWorks III was a board redesign of the RamWorks II so it would fit
into European Apple IIEs. The Aux slot was in line with Slot 3 and I
believe it also may have been closer to the back.

Correct on both counts. The Ramworks III has a 'notch' in the upper
right corner to allow for the shorter clearance. It's still a *very*
tight fit however.

The board redesign BTW is to allow a card to tap the negative voltage
pins that aren't available on the AUX slot. I suspect someone
somewhere also felt that rendering slot 3 physically inaccessible made
the machine more 'user friendly', since it's usefulness for other
tasks. As evidence that this was a stupid idea I have in my collection
a hacked IIe motherboard that redirected slot 3's IOSEL/DEVSEL signals
to allow a Videx Ultraterm to be in slot 3 whilst physically being in
slot 4.

Once US IIe motherboards became cheap and plentiful on ebay, I swapped
out the board in my 'production' IIe for the IMO better design.

Matt

[rich12345]

Post by D Finnigan
One of the big problems is
that ProDOS isn't meant to be called from AUX RAM.

the problem has been solved...


http://groups.google.com/group/comp.sys.apple2.programmer/browse_frm/thread/fb6c625954fa665c/e47a01a576fe75fd?lnk=gst&q=AUX+mli#e47a01a576fe75fd

[D Finnigan]

Post by rich12345

Post by D Finnigan
One of the big problems is
that ProDOS isn't meant to be called from AUX RAM.

the problem has been solved...

Thanks for posting that. I had read it a few months ago, but forgot.

The thing about this XINU package is that it has its own "custom" version of
ProDOS called the DDD, and I don't know what's changed with it.

[rich12345]

Post by D Finnigan
The thing about this XINU package is that it has its own "custom" version of
ProDOS called the DDD, and I don't know what's changed with it.

do MLI calls in DDD still go through BF00?

If so, you'd just have to make sure that my code (MLI FROM AUX)
doesn't run over anything in main RAM that XINU uses.


Rich

[D Finnigan]

Post by rich12345

Post by D Finnigan
The thing about this XINU package is that it has its own "custom" version of
ProDOS called the DDD, and I don't know what's changed with it.

do MLI calls in DDD still go through BF00?

I don't know; I haven't looked into it yet. But you could. I posted the
ASCII sources here:

http://dserver.macgui.com/XINU_for_Apple_II.zip

Note that we only have the DDD as a binary, so you'd probably find it easier
to search for BF00 in the equates.

[magnusfalkirk]

Post by D Finnigan
I haven't had any time to work on this since I wrote the original post, but
hopefully I will in the coming weeks.
As an aside, is there anyone interested in this project? The complete lack
of replies had me doubtful.

Along these same lines, but slightly different, here's a page you
might want to look at that will either be of some help or may make you
decide to try your hand at this port of UNIX. It's called LUnix and is
being worked on for C64, as well as a few other 6502 computers I
think. Here's the page: http://lng.sourceforge.net/

Dean

[D Finnigan]

Post by magnusfalkirk

Post by D Finnigan
I haven't had any time to work on this since I wrote the original post, but
hopefully I will in the coming weeks.
As an aside, is there anyone interested in this project? The complete lack
of replies had me doubtful.

Along these same lines, but slightly different, here's a page you
might want to look at that will either be of some help or may make you
decide to try your hand at this port of UNIX. It's called LUnix and is
being worked on for C64, as well as a few other 6502 computers I
think. Here's the page: http://lng.sourceforge.net/

Thanks. Someone else mentioned that earlier, but I haven't taken an in-depth
look at it yet. I am still waiting for the XINU book to arrive. Hopefully it
will come by early next week.

[D Finnigan]

Post by D Finnigan
look at it yet. I am still waiting for the XINU book to arrive. Hopefully it
will come by early next week.

Still waiting. Hopefully, it will arrive _this_ week.

[D Finnigan]

Post by D Finnigan

Post by D Finnigan
look at it yet. I am still waiting for the XINU book to arrive. Hopefully it
will come by early next week.

Still waiting. Hopefully, it will arrive _this_ week.

I got an email stating that the book had arrived and I've only just picked
it up moments ago. Skimming over it, there is source provided, but it's in
C. I'm starting to really appreciate the work done on XINU for Apple II so
far, since I had assumed that there wouldn't be code, or at least not 6502
assembly.

I won't be doing any more fiddling with the existing sources until I've
thoroughly read this book.

Until then! :-)

[D Finnigan]

Post by D Finnigan
Until then! :-)

Another status update! (Usenet isn't a blog!!!)

Thanks to the kind donation of Twilight_Rodent, I now have a genuine
AppleMouse card, suitable for making silly MousePaint pictures and
generating a 60Hz interrupt signal; and a RamWorks III card with what I
believe is 256 KB of RAM, suitable for bank-switching maneuvers.

As for the XINU book, progress is coming along well. I'm up to Chapter 10
out of 20. I've been typing all of the C source code as I go to help me
understand what the system is doing and how it functions. I can then compare
it to the 6502 assembly code. The rest of the text is absolutely essential
too of course, and I plan to have both the C source code and some
descriptions of it from the text posted online as soon as I have it all
finished.

Then the fun begins. :-)

[RedskullDC]

Post by D Finnigan
The problem with it is a real twist of fate: the guy who wrote it had an
Apple II clone (the "CAT") which had 256 KB of memory and a non-standard way

......

Post by D Finnigan
How one switched different banks into the 4 blocks was to write either a $1,
$2, ... $F into one of 4 special I/O locations, $C07C, $C07D, $C07E, and
$C07F, which corresponded to blocks 1, 2, 3, and 4, respectively.

Hi, D.

Just downloaded the sources, haven't had a look as yet.

Way the Cat handled 80 column screens may be an issue as well?
(in $1000 to $17FF instead of the Apple mem setup)

Cheers,
Red

[D Finnigan]

Post by RedskullDC

Post by D Finnigan
The problem with it is a real twist of fate: the guy who wrote it had an
Apple II clone (the "CAT") which had 256 KB of memory and a non-standard way

......

Post by D Finnigan
How one switched different banks into the 4 blocks was to write either a $1,
$2, ... $F into one of 4 special I/O locations, $C07C, $C07D, $C07E, and
$C07F, which corresponded to blocks 1, 2, 3, and 4, respectively.

Hi, D.
Just downloaded the sources, haven't had a look as yet.
Way the Cat handled 80 column screens may be an issue as well?
(in $1000 to $17FF instead of the Apple mem setup)

Yes, I have gone over the code and I have identified the sections which will
need changing. I've also read and re-read the provided notes quite a few
times. The problem I was having was with working the LISA assembler. It's
rather arcane to me. :-/ Even getting the sources into ASCII format took
literally several hours on an emulator.