Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #4942 > unrolled thread

Searching for a boot-loader

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Searching for a boot-loader Marc Golombeck <marc.andre.tichy@googlemail.com> - 2019-01-01 11:02 -0800
    Re: Searching for a boot-loader David Schmidt <schmidtd@my-deja.com> - 2019-01-02 01:51 -0500
    Searching for a boot-loader Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-01-02 01:09 -0800
      Searching for a boot-loader Antoine Vignau <antoine.vignau@laposte.net> - 2019-01-02 03:57 -0800
        Re: Searching for a boot-loader qkumba <peter.ferrie@gmail.com> - 2019-01-02 13:44 -0800
          Re: Searching for a boot-loader ol.sc@web.de (Oliver Schmidt) - 2019-01-02 22:22 +0000
            Re: Searching for a boot-loader Antoine Vignau <antoine.vignau@laposte.net> - 2019-01-02 19:17 -0800
              Re: Searching for a boot-loader gids.rs@sasktel.net - 2019-01-08 12:45 -0800
            Re: Searching for a boot-loader Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-03-19 12:53 -0700
              Re: Searching for a boot-loader James Davis <JPD.Enterprises@outlook.com> - 2019-03-19 13:10 -0700
              Re: Searching for a boot-loader Michael J. Mahon <mjmahon@aol.com> - 2019-03-19 17:55 -0500
                Re: Searching for a boot-loader Michael Pohoreski <michael.pohoreski@gmail.com> - 2019-04-01 14:52 -0700
                  Re: Searching for a boot-loader D Finnigan <dog_cow@macgui.com> - 2019-04-02 00:06 +0000
                  Re: Searching for a boot-loader gids.rs@sasktel.net - 2019-04-01 22:33 -0700
                    Re: Searching for a boot-loader Brian Patrie <bpatrie@bellsouth.spamisicky.net> - 2019-04-02 01:56 -0500
                      Re: Searching for a boot-loader gids.rs@sasktel.net - 2019-04-02 10:32 -0700
                  Re: Searching for a boot-loader Michael J. Mahon <mjmahon@aol.com> - 2019-04-02 17:11 -0500
              Re: Searching for a boot-loader Steve Nickolas <usotsuki@buric.co> - 2019-03-20 22:37 -0400
    Re: Searching for a boot-loader James Davis <JPD.Enterprises@outlook.com> - 2019-03-19 13:12 -0700

#4942 — Searching for a boot-loader

I am searching for a simple boatloader without the need to use an OS like DOS 3.3. I had a discussion with Michael Packard some time ago where he told me that he uses a boot loader that loads his game e.g. Alien Downpour completely into RAM in one go while displaying a splash screen. This makes the DOS routines sweet & small and leaves him extra space in RAM for his code.

This solution is nice (and available on GitHub) but I also need a solution where I can reload parts while my software is running (only loading, no saving of data at the moment). Furthermore I am looking for a toolchain how can I prepare a DSK-image and put code parts onto this disk when using a simple boot loader.

If there are already solutions document elsewhere I would be happy for a friendly hint or if somebody is willing to share some knowledge I would also be very happy ;-)

Thx and Happy New Year 2019!!!

[toc] | [next] | [standalone]

#4943

On 1/1/19 2:02 PM, Marc Golombeck wrote:
> I am searching for a simple boatloader without the need to use an OS like DOS 3.3. I had a discussion with Michael Packard some time ago where he told me that he uses a boot loader that loads his game e.g. Alien Downpour completely into RAM in one go while displaying a splash screen. This makes the DOS routines sweet & small and leaves him extra space in RAM for his code.
> 
> This solution is nice (and available on GitHub) but I also need a solution where I can reload parts while my software is running (only loading, no saving of data at the moment).

This sounds like you're wandering into OS territory to me; you're beyond 
the "load some sectors into 0x800 and execute it" that you get with the 
bootloader scheme.  But you can make use of the Disk II firmware 
routines to do sector reads if that's all you want to do.  Sector 
placement will be important rather than, say, filenames (or even file 
structures), but you can do that level of reading fairly cheaply by 
borrowing the firmware.

> Furthermore I am looking for a toolchain how can I prepare a DSK-image and put code parts onto this disk when using a simple boot loader.

There are lots of toolchains to do just that.  Everyone has their 
favorite.  My favorite is AppleCommander:
http://applecommander.sourceforge.net/acguide.html
I actually use it from within my ant build scripts:
http://applecommander.sourceforge.net/acant.html

