game machines

[BigEd]

From a teaching perspective, I think it's good to deal with multi-word arithmetic - that's where the carry bit really helps, and the carry bit is only exposed in the lowest levels of programming. But, it might be good not to have to introduce multi-word arithmetic in the very first lesson.

I like 16 bits as a data size, and I like word-addressed machines, and I think programming to a VM or in emulation is just as valid for a learning situation as programming to hardware. The key is in the encapsulation: programming in emulation on a machine which boots to a single application (the emulator) is very different from programming on a regular PC with email in one window and a browser in another and system alerts popping up just when you got your head into the programming. Programming an embedded emulation on a microcontroller is almost indistinguishable from programming the microcontroller itself, except that the emulation can be designed to be clean and easy and portable.

Which is to say, programming some nice 16 bit VM implemented on an Arduino would be a win. The hardware is cheap, is available, and the machine is nice.

[White Flame]

Hugh Aguilar wrote:

A game-machine is going to be dealing primarily with 16-bit data --- whether you use assembly-language, Forth or C, you are better off with a 16-bit processor,

What data specifically would be 16-bit? Most single-process game machines set up a static allocation of the address space (or the hardware provides fixed area allotments, like the NES), which does not have to be dynamic-pointer-heavy. I would say that generally speaking there's more rationale for home computer applications to be 16-bit, not games. If your I/O hardware demands many 16-bit values shoved into it, then that is certainly a hardware design dependency that would speak to it, but there aren't many specifics around this idea yet.

Quote:

If the game-machine is going to be programmed by teenagers, then an upgraded 65c816 or a 65902 would be a more comfortable environment.

You certainly have a lot to say about teenagers, that I'm not convinced about. New learners of any form jump through whatever hoops they need to, and don't even really perceive the hoops, so long as the very initial barrier to entry is simple (ie, not tons of instructions & details to learn). It's only the experienced people who realize better ways of doing things exist beyond what they've initially learned, as they progress though greater complexity.

There's lots of opinions that people have thrown in the ring here, but what premises bound the design that guides which opinions apply? "Game machine that teenagers can program" still leaves open a lot of underlying assumptions: What kinds of games? What kinds of "teenagers", heads-down geeks or more general/casual audience? What is easy vs hard given the answers to the prior 2? How do hardware compromises balance those? Where does cost & hardware design complexity balance in, as simpler hardware means more user work? If you want users focused on the game dev & not the tech details, what do you have to offer to compete with a rich, integrated software environment on a PC that handles most of the details for you?

[sark02]

White Flame wrote:

What data specifically would be 16-bit?

I wrote (hobby) games in 6502 for the Atari 800XL back in the early 80s. Even on a (160, 200) pixel screen, 16-bits were used as 8.8 fixed-point values for things like position and speed - allowing for precise movement. Not usually as two contiguous bytes, but rather as XPOSLO,X and XPOSHI,X - where X was an object index. For games whose playfield extended beyond the screen (e.g. side-scrollers), 24-bits might be used; i.e. XPOSLO,X XPOSMID,X and XPOSHI.X - giving, say, a 16.8 fixed-point format. Discrete 16-bit values, stored as two contiguous bytes, were also used for scores.

I was using hardware scrolling and raster interrupts... changing hardware registers multiple times within a frame, while running the main game loop and moving objects around at the base level.

One common trick was to change the color of the background during different parts of the main loop so you could see (by how far the down the screen the beam was when the color changed) how much time had passed and how much time was left (to the bottom of the screen). Lose the race (run out of time) and your game goes from 50 frames/sec down to 25... which would be bad.

Time was always tight. Everything was optimized as much as possible. Do I need to CLC before this ADC, or can I rely on C being clear already? In that environment of cycle counting everything, even Forth would have been too inefficient. It was great fun... and all these same things (cycle counting and racing the beam) happened again on the Atari ST... only with 68000 assembly. The 80s were awesome.

[BigEd]

I think 16 bits for a data type is a simplifying assumption for two reasons: it's a good size for addresses, and it's a good size for data. Incrementing a zero page pointer in 6502 is just a little fiddly - while I agree it's not an obstacle, it's a speed bump. For data, you've got screen coordinates at least, also pitches for sounds need more than 256 bits if you're supplying a period rather than an index, and of course scores, and as noted by sark02, variables like world coordinates or velocities are likely to need more than a byte of range. Even a lookup table can sometimes find one byte of index a bit limiting.

