game machines

[Hugh Aguilar]

sark02 wrote:

Hugh Aguilar wrote:

If the game-machine used an off-the-shelf 65c816 (as DerTrueForce suggests) then I would not consider getting involved at all.

What level of additional involvement did you have in mind?

Write the Forth system.

sark02 wrote:

These discussions are interesting to me as I enjoy hearing how other people approach the problem, what their preferences are, etc. Seems there are opinions on frame buffers vs. tiles, standard vs. customized CPUs, DMA, bit depth, sound generation, etc. It's all hypothetical, of course, and I wouldn't expect it to go further. Producing an actual consumer-level product (nicely packaged), even at Kickstarter levels, would take $100,000s+.

It doesn't have to be nicely packaged --- it is for programmers, not Walmart shoppers.
It would just be a board with an RS-232 port for development and an HDMI port for the video/audio.

sark02 wrote:

Looking at your posting history, Hugh, it looks like you've been working on a handful of different things. Maybe you're like me - I tend to bounce around - things grab my attention, occupy my time for a while, and then I'll find something else. But if you'd like to do something real then these platforms might help you take an idea to the next level, with backers and funding.

The 65VM02 design was abandoned because it was a bad idea.

The 65ISR design is a marginally good idea --- if any HDL programmer got interested I would like to continue it --- I don't know Verilog or VHDL, so I can't take a design further than just a description.

The TOYF design is what I am interested in now. I'm working with a Verilog programmer on implementing it --- hopefully that will come to fruition.
The TOYF should out-perform the MSP430. It addresses 64KW (128KB) of code-memory and 64KW (128KB) of data-memory. It is for pretty big programs that would normally require an ARM Cortex.

I'm not enthusiastic about any 8-bit processor. In today's world we have many 16-bit and 32-bit processors available --- not many people are interested in 8-bit processors anymore (the STM8 gets some use, and ye olde 8051 family will always be used).
Most 8-bit systems are pretty small, with cost being the only issue. This is why the 65VM02 was a bad idea; it was for large systems with 128KB of memory that the MSP430 would be more suitable to.
The 65ISR-chico is a better idea because it can work with very little internal RAM, like 1KB or thereabouts. The 65ISR-abu can address up to 16MB but it is still for small systems that work with a few KB of internal RAM --- all those megabytes would be for storage of data-files --- this is similar to how the ds89c420 works with 256 bytes of internal RAM, but it can address megabytes of external RAM (it has a "stretch value" for external memory access, on the assumption that external RAM will be slow).

All this talk about sprites and such for the game-machine is more complication than I think is a good idea. This makes the programming more complicated than most teenagers are going to delve into. Also, sprites tend to support a certain style of game, so all the games tend to look alike --- you have a few squarish graphical images floating around (like Ms. Pacman and the ghosts), and you often have physically impossible feats such as objects that pass through walls.

I would actually be more interested in using the TOYF and a very simple graphics design such as 320x200 with 16 colors. You could have 16KW for the frame-buffer (bank-switch this with the display buffer). The TOYF has 64KW of data-memory, so there is plenty of room left over. The TOYF is going to be hella fast, so programs can just brute-force the graphics display, redrawing the entire thing in every heart-beat. The programming is simple this way, with less to learn (it should take about 10 minutes to learn how the frame-buffer works, even by a teenager who has never heard the term "frame-buffer" previously), and there is more opportunity for creativity because you do everything in software.

I have mentioned the M65c02A and the MC6809 earlier in the thread, and DerTrueForce mentioned the 65c816. Those are 8-bit processors. They aren't fast enough to brute-force the graphics display --- they are going to need hardware support in terms of sprites or whatever --- I had mentioned 6502-family processors partly because this is a 6502 forum, and partly because I thought that compatibility with a classic game-machine such as the Commodore-64 would be a big draw, but I no longer think that an 8-bit game-machine is a good idea.

BTW: This may be a dumb question, but why is the video always wider than tall? For example, 320x200 seems to be common. Why not 320x320? This would be a 25KW frame-buffer which is still reasonable, and you would get square pixels that would simplify the programming (moving up or down one pixel would appear to be the same speed, although moving at an angle still requires some math to keep the speed consistent).
I'm guessing that this is because ASCII characters are taller than they are wide, because they have to support both upper-case and lower-case with tails underneath (g j p q y). In a game-machine, text is not very important --- it would be painted like any graphical image --- so having hardware support for text is not needed.

