Fig-Forth

[wawa.voun]

Hello,

On Mark's website I found 4 floppy image for running Forth on OS65D.

Mainly I am interested by Fig-Forth.

I don't own a C1P board but a Junior Computer and usually I run a modified Tut 5 floppy disk.
The modified bytes from original OS65 V3.3 Tutorial 5 track 0 and 1 (track 0 loaded in memory at $2200 and track one at $2A00) are as per joined picture.

Does anybody know if track 0 and 1 of these Forth disk are the same that on original OS65D V3.3 Tut 5 floppy ?

I can do this myself (maybe) but what is the best way to read datas inside a 65D or hfe image (track per track for example) and modify some bytes on a Linux or Windows machine ?

Tanks, regards.
Philippe

[Mark]

[edited: updated attachment txt, no content changes]
Well I gave it a shot based on the instructions you posted and it seems to have worked. The fig Forth disk seems to have a similar OS65D version, however it was missing a bit of code on track 1. Not sure if it was used-- it was all 0's on the FigForth disk. I just copied the missing bytes from tutorial 5 and patched according to the instructions provided. I was able to boot the disk with serial I/O and get an index. No further testing was done.
The modified disk image is attached below. Use OSIHFE to convert to HFE disk image if needed.
-Mark

Conversion of C1P-FIG-Forth.65D OSI disk dump image
Each OSI 5.25" dump track is $900 bytes long, 1st track starts at 0, 2nd at $900, 3rd at $1200 and so on. There is a 8 byte track & sector header on tracks 1+ before data. [edited] and a 3 byte track 0 header.

Step 1: remove excess noise from disk image, align tracks using OSIHFE

OSIHFE -c C1P-FIG-Forth.65D C1P-FIG-Forthclean.65D

Step2: load cleaned disk image into hex editor modify track 0 offsets [updated] $001A, $0048, $0088
copy code from OS65D tutorial $0D80-0DEF, modify offset $0D8B
save image as C1P-FIG-ForthcleanMOD.65D

Boot C1P-FIG-ForthcleanMOD.65D and this is the result on terminal:

Code: Select all

