Spectrum Computing

just look at SP in debugger. ;-)

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

sludge wrote: ↑Wed Apr 10, 2024 6:06 am My coding skills are quite shocking, I doubt I know how to use any more than twenty Z80 commands properly.

more than enough! "LD" alone occupies about 1/3 of the whole non-prefixed instruction set! ;-)

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.

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

that's how i detect kempston joystick in my code. HL is 0 if no kemprson joystick present, 1 otherwise. ld hl, # 0 ;; zero flag xor a ;; wait for the interrupt to avoid floating bus issue halt in a, () $1F ;; $FF? nothing's here inc a \ jr z, # .done ret z ;; test for some invalid values dec a ld e,...

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

properly stolen room from Rex. now it looks like The Real Editor! ;-) https://files.catbox.moe/c0kvbr.png 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 implem...

the best thing with Speccy b/w is that it is a nice shade of gray, ideal to implement fadeins and fadeouts: just inc/dec. which i did a lot in my programs with small z80 code snippets… and then i saw it on a color tv. had to remove all fades. ;-)

Personally I've always really loved the colours in Rick Dangerous. oh, memories… when i first played R.D., i had b/w display. yay, no color problems at all! i still can't convince myself that this colorful Rick is the same i played. because i spent literally monthes playing, i learned everything, a...

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