The Centipede game always looked like a text display to me, with all the mushrooms lined up in neat rows and the eponymous centipede moving only horizontally and vertically --- the biological elements seemed rather robotic, but ironically the laser-cannon moved smoothly in any direction as if it were biological (that had to be a sprite) --- does anybody know if the mushrooms and centipede segments were actually text characters?

I would hope that a TOYF-based game-machine could provide more biological-appearing movement than the 1980s vintage Centipede game --- I'm not an expert on biology --- I'm pretty sure that critters move freely in all directions though, not just at 90 degree angles.

[BitWise]

I bought one of these FTDI EVE displays a while back but have never found the time to play with it. You use an SPI interface to talk to its graphics processor. You build up a collection of objects in its memory which you can scale, rotate and move like big sprites.

There are a number of videos on YouTube that show EVE cards in operation
https://www.youtube.com/results?search_ ... 0+examples

[CurtisP]

Hugh Aguilar wrote:

BTW: This may be a dumb question, but why is the video always wider than tall? For example, 320x200 seems to be common. Why not 320x320? This would be a 25KW frame-buffer which is still reasonable, and you would get square pixels that would simplify the programming (moving up or down one pixel would appear to be the same speed, although moving at an angle still requires some math to keep the speed consistent).

Because television and monitor screens are wider than they are tall, unless you turn them sideways like some of the old arcade games used to do.

The closest I've seen to a square display was the TRS-80 Color Computer, which had a 256x192 display and pixels that were slightly taller than they were wide, with huge borders on either side.

I think the ideal screen resolution for an 8-bit system is 256x256 since you can use exactly one byte for each coordinate.

[barrym95838]

CurtisP wrote:

... I think the ideal screen resolution for an 8-bit system is 256x256 since you can use exactly one byte for each coordinate.

Maybe I'm completely nuts, but if we're going to be rolling our own FPGA package together shouldn't we consider the possibility that 8-bit bytes are an arbitrary and artificial limitation? A 65902 would have twice the op-code space, over twice the stack space and over four times the memory space with almost no effort. The hardest parts would be agreeing what to do with 256 more op-codes and modifying an assembler to implement them! I have brought this up before, but few (maybe less than two) have visibly shared my excitement over this idea.

Mike B.

[BigEd]

