| BSAVE (ing) in Dos 3.3 sector question? [message #305962] |
Fri, 11 December 2015 12:02  |
|
|
Originally posted by: Tom Porter
Heres a weird one, maybe I just do not understand how the Apple works.
I know that Text Files have a minimum 2 block size which is quite alright (unless its in opened/unsaved condition). I'm not sure about Binary, but I think it also has the same 'limitation'.
The problem is when I do BSAVE a chunk of memory. Usually its not a big problem but space concerns on my new game are making me triple check every single block of available disk space.
----
BSAVING a block of memory, say BSAVE FILE,A2048,L512 produces a file of 4 block, yet it only consists of 2 block of (256 pages)... is that correct. Now I know that the file length/size is also recorded, so if I manually cut it back say 20 bytes, it reduces the file down to 3 blocks.
Why does this not appear on the table as 2 blocks?
Thanks a lot, Tom
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #305964 is a reply to message #305962] |
Fri, 11 December 2015 12:55  |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Friday, December 11, 2015 at 11:02:48 AM UTC-6, Tom Porter wrote:
> Heres a weird one, maybe I just do not understand how the Apple works.
>
> I know that Text Files have a minimum 2 block size which is quite alright (unless its in opened/unsaved condition). I'm not sure about Binary, but I think it also has the same 'limitation'.
>
> The problem is when I do BSAVE a chunk of memory. Usually its not a big problem but space concerns on my new game are making me triple check every single block of available disk space.
> ----
> BSAVING a block of memory, say BSAVE FILE,A2048,L512 produces a file of 4 block, yet it only consists of 2 block of (256 pages)... is that correct. Now I know that the file length/size is also recorded, so if I manually cut it back say 20 bytes, it reduces the file down to 3 blocks.
>
> Why does this not appear on the table as 2 blocks?
>
>
> Thanks a lot, Tom
One sector is always needed for the Track/sector list since not all data is stored sequentially, there needs to be a way to find other sectors of data after the first one.
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #305985 is a reply to message #305964] |
Fri, 11 December 2015 13:22 |
qkumba
Messages: 1584
Registered: March 2013
Karma: 0
|
Senior Member |
|
|
|
Your 512-bytes file requires one sector for the track/sector list, four bytes for start address and length, followed by 512 bytes of your data. Those initial four bytes are pushing your data into a third sector. If you shorten by just four bytes, you'll be back to three sectors.
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #305986 is a reply to message #305964] |
Fri, 11 December 2015 14:40 |
|
|
Originally posted by: Don Bruder
In article <9fe4b9c8-14f1-4489-b193-460efe78bb67@googlegroups.com>,
gids.rs@sasktel.net wrote:
> On Friday, December 11, 2015 at 11:02:48 AM UTC-6, Tom Porter wrote:
>> Heres a weird one, maybe I just do not understand how the Apple works.
>>
>> I know that Text Files have a minimum 2 block size which is quite alright
>> (unless its in opened/unsaved condition). I'm not sure about Binary, but I
>> think it also has the same 'limitation'.
>>
>> The problem is when I do BSAVE a chunk of memory. Usually its not a big
>> problem but space concerns on my new game are making me triple check every
>> single block of available disk space.
>> ----
>> BSAVING a block of memory, say BSAVE FILE,A2048,L512 produces a file of 4
>> block, yet it only consists of 2 block of (256 pages)... is that correct.
>> Now I know that the file length/size is also recorded, so if I manually cut
>> it back say 20 bytes, it reduces the file down to 3 blocks.
>>
>> Why does this not appear on the table as 2 blocks?
>>
>>
>> Thanks a lot, Tom
>
>
> One sector is always needed for the Track/sector list since not all data is
> stored sequentially, there needs to be a way to find other sectors of data
> after the first one.
EXCEPT when the file fits completely into one sector - then there's no
overhead for the T/S list. Read up on "seedling", "sapling" and "tree"
files - Short form:
Seedling files have *no* T/S list sector overhead - the catalog entry
points directly at the lone sector holding the file's data, and the file
will be exactly one sector in size.
Sapling files have *exactly one* T/S list sector worth of overhead - the
catalog entry points at a T/S list sector, whose entries in turn point
at the actual data sectors.
The size will be (1 + datasize/256 + (1 * ((datasize mod 256) != 0)))
sectors. (Which is to say, whatever number of 256 byte sectors are
needed to hold the actual data, plus 1 sector for the T/S list.)
Tree files have a *minimum* of two sectors worth of T/S List overhead -
A "master" T/S list sector, which is a list of pointers to one or more
additional T/S list sectors, which in turn hold values that point to the
actual data sectors. A tree file's catalog entry points at the master
T/S list sector. Size in sectors is is figured similar to the sapling
file, adding 1 for the master, plus 1 for each T/S list sector the
master points to.
--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q
|
|
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #306029 is a reply to message #305962] |
Sat, 12 December 2015 03:12 |
|
|
Originally posted by: Tom Porter
Remember, this is for Dos 3.3 (honestly Pronto Dos *3.3)
Ok, so I should only be worried if there are a lot of 'little' files. If I make a bunch of 'mini' recordings of binary files as (temps) then combine them later to make one big file, that savings would come back right?
EXP1 (saving as work/temp files)
BSAVE ONE,A2400,L252 (3 BLOCKS)
BSAVE TWO,A2652,L252 (3 BLOCKS)
BSAVE THREE,A2904,L252 (3 BLOCKS)
----------------Total 9 blocks
EXP2 (opening those temps, then saving them into one)
FOR X=1 TO 3:BLOAD ONE,BLOAD TWO,BLOAD THREE:NEXT X ('not real code)
BSAVE FINAL,A2400,L756 (4 BLOCKS)
----------------Total 4 blocks
*... I just tried it out, it works great! Cool!
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #306030 is a reply to message #305962] |
Sat, 12 December 2015 03:18 |
|
|
Originally posted by: Tom Porter
Remember, this is for Dos 3.3 (honestly Pronto Dos *3.3)
Ok, so I should only be worried if there are a lot of 'little' files. If I make a bunch of 'mini' recordings of binary files as (temps) then combine them later to make one big file, that savings would come back right?
EXP1 (saving as work/temp files)
BSAVE ONE,A2400,L252 (2 BLOCKS)
BSAVE TWO,A2652,L252 (2 BLOCKS)
BSAVE THREE,A2904,L252 (2 BLOCKS)
----------------Total 6 blocks
EXP2 (opening those temps, then saving them into one)
FOR X=1 TO 3:BLOAD ONE,BLOAD TWO,BLOAD THREE:NEXT X ('not real code)
BSAVE FINAL,A2400,L756 (4 BLOCKS)
----------------Total 4 blocks
*... I just tried it out, it works great! Cool!
|
|
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #306056 is a reply to message #305962] |
Sat, 12 December 2015 11:28 |
|
|
Originally posted by: Tom Porter
Dos 3.3 is what I learned/used as a youth... I never did upgrade to Prodos during my 'professional adult' life. I was seriously tempted because of the lack of the RamDrive, but I recently found DiskQuik, and I find it totally fascinating and have absolutely no reason to upgrade now. Besides, doesn't Prodos use more memory giving less to basic? With Pronto it has the added speed. What is the advantage with these 'mods' over Prodos?
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #306059 is a reply to message #306056] |
Sat, 12 December 2015 12:29 |
|
|
Originally posted by: Don Bruder
In article <45f14b03-4054-45c5-8713-d9fabd09623f@googlegroups.com>,
Tom Porter <laseractiveguy@gmail.com> wrote:
> Dos 3.3 is what I learned/used as a youth... I never did upgrade to Prodos
> during my 'professional adult' life. I was seriously tempted because of the
> lack of the RamDrive, but I recently found DiskQuik, and I find it totally
> fascinating and have absolutely no reason to upgrade now. Besides, doesn't
> Prodos use more memory giving less to basic? With Pronto it has the added
> speed. What is the advantage with these 'mods' over Prodos?
In main memory, ProDOS "steals" one page up high ($BF00-$BFFF), a
handful of zero page locations (Most of them the same locations that DOS
3.3 claims) and diddles a few things on page $0300 - again, mostly the
same places DOS 3.3 uses). Everything else lives in bank-switched memory
that "plain" (meaning "no added on assembly language tricks" or
deliberate PEEKing/POKEing at soft switches) Applesoft never even knows
exists.
Without digging up a memory map, I'm not certain exactly what
BASIC.SYSTEM snatches, but it's not much, if any, beyond the stuff that
would be grabbed by DOS 3.3 - BASIC.SYSTEM is essentially just a little
bit of glue to stick the Applesoft in ROM to ProDOS routines - in nearly
the same manner as DOS 3.3 is glued to ROM Applesoft.
In short, ProDOS vs. DOS 3.3 is a pretty pointless comparison. At least
at the level of Applesoft, the majority of the differences between them
are invisible. Things change *DRASTICALLY* when you start playing at the
assembly level, but... <shrug> When HASN'T that been the case?
--
Security provided by Mssrs Smith and/or Wesson. Brought to you by the letter Q
|
|
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #306077 is a reply to message #306056] |
Sat, 12 December 2015 18:36 |
Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Saturday, December 12, 2015 at 5:28:58 PM UTC+1, Tom Porter wrote:
> Dos 3.3 is what I learned/used as a youth... I never did upgrade to Prodos during my 'professional adult' life. I was seriously tempted because of the lack of the RamDrive, but I recently found DiskQuik, and I find it totally fascinating and have absolutely no reason to upgrade now. Besides, doesn't Prodos use more memory giving less to basic? With Pronto it has the added speed. What is the advantage with these 'mods' over Prodos?
Understood. I always think assembly language, not BASIC. ProDOS and assembly give you more memory than DOS 3.3 in the main bank.
I also prefer the hierarchical file system of ProDOS and its speed over DOS 3.3.
Keep up the good work,
Antoine
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #306086 is a reply to message #305962] |
Sat, 12 December 2015 21:56 |
|
|
Originally posted by: Tom Porter
Thank you Marco,
BitDisk seems to be a little more concise in execution and file sizes/number of files compared to DiskQuik... except for the title screen! It loads/runs the files in a weird spot 24576 but after some testing, it doesn't seem to need the data to work once loaded. Also provides 71 more sectors. I like BeagleBros, but this seems to be slightly better. Appreciate the link!
(Also, if you get the file and use Pronto, it must be converted/copied by a Pronto disk or will destroy your destination data/disk.)
Tom
|
|
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #306438 is a reply to message #306056] |
Sat, 19 December 2015 05:50 |
ol.sc
Messages: 211
Registered: January 2013
Karma: 0
|
Senior Member |
|
|
On Sat, 12 Dec 2015 08:28:56 -0800 (PST), Tom Porter
<laseractiveguy@gmail.com> wrote:
> What is the advantage with these 'mods' over Prodos?
Just two aspects:
1. With DOS 3.3 you're more or less bound to DISK II drives (or
devices emulating DISK II drives). In contrast ProDOS has the concept
of device drivers making it extensible. Users of your software will
have much more choices where to store your software when you build it
on ProDOS. Just two - relevant - examples for devices working with
ProDOS but not with DOS 3.3: The original CFFA and the ADTPro Virtual
Drive.
2. With ProDOS your initial issue with the overhead for storing 512
bytes wouldn't exist at all. ProDOS is a) clever enough to understand
that it doesn't need something like a track-sector-list for files up
to 512 bytes and it b) stores the start address in the directory
instead of the file.
Regards,
Oliver
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #339145 is a reply to message #305962] |
Sun, 12 March 2017 15:33 |
|
|
Originally posted by: Tom Porter
A while back... someone showed me BITDISK which is a RAMDRIVE for DOS 3.3.... it utilizes every available resource on the board that is not lower 48k to provide 309 blocks of ramdrive, better than DISK-QUIK by beagle-bros and everything else I've seen. The only downside is the titlescreen. I have been looking into it and here is what you need to modify to remove the titlescreen.... if anybody is interested....
Change the first line of BITDISK to read...then resave.
6000- 4C 73 60 JMP $6073
If the original author is still around... whoops, I'm sorry! -Tom at Naspite
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #339146 is a reply to message #339145] |
Sun, 12 March 2017 16:25 |
bpiltz
Messages: 78
Registered: October 2012
Karma: 0
|
Member |
|
|
|
Where may I find such a treasure known as "BITDISK"? A quick search unfortunately proved fruitless. The best ramdrive for DOS 3.3 that I know of only provides 242 sectors, 309 free sectors sounds fantastic! Any help in locating it for download would be truly appreciated.
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #339150 is a reply to message #339145] |
Sun, 12 March 2017 18:04 |
gids.rs
Messages: 1395
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
On Sunday, March 12, 2017 at 1:33:40 PM UTC-6, Tom Porter wrote:
> A while back... someone showed me BITDISK which is a RAMDRIVE for DOS 3.3.... it utilizes every available resource on the board that is not lower 48k to provide 309 blocks of ramdrive, better than DISK-QUIK by beagle-bros and everything else I've seen. The only downside is the titlescreen. I have been looking into it and here is what you need to modify to remove the titlescreen.... if anybody is interested....
>
> Change the first line of BITDISK to read...then resave.
> 6000- 4C 73 60 JMP $6073
>
> If the original author is still around... whoops, I'm sorry! -Tom at Naspite
I believe you mean 309 sectors or pages. Blocks is used with Prodos and are 512 bytes each compared to the 256 byte sector.
I don't use DOS 3.3 any more so don't have a need for a ram drive, but when I did, for me the best ramdrive was the ramfactor card. It allowed the Dos 3.3 max of 50 tracks of 16 sectors for 800 sectors (or 400kb).
It also supported a Dos 3.3 ramdrive and a Prodos ramdrive at the same time and you could boot from either one.
Have you tried AMDos or UNIDos yet? Both are DOS3.3 clones that supports regular 5.25 disks but also has support for 2 volumes of 400kb on a 3.5 disk..
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #339253 is a reply to message #305962] |
Mon, 13 March 2017 20:32 |
|
|
Originally posted by: Tom Porter
https://www.dropbox.com/s/vwv1e03izyi98wv/RAMDRIVES.dsk?dl=0
Sorry if some of post is duplicate... here is 3 ram drives.... Tom
----
A while back... someone showed me BITDISK which is a RAMDRIVE for DOS 3.3.... it utilizes every available resource on the board that is not lower 48k to provide 309 blocks of ramdrive, better than DISK-QUIK by beagle-bros and everything else I've seen. The only downside is the titlescreen. I have been looking into it and here is what you need to modify to remove the titlescreen.... if anybody is interested....
Change the first line of BITDISK to read...then resave.
6000- 4C 73 60 JMP $6073
If the original author is still around... whoops, I'm sorry!
(*note, only 1 can be active at a time... and it sits at Slot 3-Drive 1)
(The following file has BITDISK... RAMDRIVE.INF (no titlescreen BITDISK) and LANG_DRIVE.INF which is a small 60 block ramdrive for the language card.... the 'buffer' sits in the 3rd text file buffer, so do not use 3 open txt files while LANG-DRIVE is active, but most people dont use do that anyway..... for DOS 3.3!
|
|
|
|
| Re: BSAVE (ing) in Dos 3.3 sector question? [message #339425 is a reply to message #339253] |
Thu, 16 March 2017 03:02 |
Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
|
Senior Member |
|
|
Tom Porter <laseractiveguy@gmail.com> wrote:
> https://www.dropbox.com/s/vwv1e03izyi98wv/RAMDRIVES.dsk?dl=0
> Sorry if some of post is duplicate... here is 3 ram drives.... Tom
> ----
> A while back... someone showed me BITDISK which is a RAMDRIVE for DOS
> 3.3... it utilizes every available resource on the board that is not
> lower 48k to provide 309 blocks of ramdrive, better than DISK-QUIK by
> beagle-bros and everything else I've seen. The only downside is the
> titlescreen. I have been looking into it and here is what you need to
> modify to remove the titlescreen.... if anybody is interested....
>
> Change the first line of BITDISK to read...then resave.
> 6000- 4C 73 60 JMP $6073
>
> If the original author is still around... whoops, I'm sorry!
> (*note, only 1 can be active at a time... and it sits at Slot 3-Drive 1)
>
>
> (The following file has BITDISK... RAMDRIVE.INF (no titlescreen BITDISK)
> and LANG_DRIVE.INF which is a small 60 block ramdrive for the language
> card... the 'buffer' sits in the 3rd text file buffer, so do not use 3
> open txt files while LANG-DRIVE is active, but most people dont use do
> that anyway.... for DOS 3.3!
>
I'm guessing that's 60 sectors, not blocks...
--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
|
|
|
|
Members
Search
Help
Register
Login
Home
