That machine is not intended to be programmed by the users. It just runs legacy C64 cartridges.

A person could make his own cartridges, but this requires being able to burn EPROMs and build a small board, which most teenagers aren't going to do. Also, you would still have to program in 6510 assembly-language --- you wouldn't get 16-bit registers or an enhanced instruction-set --- not too many teenagers are going to accept such a primitive processor as the 6510 in the year 2018.


I watched about half of that video. This is not interesting to me --- it wouldn't have been interesting to me when I was a teenager either.

That guy is presenting a scripting language that is designed for developing games. The message being presented to the teenagers is that they are too dumb to learn how the hardware works, so they need several layers of software between them and the hardware --- they are told that all they can do is to memorize the code-library functions that their scripting language provides them, but they can never do anything creative themselves.

Personally, I'm not very good at learning to use software written by somebody else. I really prefer to write my own software. I can learn how hardware works --- in the C64 days, everybody was required to learn how to work with the video and music chips --- that was a lot more interesting, and it provided an opportunity to be creative in writing software.

I'm not entirely opposed to code-libraries, so the users don't have to reinvent the wheel every day --- but they can result in all of the games looking alike, because all of the games used the same code-library functions --- they can stifle creativity.


So we need a 64-bit x86 dual-core desktop-computer, and a browser and internet connection, to write a video game such as Ms. Pacman?
Also, you describe a 3D game-engine involving "rich worlds to explore" as being state-of-the-art --- you're describing first-person shooter games, that are essentially mass-murder fantasy.

What I was describing was something similar to the C64 except with 16-bit registers and an enhanced instruction-set (the M65c02A or something like it) --- writing a game within such a system would be fun and challenging --- when people do something creative they feel good about themselves, which is the point.

Now that you mention it, I've seen that part before (or something similar). It looks very impressive but I still feel that the Propeller (Parallax) is about the best option for general purpose video. It's nowhere near as advanced, but too much video power seems a little out of place for a 6502...for me anyway. Perhaps that would be a better fit for an '816.

_________________
Cat; the other white meat.

Hmm... reminds me to something I had seen on GIGA TV back in 2009 or so.

Some gamers commenting screenshots from the latest state of the art game in the style of bored sports reporters who had seen a few games too many.
Suddenly, one of them put an old Atari 2600 on the table... and they couldn't stop playing Pong.
Eventually, one of them shouted: "Hey, this game has sort of a concept !"

For a game-machine to be interesting, the hardware should be exposed to the users --- the idea is that teenagers can have fun programming games --- I was never really into playing games written by other people (the entire time that I owned a C64, I never bought a game-cartridge).

I bought a Super Nintendo with the intention of writing games for it. The 65c816 would have been an easy jump for me as I already knew 65c02 assembly-language. I found out that Nintendo doesn't allow people to write games for the Super Nintendo --- they have a small group of certified professionals write the games --- they don't want a lot of low-quality games floating around that make their machine look bad. I played the Mario game for a while, but got bored with it --- I ended up giving the Super Nintendo to a girl who had a daughter who might like the Mario game more --- a game involving an Italian plumber who rides a green dinosaur named Yoshi is too juvenile for anybody over the age of 12. I would want somewhat more strategic depth in a game.

Nowadays, the only game I play is Go --- I play on KGS against human opponents --- occasionally I will play against a bot, but bots play differently from people so they aren't very good training for human opponents.
Sometimes people cheat by using a computer to generate their moves for them, but I can recognize that they are doing this and usually beat them anyway.
It is very difficult to make a computer play strategically --- most games lack any strategic depth.

To each his own, but I certainly disagree with that statement. I'm in my 40's and I love that game. The whole point for me to play games it to *not* think about anything complicated.

_________________
Cat; the other white meat.

Have you seen any of the intricate hacks performed by some SNES fans?

Mike B.

Just for facts' sake, TheC64 is an ARM-based software emulator that runs .D64 images, not cartridges. There's no classic hardware interfacing at all. Joysticks/keyboard/ext-storage are USB, and video/audio is HDMI.

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

Jail-breaking the Super Nintendo was somewhat beyond my ambition-level --- likely beyond my skill-level too --- I watched some of that youtube video, and the guy seemed to be telling us about self-modifying code in RAM (ugh!).

