Apple II Desktop Deconstruction

[i***@gmail.com]

As noted elsewhere, I'm taking on disassembly and documentation of the Apple II Desktop (a.k.a. A2D, a.k.a. MouseDesk) graphical shell for the Apple II.

Code and documentation are at: https://github.com/inexorabletash/a2d

Goals:

* Get the code fully documented
* Get the code buildable with changes (i.e. no hard-coded addresses except documented entry points)
* Document the API (the GUI library and the app entry points needed by DAs)
* Fix known bugs in DAs and the app
* Code modernization.
* Add additional Desk Accessories. One is done already (an image viewer)
* Add additional functionality to the DeskTop app itself.
* Performance improvements (it's sluggish at 1MHz)

I'm using the issue tracker for feature requests/bug reports. I'm building it with ca65, and ensuring that it builds byte-identical for the moment.

The overall structure of the system is now reasonably well understood; see https://github.com/inexorabletash/a2d/blob/master/desktop/README.md which includes a breakdown of the file segments/overlays and the memory map. All the weird naming is my fault.

There's a GUI library that handles mouse/keyboard input, managing cursors, windows and menus, and drawing text and graphics in DHR; this provides an API with a MLI-like calling convention and is mostly understood, except for a handful of calls. It's pretty slick - fill patterns, polylines, bitmaps, cursors, menus, hit testing, proportional text rendering, 16-bit coordinates... everything you'd expect from a decent GUI library. This spans AUX $4000-$8500ish.

The bank switched memory in AUX $D000-$FFFF holds a tiny bit of code, but mostly resources (strings, bitmaps, menu definitions, points/rects, tables) and buffers for the windows/icons.

Everything else not taken up by ProDOS or DHR in both AUX and MAIN is the actual application, comprising the desktop logic, the contents of windows, and actions performed on volumes/files - dialog input loops and the actual ProDOS MLI work. The segments which are initially loaded are in the process of being understood (e.g. working backwards from string and bitmap resources it's possible to identify the handlers for various menu items and dialogs). Overlays are pulled in for operations with additional UI (e.g. disk copy) and I haven't dug into those yet.

There are some interesting things lurking in the code. For example, in the initial launch sequence which overrides the ProDOS QUIT handler (twice), there's an unreferenced block of code which can dump the DHR screen to an ImageWriter printer attached to an SSC in slot 1. I suspect this was used to generating screenshots for the manual, and could be hooked up by altering a few bytes. The code is all 6502, not 65C02. There are inconsistencies in coding style, but it's overall pretty elegant... if a bit pokey. The DAs are particularly buggy and have a fair bit of dead code.

If anyone is interested in helping... well, PRs welcome. :) The code base is large enough that assistance in deciphering it would be handy, although coordination would be required. There's definitely enough documented to produce custom DAs - I started documenting the lifecycle at https://github.com/inexorabletash/a2d/blob/master/desk.acc/a2d.md but that could definitely be improved.

[John Brooks]

Post by i***@gmail.com
As noted elsewhere, I'm taking on disassembly and documentation of the Apple II Desktop (a.k.a. A2D, a.k.a. MouseDesk) graphical shell for the Apple II.
Code and documentation are at: https://github.com/inexorabletash/a2d
* Get the code fully documented
* Get the code buildable with changes (i.e. no hard-coded addresses except documented entry points)
* Document the API (the GUI library and the app entry points needed by DAs)
* Fix known bugs in DAs and the app
* Code modernization.
* Add additional Desk Accessories. One is done already (an image viewer)
* Add additional functionality to the DeskTop app itself.
* Performance improvements (it's sluggish at 1MHz)
I'm using the issue tracker for feature requests/bug reports. I'm building it with ca65, and ensuring that it builds byte-identical for the moment.
The overall structure of the system is now reasonably well understood; see https://github.com/inexorabletash/a2d/blob/master/desktop/README.md which includes a breakdown of the file segments/overlays and the memory map. All the weird naming is my fault.
There's a GUI library that handles mouse/keyboard input, managing cursors, windows and menus, and drawing text and graphics in DHR; this provides an API with a MLI-like calling convention and is mostly understood, except for a handful of calls. It's pretty slick - fill patterns, polylines, bitmaps, cursors, menus, hit testing, proportional text rendering, 16-bit coordinates... everything you'd expect from a decent GUI library. This spans AUX $4000-$8500ish.
The bank switched memory in AUX $D000-$FFFF holds a tiny bit of code, but mostly resources (strings, bitmaps, menu definitions, points/rects, tables) and buffers for the windows/icons.
Everything else not taken up by ProDOS or DHR in both AUX and MAIN is the actual application, comprising the desktop logic, the contents of windows, and actions performed on volumes/files - dialog input loops and the actual ProDOS MLI work. The segments which are initially loaded are in the process of being understood (e.g. working backwards from string and bitmap resources it's possible to identify the handlers for various menu items and dialogs). Overlays are pulled in for operations with additional UI (e.g. disk copy) and I haven't dug into those yet.
There are some interesting things lurking in the code. For example, in the initial launch sequence which overrides the ProDOS QUIT handler (twice), there's an unreferenced block of code which can dump the DHR screen to an ImageWriter printer attached to an SSC in slot 1. I suspect this was used to generating screenshots for the manual, and could be hooked up by altering a few bytes. The code is all 6502, not 65C02. There are inconsistencies in coding style, but it's overall pretty elegant... if a bit pokey. The DAs are particularly buggy and have a fair bit of dead code.
If anyone is interested in helping... well, PRs welcome. :) The code base is large enough that assistance in deciphering it would be handy, although coordination would be required. There's definitely enough documented to produce custom DAs - I started documenting the lifecycle at https://github.com/inexorabletash/a2d/blob/master/desk.acc/a2d.md but that could definitely be improved.

Very cool project, and nice work on documenting your findings.

Do you know if there is any relation between the MouseText-based MouseFiler util (1986) and A2Desktop? MouseFiler has 3x segs totaling about 52K.

I submitted an issue on Github. Desktop crashes on ProDOS 2.x on a smartport card with 3+ volumes mounted. I suspect Desktop is trying to directly call the card's driver and crashing because the 3rd volumes was remapped by ProDOS 2 to an empty slot.

Oh, and +1 for a Merlin32 version in the future.

-JB
@JBrooksBSI

[Antoine Vignau]

Yes, cool project! Why did you call it A2D if the name is Mousedesk?

av

[i***@gmail.com]

Post by John Brooks
Do you know if there is any relation between the MouseText-based MouseFiler util (1986) and A2Desktop? MouseFiler has 3x segs totaling about 52K.

Taking a quick peek.... no author names in common. That's all I know.

Post by John Brooks
I submitted an issue on Github. Desktop crashes on ProDOS 2.x on a smartport card with 3+ volumes mounted. I suspect Desktop is trying to directly call the card's driver and crashing because the 3rd volumes was remapped by ProDOS 2 to an empty slot.

Thanks! Responded there, but a quick note here: this has the same root cause as the issue where my Floppy Emu-based HDs show up as 3.5" disk icons. The app decodes the unit_number bits in DEVLST and accesses the slot directly and trusts the lower nibble, in violation of ProDOS Tech Note 21. It needs to follow the protocol there instead. And ideally would also query SmartPort devices to distinguish device types.

Fortunately, while the code is big it is not particularly dense; there's a fair bit of padding between absolutely located segments, and there looks to be lots of potential for code size optimization. So squeezing a rewrite of that logic in seems doable.

The issues track interesting findings along the way, e.g. why it crashes on exit on non-GS systems (issue #3), where double-click timing is processed (#2), etc.

Post by John Brooks
Yes, cool project! Why did you call it A2D if the name is Mousedesk?

So far as I've been able to reconstruct the history: Version Soft (French company) created MouseDesk and iterated on it for several versions, evolving the GUI from Lisa-like look and feel to Mac-like. The product was licensed/sold in the US by International Software through version 2. It was rebranded as Apple II Desktop at some point. Then (speculation) Apple Computer was ready to ship the IIGS but GS/OS was not ready so Apple bought out the distribution license and included it on the early GS system disks.

The software had minor tweaks and improvements along the way (and also some functionality removed). The latest version (Nov 1986) was branded "Apple II DeskTop Version 1.1" so that's what I've used. There are still elements of "MouseDesk" in the code, e.g. if you lack a system clock and use the Date DA to set the date the code attempts to write a timestamp at a particular offset into the "MD.SYSTEM" file, which doesn't exist.

https://mirrors.apple2.org.za/ground.icaen.uiowa.edu/MiscInfo/Misc/mousedesk.info was extremely helpful in understanding he history.

[Antoine Vignau]

Post by i***@gmail.com
So far as I've been able to reconstruct the history: Version Soft (French company) created MouseDesk and iterated on it for several versions, evolving the GUI from Lisa-like look and feel to Mac-like. The product was licensed/sold in the US by International Software through version 2. It was rebranded as Apple II Desktop at some point. Then (speculation) Apple Computer was ready to ship the IIGS but GS/OS was not ready so Apple bought out the distribution license and included it on the early GS system disks.
The software had minor tweaks and improvements along the way (and also some functionality removed). The latest version (Nov 1986) was branded "Apple II DeskTop Version 1.1" so that's what I've used. There are still elements of "MouseDesk" in the code, e.g. if you lack a system clock and use the Date DA to set the date the code attempts to write a timestamp at a particular offset into the "MD.SYSTEM" file, which doesn't exist.
https://mirrors.apple2.org.za/ground.icaen.uiowa.edu/MiscInfo/Misc/mousedesk.info was extremely helpful in understanding he history.

OK, I did not know it was rebranded.

For the story: IS was a subsidiary of Version Soft. See it as Version Soft US. Luc Barthelet was the CEO there.
Luc B. and Henri L. then worked for Apple on the toolbox of the IIgs (mainly on the printer part).
Apple was not ready for a Finder-like app, so they sold the IIgs with IS' MouseDesk (v2 if I'm correct)

I suppose you are working on what I call MouseDesk 2.0

Antoine

[Antoine Vignau]

Oh, I almost forgot. I opened the different source code disk images of Version Soft I have but none will help you, apart from the fact that the Apple Mouse interface sessions and disks may help you understand how they coded the mouse interface part.

http://www.brutaldeluxe.fr/documentation/forumdesdeveloppeurs.html

Antoine

[i***@gmail.com]

Thanks!

The MouseGraphics Toolkit references are intriguing. I also noted that on the Syndicomm site and put in an order a few months ago... but haven't heard anything. I don't know if A2D's GUI lib is that or something custom.

[Oliver Schmidt]

Hi John,

Post by John Brooks
Oh, and +1 for a Merlin32 version in the future.

I'm having a hard time to see what's wrong with ca65/ld65 for pure
8bit dev.

I'd rather see the effort spent to provide more content instead of the
same content in different format - just my two cents.

Regards,
Oliver

[MG]

Post by Oliver Schmidt
Hi John,

Post by John Brooks
Oh, and +1 for a Merlin32 version in the future.

I'm having a hard time to see what's wrong with ca65/ld65 for pure
8bit dev.
I'd rather see the effort spent to provide more content instead of the
same content in different format - just my two cents.

I'll throw my 2 cents in...

I believe the same, and find ca65 to be relatively easy to work with, and not so hard to bend to my will. Porting effort from other assemblers isn't that difficult.

You will notice that almost all of my projects I use ca65, so I am not trying to come off as anything more than a constructive critic here...

What you have though, is two major things. One is preconceived notions on what an "Apple II assembler" is. Well, my answer is simply "it's not an Apple II assembler, it's a 65xx assembler." But, for Apple II development it is a bit of a departure in terms of how it deals with certain things, and if that's what you are used to, it's what you are used to. The other major thing is inter-operability.

Based on my observations, what would help ca65 "get along" better in the Apple II world?

As to my preconceived notions... When I got back into Apple II/6502 programming, I went with ca65 as a cross-assembler because it could run on my operating systems I was using at the time. I wasn't specifically looking at Apple II programming as much as I was looking at designing my own '816 machine. But I ended up going back to my childhood machines and scrapping my project, and I took ca65 with me. I hadn't programmed the 6502 since I was using LISA 2.5D, so those memories were old and worn out. But the fact is that you aren't going to get around preconceived notions about what assembler directives should look like, whether labels have colons, etc. It's opinion and experience and its up to an individual to change their mind there. So I won't even talk about how to address this bias.

So for technical things...

So, for starters it would be nice if it could either directly output, or have a tool that converted its object files into OMF so that could be linked with the output of the IIgs tool chains or run on a IIgs directly.

OMF is the de-facto standard for object files in the Apple II world, and it is the only format for GS/OS load files. As I've gotten deeper into some of the rabbit holes around the Apple II, I've been more and more exposed to the MPW '816 assembler and Merlin, and I see the value in this interoperability. Linux and Windows users don't have access to Kelvin's excellent MPW emulator, so they have Merlin32 or nothing if they want to program for the IIgs. There were only two systems that were widespread and based on the 65816, and ca65 can't even build executables for one of them.

And maybe include a macro pack that implemented some of the "Apple II" conventions. I am willing to contribute what I have done in this area. This would address a lot of the people who merely like org instead of .org, for instance.

And last thing I can think of right now, a .feature that enabled loose string and loose char terms, and set the high bit based on the quotes used. Nearly every Apple II assembler that didn't have MSB ON/OFF supported this format. MSB ON/OFF can be done in macros, but if there's a way to detect which quoting was used in a macro, I have missed it.

MG

[Oliver Schmidt]

Hi,

Post by MG

Post by Oliver Schmidt
I'm having a hard time to see what's wrong with ca65/ld65 for pure
8bit dev.

I'll throw my 2 cents in...

First of all thanks for your comprehensive posting !

Post by MG
You will notice that almost all of my projects I use ca65, so I am not tryi=
ng to come off as anything more than a constructive critic here...

Surely.

Post by MG
I hadn't programmed the 6502 since I was us=
ing LISA 2.5D, so those memories were old and worn out.

I used LISA back then too...

Post by MG
But the fact is th=
at you aren't going to get around preconceived notions about what assembler=
directives should look like, whether labels have colons, etc. It's opinio=
n and experience and its up to an individual to change their mind there. S=
o I won't even talk about how to address this bias.

I must admit that I never even thought about that aspect. Likely I'm
just not writing enough ASM code to have preconceived notions at all
;-)

Post by MG
So for technical things...
[quite some IIgs / 65816 aspects]

Please note that I wrote above "for pure 8bit dev". When it comes to
the IIgs I absolutely see that ca65 isn't the tool to use!

Post by MG
And last thing I can think of right now, a .feature that enabled loose stri=
ng and loose char terms,

I guess you are aware of all the .feature settings:
http://cc65.github.io/doc/ca65.html#ss11.43

There's (among quite some others):
- loose_char_term
- loose_string_term
- missing_char_term

Post by MG
and set the high bit based on the quotes used. Ne=
arly every Apple II assembler that didn't have MSB ON/OFF supported this fo=
rmat. MSB ON/OFF can be done in macros, but if there's a way to detect whi=
ch quoting was used in a macro, I have missed it.

Recently https://github.com/cc65/cc65/blob/master/asminc/apple2.mac
was added. See
https://github.com/cc65/cc65/blob/master/libsrc/apple2/irq.s#L41 for a
usage.

Regards,
Oliver

[John Brooks]

Post by MG

Post by Oliver Schmidt
Hi John,

Post by John Brooks
Oh, and +1 for a Merlin32 version in the future.

I'm having a hard time to see what's wrong with ca65/ld65 for pure
8bit dev.
I'd rather see the effort spent to provide more content instead of the
same content in different format - just my two cents.

I'll throw my 2 cents in...
I believe the same, and find ca65 to be relatively easy to work with, and not so hard to bend to my will. Porting effort from other assemblers isn't that difficult.
You will notice that almost all of my projects I use ca65, so I am not trying to come off as anything more than a constructive critic here...
What you have though, is two major things. One is preconceived notions on what an "Apple II assembler" is. Well, my answer is simply "it's not an Apple II assembler, it's a 65xx assembler." But, for Apple II development it is a bit of a departure in terms of how it deals with certain things, and if that's what you are used to, it's what you are used to. The other major thing is inter-operability.
Based on my observations, what would help ca65 "get along" better in the Apple II world?
As to my preconceived notions... When I got back into Apple II/6502 programming, I went with ca65 as a cross-assembler because it could run on my operating systems I was using at the time. I wasn't specifically looking at Apple II programming as much as I was looking at designing my own '816 machine. But I ended up going back to my childhood machines and scrapping my project, and I took ca65 with me. I hadn't programmed the 6502 since I was using LISA 2.5D, so those memories were old and worn out. But the fact is that you aren't going to get around preconceived notions about what assembler directives should look like, whether labels have colons, etc. It's opinion and experience and its up to an individual to change their mind there. So I won't even talk about how to address this bias.
So for technical things...
So, for starters it would be nice if it could either directly output, or have a tool that converted its object files into OMF so that could be linked with the output of the IIgs tool chains or run on a IIgs directly.
OMF is the de-facto standard for object files in the Apple II world, and it is the only format for GS/OS load files. As I've gotten deeper into some of the rabbit holes around the Apple II, I've been more and more exposed to the MPW '816 assembler and Merlin, and I see the value in this interoperability. Linux and Windows users don't have access to Kelvin's excellent MPW emulator, so they have Merlin32 or nothing if they want to program for the IIgs. There were only two systems that were widespread and based on the 65816, and ca65 can't even build executables for one of them.
And maybe include a macro pack that implemented some of the "Apple II" conventions. I am willing to contribute what I have done in this area. This would address a lot of the people who merely like org instead of .org, for instance.
And last thing I can think of right now, a .feature that enabled loose string and loose char terms, and set the high bit based on the quotes used. Nearly every Apple II assembler that didn't have MSB ON/OFF supported this format. MSB ON/OFF can be done in macros, but if there's a way to detect which quoting was used in a macro, I have missed it.
MG

We are getting off-topic, so I'll just summarize:

Benefits of Merlin src vs ca65:

1) Listings can calc code-block cycle counts for all 65xx processors

