Jump to content
Asmusr

4K Short'n'Sweet game contest

Recommended Posts

 

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!

  • Like 1

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

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.

:)

  • Like 1

Share this post


Link to post
Share on other sites

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
  • Like 1

Share this post


Link to post
Share on other sites

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
  • Like 1

Share this post


Link to post
Share on other sites

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
  • Like 3

Share this post


Link to post
Share on other sites

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

Edited by Tursi
  • Like 5

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

:)

 

  • Like 2

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 5

Share this post


Link to post
Share on other sites

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

 

That's only one of multiple options.

Share this post


Link to post
Share on other sites

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?


Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

 

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

<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

Share this post


Link to post
Share on other sites

 

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

  • Like 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...