Previous Thread
Next Thread
Print Thread
Page 4 of 9 1 2 3 4 5 6 7 8 9
Re: Apple II disk seek issue [Re: peter ferrie] #97129 11/28/14 04:44 PM
Joined: Mar 2006
Posts: 1,043
L
Lord Nightmare Offline
Very Senior Member
Offline
Very Senior Member
L
Joined: Mar 2006
Posts: 1,043
could it be dependent on the Woz state machine stuff somehow? (or does that also dictate exactly 4us? I never fully understood the woz state machine on the DiskII card...)

LN


"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
Re: Apple II disk seek issue [Re: peter ferrie] #97178 11/30/14 09:17 PM
Joined: Mar 2001
Posts: 16,575
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,575
4 us is primarily due to the disk rotation speed vs. the write density, as I understand it. The state machine has no say in the matter.

To the matter at hand, IWM documentation states:

"In the read state the data is shifted into the LSB of the shift register, and the shift register shifts data from LSB to MSB. A full data nibble is considered to be shifted in when a one is shifted into the MSB. When a full data nibble is shifted into the internal shift register, the data will be latched by the read data register and the shift register will be cleared to all zeros so that it will be ready to shift in the next data word".

The boldface part all but states that IWM indeed has a one-GCR-byte buffer. I don't know if this also applies to the original Woz state machine - it's possible it's a safety feature that was added to the IWM.

Last edited by R. Belmont; 11/30/14 10:23 PM.
Re: Apple II disk seek issue [Re: peter ferrie] #97179 11/30/14 11:49 PM
Joined: Jun 2014
Posts: 84
P
peter ferrie Offline OP
Member
OP Offline
Member
P
Joined: Jun 2014
Posts: 84
I reordered two pairs of instructions, which shortened the delay between reads by a few cycles, and now MESS runs my code consistently. So it appears that as far as MESS was concerned, I was missing the window... but the sectors that were read successfully (and there were some) just happened to have the right bits in the right place, and also match the checksum? That seems unlikely, but I suppose that it could happen.

If a bit is shifted every 4 cycles, then it would need 32 cycles to form the byte, after which there would be 4 more cycles in which the read could be performed and acquire the correct byte. So any read that is faster than ~32 cycles would poll for the byte to be completed. That should cover both my code and Sherwood Forest, even though both of them appear to fall within that range. It appears that I've fixed my code to fit an even more restricted range. I'll double-check the cycle count for Sherwood Forest.

