| Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382062] |
Sat, 16 March 2019 00:01  |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Fellas,
This is a long shot, but I've got to ask:
Can you offer any speculation as to why a piece of code that calls (JSR)
a routine residing in LC Bank 2 ($D000+) runs fine on a real IIGS, but
on *SOME* (not all) accesses hangs both GSPort (Windows 10) and Sweet16
(Mac OS X)? Other accesses to the SAME routine, however, run fine under
emulation.
I'm having trouble understanding why the code always works on a real
machine, but hangs two very different emulators.
The code is in LC Bank 2 and part of it is located where the ProDOS Quit
code normally is. (the Quit code has been temporarily moved to another
location). It's not my code, and I don't yet fully understand it, but
I'm working to update it feature-wise and to run properly under emulation.
Is there some strange mechanism where the bank switching soft switches
can be toggled without actually having to access the soft switches? If
that were to happen, I suppose the code could venture into ROM, but it
seems like that would just crash to the monitor, not hang the emulator.
Thanks.
Hugh Hood
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382063 is a reply to message #382062] |
Sat, 16 March 2019 00:53  |
|
|
Originally posted by: kegs
In article <99KdnRpw1LqU6BHBnZ2dnUU7-R3NnZ2d@earthlink.com>,
Hugh Hood <hughhood@earthlink.net> wrote:
> Fellas,
>
> This is a long shot, but I've got to ask:
>
> Can you offer any speculation as to why a piece of code that calls (JSR)
> a routine residing in LC Bank 2 ($D000+) runs fine on a real IIGS, but
> on *SOME* (not all) accesses hangs both GSPort (Windows 10) and Sweet16
> (Mac OS X)? Other accesses to the SAME routine, however, run fine under
> emulation.
>
> I'm having trouble understanding why the code always works on a real
> machine, but hangs two very different emulators.
>
> The code is in LC Bank 2 and part of it is located where the ProDOS Quit
> code normally is. (the Quit code has been temporarily moved to another
> location). It's not my code, and I don't yet fully understand it, but
> I'm working to update it feature-wise and to run properly under emulation.
>
> Is there some strange mechanism where the bank switching soft switches
> can be toggled without actually having to access the soft switches? If
> that were to happen, I suppose the code could venture into ROM, but it
> seems like that would just crash to the monitor, not hang the emulator.
>
> Thanks.
>
>
>
>
> Hugh Hood
I believe GSPort is based on KEGS. KEGS takes some shortcuts in emulation
which very weird code might be affected by.
One example: certain indexed 65816 operations can cause spurious accesses,
especially with page crossings: LDA ($24),y where $25,$24=$c081 and y=$81
will eventually access $c102, but it will first do an access to $c002. KEGS
does not model these spurious accesses, and they don't all involve page
crossings (although most page crossings cause spurious accesses). And since
it isn't fully modeled in KEGS, I didn't feel safe trying to emulate properly
that certain repeated accesses lock/unlock the LC RAM, since the spurious
accesses could change the number of accesses. I never wanted the card to be
locked when it shouldn't be, and this approach was least likely to run into
problems.
It's possible the code is working by relying on these spurious accesses,
and the emulators are not handling it properly. Or the code may be relying
on locking/unlocking writes to the LC RAM which isn't modeled right. Or some
other strange thing is occurring. If you can make an example available,
this can be debugged.
Kent
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382087 is a reply to message #382063] |
Sat, 16 March 2019 13:09 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Kent,
Thanks for taking the time to respond.
I'm still getting a handle on the code, but a cursory disassembly shows
mid-routine accesses to both $C002 (RDMAINRAM) and $C003 (RDCARDRAM) {Aux}.
I haven't seen anything, however, that is fiddling with the state of the
ROM/LC softswitches.
I'll do some experimental patching to try to narrow/isolate the exact
problem before I put any code up for you to 'ponder' on.
Thanks so much, and sorry for the reply to email - wrong key!
Hugh Hood
On 3/15/2019 11:53 PM, Kent Dickey wrote:
>
> I believe GSPort is based on KEGS. KEGS takes some shortcuts in emulation
> which very weird code might be affected by.
>
> One example: certain indexed 65816 operations can cause spurious accesses,
> especially with page crossings: LDA ($24),y where $25,$24=$c081 and y=$81
> will eventually access $c102, but it will first do an access to $c002. KEGS
> does not model these spurious accesses, and they don't all involve page
> crossings (although most page crossings cause spurious accesses). And since
> it isn't fully modeled in KEGS, I didn't feel safe trying to emulate properly
> that certain repeated accesses lock/unlock the LC RAM, since the spurious
> accesses could change the number of accesses. I never wanted the card to be
> locked when it shouldn't be, and this approach was least likely to run into
> problems.
>
> It's possible the code is working by relying on these spurious accesses,
> and the emulators are not handling it properly. Or the code may be relying
> on locking/unlocking writes to the LC RAM which isn't modeled right. Or some
> other strange thing is occurring. If you can make an example available,
> this can be debugged.
>
> Kent
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382405 is a reply to message #382063] |
Sun, 24 March 2019 21:55 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Kent,
Thanks for offering to glance at some example code that is causing
GSPort to hang on me.
FWIW, when I turn the GSPort 'Status Lines' on, I get a 'Code: Yellow',
and a message that 'Emulated system state suspect, save wor[k]' whenever
this code is called from a particular routine located in Main Memory.
If you see anything that might cause an issue, let me know and I'll
modify/patch it and try again.
This is not my code, but rather is from the AppleWorks memory manager
for the Apple IIGS, and was probably written and/or modified by Alan
Bird 30 years ago.
-- Called from $4047 in Main Memory
-- This Code Located in Main Memory LC Bank 1
00/DA28: 18 CLC
00/DA29: FB XCE
00/DA2A: C2 30 REP #30
00/DA2C: A9 02 00 LDA #0002
00/DA2F: 20 31 D1 JSR D131
00/DA32: 20 4C DA JSR DA4C
00/DA35: B2 9A LDA (9A)
00/DA37: 20 54 DA JSR DA54
00/DA3A: A2 F4 00 LDX #00F4
00/DA3D: 20 CA D0 JSR D0CA
00/DA40: A0 04 00 LDY #0004
00/DA43: B7 F4 LDA [F4],Y
00/DA45: AA TAX
00/DA46: C8 INY
00/DA47: B7 F4 LDA [F4],Y
00/DA49: 38 SEC
00/DA4A: FB XCE
00/DA4B: 60 RTS
00/DA4C: E2 20 SEP #20
00/DA4E: 8D 03 C0 STA C003
00/DA51: C2 30 REP #30
00/DA53: 60 RTS
00/DA54: E2 20 SEP #20
00/DA56: 8D 02 C0 STA C002
00/DA59: C2 30 REP #30
00/DA5B: 60 RTS
00/D131: A8 TAY
00/D132: 8D 2F D1 STA D12F
00/D135: A3 03 LDA 03,S
00/D137: 85 98 STA 98
00/D139: 18 CLC
00/D13A: 6D 2F D1 ADC D12F
00/D13D: 83 03 STA 03,S
00/D13F: 88 DEY
00/D140: B1 98 LDA (98),Y
00/D142: 99 99 00 STA 0099,Y
00/D145: 88 DEY
00/D146: D0 F7 BNE D13F {-09}
00/D148: A0 00 00 LDY #0000
00/D14B: 60 RTS
00/D0CA: 95 00 STA 00,X
00/D0CC: AD D6 0F LDA 0FD6
00/D0CF: 29 7F 00 AND #007F
00/D0D2: C9 08 00 CMP #0008
00/D0D5: D0 0F BNE D0E6 {+0F}
00/D0D7: B5 00 LDA 00,X
00/D0D9: EB XBA
00/D0DA: 48 PHA
00/D0DB: 29 00 FF AND #FF00
00/D0DE: 95 00 STA 00,X
00/D0E0: 68 PLA
00/D0E1: 29 FF 00 AND #00FF
00/D0E4: 80 0A BRA D0F0 {+0A}
00/D0E6: A8 TAY
00/D0E7: A9 00 00 LDA #0000
00/D0EA: 16 00 ASL 00,X
00/D0EC: 2A ROL
00/D0ED: 88 DEY
00/D0EE: D0 FA BNE D0EA {-06}
00/D0F0: C9 02 00 CMP #0002
00/D0F3: 90 0D BCC D102 {+0D}
00/D0F5: C9 04 00 CMP #0004
00/D0F8: 90 04 BCC D0FE {+04}
00/D0FA: 3A DEC
00/D0FB: 3A DEC
00/D0FC: D0 04 BNE D102 {+04}
00/D0FE: 18 CLC
00/D0FF: 69 DE 00 ADC #00DE
00/D102: 95 02 STA 02,X
00/D104: 60 RTS
If I patch around the call to this code altogether, and preload the
accumulator with a 'reasonable' returned value, GSPort runs just fine,
so I suspect something in the above is causing GSPort to be confused.
Thanks again.
Hugh Hood
On 3/15/2019 11:53 PM, Kent Dickey wrote:
> In article <99KdnRpw1LqU6BHBnZ2dnUU7-R3NnZ2d@earthlink.com>,
> Hugh Hood <hughhood@earthlink.net> wrote:
>> Fellas,
>>
>> This is a long shot, but I've got to ask:
>>
>> Can you offer any speculation as to why a piece of code that calls (JSR)
>> a routine residing in LC Bank 2 ($D000+) runs fine on a real IIGS, but
>> on *SOME* (not all) accesses hangs both GSPort (Windows 10) and Sweet16
>> (Mac OS X)? Other accesses to the SAME routine, however, run fine under
>> emulation.
>>
>> I'm having trouble understanding why the code always works on a real
>> machine, but hangs two very different emulators.
>>
>> The code is in LC Bank 2 and part of it is located where the ProDOS Quit
>> code normally is. (the Quit code has been temporarily moved to another
>> location). It's not my code, and I don't yet fully understand it, but
>> I'm working to update it feature-wise and to run properly under emulation.
>>
>> Is there some strange mechanism where the bank switching soft switches
>> can be toggled without actually having to access the soft switches? If
>> that were to happen, I suppose the code could venture into ROM, but it
>> seems like that would just crash to the monitor, not hang the emulator.
>>
>> Thanks.
>>
>>
>>
>>
>> Hugh Hood
>
> I believe GSPort is based on KEGS. KEGS takes some shortcuts in emulation
> which very weird code might be affected by.
>
> One example: certain indexed 65816 operations can cause spurious accesses,
> especially with page crossings: LDA ($24),y where $25,$24=$c081 and y=$81
> will eventually access $c102, but it will first do an access to $c002. KEGS
> does not model these spurious accesses, and they don't all involve page
> crossings (although most page crossings cause spurious accesses). And since
> it isn't fully modeled in KEGS, I didn't feel safe trying to emulate properly
> that certain repeated accesses lock/unlock the LC RAM, since the spurious
> accesses could change the number of accesses. I never wanted the card to be
> locked when it shouldn't be, and this approach was least likely to run into
> problems.
>
> It's possible the code is working by relying on these spurious accesses,
> and the emulators are not handling it properly. Or the code may be relying
> on locking/unlocking writes to the LC RAM which isn't modeled right. Or some
> other strange thing is occurring. If you can make an example available,
> this can be debugged.
>
> Kent
>
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382561 is a reply to message #382405] |
Fri, 29 March 2019 16:51 |
|
|
Originally posted by: kegs
In article <H56dnVMvRZOVqAXBnZ2dnUU7-dHNnZ2d@earthlink.com>,
Hugh Hood <hughhood@earthlink.net> wrote:
> Kent,
>
> Thanks for offering to glance at some example code that is causing
> GSPort to hang on me.
>
> FWIW, when I turn the GSPort 'Status Lines' on, I get a 'Code: Yellow',
> and a message that 'Emulated system state suspect, save wor[k]' whenever
> this code is called from a particular routine located in Main Memory.
>
> If you see anything that might cause an issue, let me know and I'll
> modify/patch it and try again.
>
> This is not my code, but rather is from the AppleWorks memory manager
> for the Apple IIGS, and was probably written and/or modified by Alan
> Bird 30 years ago.
>
> -- Called from $4047 in Main Memory
> -- This Code Located in Main Memory LC Bank 1
>
>
> 00/DA28: 18 CLC
> 00/DA29: FB XCE
> 00/DA2A: C2 30 REP #30
> 00/DA2C: A9 02 00 LDA #0002
> 00/DA2F: 20 31 D1 JSR D131
> 00/DA32: 20 4C DA JSR DA4C
> 00/DA35: B2 9A LDA (9A)
> 00/DA37: 20 54 DA JSR DA54
> 00/DA3A: A2 F4 00 LDX #00F4
> 00/DA3D: 20 CA D0 JSR D0CA
> 00/DA40: A0 04 00 LDY #0004
> 00/DA43: B7 F4 LDA [F4],Y
> 00/DA45: AA TAX
> 00/DA46: C8 INY
> 00/DA47: B7 F4 LDA [F4],Y
> 00/DA49: 38 SEC
> 00/DA4A: FB XCE
> 00/DA4B: 60 RTS
> 00/DA4C: E2 20 SEP #20
> 00/DA4E: 8D 03 C0 STA C003
> 00/DA51: C2 30 REP #30
> 00/DA53: 60 RTS
> 00/DA54: E2 20 SEP #20
> 00/DA56: 8D 02 C0 STA C002
> 00/DA59: C2 30 REP #30
> 00/DA5B: 60 RTS
>
> 00/D131: A8 TAY
> 00/D132: 8D 2F D1 STA D12F
> 00/D135: A3 03 LDA 03,S
> 00/D137: 85 98 STA 98
> 00/D139: 18 CLC
> 00/D13A: 6D 2F D1 ADC D12F
> 00/D13D: 83 03 STA 03,S
> 00/D13F: 88 DEY
> 00/D140: B1 98 LDA (98),Y
> 00/D142: 99 99 00 STA 0099,Y
> 00/D145: 88 DEY
> 00/D146: D0 F7 BNE D13F {-09}
> 00/D148: A0 00 00 LDY #0000
> 00/D14B: 60 RTS
>
> 00/D0CA: 95 00 STA 00,X
> 00/D0CC: AD D6 0F LDA 0FD6
> 00/D0CF: 29 7F 00 AND #007F
> 00/D0D2: C9 08 00 CMP #0008
> 00/D0D5: D0 0F BNE D0E6 {+0F}
> 00/D0D7: B5 00 LDA 00,X
> 00/D0D9: EB XBA
> 00/D0DA: 48 PHA
> 00/D0DB: 29 00 FF AND #FF00
> 00/D0DE: 95 00 STA 00,X
> 00/D0E0: 68 PLA
> 00/D0E1: 29 FF 00 AND #00FF
> 00/D0E4: 80 0A BRA D0F0 {+0A}
> 00/D0E6: A8 TAY
> 00/D0E7: A9 00 00 LDA #0000
> 00/D0EA: 16 00 ASL 00,X
> 00/D0EC: 2A ROL
> 00/D0ED: 88 DEY
> 00/D0EE: D0 FA BNE D0EA {-06}
> 00/D0F0: C9 02 00 CMP #0002
> 00/D0F3: 90 0D BCC D102 {+0D}
> 00/D0F5: C9 04 00 CMP #0004
> 00/D0F8: 90 04 BCC D0FE {+04}
> 00/D0FA: 3A DEC
> 00/D0FB: 3A DEC
> 00/D0FC: D0 04 BNE D102 {+04}
> 00/D0FE: 18 CLC
> 00/D0FF: 69 DE 00 ADC #00DE
> 00/D102: 95 02 STA 02,X
> 00/D104: 60 RTS
>
>
> If I patch around the call to this code altogether, and preload the
> accumulator with a 'reasonable' returned value, GSPort runs just fine,
> so I suspect something in the above is causing GSPort to be confused.
>
> Thanks again.
>
>
>
>
> Hugh Hood
What do you think this routine does?
The code expects to be called in emulation mode with something like this:
jsr $da28
.word16 Handle1
Where Handle1 is a ptr-to-a-ptr. The code at $d131 reads the Handle1 itself
from just after the JSR call, and writes back to the calling code to increment
Handl1 by 2. So if the code was:
jsr $d028
.word $2000
then after the call returns, the calling code would be modified to:
jsr $d028
.word $2002
The code also reads from the original ptr (from address $2000 and $2001 in my
example) to dereference the handle. Let's assume the value at $2000.2001 is
$4568. It then sets RAMRD=1 (writes to $c003 switch accesses to the main 48K
memory to auxiliary memory), and then accesses $4568,$4569, and sets
RAMRD=0 (switches back to main 48KB memory). There's some funniness where
where a 2-byte absolute is used to reference a ZP location, which won't work
right if the Direct Page isn't $0000.
Let's assume the value at $4568,$4569=$1234.
This gets us to $da3a, where Accumulator=$1234. Let's call this in_address.
The code then calls $d0ca, where it looks at address $0fd6. If that location,
AND'ed with #$7f, is $08 then: { The $1234 value is changed to a new ptr
at address $f4-$f7: $123400. }
If $0fd6 & #$7f != $08 then: { the $1234 value is changed to a new ptr,
rotated left by $fd6 & #$7f bits. }
So this is just an optimization and the code likely expects a common calling
use is to left shift the address 8 bits (meaning $0fd6 is usually $08).
This ptr is saved at $f4-$f7. This new ptr is adjusted: if the ptr at
$f4-$f7 is <= $01_ffff, it's left alone. If it's from $02_0000 through
$03_ffff, it's adjusted to be $e0_0000 through $e1_ffff instead. If it's
from $04_0000 and higher, it has $02_0000 subtracted from it.
So, using my example Accumulator=$1234 in_address, it would form the ptr
at $f4-$f7 to have $10_3400.
It then reads 3 bytes from this ptr, returning X=the low byte, and Acc=the mid
byte, and ACC_B=the upper byte. It returns in emulation mode.
So, this code itself is fine, but the data structures it's operating on are
complex. Code Yellow in KEGS-based emulators generally means non-existent
memory was accessed (meaning, banks $80-$ef, not including $e0,$e1,
assuming you aren't using 14MB of memory).
I suspect the structures this code is operating on are getting corrupted
somehow (or not formed in a valid way), resulting in bad memory accesses.
This code also does self-modifying code to the language card memory itself.
If that memory gets marked as read-only at some point, that would cause this
code to fail, and possibly access illegal memory.
To debug this further will require the full code which is failing.
If you say this runs on a real Apple IIgs, that could be due to differences
in how KEGS handles reads to non-existent memory. KEGS always returns 0 to
all reads of non-existent memory. I'm not sure what a real Apple IIgs does.
It's possible the code is wrong, but it works on a real Apple IIgs since
the bad read to unavailable memory returns values that allow the code to
continue to work.
Kent
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382583 is a reply to message #382561] |
Sat, 30 March 2019 14:30 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Kent,
Thanks for taking the time to do a thorough analysis of that code I
threw at you. You've given me some solid things to toy with.
>> What do you think this routine does?>
I'm not surprised that you pretty much figured it out on your own.
Remember, you asked. ;-)
This routine is called 'RetWPSize'. Its job is to return with the length
of a single AppleWorks Word Processor line stored in the accumulator.
As you discovered, the call is followed by the address (stored in Aux
Memory starting at $01/4000+) of the AppleWorks' memory manager 'block
number'. The stack is adjusted so that an RTS returns past the address.
Each 'block number' is 2-bytes long. The list of blocks extends from
$01/4000 up to a max of about $01/BEFF, and thus permits an AppleWorks
document to contain a maximum of about 16,000 lines.
Using the block number listed (unless it's something simple like a
CR-only line, specified by $D000 in the list of blocks), the memory
block (details omitted because I'm not sure I understand it fully yet)
is accessed. In this case AppleWorks is using its IIGS-specific memory
manager.
{AppleWorks running on a IIe or IIc would instead use an Aux-Slot or
Slinky memory manager}.
The first (2) bytes in the memory block contain the length of the block.
The lower 7 bits of the low byte contain the line length, as Word
Processor lines are limited to 80 characters.
>
> I suspect the structures this code is operating on are getting corrupted
> somehow (or not formed in a valid way), resulting in bad memory accesses.
>
> This code also does self-modifying code to the language card memory itself.
> If that memory gets marked as read-only at some point, that would cause this
> code to fail, and possibly access illegal memory.
>
> To debug this further will require the full code which is failing.
>
I'll try to isolate something solid first, rather than just throwing
more code in bulk your way.
Here is what is puzzling me -- this routine can be called from some
routines and have no issues. But, for some reason the calling code I'm
working with causes it to choke (Code Yellow). Why that is occurring is
what I'll attempt to isolate, and see if you have any suggestions.
Hugh Hood
|
|
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382590 is a reply to message #382587] |
Sat, 30 March 2019 20:17 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
Antoine,
Thanks for offering your input.
This issue affects (and the code is present in) both AppleWorks 3.0 and
AppleWorks 5.1.
The calling routine is in a TimeOut application (CopyBlock) written by
Mark Munz for AppleWorks 3.0. It does not play well with GSPort.
I have updated and enhanced CopyBlock for AppleWorks 5.1, and although
it works fine on a real Apple IIGS, it also has issues running under GSPort.
As I mentioned to Kent, I'm going to re-examine the area preceding the
calling code to try to make sense of what could possibly be going wrong.
Hugh Hood
On 3/30/2019 5:04 PM, Antoine Vignau wrote:
>
> Which AppleWorks version, please?
> av
>
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382591 is a reply to message #382590] |
Sat, 30 March 2019 20:48 |
|
|
Originally posted by: messdrivers
> The calling routine is in a TimeOut application (CopyBlock) written by
> Mark Munz for AppleWorks 3.0. It does not play well with GSPort.
>
> I have updated and enhanced CopyBlock for AppleWorks 5.1, and although
> it works fine on a real Apple IIGS, it also has issues running under GSPort.
Perhaps a ROM 01/03 difference? Like your real IIGS is ROM 01 and GSPort is running ROM 03 or vice-versa?
|
|
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382596 is a reply to message #382561] |
Sun, 31 March 2019 02:05 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 3/29/2019 3:51 PM, Kent Dickey wrote:
>
> Code Yellow in KEGS-based emulators generally means non-existent
> memory was accessed (meaning, banks $80-$ef, not including $e0,$e1,
> assuming you aren't using 14MB of memory).
>
> It's possible the code is wrong, but it works on a real Apple IIgs
> since the bad read to unavailable memory returns values that allow
> the code to continue to work.
>
I now believe you have identified the exact issue.
It appears that the calling code is being passed both valid and invalid
parameters. The invalid parameters are out-of-range, resulting in
attempted accesses to unavailable memory.
My preliminary testing shows that if I filter the parameters to known
valid values, the Code Yellow condition in GSPort is completely avoided.
FWIW, I checked within AppleWorks itself and every time it accesses the
'offending' routine, it filters the parameters first.
The code that I have been updating failed to do that, but when it was
written in 1990, I suppose there were no Apple IIGS emulators on which
to test such things!
Thanks for the guidance on this Kent. While I haven't for certain solved
it, I'm confident that I'm close.
Hugh Hood
|
|
|
|
|
|
| Re: Code is Hanging IIGS Emulators (But Not Real IIGS) [message #382624 is a reply to message #382616] |
Sun, 31 March 2019 20:43 |
Hugh Hood
Messages: 678
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On 3/31/2019 2:53 PM, Antoine Vignau wrote:
>
> The code in GSPort or your 6502 code? Which one do you want to update?
>
I'm updating and enhancing Mark Munz' 6502 code from one of his most
useful TimeOut TextTools (CopyBlock).
CopyBlock allows one to Copy/Paste a rectangular block/column within a
word processor document. It overcomes AppleWorks' restricting such
things to contiguous characters.
An analogy would be holding the 'OPTION' key on the Mac while selecting
some block/column text, or the ALT key on Windows while selecting some
block/column text.
Based on Kent's suggestion that the 6502 code was attempting to access
invalid memory locations, I modified the code to filter valid/invalid
pointers and that has appeared to solve the problem completely.
This issue affected not only GSPort, but also Munz' own Deja IIx
AppleWorks emulator. Knowing the problem, I'm surprised that it ran on a
'real' IIGS, but it did.
FWIW, I'll leave updating *emulator* code to guys who know what they're
doing. ;-)
Now, I only need to squash about (3) more bugs in the original code and
I'll be happy. It seems the more you test something, the more bugs you find.
Hugh Hood
|
|
|
|
|
|
|
|
|
|
Members
Search
Help
Register
Login
Home
