4K Short'n'Sweet game contest

[+Vorticon]

 

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!

[palmheads]

 

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

[+Vorticon]

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

[sometimes99er]

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.

[speccery]

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

[sometimes99er]

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

[+retroclouds]

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

[Tursi]

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

[+mizapf]

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.

[sometimes99er]

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

 

[Asmusr]

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?

[PeteE]

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.

[Tursi]

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

[Asmusr]

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.

[Asmusr]

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

 

That's only one of multiple options.

[+FarmerPotato]

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?

[+mizapf]

 

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

[Asmusr]

 

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.

[+FarmerPotato]

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?

[+Lee Stewart]

<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

[+adamantyr]

 

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

[+Lee Stewart]

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

[+FarmerPotato]

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

[+Lee Stewart]

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

[+adamantyr]

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!