I'm suggesting a game-machine that comes with an assembler and a Forth, and is well documented --- easy enough to write games for that any teenager could figure it out --- the C64 was in this category.
The C64 had a graphics chip and a music chip. I never delved into the music side of the C64, but many people did figure it out, so it couldn't have been too complicated.
The graphics weren't too complicated. You have a typical frame-buffer that you write into. You have sprites, which are mildly complicated but not too bad. You can interrupt the system partway down the screen to switch into text, which is useful for a display of scores and other information.
6510 assembly-language is pretty easy to figure out, although it does have some depth (Michael Barry's skill level is likely above mine, although with some practice I could get there).
I am learning M65c02A assembly-language now, and it can be figured out --- I'm not using all the features though --- some features, such as the register stacks, I didn't understand the purpose of so I just ignored them.

The goal, I think, should be a game-machine that is easy enough to program that teenagers could learn to do so.
You would want to expose the hardware --- telling people they need multiple layers of software between them and the hardware is bad, and telling them to learn how all this software works is bad --- people can just learn how the hardware works instead, as this is both easier to learn and more interesting.

I have something of a list of desires for such a system, but we should take this to another thread if we want to discuss that further, since a game system and video signals are significantly different topics. Related, but not closely enough to warrant continuing this here, in my opinion.

Okay --- I'll start another thread in General Discussions.

https://www.youtube.com/watch?v=mDr5zHlyLSw&t=3s

Here's my homebrew SNES game. It's more impressive than any of those smw hacks.

I've been working on my own video chip for a few months now and finally had success today!




It outputs a 640x480 60 Hz signal, and can generate 320x240 graphics with 6-bit color (BGR222) or 80x30 text with 16-color foreground and background colors and a font read from high RAM (it is designed for 128K of VRAM with a sparse memory mapping like the Apple II). I'm going to also be adding PS/2 keyboard (and possibly mouse) support onto the chip as well, maybe hardware SPI if I'm feeling lucky.

The code is in VHDL and currently runs on a Max V dev board with a 5M570ZF256 with 570 logic elements, of which I'm using about 25% right now. It will probably be back up around 30-35% once I disable the test pattern and re-enable actual VRAM reads, but that still leaves plenty left over to cram in more functionality. My only constraint is that the final design needs to fit into one of the QFP models so that I can actually solder it; for the most part this just means I'm limited to 144 pins, and since I'm only at 48 or so now I should be fine.

The chip is designed to eventually slot into a future 65816 SBC and share the video ram banks with the processor. Since all I have now is my 6502 SBC I'm going to rig up something with a big AVR chip (like a 644, which I have already) to let the 6502 SBC talk to it over its VIA ports. It won't be fast, but it'll get me decent keyboard and text mode support at least, and let me debug the VHDL before building the next SBC.

Looks good, Josh! I can well imagine this is an exciting milestone.

I'm a little curious about how an '816 would share the video ram banks, but I expect these details will become clear later. You're intending to implement both bit-mapped and character mapped modes, is that right?

Does your 6502 SBC run on 3 volts or 5? Will there be issues interfacing with the FPGA board?

-- Jeff

ps- on this forum you can attach images with your post. You'll probably find this more convenient than hosting them on a third-party site.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

For sharing the RAM I am going to have the video RAM banks on physically separate chips, and any attempts by the '816 to access those banks will temporarily slow the CPU until there is a free cycle (probably using RDY). I'm also providing a vertical blanking signal and interrupt so the CPU can try to do most of its work during the downtime between frames, but there are some free VRAM cycles even during frame draws. Text mode doesn't fetch much data; every 8 pixels fetches a font byte, and every 16 lines it also fetches the character code and attributes bytes. For 320 mode every other line is blank (240 lines out of 480) so there's some spare ram cycles there too.



Yep, the implementation is actually already done, and looks good in simulation, but until I can get something rigged up to actually load a font into RAM I can't really test text mode.



The plan is to go 3.3V to make it easier to interface to the Max V, and it's also a lot easier to find larger RAM sizes in 3.3V these days. I know this will limit me to 8 MHz but I'm willing to make the trade-off.



My blog uploads them to S3 so I just reused the links I already had

Great work. But I think you mean 60 Hz.

_________________
Cat; the other white meat.