Hi Tiny,

Abstract: It is very likely that the 228 CD limit is a Turbo Pascal/real
mode memory limit. EZ-ROM is (according to findings) a DOS door written
in Turbo Pascal; Turbo Pascal in 16-bit real mode has a maximum of 64 KB
per data segment for global/static data. If the developer created a static array table of records for the CD catalog entries, the record size
determines how many entries fit into the 64 KB. With a record size of roughly ~280 bytes, you end up with about ~228 entries (64 KB / ~280 B ≈ 228). This explains why 256 were not used: the 64 KB segment limit was there before.
A round number like 256 does not help if the sum of the record bytes exceeds the 64 KB mark beforehand.

Greetz
neo67

--- Mystic BBS v1.12 A48 (Windows/64)
* Origin: -= The News BBS | bbs.dosnetz.de:3232 =- (21:2/136)

Abstract: It is very likely that the 228 CD limit is a Turbo Pascal/real mode memory limit. EZ-ROM is (according to findings) a DOS door written
in Turbo Pascal; Turbo Pascal in 16-bit real mode has a maximum of 64 KB
per data segment for global/static data. If the developer created a static array table of records for the CD catalog entries, the record size determines how many entries fit into the 64 KB. With a record size of rough ~280 bytes, you end up with about ~228 entries (64 KB / ~280 B ≈ 228). Th explains why 256 were not used: the 64 KB segment limit was there before.
A round number like 256 does not help if the sum of the record bytes exceed the 64 KB mark beforehand.

Every release he raised it. It started as 96, then worked its way to 228. So it MAY or MAY NOT explain this.

... Don't confuse me with facts.

--- Renegade v1.35/DOS
* Origin: The Titantic BBS Telnet - ttb.rgbbs.info (21:1/144)

Hi Exodus,
In a message to Neo67 you wrote:

64 KB per data segment for global/static data. If the developer

Every release he raised it. It started as 96, then worked its way to
228. So it MAY or MAY NOT explain this.

It makes sense, I'll take that as the answer ;) I didn't think of that.

... Good: Your uncle leaves you a fortune. Bad: It's counterfeit.


* SeM. 2.26 * From the Dirty Shwa
--- SBBSecho 3.29-Linux
* Origin: _thePharcyde telnet://bbs.pharcyde.org (Wisconsin) (21:1/700)

Welp, I did it, I filled EZ-ROM CD-ROM Door to the max of 228 Shareware CDs. <tear> ;)

I've found that I can't have files >64MB in my filebase on Ezycom 2.15g1. They adopt OK, but if you try to queue it, your session drops. The error in the log file is an overflow of some sort.

One day I'll sit down and upgrade further, maybe even get 3.00 working if we can unearth a compatible key!

The temptation is to set up a modern 'frontend', but man I love operating Ezycom. It's a leap back into my formative years.

Cheers,
RetroSwim

--- Ezycom V2.15g1 01FD0295
* Origin: >> Pool's Open - The RetroSwim BBS (21:2/121)

Every release he raised it. It started as 96, then worked its way to
228. So it MAY or MAY NOT explain this.

... Don't confuse me with facts.

Hi Exodus,

The era of the early BBS systems differs from today in two ways:

1. Everyone was interested in these technical aspects of programming.

2. If you weren't interested, you just kept your mouth shut.

Confuse no other...

THX

neo67

--- Mystic BBS v1.12 A48 (Windows/64)
* Origin: -= The News BBS | bbs.dosnetz.de:3232 =- (21:2/136)

Every release he raised it. It started as 96, then worked its way to 228. So it MAY or MAY NOT explain this.

... Don't confuse me with facts.

Hi Exodus,

The era of the early BBS systems differs from today in two ways:

1. Everyone was interested in these technical aspects of programming.

2. If you weren't interested, you just kept your mouth shut.

Confuse no other...

What did that have to do with how many CDs it was able to read?

... Finish the project. We'll buy you a new family.

--- Renegade v1.35/DOS
* Origin: The Titantic BBS Telnet - ttb.rgbbs.info (21:1/144)