| Mame and AppleWin different behaviour ? [message #383049] |
Sat, 13 April 2019 14:32  |
|
|
Originally posted by: Stefan C
Hello,
I've written a demo that relies heavily on Disk II timings. Somehow, when I run the demo on AppleWin and Mame, it behaves differently. Maybe it's the emulators, maybe it's my set up...
The disks are there :
https://github.com/wiz21b/badapple/releases/download/1.0/Bad Apple.zip
just run BAD_APPLE.DSK then, when asked, replace it with BAD_APPLE_DATA.DSK...
The demo speed is tied to the speed at which the drive read the sectors (I count the sectors read during video processing, then I adjust the display accordingly, that's rather tough).
So if someone could compare the speeds, that'd be great.
Note that I've never run that code on a real machine, so I don't know the real behaviour...
Thanks,
Stefan
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383050 is a reply to message #383049] |
Sat, 13 April 2019 14:34  |
|
|
Originally posted by: Stefan C
On Saturday, 13 April 2019 20:32:08 UTC+2, Stefan C wrote:
> Hello,
>
> I've written a demo that relies heavily on Disk II timings. Somehow, when I run the demo on AppleWin and Mame, it behaves differently. Maybe it's the emulators, maybe it's my set up...
I use AppleWin 1.28 and Mame 0.182
Regards,
Stefan
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383072 is a reply to message #383050] |
Sun, 14 April 2019 08:36 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, 13 April 2019 19:34:21 UTC+1, Stefan C wrote:
> On Saturday, 13 April 2019 20:32:08 UTC+2, Stefan C wrote:
>> Hello,
>>
>> I've written a demo that relies heavily on Disk II timings. Somehow, when I run the demo on AppleWin and Mame, it behaves differently. Maybe it's the emulators, maybe it's my set up...
>
> I use AppleWin 1.28 and Mame 0.182
>
> Regards,
>
> Stefan
re. AppleWin
You must be using 'Disk Access Speed' = authentic, otherwise it runs far too fast.
> Somehow, when I run the demo on AppleWin and Mame, it behaves differently
Can you give some details about this different behaviour?
NB. AppleWin's "authentic" disk speed is probably far from authentic! It does a bit of spin emulation (based on number of cycles between $C0EC accesses) and sector skew (when internally converting .DSK to its internal nibble representation). This is never a substitute for running & checking on real h/w. I really recommend you do this, then raise a bug against AppleWin.
btw. there appears to be a bug in your demo: after running the demo successfully, when I reboot the Apple II system (eg. using F2), then the code doesn't wait for the key-press (at the prompt to swap disks) and so quickly loads the wrong data from "BAD_APPLE.DSK". I have to close AppleWin, then restart it to correctly be able to re-run the demo again.
Tom
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383073 is a reply to message #383072] |
Sun, 14 April 2019 08:49 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
> btw. there appears to be a bug in your demo: after running the demo successfully, when I reboot the Apple II system (eg. using F2), then the code doesn't wait for the key-press
I see that Frank M said similar over on csa2p:
"Just a minor point, but you'll want to clear the keyboard strobe (kbd: STA $C010) before the "done_print:" keypress checking routine [...]"
(And AppleWin should clear this on an F2 reboot though. I'll fix this...)
Tom
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383074 is a reply to message #383073] |
Sun, 14 April 2019 09:08 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, 14 April 2019 13:49:27 UTC+1, TomCh wrote:
>> btw. there appears to be a bug in your demo: after running the demo successfully, when I reboot the Apple II system (eg. using F2), then the code doesn't wait for the key-press
>
> I see that Frank M said similar over on csa2p:
>
> "Just a minor point, but you'll want to clear the keyboard strobe (kbd: STA $C010) before the "done_print:" keypress checking routine [...]"
>
> (And AppleWin should clear this on an F2 reboot though. I'll fix this...)
>
> Tom
Hmm... you code does:
..loop
:
LDA $C000
CMP #0
BEQ .loop
Instead you should be testing bit,7 as $C000 will only read as zero:
- after power on, and no key has been pressed
- if you have pressed & released CTRL-@
So your code should be:
..loop
:
LDA $C000
BPL .loop
STA $C010
Tom
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383078 is a reply to message #383074] |
Sun, 14 April 2019 09:49 |
|
|
Originally posted by: Stefan C
On Sunday, 14 April 2019 15:08:12 UTC+2, TomCh wrote:
> On Sunday, 14 April 2019 13:49:27 UTC+1, TomCh wrote:
>>> btw. there appears to be a bug in your demo: after running the demo successfully, when I reboot the Apple II system (eg. using F2), then the code doesn't wait for the key-press
Done :-)
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383079 is a reply to message #383072] |
Sun, 14 April 2019 09:54 |
|
|
Originally posted by: Stefan C
>
>> Somehow, when I run the demo on AppleWin and Mame, it behaves differently
> Can you give some details about this different behaviour?
Well, the overall speed is different. Since I synch on the sector reads, I concluded that the emulation of the disk drive is different between Mame and AppleWin.
Basically, what the demo does is :
- read a sector
- process the sector
- loop
if "process a sector" takes more time than reading a sector, then I use the sector address to know how much "time" the processing has took and adapt my speed appropriately (I do that because there's no timer in the Apple 2+)
>
> NB. AppleWin's "authentic" disk speed is probably far from authentic!
That's very bad news :-( I hope it's slower :-) (else I have a problem).
> This is never a substitute for running & checking on real h/w. I really recommend you do this, then raise a bug against AppleWin.
I'd love to but I'll have to ask the web for that : I don't have an Apple 2 :-(
Thx for your insightful comment !
Stefan
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383081 is a reply to message #383079] |
Sun, 14 April 2019 11:30 |
TomCh
Messages: 242
Registered: November 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, 14 April 2019 14:54:34 UTC+1, Stefan C wrote:
>>
>>> Somehow, when I run the demo on AppleWin and Mame, it behaves differently
>> Can you give some details about this different behaviour?
>
> Well, the overall speed is different. Since I synch on the sector reads, I concluded that the emulation of the disk drive is different between Mame and AppleWin.
>
> Basically, what the demo does is :
>
> - read a sector
> - process the sector
> - loop
>
> if "process a sector" takes more time than reading a sector, then I use the sector address to know how much "time" the processing has took and adapt my speed appropriately (I do that because there's no timer in the Apple 2+)
>
>
>>
>> NB. AppleWin's "authentic" disk speed is probably far from authentic!
>
> That's very bad news :-( I hope it's slower :-) (else I have a problem).
>
>> This is never a substitute for running & checking on real h/w. I really recommend you do this, then raise a bug against AppleWin.
>
> I'd love to but I'll have to ask the web for that : I don't have an Apple 2 :-(
>
> Thx for your insightful comment !
>
> Stefan
> I do that because there's no timer in the Apple 2+
Perhaps you can put a Mockingboard into slot 4 (or 5) and then use the 6522's 16-bit 1MHz cycle timer to debug the AppleWin vs MAME difference?
The 6522's 16-bit timer is a free-running countdown timer. Take care when reading as a carry can occur between reading the high 8-bits and low 8-bits. So maybe read high, low, and high'. If high != high' then re-read. NB. It's been a while since I've done this, so there's probably a better way!
If there's a Mockingboard in slot-4 then $C404 is the low timer byte, and $C405 is the high byte. It's always running, so there's no setup required.
Tom
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383093 is a reply to message #383081] |
Sun, 14 April 2019 23:50 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
|
MAME by default uses cycle-level disk access, meaning that the nibbles don't arrive fully-formed as they do in AppleWin, meaning that AppleWin disk reading will run a fair bit faster than MAME. If you want to match AppleWin behaviour, run MAME with "-sl6 diskii".
|
|
|
|
| Re: Mame and AppleWin different behaviour ? [message #383103 is a reply to message #383081] |
Mon, 15 April 2019 11:25 |
|
|
Originally posted by: fadden
On Sunday, April 14, 2019 at 8:30:52 AM UTC-7, TomCh wrote:
> The 6522's 16-bit timer is a free-running countdown timer. Take care when reading as a carry can occur between reading the high 8-bits and low 8-bits. So maybe read high, low, and high'. If high != high' then re-read. NB. It's been a while since I've done this, so there's probably a better way!
I know somebody who used to ask this during interviews for Linux kernel engineers. :-) Sort of a quick screening for "do you know about volatile pointers in C, do you know that interrupts exist", etc.
IIRC a common bad approach was reading low / high / low, and incrementing high if low rolled over. You can't be sure whether you initially read high before or after the low part rolled over. I think you have to do it the way you said: high / low / high, then re-read low if high changed. (With interrupts disabled, it shouldn't be necessary to check high a 3rd time.)
|
|
|
|
Members
Search
Help
Register
Login
Home
