Apple II emulation - next steps? [message #360783] |
Sun, 14 January 2018 14:06 |
anthonypaulo
Messages: 531 Registered: September 2013
Karma: 0
|
Senior Member |
|
|
I wrote a 65C02 emulator for the Raspberry Pi and have ROM loaded up and executing from the boot vector at $FFFC. I also have it so that it interprets writes to the text page and converts them to the appropriate XY coordinates for my console output, so now I see the screen clearing and the Apple //e centered correctly at the top of the screen. However, the boot sequence must be looking for something that I've not yet implemented because it ends up at an endless loop at $F181 and I believe that's not a valid location for it to be at since I put a breakpoint at that address in AppleWin and it never gets there.
Anyone have any recommendations on what my next steps should be? That is, what I should be implementing next in order to get the absolute basic core system functionality (no peripherals) working where I can see the command prompt and blinking cursor?
|
|
|
|
Re: Apple II emulation - next steps? [message #360800 is a reply to message #360783] |
Sun, 14 January 2018 17:20 |
sicklittlemonkey
Messages: 570 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Monday, 15 January 2018 08:06:08 UTC+13, Anthony Ortiz wrote:
> Anyone have any recommendations on what my next steps should be? That is, what I should be implementing next in order to get the absolute basic core system functionality (no peripherals) working where I can see the command prompt and blinking cursor?
My advice is to generate a trace log from an emulator you trust (e.g. AppleWin).
Then add this feature to your own emulator and diff the logs. These problems often come down to a flag or instruction or memory bank not being emulated correctly. It's surprising how far a broken CPU will execute.
Cheers,
Nick.
|
|
|
|
Re: Apple II emulation - next steps? [message #360815 is a reply to message #360801] |
Sun, 14 January 2018 21:24 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On Sunday, January 14, 2018 at 5:56:09 PM UTC-5, Anthony Ortiz wrote:
> I ran my emulator through Klaus’s test suite so I believe it’s pretty sound, but a trace sounds like a good idea.
Once you do track the problem down, let me know if you think it would be the kind of thing that would be appropriate to add to a test suite intended just for Apple II emulation that picks up after you have your 6502 working due to Klaus's test suite. :-)
I might just have (the beginnings of) such a thing…
https://github.com/zellyn/a2audit
Zellyn
|
|
|
Re: Apple II emulation - next steps? [message #360883 is a reply to message #360783] |
Tue, 16 January 2018 01:20 |
|
Originally posted by: awanderin
Anthony Ortiz <anthonypaulo@gmail.com> writes:
> I wrote a 65C02 emulator for the Raspberry Pi and have ROM loaded up
> and executing from the boot vector at $FFFC. I also have it so that it
> interprets writes to the text page and converts them to the
> appropriate XY coordinates for my console output, so now I see the
> screen clearing and the Apple //e centered correctly at the top of the
> screen. However, the boot sequence must be looking for something that
> I've not yet implemented because it ends up at an endless loop at
> $F181 and I believe that's not a valid location for it to be at since
> I put a breakpoint at that address in AppleWin and it never gets
> there.
>
> Anyone have any recommendations on what my next steps should be? That
> is, what I should be implementing next in order to get the absolute
> basic core system functionality (no peripherals) working where I can
> see the command prompt and blinking cursor?
From the other thread over on csa2, wasn't the F181 routine the
find-top-of-memory routine? If so, does your emulator properly emulate
the I/O space and ROM space? If it doesn't and instead treats it like
RAM (that is, changes contents when written), this routine will run
forever. Since it starts at $800 and tries to read and write the first
byte of each page to see if RAM is there, it ought to break out of the
loop when $50 and $51 are set to $00 and $C0, respectively. So, check
your emulator for how it handles address $C000. That's the keyboard
latch, and writing to it is a IIe/IIc/IIgs softswitch. What you write
in there should never be readable.
--
--
Jerry awanderin at gmail dot com
|
|
|
Re: Apple II emulation - next steps? [message #360922 is a reply to message #360783] |
Tue, 16 January 2018 19:36 |
Steve Nickolas
Messages: 2036 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sun, 14 Jan 2018, Anthony Ortiz wrote:
> I wrote a 65C02 emulator for the Raspberry Pi and have ROM loaded up and
> executing from the boot vector at $FFFC. I also have it so that it
> interprets writes to the text page and converts them to the appropriate
> XY coordinates for my console output, so now I see the screen clearing
> and the Apple //e centered correctly at the top of the screen. However,
> the boot sequence must be looking for something that I've not yet
> implemented because it ends up at an endless loop at $F181 and I believe
> that's not a valid location for it to be at since I put a breakpoint at
> that address in AppleWin and it never gets there.
>
> Anyone have any recommendations on what my next steps should be? That
> is, what I should be implementing next in order to get the absolute
> basic core system functionality (no peripherals) working where I can see
> the command prompt and blinking cursor?
>
My first steps, FWIW, were:
1. I attached the CPU, an Apple ][+ ROM, 48K of RAM - this is the simplest
configuration to deal with from our perspective as everything but the I/O
space is full but the least amount of hardware needs to be present.
2. I added code to special-case the video memory and C00x/C01x.
Everything after that I added as needed.
-uso.
|
|
|
Re: Apple II emulation - next steps? [message #360923 is a reply to message #360883] |
Tue, 16 January 2018 19:54 |
anthonypaulo
Messages: 531 Registered: September 2013
Karma: 0
|
Senior Member |
|
|
On Tuesday, January 16, 2018 at 1:20:19 AM UTC-5, awanderin wrote:
>
>> I wrote a 65C02 emulator for the Raspberry Pi and have ROM loaded up
>> and executing from the boot vector at $FFFC. I also have it so that it
>> interprets writes to the text page and converts them to the
>> appropriate XY coordinates for my console output, so now I see the
>> screen clearing and the Apple //e centered correctly at the top of the
>> screen. However, the boot sequence must be looking for something that
>> I've not yet implemented because it ends up at an endless loop at
>> $F181 and I believe that's not a valid location for it to be at since
>> I put a breakpoint at that address in AppleWin and it never gets
>> there.
>>
>> Anyone have any recommendations on what my next steps should be? That
>> is, what I should be implementing next in order to get the absolute
>> basic core system functionality (no peripherals) working where I can
>> see the command prompt and blinking cursor?
>
> From the other thread over on csa2, wasn't the F181 routine the
> find-top-of-memory routine? If so, does your emulator properly emulate
> the I/O space and ROM space? If it doesn't and instead treats it like
> RAM (that is, changes contents when written), this routine will run
> forever. Since it starts at $800 and tries to read and write the first
> byte of each page to see if RAM is there, it ought to break out of the
> loop when $50 and $51 are set to $00 and $C0, respectively. So, check
> your emulator for how it handles address $C000. That's the keyboard
> latch, and writing to it is a IIe/IIc/IIgs softswitch. What you write
> in there should never be readable.
>
>
> --
> --
> Jerry awanderin at gmail dot com
Thanks Jerry, that's why I ended up discovering, I was not write-protecting the ROM areas.
|
|
|
Re: Apple II emulation - next steps? [message #360924 is a reply to message #360922] |
Tue, 16 January 2018 19:56 |
anthonypaulo
Messages: 531 Registered: September 2013
Karma: 0
|
Senior Member |
|
|
On Tuesday, January 16, 2018 at 7:37:01 PM UTC-5, Steve Nickolas wrote:
> On Sun, 14 Jan 2018, Anthony Ortiz wrote:
>
>> I wrote a 65C02 emulator for the Raspberry Pi and have ROM loaded up and
>> executing from the boot vector at $FFFC. I also have it so that it
>> interprets writes to the text page and converts them to the appropriate
>> XY coordinates for my console output, so now I see the screen clearing
>> and the Apple //e centered correctly at the top of the screen. However,
>> the boot sequence must be looking for something that I've not yet
>> implemented because it ends up at an endless loop at $F181 and I believe
>> that's not a valid location for it to be at since I put a breakpoint at
>> that address in AppleWin and it never gets there.
>>
>> Anyone have any recommendations on what my next steps should be? That
>> is, what I should be implementing next in order to get the absolute
>> basic core system functionality (no peripherals) working where I can see
>> the command prompt and blinking cursor?
>>
>
> My first steps, FWIW, were:
>
> 1. I attached the CPU, an Apple ][+ ROM, 48K of RAM - this is the simplest
> configuration to deal with from our perspective as everything but the I/O
> space is full but the least amount of hardware needs to be present.
>
> 2. I added code to special-case the video memory and C00x/C01x.
>
> Everything after that I added as needed.
>
> -uso.
Thanks Steve, I have the CPU, Apple //e ROM, and 48K RAM as well, and I added code to interpret writes to text page 1 but have yet to do anything in IO; that's my next step!
|
|
|
Re: Apple II emulation - next steps? [message #360929 is a reply to message #360924] |
Tue, 16 January 2018 22:30 |
anthonypaulo
Messages: 531 Registered: September 2013
Karma: 0
|
Senior Member |
|
|
On Tuesday, January 16, 2018 at 7:56:42 PM UTC-5, Anthony Ortiz wrote:
> On Tuesday, January 16, 2018 at 7:37:01 PM UTC-5, Steve Nickolas wrote:
>> On Sun, 14 Jan 2018, Anthony Ortiz wrote:
>>
>>> I wrote a 65C02 emulator for the Raspberry Pi and have ROM loaded up and
>>> executing from the boot vector at $FFFC. I also have it so that it
>>> interprets writes to the text page and converts them to the appropriate
>>> XY coordinates for my console output, so now I see the screen clearing
>>> and the Apple //e centered correctly at the top of the screen. However,
>>> the boot sequence must be looking for something that I've not yet
>>> implemented because it ends up at an endless loop at $F181 and I believe
>>> that's not a valid location for it to be at since I put a breakpoint at
>>> that address in AppleWin and it never gets there.
>>>
>>> Anyone have any recommendations on what my next steps should be? That
>>> is, what I should be implementing next in order to get the absolute
>>> basic core system functionality (no peripherals) working where I can see
>>> the command prompt and blinking cursor?
>>>
>>
>> My first steps, FWIW, were:
>>
>> 1. I attached the CPU, an Apple ][+ ROM, 48K of RAM - this is the simplest
>> configuration to deal with from our perspective as everything but the I/O
>> space is full but the least amount of hardware needs to be present.
>>
>> 2. I added code to special-case the video memory and C00x/C01x.
>>
>> Everything after that I added as needed.
>>
>> -uso.
>
> Thanks Steve, I have the CPU, Apple //e ROM, and 48K RAM as well, and I added code to interpret writes to text page 1 but have yet to do anything in IO; that's my next step!
Woohoo! Thx guys, that did the trick. I'm able to see the prompt and run basic programs, woohoo! Baby steps, baby steps...
|
|
|
Re: Apple II emulation - next steps? [message #361003 is a reply to message #360815] |
Wed, 17 January 2018 23:22 |
anthonypaulo
Messages: 531 Registered: September 2013
Karma: 0
|
Senior Member |
|
|
On Sunday, January 14, 2018 at 9:24:21 PM UTC-5, Zellyn wrote:
> On Sunday, January 14, 2018 at 5:56:09 PM UTC-5, Anthony Ortiz wrote:
>> I ran my emulator through Klaus’s test suite so I believe it’s pretty sound, but a trace sounds like a good idea.
>
> Once you do track the problem down, let me know if you think it would be the kind of thing that would be appropriate to add to a test suite intended just for Apple II emulation that picks up after you have your 6502 working due to Klaus's test suite. :-)
>
> I might just have (the beginnings of) such a thing…
> https://github.com/zellyn/a2audit
>
> Zellyn
Wow, this kind of test suite is exactly what I need! Tried this on AppleWin and there are a couple of LC errors, was going to try with mine but I don't have disk access going yet. Since this suite would definitely be the next thing right after the 65C02 test suite, it would be most useful to run before the disk drive is implemented... would it be possible to provide a binary dump that I can load into memory (the same way I load the ROM from a binary file)? It will be a while before I implement disk access so being in .dsk format it's inaccessible to me.
Regards,
Anthony
|
|
|
Re: Apple II emulation - next steps? [message #361010 is a reply to message #361003] |
Thu, 18 January 2018 03:20 |
|
Originally posted by: James Davis
On Wednesday, January 17, 2018 at 8:22:54 PM UTC-8, Anthony Ortiz wrote:
> On Sunday, January 14, 2018 at 9:24:21 PM UTC-5, Zellyn wrote:
>> On Sunday, January 14, 2018 at 5:56:09 PM UTC-5, Anthony Ortiz wrote:
>>> I ran my emulator through Klaus’s test suite so I believe it’s pretty sound, but a trace sounds like a good idea.
>>
>> Once you do track the problem down, let me know if you think it would be the kind of thing that would be appropriate to add to a test suite intended just for Apple II emulation that picks up after you have your 6502 working due to Klaus's test suite. :-)
>>
>> I might just have (the beginnings of) such a thing…
>> https://github.com/zellyn/a2audit
>>
>> Zellyn
>
> Wow, this kind of test suite is exactly what I need! Tried this on AppleWin and there are a couple of LC errors, was going to try with mine but I don't have disk access going yet. Since this suite would definitely be the next thing right after the 65C02 test suite, it would be most useful to run before the disk drive is implemented... would it be possible to provide a binary dump that I can load into memory (the same way I load the ROM from a binary file)? It will be a while before I implement disk access so being in ..dsk format it's inaccessible to me.
>
> Regards,
>
> Anthony
Anthony,
You can probably do it yourself using AppleWin and WASP or CiderPress in combination to dump the binary to a text file (from within AppleWin into WASP/CiderPress) to exec into Your-Emulator at the proper memory address.
James Davis
|
|
|
|
Re: Apple II emulation - next steps? [message #361111 is a reply to message #361052] |
Fri, 19 January 2018 04:46 |
|
Originally posted by: James Davis
On Thursday, January 18, 2018 at 9:20:36 AM UTC-8, Anthony Ortiz wrote:
> I tried wasp but it couldn’t read the dsk image; it’s in some foreign format.
Bload the file into AppleWin. Save/dump to your disk image. Not to exotic disk. Use CiderPress to convert it. Or call-151 and list/dump the range to a text file that you can copy to your clipboard and then paste into your emulator.
|
|
|
Re: Apple II emulation - next steps? [message #361143 is a reply to message #361003] |
Fri, 19 January 2018 11:52 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
> Wow, this kind of test suite is exactly what I need!
Thanks! That's exactly what I was hoping. Suggestions welcome :-)
> Tried this on AppleWin and there are a couple of LC errors, was going to try with mine but I don't have disk access going yet. Since this suite would definitely be the next thing right after the 65C02 test suite, it would be most useful to run before the disk drive is implemented... would it be possible to provide a binary dump that I can load into memory (the same way I load the ROM from a binary file)? It will be a while before I implement disk access so being in .dsk format it's inaccessible to me.
It is most definitely a weird disk format :-) I optimized it using qkumba's “Standard Delivery” format so that it would put all the data at the beginning of the disk, followed by only zeros, so I could transfer it over the audio port as fast as possible :-)
However, the build is really simple: just compile at using acme, and jump to the start.
https://github.com/zellyn/a2audit/blob/master/audit/build#L7
|
|
|
Re: Apple II emulation - next steps? [message #363502 is a reply to message #361143] |
Wed, 14 February 2018 22:14 |
anthonypaulo
Messages: 531 Registered: September 2013
Karma: 0
|
Senior Member |
|
|
On Friday, January 19, 2018 at 11:52:01 AM UTC-5, Zellyn wrote:
>> Wow, this kind of test suite is exactly what I need!
>
> Thanks! That's exactly what I was hoping. Suggestions welcome :-)
>
>> Tried this on AppleWin and there are a couple of LC errors, was going to try with mine but I don't have disk access going yet. Since this suite would definitely be the next thing right after the 65C02 test suite, it would be most useful to run before the disk drive is implemented... would it be possible to provide a binary dump that I can load into memory (the same way I load the ROM from a binary file)? It will be a while before I implement disk access so being in .dsk format it's inaccessible to me.
>
> It is most definitely a weird disk format :-) I optimized it using qkumba's “Standard Delivery” format so that it would put all the data at the beginning of the disk, followed by only zeros, so I could transfer it over the audio port as fast as possible :-)
>
> However, the build is really simple: just compile at using acme, and jump to the start.
> https://github.com/zellyn/a2audit/blob/master/audit/build#L7
Hey Zellyn,
Would you happen to know the range in memory? I know it starts at $6000 but I'm trying to figure out how big it is so I can save it to a binary via AppleWin's bsave command.
Thanks!
Anthony
|
|
|
Re: Apple II emulation - next steps? [message #363511 is a reply to message #363502] |
Thu, 15 February 2018 05:33 |
sicklittlemonkey
Messages: 570 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Thursday, 15 February 2018 16:14:29 UTC+13, Anthony Ortiz wrote:
> Would you happen to know the range in memory? I know it starts at $6000 but I'm trying to figure out how big it is so I can save it to a binary via AppleWin's bsave command.
Zellyn linked to the exact line in the build script that builds the binary.
Download the acme assembler and the audit source and just run:
acme audit.asm
Cheers,
Nick.
|
|
|
|
Re: Apple II emulation - next steps? [message #363521 is a reply to message #363512] |
Thu, 15 February 2018 09:58 |
zellyn
Messages: 173 Registered: April 2013
Karma: 0
|
Senior Member |
|
|
On Thursday, February 15, 2018 at 6:27:40 AM UTC-5, Anthony Ortiz wrote:
> I haven’t downloaded acme due to my fear of all things sourceforge-based since they package their installers with adware.
acme is just a jar file. Nothing crazy. And I believe Sourceforge has stopped the crazy too.
|
|
|
Re: Apple II emulation - next steps? [message #363522 is a reply to message #363521] |
Thu, 15 February 2018 10:27 |
David Schmidt
Messages: 993 Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On 2/15/2018 9:58 AM, Zellyn wrote:
> On Thursday, February 15, 2018 at 6:27:40 AM UTC-5, Anthony Ortiz wrote:
>> I haven’t downloaded acme due to my fear of all things sourceforge-based since they package their installers with adware.
>
> acme is just a jar file. Nothing crazy. And I believe Sourceforge has stopped the crazy too.
They gave that up (quite) a while ago - and is under new management as well.
|
|
|
|