Abersoft fig-Forth Recompiled

Show us what you're working on, (preferably with screenshots).
catmeows
Manic Miner
Posts: 716
Joined: Tue May 28, 2019 12:02 pm
Location: Prague

Re: Abersoft fig-Forth Recompiled

Post by catmeows »

ketmar wrote: Wed Mar 27, 2024 4:49 pm i had to look at (and edit) the sample game. standard line editor sux, so i wrote the fullscreen one. and implemented 64 columns print driver for it. ;-)
screenshot
Image
the editor works in any mode, though (32, 42, 64). it has line yank/insert, and nice incremental search.

sadly, editor source cannot be made loadable on Speccy itself: it is using some headerless system words. i removed headers from some rarely used internal words to save some RAM (and the editor itself is mostly headerless too). but it is only 2.9KB, so i guess i can include it instead of the old line-oriented one.
Can I try the editor somewhere and is there a documentation ? I wonder how much space a minimal fullscreen editor would take. 2.9 KB is quite a lot, considering line editor can take perhaps one third of space, I guess.
Proud owner of Didaktik M
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

catmeows wrote: Sun Mar 31, 2024 7:39 pm Can I try the editor somewhere and is there a documentation ? I wonder how much space a minimal fullscreen editor would take. 2.9 KB is quite a lot, considering line editor can take perhaps one third of space, I guess.
latest demos in this topic are compiled with the editor. just type "LOADT 1 EDIT".

and it is not minimal, i added quite a number of features — because i am using this editor to edit blocks in the emulator. ;-)

there is no documentation yet, but pressing CS+SS will show some extended commands in the status line. there are more commands there, but the status line is too short. ;-)

as the editor is mostly in Forth (sans one or two code words added for speed), it will be possible to load it on ZX from block file later. with transient vocabularies system in place (still have to implement it) it won't take any program space at all. ;-)

p.s.: it is about 20 KB of Forth source, so ~3 KB is quite good, i believe. ;-)
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

i cached "NEXT" in IX. the code became slightly smaller, and slightly faster. not much, but why not? IX was used for user area pointer, but we don't have a lot of uservars anyway, so it was a waste of register.

i wonder if caching TOS in DE will do any good. but this will require rewriting of all primitives, and it would be hard to make it optional (the code will became a mess). i don't expect a huge speedup anyway, so i decided to not try it yet. at least not in this system.

also, i am too lazy to decompile "laser library" from White Lightning. i think it would be easier to write simple blitters myself — nobody really needs the whole "laser lib" anyway. it is nice to have, but i believe that "get-sprite" and "put-sprite" will be enough for practical purposes.

i definitely remember seeing laser basic disassemly, but my google-foo is not strong enough to find it. alas.
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

wrote simple sprite blitter. currently only in overwrite mode, at char positions. tested on White Lightning sprites, lol. the code is not superfast (althroug it is using unrolled LDI loop per sprite line).

it would be easy to modify the blitter to allow arbitrary y coords (not restricted to chars), but whithout attributes, of course. it is also possible to save screen part in sprite format, and either blit it back, or use it as a sprite. lib size is ~400 bytes (this includes screen$ save/restore too). so no more stupid UDGs, we have Almost Real Sprites now! ;-)

i really have to port XTE2 to this! ;-)

of course, the blitters do no sprite clipping, but hey, it is better than nothing!

i prolly need to write a better sample game now. ;-)
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

added (optional) OR/XOR/AND blitters too. with all blitters included library size is ~1KB.
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

creating flicker-free XOR sprites is surprisingly hard. i wonder how Jonathan Cauldwell did it in AGD. althrough AGD is not shifting sprites, i believe.

i created 16x16 blitter with shifting, so i can blit at any x pixel coord, but of course it flickers hard. HALT only helps with 2 sprites or so.

another idea was to simultaneously erase the old sprite and print the new one. now it flickers like there is a running tv static, lol. i mean, one horizontal sprite line. looks fun, but…