2) Assemble to bin or rel on an Apple II,II+,//e,//c,GS with Merlin8

3) Assemble (as 8-bit or 16-bit) to bin/rel/OMF on a IIGS with Merlin16

4) Cross-assemble on Mac/PC/Linux to bin/rel/OMF with Merlin32

5) Share code (same syntax!) to or from other Merlin src apps

6) Easy to migrate 8-bit code to GS apps

7) Large collection of legacy Merlin programs, books, magazines, listings to share with

8) Merlin8 & Merlin32 are open source, so improving them helps all the above


Benefits of ca65 src vs Merlin8+Merlin16+Merlin32:

?


-JB
@JBrooksBSI

[Antoine Vignau]

I'm a Merlin X user only, on Apple IIs only.
I tried to enter the acme/cx65 syntax but I find them not Apple II native and more C oriented.

Those target all 6502 machines, Merlin X target the Apple II. On one side, the assemblers provide compatibility with Commodore, VIC and the Apple II. On the other side, support is provided for the different Apple II machines.

People will never change, the discussion thirty years ago was APW vs MPW vs Merlin. We have new toys but that is the same discussion.

All I know is that I will follow your deconstruction, may provide info if I find some relevant, but no more, I just cannot enter the ccxx world

av

[MG]

We are, and to keep my response short, I concede almost all of your points with a few rebuttals.

