8bitworkshop - online IDE now supports NES

I found this to be pretty impressive:
https://8bitworkshop.com/

I first saw it when it supported Atari 2600 only, and now it also supports NES, some (I think 8080-based) arcade hardware, Apple ][, and even custom Verilog machines. I've never seen such an IDE for Verilog before, that provides audio and video output.

Plenty of NES example code is there, in C and assembly.

edit: Project is GPL3, and may be run locally.
https://github.com/sehugg/8bitworkshop

Wow! I saw this come up in my Twitter or RSS feeds a few days ago and bookmarked it. This is really quite impressive though. Not that it would replace my local setup, but maybe I can get some more local gamedevs interested in retro-dev.

That looks really impressive. Is it really possible to develop a game in C? What about the function call stack frame performance hits, etc.? How do you break a C program up into swappable banks? I guess I'm really asking, is this a toy or can you really do something with this?

This IDE will let you do C or assembly, some of the examples are in C, some aren't. This thing seems to provide the cc65 toolchain which will do either.

Whether you can make a game in C is a different topic/question, but yes you can, and lots of people have at this point. It seems to have used shiru's neslib as a starting point. Banking is possible too.

I'm not really sure how this IDE handles banking... it seems to have a bankswitching example, but doesn't look like it provides access to a CFG file to set it up? There's a "memory map" view which looks kinda like a CFG file but I can't figure out how to edit it. Doesn't seem to have any documentation?

You have to pay for it: https://www.amazon.com/gp/product/10759 ... e2c322d80a

Yes it is.


When writing NES games in C, you're better off using only global variables. This way, you don't need to have a stack for parameters and local variables. Otherwise, yes, the performance can suffer immensely.
(You can simulate function calls with parameters by declaring macros, so your code still looks clean.)


In the same way you do this in Assembly. The cc65 compiler lets you put code and data into segments by using #pragma and then code-name, rodata-name, bss-name:
https://cc65.github.io/doc/cc65.html#s7

I recognize some of those graphics.

This is wayyyy cool, I remember running across those books on Amazon, definitely interested.

I also instantly recognized the font (and the entire order of the chr sheet.)

It looks like the project is GPL3, and can be run locally if needed:
https://github.com/sehugg/8bitworkshop

I've noticed when making changes (in the Verilog compiler at least) if the video starts getting jittery, hitting the start/stop recording button clears it up.

yes, cc65 takes 1 page(256 bytes at least) for running stack to call functions, but i insist on c environment.

also u can define globle ver. in zero-page, and extern them in c file. then u can save the memory. but be careful, cc65 also use zero-page as its own system low-level funcs and bootloader usage. DO NOT ACCESS OVER $60(Hex), in another word, u can use 96 bytes of ram space in zero-page freely

You can set this up to use far less than 256 bytes. 64 bytes is probably more than adequate for most purposes.

Adjusting it for this 8bitworkshop IDE thing might be impossible though, unfortunately.


The cc65 runtime takes 26 bytes of zeropage. I don't know where you get the number 96 from, because there should be 240 bytes free. On top of this, you should not be using raw hex addresses for your variables. Reserve them in the ZEROPAGE segment, and the linker will ensure they don't overlap with anything else allocated there.

;; FIXME: optimize zeropage usage

SCREEN_PTR = $62 ;2
CRAM_PTR = $64 ;2
CHARCOLOR = $66
BGCOLOR = $67
RVS = $68
CURS_X = $69
CURS_Y = $6a

tickcount = $6b ;2

VBLANK_FLAG = $70

ringbuff = $0200
ringwrite = $71
ringread = $72
ringcount = $73

ppuhi = $74
ppulo = $75
ppuval = $76

screenrows = (30-1)
charsperline = 32
xsize = charsperline

cc65 normally use $62 to $80 for system usage, and they are stored at fixed address.
only below $62 here is safe to use, so i suggest not to over $60. and over $80, there maybe exist other stack

I strongly recommend that you stop hard-coding addresses and use reservations instead:


As for what you're doing with $80-$FF I have no idea what you've set up there, but that's not a normal CC65 thing. You are doing something custom that has reserved that, I guess.

I just noticed there's an example that shows how to include a CFG (guess what it's based on):
https://8bitworkshop.com/projects/?n=nes/NES-ca65-example
other projects not listed inside the IDE: https://8bitworkshop.com/projects/

I bought that book. Will comment on it after I read it.

Ok, I read the book. cc65 with neslib.

Here's my opinion. Probably too much technical info and not enough explanation on actual code. A few incorrect details, but mostly fairly in depth, and 99% correct information.

Uses the CLBR fork of neslib (Calima) but doesn't credit her contribution, nor link her github.

Some things it points you in a good direction, like using famitracker and famitone2, but doesn't explain any of how to use these tools (except for the c code to run them). Doesn't mention text2data, for example.

Uses some slow code examples. Locals. Ints where u char would suffice. Arrays of structs. Bitfields. String.h functions.

I'm a little unclear how it manages linker cfg files, I didn't actually look at the example codes yet. Though it has some kind of NESASM style directives added to define mapper and bank sizes.

It seems to have MMC3 details and examples, including IRQs and bank switching. I need to look at the actual code to figure out what it's actually doing in the IRQ code.

It has a section on ASM. Uses DASM assembler.

Some of the example code is fairly impressive. One looks like Galaga, another has a randomly generated map.

I would like to know how a newcomer would view this book and IDE. I'm already familiar with cc65 and neslib, so I can follow it fine.

Are bitfields slow? I'm using them and the generated assembly code is pretty clean:

Example:

It's not terrible (it probably would be if it was straddling a byte boundary though), but the 6502 part of my brain is like "NO!!" when viewing that. Those 6 LSRs putting a bit into D0 are completely unnecessary, ideally it would do AND #$20 instead, to test D5. Plus, if it really needed the result in D0, 4 ROLs would have been faster than 6 LSRs.

Would be cool if there was away to add that into the optimizer somehow, but I have no idea how to do that.

Do NOT use bitfields in cc65 if you want any semblence of speed or code size. big big big huge no no.

-Thom