Welcome, Guest. Please login or register.


Author Topic: Sizecoding on the Enterprise (Read 617 times)

Offline Sdw

  • User
  • *
  • Posts: 50
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
Sizecoding on the Enterprise
« 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.

Offline geco

  • EP addict
  • *
  • Posts: 5088
  • Country: hu
  • OS:
  • Linux / Sony Ericsson SK17i Linux / Sony Ericsson SK17i
  • Browser:
  • Safari 4.0 Safari 4.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #1 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 :-)

Offline geco

  • EP addict
  • *
  • Posts: 5088
  • Country: hu
  • OS:
  • Linux / Sony Ericsson SK17i Linux / Sony Ericsson SK17i
  • Browser:
  • Safari 4.0 Safari 4.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #2 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.

Online Zozosoft

  • EP addict
  • *
  • Posts: 13081
  • Country: hu
  • OS:
  • Windows NT 10.0 Windows NT 10.0
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
    • http://enterprise.iko.hu/
Re: Sizecoding on the Enterprise
« Reply #3 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)

Offline Sdw

  • User
  • *
  • Posts: 50
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #4 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!

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 51.0 Firefox 51.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #5 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, 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.

Offline Sdw

  • User
  • *
  • Posts: 50
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #6 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?

Offline IstvanV

  • EP addict
  • *
  • Posts: 4756
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 51.0 Firefox 51.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #7 on: 2017.April.26. 23:29:11 »
It is not required to initialize the stack pointer if you never use EXOS calls/interrupts.

Offline Sdw

  • User
  • *
  • Posts: 50
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #8 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

Offline geco

  • EP addict
  • *
  • Posts: 5088
  • Country: hu
  • OS:
  • Linux Linux
  • Browser:
  • Firefox 45.0 Firefox 45.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #9 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.

Offline Sdw

  • User
  • *
  • Posts: 50
  • OS:
  • Windows 7/Server 2008 R2 Windows 7/Server 2008 R2
  • Browser:
  • Firefox 53.0 Firefox 53.0
    • View Profile
Re: Sizecoding on the Enterprise
« Reply #10 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!