flange , thank you for your support! yep, "advanced" comparisons are not properly tested yet, thank you. they weren't in the original, and i wrote the code in "blind mode", just to have something there. ;-) as for not popular language… i am using x86 Forth system on daily basis ...
by the way. WIP version to play with: download .TAPs . WARNING! this is NOT final! it should work, but there may (and will) be some bugs. there are 3 .TAP versions, all with demo game. WARNING! demo game works only in 32cols mode. to load demo game, use: "LOADT 1 LOAD" source code will be ...
also, there will be a target cross-compiler which creates "turnkey" apps, omiting all headers, and all unused words. but you'll need x86 GNU/Linux to use it.
nope, "main system size" is total size (bad description, i know ;-). 16 kb with all bells and whistles. can be much smaller if various optional parts are turned off. p.s.: note that even with RAM-DISC you'll have ~13 kb for your code (this is about as much as the original Aberforth had). a...
hm. i decompiled Forth part of White Lightning, and it looks quite interesting. the usual fig model code is intact (of course), along with several standard fig inefficiencies. but the added code looks way more interesting. for exampe: it contains two "AT" implementations, absolutely identi...
fun fact: for some reason White Lightning has around 40 hidden words. they are not linked to any vocabulary, but have valid headers and names (and they are referenced from other, visible words). it looks like that system wasn't cross-compiled from some asm source code, but created in several stages....
ported ROM floating point library from dsForth. for ~1KB of code you'll have full floating point support, backed by ROM calculator. because why not? ;-)
i know, i know, Chuck Moore said that floating point math is for wimps. but hey, i don't have to write my own FP code in asm anyway! ;-)
It'll be cool to see the example game. it is the one supplied with Mastertronic re-release. that tape contains RAM-DISC image, you can load it with "LOADT", and then use "1 LOAD" to load the game. but beware: the game completely sux. ;-) So if i read the manual to fig forth I wo...
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. ;-) https://files.catbox.moe/xxnhla.png the editor works in any mode, though (32, 42, 64). it has line yank/insert, and nice incremental search. by th...
i am preparing poc v2, btw, with many decompilation bugs fixed. i managed to cut demo game compiling time from ~40 seconds to ~20 seconds. the change is very simple: i put LFA field before NFA. i don't know why Bill Ragsdale decided to organize word headers this way, but the effect is that "(FI...
several Forth CPUs had various interesting… solutions, including minimalistic instruction sets, superscalar CPUs, VLIW CPUs… and most of them are even more minimalistic than minimalistic RISCs! ;-)
as i played with AberForth , i also created Yet Another decompiled version of it. there were other decompiled versions, but mine has something new to offer. ;-) * rebased to $6000, so it can be used with TR-DOS (no TR-DOS support included yet). * removed some unused FIG-Forth parts ("MON",...
I didn't think of calling "stc-to-dstack" and calling "stc-to-rstack" to switch SP contents. When I initially tried different variants of how to use SP, I was told that changing SP is not worth it. it doesn't worth it with the traditional STC code. but Succubus does very aggress...
i bet that the only game that may pass is a crap one. prolly even in BASIC. and there is no reason to do it, because it won't be a "hidden gem", people will barely notice. the thing is that it's not so hard to spot modern games disguised as old ones. graphical style, programming style, all...
And I solved your code for days. this is because you had tried to decipher the output of highly optimising compiler. take GCC -O3 output, for example, and try to "decompile" it back to C code. it will be very hard to do, because the compiler transformed the original code into something ba...
I've been trying for days (!!!) to understand that code. ah, it's mostly straightforward. i omited some helper routines, tho. You don't use do..loop loops, so I replaced them with the closest equivalent, namely begin..while..repeat and begin..until yeah, i am not a big fan of DO/FOR, and sometimes ...
by the way, it is possible to do this (copy the whole screen in one frame) on Pentagon. it has slightly more tstates per frame, and no wait states. but you have to load values directly into registers in blit routine, so drawing to such backbuffer is a PITA, and will kill the performance anyway. but ...
eh. just take a look at Firefly. 8-direction scrolling (actually, there is no "scrolling" there, the engine can draw the map from the arbitrary coordinates). 25 FPS, JIT-compiled blitter, and many, many different maps, all in 48k. i once extracted that engine and turned it into reusable, w...
yep, i agree: drawing behind the raster is way easier. you'll have ~14K tstates to prepare: jit-compile your render code, sort sprites, play some music, and so on. and then you can render everything without worrying about raster at all. even if your render code will take more than 69K tstates, it do...
btw. if you are scrolling by 8 pixels a time, and you see attribute flicker, then you need to rewrite your scoll routines. do not scroll attrs and gfx separately: copy one char, and then immediately copy its attribute. that's if i understood you right.