fig-Forth

[eastonj]

fig-Forth

[davisgw]

I'm not sure if this is archived somewhere but here is a scan of the OSI-Forth user manual.

[davisgw]

Mark,
Do you know whether the fig-forth image at https://osi.marks-lab.com/software/file ... -Forth.65D will boot and run on a C1P? I've written the image to diskette and tried to make a system disk from the instructions I have but having no luck....

[Mark]

Hi,
After looking at C1P-FIG-Forth.65D, it looks like the disk is mostly intact, however the instructions for fig forth posted earlier are not for the same version. This image came from a random collection of OSI floppy disks for which I have no information. It may be a demo version?

The disk image itself looks like a raw dump with the garbage data that comes along with it. It may work better if run through OSIHFE in clean mode before writing. e.g. osihfe -c C1P-FIG-Forth.65D C1P-FIG-Forth-clean.65D

I booted it in the emulator and played with it a bit and discovered I really don't understand Forth I've encountered Forth many time over the years and it somehow always confuses me! Commands like "1 39 index" seem to work, and I can load various screens, however some reported errors seem to indicate bad disk data. (like FSave)?

I see DiskTool may be having problems writing multisector OS65D tracks on stock 1MHz C1P. According to the timing in my emulator, the intersector delay needs to be shorter at 1Mhz to prevent multisector tracks from exceeding the track length. In other words I need a shorter gap. This doesn't affect tracks with single 8 page sectors or tracks with multiple sectors that total 6 or 7 pages total. FigForth uses 2 4-page sectors per track for its screens and I think the end of the 4th page in the 2nd sector could getting truncated. You could confirm this by re-downloading the disk image previously written to the OSI & sending it to me.

This and a bunch of other issues in multiple programs are being fixed now.

I anyone has any other copies of OSI software including Fig-Forth, please post them!

[davisgw]

Mark,
First let me say that I know even less about Forth than you A friend in the '80's provided a copy of OSI-FORTH along with the document I posted, so I think they match. Attached are two FORTH images I downloaded. The first is the C1P-FIG-Forth.65D floppy dump you requested for analysis. It boots but displays "parity error" for every command to load a page. The second is a dump of the OSI-Forth 2.0 diskette from my friend. It boots and immediately hangs the system when complete. Let me know what you find. Thanks.

[davisgw]

Mark,
I ran both of the images I posted thru OSIHFE and had some success with another mystery. The resulting Fig-Forth image written to disk did not act differently from the original. But with the resulting OSI-Forth image written to disk, following the instructions I have which called for copying OS65D3.2 to tracks 0 - 13, boots and appears to load and execute pages on my 600B using my S-100 video card...no hangs or errors. However, it does not boot all the way on my 600D that has 48 chars per line turned on in ROM....in fact the opening message of "OSI Forth 2.0 ...." seems slow to display.
Anyway here is the cleaned OSI-Forth image without the OS65D3.2 overlay.

[davisgw]

I have the OSI-Forth working on both my 600B and my 600D. Back in the '80s after bringing up the 600B with S-100 expansion I modified the BEXEC* for that system and never documented the changes. So now the unmodified version boots and runs on the 600D. I'm attaching the corrected image and a copy of the changes that WERE in BEXEC*. I left line 8 in the BEXEC* because it affects disk access and may be important...

[Mark]

Thanks for the update, I'm glad you got it working!

