MEGA65 FORUM

MEGA65 wants you!

append delete Deft

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

Reply RSS

Replies

append delete #26. Urias Nooteboom

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 ?

append delete #27. gardners

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.

append delete #28. LGB

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

append delete #29. RKT

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?

append delete #30. gardners

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.

append delete #31. RKT

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

append delete #32. gardners

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.

append delete #33. gardners

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 paul@m-e-g-a.org and we can explore a few ideas.

Paul.

append delete #34. RKT

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?

append delete #35. gardners

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.

append delete #36. rosettif

@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).

append delete #37. gardners

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.

append delete #38. rosettif

@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?)

append delete #39. gardners

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.

append delete #40. Freddy Champagne

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

#41. rosettif

This post was deleted by its owner

append delete #42. rosettif

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

append delete #43. Urias

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)

append delete #44. gardners

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.

append delete #45. Urias

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)

append delete #46. gardners

Sounds all good. Still looking forward to see the polygon renderer when you are ready to share it :)

append delete #47. Jody Huebner

Our group can't wait to program games for the mega65 in 800x600, 256 color, up to 1 meg, in 64k banks. It will be a real pleasure transfering our games, and utility software into this renewed system, if its 6502 it will be easy, and if the cartridge port works the same as a 1750 or 1764, were in business.

President JAH, Excalibur 64/Amiga user group wisconsin, via Compute! Magazine

looking for an Amiga PAWS if any one knows of its existance

Windjammerhobbies@gmail.com

append delete #48. gardners

Hi Jody,

This sounds great.

The cartridge port works very similarly as for a C64, and most C64 cartridges will work. For expansion memory, the MEGA65 will have 8MB of ~10MHz expansion RAM in the final version, but in the meantime, there is 384KB of main memory, that the VIC-IV and CPU can both access, as well as being able to access the SD card at between 700KB/sec and 1.3MB/sec already.

The CPU is an enhanced 6502, with memory banking commands, and also some instructions for directly accessing any byte of memory without having to change the memory bank layout, which helps keep code small and fast.

Basically if you have questions, or need information, then poke us, and we will do our best to support you, as we are also excited about the prospect of MEGA65 games.

Paul.

Reply

(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Deft, gardners, Ralph Egas