Your 2, 3, and only come into play if one intends to move code to the target platform and assemble it. For me, that's a not really happening because even though I love my old machines, I like the speed at which things happen on my new machine. I like my makefiles and editor with split screens and limitless memory. As an example, in my davex utilities, the documentation is embedded in comments in the code, and I have a small script that extracts them and formats them appropriate for the Apple II at build time. While I could make this happen with Merlin32, it isn't happening on the other Merlins.

Your 8: ca65 is also open-source, with the exception of the support for one particular processor.
* The main thing for me is the segment support. It makes doing certain things rather trivial.

* There's a C compiler that targets it... not that I've felt a necessity to attempt to write C code for the 6502, but the option is there.

* Cf. your 6: easily migrate code to other 8-bit 65xx platforms.

Let's not start a "holy war", though. I also happen to like the MPW IIgs assembler after using it a fair bit to play with a certain codebase...

I will say this: I'm not really "put off" by the choice of an assembler. If a project I want to contribute to is in Merlin, I will use Merlin, if it's in ca65, I will use ca65, etc.

To pull out a good old fashioned car analogy: When I go on a road trip, I don't do it to enjoy the car, I do it to enjoy the destination. Having a car I like is nice, but I'm not going to cancel the trip just because everyone else going on the trip likes a different car.

MG

[Oliver Schmidt]

Hi,

Post by MG
Let's not start a "holy war", though.

Full ACK! Let's recapitulate:

The OP is presenting significant effoert here for the benefit of the
community.

He chooses one format among several viable options to do so - and what
does he get as feedback: Being asked to add another format!

We shouldn't be surprised to find that this behavior rather puts him
off to continue his effort (or share the results with us).

Post by MG
I will say this: I'm not really "put off" by the choice of an assembler. =
If a project I want to contribute to is in Merlin, I will use Merlin, if it=
's in ca65, I will use ca65, etc.

Exactly.

Post by MG
To pull out a good old fashioned car analogy: When I go on a road trip, I =
don't do it to enjoy the car, I do it to enjoy the destination. Having a c=
ar I like is nice, but I'm not going to cancel the trip just because everyo=
ne else going on the trip likes a different car.

You hit that nail square on the head!

Regards,
Oliver

[i***@gmail.com]

Post by Oliver Schmidt
We shouldn't be surprised to find that this behavior rather puts him
off to continue his effort (or share the results with us).

Don't worry, I'll just ignore it. I let others dictate priorities in my day job. For a hobby project I'll just muddle forward with my own approach, picking and choosing what feedback to incorporate.

[Oliver Schmidt]

Hi,

Post by John Brooks
1) Listings can calc code-block cycle counts for all 65xx processors

I see.

