Hello, friend. How I can save screen background and move objects without erase (like game) in TRS-80 ? In BASIC I can with PEEK and POKE or only Assembly ?
Unfortunately I think BASIC PEEK/POKE will be too slow (unless maybe you just use a very small portion of the screen, like maybe 10×10 only). My code was in C language that was compiled to Z80 assembly.
The approach I used is not quite “double buffered” (like more modern systems will use that with H/W support for it)… In my approach I keep a copy of the map in memory (so that’s use 1K RAM). Then I have two “scratch pad” sections of memory: a bit mask to mark which cells have been modified, then another sections of RAM reserved to store which locations (x,y) were modified (and the target symbol to modify them to). The length of that RAM just depends on how large of icons/cells you want to support (I chose vector of 34). But for performance reasons with these limited 1mhz processors, the real “trick” was avoiding any / (divide) and % (multiply) call by using pre-computed tables (like when deciding which cell_state bit corresponds to which x/y screen coordinate).
Sorry it’s not a real easy explanation. I think the same concept could be done in BASIC (using DIM and DATA statements to reserve RAM for tables), and the same bit-logic could be used — but it’ll be interpreted and just won’t be able to run fast enough at 1mhz to be a smooth movement.
Nice game, though I’m having problems with it. I’ve tried it on my PET 4032, but it keeps crashing. On the STRZYGA screen it gave this:
PC IRQ SR AC XR YR SP
100E E455 31 52 7E 01 F2
And on SLUAGHS I got:
PC IRQ SR AC XR YR SP
0F09 E455 31 52 7E 01 F2
It’s crashed every time I get to SLUAGHS, though I’m not sure if the error details are the same. I’ve only played STRZYGA once, but I expect that will crash every time, too.
Also, when I was choosing type 4 at the beginning I wasn’t seeing a second enemy on the first screen. With type 6 that seems to work.
Is it incompatible with the PET Wedge program that makes directory navigation easier? I could try putting it in the root directory and doing a DLOAD to see if that works.
I’m on travel this week and can’t get to my physical PET. Do you have any other program that is over 16KB? (i.e. any PRG that is over 16KB) Just to try and see if they are also having any runtime crash. If other large programs are running fine, then probably the RAM chips are ok. But that gives me an idea, maybe we need to write a RAM tester program for the PET – I’m not sure if anyone has done that. It would just go to every address and try to write, then confirm if it read back what was written. Also I should probably establish some CRC codes to help identify which version people are running (for the PET there should be only one “final” version – but there were a few beta releases just prior to that and at least one “modded” version I think is floating around). Persona selection shouldn’t have any impact to the number of creatures/challenges, so that is suggesting to me a bad RAM chip issue. When I get back home next weekend I try it with Wedge – typically in testing I never did try with Wedge. I don’t think it should effect it – but it is possible. I’ve actually never seen a PET crash like that, I wonder if the output you are seeing is a Commodore ROM output, or something that is part of the cc65 build system. Thanks for the note – sorry can’t be more helpful at the moment, but will definitely look into it next weekend when I can get back to the physical PET to try things out.
I ran some memory test programs. One from Tynesoft (I think it came with my SD2PET card), gets stuck if I have the wedge running, but gives no errors when it works. 4032TEST highlights “D8 00”, but I don’t know what that means, and all other games work.
So I ran DHunter without the wedge program and it’s been working great! I’ve finished it on the two easiest levels, then died on the normal one. I think I got the Orb, but forgot to use it I’ll put a video up on my YouTube channel, but I’ll leave off the Orb being used so as not to spoil it, unless you want me to (if I can get it again on a harder level).
Nice, thanks for the update! One reason I made DestinyHunter the way it is, is because I’d like to someday see folks do a “speedrun” of the game (there are some who take that very seriously, with some overlay times to accurately measure time at each level/portion of a game). For example, I’m not sure if under 2 minute win is possible (on a stock/standard system, of course). My ultimate dream was to have WiModem232 support to upload your results to a server, and collect metrics on which persona was truly more efficient at playing the game – but then I couldn’t make it a standalone 32K game (and would instead probably need a fully floppy). And gosh, I’ve done that too, forgetting to use the Orb!! Haha
Destiny Hunter
Testing! Hello!
LikeLike
Hello, friend. How I can save screen background and move objects without erase (like game) in TRS-80 ? In BASIC I can with PEEK and POKE or only Assembly ?
LikeLike
If possible, consult my PDF document here. It is not specific to TRS-80, but gives general outline of the strategy I used for moving objects on the text screen: https://github.com/voidstar78/DestinyHunter/blob/main/doc/strategy%20for%20flicker-free%20heterogeneous%20multi-cell%20icon%20animationV3.pdf
Unfortunately I think BASIC PEEK/POKE will be too slow (unless maybe you just use a very small portion of the screen, like maybe 10×10 only). My code was in C language that was compiled to Z80 assembly.
The approach I used is not quite “double buffered” (like more modern systems will use that with H/W support for it)… In my approach I keep a copy of the map in memory (so that’s use 1K RAM). Then I have two “scratch pad” sections of memory: a bit mask to mark which cells have been modified, then another sections of RAM reserved to store which locations (x,y) were modified (and the target symbol to modify them to). The length of that RAM just depends on how large of icons/cells you want to support (I chose vector of 34). But for performance reasons with these limited 1mhz processors, the real “trick” was avoiding any / (divide) and % (multiply) call by using pre-computed tables (like when deciding which cell_state bit corresponds to which x/y screen coordinate).
Sorry it’s not a real easy explanation. I think the same concept could be done in BASIC (using DIM and DATA statements to reserve RAM for tables), and the same bit-logic could be used — but it’ll be interpreted and just won’t be able to run fast enough at 1mhz to be a smooth movement.
LikeLike
Nice game, though I’m having problems with it. I’ve tried it on my PET 4032, but it keeps crashing. On the STRZYGA screen it gave this:
PC IRQ SR AC XR YR SP
100E E455 31 52 7E 01 F2
And on SLUAGHS I got:
PC IRQ SR AC XR YR SP
0F09 E455 31 52 7E 01 F2
It’s crashed every time I get to SLUAGHS, though I’m not sure if the error details are the same. I’ve only played STRZYGA once, but I expect that will crash every time, too.
Also, when I was choosing type 4 at the beginning I wasn’t seeing a second enemy on the first screen. With type 6 that seems to work.
Is it incompatible with the PET Wedge program that makes directory navigation easier? I could try putting it in the root directory and doing a DLOAD to see if that works.
LikeLike
I’m on travel this week and can’t get to my physical PET. Do you have any other program that is over 16KB? (i.e. any PRG that is over 16KB) Just to try and see if they are also having any runtime crash. If other large programs are running fine, then probably the RAM chips are ok. But that gives me an idea, maybe we need to write a RAM tester program for the PET – I’m not sure if anyone has done that. It would just go to every address and try to write, then confirm if it read back what was written. Also I should probably establish some CRC codes to help identify which version people are running (for the PET there should be only one “final” version – but there were a few beta releases just prior to that and at least one “modded” version I think is floating around). Persona selection shouldn’t have any impact to the number of creatures/challenges, so that is suggesting to me a bad RAM chip issue. When I get back home next weekend I try it with Wedge – typically in testing I never did try with Wedge. I don’t think it should effect it – but it is possible. I’ve actually never seen a PET crash like that, I wonder if the output you are seeing is a Commodore ROM output, or something that is part of the cc65 build system. Thanks for the note – sorry can’t be more helpful at the moment, but will definitely look into it next weekend when I can get back to the physical PET to try things out.
LikeLiked by 1 person
I ran some memory test programs. One from Tynesoft (I think it came with my SD2PET card), gets stuck if I have the wedge running, but gives no errors when it works. 4032TEST highlights “D8 00”, but I don’t know what that means, and all other games work.
I’ll put a video up on my YouTube channel, but I’ll leave off the Orb being used so as not to spoil it, unless you want me to (if I can get it again on a harder level).
So I ran DHunter without the wedge program and it’s been working great! I’ve finished it on the two easiest levels, then died on the normal one. I think I got the Orb, but forgot to use it
LikeLiked by 1 person
Nice, thanks for the update! One reason I made DestinyHunter the way it is, is because I’d like to someday see folks do a “speedrun” of the game (there are some who take that very seriously, with some overlay times to accurately measure time at each level/portion of a game). For example, I’m not sure if under 2 minute win is possible (on a stock/standard system, of course). My ultimate dream was to have WiModem232 support to upload your results to a server, and collect metrics on which persona was truly more efficient at playing the game – but then I couldn’t make it a standalone 32K game (and would instead probably need a fully floppy). And gosh, I’ve done that too, forgetting to use the Orb!! Haha
LikeLike