| Apple II Desktop Deconstruction [message #361735] |
Sat, 27 January 2018 01:06  |
|
|
Originally posted by: inexorabletash
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/RE ADME.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/a 2d.md but that could definitely be improved.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361737 is a reply to message #361735] |
Sat, 27 January 2018 03:30  |
|
|
Originally posted by: John Brooks
On Friday, January 26, 2018 at 10:07:01 PM UTC-8, inexora...@gmail.com wrote:
> 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/RE ADME.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/a 2d.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
|
|
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361743 is a reply to message #361738] |
Sat, 27 January 2018 12:02 |
|
|
Originally posted by: inexorabletash
On Saturday, January 27, 2018 at 12:30:39 AM UTC-8, John Brooks wrote:
>
> 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.
> 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.
On Saturday, January 27, 2018 at 4:50:49 AM UTC-8, Antoine Vignau wrote:
> 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/MiscInf o/Misc/mousedesk.info was extremely helpful in understanding he history.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361771 is a reply to message #361743] |
Sat, 27 January 2018 15:10 |
Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, January 27, 2018 at 6:02:23 PM UTC+1, inexora...@gmail.com wrote:
> 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/MiscInf o/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
|
|
|
|
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361807 is a reply to message #361737] |
Sat, 27 January 2018 19:10 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi John,
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361808 is a reply to message #361735] |
Sat, 27 January 2018 19:20 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361820 is a reply to message #361807] |
Sat, 27 January 2018 20:21 |
|
|
Originally posted by: MG
On Saturday, January 27, 2018 at 4:10:46 PM UTC-8, Oliver Schmidt wrote:
> Hi John,
>
>> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361821 is a reply to message #361808] |
Sat, 27 January 2018 20:51 |
|
|
Originally posted by: inexorabletash
On Saturday, January 27, 2018 at 4:20:29 PM UTC-8, Oliver Schmidt wrote:
> 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/a2 d.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...)
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361824 is a reply to message #361820] |
Sat, 27 January 2018 22:10 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi,
>> 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 !
> 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.
> 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...
> 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
;-)
> 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!
> 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
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361825 is a reply to message #361821] |
Sat, 27 January 2018 22:16 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi,
> That would be very cool. The library is fairly well isolated already in the=
> binary, and I'm keeping the source/headers distinct too:
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361826 is a reply to message #361807] |
Sat, 27 January 2018 22:22 |
Egan Ford
Messages: 304
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 1/27/18 5:10 PM, Oliver Schmidt wrote:
> Hi John,
>
>> 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.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361838 is a reply to message #361820] |
Sun, 28 January 2018 00:53 |
|
|
Originally posted by: John Brooks
On Saturday, January 27, 2018 at 5:21:29 PM UTC-8, MG wrote:
> On Saturday, January 27, 2018 at 4:10:46 PM UTC-8, Oliver Schmidt wrote:
>> Hi John,
>>
>>> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361843 is a reply to message #361838] |
Sun, 28 January 2018 03:45 |
Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361848 is a reply to message #361838] |
Sun, 28 January 2018 04:59 |
|
|
Originally posted by: MG
On Saturday, January 27, 2018 at 9:53:12 PM UTC-8, John Brooks wrote:
> We are getting off-topic, so I'll just summarize:
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.
> Benefits of ca65 src vs Merlin8+Merlin16+Merlin32:
* 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361849 is a reply to message #361735] |
Sun, 28 January 2018 06:01 |
|
|
Originally posted by: 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
> 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. :)
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361851 is a reply to message #361838] |
Sun, 28 January 2018 06:14 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi,
> Benefits of Merlin src vs ca65:
>
> 1) Listings can calc code-block cycle counts for all 65xx processors
I see.
> 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
> 6) Easy to migrate 8-bit code to GS apps
We're talking about pure 8bit dev here.
> 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
Just let me put that together for the enjoyment of everybody:
> Benefits of Merlin src vs ca65
> Merlin8 & Merlin32 are open source
Sorry but that doesn't actually improve your credibility ;-)
> Benefits of ca65 src vs Merlin8+Merlin16+Merlin32:
>
> ?
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361852 is a reply to message #361848] |
Sun, 28 January 2018 06:24 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
Hi,
> 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).
> 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.
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361853 is a reply to message #361851] |
Sun, 28 January 2018 06:26 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
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.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361855 is a reply to message #361821] |
Sun, 28 January 2018 08:16 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361864 is a reply to message #361735] |
Sun, 28 January 2018 11:21 |
|
|
Originally posted by: 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361879 is a reply to message #361735] |
Sun, 28 January 2018 13:17 |
|
|
Originally posted by: James Davis
On Friday, January 26, 2018 at 10:07:01 PM UTC-8, inexora...@gmail.com wrote:
> 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/RE ADME.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/a 2d.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).
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361880 is a reply to message #361864] |
Sun, 28 January 2018 13:34 |
|
|
Originally posted by: inexorabletash
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, 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
> 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.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361881 is a reply to message #361849] |
Sun, 28 January 2018 14:06 |
|
|
Originally posted by: inexorabletash
On Sunday, January 28, 2018 at 3:01:44 AM UTC-8, John Brooks wrote:
> 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:
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.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361882 is a reply to message #361852] |
Sun, 28 January 2018 14:09 |
|
|
Originally posted by: inexorabletash
On Sunday, January 28, 2018 at 3:24:56 AM UTC-8, Oliver Schmidt wrote:
> 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.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361883 is a reply to message #361855] |
Sun, 28 January 2018 14:23 |
|
|
Originally posted by: inexorabletash
On Sunday, January 28, 2018 at 5:16:22 AM UTC-8, Oliver Schmidt wrote:
> 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.
> 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.
> 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.)
|
|
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361901 is a reply to message #361881] |
Sun, 28 January 2018 14:52 |
|
|
Originally posted by: John Brooks
On Sunday, January 28, 2018 at 11:06:15 AM UTC-8, inexora...@gmail.com wrote:
> On Sunday, January 28, 2018 at 3:01:44 AM UTC-8, John Brooks wrote:
>> 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:
>
> 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/progra mming/6502assembly/Developer 's%20Handbook%20for%20the%20Apple%20II%20MouseText%20Tool%20 Kit.pdf
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361907 is a reply to message #361735] |
Sun, 28 January 2018 16:35 |
|
|
Originally posted by: frank_o_rama
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361908 is a reply to message #361907] |
Sun, 28 January 2018 16:43 |
Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 28 Jan 2018, frank_o_rama@hotmail.com wrote:
> 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.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361909 is a reply to message #361901] |
Sun, 28 January 2018 16:52 |
|
|
Originally posted by: inexorabletash
On Sunday, January 28, 2018 at 11:52:28 AM UTC-8, John Brooks wrote:
> 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-tool kit/ very intriguing. Again, ordered it from Syndicomm back in October but haven't heard anything yet. :(
> 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/progra mming/6502assembly/Developer 's%20Handbook%20for%20the%20Apple%20II%20MouseText%20Tool%20 Kit.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... :)
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361910 is a reply to message #361908] |
Sun, 28 January 2018 16:57 |
|
|
Originally posted by: inexorabletash
On Sunday, January 28, 2018 at 1:43:36 PM UTC-8, Steve Nickolas wrote:
> On Sun, 28 Jan 2018, Frank wrote:
>
>> 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.m d (This is documented in the early IIgs System Disk docs, too.)
|
|
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361914 is a reply to message #361900] |
Sun, 28 January 2018 18:52 |
|
|
Originally posted by: MG
On Sun, 28 Jan 2018, inexorabletash wrote:
> (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.
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361915 is a reply to message #361864] |
Sun, 28 January 2018 19:15 |
|
|
Originally posted by: 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361916 is a reply to message #361909] |
Sun, 28 January 2018 19:20 |
|
|
Originally posted by: John Brooks
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361917 is a reply to message #361916] |
Sun, 28 January 2018 20:07 |
|
|
Originally posted by: John Brooks
On Sunday, January 28, 2018 at 4:20:24 PM UTC-8, John Brooks wrote:
>> 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
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361933 is a reply to message #361917] |
Sun, 28 January 2018 23:10 |
|
|
Originally posted by: inexorabletash
On Sunday, January 28, 2018 at 5:07:41 PM UTC-8, John Brooks wrote:
> 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?
|
|
|
|
Members
Search
Help
Register
Login
Home
