Jump to content
IGNORED

Proposal for a new Geneve boot process


mizapf

Recommended Posts

This is a first concept for a new Geneve boot process, which is implemented in the boot EPROM.

 

Over the years, and in particular after some debugging and disassembling, I found that the existing solutions (0.98 and 1.00) offer some potential for improvement (politely saying).

 

Both boot EPROMs offer to boot from one of several fixed sources. Also, they include code for a low-level access to the storage media. Such code should be part of a driver, and the driver should not be hardcoded into the EPROM, because there is always the chance of having bugs in it, or you encounter a new device that will not be supported this way.

 

Also, booting is performed the same way, once your hardware setup has evolved to a stable state. If you need to press a certain key every time for loading from your favorite device, this is somewhat annoying. Unfortunately, the Geneve does not offer a non-volatile storage (EEPROM) to store user preferences.

 

For that reason, I considered to write a new boot process with the following properties:

  • The EPROM shall not contain any low-level device access code. It contains a fixed list of popular boot devices, though.
  • The boot process is composed of two stages.
  • The first stage consists of loading a boot loader from one device of the built-in list, using the DSR from the device. After successfully loading the first stage, control is passed to the loaded code, and the boot EPROM is no longer needed from there on.
  • The second stage consists of loading a controller-dependent part that loads low-level routines into the system, still using the card DSR (but may also use own code).
  • The controller-independent (CI) loader must be placed on one device of the built-in list. However, it has full control from where to load the controller-dependent (CD) part. That way, a known device may bootstrap any future, still unknown device.
  • Since the EPROM passes control to the first stage, the first and second stage may be combined to a single stage, containing all required low-level routines.
  • In case of a broken boot process, there is an override to force loading from DSK1.

This leaves a lot of space in the EPROM, and I envisage to get a more informative boot screen with memory test output, device detection, and a progress bar for loading. All of these are comparatively simple tasks. Also, the Swan should be shown on the screen, as it is the well-known brand icon of our computer.

 

The typical situations that I have in mind:

  • Floppy only. The disk in DSK1 contains two files: @BOOT1 and @SYSTEM. The boot loader must be selected according to the floppy controller. The first and second stage are contained in @BOOT1.
  • MFM drive. The drive (WDS1) contains the above files. As long as no space bar is pressed, loading will start from WDS1, which is part of the built-in list.
  • SCSI drive. See MFM drive.
  • Floppy and EXOTIC device. The second drive is not part of the built-in list. The Floppy drive contains the file @BOOT1 only. The file is tailored to point to the EXOTIC drive, from where @BOOT2 and @SYSTEM are loaded. This way, the floppy will only be used for the first stage, and most of the code will come from the second drive.
  • SCSI and EXOTIC device. Similar to above; @BOOT1 and @BOOT2 may be combined and put on the SCSI drive, since the SCSI drive is fast. @BOOT2 is tailored to attempt loading @SYSTEM from the EXOTIC drive.
  • Since the floppy drive may always be forced to load @BOOT1, you can do anything you deem reasonable from here on, probably booting a rescue system that you put on DSK1.

I cannot promise this will become real in any shorter period of time, but maybe someone here feels like starting with it, or has another idea.

post-35000-0-63987900-1554653564_thumb.png

post-35000-0-56323900-1554653575_thumb.png

post-35000-0-40831400-1554653584_thumb.png

  • Like 10
Link to comment
Share on other sites

On my way out the door but wanted to mention two potential caveats:

 

1. The Horizon ramdisk has no DSR installed, so retaining some low-level code is necessary. Unless, of course, you implement a minimal DSR and update the ramdisk formatting method/routines.

 

2. As M@ pointed out during TIPI testing, he could not use the TI FDC in ROMPAGE configuration. I confirmed this is the case with both a TI FDC and CorComp FDC. the Myarc FDC will typically only work at the equivalent of GPL SPEED 2. So, it would be important to test whether or not the on-board FDC DSRs will function properly for these initial DSR-based loads. The timing/DSR challenges could explain why Myarc placed low-level code in the Geneve EPROM to begin with. I no longer have either of these card varieties in my possession.

 

