Log In  

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...

P#11380 2015-06-25 06:08 ( Edited 2015-06-29 21:57)

well technically lua IS a register-based VM

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

P#11381 2015-06-25 06:52 ( Edited 2015-06-25 10:52)

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.

P#11389 2015-06-25 11:03 ( Edited 2015-06-25 15:08)

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)

;-)

P#11396 2015-06-26 04:57 ( Edited 2015-06-26 08:57)

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"?

P#11397 2015-06-26 11:34 ( Edited 2015-06-26 15:34)

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.

P#11404 2015-06-29 17:57 ( Edited 2015-06-29 21:57)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-29 09:10:49 | 0.006s | Q:13