Post by John Brooks
2) Assemble to bin or rel on an Apple II,II+,//e,//c,GS with Merlin8
3) Assemble (as 8-bit or 16-bit) to bin/rel/OMF on a IIGS with Merlin16

;-)

Post by John Brooks
4) Cross-assemble on Mac/PC/Linux to bin/rel/OMF with Merlin32
6) Easy to migrate 8-bit code to GS apps

We're talking about pure 8bit dev here.

Post by John Brooks
5) Share code (same syntax!) to or from other Merlin src apps
7) Large collection of legacy Merlin programs, books, magazines, listings t=
o share with
8) Merlin8 & Merlin32 are open source, so improving them helps all the abov=
e
Benefits of Merlin src vs ca65
Merlin8 & Merlin32 are open source

Sorry but that doesn't actually improve your credibility ;-)

Post by John Brooks
?

This shows clearly that do you don't know ca65/ld65 or simply don't
want to know it. Therefore the worth of your assessment is after all
.. null.

Regards,
Oliver

[Steve Nickolas]

A couple switches should get you Merlin-like syntax out of CA65, right?

But I, personally, like the CA65 syntax better (because it's like the Z80
and x86 assemblers). ;)

The big limit has to do with OMF, doesn't it? I'm pretty sure you can do
65816 assembly just fine with CA65.

Worst case, it might be possible to write a .o -> .omf translator?

-uso.

[Egan Ford]

Post by Oliver Schmidt
Hi John,

Post by John Brooks
Oh, and +1 for a Merlin32 version in the future.

I'm having a hard time to see what's wrong with ca65/ld65 for pure
8bit dev.

Absolutely nothing. I am in the only-use-cross-assembler camp.
ca65/ld65 makes it easy to use editors with a lot of lines, editor of
choice (vi), git, make/makefiles, computer generated tables/code, and
very rapid testing (via emulation).

For 65816/65802 I still use asl.

[Oliver Schmidt]

Hi,

There's a GUI library that handles mouse/keyboard input, managing cursors, =
windows and menus, and drawing text and graphics in DHR; this provides an A=
PI with a MLI-like calling convention and is mostly understood, except for =
a handful of calls. It's pretty slick - fill patterns, polylines, bitmaps, =
cursors, menus, hit testing, proportional text rendering, 16-bit coordinate=
s... everything you'd expect from a decent GUI library. This spans AUX $400=
0-$8500ish.

Maybe that GUI library could be made available not only to DAS but
also to ProDOS 8 system files loaded by A2D. Then one could end up
with something like GEOS. In case this would generaly work I'd be
interested to discuss integration into the cc65 delivery. Maybe
similiar to the exsisting cc65 GEOS support with the option to use C
as language.

Regards,
Oliver

[i***@gmail.com]

Post by Oliver Schmidt
Maybe that GUI library could be made available not only to DAS but
also to ProDOS 8 system files loaded by A2D. Then one could end up
with something like GEOS. In case this would generaly work I'd be
interested to discuss integration into the cc65 delivery. Maybe
similiar to the exsisting cc65 GEOS support with the option to use C
as language.

That would be very cool. The library is fairly well isolated already in the binary, and I'm keeping the source/headers distinct too:

https://github.com/inexorabletash/a2d/blob/master/a2d.inc
https://github.com/inexorabletash/a2d/blob/master/desktop/a2d.s

(Sorry about the naming. It should be 'gui' not 'a2d' or something. Maybe it will turn out to be the MouseGraphics Toolkit.)

I'm skeptical that inventing a launching convention just to keep it resident in memory would be worth it in this day and age, rather than just having each system file keep its own copy. But allowing use from C would be cool. (I'd also love additions to ca65 to make populating structs easier...)

[Oliver Schmidt]

Hi,

That would be very cool. The library is fairly well isolated already in the=

Cool!

I'm skeptical that inventing a launching convention just to keep it residen=
t in memory would be worth it in this day and age, rather than just having =
each system file keep its own copy.

Interestingly I originally want to propose just that. But I guessed
others wouldn't want to have the code duplicated on disk. However,
having the code in a "real" cc65 libary allows each system file to
link in only what it actually needs. And it makes the system file
independent for A2D

But allowing use from C would be cool.

:-)

(I'd also love additions to ca65 to make populating structs easier...)

Are you aware of http://cc65.github.io/doc/geos.html#ss4.5

Regards,
Oliver

[Oliver Schmidt]

Hi,

[...] GUI library [...]
[...] option to use C as language.

That would be very cool. [...]
I'm skeptical that inventing a launching convention just to keep it residen=
t in memory would be worth it in this day and age, rather than just having =
each system file keep its own copy. But allowing use from C would be cool. =

In the light of the recent posts in this thread it might make sense to
elaborate a bit more:

I understood that your primary goal was/is to understand A2D in order
to allow to improve it and add additional DAs.

I think the GUI of A2D is great. But that's a "problem": Every system
file you start looks/feels ugly compared to A2D (maybe with the
exception of mousepaint).

If that "problem" could be "solved" the momentum of A2D could reach a
completely new level.

Inorder to do so the GUI of A2D would need to be available for system
files. Either a) with the GUI code staying in RAM and being shared
(like e.g. done with GEOS) or b) with the GUI code becomeing part of
each system file.

The benefit of a) would be that the system files are smaller. GOES
came from the C64 with extemely slow disk i/o and from the time of
1xxkB floppies.

The benefit of b) would be that system files don't depend on being
lanched form A2D and that system files not requiring all of the GUI
code can omit the parts they don't need.

You already expressed that you prefere b) so in order to actually
realize the potential benefit of b) the GUI code should be
modularized. There should be some core always necessary and there
should be modules with optinal parts. I don't know how much effort you
can/want to spend for that modularization, but if you push that
modularization really far then ca65/ld65 is _THE_ tool for you.

E.g. the library for C programs consists of very many very small .s
files. They just export and reference symbols. The ld65 linker checks
which symbols are refenced by the actual user program and pulls in the
code from the .s files exporting those symbols. But that code
references other symbols. So that pulling in of code continues in a
recursive fashion until all references are satisfied. THen the code
pulled in is placed in memory according to the linker config file
rules. The result is a binary that contains only the code acually
required. That code is placed at different locations for every binary
but that doesn't hurt as the linker takes care of everything. And if
you need to find something in RAM afterards then look at the map file
showing what went where.

So you could reengineer the A2D GUI code to work in the same way the
libary for C programs works.

Additionally you can provide a thin layer on top of the API of the GUI
code to make the code callable from C programs. I've done such a
retrofitting of a C callable layer on top of an existing library
recently with the IP65 TCP/IP library. Here's the layer for the C
function dns_resolve() to give you a rough idea:
https://github.com/oliverschmidt/ip65/blob/master/ip65/dns_c.s

However, the C compiler doesn't know of memory bankng so if you want
to make use of AUXMEM then this would need to be done "inside" your
library. Anyhow, if you are interested in the C option then ca65/ld65
is obviously _THE_ tool for you because of the seamless integration of
C code with "real" libraries written in assembly.

Regards,
Oliver

[i***@gmail.com]

Post by Oliver Schmidt
I think the GUI of A2D is great. But that's a "problem": Every system
file you start looks/feels ugly compared to A2D (maybe with the
exception of mousepaint).

Even MousePaint looks and feels clunky when you have spent enough time with A2D. But yes, I totally agree. The elegance of the original Mac L&F - as mostly captured by A2D - is hard to overstate, and what attracts me to the project.

