TIC-80
TIC-80 copied to clipboard
nesbox
Use some kind of retro fantasy CPU instead?
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.
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.
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?)
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:
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.
You can have a C virtual machine with Python (or other high level language) peripherals
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.
@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.
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!
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 [email protected] 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 .
@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.
@nesbox
- by "separate instructions and data" you mean Harvard architecture?
- 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?
- Any guides / tips on how to start implementing new language?
- yes, seems it's the Harvard architecture :)
- we still have about 12KB of free RAM, just updated the wiki https://github.com/nesbox/TIC-80/wiki/RAM
- 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
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.
@Anrock I spoke too soon in the other thread... sounds like nesbox is entirely onboard with the idea... you'd write assembly in the editor... and compiling assembly is a lot simpler than a whole compiler/linker toolchain for a higher level language... of course no one is stopping you from doing that outside TIC-80 and just pasting the assembly into TIC-80... and cartridges would be binary... so you'd essentially have 64kb of ROM say...
Of course writing in assembly is a LOT different TIC-80 experience, but I suppose some would find it fun. :) Or perhaps you want to use a higher level language and still just be subject to those post compilation "hard limits"... one problem is that the "hard limits" you'd find (96kb total RAM) are going to be very, very, very different than the "hard limits" someone using JavaScript or Wren or Lua are going to find. IE, TIC-80 DCPU-16 would be almost an entirely different beast from TIC-80 Lua.
@nesbox Is there a reason we need to design our own CPU from scratch vs using some CPU architecture already in existence? Why couldn't we just say drop in a DCPU-16 directly or some such?
N/m, I think it's out because of the limit of only 64K words of "total address space"... so that's 128kb but that doesn't leave room both both the 96kb of data AND 64kb of code. So we need something with a 32-bit (or at least 18 bit) address bus...
I'm just saying adding a fantasy CPU architecture to TIC-80 with an assembler based around it would be an exciting addition.
So are those of you asking for this wanting/expecting to write your actual cartridges in pure assembly?
@joshgoebel
Is there a reason we need to design our own CPU from scratch vs using some CPU architecture already in existence? Why couldn't we just say drop in a DCPU-16 directly or some such?
This is arbitrary decision, I believe. We can settle on canonical CPU like just as we're having LUA as canonical language, but nobody is forbidding implementation of any other CPU binary interpreter just as we have Moonscript and other languages.
N/m, I think it's out because of the limit of only 64K words of "total address space"... so that's 128kb but that doesn't leave room both both the 96kb of data AND 64kb of code. So we need something with a 32-bit (or at least 18 bit) address bus...
Not necessarily. There are (at least) two not mutually-exclusive options here a) We say that TIC is harvard architecture and program code is not accesible to program itself and thus we don't need 64kb of space for code. Poof, problem gone. Sure, we lose ability to make self-modifying code but it's minor. And we can redo things later if people really want it. b) Current occupied address space is mostly fully mapped VRAM (and other devices). We could unmap it and replace with hardware registers thus saving huge amount of space to be remapped as code and data RAM. But it will break cartridges that rely on changing RAM values directly.
So are those of you asking for this wanting/expecting to write your actual cartridges in pure assembly?
Yes.
So we need something with a 32-bit (or at least 18 bit) address bus...
This comment was specifically referring to my taking back of my "we could just use DCPU-16 [as is]"... because it's Von-Neumann. I'm aware that a Harvard architecture makes the most sense since then it gives us 64kb of addressable RAM that we could page our real 96kb memory in and out of.
Current occupied address space is mostly fully mapped VRAM (and other devices). We could unmap it
You could but writing assembly that has to keep track of which 16kb segments (for example) is currently paged in or out sounds pretty annoying to me (though I guess perhaps it's old hat to some). I'm mostly used to ARM m0 and Arduino where that's not a problem I have to worry about. Doing something like a map (we need VRAM, MAP, TILES, etc.) requires paging in 24-32kb of VRAM... so realistically for any code doing drawing you're stuck with only 32kb of addressable RAM for program code. Perhaps that isn't as terrible a restriction as I think.
If we went Harvard we could just not think about the program code at all and have 64kb of mappable RAM, which seems like more breathing room.
But it will break cartridges that rely on changing RAM values directly.
No. There are no "existing cartridges" running on a fantasy CPU - thus nothing to break. I think this architecture will be quite different (in severals ways) than what the other VM runtimes are doing - and it doesn't necessarily require that the hardware they see changes one bit. IE, remapping RAM makes sense in a 64kb constrained "fantasy CPU" environment, it makes far less sense in the other scripting environments - so I'm not sure it would need to be exposed there at all - they would maintain their existing 32-bit address bus 96kb view of the world. More on this in the other thread.
We can settle on canonical CPU like just as we're having LUA as canonical language
Is Lua canonical? Either way I don't think there will be a separate award for "canonical CPU"... Tic-80 is a platform with many "runtimes"... if Lua is canonical, then it is canonical period (as I think of it). If we start adding fantasy runtimes they'd just be another supported runtime, I don't think there would be a "default". Unless first becomes default just because it's first... but that doesn't mean a lot IMHO.
I'm closing all the fantasy CPU/68000 issues I opened. I think the interest level is too low, the complexity too high, and the payoff not nearly worth it given that we can have something very similar (and much better in many ways) with WASM support - so that's where I'm focusing all my attention. If anyone else wants to pick this up and run with it in the future you can find all the threads linked above.
@StinkerB06 I wonder what you think about WASM...
As this isn't my issue and is the originator I will leave it open as a request.
For those interested in playing within a far more "fantasy CPU" context, WASM support was just merged: #1772.
- compiled binary code
- hard limit 256kb RAM (vs the almost unlimited offered by scripting runtimes)
- hard limit 256kb
BINARYblog size (compiled "binary" size)
No CPU limits, but I'm not sure that's a direction the project is super interested in either.
Take a look at MEG-4 Fantasy computer, which has a virtual CPU and supports ASM:
https://github.com/relector-tuxnix/meg4
