fig-Forth

[davisgw]

bxdanny,
The POKE 9625,76:POKE 9626,59:POKE 9627,255 were added by me back when I was building my S-100 system and my latest ROMs have moved the video driver to $E320....hence the hangs when I tried to boot the Forth disk. That's why I REMed out those statements this weekend because it was hanging both the 600B and the 600D systems.
But the POKE 61440,3:POKE 61440,16:POKE 10406,0:POKE 10407,234 and POKE 10408,234:POKE 10409,234:POKE 10414,253 must have been provided by the friend who gave me the OSI-Forth and the documentation because I never used it except to create disks that would run on the S-100 system. I guess I will try looking at the OS65D 3.2 code to see the change it makes.
Mark,
I created a OSI-Forth image without initialized block storage and was able to download it with Disktool. But if someone uses the image to create a disk and the block initialize is done after booting it I am not sure if all the screens will get clobbered. I think it would be smart to make 2 copies to preserve the screens so that if initializing block storage blows away the screens they can be copied from the second disk.
Do you think I should post it?

[Mark]

Mark,

I'm impressed with how you found that 34 bytes were truncated from the 8th sectors. But I'm wondering: can a sector continue past the index hole into the start of the "next revolution" of the disk? 34 bytes would take 34 * 88 = 2,992 microseconds, which is more than the 1 millisecond delay there supposedly is between the index hole and the track header. But I'm not sure how long the index hole itself lasts for (I haven't been able to find anywhere what the angular size of the index hole is supposed to be), nor if that 1 msec delay is the right figure for 5.25" diskettes.

If there were a few bytes going past the index hole, I presume the .65D format would simply include them without any indication of that. Still, I'm wondering how WinOSI handles requests to read bytes from a track after the designated end of data on the track has been reached. Not because of things like these FORTH tracks, but for things like some versions of the DI (sector directory) command. Will it start from the beginning of the track again? I think it doesn't and (correct me if I'm wrong) will hang waiting forever for the RDRF bit to go high. If that's the case, can that be changed?

Compute's Gazette #20 Jan 1982 p136 & Part 2 #21 have a very detailed description of actual OSI disk timing. It varies greatly from what OSI states. I believe it shows that 8 single-page 65D sectors on a 1MHz will not fit on 5.25" track with actual timing.

As you state - the disk rotates, the index hole comes into view & index goes active, then as it passes goes inactive again. This is the edge that all later OSI code use to start the sector timing. Supposedly delaying at least 1ms before starting writes. But how long is the index active? 5ms? SA800 says 1.7ms +/-5ms, SA801 says 0.4ms +/- .2ms. I can't find Ed's original RawDump code, but all the ones since 2004 stop reading a track when the index is active.

As a test I modified the disk dump read code to include the area "under" the index hole for the FigForth disk I have, but was unable to retrieve any more valid data. I just got a series of $01s, which in itself was unexpected (perhaps leftover MFM data from PC formatted blank?).
I'm not sure how FlashFloppy handles the index signal at all! The virtual disk creates the index signal, but it's unclear if anything in the track image starts the index or if it just starts before the track data is clocked out, or if it's just a fixed duration at the start of data(my assumption).

I recall some OSI disk write code checking for reassertion of the index signal during write and exiting the write code, but the code in the disassembly of OS65DV3.2 shows it only waits until the next byte is accepted and does no other checking. It will try to verify what it wrote though. (Perhaps I saw that in one of the other OSes?) Anyway it seems possible that OS65D writes "under" the index hole. Perhaps the disk dumper needs to read through index activation?

So for "RawRead" it fills the buffer with zeros, then starts saving all the data from the time the index ends until it is active again. Depending on the disk this could be 0 or up to 2.2K of data. One change I made was to include a "high water" mark at the end of the track buffer to indicate the last byte read. This value is used in WinOSI to stop clocking out bytes on virtual tracks, otherwise all the extra zeros in the disk padding would keep streaming out.
So eventually the index comes around on the virtual track in WinOSI, it passes, and then data becomes available again and the track is replayed. At least that is how it should work. There have been a few bugs when the high water mark was added that broke things for a while. DI should work in the current version, or at least in the version I'm working on

So on OS65D, during boot there is code at $2E84 that gets called which measures the 60Hz clock from the OSI540 board by testing the high bit of $DE00 & counting loops. For 1Mhz or no detection you get a value of $31, for 2Mhz ~$62 and so on. This "NMHZ" value @ $267B changes some of the time delay values used on OS65D. So does the C1P use 1Mhz timing for any CPU frequency? I don't think it has the equivalent clock. Also is there any programmatic way to detect a series II 600D vs original 600?

You can detect the amount of CPU clocks needed to clock out bytes of the disk ACIA & determine CPU speed, but an 8" disk on a 2MHz machine looks a lot like a 5.25" on a 1Mhz machine ACIA-wise. Further testing drive characteristics could identify machine configurations programmatically.
The other unique clock is the 400ms 5.25" or 1sec 8" clock connected to CB1 on the disk PIA. But do all disk controllers have this strapped?

davisgw,
You should be able to successfully dump any disk image that works on your C1P without errors using disktool or the older OSIDump even if you are having write problems with the disk image in disktool. (Unless data is being written to the hidden area under the index hole)...
Please "ZIP" up posted images to ensure data integrity. It will be interesting to see what you've made!

[davisgw]

Mark,
I don't think you get what I'm saying. I'm not requesting Disktool changes, but it clearly cannot dump a fully prepared OSI-Forth system disk. The format stated in the manual is:
Track 0-13 - OS65D3.2, 14 - BEXEC*, 16-20 - FTHSYS, 21 - 39 - BLOCK STORAGE
Every disk I tried to dump got errors starting at track 21 and gave up reading with the dump unfinished.
The instructions to prepare a system disk from my notes is:
1) Initialize a blank diskette
2) Copy tracks 0 - 14 from the Forth master diskette and then boot the Forth master diskette
3) Type "8 LOAD" and insert the new diskette. Then type "SYSCOPY"
4) Insert the Forth master diskette and type "12 LOAD"
5) Insert the new diskette and type "SYS0-INIT". This may take several minutes.
6) insert the Forth master diskette and type "9 LOAD".
7) Insert the new diskette and type "0 14 COPY-SCREENS". Then follow onscreen instructions.
For dual drive systems load screens 10 and 11 instead of 12 and 9.
After steps 4 and 5 the disk cannot be dumped by Disktool. So I'm posting the image that will need further prepping to
be a operational Forth system diskette. I just verified that step 5 will indeed wipe out the screens so 2 copies of this image is necessary....one for the "master" and one for the "new". Then skip steps 1 - 3 and execute the rest to get a runable Forth system diskette.
Please let me know if this process does not work.

