Thanks for showing that "a simple monochromatic GUI" is not only doable on the '02 but has already been done. A lack of a 512MB expansion pack might make it not so useful on a C64 though.

Me? When it comes to nostalgia I like the FORTH or C64 BASIC OS.

I did know someone who ran GEOS on the C-128 with a pair of Commodore SFD-1001 floppy drives, which were connected to the C-128 through IEEE-488 (aka GPIB). The SFD-1001 was a one megabyte drive with a Panasonic mechanism that was reliable and very fast for the time. The IEEE-488 interface was the bottleneck, as Commodore chose to implement it on their drives at a sedate 1.2KB per second, a fraction of the 1MB/second rate the IEEE-488-1978 standard allowed. Even so, GEOS ran at a respectable rate.

Running GEOS with the REU was an altogether different experience, as the theoretical data transfer rate between the REU and the C-128 was 1MB/sec. In practical terms, the GEOS overlays loaded almost instantaneously from the user's perspective.

Back when I was developing software for the C-128 I had a Lt. Kernal (LK) hard drive subsystem attached to my development machines (two of them, using a multiplexer). At the time, Xetec was shipping 40MB LKs with a Seagate ST-251 mechanism, which had a 28 millisecond maximum seek time, and something like a 3-4 millisecond track-to-track seek time. It was the fastest ST-412/506 hard drive in production in those days (c. 1988). A disk block could be read into RAM in as little as 10ms, depending on how much of a seek was required to get the heads positioned to the correct cylinder. That would have been fast enough to run GEOS with little to no perceptible lag.

The eight bit hardware of those days was more capable than many Intel snobs would have thought.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Just stumbled on this quote which I'd seen before but couldn't find:

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

An object is basically just a data structure that includes functions or pointers to functions (known as "methods" in OOP parlance). Its chief advantage is that you can add customizations to an object without altering the original object and you can restrict access to parts of an object thus limiting the scope for buggy programming. This makes it ideal for large projects.

This is OOP in a nutshell although there are a bewildering array of other features that most OOP languages offer. Your last comment is not necessarily true; it depends on the language.

Yes. Terminology is a big part of the problem. Methods, classes, and what's the oop name for an init function again.. it can look pretty foreign. Rip all that away however, and what you have are familiar concepts: data structures that come with functions to manipulate them, restricted scope, etc. None of that is unfamiliar to a structured programmer. Then tack on a mechanism to extend without rewriting and some other helpers (all of which can be figured out and has been done in non-OOP languages as C too).
Big bloated programs are generally a result of normal mediocry, culture (as has been mentioned), and other external factors.

100MB applications of today load and run faster than 10kB applications on my first computer. In most cases, bloat is not a problem.

The first computer I used was a Sinclair ZX-81 (aka Timex Sinclair 1000 in the US), with 1kB RAM.

Loading a program from tape took less than a minute! Who could possibly need more speed!?

Did someone say GEOS? I wrote papers in high school using GeoWrite with a regular 1541 disk drive. It was pretty slick, and the only major slowdown happened when going to another page.

Quality software seems to come more from experience and giving a s*** than the choice of computer language itself.

My high school word-processor was AppleWriter, on my ][+. I had to make the "shift key jumper" modification to my keyboard to avoid going insane, and I had the original 40-column upper-case only display hardware, so upper-case letters were displayed as inverse upper-case, and lower-case letters were displayed as normal upper-case. It was incredibly fast, and even had a primitive built-in "scripting" language to automate custom tasks. My hard copies came from an Epson MX-80. Fond memories ...

Mike B.

LOL 10 years ago, I could download an entire C64 disk image (170K) over a 56k diallup faster than the C64 could load a single program from the disk.

Yep.

in OOP is functionally the same as

in C. Depending on the compiler, the latter may run faster since there is no indirection in the function/method call.

You can even extend a C style "object" without recompiling the original code:

Note that it is easier to make mistakes in the C code and there is nothing to stop an uncooperative programmer from modifying the members of a struct directly instead of using the functions provided thereby bypassing the function's error checking.

This pattern is used extensively in the Linux kernel as the previously mentioned example of an object-oriented software architecture implemented in a non-OO language. I don't think there's much serious debate on whether or not OO has value for projects of significant size and complexity. "Object Oriented" is a point of view - an abstraction model - a way of breaking down a system into pieces and then understanding the relationships between those pieces. It's what software engineers do every day, and it's not scary. Mostly it's a handful of terms of art, such as "class" and "inheritance", that all people familiar with OO will know. And once you know the terms, you can discuss OO architectures with others.

OO programming is often discussed along with OO languages, and that's often where people start to passionately disagree. I find that often people cling to the language they learned in college. I've seen C++ programmers argue with C programmers, with C programmers claiming that everything C++ can do, they can do too, with the C++ proponents claiming that their language has the syntax to more expressively describe the relationships and operations with a level of type-safely. Then colleges started to teach Java, and now the Java guys were arguing with the C++ guys about type safety, interfaces vs. multiple inheritance, etc. The C# guys argued with everyone, although the C++ people started to come around; acknowledging that C# has some nice syntax. With the rise of Apple tech, Objective-C became relevant and... well.. some people think it both the purest and yet still worst language of the bunch.

I did embedded systems programming in C++ back in the mid 90s, at 3Com. This was on Motorola 68360 CPUs in Ethernet switches. We avoided operator overloading and exceptions. Operator overloading hides the complexity of a simple line of code ("a = b + c" can become a function call). Exceptions were not ready for prime-time. By limiting ourselves to what was thought to be a "safe" subset of C++, using it for object modeling and class hierarchies, we got the syntax and type-checking benefits without the perceived "bad stuff". It was very successful... and that was on systems with limited RAM and that had many software components, protocols, etc, that needed to run with certain performance characteristics.

I've not used C++ in embedded systems since then. The embedded systems guys I come across generally fall into two camps: The "never used C++, but instinctively hate it" camp, and the "learned Java in college, C++ is gross and unsafe" camp. I'm glad I used C++ back then, as I think I might have otherwise developed in that first group. People tend to fear what they don't know. I was the same with Objective-C until I studied it a little. The syntax still looks strange, but I appreciate what it's doing.

Object Oriented facilities are present in many languages now. I work almost exclusively in 'C', but I do appreciate OO design and I still do like C++. It has all the power of 'C' for the low-level stuff, yet still lets you think high level, if you want to.


This thread was about Object Oriented dispatch - a language neutral topic, so this car has veered way, way of the road. The core question from the poster was as relevant, I think, as the implementation of Forth's NEXT primitive. It is the sequence of operations needed to call a class-specific method, and is at the very core of an OO implementation. So, what is the best way to implement a class-specific vtable or similar object-type-specific jump table on the 65816? If anyone is still interested in that question, I would suggest reading the first message of the thread.

@Garth et al: The problem is not Object Oriented, the problem is that some languages (Java) & coding styles go all the way into "Object Obsessed" territory, bolting in OO ideas beyond where they're useful, making it harder for both the programmer and the processor.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I read an interesting anecdote from someone who'd roped some recent CS graduates into a technical endeavour, something to do with writing device drivers. They knew Java, they were competent at that level, but it turned out they had no idea how computers worked and could not operate in C. (I hope they were able to learn quickly.)

Sometimes we have too many layers of abstraction, and sometimes we have too few.