|
|
Post by hydrophilic on Aug 17, 2015 9:38:13 GMT
gsteemso,
I think #1 is where we agree most... give the user to boot from any device, or "boot into monitor", or not boot anything at all... just press an appropritate key on power-up!
Updates to KERNAL and/or BASIC (#2 and #3) I think is for the user decide... what extra feautes does (s)he want?
In my opinion (and it seems from many other C128 owners), the most annoying boot-up aspect is the "default" boot from unit 8....
I think default should be "no boot"... *IF* you want to "auto-boot" then hold down 8, 9, or [1]0 on the keyboard during power-up.
|
|
|
|
Post by gsteemso on Aug 29, 2015 17:01:41 GMT
"By default, don't boot" overlooks an important point: it only works if your preferred OS is BASIC. Anything else, you want it to "just work" without having to muck around pressing keys, i.e., you want autoboot. Why exactly is it such a huge deal that the computer tries to access drive 8 ONCE on startup, anyway? Unless you have a boot disk in that drive, nothing happens!
|
|
|
|
Post by hydrophilic on Aug 30, 2015 7:10:41 GMT
If I am using a uIEC or 1581 as device 8, the automatic (yet failed) boot of device 8 is not a concern (these devices are smart enough to know when no disk is present). The major issue for me (and presumably others) is that when there is no disk in your 1541/1571, then start-up will be delayed for about 5 seconds while the drive makes multiple attempts to read from a disk that isn't present. I always thought (one of) the best things about Commodore computers is there "instant boot" technology... if I want to wait 5+ seconds, then I could use a PC or Mac or PS4. I guess if the user *always* had a disk in their drive, or did *not* care about an additional 5 second wait (and lots of head-banging in the case of 1541), then the "no boot option" would be unnecessary. But for me, I would prefer to press 8 to boot from disk 8. Just my opinion. Another issue could be for CMD-HD users... what if the user does *not* want to load the program referenced by the boot sector (like GEOS) ? So if you get enough feedback to justify no key-presses are needed during "normal" boot-up, I still *HIGHLY* suggest an option (like SHIFT?) to disable booting from unit 8 (or whatever is the default unit). Finally, gsteemso, I don't understand what this has to do with BASIC? I can "not boot" (no disk, no key) into BASIC 7, or (by holding C=) boot into BASIC 2, or (by holding STOP) boot into 128 MONITOR. (Obviously there is no way to *not* boot into CP/M  ). I can also imagine others, with a cartridge or function ROM, can *not boot* into some other environment (BASIC 8, GEOS) ? |
|
|
|
Post by gsteemso on Aug 31, 2015 4:07:06 GMT
Ah, that explains a lot. I usually have a 1581 set as device 8, so had forgotten that the 1541/'71 does that when accessed while there's nothing in it... which is usually the case when I turn on my Commodore because I don't trust the things not to corrupt the couple of bits under the write head due to a tiny power-on surge. Your question about "what does this have to do with BASIC" is rather mystifying to me. Suppose you change your ROM to eliminate autoboot. Then, when you turn on your system, you will always end up in BASIC. If you want it to always start up in CP/M or GEOS or something, you're out of luck. Having to hold down a key every time you turn on the computer would be almost as silly as having to wait for the BASIC prompt, then manually type "BOOT 8" or however that syntax goes, every time you turn it on. That's just not a reasonable option. Let's be clear, here -- the problem with a stock ROM is not that it autoboots. The problem is that it does a stupid job of autobooting. The current autoboot sequence looks a lot like this: - Blindly tell unit 8 drive 0 to load the autoboot file. We don't care if it takes ages to fail because we're cutting corners in order to ship the product on time.
- If we found the file, run it. Otherwise, clear the disk error and proceed to the BASIC prompt.
It wouldn't take a huge amount of effort to add things to it, like this: - If the "don't autoboot" key is being held down, abort and proceed to the BASIC prompt. Otherwise, continue to the next step.
- Blindly open the command channel on unit 8 and read the status message to find out what kind of drive it is.
- If we got an error, either there wasn't any unit 8 or whatever's there isn't recognizable as a drive. Abort and proceed to the BASIC prompt. Otherwise, continue to the next step.
- If unit 8 is a type of drive known to be unable to tell when it hasn't got a disk in it, including at a minimum the 1540, 1541, 1570, 1571, 1572, and any drive which is a blatant clone of any of these, then download a small program into the drive's RAM and remotely run it. (This small program will patch the drive ROM to (1) not retry the next read access to the disk, then (2) delete the patch after it has performed this interference.) Either way, continue to the next step.
- Blindly tell unit 8 drive 0 to load the autoboot file.
- If we found the file, run it. Otherwise, clear the disk error and proceed to the BASIC prompt.
Do you see what I'm getting at here? I'm not saying this is THE way to do it. It might even, as written here, be absurd. It's the concept I'm arguing for, rather than the specifics. |
|
|
|
Post by hydrophilic on Sept 3, 2015 16:41:42 GMT
I don't understand all the specifics, but yes the general concept that auto-boot needs some work, I think we agree.
Well, I like that you are thinking of me (and others) with your no-boot option in Step 1
I still think it would be nice to hold down a key during boot to select another unit (9, 10, 11, at least).... I'm guessing this would be part of Step 1 (check for key press)
I think your Step 4 option is pretty bold/ambitious. There are simple codes that can be uploaded to 1541/1551/1571 RAM which can reliably detect if a *standard* formatted disk is present... easiest method in my experience is to let the disk spin for 1 or 2 revolutions (which is much less than 1/2 second) and if no sync marks are detected, there is no disk (or it is not formatted).
Step 4 is easy in concept, but then you have ROM bloat/delay of determining what kind of device is connected, and then uploading appropriate code. Because the code(s) is(are) very similar, you could probably use some compression if ROM space was at a premium.
Another, more serious, issue for Step 4 is custom 1541 (rarely 1571) formats that don't use sync marks on some tracks... I think a well-known fast-loader "V-MAX" only has sync marks on track 18 (and track 1 if C128 bootable)... if the head is not on track 18 (or 1) when the test is run, it will report a "false negative" (think the disk is not present).
Of course you can force the head to track 18 (or track 1) before the test, but this will take additional time... especially with 1541 (no track 1 sensor).
So in summary, step 4 would be good for 1541/51/71 owners, but I think it would be a lot of work to make it bullet-proof.
Besides the "details" (as you say), the only real issue with Step 4 is the last sentence: Either way, continue to next step (Blindly attempt to load file).
Can you explain that? Why are bothering to do a test a the beginning of Step 4, when you ultimately don't care? I hope you wrote it wrong, or I read it wrong!
P.S., In retrospect, I see that "auto-boot" problem is only issue with BASIC 7 and CP/M... for BASIC 2 or custom (internal/cartridge) ROM, this is not an issue for us...
Also, there is no way to fix the "auto-boot" problem with CP/M, unless the CP/M disk is re-written... all official C128 versions REQUIRE boot from unit 8.
P.P.S., Pure wish/dream/fantasy... but it would be nice to boot from REU... the KERNAL allows to boot from cartridge ROM, but not from cartridge RAM (17xx REU). I realize this is a "pipe dream" because there is no standard way to store disk data in REU... just compare the way CP/M, RAM-DOS, and GEOS use the REU to emulate a disk, and you'll see what I mean!
|
|
|
|
Post by gsteemso on Sept 7, 2015 18:01:00 GMT
I agree that step 4 would need a lot of thinking and working out, and might consume too much ROM space to be practical, but again, I'm not concerned right now with the details, only the concept.
The reason I have step 4 always proceeding to step five ("blindly load the boot file") is that, the way I wrote the example logic, it's just like what it does now except the patch makes it fail right away if there's no disk. Failing right away was the problem that wasn't happening, this fixes it. Taking another approach such as what you mention about longer drive-resident code to actually determine with certainty whether a disk is present is probably unneeded effort, and what you mentioned about it failing to detect properly in the presence of certain types of copy protection is not really relevant -- given that the autoboot functionality wasn't really used all that often "back in the day", I'd be pretty surprised if any 128-mode boot disks with that particular problem even exist.
As for booting from the REU, that would be taken care of by one of the other ROM edits I proposed -- having a proper Kernal device number and better ROM support for the REU would allow it to show up in the "boot menu" I mentioned several posts ago, if such a thing were also implemented. The major annoyance would lie in the fact that the REU is always uninitialized after a cold boot. The only way such a function could be considered at all useful is if you set it up with the data you wanted it to have and then issued a "BOOT ON U6" command from BASIC. I suppose that _could_ be useful from within another program.
Having looked up the BOOT command in Hydrophilic's excellent BASIC encyclopedia, I see it could also stand considerable improvement. It only working with unit numbers between 8 and 11 is just ridiculous, as are (a) the more pervasive BASIC limitation of being unable to work with partition (drive) numbers higher than 1, and (b) the hard limit of 16 characters on the filename (useless if you wanted to pass a file path instead, or even if you only need to pass a filetype in conjunction with a 15- or 16-character name).
|
|
|
|
Post by hydrophilic on Sept 8, 2015 9:09:23 GMT
Yeah, I thought you meant "bail out" if no disk is detected in step 4, it just didn't seem to read that way; thanks for clarification!
I agree that accounting for custom disk formats would be hassle; but if you do develop a ROM that implements step 4, it would be nice to have that limitation documented.
REU boot is really only useful if you have a way to load the REU. On classic equipment, you need to run some other software to load the data, and that software can perform the boot. But if you have 1541 Ultimate, you can load the REU from a CF/SD card (and in VICE you can load the REU from a file in the host OS)... only in those cases would REU boot be most useful (but also useful to all after a soft-reset, like you say). So like I said, a bit of a pipe-dream (due to no standards and limited user base).
Yeah, all the BASIC DOS commands (like BOOT) suffer from limit of drive 0/1, unit 8~11, and 16-char filename. They all are unfriendly to CMD-HD unless you use partition 0 or 1, *and* you don't need a (different) path.
So have you decided on the features you'll implement? (I can't think of anything else at the moment.)
|
|
|
|
Post by gsteemso on Sept 12, 2015 6:26:51 GMT
Well, every time I investigate this in greater detail, I find more stuff that could really stand to have its Stupid removed. As you observe, BASIC is pervasively afflicted with boneheaded limitations on its drive-command handling, which collectively are a royal nuisance if you have (for example) a CMD hard drive, or any storage device with a unit number outside the range 8-11. There are many other places where BASIC 7 could work better -- with zero loss of compatibility! -- but doesn't. It seems almost every entry I look up in your BASIC Encyclopedia lists unnecessary limitations which could be reduced or eliminated with a little creative thinking.
|
|
|
|
Post by hydrophilic on Sept 18, 2015 4:34:50 GMT
Hey gsteemso, Glad you got useful info from my Encyclopedia... sorry if BASIC isn't as flexible as it could/should be... (don't blame me for that!) Because of the limitations of BASIC 7.0, I often used more primitive (BASIC 2.0) disk commands in my C128 Media Player... most (at least 1/2) of the code is in BASIC (the UI)... only the "hard core" audio/video player stuff is ASM. So maybe it is worth a look for "lame work-arounds"? If you are more into ASM programming, then also consider CBM File Browser (by Denial). |
|
|
|
Post by gsteemso on Oct 13, 2015 2:22:06 GMT
One of Hydro's other threads here reminded me of a big one that all projects of this nature should consider. Fixing the random number generator! The stock routine is just awful as far as producing evenly spread results, as you would expect if every output value were equally probable.
|
|
). I can also imagine others, with a cartridge or function ROM, can *not boot* into some other environment (BASIC 8, GEOS) ?