6502.org

This thread is a fork of this thread: viewtopic.php?f=10&t=1789&p=59348#p59348
Over there I was discussing the design of a game machine. I said: That actually makes more sense. The C64 only ran at 1 Mhz., so simulating it with an ARM is possible.

I never heard of .D64 images. These are just binary files representing C64 cartridges? That is probably illegal --- copyright infringement --- but I doubt that the owners of those cartridges care enough to do anything about it, as they haven't made any money on the cartridges in decades.

Can that PIC chip (PIC24FJ256DA210) work with HDMI? I don't know anything about HDMI. That PIC chip is likely fast enough to simulate the 1 Mhz. C64 too.

Is it okay to discuss a PIC chip on the 6502 forum? Maybe this whole discussion should be moved to the anycpu forum where, by definition, any cpu can be discussed.
It might be realistic to build a game-machine on the 65c816, M65c02A, or some other 16-bit derivative of the 65c02 --- even that is somewhat unlikely though --- that PIC chip is pretty impressive compared to a 65c816 etc..

I'm not opposed to the Mario game --- I actually spent several months playing the game --- there are worse ways to waste time!

I'm mostly only opposed to games that promote violence and/or crime --- Mario doesn't do this.

In our discussion of a game-machine design, we should assume that somebody is going to try to get Mario and Yoshi, or at least something roughly comparable, to run.
I watched part of that video by the guy reverse-engineering the Mario game on the Super Nintendo, and the guy seemed to be describing self-modifying code in RAM. I think they had I/O ports mapped to the operands of instructions. That is pretty wild! This seems to imply that the 65c816 was barely capable of running Mario and such tricks were needed to shave off every clock cycle possible. I would hope that a modern game-machine, such as based on that PIC chip, would be capable of running a program such as Mario using structured-programming and all that good stuff.
I'm expecting the machine to be programmed in Forth or Pascal, or both --- not all that many teenagers want to delve into assembly-language.

A .D64 is a C64 disk image, as I understand it, not a cartridge dump. They still have the same legal issues, but I don't actually know much about that area.


In the other thread, I alluded to what I'd like out of a games system, but now that I think about it, I seem to have most of the system planned out already. I came up with this in the context of a portable system, though. A bench-bound console may call for a different approach. I may try to implement this in the future, but that remains to be seen. Also, this is just my idea of a good games machine. Yours may differ.
320x200 graphics, with 256 programmable colours and a text generator.
Some kind of PSG(Comparable to the SID, or better). Sampled audio capability is preferable, but not strictly necessary.
8-button controller(built-in or otherwise).
Cartridge media, and some kind of serial link for direct binary upload.

- The graphics would require 64,000 bytes for the display bitmap(bytemap?), and then 768 bytes on top of that for the palette(colour) data. 768 bytes are left over from this. Perhaps this could be used as register locations for other graphics features. This would require something more capable than the 65C02, because it can't address enough memory for that and a program without paging. The 65816 would be my choice. Given that it can be clocked to 10MHz within its specs, I would say that even if the SNES is incapable of running Mario without tricks, this would likely be able to run a similar title without such things, just due to the sheer speed increase. It is difficult to find existing hardware that doesn't exceed this by a substantial amount, which could be an advantage or a disadvantage, depending on how you look at it.
- For the sound, it would be nice to be able to do more than just a SID, to have more voices, generate sine waves, and apply filters to each individual voice if desired, but this would call for some custom hardware. Either an FPGA or CPLD would be necessary for that. Such hardware could make implementing sampled audio substantially easier as well. There are pre-existing emulations of the SID, such as the SIDCog, which runs on a Parallax Propeller. Using one of those would simplify such a project.
- For the cartridges, I would use some kind of serial, much like Dodo has done, in order to keep the size of the cartridge down. My choice is SPI, because Daryl Rictor has made the 65SPI, which is an HDL SPI master for the 65xx bus. If that is used, I think it would be sensible to use the same type of serial for the dev link, if possible, to keep from needing to implement another interface.
- The button count of the controllers includes the directional controls, so there would be a d-pad(four directions) and four other buttons. I would want to avoid labelling any of them "Start" or "Select" because those buttons do not seem to be used much at all. Better to leave them uncommitted in name as well as function, in my opinion.
- I would also like plenty of uncommitted RAM, and a built-in library for basic functions like reading/writing cartridges, doing various things on the display, and basic audio functions. Being able to program it with minimal extra hardware sounds very nice as well.

PIC32MZ DA family looks interesting.

PIC32MZ2064DAG176-I/2J is 19.16€ at Mouser.
200MHz MIPS32 core, integrated graphics controller, integrated GPU, integrated 32MB of DDR2 RAM.

Microchip DM320010 starter kit for PIC32MZ2064DA is 110.86€ at Mouser.

