Floppy boot sequence ?

[applepie]

Hi, I'm coding my own floppy builder in Ruby, thanks to FloppyBuilder code, old2fmt code and "Sedoric à nu" book.

I was totally at loss, but after 3 days of battle I start (a little better) to understand what's going on, how is the disk structure organized.
Now, for the first time, Oricutron is able to boot my disk img, and I know my junk asm code is executing.

But I'm far from finish and there are still many things I don't understand and are fuzzy :

1) I worked (for now) for the microdisc controller. Why is the third sector needed (the one containing a signature including "SYSTEMDOS" and "BOOTUPCOM") ? That seems related with Sedoric, is there a relationship between the microdisc controller and Sedoric ? That's strange, for me the twos should be totally unrelated

2) Why is the boot sector's code in sector 2 (microdisc) or 3 (jasmin) ? I remember me coding stuff for the Apple II where the boot sector was always the first one (0 on apple II), which make sense.

3) When my junk code executed for the first time I was very surprised to see the classic "ORIC EXTENDED BASIC, TANGERINE" etc etc - I though that the microdisc ROM would shadow the Oric's ROM and show a different display, or better : nothing. Obviously there are things that I don't get at all.

4) On microdisc, can someone confirm that the sector 2 content is aligned at address 0 ?

[iss]

3) and 1) Why is the third sector needed (the one containing a signature including "SYSTEMDOS" and "BOOTUPCOM") ? That seems related with Sedoric, is there a relationship between the microdisc controller and Sedoric ? That's strange...

It's not strange it's by design. Microdisc ROM code searches for this files to boot. Take look with hex viewer at 'oricutron/roms/microdis.rom' file and you'll find a clue:

2) Why is the boot sector's code in sector 2 (microdisc) or 3 (jasmin) ? I remember me coding stuff for the Apple II where the boot sector was always the first one (0 on apple II), which make sense.

Same as above... it's author's decision. And to be more confusing: yes, Apple's sectors are counted from '0' vs. Oric's from '1'. Else, thanks to difference between Microdisc and Jasmin or more correctly between Sedoric and FT-DOS we can have 'multi system' bootable disk image. For details use Dbug's FloppyBuilder documentation and sources where you can find useful tips in comments.

4) On microdisc, can someone confirm that the sector 2 content is aligned at address 0 ?

I'm not sure what's the question but this seams to be related (again from sources):

Code: Select all

    ; These are the 23 header bytes that goes
    ; before the actual executable part of the bootsector
    .byt $00,$00,$FF,$00,$D0,$9F,$D0,$9F,$02,$B9,$01,$00
    .byt $FF,$00,$00,$B9,$E4,$B9,$00,$00,$E6,$12,$00

i.e. this 23 must be included before actual code.

Here is something I've posted 2 years ago: BOOTER which boots from any drive,
now it's updated but I'm still not found suitable project to use it, maybe next [raxiss] release will be disk-based ...

[applepie]

About the relationship between de floppy controller and the OS, that make sense now

Regarding my last question : Yes I already have the 23 "signature" bytes, then my code at $17.
I just wanted to be sure that the sector 2 load address is $0, but I can check that with a breakpoint with Oricutron I presume, or dig a little more in "Sedoric à nu" (but this book is very very packed with a lot of informations, and I often miss the right lines)

[Chema]

Fabrice Frances once told me about the mystery of the EPROM looking for those files. He said

The Microdisc and Cumana don't really boot either, the eprom contains an incomplete version of OricDOS 0.6. So they already know both the filesystem structure of OricDos and the record-based files of OricDos, and thus they know how to access the OricDos directory and search for two system files of a more recent version of OricDOS. Which means that all the other operating systems running on Microdisc (like RANDOS or Sedoric) need to fake this OricDos filesystem and have to include the operating system in the special format of these two OricDos system files

That is what goes in sector 3. This fake OricDOS filesystem. It would be nice to have more technical information about all this.

[applepie]

Yeap, that's what puzzled me... Remembering the Apple II boot sequence, the controller didn't care about the kind of operating system (or not) was on disk. No matter if it was DOS3.3, Prodos, UCSD or whatever : first and optionnaly second sectors where loaded at $800 and then jump at $801. Straight to the point, Wozniak way of doing things

[Jonh]

André C dealt with this topic in detail in his Sedoric a Nu book, downloadable here:

https://library.defence-force.org/index ... =Sedoric+3

Go to Annexe 6, p.482 and the following pages...

[applepie]

I'm on a loop with this section, this book is HUGE !

[ibisum]

That book is a reason to learn French. Wish someone would translate it ..

[applepie]

OMG !!!



Back in the day : More OSes than floppy drive owners

[xahmol]

That book is a reason to learn French. Wish someone would translate it ..

That would help indeed, but luckily assembly is assembly, so the book was already tremendously helpful for me to do the disparser part of my Oric Screen Editor.