Agreed, though, teaching and learning, when done well, don't fall apart when they hit small speed bumps. Motivation gets over that, and designing suitably motivating challenges is part of the challenge. A beginner is not going to be able to write an immersive 3D game as their first effort: they need to be guided to the realisation that breakout, pong, tetris, snake, are all rewarding games to play and suitable challenges to write.

[BigDumbDinosaur]

Hugh Aguilar wrote:

Any program that deals primarily with 16-bit data is going to be bloaty and slow on an 8-bit processor --- a hybrid processor such as the 65c816 is going to be a lot better --- an actual 16-bit processor is, of course, preferred.

Ahem...the 65C816 is indeed "an actual 16-bit processor," not a "hybrid" (whatever that means—perhaps "dual personality" is a more accurate description).

The 65C816 has a 16-bit ALU, 16-bit user registers and a 16-bit stack pointer—only DB, PB and SR are eight-bit registers. All internal arithmetic and logic operations are performed 16 bits at a time, regardless of register width settings (the m and x bits in SR). Setting register widths merely affects what the "outside world" sees during loads, arithmetic/logic operations and stores. For example, if the index registers are set to eight bits width and one of them is incremented past $FF the increment operation internally is 16 bits, but carry into the MSB is discarded. The 65C816's data bus itself is eight bits wide, but that simply means a 16-bit load or store operation will atomically occur in two memory cycles.

Quote:

I'm not opposed to the 65c816 if it could be upgraded with an OSX prebyte like on the M65c02A --- without that, Forth is too bloaty and slow to bother with.

You keep making this assertion, despite no evidence to support it. Can you provide a link to a Forth that is bloaty and slow running on a 65C816? I'm aware of Garth's 65802 Forth, which he has described as running considerably faster than the 6502 equivalent. As a well-written Forth kernel tends to be quite efficient (efficiency being one of the hallmarks of Forth), I'd expect that a kernel optimized for the 65C816 running in native mode would see a substantial performance gain.

Quote:

If the game-machine is going to be programmed by teenagers, then an upgraded 65c816 or a 65902 would be a more comfortable environment.

Again, I will challenge you to introduce us to these teenagers who are interested in writing bare-metal code for any microprocessor, not just a 65xx one. Few of them existed during the halcyon days of 6502-powered home computers, a period of time with which I am very familiar. I suspect that these days I'd have better luck meeting up with a unicorn than meeting up with a teenager who is fluent in any assembly language.

[BigDumbDinosaur]

DerTrueForce wrote:

I'm interested in fiddling around with Forth, particularly Tali Forth 2, but I'm having trouble getting it to work on my build(the Duart isn't playing ball for some reason, and I'm still attempting to ascertain why).

What exactly is the DUART doing...or not doing?

[cbmeeks]

BigDumbDinosaur wrote:

Again, I will challenge you to introduce us to these teenagers who are interested in writing bare-metal code for any microprocessor, not just a 65xx one. Few of them existed during the halcyon days of 6502-powered home computers, a period of time with which I am very familiar. I suspect that these days I'd have better luck meeting up with a unicorn than meeting up with a teenager who is fluent in any assembly language.

I agree 100%. My son's school teaches "coding" and it's always either HTML or Python. Nothing wrong with that. But unless your focus is hardware (or better yet, embedded hardware) you probably won't see many teens coding bare metal ASM. In fact, I've known several junior level programmers as well as interns in college and they've "heard" of assembly language. But you might as well be speaking Klingon to them.

Just a different world.

[BigEd]

Hmm, if enough of us here join in the game of playing at grumpy old men, we will end up only having grumpy old men joining in here. Wouldn't that be a bit self-fulfilling.

To be constructive, as I think the head post intended to be: what might one build, what might one do, which would be a good thing? What might interest, what might illuminate, what might inspire?

[White Flame]

BigDumbDinosaur wrote:

Quote:

If the game-machine is going to be programmed by teenagers, then an upgraded 65c816 or a 65902 would be a more comfortable environment.

Again, I will challenge you to introduce us to these teenagers who are interested in writing bare-metal code for any microprocessor, not just a 65xx one. Few of them existed during the halcyon days of 6502-powered home computers, a period of time with which I am very familiar. I suspect that these days I'd have better luck meeting up with a unicorn than meeting up with a teenager who is fluent in any assembly language.

The majority of the crackers and demo coders in the 80s were teenagers. Many of the upstart utility developers (not productivity app development, though) and game developers were late teens & young adults. Of course, many of the computer handyman troubleshooters were & still are teens; back then that had a lot of overlap with assembly language.

I was in late elementary school during the C64's time when I learned assembly, with other kids who already knew it. It was the only way to get the machine to do the cool stuff at the time, hence it was attractive to know.

