Spectrum Computing

just to add more confusion to the thread: with +3 one can page in 16K RAM at $0000 (instead of ROM). yay. all go +3! ;-)

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… ;-)

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

started implementing room editor…

Spoiler

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

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

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

@R-Tape, wow! a nice platformer i never knew about! despite… let's say, not the best graphics, it is suprisingly fun to play. thank you!

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

tile gfx editor GUI:

Spoiler

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

windows, buttons, arrow: https://files.catbox.moe/qu5fzy.png the arrow is interrupt-driven (reading new mouse coords, repainting), everything else is in Forth. hot areas are specified like this: ;; demo hot area create hot-test ( x) -4 c, ( y) -1 c, ( text) ," OK " ( udata) 0 , ( x) -11 c,...

as i need to build rooms somehow, let's build the room builder! of course, with kempston mouse, because i refuse to use any kind of such visual editor without a mouse. lucky me: ZXEmuT has API to read and write host files, so i don't have to mess with snapshots. for others it will be the usual block...

screenshot:

Spoiler

also, sprites are rendered from their borrom line now. and sprite origin is its bottom line: i used to this in XTE, and i believe that it is more useful than "origin at the top" mode.

implemented sprite attributes, and property map. property map covers the whole screen (32x24), and if bit 7 in property byte is set, it means "don't replace attributes". this map can also be used for other tile properties, like "passable" and such. currently, attribute mask for s...

trying to optimise things a little, and add attribute control. but for this we need 768-byte "screen property map", so the engine could skip overwriting tile attributes. this map can be put in contended memory, i believe, because it is not heavily used. for now, i can (re)print 11 sprites ...

16-sprite PoC tech demo . control code is in Forth, of course. updating 9 sprites per interrupt. the main control loop is exactly: : xi 1 BORDER SPR-SETUP \ CLS CR CR CR ." \cpress SPCACE to pause animation.\nuse kempston to move.\n" #XI . ." sprites, and the player." SPR-ON 0 L...

I think it's probably also important to add that when you say "your stack stays in the old one" what you really mean is "all the data that was on the stack stays in the old bank but the Z80 thinks whatever random data is in the same addresses in the new bank is what was on the stack&...

found bugs in "2SWAP" and "<>". two almost useless words, lol. and some trivia to make this post bigger: did you know that ZIP Compiler basically translates BASIC to Forth, and then compiles Forth to machine code, with top of the stack cached in HL? it is possible to write a nati...

also, while i am here: i stole some sprites for tests from All Hallows . of course, i will remove them for the release, just wanted to recomend you a fun game. ;-) p.s.: btw, i hope you're all enjoying reading this "dev diary" (or at least not annoyed by it too much ;-). sorry if i spam wi...

so, i wrote the code to queue sprites, to sort the queue to 3 batches, and to blit the batches. i implemented one additional check: if the bottom batch doesn't have enough sprites (currently "no sprites", but i will prolly change it to "2" or something), i am blitting the mid bat...

You could do everything else you want to do 50 times a second immediately after the drawing routines, they would still be happening every 1/50 of a second, just ~128 scan lines after the interrupt itself. yes, you are right. but there can be less than 4 sprites to update. i don't want to waste time...

ParadigmShifter , optimisations will come later. at first, i want the main code up and working. ;-) David Webb's routines from his book Advanced Spectrum Machine Language will print 40 characters with attributes before the main screen starts being drawn. That's ten 16x16 sprites on character bounda...

so i decided to draw sprites in batches by 8 sprites per interrupt. let's hope it will be enough. (i may adjust this number after testing, tho.) interrupt handler will take first 8 sprites from the queue, and sort them in 3 sub-batches: one sub-batch per 1/3 of screen$. it won't sort sub-batches the...

I was assuming that all the entry points to the sprite routines for Machine Lightning would be exposed so you could call them from your own assembler or otherwise compiled code… or is that not what you're seeking to do? sorry, but i need full disassmbly, so i could re-assemble everything to any add...

p.s.: i mean, my sprites are "hardware" in the meaning that you cannot get back the sprite position or gfx after you updated it. it is like doing OUT to some write-only hardware ports: you put new values there, and that's it. if you need to track any info about your sprites, then do it you...