Why you are interested in 8bit computers?

[Scott Robison]

The biggest problem is that there are two (in general) audiences that use computers. There are the technical people who love to use and understand the internals, and there are those who just want or need to use it as a tool. People who only have an interest in web browsing, word processing, etc, want cheap and fast. The rest of us need them to be secure so that we aren't all paying for their lack of knowledge. Most of the lock down of tech has been security related, though there is plenty of "trade secret" and "walled garden" and other stuff at work as well.

In the 80s, the 8 bit computers weren't powerful enough for most people to find them compelling. Now they are and there is far more to accomplish with them.

But I am in agreement with you. I'd like to have both worlds: low level access that allows me to do whatever I want with the computer I own, and high level access that allows me to get stuff done. They don't have to be mutually exclusive, even though they often are.

[Ju+Te]

Latency never, really never, was a problem for me on a Windows-/Linux-PC or Mac.

Though I know how my 8bit machine worked (from hardware to software), I've did not reach this level of knowledge for a modern PC (I'm a Java developer since >20 years). There is a lot of abstraction that hides the details - modern processors are much more complicated beasts than 8bit processors. Think about multiple threads, memory not accessible for different processes, ways of leaking information from other threads. But this is not bad in general, the details are not necessary for a normal application developer any more. But as a consequence it produces application bloat - think of some RGB keyboard configuration software that would not fit on a CD or operating systems that require downloads of ~15GB.

[TomXP411]

On 11/2/2021 at 11:19 PM, Ju+Te said:

think of some RGB keyboard configuration software that would not fit on a CD

Agreed: program size is getting out of hand, although I will squarely place the blame for a lot of that on bloat. I've gone back and used old versions of Office, and I still maintain that Office 97 is the last version that I actually enjoy using - before the bloat cut in. I feel the same way about older versions of other software I relied on : Paint Shop Pro was my go to tool back in 2001-2002, and I can't even use it now, it's gotten so chonky and slow. 

As to that keyboard configuration software: configuration software my keyboard is less than 2 megabytes, and It actually fits on a small flash drive built into the keyboard itself. (I have 3 KinesisGaming keyboards.) These gigabyte-plus installers are just super bloat heavy with graphics, animation, and a lot of unnecessary junk that should be removed. Razer might be the worst offender, requiring a cloud connection to program your keyboard. 

45+ gigabyte game installs are down purely to the assets. Bitmaps, game maps, and music are just causing games to burst at the seams. 

None of that really is caused by low level OS dependency stuff, however. Most of what a game developer does is hidden by the game engine, in fact, so they're actually developing on two operation systems, stacked on top of each other: the game engine on top of the OS. 

As to latency - there's a super obvious place to see it. Load up something like Cynthcart on VICE, which lets you play music in real time using the keyboard, and you'll see the latency problem....

[MaicoD]

On 11/3/2021 at 2:41 PM, john_e79 said:

You have to remember also, that way back in Windows 3.1/95/98 you could boot from DOS or "Exit to DOS" from Windows whenever you wanted, you weren't locked into Windows. They took that out around the time Windows Millennium Edition and Windows XP came out. It should have stayed. Plenty of people using PCs around that time just knew that Windows gives up time-slicing and so it's not very low latency when it comes to things like games. In DOS it was direct access to hardware, so you write to something like 0xA000:0000 in 320x200x256, it writes to the screen, no hardware abstraction layers of things hidden behind the scenes. It was more like this, I remember it was a big thing to have a copy of Ralf Brown's Interrupt Listing, things like this: http://www.ctyme.com/intr/int-10.htm

Man, those were the days... once you discovered that plotting pixels in any DOS graphics mode was as easy as setting a pointer address to 0xA000:0000 in EGA/VGA memory, then incrementing the pointer to fill the screen pixel array with the colour palette index of your choice... you entered the magical realm of PC graphics where life would never be the same...

The next step of the journey would be displaying PCX images and sprites to screen, then Bresenham's line algorithm and eventually polygon rasterization... add a bit of logic and you had your very own DOS game. And if it's possible to feel more nostalgic for a development environment than the actual game you designed with it, then... Borland Turbo C, you were simply the best!

[Ju+Te]

Well, I also remember my first steps in the Win32-API using TurboPascal. Man, those were days! It was amazing how well everything fitted together and allowed to create applications that looked and behaved like normal Windows applications.

[john_e79]

On 11/5/2021 at 9:53 PM, MaicoD said:

Man, those were the days... once you discovered that plotting pixels in any DOS graphics mode was as easy as setting a pointer address to 0xA000:0000 in EGA/VGA memory, then incrementing the pointer to fill the screen pixel array with the colour palette index of your choice... you entered the magical realm of PC graphics where life would never be the same...



The next step of the journey would be displaying PCX images and sprites to screen, then Bresenham's line algorithm and eventually polygon rasterization... add a bit of logic and you had your very own DOS game. And if it's possible to feel more nostalgic for a development environment than the actual game you designed with it, then... Borland Turbo C, you were simply the best!