the problem is that with run-time shifting, i simply don't have enough time in interrupt handler to process any good number of sprites. and i don't want to remove shifting, this is a handy feature.

ok, another idea: let's waste 160 bytes per active sprite. store old and new sprite data, and precalced scr$ addresses there. this way interrupt handler will have to do a minimum amount of work: basically, read address, xor several bytes, repeat until there are no more updates.

problem: interrupt may trigger when we half-finished updating the buffer. prolly need some way to mark the sprite as "updating yet".

i still think that XOR sprites sux (sorry, Jonathan! ;-), but writing flicker-free XOR engine is surprisingly hard. much harder than doing masked sprites with double buffering. ;-)


and now for something completely different. i suddenly found a way to make my libraries with asm code loadable on ZX itself, and without any asm compiler! Forth code is ok, it doesn't use anything ZX cannot compile. and for asm, i can simply preprocess everything! i mean, i can output compiled machine code ("$76 C,", and so on), and then simply emit some Forth code to fix labels. my assembler tracks all labels anyway (for cross-reference files), so it's not a problem to write fixups.

this way we can have a base system, and add various bells and whistles (libraries) on ZX itself. yay. quite useless, but hey, this is something that could be done back then on ZX itself, and it is a sensible way to distribute libraries. so let's pretend that i am simply emulating something some software house did in 80s. at least you won't need any cross-compiler to build the system you like.
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

oh, i see. Jonathan did exactly what i thought of: simultaneous erasing and drawing after vblank. only AGD doesn't have run-time sprite shifting, so no need for any temp buffers. ok, i will prolly make two versions: with shifts, and without. so 3 sprite engines now, lol: White Lightning like, XOR16 with shifts, XOR16 without shifts.

and don't ask me why, please. i know that nobody will use this to write games. especially considering that the main system is in contended memory, and therefore is bloody slow. but it is fun to write!
DoctorRad
Drutt
Posts: 27
Joined: Mon Mar 18, 2024 4:40 pm

Re: Abersoft fig-Forth Recompiled

Post by DoctorRad »

ketmar wrote: Fri Mar 29, 2024 12:28 am sadly, most of the "laser library" is one blob of machine code, without any headers. i vaguely remember that there was a Laser Basic disassembly around.
There's always Machine Lightning, which presumably has similar capabilities. While the software is in the archives, the documentation appears to be lost at the moment :cry:
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

DoctorRad wrote: Tue Apr 02, 2024 5:00 pm There's always Machine Lightning, which presumably has similar capabilities. While the software is in the archives, the documentation appears to be lost at the moment :cry:
thank you! but it still doesn't have a source code (or i am unable to extract it). i mostly need the source to create relocatable code, and to allow selecting which part of the library should be compiled in.

sure, i can write it all myself, but… this is boring. ;-)

also, my sprite blitter is faster. ;-)
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

i implemented "prepare, then redraw in interrupt handler" engine for 16x16 sprites with run-time shifting… and will throw it away now. ;-) it doesn't worth the efforts. it requires 2KB for buffers, takes a lot of time to prepare buffers, and dog slow even with 13 sprites (this is as much as it can update in one interrupt).

