Talk:BSAVE

Initial Composition

I am still in the process of adding info and references to this page. I wrote it from scratch and from memory so I need to clean-it up some more and add other platforms and some format variation info.

I'll try to keep the references up to date. Time constraints will undoubtedly prevent me from finishing this today or tomorrow, but seems pretty complete so far.

--Bill Buckels 19:13, 23 May 2007 (UTC)

I need to add information on the BLD and PLT variations of the Bsaved image format used by VGACAD. It's hard to say how many people actually used VGACAD. But the BLD file extension is referenced all over the web, including WikiPedia.

--Bill Buckels 17:04, 24 May 2007 (UTC)

I will need to split this page into several topics before I am finished. I am not at that point yet, and need to complete the Apple II information. I work on this a little every day and leave this page in a more or less finished manner each edit.

--Bill Buckels 09:50, 2 June 2007 (UTC)

I will be finishing this over June.

--Bill Buckels 07:46, 14 June 2007 (UTC)

I have added the first part of the Commodore 128 specifications. I am currently working on this as time permits. and I will bring this to a completion point in the next few weeks.

--Bill Buckels 10:51, 22 August 2007 (UTC)

Errata and so forth

C64

Errata

"C64's BASIC did provide a LOAD command which was intended to LOAD both binary program images and BASIC programs but this command when used in a C64 BASIC program could not be used to load binary data files like BSAVE images. This was because C64 BASIC would clear the current program from memory and automatically attempt to run (chain to) the newly loaded binary data assuming that it was program code. While this was desired behaviour for programs, using the LOAD command in a BASIC program to load binary data files like BSAVE images would cause the C64 to execute invalid instructions and probably to hang."

Not true. A non-relocating load could be specified, which did not overwrite the BASIC program in memory. The non-relocating load would reset the text pointers at CHRGET, which would restart the BASIC program. However, a flag variable could be used to detect that effect and compensate for it. —Preceding unsigned comment added by 70.228.163.254 (talk) 13:47, 18 April 2008 (UTC)

Resolution

After reviewing the above comment months after it was posted, being the wiser I revised this portion of the article and added a programming example. The reference to the flag variable in the above is shown in my example. Why this works is that when a C64 BASIC program is initially RUN, all variables are cleared, but when the non-relocating LOAD command is used in the program causing the program to then restart, variables are not cleared. This results in convoluted program design since it is dependent on a branch-logic type workaround for sure but it is what it is.

--Bill Buckels (talk) 22:26, 26 October 2008 (UTC)

Apple II

Additional Details

