Abersoft fig-Forth Recompiled

[ketmar]

windows, buttons, arrow:

Spoiler

the arrow is interrupt-driven (reading new mouse coords, repainting), everything else is in Forth. hot areas are specified like this:

Code: Select all

;; demo hot area
create hot-test
  ( x)  -4 c, ( y) -1 c, ( text) ,"  OK " ( udata) 0 ,
  ( x) -11 c, ( y) -1 c, ( text) ,"  INFO " ( udata) 0 ,
$80 c, create;

i'll create a special word for this later, so it will look like:

Code: Select all

['] handler -4 -1 " OK " mk-hot-item

negative coords means "from the right/bottom of the current window". ah, yeah, all Forth printing redirected to the new driver which understands screen windows. so you can use all the usual Forth words to print the text. windows aren't scrolled, though, y coords just wraps.

window clearing, frame printing, checking hot areas, inverting them, etc. — everything is in Forth, no asm involved!

p.s.: the arrow is blinking (just a little), to make it easier to spot.

[Wall_Axe]

Pretty cool

[ketmar]

non-micro$oft windows demo video! ;-)

pure Forth, no assembler (except the arrow driver). saving/restoring scr$ area is in Forth too, of course. arrow is controlled by kempston mouse, but i'll add kempston joystick and keyboard control later. it is interrupt-driven, so you don't have to do anything for it to move.

saving scr$ under a new window is optional: it is mostly intended for temporary windows like info messages and such.

the code for the demo:

Code: Select all

: show-about
  4 10 24 5 @050 open-window
  ." TILE/ROOM EDITOR v0.01\n     Forth power!"
  wait-butt-press close-window ;

: ok-pressed
  " INFO TEST!" show-info-window wait-butt-press close-window ;

;; demo hot area
create hot-test
  ( x)  -4 c, ( y) -1 c, ( text) ,"  OK "   ( udata) ['] ok-pressed ,
  ( x) -11 c, ( y) -1 c, ( text) ,"  INFO " ( udata) ['] show-about ,
$80 c, create;

: ii
  init-editor
  @060 to e8-attr
  5 2 22 19 mk-window
  attr-fill-window frame-window shrink-window
  ." hello!\nyay!"
  hot-test hot-setup  ;; this will print and frame it
  << menu-loop hcur-udata ?^| hcur-udata execute |?
  else| 0 0 at ." no button!\n" >> ;

[ketmar]

tile gfx editor GUI:

Spoiler

[Wall_Axe]

That's amazing progress to make such a tool within a day or two.

Are you writing the forth code on the PC and injecting it into the fig thingie on the spectrum?

[ketmar]

That's amazing progress to make such a tool within a day or two.

Are you writing the forth code on the PC and injecting it into the fig thingie on the spectrum?

thank you!

yes, i am writing on PC, but technically there is nothing that cannot be done on ZX, with almost the same speed, or maybe even faster. faster due better because interactive testing: currently i have to write a huge batch of code, and then test it. on ZX i could write word or two and test them. but of course, ZX has other limitations, so i still prefer PC. ;-)

btw, i started writing tile/room editor simply because i need something to draw a test room. and using Speccy is simplier than Xlib. ;-)

here's the editor source, for example. it is using some UrForth syntax ("?< … >?" instead of "IF … ENDIF", and such), but that syntax is supported by the ZX system too. except using "qvar:!" (var name with colon and "!"), on ZX it should be "to qvar". the difference is purely cosmetic, though.

p.s.: the tile editor shown above is fully working now. for room editor, i haven't thought about multiple rooms and such yet. will think about it later. the bitmap editor was added only because i need it, other features are added with the same logic. ;-)

p.p.s.: ok, one thing that would be much slower on the real ZX is writing and debugging asm code. because the assembling is much slower, and it is "all or nothing" — either it works, or it crashes and you have to reset Speccy, and reload everything. but i finished with asm code for now.

[ketmar]

implemented keyboard and kempston joystick control for the arrow. because why not? ;-) i developed the universal input scanning routine long time ago, and there is no reason to not use it. it can read up to 8 keys (or kempston and 3 keys), all redefinable. up to 8 because there are no more bits in the byte. ;-) should be enough for any game, i guess. or you can call it with different input tables if you want more. it also includes kb scanner with translation to ASCII codes to use in "redefine keys" routine.

[ketmar]