using preshifted sprites will be much faster, and will not require any additional buffers. i mean, the code will prolly be able to update only about 8-9 sprites per interrupt, but without any extra time spent on preparations (so you don't have to share game logic time with housekeeping code).
User avatar
ParadigmShifter
Manic Miner
Posts: 666
Joined: Sat Sep 09, 2023 4:55 am

Re: Abersoft fig-Forth Recompiled

Post by ParadigmShifter »

I wouldn't recommend drawing in the interrupt code myself. Unless there's no HALT of course.

I did say to someone the other week maybe do a backbuffer copy in the interrupt though (but you rightly pointed out a full screen backbuffer copy would be too slow even using the stack, so can only be done for backbuffer not too big). Then I backtracked and said don't draw in the ISR do it after the HALT since it's much easier.

When I did draw in the interrupt routine (first attempt at ASM coding ever) I was using a backbuffer but had a dirty list of which cells from the backbuffer needed copying to the screen (3 bytes per row, a bitfield of clean/dirty flag for each character cell that was dirty). Note I did not do the dirty buffer handling inside the ISR either I turned it into an #FF terminated list (well a size 64 array) I think, with a max size of 64 entries, and a flag for "we have more than 64 cells to update, just copy the entire backbuffer" - which was used for first drawing of each level). That turned out to be a pain to implement though and made my actual sprite drawing slower cos I had to update the dirty buffer). I used self modifying code to outside the ISR to signal that we are ready to draw i.e. I replaced the 0 operand in LD A, 0 here:

readytodraw: LD A, 0
OR A
RET Z

by doing

DI
LD (readytodraw+1), 1 ; obvs not really this, I had to LD A, 1 first and LD (readytodraw+1), A
EI

when I was done updating game logic etc. ISR routine would set it back to 0 at the end.

I would recommend preparing as much as possible AFTER drawing sprites for the next frame (e.g. do the shifting for the next frame into per sprite buffers if you have the space for that, you'd need 1 buffer per sprite then though, much more complicated if you have variable width sprites).
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

also, moving the system to $8000, and removing RAM-DISC will leave about 12KB of RAM free for user code. this is quite a lot (the whole system is ~15KB now, or ~18KB with fullscreen editor). so i will prolly ditch RAM-DISC at all, and implement support for TR-DOS and +3DOS instead.

i mean, 'cmon, you cannot do anything serious using tape only! everybody used either some DOS, or microdrives (poor souls!). i never bothered to implement microdrive support in my emulator, and i won't do it in R/W word.

for TR-DOS i will prolly use the whole disk as block storage (maybe with some offset, so you could have TR-DOS directory and some data there), and for +3DOS i can use regular disk files instead (because this is The Real DOS).

i may also separate word headers from compiled code. there is no reason why headers cannot grow from $7FFF and towards $0000. and then you'll be able to create "turnkey" apps on Speccy itself, by saving the compiled code, and omiting all headers. currently, headers size is ~3.5KB, so you'll have 3KB more for your compiled code.

and it will allow to trivially implement word hiding by removing some headers altogether, so you would load your library, and then wipe headers for all internal/support words, leaving only high-level API (this is what i am currently doing in my target compiler, btw).

this way you'll be able to use the system on the real hardware to do some Serious Development. i don't know why, but hey, it's a k00l feature anyway! ;-)
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

@ParadigmShifter, the problem is that i want to make everything easy to use. the idea is that you only call "SPR-UPDATE" word with new sprite position and animation frame, and the system will magically do the rest. i don't want the user to think about interrupts, where to insert HALT, and so on.

as i am doing XOR sprites, the only place where i can draw them without user intervention (and almost without flicker) is interrupt handler.

the idea is to create something like White Lightning (or AGD): simple, easy to use, and fun. and it should be possible to use it on the real hardware (just because i want it that way ;-). let's pretend that it is 1986, and i am releasing a Forth-based game creation/programming system, which will show that it is possible to create real games with such thing. then i will sell it to Ocean to be published under Ocean IQ label. ;-)
User avatar
ParadigmShifter
Manic Miner
Posts: 666
Joined: Sat Sep 09, 2023 4:55 am

Re: Abersoft fig-Forth Recompiled

Post by ParadigmShifter »

Fair enough.

I had White Lightning (boxed copy) BITD but I struggled with the Forth since it was so different to what I was doing when I was a teenager (mainly BASIC, tried a bit of ASM but with tapes only, no thanks lol). Then I moved onto The Quill and GAC really. Also I agree that the WL editor sucked balls ;)

I only learnt Z80 after years of writing PS1 games in C since I'd always wished I had been able to do it when I was a teen. Was probably nearly 40 when I started lol ;)

I was too young to work professionally as a games programmer when I was a teen, my Spectrum broke when I was 17 (so went the pub instead from then on lol). It was only after uni/going on an employemt training course to learn C - then the most in demand job skill (and easy because I already knew pascal) I got a job as a PS1 programmer by mistake :) Didn't even own a PC until my mid 30s I think! Mathematicians did all their computing on paper back then ;)

