PC32 to DC32

[newtechstudio]

Hi everyone, my name is Julian. I made a computer language called PC32(which you can find at dscf.co.uk) and am looking to see if people are interested in the Dreamcast version tentatively named DC32.

The PC32 environment is a derivative of the FORTH language that uses color to encode extra information in the program source, however, its real strength lies in the fact that its so small and fast that the entire compiler+editor+assembler can fit in a few dozen Ks of ram.

By abusing this feature I've been able to port it to other systems and have a compiler running inside the hardware itself, so you can see where am going, I'd like to know if there's community interest in having a compiler inside the Dreamcast itself, making possible to make and test games with only a keyboard needed.

For example this here is an older version of the compiler that runs live on the Nintendo DS


Visually speaking the language fits the DC like a glove, it targets standard 640x480 VGA natively while its 3D capabilities are also very much like those of the Dreamcast targetting a fixed pipeline with vertex submission.
What's even better is that the assembly language of the Dreamcast is practically an older version of the modern ARM THUMB assembly which I am really familiar with as both the NDS and the rp2040 run this architecture so porting efforts should be minimized.


I'll be completely honest, I am looking for sponsorships or maybe a small kickstarter campaign in order to bring the language and a game made in it, with full source code available for free, as a digital download or as a physical CD in order to fund further development.

The game am working on currently is called U.F.O. Girlfriend ULA, a fully 3d shmup using the language. This is the first time I work on a larger game but the development of the engine has been a breeze due to the iterative nature of the language.
Anyways, here's a video of what am talking about:
https://youtu.be/oPuTBlQqo1I

It says "in 5 blocks" which translates to about 160 lines of code and its (almost) a fully fledged shoot'em up engine that runs at native speeds and compiles before you lift up your finger from the key.

I want to bring this to the community so there's a new way to program the DC that is also fun, powerful and expressive enough to bring out the full potential of the hardware, even by a single dev, with just the Dreamcast, a vga monitor and a keyboard.

I'd love to hear what you guys think about my pitch, cheers.
Julian.

[Ian Micheal]

Very interesting project not sure i fully get how you use it on a Dreamcast and if you have to type in a game each time or you can load up script to load in the compiler.. By what you saying could have a game work loaded from the vmu lol

[newtechstudio]

Very interesting project not sure i fully get how you use it on a Dreamcast and if you have to type in a game each time or you can load up script to load in the compiler.. By what you saying could have a game work loaded from the vmu lol

Thanks Ian! You store the source on some media be it the slower VMU(using compressed blocks) or an SDcard with the adapter, then test it on your own console and finally you produce the binaries and the final CDI in-console and save it either via serial or the SD to a computer to distribution.
One big feature of the language is that you never lose code due to crashing so you turn on the console and pick up right where you left down to the cursor position.
Something cool and totally possible to implement would be a games browser ala pico8 so you wouldnt even need an SD adapter, just connect to your computer via the network to save and share with others.

[Anthony817]

Wow, gonna level with you here, that game demo looks phenomenal for such lightweight code! Very cool project and just seeing that demo shows what sorts of things is possible with this. With what you said about porting other ARM based projects over sounds really compelling. I always thought one day would be cool to see early IOS games decompiled and ported over to DC since they also used the same graphics chip of the PVR2 as DC so there were so many visually impressive games on them. Anything from maybe 2011 and under should be able to be within the DC's capabilities. With the advent of things like AI and Ghidra as well as all these game decompilations coming out there should be a possibility for some cool stuff.

Hell even some of the early Symbian OS stuff running natively ported to Dreamcast has been a dream of mine. Sky Force is one game I absolutely fell in love with after playing the PSP Minis port around 2011 or so.

https://youtu.be/AZtfF5a_vAQ

[newtechstudio]

Wow, gonna level with you here, that game demo looks phenomenal for such lightweight code! Very cool project and just seeing that demo shows what sorts of things is possible with this. With what you said about porting other ARM based projects over sounds really compelling. I always thought one day would be cool to see early IOS games decompiled and ported over to DC since they also used the same graphics chip of the PVR2 as DC so there were so many visually impressive games on them. Anything from maybe 2011 and under should be able to be within the DC's capabilities. With the advent of things like AI and Ghidra as well as all these game decompilations coming out there should be a possibility for some cool stuff.

Hell even some of the early Symbian OS stuff running natively ported to Dreamcast has been a dream of mine. Sky Force is one game I absolutely fell in love with after playing the PSP Minis port around 2011 or so.

https://youtu.be/AZtfF5a_vAQ

Yeah man, its crazy how practically the entire world nowadays runs on what could've easily been the Dreamcast's architecture, even the GPUs are all tiled PVR's cousins. At some point most modern systems start to blur, so its great to get a hands on low level/high level programming what would've been their ancestor.
What you said about AI is also incredible, I think it would be really interesting to see decompilations of the older iPhone games running too since a lot of them are almost lost media today.

[Anthony817]

Hell yeah, there was an exclusive port of Driver 1 for the IOS that was very unique compared to the PSX and even PC originals. They had COD WAW Zombies, RE 4 and lots of other game ports on IOS from the early architecture that would be so freaking crazy to see those titles running on DC.

Just take a look at them, really cool to imagine them on DC since the graphics are absolutely what you would expect on DC.

[mistamontiel]

I've been dying to replay Driver 1 in that.. I tweeted the touchhle developer and says nope I hope so future build I've held down this IPA file for years

Re-done voice lines, text to read-along. So miserably need those

[Grey Fox]

Interesting project and the possibilities are exciting.

