| Re: Apple II Desktop Deconstruction [message #361934 is a reply to message #361933] |
Sun, 28 January 2018 23:50   |
|
|
Originally posted by: John Brooks
On Sunday, January 28, 2018 at 8:10:05 PM UTC-8, inexora...@gmail.com wrote:
> 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?
MousePaint and Multiscribe (BeagleWrite) used DHGR desktop GUIs IIRC. No idea if they used this lib though.
-JB
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #361939 is a reply to message #361934] |
Mon, 29 January 2018 00:57 |
|
|
Originally posted by: John Brooks
On Sunday, January 28, 2018 at 8:50:18 PM UTC-8, John Brooks wrote:
> On Sunday, January 28, 2018 at 8:10:05 PM UTC-8, inexora...@gmail.com wrote:
>> 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?
>
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #362032 is a reply to message #361915] |
Tue, 30 January 2018 00:11 |
ab616
Messages: 15
Registered: January 2012
Karma: 0
|
Junior Member |
|
|
There's a workaround at this url:
https://www.chebucto.ns.ca/Services/PDA/AppleIIMiscellaneous .shtml
---
> On Sunday, January 28, 2018 at 8:15:47 PM UTC-4, MG wrote:
> 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 #362034 is a reply to message #361901] |
Tue, 30 January 2018 00:24 |
mdj
Messages: 301
Registered: December 2012
Karma: 0
|
Senior Member |
|
|
On Monday, 29 January 2018 05:52:28 UTC+10, John Brooks wrote:
> 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.
|
|
|
|
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #366401 is a reply to message #364978] |
Tue, 17 April 2018 12:38 |
|
|
Originally posted by: MG
On Saturday, March 10, 2018 at 7:04:25 AM UTC-8, Todd Holcomb wrote:
> I just found this site which has a patch for the IIc+ drive bug:
>
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #366402 is a reply to message #366401] |
Tue, 17 April 2018 13:16 |
|
|
Originally posted by: John Brooks
On Tuesday, April 17, 2018 at 9:38:30 AM UTC-7, MG wrote:
> On Saturday, March 10, 2018 at 7:04:25 AM UTC-8, Todd Holcomb wrote:
>> I just found this site which has a patch for the IIc+ drive bug:
>>
>> 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
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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #366427 is a reply to message #366402] |
Tue, 17 April 2018 20:02 |
|
|
Originally posted by: MG
On Tuesday, April 17, 2018 at 10:16:46 AM UTC-7, John Brooks wrote:
> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #366428 is a reply to message #366427] |
Tue, 17 April 2018 23:13 |
|
|
Originally posted by: John Brooks
On Tuesday, April 17, 2018 at 5:02:58 PM UTC-7, MG wrote:
> On Tuesday, April 17, 2018 at 10:16:46 AM UTC-7, John Brooks wrote:
>> 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
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #366435 is a reply to message #366401] |
Wed, 18 April 2018 02:14 |
ab616
Messages: 15
Registered: January 2012
Karma: 0
|
Junior Member |
|
|
> On Tuesday, April 17, 2018 at 1:38:30 PM UTC-3, MG wrote:
> 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
|
|
|
|
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #378758 is a reply to message #378493] |
Fri, 21 December 2018 01:30 |
|
|
Originally posted by: MG
On 2018-12-18 00:29:16 +0000, Rob Justice said:
>
> That was interesting to read about the Apple II version of the Apple
> /// console driver. Do you know if anything used this?
>
All of the text-mode AppleTalk programs (LOGON, LOGOFF, ATINIT, etc)
appear to use a version of it.
MG
|
|
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #378817 is a reply to message #378759] |
Fri, 21 December 2018 15:33 |
Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, December 21, 2018 at 7:32:00 AM UTC+1, MG wrote:
> On 2018-12-16 09:37:44 +0000, Antoine Vignau said:
>
>> I've gathered all the 8-bit documentation and disk images about
>> desktop, console, and I/O @
>> https://drive.google.com/drive/folders/19F_GpQV2awNFV0sch8CQ Kirtn6jVssoS?usp=sharing
>>
>>
>> Parts of the package was already available on my site @
>> http://www.brutaldeluxe.fr/documentation/forumdesdeveloppeur s.html
>>
>> Hope it helps,
>> av
>
> Thanks, Antoine.
>
> One thing... it looks like the FileCard Toolkit images are duplicates
> of the Desktop/Mouse Graphics Toolkit disks and don't have the FileCard
> Toolkit present. Did I miss something?
>
> MG
You are welcome, MG :-)
I'll check the images, I don't know if I imaged the same disk twice or if I did some other bad thing,
Antoine
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #378835 is a reply to message #378758] |
Sat, 22 December 2018 01:03 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 12/21/2018 12:30 AM, MG wrote:
> On 2018-12-18 00:29:16 +0000, Rob Justice said:
>>
>> That was interesting to read about the Apple II version of the Apple
>> /// console driver. Do you know if anything used this?
>>
>
> All of the text-mode AppleTalk programs (LOGON, LOGOFF, ATINIT, etc)
> appear to use a version of it.
>
> MG
>
AppleWorks also uses a console driver (located @ $1109) and viewport,
but Rupert Lissner's notes say it works like .CONSOLE from the Apple ///.
I do know the control codes are different from those shown in the Apple
II console driver notes that Antoine made available.
Here's what I have on the control codes AppleWorks' Console Driver uses:
ClrEOL EQU $01 ; Clear from cursor to end of line
Clrline EQU $02 ; Clear entire line cursor is on
ClrVP EQU $03 ; go to 0,0 and clear window
ClrEOW EQU $04 ; Clear from cursor to end of window
AbsPosn EQU $05 ; 05xxyy -- Move cursor to column xx, row yy
Left EQU $06 ; Move cursor left
Right EQU $07 ; Move cursor right
Up EQU $08 ; Move cursor up, scroll if already at top
Down EQU $09 ; Move cursor down, scroll if already at bottom
Inverse EQU $0A ; Set inverse mode
Normal EQU $0B ; Set normal mode
VPBot EQU $0C ; Store current cursor as bottom-right corner
Return EQU $0D ; Move cursor to beginning of current line
VPTop EQU $0E ; Store current cursor as top-left corner
ResetVP EQU $0F ; restore full ViewPort / full-screen window
Bell EQU $10 ; Beep! (the AppleWorks low-tone bell)
HorShiftVP EQU $11 ; can be + or -
* $11xx -- Slide the screen sideways xx columns
* If xx>0 slide to right; if xx<0, slide to left
Hugh Hood
>
|
|
|
|
| Re: Apple II Desktop Deconstruction [message #401000 is a reply to message #378835] |
Mon, 12 October 2020 01:05 |
barana
Messages: 91
Registered: March 2013
Karma: 0
|
Member |
|
|
I wonder.... These are my Raw thoughts here...
Thinking GSOS toolbox and early macroms and how they relate to the II/DeskTop..
I know Desktop isnt an os and wont be...Prodos is the OS . DeskTop is the GUI that sits on top.
DeskTop uses whats called quickdraw ... grafports. 8bit but still...
correct me if I wrong (I havent looked yet) quickdraw is in the roms of both the GS and mac along with boardpresent chip drivers...
the mt toolkit used the mousetext chars in rom, and the GS and Mac have the equivalents of the MTGK in rom (quickdraw)
I wonder with the advent of Deans II+ flashrom board , bankswitching ramboards.and others...
Would it be advantageous to build a superrom that may sit in its own bank with all the quickdraw and drivers code
to free up space in the first 128kb for othercode...
Its almost what apple would have done if they were on the 8bitball like what they could have done if they launched a IIC++
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