That seems realistic.
Sprites like in the C64 might be useful, although not necessary if you have a pretty fast processor.

Sprites can be somewhat limiting in what they provide. They were introduced to support games such as Ms. Pacman or Centipede in which you have a few objects (Ms. Pacman and the ghosts, or in Centipede the laser-cannon, the centipede segments and the spider), and these objects don't change their shape at all (or very little; Ms. Pacman would alternate between open-mouth and close-mouth, and the spider would flap its legs up and down).
Sprites were introduced at the time of the 1 or 2 Mhz. 6502, or the 2 or 4 Mhz. Z80. In those days, a game such as Ms. Pacman or Centipede really pushed the limits of the processor.
I doubt that sprites would be very useful for the Mario game though. Mario and Yoshi aren't such simple objects as Ms. Pacman or the spider --- they can't really be represented by a sprite that floats across the screen.
I agree that you need a processor that can support multiple 64KB segments easily. This rules out both the 65c02 and that PIC chip. I think that PIC chip is more oriented toward supporting a GUI than it is to being the basis for a game-machine (the device-overview says: "Ideal for Graphical interface applications"). It has much higher resolution than what you are describing, but is much more limited in the use of color --- you said 320x200 (40x25 text), which is the same as the C64, but you said 256 colors which is a lot more than the C64 had --- the PIC chip has 640x480 (80x60 text), which is makes it a business-machine not a game-machine.
The PIC chip is very impressive! I don't think it is a good choice for a game-machine though --- I doubt that MicroChip cares about game-machines anyway (because teenagers don't have any money).

Is there a soft-core version of the 65c816? I would expect the game-machine to use an FPGA so that sound, especially speech-synthesis, can have hardware support --- an 8-bit processor with hardware support for sound should be able to out-perform an ARM Cortex that does everything in software --- that is the advantage of the FPGA, to boost the speed of highly repetitive processing that drags down a system when done in software.
People seem to like speech synthesis --- look at the popularity of the Furby, etc. --- people want to pretend that their robot has emotions, so the robot either needs facial expressions or speech (speech is realistic).

Also, an FPGA could provide a somewhat improved version of the 65c816. For example, the M65c02A has an OSX prebyte that causes instructions that normally use S to use X instead. This allows PHA PLA etc. to work using X as the stack-pointer. Also, the powerful addressing-modes available for S can be used with X also. This would allow Forth to use X as the data-stack and S as the return-stack. Perhaps that unused WDM instruction could be put to use as OSX --- William Mensch doesn't like prebytes because he thinks they bloat the machine-code (this was a lot of people's complaint against the MC6809) --- one prebyte wouldn't be so bad though!

I would think that teenagers could learn 65c816 assembly-language --- you have two stacks, X and S, and you have two registers A and Y --- shouldn't be a brain-buster!

A Forth system would either support local variables, or support >R data, but it can't support both because there is no register available for use as the local-frame pointer. I would go with local variables, and forget about >R etc. that tend to result in hard-to-read source-code --- >R were introduced to Forth by Charles Moore in the 1970s as a somewhat crude step toward local variables --- actual local variables would be better.

Given the OSX prebyte, I could write a pretty powerful Forth system for the 65c816!
I think there already are C or Pascal compilers available for the 65c816 for people who don't like Forth.

Writing code for PIC32MZ certainly isn't for teenagers, but maybe the chip would be fast enough for emulating a 6502.
From the datasheet, I'm starting to think that the on chip graphics controller is meant to drive a LCD directly,
but not to generate DVI\HDMI for a monitor (so this might require some additional hardware).

Personally, I would prefer a real 6502 and 74HCT TTL chips instead of PICs and\or CPLDs\FPGAs,
but when considering the price of the PCB space a 6502 computer plus more than a handful of TTL chips would be going to take...

...I think it would be hard to beat the 19€ price of that PIC (goes down to 14€ when ordering 100 chips).

;---

Speaking of TTL chips, Marcel van Kervinck's Gigatron project is quite impressive:
custom TTL CPU (34 TTL chips) which is generating a VGA picture.

Yes. It's not free, but WDC supplies it along with support to develop your own ASICs or FPGAs using it. I understand licensing fees are less the 1% of ARM's.
Locals are definitely more readable. Last fall, I started developing a system for locals, including local arrays (which ANS does not provide for), for my '816 Forth. I had to put it on the back burner; but I do intend to get back to it. It does not interfere with >R and R>. You can have both.

I'd be inclined to just use the off-the-shelf '816 and put the extra functionality in one or more peripheral chips. I don't know how well a sound device could be done in programmable logic, but I'm sure it's possible.