Well, it looks like DiskTool CAN correctly write multisector tracks at 1Mhz correctly. I realized I could assert the WAIT line on the system bus on the C4P to force 1MHz mode without any clock adjustments to test disk writes. [ I also rediscovered that WAIT is asserted whenever the 505 C4P accesses upper addresses (I think the ROMS & I/O hardware - but I didn't map the decoder completely.) ] I guess that can affect disk timing too if expecting 2Mhz mode & getting 1Mhz whenever you read disk hardware

I looked at the original disk that the Fig-Forth 1.0 on my website came from, imaging it with Grease Weasel just to be sure, and unfortunately found the 2nd sectors to be truncated by ~34 bytes on the original as well. According to the BEXEC* on the FigForth disk, OS65D is patched to have a shorter intersector gap length, but the disk must have been copied with a copier using standard timing, or the drive was rotating faster resulting in the 2nd 4-page sectors being truncated. Most of those pages are just full of blank space characters, but a few have chopped off code. The basic figforth system works, it's just a couple of data pages that have problems.

I had a quick look at the FigForth image you posted -- I noticed if I have RAM at CFxx it hangs on reading the nonexistent OSI 550 serial ports - setting ram to FF breaks the loop. Somehow the I/O map has enable device #8 the CA-10X/OSI550 serial ports. Oh I see its in Bexec* "130 PRINT#5,"IO 10,80"CHR$(13);" - maybe it should be 130 PRINT#5,"IO 10,02";CHR$(13); or even 10,00 ? Was that a mod for your S100 video?
02 makes the boot a little more interesting...

Boot screen when device output set to 02

device02.gif (2.8 KiB) Viewed 4244 times

This disk uses 8 single page sectors for screens instead of 2 4-page sectors. It looks like the last sector on these tracks are truncated too by about 144 bytes! Most of these pages are blank anyway. The main forth system tracks use 1 8-page sectors and are intact.
You can use osihfe -t <filename> to test the disk images and view track layout such as

Code: Select all

osihfe -t osi-forth.txt
Test: disk type OS65D5
Trk 00 Boot @ $2200/8 pages
Trk 01 1/8
Trk 02 1/8
Trk 03 1/8
Trk 04 1/8
Trk 05 1/8
Trk 06 1/1
Trk 07 No Sector 1
Trk 08 No Sector 1
Trk 09 No Sector 1
Trk 10 No Sector 1
Trk 11 1/1
Trk 12 1/1 2/1 3/1 4/1
Trk 13 1/5
Trk 14 1/8
Trk 15 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 16 1/8
Trk 17 1/8
Trk 18 1/8
Trk 19 1/8
Trk 20 1/8
Trk 21 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 22 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 23 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 24 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 25 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 26 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 27 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 28 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 29 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 30 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 31 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 32 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 33 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 34 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 35 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 36 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 37 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 38 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Trk 39 1/1 2/1 3/1 4/1 5/1 6/1 7/1 8/1
Possibly damaged file OS65D3

It bases the file damage on the directory map and the presence of sectors based on that map. For .HFE/.SCP files it will also check for parity errors and file damage, but there is no parity information in .65D files so it can't detect that corruption. Since the directory says file OS65D3 uses track 1-12 and some tracks have no sectors in that range, it marks it as possibly bad. (It doesn't know if short files are OK or not.)

I guess the last thing to do is update the directory on track 12 to better match the layout of the disk. This doesn't seem to match:

Code: Select all

osihfe -d osi-forth.txt
OS65D File  Track range
-----------------------
 OS65D3      00 - 12
 BEXEC*      14 - 14
 RSEQ        15 - 18
 REPACK      22 - 25
 DISASM      26 - 29
 GSOSRT      30 - 32
 DATRAN      33 - 34
 BUFFER      35 - 38

56 entries free out of 64

Anyway good progress!
Cheers!

[davisgw]

Mark,
After looking at the documentation for OSI-Forth previously posted I realized that sometime in the '80s I had copied OS65D disk 2 to a blank and overlaid the Forth system disk on tracks 0-11, which left the directory showing disk 2 files that were not there. So I have followed the instructions from page 10 to create a good system disk. Part of that process is to initialize block storage starting on track 21. Now Disktool fails with lots of errors beginning on track 21...I tried 3 different disks with the same result so I'm unable to post a corrected image and I suspect the one I posted did not have initialized block storage. And I think Disktool cannot handle the format of the block storage tracks.
So either I can post a corrected image without initialized block storage or maybe you have a way to remove the filenames from the directory,,,it should only show OS65D3 and BEXEC*.
Also do you or bxdanny know what is changed by the following statements in the BEXEC*? Either video format or write sector delay time?
POKE 9625,76:POKE 9626,59:POKE 9627,255
POKE 10406,0:POKE 10407,234
POKE 10408,234:POKE 10409,234:POKE 10414,253

[bxdanny]

davisgw,

POKE 9625,76:POKE 9626,59:POKE 9627,255 ==> 2599 4C3BFF JMP $FF3B

$2599 is the start of the video output routine in OS-65D. $FF3B, in the standard SYN600 ROM (and in CEGMON as well), is the middle of an instruction, and jumping there can be expected to crash the machine. But in your custom boot ROM, $FF3B contains the instruction JMP $E000, which is to say, it jumps to your routine to output to the S-100 video board. So this must be a patch which you created, to direct output to your video board. So how is the disk booting at all on other systems? Because the line containing those POKEs is REMmed out in the BEXEC* on the actual disk, although not in the separate listing of it that you posted.

Here are the relevant lines from your actual BEXEC*:

3 REM ACTIVATE THE 16 X 64 VIDEO DISPLAY,
4 REM SET THE SERIAL BAUD RATE TO 4800 FOR THE PRINTER,
5 REM AND MODIFY THE DOS WRITE SECTOR-SECTOR DELAY TIME!!
6 REM POKE 9625,76:POKE 9626,59:POKE 9627,255
7 REM POKE 61440,3:POKE 61440,16:POKE 10406,0:POKE 10407,234
8 POKE 10408,234:POKE 10409,234:POKE 10414,253

The POKEs in line 8 I THINK disable a delay loop, which may have been used to cause a pause between sectors written, and so disabling it would make the sectors closer together, and so make 8 one-page sectors reliably fit on a track. But I'm not certain that's what it is.

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?