MEGA65 wants you!

Es gibt 47 Antworten in diesem Thema, welches 9.291 mal aufgerufen wurde. Der letzte Beitrag (24. Januar 2022 um 15:19) ist von deft.

  • Hello,

    We are always looking for folks who are willing and able to help out in a variety of ways. Is there any particular type of task that takes your fancy? Poke me off-forum, and we can explore the options. If you send a message to the MEGA65 facebook page, I can give you my direct contact details there.

    Paul.

  • Hey,

    are you also looking for someone without much experience in programming? I learned some basics about C so C++ shouldn't be such a big deal but I won't be as fast as your teammembers.
    I would appreciate if I would be able to join your project.

  • Sure. There is a bunch of stuff that doesn't require extensive programming experience. Some of that could include testing instructions for simple programming examples prepared by others, and generally assisting with documentation etc. Perhaps it is time for us to get our google group back up as a place to coordinate this kind of thing. So, if you like, hop over to:

    Bitte melde dich an, um diesen Link zu sehen.

    And introduce yourself, and we will start from there.

    Paul.

  • As once I had a C65 (for example, the border demo mentioned on Bitte melde dich an, um diesen Link zu sehen. was written by me, and there should also be a plasma demo floating around somewhere), I'd be very interested in participating :) If you have a spare development board, feel free to contact me :)

  • Hi there. Nice work on this machine!
    I used to program demo’s and music in the C64 until 1990 (6502)
    After that I bought an Amiga and programmed Some Nice real time 3D algorithms.
    That was 25 years ago. As a matter of fact I started to program 6502 Again this month.
    Just remembering ‘the gold old days’. Also wondering how I can optimize algirithms and for example 3D on C64. Today I met your project. Hoe Nice! Would like to contribute, start Some programming. but how to start ?

  • Hello,

    Thanks for the nice words.

    Now, for doing 3D on a C64 or on a MEGA65, it will be relatively different between the two. First, on the MEGA65 you have access to modes where it is one byte per pixel, although not strictly linearly addressed, as the screen is made of 8x8 tiles which are encoded using 8x8 = 64 bytes each, to give you a 256 colour display. Thus pixel fiddling is already faster on the MEGA65, before you even consider the clock speed difference. Then the MEGA65 has a hardware multiplier to make your life quite a bit easier. At some point, I will likely also add a hardware divider, but that isn't there yet. There is also a "hardware spreadsheet" facility, that is basically an equation accelerator, which will also in the fullness of time get dividers, and thus make it very easy and fast to calculate 3D pixels.

    But more generally, if you want to play around on the MEGA65, and or contribute tools, games, demos etc, we don't yet have a thorough set of documentation, although there is some, and there are some example programs. In the short term, it really depends on what you want to do. What would you like to do?

    Paul.

  • Also don't forget the DMA engine which helps very fast transfer/fill memory areas with optional features like integer and/or fractional skip rates at source/target, and so much. I also used once a 256 colour video mode with a "setup" as "tiled gfx" in the way that every "pixels" under each other exactly has +8 offset, so then DMA can be used to fill that area with gfx with skip target rate of 8. This for sure needs to set up "video RAM" with 16 bits mode, and with address of "glyps" arranged in the way that the scenario I've described above would apply ... Thus a bit tricky to do, but a "bit more linear" then to handle, even if it's vertically and not horizontally, but at least always +8 then. Or so, hard to explain with my "fantastic" English :)

  • I'm a pixelartist, and can you share a bit more information on what kind of graphics are you looking for and the gfx specs of the machine?

  • Hi RKT,

    The MEGA65 has video modes upto 800x600 and mono, 4-colour, 16-colour and 256-colour video modes.

    You can also change the 256 colour palette using raster interrupts to get more colours overall on the screen. Similarly, you can overlay sprites which can use a different 256 colour palette, so there is scope for more colours.

    At this stage, any graphics, games and/or demos that people would like to develop, would be great for showing off the machine.

    As for one idea: We can also load from SD card at about 500KB - 700KB/sec, so having animated graphics, and even video should be possible, with some care. Basically just make sure that the frame rate x graphics data size is below ~600KB/sec, including audio track. I would happily cook up a video and audio player, if someone was willing to look at producing the material. It should also be possible to bash FFMPEG or similar to produce PNG frames, and then convert them. Not sure how audio conversion would go in that context, but should also be possible. But such a thing would be really nice to have the MEGA65 give a video introduction to itself as a promotional demonstration.

    Paul.

  • That's way more than I expected, pertaining to pixelart, that can be consider no limitations at all more or less.

    Well, I could donate some of my gfx or maybe make some more, but to make an actual game is beyond my skills. If there is a game-designer/coder and a musician somewhere around here maybe we can work on something together. I'll post some of my art here then, maybe someone else is interested and we can try our hand at making a game.

    Bitte melde dich an, um diesen Link zu sehen.

  • Actually, the main limitation is that you have only limited RAM. 800x600 256 colour requires 480,000 bytes -- which is more RAM than the machine has. So you need to use lower resolutions, and/or other tricks, like filling blank areas of a scene with repeated characters or similar.

    Paul.

  • Your artwork looks reaaly nice, btw. Let's see if any coders or others might pop out of the woodwork to help make something interesting. I'll also keep thinking. Maybe poke me an email at Bitte melde dich an, um diesen Link zu sehen. and we can explore a few ideas.

    Paul.

  • Working with limitations is no problem, as it's basically the definition of pixelart. Smart design and some compression techniques can go a long way, but I'm not really sure how much ram is available? I'm reading up on the c65 (which this seems to be based of) and that had 128k?

  • The MEGA65 has 384KB in total, the middle 128KB of which doubles as the C65 ROM.
    Then there is also 32KB of colour RAM, to support the larger display sizes and 16-bit text mode.

  • Bitte melde dich an, um diesen Link zu sehen.: And how much RAM is accessible for the mapper and the DMA?

    It might be a good idea to use the DMA engine for dynamically refreshing some parts of the screen sometimes (even from within a raster IRQ).

    Or the mapper for double or triple buffering (just re-mapping a new frame for the VIC chip by a single command while editing the next one in the background).

  • All the RAM is available to both. You can easily point the screen memory to point anywhere in that space, and even set the logical row length, so you can have a big playfield in memory, and pan around in it in hardware. We've tried to make it easy to do 8-bit kind of things, like platform games.

    Paul.

  • Bitte melde dich an, um diesen Link zu sehen.: I rather meant it as a possible way of exceeding those 128K limitations.

    E.g. the Nexys boards have 16 or 256 MB (maybe even more on newer revisions), but we don't know how much would be available (and how much of that actually accessible in this way) on the final production version of the real MEGA65.

    (Aren't there any problems with the DDR RAM controller any more?)

  • We are not planning to add support for the DDR on the Nexys boards as it is too fiddly to get right, but there will be 8MB of expansion RAM on the MEGA65 computers. That 8MB RAM will be accessible via DMA etc, but at this stage, it will not be usable as video memory. It will also be somewhat slower than the main 384KB RAM, probably with 4 or 5 cycle penalty per access. Of course, if someone wants to make the DDR RAM on the Nexys4 boards work for us, we won't say no.

    Paul.

  • Speaking about the RAM.
    As of reading the 'preliminary manual', I read that the Microcontroler (4510) has the memory mapper inside which can access 1MB of 'real RAM'.
    So I consider this memory mapper as the successor of C128's MMU.
    Then I read about the DMAgic chip which can access the full 8MB (sic!) 'System Map'.
    I consider the DMAgic as being the successor of the DMA-Chip inside C128's REU (1750). Swapping content from the 8MB REU to the 1MB MMU RAM.
    Then again we read about one 'REC ram expander controler' in chapter 1.5.2 C65 System Memory Map.
    So I guess that the C65 is designed to have up to 9MB of 'real ram', where 1MB is 'main memory' and 8 MB are to be considered as REU.
    DMAgic and REC are the chips that manage to transfer data between REU and main memory?
    It's a little bit confusing, but I try to understand the 'logic'.