+mizapf Posted March 4, 2021 Share Posted March 4, 2021 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 6 Quote Link to comment Share on other sites More sharing options...
+9640News Posted March 4, 2021 Share Posted March 4, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 4, 2021 Author Share Posted March 4, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+9640News Posted March 4, 2021 Share Posted March 4, 2021 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 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted March 5, 2021 Share Posted March 5, 2021 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 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 5, 2021 Author Share Posted March 5, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 15, 2021 Author Share Posted May 15, 2021 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-2021-05-15_12.59.33.mp4 genboot.dsk 5 1 Quote Link to comment Share on other sites More sharing options...
F.G. Kaal Posted May 26, 2021 Share Posted May 26, 2021 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted May 26, 2021 Author Share Posted May 26, 2021 Hi Fred, thanks for the information; in fact, I found it out already, as my new implementation of the boot loader demonstrates. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.