But it if course assumes some kind of OS is on the disk.  If you're 
going with something lighter weight, you might be interested in Martin 
Haye's NakedOS:
https://bitbucket.org/martin.haye/super-mon/wiki/Home

[toc] | [prev] | [next] | [standalone]

#4944

How many sectors do you need to load?

= The Poor Man's Way =
(Read only track 0)
You can load (up to) an entire track of data by changing a single byte of the boot sector @ 00 from the standard $01 to $10. Yes it will be dog slow but it literally takes zero effort. If you pack your code/data using LZ4, etc. you can load even more data.


= The Middle Class's Way =
(Use a File System)
Personally, I'd recommend using qkumba's ProRWTS 2
https://github.com/peterferrie/prorwts2

IIRC his other utilities have been superseded with ProRWTS 2 but may be of interest:

* https://github.com/peterferrie/prorwts
* https://github.com/peterferrie/qboot


= The Rich Man's Way =
(Bypass the File System)
It is rather trivial to write a SeekTrack routine and call $C65C to load sectors once you've seen how it is done. See my disassembly of Fantavision's boot sector for details; specifically section: Ye Olde Boot Tracing
https://github.com/Michaelangel007/apple2_fantavision_reloaded#ye-olde-boot-tracing


Cheers
Michael

[toc] | [prev] | [next] | [standalone]

#4945

Accolade boot @ http://boutillon.free.fr/Underground/Cours/Cours_GDF/Gp11/Gp11.html - Accoboot is a simple track/sector load. Easy but no DOS structure present so harder to write data on it)

Or use Quiksilver's OS used in Data East products. It loads file through A/X/Y where A contains the filename from a DOS 3.3 disk.

Antoine

[toc] | [prev] | [next] | [standalone]

#4946

Marc, you can essentially three choices:
- you can use real files in DOS 3.3 formatted disk, and then use Antoine's suggestion of Quiksilver's OS (but lacks source code);
- you can use real files in a ProDOS formatted disk, and then use Michael's suggestion of ProRWTS2 (comes with source and tech support :-) );
- you can use chunks of data written directly to the disk without structure, and then use Michael's suggestion of qboot (also comes with source and tech support).

If you go with ProDOS, then the same ProRWTS2 code can run from a hard disk, too.

In any case, using files (either DOS 3.3 or ProDOS) is perhaps the simplest way to place data on the disk, in case they ever need updating.

[toc] | [prev] | [next] | [standalone]

#4947

Hi,

[...]
>- you can use real files in a ProDOS formatted disk, and then use Michael's suggestion of ProRWTS2 (comes with source and tech support :-) );
[...]
>If you go with ProDOS, then the same ProRWTS2 code can run from a hard disk, too.

Please don't underestimate that aspect! At least from my POV there's
about no valid reason to create anything new in 2019 that's not
compatible with ProDOS.

With ProRWTS2 there's just no need anymore to tie anything to 5.25"
floppies. This only creates efforts for others to untie it from 5.25"
floppies at a later point in time...

Just my two cents,
Oliver

[toc] | [prev] | [next] | [standalone]

#4948

I'd also take the ProDOS way. Nevertheless, there's the Fast Boot option as well, I've upload a maker at http://www.brutaldeluxe.fr/public/

av

[toc] | [prev] | [next] | [standalone]

#4950

I 2nd the use of Prodos.  If a Ram disk is available, then copying a floppy to a Ramdisk makes very easy and very fast to load and run  game segments or files, and even save high scores.

[toc] | [prev] | [next] | [standalone]

#5037

> no valid reason to create anything new in 2019 that's not 
> compatible with ProDOS. 

There are at least a _few valid_ reasons *not* to use a ProDOS file system:

a) If you want to have a filename that starts with a number due to ProDOS's bone-headed filename design that a filename MUST start with a letter and not a number. ProDOS will print a generic "SYNTAX ERROR?" instead of a human readable "Bad filename". (Under DOS 3.3 it will re-direct to using the cassette port if you try and you'll probably be wondering why your machine appears to be hung.)

e.g. These all fail with both ProDOS and DOS 3.x

  SAVE 3D
  SAVE 2048

b) You want filenames longer then a cryptic 15 chars.  (Insert joke that someone will _always_ have a valid reason for why they want N+1 characters in their filenames when the file system only supports N characters. Considering filenames are designed **for people** they reason(s) are _probably_ valid -- within reason of course.)  You will get a nondescript "SYNTAX ERROR" if you try instead of a human friendly "Filename too long" error message.  

