Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Emulator RAM init differences - encountered another problem with an old Apple program
49 views
Skip to first unread message
Hot Rod
Aug 30, 2012, 6:24:20 PM8/30/12
to
Greetings,
I ran across another old Apple program ('Moptown Parade') that works on a real Apple //e, but a .dsk image did not work on AppleWin (1.20.0). The cause is a bit different, so thought I'd share.
After checking the usual suspects (volume number, hardware checks), I'll admit I got stumped. So, I reached out to Brendan Robert to see if he could try it on JACE, and perhaps shed any more light on what was happening. Brendan reported that it also failed (initially) on JACE in the same way I was seeing, but then through some masterful keystrokes, was able to get it to run. He happened upon invoking both HGR and HGR2, and then doing a warm-boot. That allowed it to work correctly, and I was also able to repeat that success with AppleWin.
So armed with that info, it seemed that something in the hi-res memory was tripping things up, and Brendan was able to point out addresses that narrowed it down, based on how RAM was init'd with a FF FF 00 00 pattern.
I did a search for #$FF in the range of $4000-$6000, and found a lone value of #$FF at $5500. By setting it to #$00, the program ran fine. That explained the what, but not the why.
Now, some background. Moptown Parade boots by running a binary HELLO program at $9000, which in turn uses direct RWTS calls to load its title screen into hi-res page 1, and then copies chars directly to the keyboard buffer to load some shape info files and then ultimately run the BASIC menu program. It was this BASIC program that was bombing out with a SYNTAX ERROR, when running in the emulator. Works great on a real Apple //e though.
However, right at the end of the binary HELLO program, before running the BASIC menu file, it stores #$55 at zero page location $68. This changes the address of where BASIC programs load and run. So instead of the usual $801, it was changing it to $5501.
But the problem is that on a cold-start in the emulator (AppleWin in this case), RAM is initialized to a FF FF 00 00 pattern. So $5500 was set to #$FF from that init. When Applesoft went to execute the BASIC program, it was reading the #$FF at $5500, and causing it to throw the SYNTAX ERROR and stop.
When a BASIC program loads and runs at the normal $801 location, $800 is usually a #$00 (leftover from boot), so apparently this doesn't cause a problem.
So why does it work fine on a real Apple?
On my real Apple //e, from a cold boot, RAM seems to be initialized in a slightly different pattern than the FF FF 00 00 AppleWin uses.
Example from real Apple //e:
$2000: FF FF 00 FF 00 FF 00...
$2100: 00 FF 00 FF 00 FF 00...
...
$5500: 00 FF 00 FF 00 FF 00...
$5600: FF FF 00 FF 00 FF 00 ...
So the pattern is generally 00 FF 00 FF, except 'even' pages start with FF FF instead of 00 FF.
This means that when Moptown Parade is cold-booted and run on a real Apple, it just happens to be getting a #$00 at $5500, and is getting away with relocating the program to $5500. In theory, if they'd used $5400 or $5600, it wouldn't work (maybe that's why $5500 was chosen in the first place though).
I'm not sure if all Apple IIs init RAM in this pattern, but maybe the emulators would want to consider it. I'll patch this .dsk image to properly init $5500 at least, so it will be able to work (and consider it another latent 'bug').
But I thought I'd pass it along. (And thanks again, Brendan!)
]HR
I ran across another old Apple program ('Moptown Parade') that works on a real Apple //e, but a .dsk image did not work on AppleWin (1.20.0). The cause is a bit different, so thought I'd share.
After checking the usual suspects (volume number, hardware checks), I'll admit I got stumped. So, I reached out to Brendan Robert to see if he could try it on JACE, and perhaps shed any more light on what was happening. Brendan reported that it also failed (initially) on JACE in the same way I was seeing, but then through some masterful keystrokes, was able to get it to run. He happened upon invoking both HGR and HGR2, and then doing a warm-boot. That allowed it to work correctly, and I was also able to repeat that success with AppleWin.
So armed with that info, it seemed that something in the hi-res memory was tripping things up, and Brendan was able to point out addresses that narrowed it down, based on how RAM was init'd with a FF FF 00 00 pattern.
I did a search for #$FF in the range of $4000-$6000, and found a lone value of #$FF at $5500. By setting it to #$00, the program ran fine. That explained the what, but not the why.
Now, some background. Moptown Parade boots by running a binary HELLO program at $9000, which in turn uses direct RWTS calls to load its title screen into hi-res page 1, and then copies chars directly to the keyboard buffer to load some shape info files and then ultimately run the BASIC menu program. It was this BASIC program that was bombing out with a SYNTAX ERROR, when running in the emulator. Works great on a real Apple //e though.
However, right at the end of the binary HELLO program, before running the BASIC menu file, it stores #$55 at zero page location $68. This changes the address of where BASIC programs load and run. So instead of the usual $801, it was changing it to $5501.
But the problem is that on a cold-start in the emulator (AppleWin in this case), RAM is initialized to a FF FF 00 00 pattern. So $5500 was set to #$FF from that init. When Applesoft went to execute the BASIC program, it was reading the #$FF at $5500, and causing it to throw the SYNTAX ERROR and stop.
When a BASIC program loads and runs at the normal $801 location, $800 is usually a #$00 (leftover from boot), so apparently this doesn't cause a problem.
So why does it work fine on a real Apple?
On my real Apple //e, from a cold boot, RAM seems to be initialized in a slightly different pattern than the FF FF 00 00 AppleWin uses.
Example from real Apple //e:
$2000: FF FF 00 FF 00 FF 00...
$2100: 00 FF 00 FF 00 FF 00...
...
$5500: 00 FF 00 FF 00 FF 00...
$5600: FF FF 00 FF 00 FF 00 ...
So the pattern is generally 00 FF 00 FF, except 'even' pages start with FF FF instead of 00 FF.
This means that when Moptown Parade is cold-booted and run on a real Apple, it just happens to be getting a #$00 at $5500, and is getting away with relocating the program to $5500. In theory, if they'd used $5400 or $5600, it wouldn't work (maybe that's why $5500 was chosen in the first place though).
I'm not sure if all Apple IIs init RAM in this pattern, but maybe the emulators would want to consider it. I'll patch this .dsk image to properly init $5500 at least, so it will be able to work (and consider it another latent 'bug').
But I thought I'd pass it along. (And thanks again, Brendan!)
]HR
D Finnigan
Aug 30, 2012, 6:47:57 PM8/30/12
to
Hot Rod wrote:
>
> I'm not sure if all Apple IIs init RAM in this pattern, but maybe the
> emulators would want to consider it.
The initial RAM pattern is a deficiency in just about all Apple II
>
> I'm not sure if all Apple IIs init RAM in this pattern, but maybe the
> emulators would want to consider it.
emulators. Maybe every emulator.
I've been working with Marc S. Ressl to get the patterns for the II Plus and
IIe as accurate as possible for his OpenEmulator.
It turns out that the pattern changes depending on what area of RAM you're
in. In other words, the startup RAM pattern IS NOT the same over all RAM.
(At least from my repeated tests on my Apple II equipment)
Also, adding the Transwarp changes the pattern too. Maybe the Zip Chip as
well, but I don't have one of those.
--
]DF$
Apple II Book: http://macgui.com/newa2guide/
Mac GUI Vault: http://macgui.com/vault/
Usenet Archive: http://macgui.com/usenet/
Steve Nickolas
Aug 30, 2012, 6:51:04 PM8/30/12
to
On Thu, 30 Aug 2012, D Finnigan wrote:
> Hot Rod wrote:
>>
>> I'm not sure if all Apple IIs init RAM in this pattern, but maybe the
>> emulators would want to consider it.
>
> The initial RAM pattern is a deficiency in just about all Apple II
> emulators. Maybe every emulator.
>
> I've been working with Marc S. Ressl to get the patterns for the II Plus and
> IIe as accurate as possible for his OpenEmulator.
>
> It turns out that the pattern changes depending on what area of RAM you're
> in. In other words, the startup RAM pattern IS NOT the same over all RAM.
> (At least from my repeated tests on my Apple II equipment)
>
> Also, adding the Transwarp changes the pattern too. Maybe the Zip Chip as
> well, but I don't have one of those.
>
>
My own emulators usually initialized, by default, all RAM to $00. (I
> Hot Rod wrote:
>>
>> I'm not sure if all Apple IIs init RAM in this pattern, but maybe the
>> emulators would want to consider it.
>
> The initial RAM pattern is a deficiency in just about all Apple II
> emulators. Maybe every emulator.
>
> I've been working with Marc S. Ressl to get the patterns for the II Plus and
> IIe as accurate as possible for his OpenEmulator.
>
> It turns out that the pattern changes depending on what area of RAM you're
> in. In other words, the startup RAM pattern IS NOT the same over all RAM.
> (At least from my repeated tests on my Apple II equipment)
>
> Also, adding the Transwarp changes the pattern too. Maybe the Zip Chip as
> well, but I don't have one of those.
>
>
think a variant of Dapple called emu2 had a few other options.)
-uso.
D Finnigan
Aug 30, 2012, 6:59:42 PM8/30/12
to
type this line:
c050 c057 c054 c030 c030 c055 c030 c030 ff70g
Try it on real hardware immediately after powering on to see what it
*should* look like. I can guarantee with nearly 100% certainty that no
emulator now in existence emulates this effect accurately.
Michael J. Mahon
Aug 31, 2012, 12:40:58 AM8/31/12
to
just happens to power up in some state that depends more on the DRAMs than
on anything else.
Any program that depends on the value of uninitialized RAM has a bug.
Period.
Anything done to accommodate such bugs is just that--an accommodation, and
it is almost certain that what works for one such program will not work for
all.
$800 is explicitly initialized by Applesoft's cold start routine, and any
program attempting to run an Applesoft program at another page must do a
similar initialization.
-michael - NadaNet 3.1 and AppleCrate II: http://home.comcast.net/~mjmahony
Steve Nickolas
Aug 31, 2012, 3:27:46 AM8/31/12
to
On Thu, 30 Aug 2012, Michael J. Mahon wrote:
> $800 is explicitly initialized by Applesoft's cold start routine, and any
> program attempting to run an Applesoft program at another page must do a
> similar initialization.
Or ideally, it should grab the input, call E000, and then ungrab the
> $800 is explicitly initialized by Applesoft's cold start routine, and any
> program attempting to run an Applesoft program at another page must do a
> similar initialization.
input. (My GameDOS, for example, uses this trick.)
-uso.
Michael J. Mahon
Aug 31, 2012, 2:03:09 PM8/31/12
to
command. There's a fair amount of initialization to be done, and it
makes most sense to let the Applesoft ROM do it.
There is one piece of initialization that is (erroneously, I think) left
out of COLDSTRT: the ONERR flag at $D8 is not cleared. I discovered
this when &RUNning a program after another program that used ONERR.
So after you call COLDSTRT and regain control by way of the output hook,
you should also clear $D8 prior to starting the program.
-michael
NadaNet 3.1 for Apple II parallel computing!
Home page: http://home.comcast.net/~mjmahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
mmphosis
Sep 1, 2012, 4:42:35 PM9/1/12
to
Good one.
I don't have real hardware, but I was curious what the emulators would do.
The results I observed for each emulator were different. I am running these
on a Mac.
Virtual ][ - I don't think this does it.
Jace - I don't think this does it, but seems a bit closer.
ApplePC (running on DOSBox) - alternates flashing a rotated grid of dots.
OpenEmulator - interesting sound effects
I don't have real hardware, but I was curious what the emulators would do.
The results I observed for each emulator were different. I am running these
on a Mac.
Virtual ][ - I don't think this does it.
Jace - I don't think this does it, but seems a bit closer.
ApplePC (running on DOSBox) - alternates flashing a rotated grid of dots.
OpenEmulator - interesting sound effects
Moose
Sep 2, 2012, 8:43:04 PM9/2/12
to
D Finnigan
Sep 3, 2012, 4:24:28 PM9/3/12
to
http://macgui.com/gallery/showphoto.php?pic_id=1689
The effect is different on the II Plus versus the IIe. On both, however, the
screen should be flashing!
I made a movie of it, so if you want to see this movie, email me, and I'll
send it to you. It's a .ASF file.
0 new messages