|
Post by gsteemso on Sept 17, 2015 18:25:16 GMT
In response to… I’m not even going to try to spell that on an iPad! …“the previous poster:” Based on the screenshot you linked us to, your homebrew converter gives absolutely beautiful results, with one exception—light black is indistinguishable from dark black. Do you have any plans to improve on that?
|
|
|
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 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 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 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 gsteemso on Aug 12, 2015 4:17:37 GMT
I haven’t followed up on this thread the way I meant to. My apologies.
I definitely would include BASIC 7.80. Including that one is as much of a no-brainer as including JiffyDOS, I think.
Another idea I had is to actually test the VDC RAM size at boot and configure things appropriately. That would allow one ROM image to support both 16K and 64K VDC setups, so installing a 64K-VDC board such as the Chip Level Designs one or the currently produced clone of it would be more useful.
VDC8x2, I like the idea of ditching the tape nonsense, though I would feel differently if there were no option to switch back to a stock ROM (I think JiffyDOS had the right idea there). I also like the idea of improved RS232 speeds and reliability, and in fact a friend of mine who goes by the handle AgentFriday has come up with a way for a stock C64 to do 38-kilobit-per-second serial communications, in bursts while the VIC-II is not active. I’ve seen it in action and it is awesome. I believe he wrote a blog article about it some time ago, probably on commodoreserver.com if that helps anyone track it down.
Hydrophilic, wow, that’s quite a number of ideas! I think we can break them down into three categories: (1) selecting any or no boot device at boot time, (2) adding useful features and functions to the Kernal, and (3) adding useful features and functions to BASIC.
One at a time, then. (1) I think I’d make it so it does what it does now, unless you held down Shift (skip autoboot altogether) or Alt (bring up a boot menu listing the available devices, like what you get on a Mac if you hold Option during boot). At first I thought the idea to select the screen as a boot device was kind of nifty, but then I realized you’d need a full-blown machine language monitor with the ability to save your work before it would be any practical use. At that point it’d be just as simple to implement the idea I mentioned several posts ago for an improved MLM and have an option in the boot menu to enter it directly, presumably after you selected one of the boot-device options so you’d have something to work with.
(2) and (3) are good in theory and I can even see the exact requirements I’d want for the specific features you suggest, but it breaks compatibility in a fairly severe way (at least, the BASIC extensions would). I suppose we could piggyback on the JiffyDOS wedge and prefix all additional commands with one of the less-used funny characters, or maybe use a digraph (!!COMMAND or the like). The idea to allocate a device number to the REU seems like something Commodore should have done in the first place, and we even have the cassette device number we’ve just rendered unusable… of course, that also would introduce severe compatibility bugs. Maybe we could use device number 6 (it seems unlikely in these paperless times that anyone would have more than two printers hooked up at once, and unit address 7 is already in use by the network controller on the Flyer cloud storage device), or perhaps 30 instead (being all the way at the far end of the available range, there shouldn’t be many things already using it)?
Does anyone else have any widely applicable Kernal or BASIC extensions they’d want to see in their dream ROMset?
Buzbard, are there any differences between the 128 and 128D JiffyDOS ROMs that are actually needed for them to work in a given machine? If not, it’d likely be simplest to just base this project on the 128D JiffyDOS ROM and ignore the flat-128 one entirely.
|
|
|
Post by gsteemso on Jul 23, 2015 0:37:26 GMT
Either that or he meant dietary fibre. (Think "My boss is giving me all the [dung] assignments!")
|
|
|
Post by gsteemso on Jul 9, 2015 23:20:25 GMT
Abnormally warm in western WA state. Exceeded our usual quota of 90 F days for the whole year back in the middle of June, IIRC. Most of them were consecutive too. Has been 5–10 F hotter than usual all summer.
|
|
|
Post by gsteemso on Jun 28, 2015 3:19:43 GMT
I finally admitted I was completely out of my depth, and wrote to one of the Contiki developers who has done a lot of work on the Commodore-specific ports as well as the rest of the OS.
Alas, he says that all the software for Contiki is so heavily integrated across all levels of the IP protocol stack that the only practical way forward would involve getting low-level access to the Flyer’s WizNet W5100 module (I think that was the name of it, anyway), and micromanaging it like it was a more traditional, “dumb” Ethernet controller. I’m fairly certain that level of fiddliness is intentionally not exposed by the Flyer’s DOS-like command syntax.
So, either we redo the whole Contiki OS and all its included software, or we get Brandon to add an entire additional syntax for commanding the Flyer at a very low level, or it’s not happening, basically.
|
|
|
Post by gsteemso on Jun 27, 2015 2:06:50 GMT
Interesting that that works before any access is attempted! I’d have expected it to need a starting guess for the serial bus address at least. Or does it only work for the default drive that is accessed if you press the RUN key, or perhaps if you OPEN a file to the device first?
Either way, it won’t catch multiple drives. For that you need to loop on such a “read the error channel” operation, once per bus ID, which will error on anything that is absent or, we desperately hope, not actually a storage device — and give you the DOS version message, error 73, for anything that IS a drive. This technique works on the C64’s DOS 2.0 as well if you do the error channel access by hand.
|
|