Welcome, Guest. Please login or register.

Login with username, password and session length


Recent Posts

Pages: [1] 2 3 4 5 6 7 8 ... 10
1
Enterprise DevCompo #2 / Re: Dither256b
« Last post by geco on Today at 08:35 »
2
Programming / Re: Sizecoding on the Enterprise
« Last post by IstvanV on Yesterday at 23:29 »
It is not required to initialize the stack pointer if you never use EXOS calls/interrupts.
3
Programming / Re: Sizecoding on the Enterprise
« Last post by Sdw on Yesterday at 23:26 »
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?
4
Programming / Re: Sizecoding on the Enterprise
« Last post by IstvanV on Yesterday at 23:19 »
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.
5
Programming / Re: Sizecoding on the Enterprise
« Last post by Sdw on Yesterday at 23:18 »
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!
6
Programming / Re: Sizecoding on the Enterprise
« Last post by Zozosoft on Yesterday at 23:13 »
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)
7
Programming / Re: Sizecoding on the Enterprise
« Last post by geco on Yesterday at 22:39 »
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.
8
Hardware / Re: Good edge connectors and cables.
« Last post by gflorez on Yesterday at 22:23 »
The cable bought to Retrocables is a cheap lead sielded wth only aluminium foil, but it does its work perfectly on the Enterprise.

The better option for me would be a VGA monitor lead, as they have at least shielded the colours, but a simple eight leads shielded cable will suit me.

Also, I opt in my RGB cables to take the sound from the Tape out connector, as it gives a louder(standard) volume level. The sound output at the Monitor connector is so low that forces me to set the volume at max on the TV.
9
Programming / Re: Sizecoding on the Enterprise
« Last post by geco on Yesterday at 22:17 »
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 :-)
10
Programming / Sizecoding on the Enterprise
« Last post by Sdw on Yesterday at 21:41 »
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.
Pages: [1] 2 3 4 5 6 7 8 ... 10