FIG-FORTH  1.0
1 60 index

  1 ( TRANSF LIST SCREENS TO OTHER SYSTEMS )
  2 DECIMAL
  3 ****************** FIG-FORTH  MODEL ***********************
  4   ( FORTH ERROR MESSAGES )
  5   ( ERROR MESSAGES )
  6
  7
  8 ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  9   ( NEWDSK     NEW DISK CREAT UTILITY ) DECIMAL
 10   ( DINIT    VARIOUS INITIALIZER ROUTINES ) DECIMAL
 11   ( DINIT2      NEW DISK CREATE WORDS ) DECIMAL
 12   ( FSAVE   FORTH SAVE BLOCK ) DECIMAL
 13   ( DISKIN     NEW DISK CREAT UTILITY ) DECIMAL
 14   ( SEDIT   STRING EDITOR FROM FIG MODEL ) DECIMAL
 15   ( SEDIT     STRING EDITING COMMANDS ) HEX
 16   ( ED10     STRING EDITOR COMMANDS ) HEX
 17   ( ED11       STRING EDITOR COMMANDS ) DECIMAL
 18
 19   ( CONSTANTS ) HEX
 20   ( COPY ) HEX
 21   ( ASM2 FIG MODEL ASSEMBLER PART #1 ) HEX
 22   ( ASM2 FIG MODEL ASSEMBLER PART #2 ) HEX
 23   ( ASM3      FIG MODEL ASSEMBLER PART #3 ) HEX
 24   ( ASM4    FIG MODEL ASSEMBLER PART #4 ) HEX
 25   ( ASM5 ) HEX
 26   ( ASM6 ) HEX
 27   ( ASM7 )
 28
 29   ( SEARCH DISK SCREENS )
 30   ( ?STK ) HEX
 31   ( DECODE PROGRAM 1/22/81 T ZIMMER ) DECIMAL
 32   ( DECOD2 PROGRAM 1/22/81 T ZIMMER ) HEX
 33
 34
 35   ( STRING        FORTH STRING STACK EXTENSIONS   BYTE 2/81 )
 36   ( STRNG2   FORTH STRINGS PART TWO BYTE 2/81 )
 37   ( STRNG3   STRING STACK WORDS PART 3   BYTE 2/81 ) HEX
 38   ( STRNG4   STRING STACK PART 4   BYTE 2/81 ) HEX
 39   ( STRNG5   STRING STACK PART 5    BYTE 2/81 ) DECIMAL
 40   ( STRNG6      TEST BLOCK FOR STRING HANDLING )
 41   ( STRNG7   STRING STACK ERROR CODES    BYTE 2/81 ) ;S
 42 : NLOA BL WORD ?LEN FNAME .
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
    OK

[wawa.voun]

Thanks Mark for your time about this question.

I open your image into a hex editor and noticed that offset $17 is at $1A, $45 at $48 and $85 at $88. Why these differences ?

There is even more difference on track one but I assume this is due to the track 1 header ?

Can I find somewhere a full description of the 65D disk image format ?

Thanks again and regards.
Philippe

[wawa.voun]

I found explanations into OSIHFE source code so now I understand what I see into the hex editor.

The last remaining question is the 7 bytes track + sector header. If I follow the explanations into the source code this should be 8.

It seems the "previous sector length" byte is missing.

It that true for all sectors ? On to all disks ?

Can I have an explanation ?

Regards.
Philippe

[Mark]

Oh, yeah, my listed offsets for track 0 are off due to the 3 byte header of track 0, and it is 8 for other tracks.
Track 0 on OSI starts with load addr hi, load addr lo, # pages. I'll update the original attachment & information.
Yes there are differences with the OS65D on the FigForth disk but the patches seemed to apply correctly and at the same spot as the OS65D tutorial disk 5 (perhaps just an older version or OS65D?). I loaded it up in WinOSI, stopped the execution at $2200 & $2214 to see where & what the patches did, and verified they looked correct on the FigForth disk as compared to OS65D tutorial disk, then located the corresponding addresses in the disk image. I redirected WINOSI serial port to a virtual serial port on the PC & connected TerraTerm to the port to see the I/O from the serial C1P booting FigForth.

The 65D disk format is just the serial decoded byte data from the disk track which was originally created from Ed's RAW Disk Dump utility years ago. It is the byte stream seen by the OSI disk ACIA, written with padding to make uniform track sizes.
This was created before there was a way to use or manipulate the flux transitions from things like kryoflux or all the ways it can be done today.
This works for OSI disks because except for 1* case, data is consistently written in FM 8E1 word format to the disk, without any half-tracks, copy protection or disk format tricks. The data is preserved, however the timing is lost with this format.
(* OS65U switches to 8N1 after the first 3 8E1 track bytes to pack more data per track on 8" floppies.)
The OSIHFE clean operation removes any extra noise bytes from the start of track and between sectors found on a RAW dump to provide a consistent layout better suited to hex editing offsets.

So the disk layout is the disk data written by the OSI padded to $900 bytes on 5.25" and $F00 bytes on 8". The content depends on the operating system. Generally all OS versions use the OS65D disk layout (Forth,Pascal,OS65D,HexDos,Dos/65,PicoDos,CP/M) except for OS65U.

[The end of sector mark doesn't appear on all disks. I think earlier versions of OS65D didn't enforce it, but I have not confirmed this yet. It doesn't seem to affect operation.]

The disk layout has been mentioned before, and is included in the source for the utilities I write. It's also reproduced below.
(I should put it up by itself somewhere too. There is more detailed timing analysis available too but not really needed for most cases.)

Code: Select all

Ohio Scientific OS65D
Track 0 format
10 millisecond delay after index hole
0,1 load address of the track in hi,lo form
2, page count of how much data is written on track 0, usually 8 on 5.25" 
3+ data

Track 1-n Format
10 ms delay after index hole
0,1 -a 2 byte start code $43, $57
2,  -BCD track number
3,  -track type code (always $58)
(sector data follows)

Sector Data
There can be any mixture of various length sectors. The total page count can not
exceed 8 pages (8*256) if more than one sector is on a track (5.25") 12 for 8"
Each sector is written in the following format:
-previous sector length (4 if none before) times 800 microseconds of delay
-sector start code $76
-sector number in binary
-sector length (#pages) in binary
-sector data
-(somewhat optional end of sector mark $47, $53) not enforced in older versions

------------------------------------------------------------------------------------
OS65U sector size is 3584  ($E00), one sector per track on 8" floppy 

Track 0 format
10 millisecond delay after index hole 8E1
0,1 load address of the track in hi,lo form
2, page count of how much data is written on track 0, usually 13
3+ data

Track 1-76 format
wait for index hole, set 8E1
$80, tkHi, tkLo, Reset ACIA 8N1 +few ms delay
$0F or $1F marker?, $E00 (3584) bytes data 
2 bytes checksum of trk header + data


The OSI 65D Raw disk dump format contains the track data minus any time delays

-Mark

[wawa.voun]

Thanks. Its more clear so I have made some tests on the Junior.

The serial Forth image wont boot. Boot start but nothing come out to serial port and after time out floppy stop and I have to reset.

I try to adapt the image you provide for work with the VDU video board. There is other modifications to do as per joined image.

Mod 1 give the modification to apply to track 0 loaded at $A200.
Mod 2 give some vector changes also on track 0 loaded at $A200

These modifications works well with standard OS65D 3.3 Tut 5 floppy.

With these modifications the system boot but I get on the video display an Err#9 and then A* prompt but not Forth.
So I assume the system boot but cant continue to load something (Forth ?).

The modified image I have tested is also joined.

Thanks for any help and advices.

Regards.
Philippe

[Mark]

I haven't investigated why figforth doesn't run however I did look at the disk & mods you posted.
It seems there were a couple of transcription errors.

moderr.gif (7.29 KiB) Viewed 1513 times

The values in red should be '8D'
here is a text version or Tableau 2 which may be easier to read.

Code: Select all

A200: A9 01 8D 5E 26 20 BC 26 A9 2A 85 FF 20 54 27 86
A210: FE 20 67 29 20 79 2E A0 BF 20 EC 22 F0 03 88 D0
A220: F8 8C 00 23 A2 01 8E C6 2A 4C 41 22 EA EA EA EA
A230: EA EA EA EA EA EA EA EA EA EA EA EA EA EA EA EA
A240: EA A9 00 8D F7 EF 8D D2 EF 20 35 F4 20 30 F3 20
A250: 61 27 20 73 2D 0D 0A 0A 2A 44 4F 53 20 4A 55 4E
A260: 49 4F 52 20 43 4F 4D 50 55 54 45 52 20 20 56 32
A270: 2E 30 2A 0D 0A 0A 43 4F 50 59 52 49 47 48 54 20
A280: 42 59 20 45 4C 45 4B 54 4F 52 00 A9 2E 8D 7C FA
A290: A9 FF 8D 7D FA A9 00 8D 7A FA A9 FC 8D 7B FA 4C
A2A0: E6 2A

The corrected disassembled code looks like this

Code: Select all

2200 A9 01    LDA #$01
2202 8D 5E 26 STA $265E	;sector#1
2205 20 BC 26 JSR $26BC	;seek track 1
2208 A9 2A    LDA #$2A
220A 85 FF    STA $FF
220C 20 54 27 JSR $2754	;load head & seek start of track data
220F 86 FE    STX $FE
2211 20 67 29 JSR $2967	;read track to $2A00-$31FF
2214 20 79 2E JSR $2E79	;(read trk6,2 to $3200; trk6,3 to $0000),trk13 to $3274-$3A73
2217 A0 BF    LDY #$BF	;(start of elector modifications)
2219 20 EC 22 JSR $22EC
221C F0 03    BEQ $2221
221E 88       DEY
221F D0 F8    BNE $2219
2221 8C 00 23 STY $2300
2224 A2 01    LDX #$01
2226 8E C6 2A STX $2AC6	;select drive 1
2229 4C 41 22 JMP $2241
222C EA       NOP
222D EA       NOP
222E EA       NOP
222F EA       NOP
2230 EA       NOP
2231 EA       NOP
2232 EA       NOP
2233 EA       NOP
2234 EA       NOP
2235 EA       NOP
2236 EA       NOP
2237 EA       NOP
2238 EA       NOP
2239 EA       NOP
223A EA       NOP
223B EA       NOP
223C EA       NOP
223D EA       NOP
223E EA       NOP
223F EA       NOP
2240 EA       NOP
2241 A9 00    LDA #$00
2243 8D F7 EF STA $EFF7
2246 8D D2 EF STA $EFD2
2249 20 35 F4 JSR $F435
224C 20 30 F3 JSR $F330
224F 20 61 27 JSR $2761	;lift head & return time
2252 20 73 2D JSR $2D73	;Print Message following call terminate with 0
2255 0D 0A 0A .BYTE $D,$A,$A,'*DOS JUNIOR COMPUTER  V2.0*'
2273 0D 0A 0A .BYTE $D,$A,$A,'COPYRIGHT BY ELEKTOR'
228A 00       BRK
228B A9 2E    LDA #$2E
228D 8D 7C FA STA $FA7C
2290 A9 FF    LDA #$FF
2292 8D 7D FA STA $FA7D
2295 A9 00    LDA #$00
2297 8D 7A FA STA $FA7A
229A A9 FC    LDA #$FC
229C 8D 7B FA STA $FA7B
229F 4C E6 2A JMP $2AE6
22A2 A0 00    LDY #$00

I like how Elector Jr. and Compukit both put "copyrights" on OSI stolen(?) code.

The 2nd mod changes entries in OS65D device I/O table at $2301+. The addresses are the I/O subroutine location -1.
Upon boot it loads the contents of [$2311,$2312] on the stack ($FEFF) and does RTS which causes execution at $F000.
Is this a valid ROM location in Elector Jr.?
I guess if you can send Elector Jr. ROMs and device memory map I could dig into this further.

Attached is your VDU disk with the corrected patch values.
Cheers,
-Mark

[wawa.voun]

Thanks for the correction. Scan of old magazines is not always easy to use...
I will give a try with these modifications.

The eprom are hereunder. I have also add the sources.

The memory map is as follow :

$0 - $BFFF is ram
Floppy controller is at $C000-$C0FF
6845 display controller $C1xx
display memory $D000 - $D7FF
$E000 - $E3FF is ram
$E400 - $E7FF is ram
$E800 - $EFFF is ram
$F000 - $F7FF PMV rom with the video display routines (2716 eprom)
$F800 - $F9FF is VIA
$FA00 - $FBFF is PIA
$FC00 - $FFFF Bootstrap is the 'monitor', basically hex display + keyboard management and track 0 reading at boot (start address $FF17) (2708 eprom)

I hope I make no mistake !

Thanks again for your time and kindness on this topic.

Regards.
Philippe

ps :
I agree that put a new copyright on code writed by somebody else is not very fair...

[bxdanny]

Hi Phillippe, hi Mark,

I have been following this thread. I actually posted a short message with a brief summary of the 65D disk formats earlier, but then saw Mark had posted a more detailed description, apparently while I was editing my message, and it looked like I was just restating a portion of what Mark had posted, so I deleted my post.

FWIW, the 65D track format descriptions can be found at https://osiweb.org/manuals/OS-65D_V3.0_usermanual.pdf, on the last page of the PDF. (The references to 12 and 13 pages on a track are for 8" disks, for 5.25" disks the maximum is always 8 pages per track.) That manual really has a lot of useful information in it, and is fully applicable to 65D 3.1 and 3.2 as well. Much of the information in it applies to 3.3 also.

(BTW, Hexdos uses its own unique disk format, as described in its manual, but all the other systems mentioned do use the 65D physical format. DOS/65, as was discussed in the thread about it, uses it even on track 0, which is why it can't be booted directly with the standard ROM.)

Since the Elektor computer doesn't use an ACIA for its serial port, setting a disk to use an OSI serial port (whether at $F000 or $FC00) clearly will not work on it. I wonder if it might not make more sense to try to move Fig-Forth onto a copy of the modified 65D 3.3 disk (replacing BASIC on tracks 2-6) than to try to put the right drivers and initialization code onto the Fig-Forth disk. Or even load it from a BASIC (or XQ-table) program, pre-pended by a block-move routine that would move it to its correct address and jump to its entry point.

[bxdanny]

Philippe,

As I was going to mention, ERR #9 is a disk read error.

What seems to be happening with your disk is that it is trying to read a non-existent Track 6, Sector 2. But track 6 only contains a single 1-page sector.

(And now I finally understand why there is no error message specifically meaning "can't find that sector", but only "can't find preceding sector". If the sector being looked for isn't found, the error message generated is #9, which technically means that the index hole was encountered.)