Show Posts
76
General discussion / Re: First Post?
« on: March 03, 2004, 05:09:44 pm »
Oh. Didn't know how this worked. Sorry... 
|
 |
Test.TestTestTestTestTestTestTestTestTestTestTestTestTestTestTest |
 |
|
ControlTextTest.TestTestTestTestTestTestTestTestTestTestTestTestTestTestTest |
|
Dude. You need something to resize your text. (not that it matters...)
79
Escheron: Shadow over Ragnoth / Re: Escheron: Shadow over Ragnoth
« on: February 25, 2014, 02:01:13 pm »
There was actually some suggestions in HCWP (off-day) that involved using MD5 hardware and messing around with the certificate page. I suggested writing to the boot code if the calc is a newer model, but that suggestion got shot down and I then suggested writeback to the app.
I don't think I'm going to make the protection too strong, but I am going to make it such that if you want to cheat, you're gonna have to work at it.
I don't think I'm going to make the protection too strong, but I am going to make it such that if you want to cheat, you're gonna have to work at it.
80
Escheron: Shadow over Ragnoth / Re: Escheron: Shadow over Ragnoth
« on: February 24, 2014, 10:46:39 pm »
I'm still going to keep the old assets as it's just another folder. An additional project can be made in b/w, but after the subproject is finished. People are expecting a full 4 level grayscale game, and they've been waiting for it for ages. We're gonna deliver that at some point.
Also, I wouldn't be worried about save scumming on the calcs, since most of the time, yanking a battery while running a typical assembly program results in data loss. Most people wouldn't think of doing something like that to try save scum. They might do things such as rename/copy files. If you wanted to protect against save scumming, you would want to keep something of a counter on hand to check against the version of the save file being presented. If there's a mismatch, then you could call them out on it.
Also, I wouldn't be worried about save scumming on the calcs, since most of the time, yanking a battery while running a typical assembly program results in data loss. Most people wouldn't think of doing something like that to try save scum. They might do things such as rename/copy files. If you wanted to protect against save scumming, you would want to keep something of a counter on hand to check against the version of the save file being presented. If there's a mismatch, then you could call them out on it.
81
Escheron: Shadow over Ragnoth / Re: Escheron: Shadow over Ragnoth
« on: February 23, 2014, 07:02:55 pm »
A subproject is currently being worked on, which has largely been kept a secret until now. We call it Aegis-Rin.
Try not to think too hard about the name. I didn't when I named it.
In short, it's planned to be a fully modular RPG engine. Me and geekboy has this entire project planned out and are working towards the goal of completing it in a reasonable time.
What we have: Text script system (fully programmable, with its own stack and registers), custom font driver, tilemap renderer and loader, tileset loader, an honest-to-god sprite routine (!), movement and collision detection.
What we don't have yet: Event system (current tile ID, current position [hotspot], timer-based (either realtime or based on steps/actions), interact-key), example scripts to recreate things such as menu systems and NPC dialog, and the PC-side tools needed to pull together the data needed for the loaders to work.
At the end of this subproject, we will have created a fully functional test RPG that does all the things that a much larger RPG (such as E:SoR) should be able to do. The test should be short, easy, and silly. Hint: It's about cherries.
Try not to think too hard about the name. I didn't when I named it.
In short, it's planned to be a fully modular RPG engine. Me and geekboy has this entire project planned out and are working towards the goal of completing it in a reasonable time.
What we have: Text script system (fully programmable, with its own stack and registers), custom font driver, tilemap renderer and loader, tileset loader, an honest-to-god sprite routine (!), movement and collision detection.
What we don't have yet: Event system (current tile ID, current position [hotspot], timer-based (either realtime or based on steps/actions), interact-key), example scripts to recreate things such as menu systems and NPC dialog, and the PC-side tools needed to pull together the data needed for the loaders to work.
At the end of this subproject, we will have created a fully functional test RPG that does all the things that a much larger RPG (such as E:SoR) should be able to do. The test should be short, easy, and silly. Hint: It's about cherries.
82
The Axe Parser Project / Re: Is it possible to execute asm within Axe/Is there a bit rotation asm program?
« on: January 22, 2014, 04:22:20 pm »
The routine for a 16-bit left rotation is:Asm(7D29176F)
The routine for a 16-bit right rotation is: Asm(7D1FCB1CCB1D) (courtesy of calc84maniac)
By "add them together", do you mean the arithmetic operation "add" or the combining of the two binary strings (concatenate) ? From what you're saying, you want each to be rotated individually in the absence of each other? If that's the case, then you'll want something completely different than what we've supplied.
You'll want the individual opcodes for RLC L / RRC L / RLC H / RRC H. For further information, try looking at this opcode reference: http://www.ticalc.org/pub/text/z80/opcodes.txt
What is it that you're trying to accomplish?
The routine for a 16-bit right rotation is: Asm(7D1FCB1CCB1D) (courtesy of calc84maniac)
By "add them together", do you mean the arithmetic operation "add" or the combining of the two binary strings (concatenate) ? From what you're saying, you want each to be rotated individually in the absence of each other? If that's the case, then you'll want something completely different than what we've supplied.
You'll want the individual opcodes for RLC L / RRC L / RLC H / RRC H. For further information, try looking at this opcode reference: http://www.ticalc.org/pub/text/z80/opcodes.txt
What is it that you're trying to accomplish?
83
The Axe Parser Project / Re: Is it possible to execute asm within Axe/Is there a bit rotation asm program?
« on: January 22, 2014, 02:13:19 pm »
If individually, the answer becomes fairly trivial. That would be an RLC/RRC ... something on each byte. As a combined unit, you'll have to have a loop of RL/RR's traversing the area that needs to be rotated with the very first byte of it being saved someplace so when the loop ends, you can rotate the trailing bit into that and reload that as the first bit to simulate a complete rotation.
84
The Axe Parser Project / Re: Is it possible to execute asm within Axe/Is there a bit rotation asm program?
« on: January 22, 2014, 01:59:58 pm »
EDIT: Mat isn't here to edit his post. There was a problem in what I posted before and the converted first routine should have actually used RLA instead of RRA. The corrected routine is thus: Asm(7D29176F)
Many apologies
Many apologies
85
The Axe Parser Project / Re: Is it possible to execute asm within Axe/Is there a bit rotation asm program?
« on: January 22, 2014, 01:51:46 pm »-.- Yes, and this removed bit goes in the carry flag.Aren't you thinking of RR/RL? Those instructions are a 9-bit shift/rotate, the 9th bit being the carry flag.I can't see any point to using rotation instructions since you don't have control on the carry flag anyway.
The instruction mentioned in the OP is RLC, which while it does do stuff with the carry flag, it does not by any means use it for anything. It is an 8-bit rotation and the bit that leaves appears immediately on the other side.
Now, extending this idea into 16 bits is a bit ... trickier, but can be accomplished with a short ASM routine, none of which ever leaves the routine, so the whole issue about carry is moot.
Code: [Select]
;Left rotate HL circular, cheap method
ld a,L
add hl,hl
rla
ld L,a
;Right rotate HL circular
ld a,h
rr h
rr L
rra
ld h,a
It's up to you to convert that to hex, tho.EDIT: Problem with the first routine after the next post was posted. It should've been an RLA.
86
TI Z80 / Re: So I re-used my YABAV for something else...
« on: January 10, 2014, 12:10:28 pm »
The grayscale is a side-effect. I don't have anything at the moment that could make something like that intentional.
EDIT: Darn it. Now you've got me thinking on how to make it intentional. And to support dithering and other image manipulations in-app.
EDIT: Darn it. Now you've got me thinking on how to make it intentional. And to support dithering and other image manipulations in-app.
87
TI Z80 / Re: So I re-used my YABAV for something else...
« on: January 09, 2014, 06:47:14 pm »
This video is a clip from Touhou Soccer 2. It is the special animation for one of the player's special moves.
I don't know what went wrong but the decompressor wanted more processing power than was available, so I had to cut out the background audio routine. Even though it wasn't doing anything, not being able to include audio is a problem.
But the video is decent. 30FPS.
I don't know what went wrong but the decompressor wanted more processing power than was available, so I had to cut out the background audio routine. Even though it wasn't doing anything, not being able to include audio is a problem.
But the video is decent. 30FPS.
88
TI Z80 / Re: So I re-used my YABAV for something else...
« on: January 09, 2014, 04:21:20 pm »
This video is the opening scene of the second Touhou Soccer game. I cheated a bit and used Irfanview to do the conversion to b/w because without dithering, it sucks. Compression didn't work as well because of that, but it still worked on some of the video.
Video stats: ~31sec long, 1921 frames @ ~30FPS
On-calc size: 425,984 (416KB)
If it was not compressed: 1440.75KB
NOTE: The fuzz at the top near the start is the Bandicam logo. Also, need to beef up the video player to support multiple compression types. Probably not gonna happen anytime soon, but hey. It could happen.
EDIT: Framerate information is wrong. I did not realize the source video was 60fps, so the vid is running at half speed. Unfortunately, I can't exactly speed things up. The system barely has enough CPU power to do 30FPS.
Video stats: ~31sec long, 1921 frames @ ~30FPS
On-calc size: 425,984 (416KB)
If it was not compressed: 1440.75KB
NOTE: The fuzz at the top near the start is the Bandicam logo. Also, need to beef up the video player to support multiple compression types. Probably not gonna happen anytime soon, but hey. It could happen.
EDIT: Framerate information is wrong. I did not realize the source video was 60fps, so the vid is running at half speed. Unfortunately, I can't exactly speed things up. The system barely has enough CPU power to do 30FPS.
89
TI Z80 / So I re-used my YABAV for something else...
« on: January 09, 2014, 11:21:51 am »
Downloaded and converted a copy of Rick Astley's popular music video for the song "Never Gonna Give You Up". The screenshot gives the basic gist of what you'll be looking at, the .8xk download is the first 5000 (of 6,392) frames (roughly 2 3/4 minutes long)
On-calc filesize is 966,656 bytes (944KB). SPASM refuses to compile the entire video (it crashes if attempted).
First 5000 frames because it was a nice, easy number to pick that would still compile. The original video would've spanned 72 pages, and SPASM crashes on attempting to compile that.
Note that there is no real audio, but if you try anyway, you'll end up with a low pitched hum (since the audio driver is never disabled)
Any suggestions on other videos to try?
On-calc filesize is 966,656 bytes (944KB). SPASM refuses to compile the entire video (it crashes if attempted).
First 5000 frames because it was a nice, easy number to pick that would still compile. The original video would've spanned 72 pages, and SPASM crashes on attempting to compile that.
Note that there is no real audio, but if you try anyway, you'll end up with a low pitched hum (since the audio driver is never disabled)
Any suggestions on other videos to try?
90
ASM / Re: How to stop interrupts being disabled after exiting app?
« on: January 08, 2014, 10:24:27 pm »
Posting the relevant parts of the code may help. Also, posting how you set up the interrupt may also be helpful.