Commander X16

2 minutes ago, geek504 said:

Gotcha! But I think we don't have enough VRAM for two 320x200x256 buffers... that's why SlithyMatt did 2 pages with 16 colors each.



I'm going to start some assembly coding and would like to ask: What workflow are you guys following? Which assembler? What steps to get the binary file inside the emulator? etc. I think my way is just too slow...

And if you need more VRAM for other things like sprites, you can decrease the color depth and take up less space with the buffers.

I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.

27 minutes ago, geek504 said:

Gotcha! But I think we don't have enough VRAM for two 320x200x256 buffers... that's why SlithyMatt did 2 pages with 16 colors each.



Edit: DOH! 4bpp = 16 colors... I should go get my coffee...



I'm going to start some assembly coding and would like to ask: What workflow are you guys following? Which assembler? What steps to get the binary file inside the emulator? etc. I think my way is just too slow...

? Yes 2x8bpp does not work. But 2x4bpp works. I would say in any animated form 8bpp is not usable if you use graphics mode and not tile mode. It is simply to much data to draw CPU constrained and also double buffering is not possible.

I do not like the cc65 approach ... I will never do and actually do not want to compile and then link my assembler .. I want to have it in my own hand how everything works. 

I am using C64studio that has ACME assembler included. It creates .prg files, that can be loaded directly into the emulator from the normal operating system. It also enters the typical SYS2062 to run your program at 080E .. ...

@SerErris I was impressed with C64studio as well. For my own Prog8 I'm also trying to make the whole process as smooth as possible so you just point it to a source file and it will compile it to assembly, run the assembler for you with the correct options, turning it into a .prg file and then launching that in the appropriate emulator executable.  It loads and autostarts the program.   From source code edit to running in the emulator in about 1 or 2 seconds on my machine. Works for C64 and CommanderX16.

The above is hotkeyed in my IDE too.  I'm using IntelliJ IDEA.  It's a really nice workflow for me because I'm still developing the compiler itself as well, in the same IDE

On 9/10/2020 at 9:08 PM, geek504 said:

That’s why I am wanting the X16 to be at least 20MHz! We could do so much with that ?

SuperCPUv2
Processor:	WDC 65C816S
Architecture:	8/16-bit
Clock Speed:	20 MHz
Opcodes:	Documented 6510 opcodes only

But you can't make a clock to clock comparison, since the SuperCPU was still bottlenecked to a certain degree by the 1MHz system bus. A hypothetical CX16 DMA card can talk to the Vera registers at 8MHz, while the SuperCPU  can only store to the RAM that the VIC can see at 1MHz. While designing the FPGA for the DMA, pick one with built in 16x16->32 multiply and include a scaled */ register setup for 16x16->32/16->16 operations. That avoids needing all of that tabled operation ROM.

Then alternate between turn off layer 0 and build in layer 0 and turn off layer 1, build in layer 1 Switch layers in VRefresh it should certainly be flicker free. Whatever resolution / color depth cannot support two bitmapped

And you get another level of effort reduction if you animate enemies and their cover onto sprites, since you can animate rising to fire or turning to call for help the same way with palette color games allowing the same animation to have enemies with different features and the higher priority sprite automatically masking whatever is being covered by the door frame, overturned table, etc, so that doesn't have to be blitted.

Indeed, don't get trapped in bitmap-only assumptions. Plenty of dungeon crawlers will rely on the 1024 16x16 tiles available. 15 tiles spans a 320x240 top to bottom, one will be the wall to ceiling corner, the ones below it the wall at that distance, the ones above it the ceiling progressively closer as you go up the screen. In a normal level the ceiling might only have the occasional water stain, so most ceiling tiles in a row duplicated. Similar for a walls and doorways. Then you have a handful of distinctive features for the ceiling or the walls, and those need to have the current version, the next and the previous ... as they come closer maybe multiple tilemaps ... but as you advance or retreat, you only have to update one tile set or tile at a time after a POV move has moved, and you are always updating not-in-display tilemaps, so that is not limited to VBlank.

That DOES NOT move you closer to executing a DOOM wad ... your POV needs to be a stable height above the immediate floor level for those to work ... and it constrains detail that isn't being added by terrain sprites ... but it seems like there's a lot of vertically scaled dungeon crawler game design to be explored in that space. Working on tiles in one layer while displaying the other will give much higher framerates than the equivalent bitmap approach.

17 hours ago, SlithyMatt said:

I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.

 

16 hours ago, SerErris said:

I am using C64studio that has ACME assembler included.

I checked C64studio but in the end I chose cc65 toolchain with Visual Studio Code as my IDE...

2 hours ago, geek504 said:

...in the end I chose cc65 toolchain with Visual Studio Code as my IDE...

I'm on cc65, and VS Code is what I use at work -- I should use it @ home as well, instead of vi.

 

Remember, VS Code is basically just Atom with a Microsoft logo slapped on it. Atom has a huge community of folks writing add-on packages. You can convert those to work on VS Code, but you might as well plug right in to the wider open source community.

Just my 2¢

Does Atom/VS Code allow debugging with breakpoints and stuff? Or is that also not working currently?

Btw: You can completely integrate the emulator into C64 studio to get your workflow to the point of beeing able to automatically compile and run it.

On 9/11/2020 at 1:07 PM, geek504 said:

I checked C64studio but in the end I chose cc65 toolchain with Visual Studio Code as my IDE...

I am looking into that option now but have issues to get it to work.

I have cc65 running, I have Visual Studio Code and I use "cc65 for 6502/65816 machines" by SharpNinja as an expansion. However I cannot get VS Code to build anything. It never understands that it shall use cc65. Instead it asks me to tell VS Code what compiler to use.

Is there anything I need to configure in the workspace for it to work?

On 9/19/2020 at 11:20 AM, SerErris said:

I am looking into that option now but have issues to get it to work.



I have cc65 running, I have Visual Studio Code and I use "cc65 for 6502/65816 machines" by SharpNinja as an expansion. However I cannot get VS Code to build anything. It never understands that it shall use cc65. Instead it asks me to tell VS Code what compiler to use.



Is there anything I need to configure in the workspace for it to work?

Yeah, I am having problems getting SharpNinja extension to work smoothly if at all... it's really old. I am now trying to setup Atom like Matt says below:

On 9/10/2020 at 2:48 PM, SlithyMatt said:

I use the cc65 toolchain (C Compiler, Assembler, Linker, etc.) with Atom as my IDE for syncing with GitHub and getting syntax highlighting, etc.

So I revert to Matt and ask... what's your setup like? Config files, workspace, hotkeys, build process, etc.