Re: Apple II disk seek issue [Re: peter ferrie] #97180 11/30/14 11:55 PM
Joined: Mar 2001
Posts: 16,575
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,575
FWIW, the .EDD protected original image of Sneakers also reads data incorrectly (it'd actually work, protection and all, otherwise), so it's not just your code and Sherwood Forest.

Last edited by R. Belmont; 11/30/14 11:55 PM.
Re: Apple II disk seek issue [Re: peter ferrie] #97192 12/01/14 01:19 PM
Joined: Jun 2001
Posts: 421
O
Olivier Galibert Offline
Senior Member
Offline
Senior Member
O
Joined: Jun 2001
Posts: 421
Originally Posted By peter ferrie
If a bit is shifted every 4 cycles, then it would need 32 cycles to form the byte, after which there would be 4 more cycles in which the read could be performed and acquire the correct byte. So any read that is faster than ~32 cycles would poll for the byte to be completed. That should cover both my code and Sherwood Forest, even though both of them appear to fall within that range. It appears that I've fixed my code to fit an even more restricted range. I'll double-check the cycle count for Sherwood Forest.


Ok, I've looked at the LSS code again, and the window is wider than that, it's around 10 cycles. They use the fact that the next bit has to be 1 (so no need to store it immediatly) and it waits roughly 2us before storing the next one.

In any case, given your timings that should work. I really need to add some visualizations to the debugger to see what's going on...

OG.

Re: Apple II disk seek issue [Re: peter ferrie] #98288 02/21/15 01:38 AM
Joined: Jun 2014
Posts: 84
P
peter ferrie Offline OP
Member
OP Offline
Member
P
Joined: Jun 2014
Posts: 84
I had a much longer look at this today. I see that LSS returns the proper value, but the value cannot be fetched in time before it is lost.

Here's a snippet that shows the problem. It comes from the Choplifter EDD image, which cannot even load the bootsector, due to the issue.

execute_run() called with icount=3
sta $300, y (partial)
timer event occurs
lss_sync() commits #$15, lss_predict() returns #$2a
execute_run() called with icount=4
sta $300, y (complete)
now icount=2
bne $-#$10 (partial)
timer event occurs
lss_sync() commits #$2a, lss_predict() returns #$55
execute_run() called with icount=3
bne $-#$10 (complete)
now icount=2
sty $3c (partial)
timer event occurs
lss_sync() commits #$55, lss_predict() returns #$ab
execute_run() called with icount=4
sty $3c (complete)
now icount=3
ldy $c08c, x (partial)
timer event occurs
lss_sync() commits #$ab, lss_predict() returns #00
(**)execute_run() called with icount=6
ldy $c08c, x (complete), y=#$55
now icount=5
bpl $-3 (taken)
now icount=2
ldy $c08c, x (partial), y is still #$55
timer event occurs
lss_sync() commits #00, and we've missed it

beginning at (**) the icount is so small that the loop cannot complete before the lss.data_reg is thrown away.
Does LSS form the value too quickly, or is the timeslice somehow not long enough?


Re: Apple II disk seek issue [Re: peter ferrie] #98289 02/21/15 02:10 AM
Joined: Mar 2001
Posts: 16,575
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,575
Does adjusting the clock of the wozfdc state machine down a little get things in better sync? Specifically this line in diskiing.c:

Code:
MCFG_DEVICE_ADD(WOZFDC_TAG, DISKII_FDC, 1021800*2)


That last value. Turning it down a small amount would cause LSS to advance more slowly.

Re: Apple II disk seek issue [Re: peter ferrie] #98290 02/21/15 02:20 AM
Joined: Mar 2001
Posts: 16,575
R
R. Belmont Offline
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,575
For me, turning it down to 1020000*2 fixes the corrupted initial screen in the Sneakers EDD but it still fails a checksum test later on in the boot.

I expect OG will wake up in about 6 hours and tell us why doing that is horrible, but it's getting results in the meantime ;-)

Re: Apple II disk seek issue [Re: R. Belmont] #98291 02/21/15 04:38 AM
Joined: Jun 2014
Posts: 84
P
peter ferrie Offline OP
Member
OP Offline
Member
P
Joined: Jun 2014
Posts: 84
Originally Posted By R. Belmont
For me, turning it down to 1020000*2 fixes the corrupted initial screen in the Sneakers EDD but it still fails a checksum test later on in the boot.


Yes, I can confirm both of those. However, the read problem remains, it's just delayed a bit. Further, the reboot might fail to find the even the first byte of the address prologue, because the values become so completely wrong, the expected value never shows up.

Originally Posted By R. Belmont
I expect OG will wake up in about 6 hours and tell us why doing that is horrible, but it's getting results in the meantime ;-)


I'd prefer that he wakes up and tells us the answer. :-)

Re: Apple II disk seek issue [Re: peter ferrie] #98292 02/21/15 09:13 AM
Joined: Jun 2001
Posts: 421
O
Olivier Galibert Offline
Senior Member
Offline
Senior Member
O
Joined: Jun 2001
Posts: 421
Nice trace.

So the window is 3-4 cycles between each bit, and 6 after the last one. IIRC it should be 10 after the last one, which explains your problem. With 4 cycles more Y would be set.

The 10 cycles come from knowing that the next bit will be a 1 so you don't have to write lss until after having asserted the value of the following one and entering the window of the one even after. A very woz-ish way of giving more time to the cpu.

I'm even surprised lss-predict predicts 0x00. It should predict 0x02 or 0x03, according to that process. Let's see...

OG.

Page 4 of 9 1 2 3 4 5 6 7 8 9

Who's Online Now
0 registered members (), 43 guests, and 3 spiders.
Key: Admin, Global Mod, Mod
ShoutChat Box
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,811
Posts115,965
Members4,914
Most Online890
Jan 17th, 2020
Powered by UBB.threads™ PHP Forum Software 7.7.3