Tic-80: Use some kind of retro fantasy CPU instead?

[StinkerB06]

Using modern scripting languages for retro game design in a fantasy console is kind of cheating.

What ideas do you have for a "TIC-80 CPU"? What kind of architecture would it be based off? Would it be original? I'm not saying you should replace the Lua, JS, Wren, etc. scripting languages in TIC-80, I'm just saying adding a fantasy CPU architecture to TIC-80 with an assembler based around it would be an exciting addition.

[RobLoach]

Make a virtual machine, and have at it.

[Anrock]

I've started my fantasy console project exactly because tic-80 uses modern languages that kinda break immersion (there is only 64k of mem, but you can allocate 4Gb on heap if you need).
And so far, I can tell you, it's not an easy task to create fantasy CPU and all the things around it like binary instruction format, parser for language, assembler itself, linker, binary emitter, debugging tools and so on. Also, you'll have to emulate devices like GPU and storage because you don't have OS to call their APIs. Or you can have an OS and face whole other pile of problems.

So this would be a major overhaul of TIC-80 and a lot of problems with rebalancing other things around it.

[StinkerB06]

Why not just have dedicated instructions that call the different TIC-80 APIs? And have a dedicated instruction to return from a program's loop (a.k.a. a return statement done inside the TIC main function?)

[Anrock]

Well, you can, of course.

But it's not how CPUs work.
So some time later some StinkerB07 will come in and say something like
"Using magic instructions in retro CPU ISA in a fantasy console is kind of cheating. What ideas do you have for IO devices? Would they memory mapped or use IO ports?" :smile:

[Anrock]

Hm, actually you can have some plausible magic instructions.
Pretend that your code is running under the OS, put arguments to registers, invoke interrupt, poof, magic. Same for returning. That may work, yeah.
Don't even need dedicated instructions. Just single one for interrupt invocation and the reset is configured via register values.

[FranchuFranchu]

You can have a C virtual machine with Python (or other high level language) peripherals

[finalpatch]

To me, the thing that breaks immersion in TIC-80 is the unlimited computing power.

PICO-8 specifies how many operations you are allowed in each frame, and it's a fairly low number, so games run exactly the same on a powerful desktop computer or in a web page on a mobile phone.

With TIC-80, some heavy games run significantly better on desktop than on weaker platforms. If I just target desktop CPU, then it's possible to do things that are unrealistic in a retro computer.

[Anrock]

@nesbox seems like you're back to TIC-80, what do you think about this idea?

Another issue I see about assembler / binary are the cartridge limits. 64k of LUA code can do so much more than 64k of assembler.

[rdrpenguin04]

I think all of these are valid points; I'd be all for having a fantasy computer that used an actual instruction set. However, that may be out of the scope of this project, as switching away from Lua would break all of the existing programs. It would be cool to see that in another project though!

[StinkerB06]

Actually, TIC-80 supports multiple languages, with Lua being the default
one if you omit the "script:" tag in the code. A "script: asm" would be the
need to switch out of Lua into assembly mode.

On Mon, Nov 9, 2020, 4:18 PM Ray Redondo [e-mail] wrote:

I think all of these are valid points; I'd be all for having a fantasy
computer that used an actual instruction set. However, that may be out of
the scope of this project, as switching away from Lua would break all of
the existing programs. It would be cool to see that in another project
though!

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/nesbox/TIC-80/issues/1007#issuecomment-724364855, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AHFK2N2JTAKRSMRXVPI47RLSPCBFPANCNFSM4KSFC34A
.

[nesbox]

@Anrock I like this idea and don't see any problems to embed an assembler to TIC.
We just need to design a fantasy CPU for TIC, something like DCPU-16 that can address 16KB VRAM + 80KB RAM with separate instructions and data.
Code Editor will show asm code if you save cart as text project, but you will see compiled byte code if you save it as a binary .tic cart.

[Anrock]

@nesbox
1) by "separate instructions and data" you mean Harvard architecture?
2) Also, isn't all 96KB address space already taken by IO? Memory map in wiki seems to be outdated because AFAIK VRAM was moved out of 80KB. Where can I get up-to-date memory map?
3) Any guides / tips on how to start implementing new language?

[nesbox]

1. yes, seems it's the Harvard architecture :)
2. we still have about 12KB of free RAM, just updated the wiki https://github.com/nesbox/TIC-80/wiki/RAM
3. there are no guides, pls look at any already added lang, JS for example https://github.com/nesbox/TIC-80/blob/master/src/api/js.c