Post by Oliver Schmidt
You already expressed that you prefere b) so in order to actually
realize the potential benefit of b) the GUI code should be
modularized. There should be some core always necessary and there
should be modules with optinal parts. I don't know how much effort you
can/want to spend for that modularization, but if you push that
modularization really far then ca65/ld65 is _THE_ tool for you.

Definitely a goal. We'll see how long the momentum keeps up. Realistically I expect my interest to wax and wane, as with many other hobby projects. This certainly doesn't need to limited to my ability to carry the torch, of course.

Post by Oliver Schmidt
E.g. the library for C programs consists of very many very small .s
files. They just export and reference symbols. The ld65 linker checks
which symbols are refenced by the actual user program and pulls in the
code from the .s files exporting those symbols.

(snipping lots of good stuff)

Yep, agreed, sounds like a fabulous direction. It's just a long way off at this point since we need to get the original fully (or at least sufficiently) understood. Well... I suppose work on the GUI library could spin up in parallel (if it doesn't turn out to be one of the existing graphics toolkits already mentioned on this thread!), but that would likely require forking the code to keep the DeskTop app able to build byte-identical...

(Aside: There's probably a lot more modularization and linker hijinks that could be done to the source as-is to make it easier to read. I'm using ca65/ld65 in the most naive possible way. Suggestions welcome.)

[Steve Nickolas]

Post by i***@gmail.com
(Aside: There's probably a lot more modularization and linker hijinks
that could be done to the source as-is to make it easier to read. I'm
using ca65/ld65 in the most naive possible way. Suggestions welcome.)

Same as when I use ca65. ;)

-uso.

[MG]

Post by i***@gmail.com
(Aside: There's probably a lot more modularization and linker hijinks
that could be done to the source as-is to make it easier to read. I'm
using ca65/ld65 in the most naive possible way. Suggestions welcome.)

For any code that gets copied elsewhere, using segments and telling the linker the load and run addresses simplifies moving things around, and also enables some bounds checking and such. The linker can automatically generate symbols for the load address, run address, and length.

Here's a linker config I am currently using for one of my projects:

MEMORY {
LOAD1: start = $2000, size = $3F00;
RUN1: start = $8900, size = $3500;
GLOBAL1: start = $BE00, size = $100;
}

SEGMENTS {
loader: load = LOAD1, align = $100;
global: load = LOAD1, run = GLOBAL1, define = yes, align = $100;
interp: load = LOAD1, run = RUN1, define = yes, align = $100;
code: load = LOAD1;
}

Then, I don't have to worry about the particulars of how things fit together during the load process. On top of that when the the RUN1 size is exceeded, ca65 tells me so and I know that I've got to move it down a page in order to keep it located properly. The linker automatically maintains the origins.

Here's a routine that makes use of it:

; move interpreter
LDR_MOVE_BASIC
lda #<__interp_LOAD__
ldy #>__interp_LOAD__
sta ZP_A1
sty ZP_A1+1
lda #<(__interp_LOAD__+__interp_SIZE__)
ldy #>(__interp_LOAD__+__interp_SIZE__)
sta ZP_A2
sty ZP_A2+1
lda #<__interp_RUN__
ldy #>__interp_RUN__
sta ZP_A4
sty ZP_A4+1
ldy #$00 ; required to move properly
jsr F8_MOVE ; firmware move routine
rts

and later, simply a JMP __interp_RUN__ to get things going.

[Oliver Schmidt]

Hi,

(Aside: There's probably a lot more modularization and linker hijinks=20
that could be done to the source as-is to make it easier to read. I'm=20
using ca65/ld65 in the most naive possible way. Suggestions welcome.)

For any code that gets copied elsewhere, using segments and telling the lin=
ker the load and run addresses simplifies moving things around, and also en=
ables some bounds checking and such. The linker can automatically generate=
symbols for the load address, run address, and length. =20
[...]

Well phrased. When I get it right then the project at hand is about
first expressing the current code in assembler source that when built
recreates the given code. Later the assembler source is to be
modified. At least theoretically the assembler source should be usable
to build a library for system programs where the individual parts are
arranged in a totally different way.

In such a scenario it helps to be able to express the structure of the
binary that is built in the linker configuration and keep it this way
out of the source files. To me it's a bit like the separation of
content and structure discussed in creation of web pages. When the
assembler source is free of address constants (apart from external
constants like H/W or O/S constants) then it can be reused without
modification to both recreate the original code as well build
something pretty different. Especially ORG directives (and similar
constructs) have no raison d'être in a ca65 project.

A small project nevertheless maybe illustrating the above is a
deconstruction of the Slinky ROM. It's a 4kB binary with the first
half being mapped to the $100 byte slot ROMs areas and the second half
being mapped as $800 byte $C800 ROM. That structure is represented as
linker config file:
https://github.com/a2retrosystems/mxp/blob/master/slinky/rom/rom.cfg

Note that the tpye of the segments is 'r/o'. The linker will give you
an error if you try to build a binary with write access to a 'r/o'
segment. So you might want to at some point place e.g. a DHGR
pre-shift table in an own r/o segment.

Another thing to mention is the use of the 'offset' attribute. One
would usually think that several 'memory areas' are the only way to
"force" things at a certain address. But you can as well use fewer
memory areas and then inside each memory area use segments with
offsets - which I choose here.

But I even went a step further and divided the slot ROMs in two
segments: The $Cx00 entry point for booting and the $CxFA Smartport
table. This way there's no padding whatsoever in the assembler source
code. Rather all necessary padding is done by the single 'fill = yes'
in the linker config file.

So if the padding in A2D would be expressed in a linker config file
then it would help to create somehting different from the same
assemble source files that doesn't need that padding.

Regards,
Oliver

[John Brooks]

a2d.s looks a lot like the Apple Pascal Mouse Toolkit from 1985. Anyone know if A2Desktop is using that lib?

The tables at L4221 to L47A1 are DHGR pre-shift tables which convert 7 pixels in a byte into the bytes to store in aux & main memory:

L4221: Shift 1 aux
L42A1: Shift 1 main
L4321: Shift 2 aux
L43A1: Shift 2 main
...

L4821 is a div7 table to find which byte to write to for a given 8-bit X pos

L4921 is a mod7 table with the remainder after div7 (used to select a L4221... shift table)

L5C24 looks like the quickdraw fast-path draw unclipped pattern slab

L5CC0 looks like the quickdraw slow-path darw clipped pattern slab

Post by MG
Your 2, 3, and only come into play if one intends to move code to the target platform and assemble it.

Yes, and for open-source community projects, one being anyone, and time being anytime in the future. :)

Post by MG
To pull out a good old fashioned car analogy: When I go on a road trip, I don't do it to enjoy the car, I do it to enjoy the destination. Having a car I like is nice, but I'm not going to cancel the trip just because everyone else going on the trip likes a different car.

Agreed that it's important to use the right tool for the job. Hence my vote for +1 Merlin in the future.

Fracturing into multiple incompatible formats is akin to building incompatible roads which causes the problem that you can't take your trip because your car is not allowed on those roads.


We are all hobbyists free to use our time and tools as we see fit. But if we want to share and collaborate as a community, I think it makes sense to analyze the pros and cons of our tools and choices.

-JB
@JBrooksBSI

[i***@gmail.com]

Awesome, thanks! As you may have noted, I'm picking things off in a fairly random order - easy stuff, and then stuff that becomes easy when the other stuff is identified. Or when I really want to identify a particular routine (e.g. the double click handler). More eyeballs are VERY much appreciated since "easy" is relative.