It is too bad Apple didn't design ProDOS with 32 character filenames -- but I guess that is what happens when you are so focused on a single tree (the "cuteness" of using a nibble for file length) that you lose sight of the *entire* forest such as not storing a 4 digit year.

c) You want to use spaces for nice human readable names instead of _dumb kludges_ like periods or underscores.  Some people actually care about readability and whitespace in their filenames. It is unfortunate Apple didn't. :-/

d) You want extremely fast loading/writing and/or minimal, dead-simple RWTS code and thus utilize 4+4.

There are pros/cons to both DOS's and ProDOS's file system.  They **both suck** depending on the use case.  i.e. While DOS gave us 32 character filenames, **with** spaces, the designer was completely _clueless_ about where meta-data goes and stuck it in the file directly instead of the directory. **Faceplam**

That said, there is something to be said for ubiquity, whether that be DOS 3.3 or ProDOS. Most of the above limitations are edge cases, not the general case.

Michael

[toc] | [prev] | [next] | [standalone]

#5038

On Tuesday, March 19, 2019 at 12:53:40 PM UTC-7, Michael Pohoreski wrote:
> > no valid reason to create anything new in 2019 that's not 
> > compatible with ProDOS. 
> 
> There are at least a _few valid_ reasons *not* to use a ProDOS file system:
> 
> a) If you want to have a filename that starts with a number due to ProDOS's bone-headed filename design that a filename MUST start with a letter and not a number. ProDOS will print a generic "SYNTAX ERROR?" instead of a human readable "Bad filename". (Under DOS 3.3 it will re-direct to using the cassette port if you try and you'll probably be wondering why your machine appears to be hung.)
> 
> e.g. These all fail with both ProDOS and DOS 3.x
> 
>   SAVE 3D
>   SAVE 2048
> 
> b) You want filenames longer then a cryptic 15 chars.  (Insert joke that someone will _always_ have a valid reason for why they want N+1 characters in their filenames when the file system only supports N characters. Considering filenames are designed **for people** they reason(s) are _probably_ valid -- within reason of course.)  You will get a nondescript "SYNTAX ERROR" if you try instead of a human friendly "Filename too long" error message.  
> 
> It is too bad Apple didn't design ProDOS with 32 character filenames -- but I guess that is what happens when you are so focused on a single tree (the "cuteness" of using a nibble for file length) that you lose sight of the *entire* forest such as not storing a 4 digit year.
> 
> c) You want to use spaces for nice human readable names instead of _dumb kludges_ like periods or underscores.  Some people actually care about readability and whitespace in their filenames. It is unfortunate Apple didn't. :-/
> 
> d) You want extremely fast loading/writing and/or minimal, dead-simple RWTS code and thus utilize 4+4.
> 
> There are pros/cons to both DOS's and ProDOS's file system.  They **both suck** depending on the use case.  i.e. While DOS gave us 32 character filenames, **with** spaces, the designer was completely _clueless_ about where meta-data goes and stuck it in the file directly instead of the directory. **Faceplam**
> 
> That said, there is something to be said for ubiquity, whether that be DOS 3.3 or ProDOS. Most of the above limitations are edge cases, not the general case.
> 
> Michael

Please, can you suggest any alternatives we can try that will still read DOS 3.x and ProDOS disks (5.25", 3.5", HDD)?

[toc] | [prev] | [next] | [standalone]

#5040

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
>> no valid reason to create anything new in 2019 that's not 
>> compatible with ProDOS. 
> 
> There are at least a _few valid_ reasons *not* to use a ProDOS file system:
> 
> a) If you want to have a filename that starts with a number due to
> ProDOS's bone-headed filename design that a filename MUST start with a
> letter and not a number. ProDOS will print a generic "SYNTAX ERROR?"
> instead of a human readable "Bad filename". (Under DOS 3.3 it will
> re-direct to using the cassette port if you try and you'll probably be
> wondering why your machine appears to be hung.)
> 
> e.g. These all fail with both ProDOS and DOS 3.x
> 
>   SAVE 3D
>   SAVE 2048
> 
> b) You want filenames longer then a cryptic 15 chars.  (Insert joke that
> someone will _always_ have a valid reason for why they want N+1
> characters in their filenames when the file system only supports N
> characters. Considering filenames are designed **for people** they
> reason(s) are _probably_ valid -- within reason of course.)  You will get
> a nondescript "SYNTAX ERROR" if you try instead of a human friendly
> "Filename too long" error message.  
> 
> It is too bad Apple didn't design ProDOS with 32 character filenames --
> but I guess that is what happens when you are so focused on a single tree
> (the "cuteness" of using a nibble for file length) that you lose sight of
> the *entire* forest such as not storing a 4 digit year.
> 
> c) You want to use spaces for nice human readable names instead of _dumb
> kludges_ like periods or underscores.  Some people actually care about
> readability and whitespace in their filenames. It is unfortunate Apple didn't. :-/
> 
> d) You want extremely fast loading/writing and/or minimal, dead-simple
> RWTS code and thus utilize 4+4.
> 
> There are pros/cons to both DOS's and ProDOS's file system.  They **both
> suck** depending on the use case.  i.e. While DOS gave us 32 character
> filenames, **with** spaces, the designer was completely _clueless_ about
> where meta-data goes and stuck it in the file directly instead of the
> directory. **Faceplam**
> 
> That said, there is something to be said for ubiquity, whether that be
> DOS 3.3 or ProDOS. Most of the above limitations are edge cases, not the general case.
> 
> Michael

