Jump to content

Photo

4K Short'n'Sweet game contest


398 replies to this topic

#101 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,220 posts
  • Location:Eagan, MN, USA

Posted Tue Jan 9, 2018 3:00 PM

 

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!



#102 palmheads OFFLINE  

palmheads

    Chopper Commander

  • 200 posts
  • Location:Christchurch, New Zealand

Posted Tue Jan 9, 2018 3:34 PM

 

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 - 


Edited by palmheads, Tue Jan 9, 2018 3:36 PM.


#103 Vorticon OFFLINE  

Vorticon

    River Patroller

  • 3,220 posts
  • Location:Eagan, MN, USA

Posted Tue Jan 9, 2018 6:50 PM

I certainly could not compete with that level of wizardry, but would have loved to have the extra 264 bytes for use!

#104 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,114 posts

Posted Sat Jan 13, 2018 5:06 AM

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.

:)



#105 speccery OFFLINE  

speccery

    Moonsweeper

  • 337 posts

Posted Sat Jan 13, 2018 5:56 AM

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 by speccery, Sat Jan 13, 2018 5:57 AM.


#106 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,114 posts

Posted Sat Jan 13, 2018 6:18 AM

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 by sometimes99er, Sat Jan 13, 2018 2:55 PM.


#107 retroclouds OFFLINE  

retroclouds

    Stargunner

  • 1,620 posts
  • Location:Germany

Posted Sun Jan 14, 2018 2:45 PM

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 by retroclouds, Sun Jan 14, 2018 2:46 PM.


#108 Tursi ONLINE  

Tursi

    Quadrunner

  • 5,129 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Jan 14, 2018 3:14 PM

No, 4k is 4096 bytes. They only started rounding to powers of ten when hard drives needed to sound bigger. ;)


Edited by Tursi, Sun Jan 14, 2018 3:15 PM.


#109 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,273 posts
  • Location:Germany

Posted Sun Jan 14, 2018 3:23 PM

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.



#110 sometimes99er OFFLINE  

sometimes99er

    River Patroller

  • 4,114 posts

Posted Sun Jan 14, 2018 4:06 PM

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

 



#111 Asmusr OFFLINE  

Asmusr

    River Patroller

  • Topic Starter
  • 2,786 posts
  • Location:Denmark

Posted Sat Jan 20, 2018 3:43 PM

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?



#112 PeteE OFFLINE  

PeteE

    Chopper Commander

  • 148 posts
  • Location:Beaverton, OR

Posted Sat Jan 20, 2018 4:10 PM

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.



#113 Tursi ONLINE  

Tursi

    Quadrunner

  • 5,129 posts
  • HarmlessLion
  • Location:BUR

Posted Sun Jan 21, 2018 3:35 AM

Wasn't the idea to provide an EA#3 anyway so it would load in MiniMemory?

#114 Asmusr OFFLINE  

Asmusr

    River Patroller

  • Topic Starter
  • 2,786 posts
  • Location:Denmark

Posted Tue Jan 23, 2018 9:50 AM

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.  



#115 Asmusr OFFLINE  

Asmusr

    River Patroller

  • Topic Starter
  • 2,786 posts
  • Location:Denmark

Posted Tue Jan 23, 2018 10:03 AM

Wasn't the idea to provide an EA#3 anyway so it would load in MiniMemory?

 

That's only one of multiple options.



#116 FarmerPotato OFFLINE  

FarmerPotato

    Star Raider

  • 85 posts
  • Location:Austin, TX

Posted Tue Jan 23, 2018 11:50 AM

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?
 


#117 mizapf OFFLINE  

mizapf

    River Patroller

  • 3,273 posts
  • Location:Germany

Posted Tue Jan 23, 2018 12:25 PM

 

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 by mizapf, Tue Jan 23, 2018 12:41 PM.


#118 Asmusr OFFLINE  

Asmusr

    River Patroller

  • Topic Starter
  • 2,786 posts
  • Location:Denmark

Posted Tue Jan 23, 2018 12:29 PM

 

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.



#119 FarmerPotato OFFLINE  

FarmerPotato

    Star Raider

  • 85 posts
  • Location:Austin, TX

Posted Tue Jan 23, 2018 12:43 PM

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? 



#120 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,695 posts
  • Location:Silver Run, Maryland

Posted Tue Jan 23, 2018 1:17 PM

<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



#121 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,338 posts

Posted Tue Jan 23, 2018 1:30 PM

 

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



#122 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,695 posts
  • Location:Silver Run, Maryland

Posted Tue Jan 23, 2018 1:39 PM

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



#123 FarmerPotato OFFLINE  

FarmerPotato

    Star Raider

  • 85 posts
  • Location:Austin, TX

Posted Tue Jan 23, 2018 2:13 PM

Scrolling was just one example. I'm thinking of data structures in general, using only VDP RAM. 



#124 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,695 posts
  • Location:Silver Run, Maryland

Posted Tue Jan 23, 2018 2:55 PM

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



#125 adamantyr OFFLINE  

adamantyr

    Stargunner

  • 1,338 posts

Posted Tue Jan 23, 2018 2:57 PM

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!






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users