(By complete coincidence, today's mos6502 post is about the Microtan 65, which had 9 bit wide video memory...)

[Hugh Aguilar]

barrym95838 wrote:

CurtisP wrote:

... I think the ideal screen resolution for an 8-bit system is 256x256 since you can use exactly one byte for each coordinate.

Maybe I'm completely nuts, but if we're going to be rolling our own FPGA package together shouldn't we consider the possibility that 8-bit bytes are an arbitrary and artificial limitation? A 65902 would have twice the op-code space, over twice the stack space and over four times the memory space with almost no effort. The hardest parts would be agreeing what to do with 256 more op-codes and modifying an assembler to implement them! I have brought this up before, but few (maybe less than two) have visibly shared my excitement over this idea.

Mike B.

My understanding is that memory in an FPGA is actually 9-bit (most or all FPGA chips) --- I don't know why --- that is just what I was told.
This is why the BUGS18 processor has an 18-bit wide opcode. I think it still has a 16-bit data cell size though.

I like your idea for an enhanced 65902 that has a 9-bit opcode, but still has an 8-bit data cell size. The lower 256 instructions would be compatible with the 65c02, but the upper 256 instructions providing enhanced functionality (such as using 16-bit registers). For example, you could have a LDA adr instruction that is compatible with the 65c02, but also have a LDD adr instruction that loads a 16-bit value (the A register is the low 8 bits of the D register). Legacy 65c02 code would run on the 65902 if, when it is loaded, you just make sure that the high-bit of each opcode is set to 0. Note that A is still 8-bit, so if you have LDA #-3 the -3 value will have its high-bit clear, but only the low 8 bits are loaded so the high-bit is irrelevant anyway. If you have LDD #-3 however, your -3 value is 18 bits but your processor will ignore the high-bit of each 9-bit value to load D with a 16-bit -3 value.

This could work for a small micro-controller in which all the code is internal to the FPGA, that has maybe 16KB of non-volatile memory for code. This is not going to work for a game-machine though, because it needs to have code in external memory --- programs are going to be pretty big --- programs are going to be written by the end-user.

I'm pretty dubious of the idea of having a 9-bit data cell size --- the rest of the world uses 8-bit or 16-bit.
This reminds me of what the head mechanic at a large cattle ranch in Colorado (about 20,000 acres) told me regarding the first-generation Hummer, which is supposed to be the ultimate off-road vehicle. It was too wide for the two-rut roads they have. All those roads wind around hills, so when the Hummer was on the road the tires on the lower side were off the road (there is no room for going off the road on the high side because there is a steep embankment there). The tires on the lower side were on a steep embankment downhill though --- they would start to slide on loose shale, and the Hummer would start to slide off the road and over the embankment. This was when the driver would hit the brakes, and get on the CB to call for help --- the head mechanic would drive out there with his trusty Jeep and rescue the Hummer --- he hated the Hummer and thought the Jeep was far superior!

The guys who know HDL could give a more solid answer --- I don't really know anything about hardware --- so I can't share your excitement about this idea until I know more.

[Hugh Aguilar]

CurtisP wrote:

Hugh Aguilar wrote:

BTW: This may be a dumb question, but why is the video always wider than tall? For example, 320x200 seems to be common. Why not 320x320? This would be a 25KW frame-buffer which is still reasonable, and you would get square pixels that would simplify the programming (moving up or down one pixel would appear to be the same speed, although moving at an angle still requires some math to keep the speed consistent).

Because television and monitor screens are wider than they are tall, unless you turn them sideways like some of the old arcade games used to do.

The closest I've seen to a square display was the TRS-80 Color Computer, which had a 256x192 display and pixels that were slightly taller than they were wide, with huge borders on either side.

I think the ideal screen resolution for an 8-bit system is 256x256 since you can use exactly one byte for each coordinate.

Well, my design can work with a 320x200 display, with 16 colors.

In my latest/greatest TOYF design, I provided support for 1-bit variables --- I was thinking of 1-bit I/O ports
It is trivial to upgrade to provide support for 4-bit variables --- this would allow four 4-bit pixels in each 16-bit cell.

[whartung]

BigDumbDinosaur wrote:

The overwhelming majority of today's teenagers are not going to get involved with a hobby computer, let alone write something as complicated as a piece of game software with heavy graphics in assembly language—regardless of the MPU being used. Today's kids are into instant gratification, which they are not going to get doing bare metal software development. If it can't be readily done on a Raspberry PI or similar, they are not likely to do it.

Why should they?

I never used a machine with core memory, drum memory, vacuum tubes, etc. I've never carved my own gears to perform mathematic equations. I own, but have never used a slide rule outside of seeing it add 2+2. Why on earth would I use any of those things to solve my problems when there is something better, smaller, cheaper, faster, and easier to use available?

Folks would push the limits of the older machines simply because the limits were so readily reached.

Today, the modern limits are physical: form factor, power, screen size.

Have you seen this?

https://www.youtube.com/watch?time_cont ... 3ue35ago3Y

That's a real time rendering, on some VERY good hardware, as it is a technology demo.

Is it no wonder that a teenager may well not be interested it cycle counting to get extra sprites on the screen of Yet Another Platform game? When they could put less time in to the same game written in JavaScript using an off the shelf game engine that runs 100FPS in a common web browser?

Then, in contrast, you have things like this:

https://www.youtube.com/watch?v=27PN1SsXbjM

That is a real time video from a demonstration where it's designed to run on a fairly generic modern Windows machine, but the EXE is limited to 64K, with no external resources. This is an article that describes it in detail. http://www.ctrl-alt-test.fr/2018/a-dive ... immersion/

The contrast that a small screenshot of a single frame of the video is larger than than the EXE that creates it is telling. It's a fascinating look in to programmable texture generation, animation, music, and video within a constrained environment.

If you look, it's over 20,000 lines of C++, that compiles down in to < 14K of code.

Meanwhile, kids are building CPUs in Minecraft using lava and water.

So it seems to me that the fundamentals are still being conveyed in to the future generations, organically, even if they're practicing their craft in different domains.

[cbmeeks]

sark02 wrote:

In the book (downloadable from http://itsbehindyou.atwebpages.com/index.html)

First off, thanks for the link to that book. I downloaded it and read the entire thing in one sitting. Great read!

sark02 wrote:

he talks about the programmers who were simultaneously working on the R-Type ports to other systems, including the C64. There are many youtube videos demonstrating the large circular rotating pattern of enemy ships that appear in the game, and the C64 programmer struggled to get his multiplexer glitch-free... eventually causing delays that lost him the Activision project. He was a competent programmer, and the alpha build of his version of his C64 R-Type can be found on the web. It's a shame that all the other work that went into the game was for naught. That's one professional games programmer who would have preferred more hardware sprites.

The fate of one game back in the 80's hardly eliminates the usefulness of a good software multiplexer. There were hundreds and hundreds of commercial games that used them and many of them were very good. Of course more hardware sprites helps. But remember this, the fact the NES had 64 sprites is not as magical as you might think. Especially since both the C64 and NES has 8 per scanline limit. But in a given scanline, the C64 could actually draw 8x24 pixels vs. NES 8x8 or 8x16. Not counting hardware doubling (which both support).

Anyway, my point is that the NES could have had 64, 128 or 500 sprites. When you're limited to 8 per scanline, the number you have isn't a deal breaker. Besides...pause a game (C64 or NES) and count the number of moving objects. I bet you'd be surprised that there aren't as many as you might imagine.

[sark02]

cbmeeks wrote:

sark02 wrote:

In the book (downloadable from http://itsbehindyou.atwebpages.com/index.html)

First off, thanks for the link to that book. I downloaded it and read the entire thing in one sitting. Great read!

Glad you liked it. I knew the C64 programmer from the book, and remember visiting his office in Southsea. At the time I was at University, away from my home town, and was a little envious that he was making a living writing games. I didn't know anything about the underlying drama, and in retrospect I'm glad I was far away from it.

Quote:

The fate of one game back in the 80's hardly eliminates the usefulness of a good software multiplexer.

Of course you're right... Multiplexers were very common, but in the end they were only necessary to overcome a limitation of the hardware. If hardware supports N sprites, then sooner or later (probably sooner) someone is going to want N+1.

If you were putting together a new system there would be no reason to copy the same limitations as found on any particular 35 year old system. If what you're actually looking for is that same VIC+SID goodness, then there's a large, active community producing games almost daily at http://www.lemon64.com/forum/. If you're a C64 fan, it's definitely worth checking out.

Regarding sprites per scan-line, I guess if you're building your pixel stream on the fly, then eventually there's either a memory bandwidth limit (reading sprite data into the chip from RAM), or a data-path complexity limit (multiplexors and gates to combine the sprite data with the background) that will get you eventually. I'm sure there are many different ways to build a video generator... I think that's the interesting part vs. assembling generic SoC components like LEGO.

[BigEd]

(I concur - that's a great book!)

[cbmeeks]

sark02 wrote:

If what you're actually looking for is that same VIC+SID goodness, then there's a large, active community producing games almost daily at http://www.lemon64.com/forum/.

Oh yeah...been an active member there since 22 Oct 2004.

sark02 wrote:

Regarding sprites per scan-line, I guess if you're building your pixel stream on the fly, then eventually there's either a memory bandwidth limit (reading sprite data into the chip from RAM), or a data-path complexity limit (multiplexors and gates to combine the sprite data with the background) that will get you eventually. I'm sure there are many different ways to build a video generator... I think that's the interesting part vs. assembling generic SoC components like LEGO.

I guess for me, I wouldn't design something that would be decades above what the CPU could have handled "back in the day". For example, a GPU with 24 bitplanes, 3D hardware and 40,000 sprites on a 65C02 would be severely out of place.

If I were designing a new system that used the 65C02, I would probably limit it to a system that could have existed back then if companies didn't care about the costs. For a 65C02 system, I would do something like 32 sprites of 32x32 pixels and all sprites can be on the same scanline and a sprite could be reused like the C64/Amiga.

If I had a blitter, it would be no more than a simple block copy and maybe rotation of tables.

The Atari 8-bits had it right, in my opinion. I only wished it had better sprites. The display list (copper in Amiga speak) is the way to go.

For audio, I would do something like a Propeller running 2-4 SID-Cogs.

[GARTHWILSON]

whartung wrote:

Why should they?

I never used a machine with core memory, drum memory, vacuum tubes, etc. I've never carved my own gears to perform mathematic equations. I own, but have never used a slide rule outside of seeing it add 2+2. Why on earth would I use any of those things to solve my problems when there is something better, smaller, cheaper, faster, and easier to use available?

Ahem... slide rules' simplest functions are usually multiplication and division, followed by square roots, logarithms, and trig functions. I guess you're supposed to be able to do addition and subtraction in your head, although there were a very few slide rules made that had addiators on one side.

One value of slide rules however is that they help the user understand number relations better. I do log conversions for decibels in my head quickly, thanks mostly to having used the slide rule years ago. I and the other engineer in our company were discussing something, and I would quickly spit out ratios from decibels, or vice-versa, and he asked, "How do you do that so quickly?!" I replied, "You're just a little too young to have used a slide rule, aren't you?" Since then, he has become quite fascinated with slide rules, and has built quite a collection. I don't know how much he actually uses them, but I do use one once in a while, including in my work, partly to sharpen my mind.

Related to the slide rule is the Smith chart which I had to get cozy with when I was working in applications engineering at a VHF/UHF power-transistor manufacturer in the mid-1980's. By then all the engineers in the lab had calculators of course; but the paper Smith chart was still necessary and gave a quick way to calculate matching networks and other things, with a graphical representation you couldn't get with a calculator (and even with today's graphics-intensive calculators smartphone ap.s, and PCs, you still can't get any faster than taking a marker to a laminated paper Smith chart).

The analogy is that using a simpler processor and doing your own address decoding, assembly-language programming, etc. gets the enthusiast, whether hobbyist or professional, a better understanding. Randall Hyde, author of "Write Great Code (No Starch)" has an essay online, "Why Learning Assembly Language Is Still a Good Idea" which has a lot of good comments about how knowledge of assembly helps you write more-efficient high-level-language code. He is an instructor at the University of California who laments the two decades of unwise "assembly-is-dead" teaching that has been in the schools. I came across another editorial—although I don't seem to have bookmarked it—about how understanding RAM makes better programmers too, in this world of "RAM is too cheap to worry about it" attitudes.

The digitally generated graphics in some modern movies is truly amazing. I am especially amazed when they can do water and waves and splashes, or forests and ferns on rocks, with the shadows and perspectives on them changing as the "camera" (not a real camera) moves, and make them look like they were photographed. The math and matrix work done with massive parallelism by the GPUs is staggering. Still, these movies are not necessarily any more enjoyable than a 1930's or 1940's Fred Astaire movie with no special effects.

The online Atari, C64, NES, etc. gaming communities are very active. These people use their modern technology to get online and discuss how to do their own game creations on 1MHz or 1.79MHz 8-bit 6502-based machines. Some younger people who have plenty of initial experience with Wii and similar also get pulled into the older technology and become obsessed with it.

[sark02]

cbmeeks wrote:

sark02 wrote:

http://www.lemon64.com/forum/.

Oh yeah...been an active member there since 22 Oct 2004.

Quote:

I guess for me, I wouldn't design something that would be decades above what the CPU could have handled "back in the day". For example, a GPU with 24 bitplanes, 3D hardware and 40,000 sprites on a 65C02 would be severely out of place.

Yes, I'm with you 100%... Staying somewhat era-appropriate is the key... Otherwise things get absurd

Quote:

I would do something like 32 sprites of 32x32 pixels and all sprites can be on the same scanline and a sprite could be reused like the C64/Amiga.

If I had a blitter, it would be no more than a simple block copy and maybe rotation of tables.

The Atari 8-bits had it right, in my opinion. I only wished it had better sprites. The display list (copper in Amiga speak) is the way to go.

I have nothing to add. Sounds great.

Quote:

For audio, I would do something like a Propeller running 2-4 SID-Cogs.

Weird, but an interesting choice. Why not embed a YM or SID core in the same FPGA that's running video?

[cbmeeks]

sark02 wrote:

Weird, but an interesting choice. Why not embed a YM or SID core in the same FPGA that's running video?

I guess it depends on how much programmable logic you're doing. Is it going to compliment your design or be the primary focus?