Hello, Guest the thread was called861 times and contains 22 replays

last post from mega65 at the

MEGA65 wants you!

  • Hi everybody,

    the machine is progressing well as you have seen on facebook and the MEGA homepage, still we could use some help to speed things up and/or do better and more. At the moment we are looking for a talented graphics artist. Oh, and coders (VHDL, 6502, C++) are always welcome. If you might be interested don't hesitate to contact us here, over mega.ms or via mega65.org. Thank you in advance!

    cheers
    Deft

  • 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 :)

  • 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.

    https://imgur.com/a/uNGpEYv

  • @gardners: 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).

  • @gardners: 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'.

  • @Freddy Champagne: It has nothing to do with the C128.

    In the C65, the 4510 was designed to handle a 1MB address space via bank switching: although it can access only 64K directly, but its two 32K segments can be mapped to anywhere within the 1MB individually (by the processor itself). The space contains both RAM and ROM which is 256K in the prototype machines (128K RAM + 128K ROM) and above which an optional 512K RAM expansion was planned.

    The DMAgic is more capable than the REU and its address space also involves the system RAM (so the first 1MB is common). It can handle up to 8MB by design. (So thus it is more similar to the DMA controller in the C64DTV which has got 2MB built in that contains the first 64K, too.)

    In the MEGA65, both the mapper and the DMAgic are further expanded by Paul to work even up to a 32-bit address space.

  • Hi Paul,

    Thank you for your answer.
    After reading some documents I thought the C65 contains:
    - several bitplanes (like Amiga has). like 4 bitplanes combine 16 colours from a palette.
    I understand you put in the Mega65 a different mode: 1 byte per pixel?

    For me the old one is okay, using tables and fast code give magic :-)
    Perhaps your additions gives new possibilities.

    - Did you add a multiply routine ?
    Can be useful for 16 bit. However I coded a multiplier, 7 x 7 bit / 256 on 6502
    that take same or less clock ticks than Amiga/68000 does with MULU/MULS function.
    It's 14 lines of code and a short 8 bit sine table. I don't know if this trick/method already is used, but it just came up in mind and I made it.

    - The DMAgic is very useful I think for cleaning and copying bitplanes, etc.
    The addition of proportions and a counter for scaling (I understand?) is also nice!

    - Also the addition of 16 bit DA converters is welcome I think!

    - But how do you see all the additions considering the original c65 ?
    Mega 65 programs will not be compatible anymore on c65 ?
    Or is there an original c65 mode ;-)

    - I was thinking of several things. Perhaps making and sharing some fast open-source routines, like division, sin, arcsin, sqrt, etc. (who contributes?)
    And simple routines for drawing lines, filled planes by coordinates,etc.

    For now I want to finish programming some small 3d objects on the C64 (sorry I use Vice with original speed). It will be 50 fps or at least 25 fps I guess, rendering small +/- 6-10 plane objects in real time. If it's ready I can show you. Nice work for the lazy sundays at the moment.

    Sure the objects can be a lot bigger and complicated on the Mega65

    Love 8 bit,

    Urias (Holland)

  • Hello Urias,

    Thanks for your reply (and also for your email). A few answers below:

    1. The MEGA65 supports almost all C65 modes and features, including the bitplanes, although in my view, the C65's bitplanes are too limited to be really useful for anything, primarily because scrolling them requires moving a lot of memory around.

    2. The MEGA65 supports new enhanced text modes, that includes both 16 colour 16x8 and 256 colour 8x8 character tiles. For both of those which require 64 bytes per character, you can have up to 2,048 characters, so it is quite easy to make large scrolling playfields this way. This will be great for platformers and similar games, and also helps save a LOT of RAM, when you tend to have large empty or repetitive parts of the screen. You can even use the hardware character kerning feature to allow characters to not be forced to the 8 pixel horizontal columns, giving some extra flexibility.

    3. There is a hardware 25x18 bit multiplier that gives a 48 bit output. This takes only a few cycles. Basically you don't have to wait at 40MHz, because it is finished before you can read the first result byte. There will also be a "hardware spreadsheet" that can be used to implement simple equations, without having to copy operands around the place, making things potentially much faster -- faster even than many 32 bit processors can calculate such equations, due to the removal of the need to shuffle values around the place.

    4. There is a C64 mode, and a C65 mode, as well as the new MEGA65 features.

    5. Yes, a library of routines for doing interesting things on the MEGA65 and/or C65 would be very interesting and useful. Bonus points if you make the routines with CC65 wrappers, so that the library can also be used from C.

    6. The 3D renderer sounds very nice, and I would certainly like to see it when you are ready to share it. Yes, it will be able to perform MUCH faster on the MEGA65 for various reasons. I would be very happy to help you optimise it for the MEGA65, so that we can show off what the MEGA65 is capable of in this area.

    Keep up the good work!

    Paul.

  • Thank you for your Answer. I admire your ability to (re)make a whole computer & more.
    Incredible & amazing job!

    1) 2) A new graphic mode is a Nice addition! However, in Some cases bitplane mode ‘ll be useful, I think. For example; one bitplane is less data. (where only using main CPU). Scrolling memory scrolls 8 bits at a time, one instruction. Tricks can be Made. But I agree, when using a coprocessor and more memory; more possibilities!
    3) Very Nice addition! I am getting tired of programming multiply routines, take lots of code & time.
    4) beautiful, multiple modes!
    5) 6)
    Still programming. Now polygon algorithm almost finished. Took me days to optimise.
    It draws a simple 4 point polygon, filled, single selectable colour.
    Very small polygon of 40 pixels high takes approxemetly 100 rasterlines of time.
    Next step is 3D calculating an object. So f.e. a very small cube (about 1 sprite) ‘ll be possible at 50 fps. (C64, vice normal speed)