I was actually talking about the PIC24FJ256DA210 which is a PIC24, not a PIC32MZ.
A PIC32 is very over-powered for a game-machine. Also, as I said, these are high-resolution (640x480) for GUI --- for games, we had been talking about 320x200 and 256 colors.

Is it legal to come out with a "clean-room implementation" FPGA that is compatible with somebody's processor? In this case, with WDC's 65c816? Or does that violate a patent law, or some such thing? It seems like it should be illegal --- basically stealing somebody else's R&D.

Stephen Pelc brags about doing a clean-room implementation of the RTX2000: http://www.mpeforth.com/rtx.htm
So he obtained ownership of the RTX2000 without paying for it. I think Intersil is out of business though, so they no longer care.
WDC is still in business and presumably do still care about ownership of the 65c816.

The 65c816 would be a lot better for Forth if it had the OSX prebyte so instructions that normally use S would use X --- that is one good thing about the M65c02A.

The existence of all the 'C02 derivatives I've seen seem to imply that if it is illegal, WDC hasn't seen fit to see about taking action about it.
I suspect that it wouldn't be illegal, and that WDC wouldn't go after you if it was fairly clear that you hadn't used the soft core they sell. I don't think there's anything particularly wrong about reading their specs and making something that meets that. But I'm not a lawyer; I could be wrong.

Why not simply use the existing '816? Even without the extra opcode, a Forth like you describe is still possible. A little more work would be involved, but it's still possible. And you're not risking any kind of legal trouble that way.

I AM NOT A LAWYER , I am merely stating my somewhat informed opinion / understanding.

As far as I am aware, making something "compatible" with an original specification in a clean-room manner (i.e. without obtaining or reverse-engineering anything from the original product) is entirely legal. I believe Sun sued Microsoft over making their own JVM or some such, and microsoft won the case - they had even used some of Sun's original header files, but the court found that header files define an "interface" not executable code and are therefore not copyrightable.

This boils down to the fact that copyright infringement implies copying. You have not infringed anything if you have not copied a copyrighted work, and abstract things like interfaces and rules are not copyrightable.

Patents, however, are a different matter. If you use an algorithm or process that is patented, the patent holder can get if you havn't licensed the patent rights from them. I should think that, by now, any patents on 6502-related hardware would have expired since patents usually only last 20-30 years (unlike copyright which is often the lifetime of the author plus 70 years, depending on jurisdiction), but don't quote me on that.

Posted on the CPU Cores page of Rob Finch's web site we also have the bc65816. It's described as untested, but if the need arose perhaps Rob (or, with his blessing, another person) could finish the job.
As a point of reference, the Zilog Z80 reused the specifications of all the the 8080 instructions. But they created new mnemonics when they defined the assembler syntax (which is a copyright issue, AIUI).
It's worth remembering the 65816's Direct Register can be used as a third index register. I don't necessarily advocate this, as there are substantial drawbacks. But in some scenarios the upside might far outweigh the downside. Beyond simply having a third index register, you also get some amazing address modes which could prove pivotal.

-- Jeff

(Thanks for restarting this discussion in a new thread Hugh!)

As noted above, for a design as old as the 6502, and even the '816, and even the first ARM, there can no longer be any protection from patents. There could be protection on the name, as a trademark, but that wouldn't be the interesting thing anyway. There isn't protection on the masks by now, either, so you're free to copy the (old) layout if you like - not that it would be the best way to proceed. (My feeling is that IP protection really isn't that hard to understand, but possibly that's a feeling which comes from experience. You just have to bear in mind the four or five different categories of things which are protected, and understand what it is they protect and how the protection expires. There is no category of thing which is in principle protected forever: copyright protection is headed in that direction, but copyright is not usually the protection that's applicable to discussions on hardware. You'll certainly be confused if you don't manage to distinguish copyright, mask copyright, patents, design patents, and trademarks.)

The difficulty with a new 816 is that below the surface of the instruction set and the programmer's model it has a surprising number of nooks and crannies, which Bruce has made an effort to document. WDC's datasheet revision history shows the difficulty of saying exactly what the chip does. If you wanted to be completely compatible with a wealth of pre-existing software, that would make a recreation quite painful to finish. But an in-the-spirit-of the '816 mightn't be so bad. I haven't looked at Rob's core.

In case this hasn't been mentioned....

Simulating a 1 MHz computer with a much faster processor or micro-controller isn't at simple as it seems. Even my 3.5 GHz, 4 core PC can't accurately reproduce a machine such as the C64. In fact, it's wildly known that the top end emulators (like VICE) cannot accurately do it. VICE even has two version for the C64. One for "good enough mode" and one for "more accurate mode" and the "more accurate mode" still sputters and has issues on my modern PC.

And don't get me started on the SID. ARM's, PC's, etc. can get a real good emulation going, but they can never reproduce the analog nature of the SID.