|
Post by gsteemso on Jan 2, 2024 16:56:36 GMT
No worries! I was a bit surprised at the time, but no harm done. I'm just glad you're still Commodore'ing with us all – cancer is no joke. :¬(
|
|
|
Post by gsteemso on Jan 1, 2024 22:14:41 GMT
Thanks for posting this stuff. I don't have a RAMlink myself, but I think it's important that big projects like yours be available when people need them, even if you yourself cannot be reached by then.
|
|
|
Post by gsteemso on Oct 31, 2023 11:57:12 GMT
Tokra, you are entirely correct regarding the hyperbolic colour counts. I was talking about what appear to be screen shots earlier in the thread. Two different claims arose during the discussion - (1) You can get some improbable number of artefact colours (not, of course, real colours) using VDC tricks, and (2), a black-and-white CGA signal flattened into a composite video feed can be made to look colorful by clever arrangement of pixels. It _sounds_ like that last one is not possible on a 128 because the colour subcarrier is not present, but it's unclear whether anyone's actually tried it; and as to the first claim, there were a lot of screen shots, but it's not at all clear whether any of them actually show a 128 at work or if they were merely illustrating the possibilities using examples from elsewhence.
|
|
|
Post by gsteemso on Oct 29, 2023 23:23:17 GMT
I'm slightly confused by the conclusions here. The previous post to this one states outright that he checked the hardware, and the 128's 80-column composite signal contains no colour subcarrier, so there is no decoding going on that can be tricked. However, earlier posts in the thread made it sound like they had actually achieved the result. Which is it? Were all those pretty pictures only taken in VICE, or using a PC with a real CGA card, or what?
|
|
|
Post by gsteemso on Mar 16, 2023 17:57:47 GMT
I was completely unaware of your site there – nice stuff! I appreciate you bringing that system to our attention. Astounding and very impressive to think it was made all the way back in 1992. Imagine what we could expand on in it knowing all that we know now!
|
|
|
Post by gsteemso on Mar 4, 2023 0:27:02 GMT
Sounds like CBM FileBrowser v1.6 with files to a 128 screen editor and other apps. Splash-screen not in CBM FileBrowser Well, you're not exactly _wrong_... I wasn't familiar with that specific program, but the whole idea is that it shouldn't much matter which file manager you use, as it is only there to manage your files; unless of course it can run one of said files as part of its feature set. Regardless, such a program would need modifying in order to (a) not stomp on anything the OS is using, and (b) take advantage of the OS's features. (I should clarify that by "splash screen", I meant the "Outermost Menu" screen you'd see upon loading the OS.) The "OS's features" part is pretty important, because why else would anyone bother?
|
|
|
Post by gsteemso on Mar 1, 2023 20:03:44 GMT
Hi all! It's been a little while, hasn't it? (Losing five years down the back of the sofa cushions could happen to anyone, I'm sure...)
Over that time, I've managed very few further moments to work on this (or indeed much of anything interesting), but I have had a few more thoughts:
• Ideally, I'd like it useable enough to catch the interest of potential users the moment they first tried to run it:
- Supporting a bare, totally stock, system is explicitly required -- both by the stated design parameters and by about half of my _own_ hardware not having any upgrades installed.
- Entry-grade storage drives can only use the horribly slow C= serial bus ("CSB"). Obviously a fastloader would help -- thank you, PiffyDOS! (I think that was the name? I'm thinking of the software-only JiffyDOS package somebody put together a few years ago.)
- Even with a fastloader, I think the best strategy is to simply keep the file size very, very small, at least insofar as is in fact possible. Once a minimally useable user shell has been set up, further code can continue to load; in other words, the lost time while the OS gets _its_ act together can be made less obvious by overlapping it with the time the user takes to get _their_ act together.
• That leads to an obvious question: Just what does need to be present to constitute a minimally but interestingly useable environment?
- It's normal, these days, for an OS to boot directly into its file manager. On a modern-style system, that makes a lot of sense; on an 8-bit Commodore, not necessarily so much. That's a lot of resources to load at a stage when you might not even need them.
- However one chooses to stack the facts, this OS is overtly special-purpose; while there's no reason it couldn't support any task you want it to, it's not going to include more than a handful of things "out of the box". This is especially true given the unlikelihood of more than a handful of people seriously using it, this many decades after the underlying hardware passed into obsolescence.
- With so few resources initially available, and so few things a bare install could do with them, a plain and simple menu interface is the obvious choice. There's no reason at all the user couldn't, later on, effortlessly customize it to suit their tastes.
(Note for those under the age of 45 or so: You've probably never encountered any computer-related thing called a "menu" that wasn't some variation of, specifically, a _pull-down_ menu. That's not the only kind, and it wasn't even invented until a very long time after menu-style user interfaces in general were. Fundamentally, a computer menu is, and looks, exactly like a restaurant menu: It lists the meals (activities) available to you, usually across multiple columns, and you pick one. Originally, you stated your choice by typing; nowadays you'd normally click it like a button.)
• Knowing what the user will encounter, they need to be able to do something with it once they have. I once ran a program on my SX-64, called "DOS 5.0", that we got off of a user-group disk back when those were a thing. It naturally took something like 10 minutes to load, given its size; once it had, it looked very good... but there was smeg-all you could actually DO with it once you had.
- The fundamental purpose of this system is to write stuff. You should be able to pop straight into the editor; and ideally, straight into the script-runner thingummy instead, once you've already written a few things.
- You should also be able to go straight to the file manager, or to some kind of integrated reference/tutorial/user-help system, or to the system settings.
• As I stated in earlier posts, a very long time ago now, ideally I'd want an editor as powerful and (relatively) easy to use as the superlative Mac program "BBEdit", or at least its former free version "Textwrangler". (Nowadays the free version is just the regular version when it hasn't been bought yet, so the more powerful features are simply not visible to the user.)
- TextWrangler's level of functionality is superlative in itself, and far better than anything else I've encountered even on modern Linux or Windows (and believe me, I have searched extensively!). To my limited knowledge, no Commodore or Amiga has ever had anything even within telescope distance of it.
- For obvious reasons, implementing anything that even leads towards software that good is a MAJOR project in its own right; in the near term, I could probably co-opt the 128's screen editor for large parts of a stand-in. That editor is actually surprisingly featureful, for a rush-job Commodore utility; it's just that no one can really tell, because it's so direly under-documented.
• I suspect the user-scripting system would be the most fun part to make, as far as I personally am concerned; that too could easily become a very complex bit of software, even if I managed to rein in the urge for creeping featurism. Once again, it _might_ prove fairly straightforward to co-opt some fraction of BASIC 7 -- which in many ways is already set up conveniently for so doing, given the stock system's careful design which has BASIC and the Kernal abstract everything out as a file, and treat all files pretty equally.
• The help/reference/tutorial subsystem should be relatively straightforward to integrate closely with all other software written for the OS; more than 50 years of UI research has led to a staggering amount of knowledge on the subject being freely available.
• The file manager is potentially a big, hairy point of contention, because absolutely _everybody_ has their own, quite irreconcileable, opinion on how one ought to look and act. The easiest solution I can see is to make that part as modular as possible, so that people can drop in their own preferred software (once suitably modified).
• The system settings wouldn't have much in them, at first; basically, the file manager, the editor, and the splash-screen menu, in descending order, would be the only parts needing much flexibility. As the system became more complete, options for storage-drive, Commodore-bus, WAN, and LAN management would also show up (probably at the front of the priority list, and in that order), but I can't think of all that many more. Leaving it flexible isn't hard and should cover all bases.
If anyone's still following this... opinions?
|
|
|
Post by gsteemso on Jul 26, 2022 1:37:00 GMT
The only thing I can think of is, when you tell BASIC to CLOSE {file-number}, it uses {file-number} for an internal table lookup to get the unit # (bus address), drive # (usually 0), etc.
Therefore, if it's suddenly whining about the device number (bus address) being wrong, there may be something corrupting the Kernal's "Logical File Number" table in RAM, where all this stuff is recorded.
That, or something is mucking around with whatever Kernal routine is called upon to sanity-check those bus addresses.
As one remote possibility: are you doing anything that might affect the MMU bank configuration? Remember that the "shortcut" configuration addresses at $ff0x (I think? it's been a while) are always present even when I/O space, and thus the actual MMU registers, are not.
|
|
|
Post by gsteemso on May 6, 2021 3:49:07 GMT
The version for the C64c is presently available at the same price. I must confess that I have thoroughly failed to grasp, well, SOMETHING about this. How does a RAM expansion for the 80-column chip in a C128 have any applicability to a C64c? I get the parallel use case involving the C16 / C116 / etc. Like the C128's VDC subsystem, that family of machines also has a 64K address space that's only populated by 16K. The C64c, not so much. Please un-bewilder-ate my poor brain!
|
|
|
Post by gsteemso on Feb 16, 2021 10:35:04 GMT
I vaguely recall that BASIC maintains some kind of index of extant variables. It's kinda-sorta compressed for simpler handling -- I believe the variable name is kept in a 2-byte structure, with the high bit of each byte repurposed: concatenating them gives a two-bit field with, obviously, 4 possible states; specifically, a1 (floating-point number), a1% (integer), a1$ (string), and FN a1 (user-defined math function). I'm pretty fuzzy on what it does to link that to the actual data (I expect it'd be a simple 2-byte pointer), and I don't remember how it keeps track of which variables are actually arrays, but I know for a fact it's laid out in all of those "MAPPING A C128" type of books.
|
|