+Vorticon Posted January 9, 2018 Share Posted January 9, 2018 So what do you think the next step(s) would be? Once you've filled that 760 bytes, do you save that chunk of code as a reloadable data source, then start again on a new chunk of code? So you might end up with (say) 4 chunks of 760 bytes that you load up that you then piece together with CALL LINK in TI-BASIC?. Or do you take all the opcodes & end up combining them all in a bunch of DATA/CALL LOAD (ie POKE) TI-BASIC commands until you filled as much of the 4k MM as possible? Always wondered how you could fill the 4k with LBLA. Nope, the entire program will have to fit in 760 bytes That's my goal. While it sounds like a minuscule amount of memory, assembly language can be pretty efficient and compact and so you can do a surprising amount with that. As I had stated earlier, it does force you to get into a different mindset than when you are programming under the EA environment, and that's the attraction for me. We shall see if I can overcome that challenge in the end! 1 Quote Link to comment Share on other sites More sharing options...
palmheads Posted January 9, 2018 Share Posted January 9, 2018 (edited) Nope, the entire program will have to fit in 760 bytes That's my goal. While it sounds like a minuscule amount of memory, assembly language can be pretty efficient and compact and so you can do a surprising amount with that. As I had stated earlier, it does force you to get into a different mindset than when you are programming under the EA environment, and that's the attraction for me. We shall see if I can overcome that challenge in the end! Thats gonna be impressive! Some quite good games were developed for the 1k ZX81 like the still talked about 1k chess - https://en.wikipedia.org/wiki/1K_ZX_Chess http://users.ox.ac.uk/~uzdm0006/scans/1kchess/ Edited January 9, 2018 by palmheads Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted January 10, 2018 Share Posted January 10, 2018 I certainly could not compete with that level of wizardry, but would have loved to have the extra 264 bytes for use! 2 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 13, 2018 Share Posted January 13, 2018 I've got several game project candidates for this contest. I hope to enter with at least one game. I'm working mostly on one specifically, but then progress hasn't been all that great. 1 Quote Link to comment Share on other sites More sharing options...
speccery Posted January 13, 2018 Share Posted January 13, 2018 (edited) I only yesterday discovered this contest, this was until the end of March, right? So still time to put something together. The 4K limit sounds very decent, I think Ill try to do something that would only need the RAM of the mini memory. Obviously could be linked to other addresses as well. Edited January 13, 2018 by speccery 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 13, 2018 Share Posted January 13, 2018 (edited) I only yesterday discovered this contest, this was until the end of March, right? Yes. And the contest officially started December 25th. Acc. post #46. The 4K limit sounds very decent, I think Ill try to do something that would only need the RAM of the mini memory. Obviously could be linked to other addresses as well. Yes, 4K, all in all, is the limit, that's RAM+ROM+GROM etc <= 4K. You can of course utilize the standard console's built-in Scratch-Pad, VRAM, ROM and GROM. Edited January 13, 2018 by sometimes99er 1 Quote Link to comment Share on other sites More sharing options...
+retroclouds Posted January 14, 2018 Share Posted January 14, 2018 (edited) I have the title screen music in place (which I shamlesly copied from a post by OLD CS1, I apologize for that). Today I started working on code optimization because ofcourse it needs to fit in 4K - which in our world means 4000 bytes right, not 4096 bytes?). Basically I broke my spectra2 library in multiple modules and by using conditional expressions in the xas99 assembler, I can include only the parts I need. Also added a preprocesor bash script which does some useful stuff for me. Long story short; I went from 5740 bytes to 4650 bytes in code size. So the good news is that I was able to save 1090 bytes. The bad news is that I'm still 650 bytes above the 4K barrier. I still have 4 more routines I can move to modules and exclude, so there is still hope Also have to add some basic sound effects and some more bug-fixing to do. Edited January 14, 2018 by retroclouds 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 14, 2018 Share Posted January 14, 2018 (edited) No, 4k is 4096 bytes. They only started rounding to powers of ten when hard drives needed to sound bigger. Edited January 14, 2018 by Tursi 5 Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 14, 2018 Share Posted January 14, 2018 I'm pretty sure it was at the time of 512M hard disks, when all of a sudden, 535M drives were available for the same price. 1 Quote Link to comment Share on other sites More sharing options...
sometimes99er Posted January 14, 2018 Share Posted January 14, 2018 I got a bunch of sprites and player movement in place. Going back and forth a bit, trying to find the best and/or lowest number of control variables (for game logic). I'm at less than 15% of the 4K (ROM only). Maybe I'll use the standard character set. Will have to add a few sound effects. May compress the graphics. Title screen may only consist of name of game and created by. Music is unlikely. If I get it working at, let's say 60%, I will probably try and add stuff to get closer to 100% (something I usually do not do). 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 20, 2018 Author Share Posted January 20, 2018 Just realized that it's not possible to provide a pure 4K RAM image for the FinalGROM 99 because the RAM must be at >7000 and the cartridge header at >6000. So the question is whether it's OK to submit a 8K image with only a header at >6000? Quote Link to comment Share on other sites More sharing options...
PeteE Posted January 20, 2018 Share Posted January 20, 2018 I would suggest it be okay, since entries could confirmed with a hex viewer that the upper half contains only the cart header and program list. Headers should not contain extra data or code used by the program. I don't know much about E/A files, but those headers should be excluded as well, for the sake of fairness. 2 Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 21, 2018 Share Posted January 21, 2018 Wasn't the idea to provide an EA#3 anyway so it would load in MiniMemory? Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 23, 2018 Author Share Posted January 23, 2018 I have been looking for a way to compress my sprite patterns, but not even state-of-the-art zip compression gave decent results, until I realized that my sprite patterns are similar in that they only have one span of 'on' pixels per line (filled convex shapes). So I came up with the idea of compressing the sprites as a run of 'off' pixels followed by a run of 'on' pixels and repeat that until the end of the sprite. The number of pixels in each run can efficiently be encoded in a single nybble (4 bits) representing a run of between 0 and 15 pixels. So the byte >84 means 8 'off' pixels followed by 4 'on' pixels. This compression scheme reduced the size of my sprite patterns to almost half. The decoder takes up about 100 bytes, but in the end I could save a few hundred bytes, which is a lot compared to what I have left. 5 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 23, 2018 Author Share Posted January 23, 2018 Wasn't the idea to provide an EA#3 anyway so it would load in MiniMemory? That's only one of multiple options. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 23, 2018 Share Posted January 23, 2018 For a program with not much CPU RAM (yes, for this contest), what's the best way to move data in VDP RAM? For instance, one might write: * VMOVE - move VDP memory * R3 destination vdp memory address * R4 source vdp memory address * R5 length * VMOVE LI R1,@834A BUFFER LI R2,8 BUFFER SIZE VMOV1 MOV R4,R0 BLWP @VMBR MOV R3,R0 BLWP @VMBW A R2,R4 A R2,R3 S R2,R5 JNE VMOV1 RT * Scroll the screen upwards by 1 line SCROLL MOV R11,R10 LI R3,0 TO VDP ADDRESS LI R4,32 FROM VDP ADDRESS LI R5,736 LENGTH BL @VMOVE B *R10 How could you improve on this? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted January 23, 2018 Share Posted January 23, 2018 (edited) How could you improve on this? I know there is not much CPU RAM, but could you at least allocate a small buffer (say 16 bytes) in CPU RAM? You could use it as an intermediate buffer, and minimize address resetting. [Edit: Right, there is a buffer (tomatoes on my eyes, as we say). As Rasmus said, it should be larger.] Edited January 23, 2018 by mizapf Quote Link to comment Share on other sites More sharing options...
Asmusr Posted January 23, 2018 Author Share Posted January 23, 2018 I know there is not much CPU RAM, but could you at least allocate a small buffer (say 16 bytes) in CPU RAM? You could use it as an intermediate buffer, and minimize address resetting. He is already using a buffer in CPU RAM. I don't think you can make it shorter but you can make is a lot faster by using a larger buffer, using inline VDP routines, unrolling the loops, etc. Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 23, 2018 Share Posted January 23, 2018 Is there an XMLLNK or GPLLNK for moving memory? I'll probably inline the VDP routines. What happens on the 9918 if you set up VDPWA and then mix accesses to VPDRD and VDPWD? are there any tricks there? Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 23, 2018 Share Posted January 23, 2018 <snip> The instruction at VMOVE should be VMOVE LI R1,>834A BUFFER should it not? You can only LI immediate values, not address contents nor other deferred values. ...lee Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted January 23, 2018 Share Posted January 23, 2018 For a program with not much CPU RAM (yes, for this contest), what's the best way to move data in VDP RAM? For instance, one might write: * VMOVE - move VDP memory * R3 destination vdp memory address * R4 source vdp memory address * R5 length * VMOVE LI R1,@834A BUFFER LI R2,8 BUFFER SIZE VMOV1 MOV R4,R0 BLWP @VMBR MOV R3,R0 BLWP @VMBW A R2,R4 A R2,R3 S R2,R5 JNE VMOV1 RT * Scroll the screen upwards by 1 line SCROLL MOV R11,R10 LI R3,0 TO VDP ADDRESS LI R4,32 FROM VDP ADDRESS LI R5,736 LENGTH BL @VMOVE B *R10 How could you improve on this? If you're trying to scroll, I would set up a second screen in VDP and write alternatively between the two screens your entire display, then just swap the screen location in the register to "scroll". 1 Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 23, 2018 Share Posted January 23, 2018 ... What happens on the 9918 if you set up VDPWA and then mix accesses to VPDRD and VDPWD? are there any tricks there? I do not think their are any tricks. Just be aware that the VDP (TMS9918A) is auto-incrementing, one byte at a time. If you alternate reads and writes, they will be to successive addresses, one byte apart. ...lee Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted January 23, 2018 Share Posted January 23, 2018 Scrolling was just one example. I'm thinking of data structures in general, using only VDP RAM. Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted January 23, 2018 Share Posted January 23, 2018 For a program with not much CPU RAM (yes, for this contest), what's the best way to move data in VDP RAM? For instance, one might write: * VMOVE - move VDP memory * R3 destination vdp memory address * R4 source vdp memory address * R5 length * VMOVE LI R1,@834A BUFFER LI R2,8 BUFFER SIZE VMOV1 MOV R4,R0 BLWP @VMBR MOV R3,R0 BLWP @VMBW A R2,R4 A R2,R3 S R2,R5 JNE VMOV1 RT ... How could you improve on this? Here is an inline version of a VDP-to-VDP move, ported from fbForth 2.0 (originally from TI Forth): * VMOVE - move VDP memory * R1: cnt (number of bytes to move) * R2: vsrc (source vdp memory address) * R3: vdst (destination vdp memory address ) * * MYWS: my workspace in Pad RAM, if at all possible * VDPWA EQU >8C02 VDP Write Address register VDPRD EQU >8800 VDP Read Data register VDPWD EQU >8C00 VDP Write Data register * VMOVE ORI R3,>4000 Prepare for VDP write * ** copy cnt bytes from vsrc to vdst * VMVMOR MOVB @MYWS+5,@VDPWA Write LSB of vsrc (LSB of R2) MOVB R2,@VDPWA Write MSB of vsrc INC R2 Next vsrc MOVB @VDPRD,R0 Read VDP byte MOVB @MYWS+7,@VDPWA Write LSB of vdst (LSB of R3) MOVB R3,@VDPWA Write MSB of vdst INC R3 Next vdst MOVB R0,@VDPWD Write VDP byte DEC R1 Decrement count JNE VMVMOR Repeat if not done RT Return to caller ...lee Quote Link to comment Share on other sites More sharing options...
+adamantyr Posted January 23, 2018 Share Posted January 23, 2018 Is there an XMLLNK or GPLLNK for moving memory? I'll probably inline the VDP routines. What happens on the 9918 if you set up VDPWA and then mix accesses to VPDRD and VDPWD? are there any tricks there? There aren't any tricks. The data ports in the scratch pad are the sole method the CPU can access VDP RAM. And the VDP processor can't move it's own data about. I had my own complaint in this area in that I hate that the disk file I/O REQUIRES a significant portion of the upper VDP RAM for buffers. This is because at the time TI designed the disk controller, the only memory they could be CERTAIN about was VDP, and they didn't want to put memory chips on the card itself for buffering. Ironically, the MG upgrade ROM's for the Corcomp FDC have a built-in "direct to CPU" sector read/write. An awesome feature, but not supported with any emulators or with any other cards, so I can't write any software to use it. Phooey! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.