Enterprise Forever

:UK => Programming => Topic started by: Sdw on 2017.April.26. 21:41:50

Title: Sizecoding on the Enterprise
Post by: Sdw on 2017.April.26. 21:41:50
There have been some really nice 256 byte entries in the devcompo (and I'm working on what might become one as well).

But what *is* 256 bytes in the EP128-world? I saw some entries that seemed to go for the strict 256 byte filesize rule, while some others seemed to ignore the 16 byte header and use 256 actual bytes, giving a 272 byte file size.

I am trying to target the strict 256 byte filesize, but thought I would be smart and try to use the 12 seemingly unused bytes in the header to have 252 bytes available instead of only 240 as I have now, but couldn't get it to work, I guess these bytes aren't loaded to memory at all.
Title: Re: Sizecoding on the Enterprise
Post by: geco on 2017.April.26. 22:17:32
The header is alsó loaded into the memory as István pointed it, just it is loaded intő system segment, and intodifferent addresses in EXOS 2.0 and 2.1. You can check István's solution in squares256 topic :-)
Title: Re: Sizecoding on the Enterprise
Post by: geco on 2017.April.26. 22:39:30
Sorry, it was snake256 topic and in hungarian párt of devcompo#2,i can not create the shortcut now, because i am from phone now, but the modified code was inserted there by IstvanV.
Title: Re: Sizecoding on the Enterprise
Post by: Zozosoft on 2017.April.26. 23:13:19
I think the Enterprise are disadvantaged in sizecoding when compared by other systems which are have a fixed hw and sw enviroment. On EP need a EXOS file header, build LPT table, setup memory...
At bigger size categories these will made less disadvantage. And some natural limits on EP: 512 bytes (one sector size), 1024 bytes (one cluster size on standard 720K disk), 4096 bytes (one tape block), 16144 bytes (maximum size of header 5 program when only Page 0 used),  48912 bytes (maximum size of header 5 program)
Title: Re: Sizecoding on the Enterprise
Post by: Sdw on 2017.April.26. 23:18:36
I looked into the code in the Hungarian section. If I understand correctly, the 16 bytes from the header get loaded into either 0xBF0C or 0xBF08, and by adding a relative jump + 2 nops, you can then use the 8 remaining bytes for "real" code. Neat trick!
Title: Re: Sizecoding on the Enterprise
Post by: IstvanV on 2017.April.26. 23:19:38
The header is alsó loaded into the memory as István pointed it, just it is loaded intő system segment, and intodifferent addresses in EXOS 2.0 and 2.1. You can check István's solution in squares256 topic :-)

It is also used in the modified version of dither256 (https://enterpriseforever.com/enterprise-devcompo-2-42/dither256/msg63342/#msg63342), and actually saves more space there. On the EP64, the header is loaded to BF0Ch instead of BF08h, so the first 4 bytes (00 05 F0 00 = NOP, DEC B, RET P, NOP) are run, but the RET P does not return because B is initialized to zero.
Title: Re: Sizecoding on the Enterprise
Post by: Sdw on 2017.April.26. 23:26:01
Another question - is it necessary to initialize the stack pointer? It skipped it (saving 3 bytes) and everything seems to work fine, but I see that all other entreis has code that sets SP so I guess you should do it anyway?
Title: Re: Sizecoding on the Enterprise
Post by: IstvanV on 2017.April.26. 23:29:11
It is not required to initialize the stack pointer if you never use EXOS calls/interrupts.
Title: Re: Sizecoding on the Enterprise
Post by: Sdw on 2017.April.27. 12:07:19
Thanks!

Another question, can anything be assumed regarding memory init values? Especially the memory after the end of my program, where I use about 16 bytes that need to be zero. It works fine both in emulator and on my real EP128, but I can imagine that there are no guarantees.
My program loads from 0x0100-0x0170 (yep, I'm trying to do a 128 byte intro! :) ), but then I'm using 0x170-0x180 as well and need that to be zero, and I don't have enough bytes left to do the initialization of that.

-edit-

Oh! And is there a shorter/smarter way to wait for VBL than:
Code: [Select]
waitvbl:
in   a,(0b4h)
bit  4,a
jr   z,waitvbl
Title: Re: Sizecoding on the Enterprise
Post by: geco on 2017.April.27. 13:16:39
There is one way if the interrupts are enabled, then a HALT, and int rut will be called after VBL, and continue after HALT.
As I know there is no guarante that 0170h-0180h is zero.
Title: Re: Sizecoding on the Enterprise
Post by: Sdw on 2017.April.27. 14:03:32
Ah, thanks! Enabling interrupts (even if it meant that I needed to set up the stack) saved me enough on the vbl wait that I could do a proper clear of those bytes and still keep below the 128 byte limit.
So now the intro is finished and can be found in the DevCompo forum!