Tried also a floppybuilder approach at the time, but that proved to be beyond my skill and available time at that moment.
But it would be great if somewhere here would make a great floppy builder library that not only is able to read data from within a program, but also to save data from the program to the disk. On the latter I became hopelessly lost when I tried it, reason why I reverted back to doing it via SEDORIC (and hacking the SEDORIC code in RAM to make the dir parse in the format I wanted it to have on screen).

For most applications you do not need a full DOS, so a floppybuilder with some assembly routines to read data from the disk and store data to the disk would be more than sufficient and might make room to use the upper 16 KB memory otherwise occupied by SEDORIC or not usable without a disk controller, useful for other stuff.

[Chema]

But it would be great if somewhere here would make a great floppy builder library that not only is able to read data from within a program, but also to save data from the program to the disk.

I made some modifications for Blake's 7 so the game could save the progress. You can check in the game sources. I am not sure it is general or useful enough to merge it to the main floppy builder utility, though.

[applepie]

So, I made some progress :

- I've now a tool that generate valid disk MFM images. I compared with google earth troll img and when using the same settings (1 side, 42 tracks, 17 sectors per track) I can see that everything is "aligned". I mean, the sync bytes, crc, all markers are at the same place. So far so good, excepted if that was caused by a very good luck

- Now, I have my junk asm code running on boot. I can read a track/sector too

But I have some questions :

1) What is the "state" of the Oric when my boot asm code is jumped in ? For what I see, the Oric ROM is disabled, the Microdisc ROM is disabled. With Oricutron I can write anywhere in the whole 64k RAM which seems good for me (I don't need the DOS, I don't need the ROM (excepted for some routines that I'll have to borrow from ROM assembly code, but maybe I'm optimistic about that)). I just found few traces of SEDORIC at $C000 (seems to be the sector 3 content)

2) My boot sector code is loaded by the Microdisc firmware at $B902. Why Not ? But why ? Why this address ? I saw something strange in the data that comes before the boot sector's code (the famous 23 bytes). I can see $02,$B9 at bytes 8 & 9. That can't be by fate/chance. I tried modifying those bytes with differents address but the code is still loaded at $B902. So I wonder if this address is really hard coded for the Microdisc, and will ever be the same.

3) Now the strategy (easier said than done)
- bootsector code is loaded at $B902
- code self relocate somewhere at $FE00
- read my custom Table of Content (track 0, sector 4)
- get the number of sectors per tracks, track and sector of program code, program size (uint16). This TOC is already generated by my tool
- load the program (CC65 generated)
- jump to entry point
- the CC65 code will then manage reading again the TOC, and will have the ability to load data from disc with small assembly routines
- some tracks at the end of the disc will be reserved as game savestate slots (1 savegame in my case), but this point is still fuzzy

And with this scenario, I would need to tell ld65 that a big part of the upper RAM is available, then with some #pragma bss-name use this space for data storage and/or some code. Don't know how, ld65 config files are not my friends.

4) As stated in 2) I pretend being able to make my day without the Oric ROM routines. What do I need ? 2 things : 1 timer, and reading the keyboard. That's all. How much work is needed for that ? Can I borrow some code from the ROM disassembly and hack it to some extent without entering the rabit hole of problems, being said that I don't have a clear understanding of the Oric low level stuff ?

Franckly all of this is quite tough but interesting and fun ! As long as it does not require knowledge that would take too long to acquire...

[Dbug]

2) My boot sector code is loaded by the Microdisc firmware at $B902. Why Not ? But why ? Why this address ? I saw something strange in the data that comes before the boot sector's code (the famous 23 bytes). I can see $02,$B9 at bytes 8 & 9. That can't be by fate/chance. I tried modifying those bytes with differents address but the code is still loaded at $B902. So I wonder if this address is really hard coded for the Microdisc, and will ever be the same.

The Atmos Microdisc and the Telestrat don't load at the same address, that's why the floppy builder boot sectors are relocating themselves to a known address.

3) Now the strategy (easier said than done)
- bootsector code is loaded at $B902
- code self relocate somewhere at $FE00

"Boot sector code is loaded 'somewhere'", then relocate to a known location.

[xahmol]

I made some modifications for Blake's 7 so the game could save the progress. You can check in the game sources. I am not sure it is general or useful enough to merge it to the main floppy builder utility, though.

Now that you say it, think that was the code I tried back then and became completely stuck with but that is probably my lack of patience and experience instead of your code.

[Dbug]

I've been trying to get the bootsectors and loader as a native part of the OSDK, and to have simple FloppyBuilder examples using that instead of all having all these files in the project that uses them.

I'm having some issues, but it's about half-way.

So the idea right now is:

• Have the loader api as a native part of the library/include set, but to not conflict with the existing projects, it has been renamed to "disk.h" and the functions are DiskSomething instead of LoaderApiSomething
• Have the three boots sectors and the loader assembly code in a new "utilities" folder at the root of the OSDK.

I guess it would make sense to add the Saving code from Chema to the OSDK loader code, possibly with some #ifdef way to define at compile time if we want to support saving, so the loader can be smaller, and then provide a new sample program that shows how to use "save slots".