EDIT: One thing studying maths does though is it teaches you how to think logically and rigorously. (I also think of loads of mad stuff then realise I was wrong about it and have to edit with corrections lol - but I always try and point out whereabouts my argument falls down - another thing maths teaches you - you will make a ton of mistakes, that's fine, just make sure you correct yourself and don't double down on a mistake - which a lot of people who did CS at uni seem to be bad at...)
catmeows
Manic Miner
Posts: 716
Joined: Tue May 28, 2019 12:02 pm
Location: Prague

Re: Abersoft fig-Forth Recompiled

Post by catmeows »

I think Jetpack (and other Ultimate games) erase and draw sprite at the same time, line by line. It sounds like horrible idea but sprites usually move just a little bit so this method basically replaces flickering by possible tearing. Well, you can check how it looks on YT yourself.
Proud owner of Didaktik M
User avatar
ParadigmShifter
Manic Miner
Posts: 666
Joined: Sat Sep 09, 2023 4:55 am

Re: Abersoft fig-Forth Recompiled

Post by ParadigmShifter »

Jonathan Cauldwell also mentioned what he does for AGD sprites on the other forum here:

https://worldofspectrum.org/forums/disc ... nt_1013240

^ which is what poster above is going on about, Jonathan borrowed that from Ultimate way of doing it after being informed of it by Joffa
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

by the way, my first contant with Forth was on ZX. i had… yeah, Abersoft Forth, pirated of course, without any documentation. and i had no idea what that "Forth" was. it was on a cassete with other languages (LISP, HiSoft Pascal, etc.), so it was definitely some language, but… what to type there?

and then, by sheer luck, i got Leo Brodie book "Starting Forth". suddenly, i realised what a gem i have in my hands!

i already knew BASIC, Pascal and a little of Z80 asm by that time, so i wasn't scared by stacks and such. Forth was small, Forth was fast (much faster than BASIC!). and i immediately wrote a font editor with it (i was obsessed with font editors at that time, and wrote 3 or 4 in BASIC already ;-).

then i had to abandon Forth for a long time, because nobody even know that such language existed. but i never really forget about it.

now i am using the 3rd incarnation of UrForth (UrForth/Beast: Devastator) to program my x86 PC. and this is prolly the first Forth system i am completely happy with.

by the way, the main reason to develop the original, first UrForth was cross-development for ZX. and now, years later, i am doing exactly this, and with UrForth! ;-)
User avatar
ParadigmShifter
Manic Miner
Posts: 666
Joined: Sat Sep 09, 2023 4:55 am

Re: Abersoft fig-Forth Recompiled

Post by ParadigmShifter »

I think LISP is probably better as a "programmers" language than Forth (since you can also compile it, but it relies on reference counting or garbage collection as well) of course it's a pain to parse! And the scope of variables is just bonkers innit. (I think Scheme probs sorted that out though?).

Also (singly!) linked lists are pretty crappy especially on 8 bit machines, and terrible these days with caches, you don't want to be following pointers to nearly anywhere, you want to be using contiguous arrays of data.