Oh yeah, all good stuff. When I started out with PCs in DOS back in 92 I was tinkering around with BASIC, then in mid-93 I was in 9th grade they sent me out to Texas Tech for two weeks for this gifted program which was not super fun with the competitiveness of other students there but I did pick up LOGO there, about 96-ish I picked up Turbo Pascal then Turbo C and some Turbo ASM a little later. I was hooked on demoscene-ish things back then and Ansi Art and BBSes too. All you have to say is PCX and images of Deluxe Paint 2 Enhanced and Neopaint come to mind. I started writing a pixel art paint program in C#/UWP just a few weeks back that does pen support for my Surface Pro 7 pen with InkCanvas and hardware accelerated pinch-zoom with ScrollView and I put a small LOGO interpreter in it if you want to code pixel art using a LOGO turtle.

[john_e79]

On 11/3/2021 at 1:19 AM, Ju+Te said:

Latency never, really never, was a problem for me on a Windows-/Linux-PC or Mac.



Though I know how my 8bit machine worked (from hardware to software), I've did not reach this level of knowledge for a modern PC (I'm a Java developer since >20 years). There is a lot of abstraction that hides the details - modern processors are much more complicated beasts than 8bit processors. Think about multiple threads, memory not accessible for different processes, ways of leaking information from other threads. But this is not bad in general, the details are not necessary for a normal application developer any more. But as a consequence it produces application bloat - think of some RGB keyboard configuration software that would not fit on a CD or operating systems that require downloads of ~15GB.

When you say that latency isn't a problem for you and that you're a Java coder in the same reply...............

Here you go, I was trying out halfNES, written in Java the other day. Yep it's got lots of frame stutters and frame skips when I test it, I put that in the category of general latency, and not just input lag necessarily, maybe I'm miswording that.

I picked up Java about 20 years ago back when it was still under Sun Microsystems, which were much nicer days I think for Java, I also learned Oracle around the same time. I also picked up C# around the same time, which I still use fairly regularly. I recently started writing a NES emulator though in C/C++/SDL2 much like the X16 emulator is written in C/SDL2. I probably would not write something like that in C# or Java without writing the core of it in C/C++ and calling into it via Interop in C# or JNI in Java, using the higher level language as a UI layer. Higher level languages do try to hide some details, but I still find them very beneficial to learn, depending on what I want to do.

Since your post though was about Arduinos and Raspberry Pis let me respond to that. I've got a few Arduinos and a few Raspberry Pis. You could with the Arduinos hypothetically take a sketch and make it reference some C/C++ library which could reference some inline ASM, but, you might not do that regularly. Arduinos are made to be more so "appliances" than a full OS. I've seen attempts at an OS on the Arduino but it's a bit of a squeeze, my Arduino 33 IoT Nano only has I think 256kb flash RAM so it's not much to work within. You could also try to make a bare metal OS for the Raspberry Pi and I've been in those forums before talking to various developers and there are nuances I've read about it with regards to things like the GPU, I've done some minor ASM so far on the RPi4B.

I'm interested in OS development btw, so something like the X16 interests me and I plan to get one. The X16 doesn't have its ASM already watered down by a Hardware Abstraction Layer was part of my earlier point, it's direct access so you can maybe learn some interesting things with it. There are no ominous "why do you need to know that?" responses from people if you ask questions about the kernel, as there are sources to its kernel on github. I'm also familiar with the 65C02 because I've already written a 6502 emulation for a NES emulator. One of the things that makes the X16 interesting is precisely that it's not a multi-tasking system so yes, it doesn't have to think about thread safety and about protecting process memory, so, if you were delving into it, it's not so complex to learn as, say, taking in and learning the whole Linux kernel sources.

[rje]

On 11/2/2021 at 10:58 PM, Scott Robison said:

The biggest problem is that there are two (in general) audiences that use computers. There are the technical people who love to use and understand the internals, and there are those who just want or need to use it as a tool. People who only have an interest in web browsing, word processing, etc, want cheap and fast.

I'm in neither category, and you're right, I'm probably a niche in the niche.

I'm a software developer who doesn't really want to understand all of the internals if I can avoid it; I just want a simple toolchain that lets me write games that aren't three orders of magnitude worse than most things written for the target platform (I'm fine with being two orders of magnitude worse though).

With some minimal software*, the Commodore 64 gave me that toolchain.

 

* The ubiquitous Sprite Editor, Butterfield's Supermon, and Martin Kees' SuperBASIC 64 (which made it trivially easy to use sprites and the SID), helped me write a dozen half-finished BASIC games in the 1980s.

 

[Scott Robison]

On 11/12/2021 at 8:50 AM, rje said:

I'm in neither category, and you're right, I'm probably a niche in the niche

Well, I did simplify it quite a bit. Most analogies fall apart at some point, and mine did. I think your desire still puts you in the tech loving crowd. Even if you don't want to understand the hardware at the chip level, the fact that you are willing to live with the limits of the tech and desire for good tools for it definitely excludes you from the "just web browsing and word processing" crowd.

[BruceMcF]

On 11/12/2021 at 11:39 AM, Scott Robison said:

Well, I did simplify it quite a bit. Most analogies fall apart at some point, and mine did. I think your desire still puts you in the tech loving crowd. Even if you don't want to understand the hardware at the chip level, the fact that you are willing to live with the limits of the tech and desire for good tools for it definitely excludes you from the "just web browsing and word processing" crowd.

Quite. It's not the second group who are buying the coffee cups that say "It's a Hardware Problem" and "It's a Software Problem" ... it's the Software and Hardware subgroups (respectively) of the first group.

And, to be clear, it IS a hardware problem. The software's working JUST as it was intended to.