[John Brooks]

Post by i***@gmail.com
Awesome, thanks! As you may have noted, I'm picking things off in a fairly random order - easy stuff, and then stuff that becomes easy when the other stuff is identified. Or when I really want to identify a particular routine (e.g. the double click handler). More eyeballs are VERY much appreciated since "easy" is relative.

I'm pretty sure a2d is a later rev of the Mouse Graphics Toolkit GUI which was distributed as part of the Pascal Toolkit in 1985. I'm guessing it's v2.7 based on the L5E51 init code #$71 byte.

See v2.1 MLI docs:
ftp://ftp.apple.asimov.net/pub/apple_II/documentation/programming/6502assembly/Developer's%20Handbook%20for%20the%20Apple%20II%20MouseText%20Tool%20Kit.pdf

Post by i***@gmail.com
Don't worry, I'll just ignore it. I let others dictate priorities in my day job. For a hobby project I'll just muddle forward with my own approach, picking and choosing what feedback to incorporate.

Exactly. I'm just up voting for a Merlin version in the future so when members of the community want to take an AppleII trip and build something neat on their Apple II, this code can be part of the ride. For example, I could see value in having a2d available as a ProDOS driver on extended-memory machines.

$.02

-JB
@JBrooksBSI

[i***@gmail.com]

Post by John Brooks
I'm pretty sure a2d is a later rev of the Mouse Graphics Toolkit GUI which was distributed as part of the Pascal Toolkit in 1985.

I also found the description in https://store.syndicomm.com/syn/apple-ii-prodos-desktop-toolkit/ very intriguing. Again, ordered it from Syndicomm back in October but haven't heard anything yet. :(

Post by John Brooks
I'm guessing it's v2.7 based on the L5E51 init code #$71 byte.
ftp://ftp.apple.asimov.net/pub/apple_II/documentation/programming/6502assembly/Developer's%20Handbook%20for%20the%20Apple%20II%20MouseText%20Tool%20Kit.pdf

There's nothing in the Mouse**Text** Tool Kit docs that convinces me one way or the other. The calling convention is similar but it's inspired by ProDOS MLI so that's not unique. The fundamental operations are the same (apart from where things are text oriented), but then those would be common to most GUI libraries and the command numbers are all different. Things like the window state bits for close/resize boxes are all different, menu accelerators are different, etc.

So: definite "maybe". Would love to know for sure, and my fingers are crossed that it's true - it would definitely save some time. (I somewhat tabled work on this after I placed the order back in October...) I'd love to identify the remaining commands. And maybe if it's a real thing we could entice Oliver to build up a nicer macro set... :)

[Antoine Vignau]

I'll double check in VS source code regarding the toolkit, maybe there are things closer to what you have,
av

[John Brooks]

Post by i***@gmail.com
So: definite "maybe". Would love to know for sure, and my fingers are crossed that it's true - it would definitely save some time. (I somewhat tabled work on this after I placed the order back in October...) I'd love to identify the remaining commands. And maybe if it's a real thing we could entice Oliver to build up a nicer macro set... :)

I took a quick look at the Apple Pascal 1.2 Mouse Graphics Toolkit that I have handy.

The GUI driver is a 16KB lib with a timestamp of Jun 1985. It reports version 1.0.0b5.

At $4000 it has:

1) Command dispatch code

2) Command dispatch jump table

3) DHGR pre-shift lookup tables

4) UI handlers & draw routines to ~8000


IE, it follows the general layout of a2d.


Differences:

1) v1.0 runs from main memory instead of aux (docs say UI code would move to aux after v1.2)

2) It is closer to LISA/Mac quickdraw - uses loops instead of unrolled 6502, and a more direct translation of 68000 QD


I think I have the later APDA Pascal & ProDOS versions of the Desktop libs around somewhere. I'll see if I can find them and compare vs 1.0 & the a2d version.

-JB
@JBrooksBSI

[John Brooks]

Post by John Brooks

Post by i***@gmail.com
So: definite "maybe". Would love to know for sure, and my fingers are crossed that it's true - it would definitely save some time. (I somewhat tabled work on this after I placed the order back in October...) I'd love to identify the remaining commands. And maybe if it's a real thing we could entice Oliver to build up a nicer macro set... :)

I took a quick look at the Apple Pascal 1.2 Mouse Graphics Toolkit that I have handy.
The GUI driver is a 16KB lib with a timestamp of Jun 1985. It reports version 1.0.0b5.
1) Command dispatch code
2) Command dispatch jump table
3) DHGR pre-shift lookup tables
4) UI handlers & draw routines to ~8000
IE, it follows the general layout of a2d.
1) v1.0 runs from main memory instead of aux (docs say UI code would move to aux after v1.2)
2) It is closer to LISA/Mac quickdraw - uses loops instead of unrolled 6502, and a more direct translation of 68000 QD
I think I have the later APDA Pascal & ProDOS versions of the Desktop libs around somewhere. I'll see if I can find them and compare vs 1.0 & the a2d version.
-JB
@JBrooksBSI

I found the APDA version of Desktop Toolkit. The ProDOS version is newer than the Pascal Mouse Graphics Toolkit, but older than the A2Desktop a2d.

APDA DT has the larger command jump table and it nearly matches a2d, but a2d has a couple more commands than the APDA version.

APDA DT has a$41 nibble (v1.4) vs 1.0 for Pascal and 1.7 for a2d.

The APDA manual looks helpful though as it gives the names of the commands and parameters, and seems to match quite closely with a2d.

-JB
@JBrooksBSI

[i***@gmail.com]

I found the APDA version of Desktop Toolkit....

After consulting with John offline and consulting some further references: confirmed, what I called "a2d" is a version of the Mouse Graphics Tool Kit which has a Graphics Primitives layer included. I'll go through the process of updating my terminology to match (e.g. rename to mgtk, and all the internals)

So... were any other applications shipped that used this?

[John Brooks]

Post by i***@gmail.com

I found the APDA version of Desktop Toolkit....

After consulting with John offline and consulting some further references: confirmed, what I called "a2d" is a version of the Mouse Graphics Tool Kit which has a Graphics Primitives layer included. I'll go through the process of updating my terminology to match (e.g. rename to mgtk, and all the internals)
So... were any other applications shipped that used this?

MousePaint and Multiscribe (BeagleWrite) used DHGR desktop GUIs IIRC. No idea if they used this lib though.

-JB

[John Brooks]

Post by John Brooks

Post by i***@gmail.com

I found the APDA version of Desktop Toolkit....

After consulting with John offline and consulting some further references: confirmed, what I called "a2d" is a version of the Mouse Graphics Tool Kit which has a Graphics Primitives layer included. I'll go through the process of updating my terminology to match (e.g. rename to mgtk, and all the internals)
So... were any other applications shipped that used this?

MousePaint and Multiscribe (BeagleWrite) used DHGR desktop GUIs IIRC. No idea if they used this lib though.
-JB

MousePaint is 1984 and looks like an early version of the Mouse Graphics Toolkit.

BeagleWrite is 1989 has GUI that is more advanced and polished than other DHGR apps, and looks like it could be using the MGT lib.

BeagleWrite includes a GUI font editor which is only 33K, so that would be a good target app to investigate.

-JB
@JBrooksBSI

[mdj]

Post by John Brooks
Exactly. I'm just up voting for a Merlin version in the future so when members of the community want to take an AppleII trip and build something neat on their Apple II, this code can be part of the ride. For example, I could see value in having a2d available as a ProDOS driver on extended-memory machines.

