MEGA65 – An open-source C65-like 8-bit computer | Hacker News Reader

MEGA65 – An open-source C65-like 8-bit computer

m-e-g-a.org

71 pointsSwellJoe24 comments

That's a strange meta-link. The actual project is at http://mega65.org/.

My first impression is that is seems awesome and like a great deal of fun. The project itself is a bit ... weirdly presented though. There's no mention of exactly what hardware (FPGA and board) is expected, just a link to download the bitstream together with some paid subscription service for getting the bitstream sent to me.

It claims to be open, but the initial impression is that it really doesn't "want" to be open, sort of.

mega65.org is a name that doesn't resolve in DNS at the moment.

http://www.downforeveryoneorjustme.com/mega65.org doesn't seem to agree, that's weird.

Of course it worked (and works) for me, otherwise I wouldn't have found it, and certainly not posted a link here.

Fascinating hi-tech/old-tech mix.

I am currently gathering the parts to build a 1979 vintage Acorn System 1 (http://speleotrove.com/acorn/index.html). I was aiming to use the original chips, although I am struggling to find the IO/RAM INS8154 at a comfortable price - I am currently working my way through some online stores that specialise in old stock without much success. If anyone has a tube of them they no longer want taking up shelf space...!?

Plan B will be to redesign the I/O interface.

Plan C will be to emulate the whole lot in a PIC Microcontroller (including the 6502).

For many years we have FPGA64[1] which as core has been ported to many boards, such as Altera Cyclone-based DE0, DE1, the C-One and Turbo Chameleon to name a few. Not sure about Xilinx-based, but I guess someone might have tried to get it on a Spartan.

[1] http://syntiac.com/fpga64.html

The Turbo Chameleon looks pretty awesome. It's kind of everything you'd want to expand a C64, including an SD card drive, keyboard jack, VGA output (with scan doubler)...but, it also has the ability to act as a C64 (or Amiga, or Spectrum, or Atari 800XL) standalone. Really clever.

I have a C64 with a MSSIAH cartridge, which I've occasionally used for music. But, my SD card drive was destroyed in a tragic vacuum cleaner accident, so I don't have any way to do much other than use MSSIAH on the machine (no way to save or load things).

So, the Turbo Chameleon actually might be sufficient for my needs. And, maybe the FPGA on board can be made to run the C65 emulator, as well. I'd like it if the MSSIAH folks made a port to work on the C65; that'd be awesome. The MSSIAH can already use dual SID chips, but I haven't done the soldering to add a second SID to my C64 yet (and I'm vaguely afraid to do that, since I only have one C64 and no parts machines, so if I break it, it's back to ebay to find one of the few remaining functional units).

The author's blog has some great stuff about development: http://c65gs.blogspot.de/

FPGAs seem to be a great way to bring old machines to live again.

Question here as much I see from the first impression: How much will the system be C64 compatible? Since the C65 was never really released, there exists no real software for it and also the incorporated Basic V10 was incomplete. So the C64 emulation is what really counts. Of course it could be fun to play with a "16bit-6502" processor, but without or limited software the fun is rather limited.

There are a few options for playing with a 16-bit 6502 like the Apple IIGS or the SNES.

Or you could buy Western Design's 'Mensch computer', a full computer built around a variant of the 65c816:

http://www.westerndesigncenter.com/wdc/Mensch_Computer.cfm

Or you could buy a single board machine from them, through Mouser.

Or just buy a 65c816 and breadboard it. The chip is still made and available through Mouser. And can be clocked up to 20mhz.

There's also the 65C02 from Western Design.

OP was talking specifically about 16-bit 6502 variant

This post: http://c65gs.blogspot.de/2015/04/c65gs-at-revision-2015-and-... mentions a "c64 mode" on the c65gs (the basis for this machine.)

It would be awesome if that machine gets used at demoparties.

As far as I can tell, it was _rumored_ to use a 65802 (a 65816 that's pin compatible with a 6502 and therefore is limited to 64k and lacks the abort pin) but actually used a 65CE02 (8 bit with a handful of 16-bit instructions). The 65802 would give you true 16-bit registers but all the instructions and address modes for using other banks are wasted. (phk, phb, plb, jsl, jml, rtl, absolute long, absolute long,x indirect long, indirect long,y)

It's odd, it feels more like conceptual art than a physical project, but there is clearly some real design behind it.

More and more retro electronics do seem to be headed into the realm of art. This particular project is retro-futurism, to all intents and purposes.

Also see Paul Gardner-Stephen's blog entry "Introducing the MEGA65 Retro Computer"

http://c65gs.blogspot.de/2015/04/introducing-mega65-retro-co...

For a working physical machine I would pay ~500 USD. It would be fun to play with.

random question - with a screen width of 320, how do you deal with screen coordinates in 8-bit variables?

You use 16-bit variables.

So, 2 registers and 16-bit math in software? Was this common, or did games find a way around it?

Yes, it was common. Also common was to have entities in your game exist on a grid, and multiply/shift those positions to get screen coordinates, when they were needed.

Sure. Toss up some side bar / status / score thing, and run the game in 8 bit coordinates.

Or, double up on movement, make the game 160 pixels, and just run that way.

The multi-color mode on C64 is 160 pixels, and that got used for a ton of games.

Finally, mixed screen setups. Sprites, high resolution (320) and multi-color (160) all were used concurrently. The coordinates for those could easily be 8 bits, and just operate in regions of the screen.

Well the 6502 didn't have many registers but the CPU and SRAM were of similar speed back then so most of the temporary values were stored in SRAM. Not too long ago I did firmware on an 8-bit processor using the C language. It would support 32/16/8-bit variables. You just have to choose the smallest one possible to be most efficient.

The C64 had one byte at $D010 -- 8 bits, one for each sprite -- that, when set, would add an offset to that sprite's X position, moving it beyond the 256 limit. This would allow the contents of each sprite's X position register to reset at 0, staying within the 8-bit limit.

Reply on news.ycombinator.com