and somewhat unrelated, but inspired by looking at the code i recently wrote: evolution of ZX Spectrum programmer.

ketmar, circa 1994, hacking some game: oh, they are storing the same sprites, only shifted, again and again! i wonder if they even know about RRA — they can shift data as necessary, not store it! oh, and a row of LDI to copy the screen… somebody, tell them about that fancy LDIR instruction! no wonder this game doesn't have more graphics and levels — they wasted all RAM on such stupid things! somebody, give them Z80 manual!

ketmar, circa 2024, hacking some game: oh, they shifting the sprites in runtime… and LDIR to copy the screen… and they sync with the interrupt, but didn't even used the stack to transfer data… no wonder this game is so slow! somebody, give them Z80 manual!

;-)

[ketmar]

started implementing room editor…

Spoiler

it is crude, but allows puting tiles! ;-)

[Wall_Axe]

Looks nice.

How would I develop using forth for spectrum using PC?

Is the download in the first post still the best version?

[ketmar]

nope, the release is not ready yet. that download is obsolete demo. i will make a new download when i'll finish a demo game, and some other parts of the system i didn't finished yet (+3DOS/TR-DOS support, for example).

also, the idea is that you are developing using Spectrum itself. ;-) that's basically why editors are for Spectrum.

of course, it is possible to use cross-compiler too, as i am doing right now. but you will need x86 GNU/Linux system, because cross-compiler is writtein in UrForth/Beast, which is native x86 Forth system, and it only supports GNU/Linux for now. i am planning to create 32-bit Windows version too, but don't have enough free hours in a day yet. ;-)


anyway, i am planning to describe how to use everything if i'll ever make a proper release. all source code, tools and such will be available, and "getting started" documentation too. and at least one simple demo game. but i have to write documentation for UrForth/Beast first, because you will need it for cross-development, and it is totally non-standard.

also, i am planning to release a strictly cross-development system later. it will be Forth-based too, but will create native Z80 code (much faster than Aberforth), and will not require a full Forth system to run games. basically, you'll write your code on PC, then compile for Speccy, and the cross-compiler will build the minimal kernel to support your code.

Abersoft fig-Forth is used as a testbed for this "bigger" thing for now; most of the code (the sprite engine, the editors, etc.) will be reused for the new system, though.

[Wall_Axe]

Ok I'm using Linux now fortunately

[ketmar]

i can give you source snapshot of the current work, but i don't think that you'll be able to do much with it without documentation. and i am not ready to answer questions about it yet (because there will be a lot ;-). but if you feel adventurous, PM me… ;-)

[ketmar]

properly stolen room from Rex. now it looks like The Real Editor! ;-)

Spoiler

the editor supports 16x16 tiles too. faking them, i mean. just draw 4 consecutive tiles so they form a bigger 16x16 tile, and hold CS when drawing. the editor will put 16x16 tile.

need to implement tile property editors now. that is, each tile has "property byte". bit 7 of this byte indicates that sprite should not recolor it (i.e. sprite attrs are ignored). bits 4-6 are reserved, and bits 0-3 are free to use by your game. i think that 16 tile types is more than enough. ;-)