There are flash-based options like the 32K atmel chip and small serial IO chips that could be added to the Geneve to store some of the configuration information and/or a bootstrap process. Anyone looking at building an updated boot eprom might want to consider that in the plan.

Link to comment
Share on other sites

Concerning the missing DSR for the Horizon, the above approach would expect the Horizon is not the only drive in the system, and in { WDS1, SCS1, DSK1 } there is one drive that contains a @BOOT1 file. This file would contain enough code to access the Horizon (or to install a temporary DSR).

 

It is indeed important that there is one card in the system that allows to be accessed by its own DSR (Rompage). Concerning the speed, this could be tested before, and set as default.

 

Of course, we could treat the mentioned controllers as special cases and include some low-level code after all. Not pretty, but maybe required. This would not break the concept as shown above.

 

Edit: Just tried to use the TI FDC in MAME with the Geneve (using a DSSD disk), but after booting, I cannot get any access to work. I tried with 6.50 and 1.14, but with the same result. Maybe I should trace the problem (assuming that it should be possible to do a DIR on A: after booting with the TIFDC), because by using MAME we could more easily find out the problem with the card DSR ... unless it is a pure physics thing.

Edited by mizapf
Link to comment
Share on other sites

Concerning the missing DSR for the Horizon, the above approach would expect the Horizon is not the only drive in the system, and in { WDS1, SCS1, DSK1 } there is one drive that contains a @BOOT1 file. This file would contain enough code to access the Horizon (or to install a temporary DSR).

 

It is indeed important that there is one card in the system that allows to be accessed by its own DSR (Rompage). Concerning the speed, this could be tested before, and set as default.

 

Of course, we could treat the mentioned controllers as special cases and include some low-level code after all. Not pretty, but maybe required. This would not break the concept as shown above.

When I tested the TI and CC cards, I tried different memory/workspace speed variations and even matched the boot EPROM's CRU bit settings. My own potential mistakes aside, I had little luck with those two cards and their on-board DSRs and at that time I didn't feel it was worth pursuing further.

 

Without RSbug stealing bytes there should be room to do what you outlined even if the floppy/ramdisk low-level code is kept intact.

 

I like the flow chart :)

  • Like 1
Link to comment
Share on other sites

I think we've heard this story before, and it dies on the vine because there is too much weight given to the things that can be booted just fine from the existing ROM... The number of users is super low... so getting this all tied up in anything I or they want separate from what you want should be secondary at most.

 

Applying willful ignorance:

 

If I was involved, I would use a custom DSRLNK to find @BOOT from unit 0 through ?, using direct-read (>x4) basic-subroutines. I would leave the complexities of a @BOOT1 and @BOOT2 to someone who needs to write a @BOOT2 for their special situation. Just look for @BOOT in the ROM... it is @BOOT's job to decide what it wants to look for.

 

Load the first one that can load, and run it... let it be responsible for anything else you want... You want cascade loading from one device to another, use a version of @BOOT that does that. a version of @BOOT could even load SYSTEM/SYS. It just needs to be possible to write a version of @BOOT that replaces itself in memory.

 

That's all I would implement in the ROM.

 

If the hardware someone wants to boot off of doesn't work in those constraints, but does work with the existing .98 or 1.00 ROM... then they can stick with the .98 or 1.00 ROM.

 

I'd just be happy to have a ROM that didn't hard-code the basic-subroutine sector-io address... I implemented >10 sector IO in the TIPI ROM, as an experiment, but the existing ROM doesn't even use the DSR header lists to find it... But I'd rather it didn't use >10, and used >14 instead. That way you don't even have to find the file on the disk... if it is there, the controller will do the work. You don't need a PAB, but some controllers still need all the mutations that happen in DSRLNK to the scratchpad space, and buffering in VDP.

 

