Another SEDORIC correction.

[Ray030471]

My ORIC (emulator) is back on for a bit more development work now that I have the time.

Whilst carrying out some testing I discovered a problem associated with the PUT command when it utilises the 2nd disk bitmap sector. I introduced this bug when I created the patches to accommodate large disks (ie with more than 1920 sectors) and I am surprised that I didn't realise this before now.

If you have the patience, enter the following Basic program, run it (it will take a while) with an otherwise empty disk and then use NIBBLE to step through the descriptor sectors for the data file. You can repeat this exercise with a freshly formatted disk after you implement the below cure.

100 F$="TEST.TXT"
110 SEARCH F$
120 IF EF=1 THEN DEL F$
130 A$=""
140 FOR I=65 TO 125:A$=A$+CHR$(I):NEXT
150 A$=A$+A$
160 A$=A$+A$
170 A$="------"+A$
180 PRINT LEN(A$)
190 '
200 OPEN S,F$,0
210 FOR I=1 TO 2000
220 PRINT I
230 PUT 0,RIGHT$("0000"+MID$(HEX$(I),2),4)+A$
240 NEXT
250 CLOSE 0

Lines up to 180 will delete the file "TEST.TXT", if it exists,and set A$ to be of length 250 characters.
Lines from 200 will open the file "TEST.TXT", creating it anew, and write 200 records each of length 254 characters (so that each record occupies exactly one sector for simplicity of testing) before closing the file.


The PUT command will create file descriptor sectors suitably as data is written to the file. In some cases, the PUT command will use sectors already allocated to this task. When there are no spare sectors already allocated, the command will secure (up to) 3 more sectors and this can overwrite the pointer to the current descriptor in RAM. If the second disk bitmap sector is loaded, because the 'first' free sector is identified in the second disk bitmap sector, then this disk bitmap sector is saved to disk instead of the file's current descriptor.

The correction involves resetting the pointer to the file's current descriptor in RAM before it is saved to disk. This uses the short subprogram at address $F85F which is already called at addresses $F795, $F7AB and $F832. The cure is to call $F85F before each call to $DAA4 (write file descriptor to disk) :

Change bytes at $F7E7 & $F7E8 to 32 & F8 respectively.
Change bytes at $F803 & $F804 to 32 & F8 respectively.

The call to $DAA4 at $F835 is already preceded by JSR $F85F (and this enables the above simple fix).

At disk sector level, NIBBLE can be used to make the following changes (based on 17 sectors per track)
On track 03, sector 05, enter the 2 bytes 32 F8 to sector addresses E7 & E8.
On track 03, sector 06, enter the 2 bytes 32 F8 to sector addresses 03 & 04.

This bug took some time to track down because it looked like an intermittent fault when I first investigated it but I am glad that it is now sorted (usual comment about famous last words may apply here).

Please let me know if you implement this fix and experience any problems as a consequence.

[Steve M]

Thanks Ray.
Which version of Sedoridc does this apply to? (Maybe all of them?)

[Ray030471]

This applies to all versions which include the use of track $14, sector 3 for the extended disk bitmap.
I am using version 2 of SEDORIC at the moment.

[iss]

Thanks for update indeed!
I'm very curious what development tool(s) are you using?
Oh, and any news about BD-DOS?

[Symoon]

Long ago I think you worked with André Chéramy who made Sedoric 3.0, and wrote (in French) the great "Sedoric à Nu".
Do you happen to take a look at it to see if some of the bugs you find in Sedoric 2.x were corrected in 3.x?
I know a few things were fixed, but that's very old memories now and can't remember at once.

Anyway, good work!

[Ray030471]

I am using my own tools, created in VB.NET, to create, read and write SEDORIC disks of the "DSK" format.
I have also created a 6502 assembler/disassembler in C++ for development purposes (about as fast as Oricutron running at 64MHz).

I also have equivalent tools for the BD500 system.

I am still testing my applications for the real ORIC operating systems (SEDORIC & BD500) and this is an ongoing process which is progressing well.

Whilst developing my Basic compiler, I discovered another interesting feature in SEDORIC. This time it is associated with the COPY command (in bank 4). This command must be the last one in the line (Basic program or immediate mode) or else a syntax error will be reported. This is because SEDORIC checks for a null byte rather than other legitimate statement terminators. This can be fixed quite easily by changing the bytes at #C43F and #C456 to #08 and #28 respectively. I found this easy to implement using Nibble :- bytes 003F & 0056 on side 0, track 04, sector 0D of the master disk (assuming 17 sectors per track).

I will try to give a further update on my developments soon.

Meanwhile, I repeat my plea for a floppy disk interface circuit board (with or without components and for a reasonable charge) to assist me in my developments.

[Dbug]

Meanwhile, I repeat my plea for a floppy disk interface circuit board (with or without components and for a reasonable charge) to assist me in my developments.

You could try to get a Cumana Reborn, as far as I know it's a proper Cumana controller disk with a real FDC, just with a built-in Gotek, and it supports connecting a physical secondary drive.