Just a quick question. You mention sponsorship (or a small Kickstarter). How much are you looking for?

[TapamN]

It's great seeing another Forth on the DC. I wrote my own Forth for the DC years (over a decade!) ago.

It looks like you based yours on ColorForth, while mine was based on StrongForth, and has static typing. Most of my Forth was written in C, with only a few parts written in Forth. There are several other changes to my Forth, compared to regular Forth, like no block file system (code is just a regular text files accessed over dcload) and C style constants (0xff). It compiled to a variable length bytecode, and has a C (includes safety checks for stack over/underflow and timeouts for infinite loops) and SH4 asm (fast) interpreters. Most common instructions (+, -, @, !, swap, load small constant) took 7 or 8 cycles on the VM.

The code for an instruction in my asm interpreter looked like this (I used the C preprocessor to name registers):

Code: Select all

!top two stack elements cache
#define st0 r4
#define st1 r5
#define c0 r6
#define inst r7	/* sign extended, shifted left 2 bits */
#define nextinst r8 /* sign extended, shifted left 2 bits */
#define stack r9
#define fstack r10
#define cstack r11
#define pc r12
#define insttable r13
#define POP(a)		mov.l @stack+,a

ALIGN4BYTE
sadd:	!0x60 01100000 ( a b -- a+b ) (7 cycles)
	add st1,st0
	bra next
	 POP(st1)

...

ALIGN4BYTE
next:	!fetch next instruction and jump to it
	mov nextinst,r0
	mov.l @(r0,insttable),r1	//1 cycle pair (1 total)
	
	mov r0,inst
	mov.b @pc+,nextinst		//1 cycle pair (2 total)
	
	jmp @r1		//2 cycle lat (5 total. Most instructions take another 2 cycles to branching back to "next")
	 shll2 nextinst

The jump table (accessed though insttable) was arranged so that using sign-extended offsets would work correctly. For a few of the most common instructions (exit, 0, dup, swap, drop, 1+), I inlined the contents of next to save a cycle or two.

I thought about adding an option to convert the bytecode to direct threaded code, which would generally save 3 cycles per instruction by not having to go though the jump table. Never got around to it, but the asm would have looked like this, with a nice trick using delayed branches:

Code: Select all

ALIGN4BYTE
sadd_threaded:	!( a b -- a+b ) (4 cycles)
  add  st1, st0
  POP(st1)
  jmp  @nextinst
   mov.l  @pc+, nextinst

You can see my Forth in this video:
https://www.youtube.com/watch?v=2uZP9iOQc6E

The rendering in that video is SH4 asm, and the physics were done with Bullet. For fun, I did try a bit of rendering with the interpreter, and (IIRC) it could do something like 300 kverts/sec when using 100% CPU. The VM has a set of floating point vector and matrix instructions, including a matrix-vector multiply instruction, and a dedicated submit-vertex-to-PVR instruction

[newtechstudio]

Interesting project and the possibilities are exciting.

Just a quick question. You mention sponsorship (or a small Kickstarter). How much are you looking for?

I need around 6K to 8K USD because the development cycle is relatively simple, however, writing a good compiler always takes a few months to make sure it runs at bare metal speed, plus, am also making a full fledged game to release alongside with the language.
So you'll get a CD with the game like a normal Kickstarter and also a CD + manual with the dev environment you can just pop in and start programming.

t's great seeing another Forth on the DC. I wrote my own Forth for the DC years (over a decade!) ago.

It looks like you based yours on ColorForth, while mine was based on StrongForth, and has static typing. Most of my Forth was written in C, with only a few parts written in Forth.

Thats really cool man, Forth is a really great language. Like you said, mine is based off of ColorForth, so it abandons the VM concept and goes down to the metal to take advantage of the hardware, for example a drop operation on the DC would be just popping the data stack to r0 so just one instruction, dup would be push r0.
Stuff like that is what am currently doing on PC32 so its really fast, not as fast as compiled C right off the bat, but I can also mix in assembler to get the full performance without losing the Forth advantage.

There are several other changes to my Forth, compared to regular Forth, like no block file system (code is just a regular text files accessed over dcload) and C style constants (0xff).

Thats really interesting, I have a way programming on the THUMB that modifies the movb opcode to store a byte variable, I use it mainly for self modifying code and the dreamcast has that same opcode since its the ancestor of THUMB, but here it might trash the cache so I have to do some profiling.
I am planning on using blockfiles since IIRC 1ST_READ can load up to 8MB to memory at boot, and my source code is just 1440 blocks so 1.44MB, to save it am planning on using either the VMU to save the binary diff or just dump it into the SDcard adapter.
The shooter engine on the OP video is only 5 blocks(5KB) so it should fit on the VMU just fine without models, although I do have a 3d modeler that uses signed distance fields and a meshing algorithm(which you can see demoed on the latter part of https://www.youtube.com/watch?v=LT3BkLAZKwE) so its entirely possible to fit a small game that compiles on the fly and generates its own meshes and textures out of code right on the VMU.

You can see my Forth in this video:
https://www.youtube.com/watch?v=2uZP9iOQc6E

The rendering in that video is SH4 asm, and the physics were done with Bullet. For fun, I did try a bit of rendering with the interpreter, and (IIRC) it could do something like 300 kverts/sec when using 100% CPU. The VM has a set of floating point vector and matrix instructions, including a matrix-vector multiply instruction, and a dedicated submit-vertex-to-PVR instruction

Man, thats seriously cool you even have an editor, having the mesh rendering on the back gives it a nice touch too.
For mine I'll have to implement floats since I dont really use them at all but the DC needs them 100% to get good performance.