[Alarm Siren]

Well, you say embedded hardware, but with the Hobbyist Revolution (which is not a bad thing), there's now a whole host of systems to make programming small micros "friendly"; Arduino is the prime example, but by no means the only one. For example, in the UK we've got the BBC Micro:bit, for which the three officially supported languages are variants of JavaScript and Python, and some Microsoft monstrosity called Blocks. They also previously had a fourth language called Microsoft TouchDevelop, but that seems to have been dropped. Admittedly the Micro:bit is mainly aimed at primary schools, so "simple" languages might be appropriate, but it still concerns me - particularly that students are mollycoddled by a VHLL that is "good enough" for the exercises and little games they make at school, so they never delve deeper, which I feel is a real shame. No, you don't always need to code to the bare metal and doing is often a waste of time, but knowing the lower level stuff makes you a better programmer even at high levels, because you understand what code will result in the compiler doing horrible contortions and what won't.

Side note: Why is JavaScript so damn popular and/or so commonly pushed? its a horrible language that is barely usable for its original purpose (client side website scripting) without massive frameworks to make it palatable, and we're only stuck with it for that purpose because its become the de facto standard; why ruin other areas of programming by shoving it into domains it was never intended for, when there's already literally hundreds of alternatives all better suited? I just don't get it.

[BigDumbDinosaur]

BigEd wrote:

Hmm, if enough of us here join in the game of playing at grumpy old men, we will end up only having grumpy old men joining in here. Wouldn't that be a bit self-fulfilling.

Describing me as an "old man" is indeed accurate. However, and despite my physical infirmities, I am seldom grumpy. A better adjective might be "pragmatic" or "no-nonsense."

Quote:

To be constructive, as I think the head post intended to be: what might one build, what might one do, which would be a good thing? What might interest, what might illuminate, what might inspire?

I am being constructive, although maybe not in a way with which you agree.

I made my comment because I have been seeing a pattern in Mr. Aguilar's posts, in which he subtly condemns the 65xx architecture as inefficient, obsolete, not worthy of use, etc. He continues in that vein with his criticisms of the 65C816 vis a vis Forth, which in my opinion, are largely unproductive. Somewhere in the middle of all that, the reader is expected to find something interesting about the design of improved game machine hardware. If anyone is being less than constructive, it isn't me—I'm not downgrading the architecture in multiple posts.

In any case, the fixation on what teenagers might or might not do with improved game machine hardware is speculative at best—I question whether it should even be a factor in how such a machine might be designed.

[BigDumbDinosaur]

White Flame wrote:

The majority of the crackers and demo coders in the 80s were teenagers.

That's an often-repeated statement that was largely not true. I was there in those days (I wrote my first 6502 program in 1977) and never met any cracker who was a teenager. Everyone who was a cracker that I did meet or learned about was at least in his or her mid-20s and had formal computer science training.

As for the demo scene, that was more a product of the 1990s and later. By then, I was not longer involved in professional 6502 development, so I can't comment on who was involved.

Quote:

I was in late elementary school during the C64's time when I learned assembly, with other kids who already knew it. It was the only way to get the machine to do the cool stuff at the time, hence it was attractive to know.

The C64 was released in 1982, at which time I was in my mid-thirties. Again, I never encountered any teenager who knew 6502 assembly language well enough to "do cool stuff" on the C-64—and I certainly attended enough seminars and such in those days to have run into such individuals if they had been around. The teenagers I did know who played with computers mostly knew BASIC, not assembly language.

[DerTrueForce]

BigDumbDinosaur wrote:

DerTrueForce wrote:

I'm interested in fiddling around with Forth, particularly Tali Forth 2, but I'm having trouble getting it to work on my build(the Duart isn't playing ball for some reason, and I'm still attempting to ascertain why).

What exactly is the DUART doing...or not doing?

I've replied to this over over here because I feel it's too off-topic for this thread. I hope nobody minds.

[sark02]

BigDumbDinosaur wrote:

White Flame wrote:

The majority of the crackers and demo coders in the 80s were teenagers.

That's an often-repeated statement that was largely not true. I was there in those days (I wrote my first 6502 program in 1977) and never met any cracker who was a teenager. Everyone who was a cracker that I did meet or learned about was at least in his or her mid-20s and had formal computer science training.