My TIPI sector io routine is not in any ever to be released DSR... just an experiment. There is no code on the PI side to go with it... I was just hoping to see the Geneve ROM lockup on the TIPI pretending to be DSK1., but it didn't even...

 

-M@

  • Like 2
Link to comment
Share on other sites

Edit: Just tried to use the TI FDC in MAME with the Geneve (using a DSSD disk), but after booting, I cannot get any access to work. I tried with 6.50 and 1.14, but with the same result. Maybe I should trace the problem (assuming that it should be possible to do a DIR on A: after booting with the TIFDC), because by using MAME we could more easily find out the problem with the card DSR ... unless it is a pure physics thing.

 

I found a bug in my TI FDC implementation. The problem is that I did not pass the SIDSEL signal when no drive is selected. The point is that in the emulation, you have to invoke a method ss_w on the floppy object, but only if there is such an object, which means that there must be one drive selected. However, MDOS first deselects all drives, then clears the SIDSEL line, so this signal is lost, hence, when it tries to read sector 0, it reads sector 709 (track 0 on the second side, sector 0 in that track). This is wrong in the implementation, because the SIDSEL signal is latched. Going to fix that.

 

The FD1771 is completely agnostic about sides; other controllers check the field "head" in the sector header, but the 1771 does not.

  • Like 1
Link to comment
Share on other sites

OK, I managed to fix that issue, so the Geneve was able to boot from the TI FDC and to load GPL. But I could not find any issue with ROMPAGE in the MAME emulation of the Geneve; I was able to load a Basic program (a cataloger) and to run it.

You can see in the second picture that the addresses are from the FDC card ROM, while in the first, only the FDC ports are visible (DSR not used).

 

This means there is at least no logical problem with the DSR in ROMPAGE. I can only imagine it is a physical thing. Timing?

post-35000-0-96750000-1554765828_thumb.png

post-35000-0-75233100-1554765841_thumb.png

  • Like 1
Link to comment
Share on other sites

My guess is the wait state (ready) logic or relevant DSR code. The non-Myarc FDC's implement wait state logic on the data ports when reading/writing bytes to/from a floppy disk. SBO 2 enables, SBZ disables. The 9995 prefetch of the MOVB @>5FF6,Rx after SBO 2 may execute too fast for wait state circuit to activate in time on real hardware.

 

With the Myarc DDCC, the DSR polls the 1770 for byte ready before accessing >5FF7. IIRC, the 1770 ports are mapped to odd bytes. This odd-byte mapping has the advantage that it gets on the 99/4A 8-bit bus first.

 

The Geneve is fast enough to use the polling technique for all FDC's.

Link to comment
Share on other sites

Yes, but I emulate all that stuff in MAME, from left-right byte order over the complete wait state logic to the 9995 prefetch. I have some faith that MAME is very closely doing what the real iron also does, so I'd be interested why the real device fails to work - so I can make the MAME emulation fail at the same point. :)

 

Maybe we have to look inside the source code of the MDOS master DSR (or the boot EPROM) and compare this with the TI FDC DSR.

  • Like 1
Link to comment
Share on other sites

I would leave the complexities of a @BOOT1 and @BOOT2 to someone who needs to write a @BOOT2 for their special situation. Just look for @BOOT in the ROM... it is @BOOT's job to decide what it wants to look for.

 

In fact, I started with the idea of @BOOT1 and @BOOT2, and later I noticed the same thing as you - why bother? If we know that @BOOT1 is loaded, it can do anything from there on, including loading @BOOT2 or telling jokes. This is the reason why I drew the left bypass in the second flow chart ("single stage bootloader").

 

The file names starting with @... is a suggestion to get rid of the slash in the file names, as they cause more trouble than necessary ("SYSTEM/SYS", "LOAD/SYS") when it comes to line parsing.

  • Like 3
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...