Re: Apple ][

The DOS and ProDOS BSAVE command options were a little different. ProDOS offered the option of BSAVE-ing with an "E$xxxx" to specify the last byte of a block of memory instead of an "L$xxxx" specifying the length from "A$xxxx". I believe ProDOS also allowed using decimal addresses and lengths. I don't remember if DOS 3.3 offered the same option. 24.80.98.109 (talk) 07:25, 27 June 2008 (UTC)

Yes, both Apple DOS and ProDOS allow either decimal or hexadecimal values for all command options—including S,D,V (though slot and drive numbers never get high enough to matter). Using decimal is preferable when a programme stores a parametre in a variable, as the programme doesn't need to convert to decimal to pass it to the DOS command. e.g. PRINT CHR$(4);"BLOAD IT ,A";START

ProDOS also allows specifying L or E to limit the scope of a BLOAD—which Apple DOS, annoyingly, does not.

—überRegenbogen (talk) 23:38, 26 July 2009 (UTC)

Resolution

After reading this, I considered changing the article and adding details on additional ProDOS options but decided against it. This article isn't so much about creating a programmer's manual for the Apple II or any other computer as it is about the Graphics image format itself, and yes I do provide lots of additional details, and not to denigrate the comment above, I see little gain in doing so in this case.

The Apple II example is clear and conscise and I am leaving it alone.

--Bill Buckels (talk) 23:16, 26 October 2008 (UTC)

I just realized that some destructive BOT removed my original image example of Apple BSaved Format.

That's too bad really because until I wrote this article the info on BSaved Images was just not anywhere. Now some little fascist process trashes what cannot be replaced. Geez! Some days why bother?

--Bill Buckels (talk) 03:23, 27 March 2009 (UTC)

convolution and disposition

I think my description of the Apple II hi-res graphics mode was much more concise. But i'm not going to spend a lot of effort worrying about it.

Meanwhile, i was considering bringing up the lo-res, double lo-res, and double hi-res modes. But the more i think about it, the more it seems like a better idea to link to the Apple II graphics article and others like it, rather than duplicating the gorey of details here. Assuming that there are articles covering all of the hardware modes of the various machines covered here, this article needs only be glue binding them to the notion of frame buffer formats as file formats, with minimal local description of those formats.
—überRegenbogen (talk) 00:47, 27 July 2009 (UTC)

When I wrote this article I wasn't necessarily talking so much about graphics modes as giving information about a Graphics File Format. This article is not primarily intended to "glue" any "notion" together nor should it be whittled down into something I didn't intend. Before I wrote it, there was very little on the BSaved Graphic Image Format anywhere. It's not about other frame buffer formats like Targa Images anymore than a Queen and a King are the same thing just because they are both people. Having said that, I would like to see the Apple II section expanded if you have actual "historic" examples of bloading lo-res, double lo-res, and double hi-res BSaved Graphics Images.

--Bill Buckels (talk) 20:48, 6 December 2009 (UTC)

BSAVE as a image format

I'm disagree with BSAVE being a Raster image format, because the data is directly extracted by the BASIC's BSAVE command as raw pixel data, similar to an uncompressed and unheadered BMP. Also, BSAVE is a coloquial name for 'BSAVING' a screen. It's in fact a way to dump memory pages to a file and commonly used to dump VRAM, not a proper image format because hasn't been designed to be a standard, doesn't have a patent, or file specifications, like other REAL image formats... Should we move BSAVE to RAW formats section? — Preceding unsigned comment added by TheXDS (talk • contribs) 05:59, 2 January 2011 (UTC)

We should leave this here and add to it as necessary. This contribution is widely read and the only one that gathers this information in one place. In your note, you are confusing BASIC's BSAVE command with the BSAVE raster image format that has long been a standard and a very REAL graphics file format supported as such by much software written in many languages other than BASIC on many computer types during its long history.

It was at the time designed to be a standard. The file specifications for some variations are provided in this contribution. This is a matter of historical record and cannot be changed by opinion. I could also have provided some additional variations like DHGR BIN and AUX file pairs from the Apple II that also saw wide use when I wrote this article but scoped it somewhat.

As far as saying that there is no header... of course there is a header. Comparing the data in a BMP which is device-independent to a device dependent and headered BSAVE graphics image as you have done makes little sense to me. And saying that BSAVE is a colloquial name seems confused... BSAVING a screen is the act of saving a graphics screen in BSAVE raster image format.. "dump memory pages to a file" is far less specific, if that is your whole point. Why you would want to generalize and lose the details that I have provided is beyond me... how is that helpful? I wonder.

Bill Buckels (talk) 03:06, 9 December 2013 (UTC)

That picture

I don't know what bothers me most about it...

• The "nudity" (?)
• The creepy expression on the guy on the right
• The dated "80's computer magazine" cartoon style
• The psychedelic rainbow effect on the 256-colour one

I don't even understand what's happening. "It starts doing this every time Erin logs on!" - doing what?

As far as I can tell, the computer screen dons a top hat, replaces Erin's head, removes her clothes, horribly deforms her body, and makes her do the can-can?

Or maybe the computer itself just transforms into a deformed naked dancing body, while Erin merely stands nearby with her amused coworker and creepy boss?

The picture doesn't really illustrate anything about the format - they are just PNG files. Mostly they just contain arbitrary image data, with the resolution/colour palette being the only constraint. The Commodore 128 images looks like the only ones that show anything meaningful. Sadly these look like they'd be difficult to reproduce.

Does anyone know of an inoffensive free image that would map nicely to the different graphics restraints, to replace the existing ones here - and also be able to convert them to the C128 formats shown?