now i need to implement property editor mode, both in tile editor, and in room editor. because the room can have separate attribute and property layers, independent of tiles (so you don't have to copy tile graphics if you want it to have a different color, or if you want to paint something with paper color on empty spaces).

[ketmar]

also, i wonder if i can squeeze some more tstates to add "don't draw sprites over this tile at all" flag. it can be really useful. the problem is that i am not only out of tstates (i want to be able to redraw at least 9 sprites per frame, and that's what i have now), but out of registers too. both register sets are used. but we still have IX and IY, i prolly could use them to track property map, and to patch blitting code on the fly. and then my engine will be even better than AGD! ;-) will have to duplicate one subroutine, though.

[ketmar]

managed to implement "tile masking". sadly, only 8 sprites per frame now: missing about 1.5K tstates for 9. ;-) the code is not fully optimised, though, so i might be able to sqeeze 200-300 tstates more. still not enough for 9 sprites. :-(

but i believe that this mode worth losing one "frame sprite". it will allow using "foreground tiles", and implement Rex-like engine. in Rex, the sprites are "OR"ed, but they won't overwrite room tiles. with this new mode, it will be possible to almost fully emulate Rex, and with colored sprites! (in Rex sprites are monochrome).

now i have to iron out some bugs in new code, and optimise it. already better than AGD, and with much fancier room editor! ;-)

(don't get me wrong, please: AGD is The Great Program, and it is really hard to do more than it does. i bet Jonathan could easily implement "tile masking", but simply decided to skip it. yet using AGD as something to compare with is a good way to "range" my engine, i believe.)

[ketmar]

gif with demo animation (warning! ~2mb gif file!): gif animation.

upd: edited the link. gif now shows two possible modes for tiles: either don't print sprites over a tile, or print sprites, but keep tile attrs.

[ketmar]

one good thing about having only 8 sprites per interrupt: testing shows that sprite gfx can be in contended memory. this adds ~1K tstates, which is still acceptable. so we can have property map (768 bytes) and sprite data before $8000, leaving fast memory for the code. it is also ok to have 256 bytes of sprite info structs in contended memory, because it doesn't matter — so i can use $5B00 (256 bytes of printer buffer) for internal sprite info buffer. the sprite engine itself is 1.4KB, quite small.

[ketmar]

implemented tile property editor window:

Spoiler

tile types mean nothing to the editor, so they are numbered.

[ketmar]

hey, but we have a disk storage! used block #60 to store property names, so they need not to be hardcoded into the editor.

Spoiler

looks ugly, but much better than numbers, i believe! ;-)

also, changed sprite definition format (added Yet Another Indirection ;-), and integrated universal "stick input" subroutine. it is table-driven, supports kempston and redefinable keys. and it is called in IM2 handler, before sprite rendering.

it looks like i still have ~2.5K tstates free. enough for AY sfx, not enough for any good beeper sfx, i believe.

by the way, if you are interested how i count timings — ZXEmuT has special traps to start tstate counter, and to print current tstate counter to the console. very useful feature.

also, i should prolly stop fiddling with tools, and write one-room Rex-like demo. and then finish disk support. the problem with disk support is not ZX code, btw: i need to write UrForth code to create TR-DOS and +3DOS disk images. and i am too lazy for this. ok, TR-DOS is easy, but +3DOS has The Real File System, and i don't even remember how it looks like on a sector/byte level.

[ketmar]

added Joffa's SFX engine from Saucer. the good thing about it is that it is simply uses the time left to the interrupt to produce some noise, so if you time your game logic right, you can produce some easy sfx for shots and such. it may slow the game down a little if you are not syncing to intrs, but with proper sync it should not be noticeable. at least it is not noticeable in test code with 16 sprites. ;-)

[Wall_Axe]

This is pretty awesome.

I have low energy and motivation for anything these days. I used to do computer/nerd stuff all day but I've changed.

So that's why I haven't actually attempted to use this yet.

I did try reading the fig forth manual but it was similar to shorthand, just tons of info badly presented.

I'll try loading the.tap file into my spectrum in a few days as my motivation to do anything is so low.

Potentially a low resource intensive game could be ported to any 8 bit system using this,I would imagine.
Maybe not something like double dragon though

[ketmar]

This is pretty awesome.

thank you! ;-)

I have low energy and motivation for anything these days. I used to do computer/nerd stuff all day but I've changed.

hey, isn't coding for Z80 one of the best ways to rest? ;-)

I did try reading the fig forth manual but it was similar to shorthand, just tons of info badly presented.

yeah, you'd better know Forth beforehand. i am sticking to FIG model here because they have most words documented — something i am not ready to write myself yet. ;-)

Potentially a low resource intensive game could be ported to any 8 bit system using this,I would imagine.
Maybe not something like double dragon though :lol:

sprites are output via XOR, so you'd better don't have a background room graphics. ;-) and you have to write all game code (including room management and such) yourself, the system only does sprite rendering for you. but it means that you can write any game you want (as long as it is not a scrolling one)!

not a big game, though, because ~18KB is occupied by the system itself. but you'll be able to use disk loading! i am currently writing +3DOS support code.

it also means that porting will require some efforts, because you'll need to implement sprite engine yourself. but yeah, the game logic could be ported as-is.

[ketmar]

i HAET writing disk image tools. but i can load .DSK image now, list +3DOS directory, and even read files. the fun thing is that i don't need any of that, because i only need to create .DSK images. everything went wrong yet again. ;-)

[ketmar]

ok, cross-copiler can create +3DOS .DSK image now. and the system even starts from it! ;-) the writer supports all 4 kinds of disks, and uses 720K disk by default. now i have to write +3DOS interface code.