“there is something to be said for ubiquity”

Indeed!  In fact there is *everything* to be said for ubiquity. 

“Being standard is better than being “better”.

and:

“The perfect is the enemy of the good.”

Every realizable system has limitations. Engineering is about making
conscious tradeoffs to achieve a result that is well-suited to a purpose.

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#5048

I hear ya about Ubiquity & "Engineering is all about trade offs."

It sucks that DOS 3.x file system is awesome in some ways:

+ 32 char file names with spaces. (Yes!! Take that brain dead CP/M and FAT12 !!) People got REALY clever with catalogs. Another "lost art". :-(

 and crap in other regards:

 - Can't store file data on track zero (Really?? EVERY disk was *assumed* to waste 3 tracks of DOS?? Of which Track 2 only _actually_ used 4 sectors. Ah, the good old days of manually using a sector editor to free them up.)
- Who the hell thought it would be a good idea to put metadata in the FILE itself?? WTF is the _entire_ point of a directory / catalog in the first place??? To store meta data!
- Buffer Bloat.  Hey, who knew that it pioneered modern crappy engineering practices! (Thank ${diety} "Fast DOSes" addressed this.)
- Using Track/Sector instead of a logical block number? How quant.  It is sad and almost comical to see that early hard drives and the BIOS on the IBM PC went through the *exact* same short sightedness with the whole CHS (Cylinder / Head / Sector) addressing schemes fiasco.
https://en.wikipedia.org/wiki/Cylinder-head-sector

What's that Murphy's Computer Law quote?

Meskimen's Law:
"There is never time to do it right, but there is always time to do it over."


Meanwhile, ProDOS solves _most_ of the problems:
+ directories
+ blocks
+ hard drive support
+ extendable commands
+ used the correct forward slash as a path separator
+ nice param passing API

but then

- totally GIMPS filenames both length and valid characters.
- is bloated

Can't win them all.

The more I use ProDOS the more I'm actually impressed with how many things ProDOS got right. Definitely some REALLY nice bits of engineering hidden away there!

Kind of makes one wonder who the hell decided to use the colon as a path separator on classic Mac OS when Unix & ProDOS already used the forward slash?? Another NIH syndrome of Apple?

Every time I see shitty File System design I'm reminded of that Unix quote:

"Those that don't understand Unix are condemned to reimplement it, badly."

Along with xkcd #927 about standards
https://www.xkcd.com/927/

I guess you are getting old when you see how NOT to do things. :-)

If I had a time machine I **wouldn't** go back and stop Hitler --  I change it so everybody used / for paths/directories/volumes, and used LF for new lines instead of having 3 stupid ways of doing the same thing.

Ah, 1st world problems -- you gotta love them. =P

[toc] | [prev] | [next] | [standalone]

#5049

Michael Pohoreski wrote:
>
> Kind of makes one wonder who the hell decided to use the colon as a path
> separator on classic Mac OS when Unix & ProDOS already used the forward
> slash?? Another NIH syndrome of Apple?

No, it's so you could name files with a short date, like 10/84 or somesuch.

[toc] | [prev] | [next] | [standalone]

#5050

