Spectrum Computing

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

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

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.

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

Spoiler

Will that still work if the +3DOS ROM is paged in? i am cheating by switching to IM1 when calling +3DOS. not that you can do much while +3DOS does its business anyway. Is there actually a guaranteed 257 byte ramp containing FFh at the same addresses in every ROM? it is still there in 48K BASIC, whi...

goodboy wrote: ↑Sun Apr 14, 2024 10:51 am on the 128k machine you can use im1 for your code subroutine

but only if you have 128K ROM paged in, otherwise SWAP is not called.

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

also note that by destroying sysvars you won't be able to use +3DOS. you need to call ROM interrupt handler to eventually turn drive motor off, and it uses some other sysvars too. tbh, i never bothered to get rid of sysvars, and i don't think you need to. ;-) hey, you wasted 257 bytes on interrupt t...

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

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

ok, cross-copiler can create +3DOS .DSK image now. and the system even starts from it! ;-) the writer supports all 4 kinds of disks, and uses 720K disk by default. now i have to write +3DOS interface code.

thank you! it is more than i had, but sadly, slightly less than i hoped. ;-) i totally forgot why TR-DOS has its buffer there, what memory map with TR-DOS is, what system vars will be corrupted, and so on. (not that i ever really wanted to know it, because i haet TR-DOS with a passion. ;-) but it is...

if you want to use system vars for your code, you will need your own interrupt handler. ROM handler expects IY to point to sysvars area, and hopes to find some sysvars there (FRAMES, keyboard state). also, if you are using RST #10 for printing, you will need sysvars too (and some other ROM routines ...

i HAET writing disk image tools. but i can load .DSK image now, list +3DOS directory, and even read files. the fun thing is that i don't need any of that, because i only need to create .DSK images. everything went wrong yet again. ;-)

This is pretty awesome. thank you! ;-) I have low energy and motivation for anything these days. I used to do computer/nerd stuff all day but I've changed. hey, isn't coding for Z80 one of the best ways to rest? ;-) I did try reading the fig forth manual but it was similar to shorthand, just tons o...

does anybody remember the trick iS-DOS used to "autoboot" on TR-DOS from non-standard disk format? i bet it is something with having a sector bigger than 256 bytes, which overwrites… something. of course, i can reverse it myself, but being old fat lazy fart i hope that somebody already did...

added Joffa's SFX engine from Saucer. the good thing about it is that it is simply uses the time left to the interrupt to produce some noise, so if you time your game logic right, you can produce some easy sfx for shots and such. it may slow the game down a little if you are not syncing to intrs, bu...

hey, but we have a disk storage! used block #60 to store property names, so they need not to be hardcoded into the editor. https://files.catbox.moe/o5wxf1.png looks ugly, but much better than numbers, i believe! ;-) also, changed sprite definition format (added Yet Another Indirection ;-), and integ...

CLEAR 24575 now the stack is <$6000. anyway, it depends of your code. if you're using BASIC, then "CLEAR" at the appropriate address. the BASIC will never use anything out of this range (well, it may corrupt a byte or two at $6000 due to ROM bugs on a very rare occasion. not something you...

implemented tile property editor window:

Spoiler

tile types mean nothing to the editor, so they are numbered.

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