Custom GeneveOS boot loader

[+mizapf]

Here is a tool that I wrote during the last days, but which I wished to have for decades (at least since I have a SCSI controller). Don't ask me why I did not think about it earlier.

 

If you have a Geneve with Swan EPROM (0.98) and a modern card like SCSI, you had to use drive A: to boot the Geneve, even though your SCSI drive works perfectly after booting. The old EPROM could only detect different floppy controllers (TI, Myarc, and CorComp), the HFDC, and the Horizon card. So your way would be to burn the 1.00 EPROM.

 

If you don't feel like swapping your EPROM, this program will be the alternative. It is a boot loader that can also be adapted to other devices if desired. I added the source code on the disk image. You need GenASM/GenLink to build it; just call "MYMAKE". Copy the resulting SCSILOAD on A: as "SYSTEM/SYS". You also need a AUTOEXEC on A:, since it is still loaded from there. I also found that I have to add a "PDMA ON" to make the SCSI card work.

 

The idea is that the EPROM will attempt to load this very small SYSTEM/SYS and run it. Then, this program searches the DSR space for a SCSI card (by the name "SCS1") and the subprogram >24 (direct file input). Having found them, it loads a file "@SYSTEM" from the SCS1 drive into pages 0-15 and then starts the loaded program. This happens to be the real GeneveOS kernel file (originally named SYSTEM/SYS).

 

Here is a short video that shows the program in action: http://www.mizapf.eu/files/genboot.mp4

 

The flashing border is just a way for me to see whether all pages (each 8K) are loaded. As you can see, the load time is really cool. (The SCSI drive is a SCSI2SD.)

scsiload.dsk

[+9640News]

Thanks for the image and the source.

 

I've got a V0.99 image I have modified that looks for the TIPI but it requires at least a disk controller besides the TIPI in the PEBox to boot from the TIPI.  Haven't quite figured out why yet as to what is happening.  I have code that is modified to load from the SCSI and IDE in addition to the HFDC, however it has failed on the IDE load testing so far and not sure why.  Maybe there is something in your code for the SCSI that might be an ah-ha moment.

 

Beery

[+mizapf]

What I noticed is that in the IDE DSR, the >24 subprogram is not available but instead >84. I do not know whether it is fully compatible - Fred should be able to tell. It must deliver the file information but also the contents of the specified number of sectors at a given start location.

[+9640News]

18 minutes ago, mizapf said:

What I noticed is that in the IDE DSR, the >24 subprogram is not available but instead >84. I do not know whether it is fully compatible - Fred should be able to tell. It must deliver the file information but also the contents of the specified number of sectors at a given start location.

Interesting..... I'm going to send you a PM with some code.

 

Beery

[F.G. Kaal]

18 hours ago, mizapf said:

What I noticed is that in the IDE DSR, the >24 subprogram is not available but instead >84. I do not know whether it is fully compatible - Fred should be able to tell. It must deliver the file information but also the contents of the specified number of sectors at a given start location.

I choose the >8x code because when developing the IDE DSR many ears ago I also used superbugger and placed jumps directly into superbugger from my test DSRLNK. To prevent to first single step through the HFDC and SCSI DSR's to find out that the device name IDE1 is really not there I decided to use some other code instead of >2x. This speeded up the development of the IDE DSR.

 

(I also thought back then that if a card has CRU address >1100 the low level code should be >10 and if the CRU address is >1200 the low level code should be >20 etc. But this idea failes when the CRU address can be set with DIP switches. I just left the low level code >8x for the IDE DSR and >9x for the HDX DSR because debugging and development is so much easier this way IMHO)

 

Fred

[+mizapf]

Understood, but since the subprograms don't have names, it will become a bit difficult to find e.g. the sector I/O subprogram of a given card, don't you think? Any program that intends to make use of level-2 subprograms would have to include some knowledge what number the sector I/O has on which card.

 

In fact, I faced this question just when I wrote the custom OS loader: If I don't assume a CRU address for the SCSI controller, how do I find its >24 program? My solution is a special DSRLNK that first searches for the name "SCS1" and then, in that very card, looks up the subprogram.

 

So may I assume that >84 does the same as >24? I'm using it to load the plain sectors.

[+mizapf]

OK guys, here is my ultimate Geneve Boot Loader. As described above, it allows you to boot from your SCSI drive - and now also from your IDE drive - if your boot EPROM does not check for these drives. Note that we have updated boot EPROMs by now, but in the case you want to keep it as is, the loader will be helpful.

 

It will try to find a card with a SCS1 device, and if not found, a card with the IDE1 device. If either one has been found, it attempts to load "SYSTEM-SYS" from that drive. As you can see in the video, I added a progress bar.

 

The boot loader is included by source code and binary; there are instructions for rebuilding it in the file. After that, you have to rename it to "SYSTEM/SYS" and place it on a floppy disk in DSK1.

 

genboot.dsk

[F.G. Kaal]

On 3/4/2021 at 7:43 PM, mizapf said:

What I noticed is that in the IDE DSR, the >24 subprogram is not available but instead >84. I do not know whether it is fully compatible - Fred should be able to tell. It must deliver the file information but also the contents of the specified number of sectors at a given start location.

The >84 subprogram is fully compatible with the >24 subprogram.

 

In the time when I was busy developing the IDE DSR (2003-2005) on the real (Geneve) thing it was  difficult to debug the DSR code when also using the >2X subprograms for the IDE DSR, because first my HFDC card was found by DSRLNK and next my SCSI card was found and finally my IDE card was found. That was the moment I changed the >2X subprograms to >8X subprograms to speed things up (if I remember correctly that was because the CRU address of my IDE address was >1800 that time). When the first version of the IDE DSR was finished I left it this way.

 

 

I saw I allready answered this a few months ago

Edited May 26, 2021 by F.G. Kaal

[+mizapf]

Hi Fred, thanks for the information; in fact, I found it out already, as my new implementation of the boot loader demonstrates.

[Brufnus]

On 5/26/2021 at 7:02 PM, mizapf said:

Hi Fred, thanks for the information; in fact, I found it out already, as my new implementation of the boot loader demonstrates.

Perhaps I'm doing something wrong, but I cannot make it work - it just beeps three times after loading from floppy, and then it stops. Correct me if I wrongly believe it should work even if there's a HFDC present as well?

Edited September 25 by Brufnus

[+mizapf]

From the source code:

* SCSI/IDE card not found
* -.
* SYSTEM-SYS file not found
* -..
* SYSTEM-SYS file has invalid type
* -..-
* SYSTEM-SYS file has invalid length
* -.-.
* Load error
* ---

 

Three long tones mean "load error", and this is caused by a non-zero value in 8350 (return from the sector load routine in the DSR).