Crash Bandicoot and Jak and Daxter were written in a variant of LISP (although the person who did most of the coding was one of the world's best Lisp programmers at the time I think). They did it properly though with most speed critical routines having switches for which register to assign to which local variable and such. Also they could recompile parts of the code, squirt it to the PS1/PS2 and the code would then use the new definition immediately WHILE THE GAME WAS STILL RUNNING!!!

When Sony bought Naughty Dog they were like OMG WTF ARE YOU DOING we hoped to be able to share some of your code with our other studios so they made them shift to C++ (which is a horrible horrible language to code in). I'm mainly doing Unity so C# now :)

EDIT: I have said many times though if I was writing a scripting language for the speccy I would turn it into some kind of forth at the lowest level (I just would write a simple parser on the PC that turns non Forth code into Forth like compiled data for use on the speccy).
Last edited by ParadigmShifter on Wed Apr 03, 2024 12:07 am, edited 2 times in total.
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

catmeows wrote: Tue Apr 02, 2024 11:45 pm I think Jetpack (and other Ultimate games) erase and draw sprite at the same time, line by line. It sounds like horrible idea but sprites usually move just a little bit so this method basically replaces flickering by possible tearing. Well, you can check how it looks on YT yourself.
with Jetpack they had no luxury to use custom interrupt handler, because of 16KB.

yet i implemented line-by-line approach, and it mostly worked. i just wasn't happy with it, and wanted something more advanced.
ParadigmShifter wrote: Tue Apr 02, 2024 11:47 pm Jonathan Cauldwell also mentioned what he does for AGD sprites on the other forum here:
https://worldofspectrum.org/forums/disc ... nt_1013240
thank you! that's basically what i am planning to do too (including sprite sorting).

my engine actually redraws only the sprite which is moved, so the user can control how much rendering will happen. there is a list of sprites to update in the interrupt handler, and the handler clears the list when it's done. so updater simply prepares the new data structure, and puts it into render list.

i will prolly limit rendering to 5 or 6 sprites per frame, sort that chunk, and blit it.
User avatar
ParadigmShifter
Manic Miner
Posts: 666
Joined: Sat Sep 09, 2023 4:55 am

Re: Abersoft fig-Forth Recompiled

Post by ParadigmShifter »

ketmar wrote: Wed Apr 03, 2024 12:03 am with Jetpack they had no luxury to use custom interrupt handler, because of 16KB.

yet i implemented line-by-line approach, and it mostly worked. i just wasn't happy with it, and wanted something more advanced.


thank you! that's basically what i am planning to do too (including sprite sorting).

my engine actually redraws only the sprite which is moved, so the user can control how much rendering will happen. there is a list of sprites to update in the interrupt handler, and the handler clears the list when it's done. so updater simply prepares the new data structure, and puts it into render list.

i will prolly limit rendering to 5 or 6 sprites per frame, sort that chunk, and blit it.
Defo do the sort at the end of the frame though ready for the next frame, don't attempt to sort whilst drawing.
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

ParadigmShifter wrote: Wed Apr 03, 2024 12:00 am I think LISP is probably better as a "programmers" language than Forth
they aren't that different, actually. both basically provide a "raw" low-level access to some imaginary virtual machine, and you can build your code upon that. Forth is simplier, though, and easier to implement. and faster. ;-)
ParadigmShifter wrote: Wed Apr 03, 2024 12:00 am Crash Bandicoot and Jak and Daxter were written in a variant of LISP (although the person who did most of the coding was one of the world's best Lisp programmers at the time I think). They did it properly though with most speed critical routines having switches for which register to assign to which local variable and such.
UrForth (with the help of Succubus) generates direct x86 machine code too. it is only ~2.2 times slower than GCC -O2. actually, it is faster than this, because Forth code is quite different from C, i deliberately tested it on "C-like" code, not on proper Forth programs.

and i am planning to implement even better native compiler for UrForth (Succubus Reincarnated ;-).
ParadigmShifter wrote: Wed Apr 03, 2024 12:00 am Also they could recompile parts of the code, squirt it to the PS1/PS2 and the code would then use the new definition immediately WHILE THE GAME WAS STILL RUNNING!!!
yeah, it is quite easy with such languages as LISP or Forth. especially when you have the full control over the compiler (i.e. wrote the compiler yourself).

also, build times! UrForth system (with Succubus) is ~500 KB of source code. i can recompile it in 60 milliseconds (80 with assembler and Uroborus target compiler). yes, MILLIseconds. way faster than some modern software boots from the compiled binary, lol.
User avatar
ParadigmShifter
Manic Miner
Posts: 666
Joined: Sat Sep 09, 2023 4:55 am

Re: Abersoft fig-Forth Recompiled

Post by ParadigmShifter »

Yeah they wrote all their compilers and debuggers themselves, in LISP.

Mad lads ;)

They also didn't use any of the Sony provided libraries to save lots of memory.(libraries admittedly pretty crappy at first, on the PS1 at least - PS2 was so hard to program people took weeks to draw a triangle on screen at first I think lol). They reverse engineered the Sony libs and rewrote the bits they needed in LISP (or ASM).

They basically had DLL style loading of code and graphics from the off on PS1 which we didn't really do until the end days of PS1.

EDIT: This is worth watching if you haven't seen it

User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

ParadigmShifter wrote: Wed Apr 03, 2024 12:05 am Defo do the sort at the end of the frame though ready for the next frame, don't attempt to sort whilst drawing.
sadly, this is something i cannot afford. i don't want the user to call any "LETS-END-THIS-FRAME" routine manually, so i have to sort everything right before i draw it. and "SPR-UPDATE" routine cannot perform sorting too, because the interrupt may be triggered anytime. so the best place to sort everything is right in the interrupt handler.

but sorting 6-7 sprites should not be that slow. actually, i don't even have to properly sort them all: what i need is to select 3-4 sprites closest to the top of the screen, and render them first, in any order. by that time the ray will start updating the screen, so i can find and process another batch. i have to write it and check if it will work as i expect it to work, but i think that "rough batching" approach will do the trick.
User avatar
ParadigmShifter
Manic Miner
Posts: 666
Joined: Sat Sep 09, 2023 4:55 am

Re: Abersoft fig-Forth Recompiled

Post by ParadigmShifter »

ketmar wrote: Wed Apr 03, 2024 12:21 am sadly, this is something i cannot afford. i don't want the user to call any "LETS-END-THIS-FRAME" routine manually, so i have to sort everything right before i draw it. and "SPR-UPDATE" routine cannot perform sorting too, because the interrupt may be triggered anytime. so the best place to sort everything is right in the interrupt handler.

but sorting 6-7 sprites should not be that slow. actually, i don't even have to properly sort them all: what i need is to select 3-4 sprites closest to the top of the screen, and render them first, in any order. by that time the ray will start updating the screen, so i can find and process another batch. i have to write it and check if it will work as i expect it to work, but i think that "rough batching" approach will do the trick.
Can't you use a callback function or something for end of game logic/start preparing next frame?

EDIT: There's never any problem which can't be solved by using an extra level of indirection is what Knuth said I think? Or maybe Djikstra...
User avatar
ketmar
Manic Miner
Posts: 697
Joined: Tue Jun 16, 2020 5:25 pm
Location: Ukraine

Re: Abersoft fig-Forth Recompiled

Post by ketmar »

ParadigmShifter wrote: Wed Apr 03, 2024 12:23 am Can't you use a callback function or something for end of game logic/start preparing next frame?
this will limit the ways to use the system. the idea is that you can move the sprites anywhere in your code, when you want it, not when the system wants you to do it. you command — the system obeys, not vice versa. ;-)

i want to let the user to split the game logic code as they want to, and to interactively debug any part of it. call "MOVE-NASTY" word from the interpreter prompt, and see the nasty made one step, for example. and so on.

just don't forget that we have a language that is both compiled and interpreted. interactive debugging is the important part of Forth programming, i don't want to throw it away.
Post Reply