[bxdanny]

Mark,

Thank you for your quick and detailed reply.

I know about that speed test using a signal from the 540 board, and about the possibility of using the ACIA instead. In fact, I used that method on one of the actual disks I sent you way back in 2005, and in the image I posted in the second message in the "Superboard Expanded on S-100 motherboard" thread (available here). And I wonder if you could do me a favor involving testing that.

I'd like to see what the results are of booting it multiple times on a real C4P. (Your system has a crystal-derived clock speed of exactly 2 MHz, right?) Specifically, boot the disk about 10 times and let it display what the value it puts into $267B is each time. You can add a line to the BEXEC* like

122 PRINT"DELAY VALUE =";PEEK(9851)

I expect there will be some variation between boots, but I'd like to see how much, and what the average is. If the average exceeds 101.5 (is closer to $69 than to $62), then I guess I should change the byte (on track 1) that loads to $2E9C from $E8 (INX) to $EA (NOP).

-Danny

[davisgw]

bxdanny,

The mystery POKEs at 10406 - 10414 in the Forth BEXEC* modify a delay as you stated:

$28A5 Becomes
LDX #$12 LDX #0
DEX NOP
BNE $28A7 NOP
NOP NOP
NOP NOP
DEY NOP
BNE $28A5 DEY
BNE $28FD

So I removed them from the BEXEC* and booted, typed "12 LOAD", "SYS0-INIT" and there was no disk activity in response.
Then I put the POKEs back, rebooted and repeated the process....it worked as expected.
I DEFINITELY did not come up with that patch, but someone gave it to me to solve a floppy timing issue.

[Mark]

Okay so OS65D (or at least FigForth) DOES write "under" the index hole.

The string of $01s I got when trying to read during the index bothered me/made no sense and I discovered a coding error - I was saving the status instead of the data.
So the extra bytes from my FigForth disk were there after all.

This is a problem, because Grease Weazle will stop reading when index is asserted, and the data is not captured. Fortunately besides HFE single rotation images, it also supports SCP "super copy plus" format which can contain 3 or more rotations of sampled data. The extra OSI data should be available at the beginning of the following rotation. I need to make some coding changes to OSIHFE. OSIDump etc.

Gotta run - more later.