Abersoft fig-Forth Recompiled

[ketmar]

implemented +3DOS support for block i/o. it is possible to open any +3DOS file as block storage with "+3BLK-OPEN", and then all standard Forth block commands will work with it. so it is now possible to use room editor (which stores everything in blocks) on real +3, yay!

of course, there is a way to call any +3DOS API you need. because +3DOS rox! ;-)

"R/W" words looks like this:

Code: Select all

: R/W  ( addr blk read-flag )
  +3BLK-OPEN? 0= 8 ?ERROR
  ;; seek
  SWAP B/BUF U* TO +3DOS-DE TO +3DOS-HL
  0 TO +3DOS-BC
  $136 +3DOS-CMD
  +3DOS-CF? 0= 8 ?ERROR ;; disk i/o error
  ;; read or write bytes
  DUP IF OVER B/BUF ERASE ENDIF
  SWAP TO +3DOS-HL  ;; addr
  B/BUF TO +3DOS-DE ;; length
  $0000 TO +3DOS-BC ;; file # and page #0 for $C000 -- FIXME!
  IF $112 ELSE $115 ENDIF +3DOS-CMD
  +3DOS-CF? 0= 8 ?ERROR ;; disk i/o error
;

that's how easy to interface with +3DOS now!

[ketmar]

…and i just thought that TR-DOS support is completely unnecessary. it will require a custom disk format with non-standard sector sizes, which is hardly supported by TR-DOS emulators on real hardware. it will not use TR-DOS "file system", so various high-level emulators will fail to map Forth block to files on HDD/SDD. therefore i see no reasion in supporting TR-DOS. +3DOS is much better just in every way possible.

[ketmar]

i tried "OR/AND" sprite printing ("OR" sprites, then erase with inverted "AND" mask)… and it looks surprisingly good, even for overlapping sprites. of course, this mode cannot be used with "print sprite over tiles", but as we have "tile mask" mode, it can be used with this.

doesn't have much sense, though, because overlapped sprites will have some artifacts. but i guess it still could be used for some fast shooter-like game, where enemies might overlap, and most enemies are updated during a frame.

also, i think i spent enough time with this, so i have to write some simple demos and documentation, and make a release. i really want to move to better system now, one which generates True Machine Code.

[ketmar]

another thing i definitely don't want to write in assembler:

Spoiler

[ketmar]

and some amimation! huge gif!
yes, it is possible to draw on the magnified sprite area, i simply forgot to record it. ;-) and the sprite keep walking.

[Wall_Axe]

That is very rapid development for the speccy

Were you saying you could use the same/similar forth code to make the same app for Linux? Or is that far off?

I was thinking of making a spectrum game a while back. So I coded a prototype in JavaScript. I basically used 8x8 squares only for the graphics, so it was a tile based game. I suppose in the same vein you could open up a window in Linux which is the same dimensions as the speccy display and it would work well.

[ketmar]

That is very rapid development for the speccy ;)

thank you! i procrastinated almost 1/2 of the time, tbh. ;-) and most code was lifted from the tile editor (arrow, magified view, hot areas). still, developing in Forth IS that fast: tile editor only took me about 2 days of work (if we remove all procrastination, and compress everything to standard 8-hour working days).

and it could be done on Speccy itself. no, really. i already have a fullscreen editor, so it is mostly the same "write a word, test a word", and i don't have to reload Forth every time. PC editor just have bigger letters, and my eyes are not as good as they were, otherwise i'd do it on Speccy itself (on an emulator). ;-) and there's no asm involved. (i wrote 2 asm words just for the sake of… size. one is "3*", and another is looking for the first set bit in a byte. both were done in Forth first, and asm versions are slightly smaller.)

by the way, bit looking word was taken directly from the x86 UrForth — it is used in sprite compiler there.

Were you saying you could use the same/similar forth code to make the same app for Linux? Or is that far off?

actually, i can. it is the basic "wait for an event / handle an event". i could rewrite low-level part (event reading, pixel manipulation) with Xlib, and reuse most of the other code almost "as is".

I was thinking of making a spectrum game a while back. So I coded a prototype in JavaScript. I basically used 8x8 squares only for the graphics, so it was a tile based game. I suppose in the same vein you could open up a window in Linux which is the same dimensions as the speccy display and it would work well.

one of the reasons i am making various Forth systems is to prototype some game ideas i am too lazy to write in asm. i want to do it on Speccy itself (emulator, of course) to see how it would fit. but yeah, i can write Xlib gfx part, and the end result will look like Speccy emulator. ;-)

p.s.: btw, the walking animation is not some interrupt trick. it's just a Forth word which blits the sprite (yep, this time it is in Forth, not in asm; all sprite sheets printed by Forth words), and it is called in the loop which waits for a mouse/key press. no black magic there at all. ;-)

[ketmar]

implemented most sprite editor functions i need:


MASSIVE 4mb gif animation of the working editor. of course, i forgot to record pixel drawing. again. ;-)

p.s.: it took me about a hour to implement all those new buttons. Forth power! ;-)

[ketmar]

just to note: nope, the project is not abandoned. trying to write documentation and examples. most complex part, which may take quite some time. ;-)

[ketmar]

i just thought that while i'm trying to write the documentation (and it may take ages), i could upload the current working source code.
src and +3DOS .dsk.

there is the prebuilt disk image (tap/aforth.dsk), with sprite editor and autoboot. type "EE" to run the editor. bonus: type "XI" to run sprite demo.

i don't believe that it is usable without a documentation, but hey, there is no reason to hide the source code anyway.