I learned Z80 on the ZX Spectrum in '84, when I was 15, and 6502 on the 800XL the next year. By 17 I was writing proto-games moving the screen and sprites around. I wrote my own utilities to transfer games from tape to disk, by patching reset vectors and invoking my own disk save routines. I wouldn't put myself in the cracker/demo scene category by a long shot, but I was a teenager and I was operating at a non-trivial technical level. I got an Atari ST in early '87 and immediately moved to 68000 and that summer was into interrupts and games again. That fall I started university and that was the first I heard of demo scene guys. From my experience the Atari ST demo scene was full of university students (mostly continental Europe)... but there may have been younger guys in there... I don't know.

The thing to remember about those days, and why "the kids" were so engaged, is that we were working on the cutting edge. As I mentioned before, I recaptured some of this feeling in 2002/2003 when I picked up the Gameboy Advance and taught myself ARM assembly and started writing games for that. Even though that machine had great hardware, and was mostly programmed in 'C', there were some performance paths that demanded dropping down to ARM code... racing the beam all over again.

No 6502 computer is going to inspire the same wonder and passion that these systems did when they were new. I had friends in the 80s that were also hacking BASIC, assembler, 6502, Z80 and 68000. In the early 2000s there were online forums with people excitedly sharing tricks and tips on the Gameboy Advance. These were shared experiences. You could show a buddy a sprite multiplexer or a smooth scrolling screen and get an appropriately enthusiastic high-five.

I have friends who teach their kids robotics. They do school projects with Lego Mindstorms, or other kits aimed at early teens. These use "beginner's languages" in the same way that we had BASIC... and that's ok. Programming is hard to get into, and it's best (I think) to start with forgiving, abstract concepts such as simple numbers and strings, as opposed to strong typing or having to understand bits, bytes and addressing.

Teenagers who are inclined to do so will go further in the direction their interests take them. Some will want to go deep, with Arduino, Propeller, Raspberry Pi or the other myriad of little computers that can blink LEDs and do stuff. Some will go the other way towards higher level languages, web, phones or big engine gaming. Others still we lose interest and find other passions (or become aimless pot-heads).

Some will develop an interest in historic computers, and join communities such as this, C64, Atari, 2600, even DOS... whatever takes their fancy.

People like different stuff. Someone tomorrow (and if not tomorrow, the next day or the day after) will start programming the C64 for the very first time. Maybe to recapture a youth playing games and wondering what they could do themselves, or maybe just through a geek interest in stone age tech.

I believe that people prefer interactive experiences, which is why many are drawn to writing games or moving colored shapes around. Maybe the retro itch can be scratched by emulators... why should I lust after a Defender-style machine when I could just write code for the machine itself and run it on MAME? There are virtual warehouses full of old computers and arcade machines that MESS and MAME can emulate. Missed out programming the Tandy or Amstrads of the 80s? You could be doing that in under an hour.

But some people like holding something in their hands. A real keyboard. A real display. It scratches a different itch. And I think that's what a fun little 6502 games machine... with just enough modern tech to be not annoying (no cassette tapes, please) could serve. Not an emulation on a $25 Raspberry Pi... might as well live in a web browser window...

That all said, nobody is going to pay $200 for a new device with a user base of fewer than 5 people.

[BigEd]

I think there is a tension here between trying to recapture one's youth, and thinking about what might be good for education today. When I was a youth, I had lots of time and the ability to get lost in thinking about and exploring something. That's something which is worth trying to make use of - capturing the imagination.

There were loads of things I didn't get into, and a few I did, so looking back it seems that computing was terribly important and everyone should do it, but maybe also sports are important, which is something I missed out on. We surely wouldn't want everyone to live exactly our own lives.

As for education, I think there are several aims
- opening the eyes, especially as to how things are in the world, and how all the manufactured things are things which someone designed and someone could make. There is no magic.
- self discovery, in that one needs to know what it is one likes, what one finds interesting, what one could develop into a skill, whether one wants to create or to help or to direct or to provide or to perform.
- safe exploration of failure, especially in making things, where failure is compulsory and a necessary part of gaining competence.
- development of competence, but more than that, development of the ability to develop competence. No-one becomes good at something without putting in lots of effort, paying attention, making mistakes.

The educational and engineering activities around Lego are great. It would be absurd to think that it's all about training people to be excellent at Lego! Likewise, then, using a block-based visual language to teach the rudiments of programming isn't about training people in visual languages. Nor is using python about training for python coding. What you need, I think, is something encapsulated and self-sufficient. A Raspberry Pi is more encapsulated than a PC - less by way of dependencies and distractions. A 16 bit VM is more encapsulated than an x86 or an ARM, especially if the VM has primitives which correspond nicely to the kind of I/O you need for robotics or games.