As long as whatever toolchain is used for the project can generate a REL file, an 'include' for Merlin users should be easy to add.

[Todd Holcomb]

Thank you for doing this - I would love to see a new version of Apple II Desktop! This could be the perfect OS for the speedy IIc+ with a HD or emulated HD.

In addition to the IIc+ constant internal disk access bug, the mouse pointer tends to drop down to the bottom of the screen and stay there on the IIc+. This happens at normal and fast speed. Not sure if that bug has been reported before.

Also, all the versions I've tried make you quit into the desktop mode upon boot. It would be nice to boot directly into the desktop.

I can't help with the programming, but let me know if you need anyone to test on the IIc+ when the time comes.

Todd

[i***@gmail.com]

Post by Todd Holcomb
In addition to the IIc+ constant internal disk access bug, the mouse pointer tends to drop down to the bottom of the screen and stay there on the IIc+. This happens at normal and fast speed. Not sure if that bug has been reported before.

Nope - add it as https://github.com/inexorabletash/a2d/issues/47

Post by Todd Holcomb
Also, all the versions I've tried make you quit into the desktop mode upon boot. It would be nice to boot directly into the desktop.

That should work today if DESKTOP.SYSTEM is the first SYSTEM file (or follows driver installers that chain correctly) in the volume directory. Worked in Virtual ][ when I just tied it.

[MG]

On Sunday, January 28, 2018 at 8:21:25 AM UTC-8, Todd Holcomb wrote:
In addition to the IIc+ constant internal disk access bug

That's not a bug in Apple II Desktop. That's a "feature" of the Apple IIc Plus firmware. It turns on the internal drive motor briefly whenever the SmartPort STATUS call is executed against the drive.

That being said, for a program that aims to detect when a disk has been inserted, issuing SmartPort STATUS to the drive is a perfectly reasonable thing to do, and no other controller in the Apple II world behaves this way as far as I know.

Probably the only real solution is to identify that it's running on a IIc Plus and disable polling the internal drive until the user clicks it.

MG

[Tony Cianfaglione]

There's a workaround at this url:

https://www.chebucto.ns.ca/Services/PDA/AppleIIMiscellaneous.shtml

---

Post by Todd Holcomb
In addition to the IIc+ constant internal disk access bug
That's not a bug in Apple II Desktop. That's a "feature" of the Apple IIc Plus firmware. It turns on the internal drive motor briefly whenever the SmartPort STATUS call is executed against the drive.
That being said, for a program that aims to detect when a disk has been inserted, issuing SmartPort STATUS to the drive is a perfectly reasonable thing to do, and no other controller in the Apple II world behaves this way as far as I know.
Probably the only real solution is to identify that it's running on a IIc Plus and disable polling the internal drive until the user clicks it.
MG

[James Davis]

Post by i***@gmail.com
As noted elsewhere, I'm taking on disassembly and documentation of the Apple II Desktop (a.k.a. A2D, a.k.a. MouseDesk) graphical shell for the Apple II.
Code and documentation are at: https://github.com/inexorabletash/a2d
* Get the code fully documented
* Get the code buildable with changes (i.e. no hard-coded addresses except documented entry points)
* Document the API (the GUI library and the app entry points needed by DAs)
* Fix known bugs in DAs and the app
* Code modernization.
* Add additional Desk Accessories. One is done already (an image viewer)
* Add additional functionality to the DeskTop app itself.
* Performance improvements (it's sluggish at 1MHz)
I'm using the issue tracker for feature requests/bug reports. I'm building it with ca65, and ensuring that it builds byte-identical for the moment.
The overall structure of the system is now reasonably well understood; see https://github.com/inexorabletash/a2d/blob/master/desktop/README.md which includes a breakdown of the file segments/overlays and the memory map. All the weird naming is my fault.
There's a GUI library that handles mouse/keyboard input, managing cursors, windows and menus, and drawing text and graphics in DHR; this provides an API with a MLI-like calling convention and is mostly understood, except for a handful of calls. It's pretty slick - fill patterns, polylines, bitmaps, cursors, menus, hit testing, proportional text rendering, 16-bit coordinates... everything you'd expect from a decent GUI library. This spans AUX $4000-$8500ish.
The bank switched memory in AUX $D000-$FFFF holds a tiny bit of code, but mostly resources (strings, bitmaps, menu definitions, points/rects, tables) and buffers for the windows/icons.
Everything else not taken up by ProDOS or DHR in both AUX and MAIN is the actual application, comprising the desktop logic, the contents of windows, and actions performed on volumes/files - dialog input loops and the actual ProDOS MLI work. The segments which are initially loaded are in the process of being understood (e.g. working backwards from string and bitmap resources it's possible to identify the handlers for various menu items and dialogs). Overlays are pulled in for operations with additional UI (e.g. disk copy) and I haven't dug into those yet.
There are some interesting things lurking in the code. For example, in the initial launch sequence which overrides the ProDOS QUIT handler (twice), there's an unreferenced block of code which can dump the DHR screen to an ImageWriter printer attached to an SSC in slot 1. I suspect this was used to generating screenshots for the manual, and could be hooked up by altering a few bytes. The code is all 6502, not 65C02. There are inconsistencies in coding style, but it's overall pretty elegant... if a bit pokey. The DAs are particularly buggy and have a fair bit of dead code.
If anyone is interested in helping... well, PRs welcome. :) The code base is large enough that assistance in deciphering it would be handy, although coordination would be required. There's definitely enough documented to produce custom DAs - I started documenting the lifecycle at https://github.com/inexorabletash/a2d/blob/master/desk.acc/a2d.md but that could definitely be improved.

I never found much use for a GUI (e.g., GEOS, anyway) on an Enh. Apple //e, without a mouse. But, to be fair, I never tried them on real hardware; I have only looked at them on AppleWin, recently (last year).

[f***@hotmail.com]

Fun project! I had sort of forgotten about Apple II DeskTop (capital 'T'?). I never really liked those green phosphor monitor ///s but A2D is a great use for them. Would be nice to have joystick support if it is currently mouse-only, just because there are probably more of them out there in the wild (not sure if it needs interrupts for anything beyond the mouse driver).
Frank

[Steve Nickolas]

Post by f***@hotmail.com
Fun project! I had sort of forgotten about Apple II DeskTop (capital
'T'?). I never really liked those green phosphor monitor ///s but A2D is
a great use for them. Would be nice to have joystick support if it is
currently mouse-only, just because there are probably more of them out
there in the wild (not sure if it needs interrupts for anything beyond
the mouse driver).
Frank

I don't think using the joystick requires interrupts. You got stick read
functions in the monitor firmware and can just use BIT to poll the
buttons.

-uso.

[i***@gmail.com]

Post by Steve Nickolas

Post by f***@hotmail.com
Fun project! I had sort of forgotten about Apple II DeskTop (capital
'T'?). I never really liked those green phosphor monitor ///s but A2D is
a great use for them. Would be nice to have joystick support if it is
currently mouse-only, just because there are probably more of them out
there in the wild (not sure if it needs interrupts for anything beyond
the mouse driver).
Frank

I don't think using the joystick requires interrupts. You got stick read
functions in the monitor firmware and can just use BIT to poll the
buttons.

I think the question went the other way: is there anything in A2D itself that requires a mouse card for interrupts?

Answer: not that I can determine. Works in Virtual II if I yank the mouse card out.

Although it doesn't support the joystick, it is keyboard accessible - I put a cheat sheet together: https://github.com/inexorabletash/a2d/blob/master/keyboard.md (This is documented in the early IIgs System Disk docs, too.)

[Todd Holcomb]

I just found this site which has a patch for the IIc+ drive bug:

https://www.chebucto.ns.ca/Services/PDA/AppleIIMiscellaneous.shtml

Todd

[MG]

Post by Tony Cianfaglione
https://www.chebucto.ns.ca/Services/PDA/AppleIIMiscellaneous.shtml
Todd

That's a workaround, not a patch. It adds Selector commands that execute BASIC programs that use an add-on BASIC.SYSTEM command to detach and reattach the device driver from ProDOS.

This is one of the two programs:

1 REM No.Floppies by Jay Edwards and Tony Cianfaglione - 2004
2 REM For help, email (redacted) or (redacted)
3 REM Prevents the computer from recognizing the 3.5 and 5.25 inch floppy drives.
5 REM Launching "YES.FLOPPIES" will undo "NO.FLOPPIES"
10 FOR PAUSE = 1 TO 1000000
15 PRINT CHR$ (4);"pr#3"
20 VTAB 5: HTAB 5: PRINT "Running No.Floppies...
30 VTAB 7: HTAB 5: PRINT "Now disconnecting your floppy drives!"
40 PRINT CHR$ (4)"-HOOK"
50 PRINT CHR$ (4)"UNHOOK,S6,D1"
60 PRINT CHR$ (4)"UNHOOK,S6,D2"
70 PRINT CHR$ (4)"UNHOOK,S5,D1"
80 PRINT CHR$ (4)"UNHOOK,S5,D2"
90 PRINT CHR$ (4)"BYE"

The correct fix is to reduce SmartPort STATUS calls to the IIc Plus smartport. The status call causes the brief access, and DeskTop makes constant STATUS calls in order to detect when a floppy is inserted.

What it should do is detect that it is running on a IIc Plus and either reduce the frequency of the calls to something less obnoxious, or (what I'd prefer) require "Check Drives" to be selected. Perhaps the action can be a preference item.

MG

[John Brooks]

Post by MG

Post by Tony Cianfaglione
https://www.chebucto.ns.ca/Services/PDA/AppleIIMiscellaneous.shtml
Todd

That's a workaround, not a patch. It adds Selector commands that execute BASIC programs that use an add-on BASIC.SYSTEM command to detach and reattach the device driver from ProDOS.
1 REM No.Floppies by Jay Edwards and Tony Cianfaglione - 2004
2 REM For help, email (redacted) or (redacted)
3 REM Prevents the computer from recognizing the 3.5 and 5.25 inch floppy drives.
5 REM Launching "YES.FLOPPIES" will undo "NO.FLOPPIES"
10 FOR PAUSE = 1 TO 1000000
15 PRINT CHR$ (4);"pr#3"
20 VTAB 5: HTAB 5: PRINT "Running No.Floppies...
30 VTAB 7: HTAB 5: PRINT "Now disconnecting your floppy drives!"
40 PRINT CHR$ (4)"-HOOK"
50 PRINT CHR$ (4)"UNHOOK,S6,D1"
60 PRINT CHR$ (4)"UNHOOK,S6,D2"
70 PRINT CHR$ (4)"UNHOOK,S5,D1"
80 PRINT CHR$ (4)"UNHOOK,S5,D2"
90 PRINT CHR$ (4)"BYE"
The correct fix is to reduce SmartPort STATUS calls to the IIc Plus smartport. The status call causes the brief access, and DeskTop makes constant STATUS calls in order to detect when a floppy is inserted.
What it should do is detect that it is running on a IIc Plus and either reduce the frequency of the calls to something less obnoxious, or (what I'd prefer) require "Check Drives" to be selected. Perhaps the action can be a preference item.
MG

Seems like the best fix would be to avoid the IIc+ firmware altogether and just check the disk regs directly (assuming the brief disk access during a STATUS is due to firmware behavior).

-JB
@JBrooksBSI

[MG]

Post by John Brooks
Seems like the best fix would be to avoid the IIc+ firmware altogether and just check the disk regs directly (assuming the brief disk access during a STATUS is due to firmware behavior).

The problem being that we don't know the exact interaction between the MIG and the IWM in the area of IIc Plus internal drive - the MIG controls the HDSEL and and /3.5DRIVE signals. Also, the internal drive is special-cased according to the IIc Plus schematics and available documentation for the MIG via the /INTEN signal. While I have figured out what some of the MIG's address space does, I don't know enough about how the 3.5" drives are controlled to know what to make of it. But I did figure out how to make the MIG strobe HDSEL and ENB2...

At any rate, I'm guessing it would require some very IIc Plus-specific code to match the unique hardware.

It would be worth the effort to disassemble the IIc Plus firmware to figure out exactly what it's doing. The main bank has a high degree of commonality with the ROM 4 //c. The aux bank, while many chunks are moved, has a lot of commonality as well in regards to the non-disk code. I've already disassembled the accelerator code. So that leaves the disk code as the remaining "hard" part.

MG

[John Brooks]

Post by MG

Post by John Brooks
Seems like the best fix would be to avoid the IIc+ firmware altogether and just check the disk regs directly (assuming the brief disk access during a STATUS is due to firmware behavior).

The problem being that we don't know the exact interaction between the MIG and the IWM in the area of IIc Plus internal drive - the MIG controls the HDSEL and and /3.5DRIVE signals. Also, the internal drive is special-cased according to the IIc Plus schematics and available documentation for the MIG via the /INTEN signal. While I have figured out what some of the MIG's address space does, I don't know enough about how the 3.5" drives are controlled to know what to make of it. But I did figure out how to make the MIG strobe HDSEL and ENB2...
At any rate, I'm guessing it would require some very IIc Plus-specific code to match the unique hardware.
It would be worth the effort to disassemble the IIc Plus firmware to figure out exactly what it's doing. The main bank has a high degree of commonality with the ROM 4 //c. The aux bank, while many chunks are moved, has a lot of commonality as well in regards to the non-disk code. I've already disassembled the accelerator code. So that leaves the disk code as the remaining "hard" part.
MG

I would expect IWM driver code from the GS to be fairly portable to the IIc+. The main difference would likely be accessing the special IWM regs through the MIG.

Neil Parker has some good IWM direct-access info:
http://www.llx.com/cgi-bin/zcat/~nparker/a2/disk

-JB
@JBrooksBSI

[Tony Cianfaglione]

Post by MG
That's a workaround, not a patch. It adds Selector commands that execute
BASIC programs that use an add-on BASIC.SYSTEM command to detach and reattach > the device driver from ProDOS.
The correct fix is to reduce SmartPort STATUS calls to the IIc Plus smartport.
The status call causes the brief access, and DeskTop makes constant STATUS > calls in order to detect when a floppy is inserted.

---

Jay and I got tired of the constant running of the drives and the potential wear and tear on them from that effect, so Jay found that Bill Tudor's Hook program did what we wanted - a temporary way of shutting off the drives that the system wouldn't puke at (simply adding an off-on switch wouldn't do) and that's what we went with. We wrote two programs; a second one that would add them back to the system when necessary. Sorry if they're not fancy programs but they serve their purpose.

Since Hook is no longer available on Softdisk or by Syndicomm, I'm unsure of its status; whether the rights reverted back to Bill. It would be great if someone who knew Bill personally could ask him to declare the program freeware so it could be housed directly on our site or on Asimov.

Tony