On Monday, April 1, 2019 at 3:52:26 PM UTC-6, Michael Pohoreski wrote:
> I hear ya about Ubiquity & "Engineering is all about trade offs."
> 
> It sucks that DOS 3.x file system is awesome in some ways:
> 
> + 32 char file names with spaces. (Yes!! Take that brain dead CP/M and FAT12 !!) People got REALY clever with catalogs. Another "lost art". :-(
> 
>  and crap in other regards:
> 
>  - Can't store file data on track zero (Really?? EVERY disk was *assumed* to waste 3 tracks of DOS?? Of which Track 2 only _actually_ used 4 sectors. Ah, the good old days of manually using a sector editor to free them up.)
> - Who the hell thought it would be a good idea to put metadata in the FILE itself?? WTF is the _entire_ point of a directory / catalog in the first place??? To store meta data!
> - Buffer Bloat.  Hey, who knew that it pioneered modern crappy engineering practices! (Thank ${diety} "Fast DOSes" addressed this.)
> - Using Track/Sector instead of a logical block number? How quant.  It is sad and almost comical to see that early hard drives and the BIOS on the IBM PC went through the *exact* same short sightedness with the whole CHS (Cylinder / Head / Sector) addressing schemes fiasco.
> https://en.wikipedia.org/wiki/Cylinder-head-sector
> 
> What's that Murphy's Computer Law quote?
> 
> Meskimen's Law:
> "There is never time to do it right, but there is always time to do it over."
> 
> 
> Meanwhile, ProDOS solves _most_ of the problems:
> + directories
> + blocks
> + hard drive support
> + extendable commands
> + used the correct forward slash as a path separator
> + nice param passing API
> 
> but then
> 
> - totally GIMPS filenames both length and valid characters.
> - is bloated


I am glad they didn't have large file names.  Forces people to be creative.  With the extra info stored in a file header, an extra 15 bytes for the file name would have limited a block to just 9 files per block.  The already 39 bytes + 15 = 54, and 512/54 = 9 with 26 bytes remainder wasted at the end of each block.

Plus the information for a CATALOG would not fit on one line of the 80-col screen.


> If I had a time machine I **wouldn't** go back and stop Hitler --  I change it so everybody used / for paths/directories/volumes, and used LF for new lines instead of having 3 stupid ways of doing the same thing.


I look at Hitler as a necessary evil.  There are a lot of inventions because of the war, and without the war, no-one would know what real death and destruction was.  It takes a war with that much pain and suffering to now make humans think twice before starting another war.

I say it is good that he wasn't smart enough and too arrogant to wait.  He started the war before half of his inventions were realized and before he developed and mastered the nuclear bomb.

No, I wouldn't change a thing.  We are on this path because alien civilizations have already come to the same conclusion that this is the only way for humans to learn from their mistakes.

[toc] | [prev] | [next] | [standalone]

#5051

On 02/04/2019 00.33, gids.rs@sasktel.net wrote:
> I am glad they didn't have large file names.  Forces people to be creative.  With the extra info stored in a file header, an extra 15 bytes for the file name would have limited a block to just 9 files per block.  The already 39 bytes + 15 = 54, and 512/54 = 9 with 26 bytes remainder wasted at the end of each block.
> 
> Plus the information for a CATALOG would not fit on one line of the 80-col screen.

But how often do we really NEED to see the creation time?

I can live with 15 chars, though.  (Unix used to be limited to 14.)  But 
limiting us to letters and periods is ridiculous.

[toc] | [prev] | [next] | [standalone]

#5052

On Tuesday, April 2, 2019 at 12:56:24 AM UTC-6, Brian Patrie wrote:
> On 02/04/2019 00.33, Rob wrote:
> > I am glad they didn't have large file names.  Forces people to be creative.  With the extra info stored in a file header, an extra 15 bytes for the file name would have limited a block to just 9 files per block.  The already 39 bytes + 15 = 54, and 512/54 = 9 with 26 bytes remainder wasted at the end of each block.
> > 
> > Plus the information for a CATALOG would not fit on one line of the 80-col screen.
> 
> But how often do we really NEED to see the creation time?
> 
> I can live with 15 chars, though.  (Unix used to be limited to 14.)  But 
> limiting us to letters and periods is ridiculous.


Since I do quite a bit of programming, I actually glance at the creation date quite a bit.  Feels weird sometimes to pick up on a program that I started back in 2013.

I believe there is a program out there called QIX or QFIX that addresses the allowable letters in a filename.

[toc] | [prev] | [next] | [standalone]

#5053

Michael Pohoreski <michael.pohoreski@gmail.com> wrote:
> 
> I hear ya about Ubiquity & "Engineering is all about trade offs."
> 
> It sucks that DOS 3.x file system is awesome in some ways:
> 
> + 32 char file names with spaces. (Yes!! Take that brain dead CP/M and
> FAT12 !!) People got REALY clever with catalogs. Another "lost art". :-(
> 
>  and crap in other regards:
> 
>  - Can't store file data on track zero (Really?? EVERY disk was *assumed*
> to waste 3 tracks of DOS?? Of which Track 2 only _actually_ used 4
> sectors. Ah, the good old days of manually using a sector editor to free them up.)
> - Who the hell thought it would be a good idea to put metadata in the
> FILE itself?? WTF is the _entire_ point of a directory / catalog in the
> first place??? To store meta data!

There are arguments 

> - Buffer Bloat.  Hey, who knew that it pioneered modern crappy
> engineering practices! (Thank ${diety} "Fast DOSes" addressed this.)
> - Using Track/Sector instead of a logical block number? How quant.  It is
> sad and almost comical to see that early hard drives and the BIOS on the
> IBM PC went through the *exact* same short sightedness with the whole CHS
> (Cylinder / Head / Sector) addressing schemes fiasco.
> https://en.wikipedia.org/wiki/Cylinder-head-sector

There is an intuitive appeal to addressing a disk in a way that can be
directly used to access it. Of course, if media are always changing, hiding
the geometry is a win. 

Conversions from block number to track/sector had better not require
divisions!

> What's that Murphy's Computer Law quote?
> 
> Meskimen's Law:
> "There is never time to do it right, but there is always time to do it over."

Right up there with one of my laws: “Quick and dirty” is never quick but
always dirty. 

> Meanwhile, ProDOS solves _most_ of the problems:
> + directories
> + blocks
> + hard drive support
> + extendable commands
> + used the correct forward slash as a path separator
> + nice param passing API
> 
> but then
> 
> - totally GIMPS filenames both length and valid characters.
> - is bloated
> 
> Can't win them all.

Amen. 

Restricting component name lengths when pathnames can have many components
is pretty much in line with the time when it was designed. At least they’re
twice as long as MSDOS. ;-)

