Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Help debugging nascent emulator
65 views
Skip to first unread message
zel...@gmail.com
Apr 22, 2013, 1:45:55 AM4/22/13
to
Hi folks,
I'm slowly building an Apple II emulator in go, and I need some help from those more experienced than I.
The work in progress is at http://github.com/zellyn/goapple2, although it lacks the various ROMs for now: I plan to write an S-C compatible assembler and bundle them as source...
Anyway: I've been shooting for the bare minimum: so far just keyboard read, keyboard strobe, firmware card, disk card. I'm cheating like crazy (probably that's the problem somewhere) on the disk, and just returning the next nibble byte on reads, as long as three or four ticks have passed.
Anyway, a lot of .dsk images (dos master, spedtest.dsk, dung beetles) work just fine, but it appears the first one I tried, chivalry.dsk, is harder... It works in Jace and OpenEmulator, naturally.
Here's what's happening: it loads up the title screen, with knight on horse, but at the point where it should start animating, it first junks up the screen a little, then jumps to text mode and flashes back and forth there: it appears that the normal program is running, flipping between page one and two to animate the horse, but something else (at 1F76) seems to be writing successive memory locations, strobing over C050, C051, etc in order, which switches out of hires mode.
After a while, the game starts, with approximately the normal text being rendered (at first) except everything not part of the letters is black.
Interesting, huh? I was expecting spectacular failure or for things to work :-/
I guess my next step is to get it working in a hackable emulator, dump all the RAM each time the disk controller card ROM sector read routine returns, and look for differences.
Unless anyone has clever guesses...
Zellyn
I'm slowly building an Apple II emulator in go, and I need some help from those more experienced than I.
The work in progress is at http://github.com/zellyn/goapple2, although it lacks the various ROMs for now: I plan to write an S-C compatible assembler and bundle them as source...
Anyway: I've been shooting for the bare minimum: so far just keyboard read, keyboard strobe, firmware card, disk card. I'm cheating like crazy (probably that's the problem somewhere) on the disk, and just returning the next nibble byte on reads, as long as three or four ticks have passed.
Anyway, a lot of .dsk images (dos master, spedtest.dsk, dung beetles) work just fine, but it appears the first one I tried, chivalry.dsk, is harder... It works in Jace and OpenEmulator, naturally.
Here's what's happening: it loads up the title screen, with knight on horse, but at the point where it should start animating, it first junks up the screen a little, then jumps to text mode and flashes back and forth there: it appears that the normal program is running, flipping between page one and two to animate the horse, but something else (at 1F76) seems to be writing successive memory locations, strobing over C050, C051, etc in order, which switches out of hires mode.
After a while, the game starts, with approximately the normal text being rendered (at first) except everything not part of the letters is black.
Interesting, huh? I was expecting spectacular failure or for things to work :-/
I guess my next step is to get it working in a hackable emulator, dump all the RAM each time the disk controller card ROM sector read routine returns, and look for differences.
Unless anyone has clever guesses...
Zellyn
BLuRry
Apr 23, 2013, 12:55:11 PM4/23/13
to
My recommendation:
1) Build out the softswitches completely. Leave no stone unturned.
2) Build a way to load roms and set the program counter to start them. You can lift dozens of great titles from the lib/data folder of Apple Game Server -- These can serve as great tests of your emulator to ensure that basic stuff is running
3) Use a test program that puts the 6502 through all its paces. Some of the nuances of the processor flags can be daunting, but you won't find all the holes in your emulator unless you have a program that tells you specifically what is not working right. I used the one written by Klauss Dormann --> https://github.com/redline6561/cl-6502/blob/b0087903428ec2a3794ba4219494005174d1b09f/tests/6502_functional_test.a65
4) Also use the self-test built in to the Apple roms. The enhanced //e self-test will give ram failures if your 80-col and language card softswitches are not implemented correctly.
Don't get too hung-up on emulating hardware like the Disk ][ controller -- it is really daunting if you still are unsure about the CPU emulation. You can tackle that later, but loading games from rom files is a good way to bypass the need for disk support. Jace didn't get disk support until after it had working hi-res graphics, for example.
It is actually a LOT easier to implement a mass-storage device for HDV and 2MG support since you can take shortcuts like loading disk blocks directly into emulated memory without any emulated 6502 code.
Hope this helps! If you need some ideas, the Jace codebase is fairly organized and object-oriented so you might be able to get some ideas of things that work (and some things that probably don't. ;-)
-B
1) Build out the softswitches completely. Leave no stone unturned.
2) Build a way to load roms and set the program counter to start them. You can lift dozens of great titles from the lib/data folder of Apple Game Server -- These can serve as great tests of your emulator to ensure that basic stuff is running
3) Use a test program that puts the 6502 through all its paces. Some of the nuances of the processor flags can be daunting, but you won't find all the holes in your emulator unless you have a program that tells you specifically what is not working right. I used the one written by Klauss Dormann --> https://github.com/redline6561/cl-6502/blob/b0087903428ec2a3794ba4219494005174d1b09f/tests/6502_functional_test.a65
4) Also use the self-test built in to the Apple roms. The enhanced //e self-test will give ram failures if your 80-col and language card softswitches are not implemented correctly.
Don't get too hung-up on emulating hardware like the Disk ][ controller -- it is really daunting if you still are unsure about the CPU emulation. You can tackle that later, but loading games from rom files is a good way to bypass the need for disk support. Jace didn't get disk support until after it had working hi-res graphics, for example.
It is actually a LOT easier to implement a mass-storage device for HDV and 2MG support since you can take shortcuts like loading disk blocks directly into emulated memory without any emulated 6502 code.
Hope this helps! If you need some ideas, the Jace codebase is fairly organized and object-oriented so you might be able to get some ideas of things that work (and some things that probably don't. ;-)
-B
BLuRry
Apr 23, 2013, 1:14:16 PM4/23/13
to
On Monday, April 22, 2013 12:45:55 AM UTC-5, zel...@gmail.com wrote:
> Hi folks,
>
>
>
> I'm slowly building an Apple II emulator in go, and I need some help from those more experienced than I.
>
>
>
> The work in progress is at http://github.com/zellyn/goapple2, although it lacks the various ROMs for now: I plan to write an S-C compatible assembler and bundle them as source...
>
>
>
> Anyway: I've been shooting for the bare minimum: so far just keyboard read, keyboard strobe, firmware card, disk card. I'm cheating like crazy (probably that's the problem somewhere) on the disk, and just returning the next nibble byte on reads, as long as three or four ticks have passed.
>
>
>
> Anyway, a lot of .dsk images (dos master, spedtest.dsk, dung beetles) work just fine, but it appears the first one I tried, chivalry.dsk, is harder... It works in Jace and OpenEmulator, naturally.
>
>
>
> Here's what's happening: it loads up the title screen, with knight on horse, but at the point where it should start animating, it first junks up the screen a little, then jumps to text mode and flashes back and forth there: it appears that the normal program is running, flipping between page one and two to animate the horse, but something else (at 1F76) seems to be writing successive memory locations, strobing over C050, C051, etc in order, which switches out of hires mode.
>
It's definitely something in your CPU emulation. I would make unit testing a top priority. If you were able to get the game loading that far then your disk emulation is probably OK. Review how you work with processor flags. The overflow and decimal flags kicked my butt for so long...
>
>
>
> I'm slowly building an Apple II emulator in go, and I need some help from those more experienced than I.
>
>
>
> The work in progress is at http://github.com/zellyn/goapple2, although it lacks the various ROMs for now: I plan to write an S-C compatible assembler and bundle them as source...
>
>
>
> Anyway: I've been shooting for the bare minimum: so far just keyboard read, keyboard strobe, firmware card, disk card. I'm cheating like crazy (probably that's the problem somewhere) on the disk, and just returning the next nibble byte on reads, as long as three or four ticks have passed.
>
>
>
> Anyway, a lot of .dsk images (dos master, spedtest.dsk, dung beetles) work just fine, but it appears the first one I tried, chivalry.dsk, is harder... It works in Jace and OpenEmulator, naturally.
>
>
>
> Here's what's happening: it loads up the title screen, with knight on horse, but at the point where it should start animating, it first junks up the screen a little, then jumps to text mode and flashes back and forth there: it appears that the normal program is running, flipping between page one and two to animate the horse, but something else (at 1F76) seems to be writing successive memory locations, strobing over C050, C051, etc in order, which switches out of hires mode.
>
-B
Bill Buckels
Apr 23, 2013, 6:52:50 PM4/23/13
to
<zel...@gmail.com> wrote:
> strobing over C050, C051, etc in order, which switches out of hires mode.
disk images to test with... I exercise all the graphics modes and use
auxiliary memory to store libraries and so forth. AppleWin runs all of my
stuff correctly as does my Apple IIe.
www.aztecmuseum.ca
Zellyn Hunter
Apr 25, 2013, 1:14:31 AM4/25/13
to
I think I've almost got Apple][js to a point where I can hack on it, and compare RAM state at key points in time, so we'll see what's going on.
Zellyn Hunter
Apr 25, 2013, 1:16:01 AM4/25/13
to
Zellyn
Bill Buckels
Apr 25, 2013, 8:03:32 AM4/25/13
to
"Zellyn Hunter" <zel...@gmail.com> wrote:
> I had a look there, but it wasn't completely clear which download you were
> referring to. Bear in mind that I'm emulating an Apple ][+ with 48K of
> RAM, not an Apple //e: it looks like most of the Aztec stuff requires more
> RAM.
earlier (or DosBox and other MS-DOS emulators) . I bundle it with disk
images that you can use for testing. You can also write test programs for
your emulator with it if you modify my examples which are pretty simple.
On an Apple II+ lower case characters will appear as junk without an 80
column card. Double-res modes came later too:
http://en.wikipedia.org/wiki/Apple_80-Column_Text_Card
You can grab the DOS 3.3 C65 cross-compiler bundle directly from the
following link if you want to give it a try:
http://www.aztecmuseum.ca/Apple33.zip
Bill
sicklittlemonkey
May 11, 2013, 8:40:14 AM5/11/13
to
Otherwise a technique I've used is to take an existing emulator and get it to log every instruction it runs. Do the same for yours, in the same format, and diff the resulting text files.
You'll need a "breakpoint" to turn this on, but it can be hard-coded.
Cheers,
Nick.
Zellyn Hunter
May 12, 2013, 7:24:04 PM5/12/13
to
0 new messages