Hi!

About the hardware specifications...

Display 128x128 16 colours
Cartridge Size 32k
Sound 4 channel chip blerps
Code Lua
Sprites 128 8x8 sprites
Map 128x32 cels
Controls 2 6-button joysticks

BUT....

Are possible to develope "directly on board"... using Registers, direct memory RAM/Video access, etc etc?

I explain clearly? (sorry for my english)

Thanks in advance...

well technically lua IS a register-based VM

for the video, you can access the draw buffer with peek()/poke() in 0x6000..0x7FFF

Hi TheHark0

There isn't any way to directly access hardware, because it really doesn't exist! Everything to do with the Lua vm is protected in order to keep it stable and to keep things simple.

There is a memory mapping for non-code data though ('base ram'), that Siapran is referring to. From the manual:

:: Base ram memory layout
	0x0    gfx
	0x1000 gfx2/map2 (shared)
	0x2000 map
	0x3000 gfx_props
	0x3100 song
	0x3200 sfx
	0x4300 user-defined
	0x5f00 draw state [,cart data] (192 bytes incl. unused)
	0x5fc0 (reserved for persistent data -- in development)
	0x6000 screen (8k)

	Colour format (gfx/screen) is 2 pixels per byte: low bits on the left
	Map format is one byte per cel (normally used as a sprite index)

You can safely read and write from these address using peek(), poke(), memset() and memcpy() which allows a few tricks. For example, some of the glitch effects in Mr. Beam are performed by doing memcpys in video memory.

OK....

I had thought that internally, the program works "as a CPU"+display... like DCPU16... with his own REGISTERS, STACK, etc etc....

And.... this

0x5f00+

0..0xf     draw palette
0x10..0x1f screen palette
0x20..0x23 clip coordinate left, right, top, bottom
0x24       unused
0x25       current draw colour
0x26       cursor x
0x27       cursor y
0x28..0x2b camera position x,y (small endian int16s)
0x2c       screen mode // 0 128x128 (normal)  1 64x128  2 128x64  3 64x64

Are maybe like "system vars", ZX-Spectrum (for example)

Pico-8 have any memory direction for "call's"? (function not implemented, I know)

;-)

oh! I remember the DCPU16
pico8 is nowhere near the same philosophy though, it wants to stay accessible for aspiring programmers and game designers.

also what do you mean by "calls"?

Yeah, there really isn't any 'real' hardware emulation going on underneath (so no instruction pointer calls etc). In fact, even the Lua vm and runtime data is quite hidden -- it could plausibly be replaced with something completely different without breaking carts in the wild. The idea is that for 99% of users, the implementation doesn't really matter, and it's better instead to focus on design and tools that only /feel/ like there is some cute 16-bit machine running behind it.