Actually, as a long-time assembly language programmer, strategies to
shorten names are pretty ingrained. ;-)

> The more I use ProDOS the more I'm actually impressed with how many
> things ProDOS got right. Definitely some REALLY nice bits of engineering hidden away there!

I agree. I’ve been delighted with the versatility of the “B(yte)” modifier.
Being able to read and write arbitrary strings of bytes in a file is quite
powerful. 

> Kind of makes one wonder who the hell decided to use the colon as a path
> separator on classic Mac OS when Unix & ProDOS already used the forward
> slash?? Another NIH syndrome of Apple?
> 
> Every time I see shitty File System design I'm reminded of that Unix quote:
> 
> "Those that don't understand Unix are condemned to reimplement it, badly."
> 
> Along with xkcd #927 about standards
> https://www.xkcd.com/927/
> 
> I guess you are getting old when you see how NOT to do things. :-)
> 
> If I had a time machine I **wouldn't** go back and stop Hitler --  I
> change it so everybody used / for paths/directories/volumes, and used LF
> for new lines instead of having 3 stupid ways of doing the same thing.
> 
> Ah, 1st world problems -- you gotta love them. =P

Remember, “natural” and “easy to use” are relative to the user’s previous
experience.  You should see what COBOL users think is natural!

-- 
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

[toc] | [prev] | [next] | [standalone]

#5041

I may offer another filesystem suggestion, that may not necessarily be an 
ideal one. ;)

FAT12 ;)

-uso.

[toc] | [prev] | [next] | [standalone]

#5039

On Tuesday, January 1, 2019 at 11:02:14 AM UTC-8, Marc Golombeck wrote:
> I am searching for a simple boatloader without the need to use an OS like DOS 3.3. I had a discussion with Michael Packard some time ago where he told me that he uses a boot loader that loads his game e.g. Alien Downpour completely into RAM in one go while displaying a splash screen. This makes the DOS routines sweet & small and leaves him extra space in RAM for his code.
> 
> This solution is nice (and available on GitHub) but I also need a solution where I can reload parts while my software is running (only loading, no saving of data at the moment). Furthermore I am looking for a toolchain how can I prepare a DSK-image and put code parts onto this disk when using a simple boot loader.
> 
> If there are already solutions document elsewhere I would be happy for a friendly hint or if somebody is willing to share some knowledge I would also be very happy ;-)
> 
> Thx and Happy New Year 2019!!!

Please, can you suggest any alternatives we can try that will still read our DOS 3.x and ProDOS disks (5.25", 3.5", HDD)?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web