Posts by mega65

    Actually, it looks like we might have 512MB of DDR3 RAM available on the final units (but this could change completely), and so the CPU will end up with 32-bit memory mapping space in the end. However, right now we still haven't implemented support for the DDR ram on the Nexys boards, because it is a bit of a pain, and not our highest priority. C65 Bitplanes and 6502 illegal opcodes are much more important that buckets of RAM.

    We think that we can get the licensing sorted out for the C65 ROM, and that is what it will initially ship with.

    I'd also like to resurrect LUnix on the MEGA65 sometime, as much for the fun as anything. Although it does have some cool ideas for relocatable code etc. I did have it working on my real C65, so this shouldn't be too hard to do.

    However, of course, we would like other options for people who want it.

    While GEOS doesn't yet work, we would of course love to make a MEGA65 version of GEOS, possibly based on the C128 version, so that 640 pixels wide is a possibility.

    One OS is being made with MEGA65 support directly in mind: http://www.theace.sk/

    Then there are projects like:

    http://www.6502.org/users/andre/icapos/osa65.html

    and

    http://www.z80.eu/dos65.html

    Also, the MEGA65 Hypervisor already has a very minimal VFAT32 implementation in 6502, and it will offer trap calls to access this. So one could build a very simple shell onto that as well, for a poor-man's operating system.

    Paul.

    We think that we can get the licensing sorted out for the C65 ROM, and that is what it will initially ship with.

    I'd also like to resurrect LUnix on the MEGA65 sometime, as much for the fun as anything. Although it does have some cool ideas for relocatable code etc. I did have it working on my real C65, so this shouldn't be too hard to do.

    However, of course, we would like other options for people who want it.

    While GEOS doesn't yet work, we would of course love to make a MEGA65 version of GEOS, possibly based on the C128 version, so that 640 pixels wide is a possibility.

    One OS is being made with MEGA65 support directly in mind: http://www.theace.sk/

    Then there are projects like:

    http://www.6502.org/users/andre/icapos/osa65.html

    and

    http://www.z80.eu/dos65.html

    Also, the MEGA65 Hypervisor already has a very minimal VFAT32 implementation in 6502, and it will offer trap calls to access this. So one could build a very simple shell onto that as well, for a poor-man's operating system.

    Paul.

    We intend to have a really nice manual shipped with the MEGA65, that will be in the spirit of the C= 8-bit manuals. So, yes, it is likely to be ring-bound, and it is also quite likely to show you how to code a raster split in assembly language (and possibly also in BASIC, since the MEGA65 is just about fast enough to do so).

    Paul.

    We don't currently have GEOS working on the MEGA65, as it never worked on the C65.

    We'd love someone to patch GEOS to work with the MEGA65.

    Paul.

    At the moment we are exploring the full-custom keyboard path with replaceable mechanical Cherry switches, as it will give the nicest experience, and at low quantities, is not much more expensive than any other option -- of course this just goes to show how expensive the other options also are!

    Paul.

    We are continuing to work on it :)

    The reality is that we are a bunch of volunteers working in our spare time, which is limited.

    Volunteers helping out with some tasks would be a great help, as would further donations that can allow us to spend less time worrying about how we might do some task, rather than just paying to get it done.

    Right now, I am working on adding support for 6502 illegal-opcodes, which is quite important.

    I'm also finally finding some time to stick my head in here in the forums, to answer some of your questions ;)

    Paul.

    We are indeed intending to allow the use of 128MB or more of DDR type RAM as the bulk memory expansion.

    The machine also already has 256KB of RAM, of which 128KB is used for the "ROM", but can infact be used as a 2nd 128KB of RAM -- the only problem is that the VIC can't see it, so it is a bit like 128KB chip RAM, and 128KB fast RAM, if we use Amiga terminology.

    This comes back to a final point: on a real C65, the mostly non-existant RAM expansion boards allow the expansion RAM to be used by the VIC, by changing which 128KB it can see. We can't currently do that, and might not ever, because DDR RAM has horrible latency, which makes it really hard to make available in a way that the VIC-IV can see. It certainly isn't something that we will be worrying about for the first release.

    We are thinking about how to make the output resolution / frequency more flexible, however yet to make any firm decisions. The first step is to reduce the size of the core, as we are getting a bit close to filling the FPGA already, then we can see what we have space for.

    We could include a ROM socket, and will think about it, but it will increase the cost of the motherboard. That said, there are some good reasons to include a ROM socket, so the jury is still out on what we will do.

    Joe: Can you poke me by email please?

    MEGA65 does currently do 1920x1200 @ 60Hz. We understand that this is really annoying for many people, and expect that we may move to 1080p @ 50Hz. This is on our TODO list, but is not currently at the top. Fixing 6502 illegal opcode support, and C65 bitplanes are the tasks currently taking my focus.

    Groepaz has it 100% right. We hope to get a couple of folks working on adding the 4502 in the first instance, as the easy first step towards C65 emulation. This will also help people develop software for the MEGA65, by at least having a working fast emulation.

    Thanks for the missing pieces of history there Joe -- very interesting to hear.

    So, all the C65 prototypes that I am aware of have a modified 65CE02 (4502), not a 65816 as the CPU. I had never seen anything about using a 16-bit 6502 variant, although it would have made a lot of sense of course.

    That said, the 4502 does include some 16-bit instructions, so I am not really sure what was going on.

    The main crippling I see in the C65, is that the bitplanes were royally crippled, presumably to prevent competition with the Amiga. It seems that some of the C= engineers tried to overcome this in the 2nd version of the DMAgic chip, which includes some nice bitplane scrolling acceleration.

    However, in terms of where we stand today, the 45GS10 in the MEGA65 runs at 48MHz already, and while not as convenient to program as the 65816 for somethings, it is almost certainly at least as fast as a 65816 for most work loads, if only because we have the higher clock speed on our side.

    As for C128 compatibility for the Chameleon, I must say that I sympathise with Jens on this point: The C128 makes life MUCH harder for this kind of cartridge. Of course this is also a compliment from me to the CMD guys who managed to make the SuperCPU work on the C128. I'd have simply given up, or instead designed a whole new motherboard where you just pull all the C= chips out of your C128 motherboard, and replace the whole thing ;)

    Paul.

    So, with regard to the cartridge port, as Deft has said, we only plan to support C64 cartridges, and not all of the crazier/more complex ones. There is no need for an REU, for example, when we can read from SD card faster than 1MB/second. Also, using a SuperCPU would just result in the machine running (quite a lot) slower.

    As for Z80 support, I appreciate that some people would like this, however, it isn't on our radar at the moment, because we have enough to do to simply create the machine, and the C65 doesn't have a Z80. Also, as mentioned above, it is likely quite possible to get reasonable Z80 emulation using the 48MHz 4510 in the MEGA65. If that isn't the case, then we can worry about finding another solution, but not before we are at the point where you all have MEGA65 computers on your desks.

    Hello,

    We do plan to have sockets for real SIDs for those who want to use them, and let people put what they want in there, although we might be able to source SIDs to pre-populate the boards (and have a good lead on doing this).

    We do already include the best VHDL SID implementation that I could find, and which includes a digital implementation of the filters.

    Sorry, I've been too flat out lately to lurk on furm64.de, so please feel free to cross-post my comments there und bitte entschuldige mich, dass ich nicht oft da bin.

    Paul.

    Hello,

    Regarding the comments about aspect ratio being messed up with down-scalers, we can actually correct for that in the VIC-IV, since everything actually passes through the horizontal hardware scaler, anyway. Thus if you picture is too fat or too skinny, or just in the wrong horizontal position, you can fix it. You can see me do this when the MEGA65 gets its first outing on a 200 inch screen:

    https://www.youtube.com/watch?v=2H2mh8wLXco

    Naturally, we will one day make kickstart allow you to define persistent settings for this sort of thing.

    Paul.

    The issue of being able to write to the disk images has been on the queue for a fair while, but is currently stuck behind these two big items that I am working on:

    1. Get 6502 illegal opcodes working, as it seems a lot of crunchers use them, and this makes lots of stuff not work.
    2. Get C65 bitplane mode working.

    Writing to D81s actually *almost* works. The F011 disk controller emulation tries to do it, at least with the older versions of the C65 ROM. The main problem is that it wrote the 256 bytes incorrectly in the 512 byte sector (the C65 ROM does some strange gymnastics with the 512 byte sector buffer to do this).

    So if someone would like to make a blank D81 image, and then try to write something, and see what mess it makes of the disk, and figure out how the sector write buffering is being mishandled, this will allow me to fix it much more quickly.

    Paul.

    Hello all,

    Regarding the problems with the SD cards, it would be quite helpful if someone were to post me one of the SD cards that is not working, or if you prefer, on a UNIXy kind of OS, use dd to copy out the first 128MB of the SD card, zip it up, and email it to me.

    I can then look at making the partition table code more robust. There is probably just a stupid bug in it somewhere.

    As for whenever a ROM boots to the 80-column MLM monitor instead of C65 BASIC, this is a sign of a definite bug in the FAT file system code, where it incorrectly calculated the location of a cluster on the disk. We need to track down and fix this bug. If anyone would like to go through kickstart_dos.a65 and hunt for it, they will receive a smily face from me if they are successful.

    Paul.

    Hello Ordyne,

    For the moment for various reasons related to laziness, the lack of an IRC client that I actually like on a Mac, we are mostly using Skype and/or Tox (which we have just started using, and is a bit like skype, but open-source, which better fits with our philosophy for the MEGA65).

    If you would like to join the MEGA65 group chat on Tox, send me your Tox ID, and I will try to add you.

    Paul.