From Newsgroup: comp.sys.cbm

Hihi

On 13 Jul 2003 15:57:15 +0200, Anders Carlsson
<anders.carlsson@mds.mdh.se> wrote:

Is it possible to 'load' a file by sending the command to channel 15
and reading the output? (by this I mean directories as well as files)

You can read PRG files just like they were SEQ files:
OPEN 15,8,15:OPEN x,8,y,"file,p,r" and then all the usual stuff
involved in reading sequential files. The directory is easiest
read block-by-block (track 18). Both methods are well described
elsewhere, like the 1541 manual.

Ahh, got them to read, I'm having to read character by character with
GET# though and I'm not too sure whether ASC(b$) is returning the
actual value of the byte or doing some sort of odd translation so I'm
having some trouble with the filesizes, also INPUT# always reports
string to long which is making it all a bit slow, I might have to look
at some other code for ideas :p

Find the beginning of the file and read block-by-block. Throw away
the n-1 first blocks. Actually you only have to parse the pointer
to the next block. Maybe the disk command B-R will work if you only
want to read a few bytes?

Actually wanting to read the whole file 16K at a time, eheh, but I
think I know how to do it, I might even know how to do it so it's not excruciatingly slow but I suppose it's a case of waiting and seeing
there, remembering things I've not done in 15 years is proving hard :P

Thanks :)

--
Enzo

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

enzo <enzo@fusionchat.net> writes:

I'm not too sure whether ASC(b$) is returning the actual value of
the byte or doing some sort of odd translation

I think the only case you have to watch out for is when you get
empty string, i.e. GET#1,b$ : IF b$="" THEN b$=CHR$(0)

Actually wanting to read the whole file 16K at a time,

If I recall correctly, the 1541 has eight buffers á 256 bytes, in
case you considered buffering lots of stuff in that memory before
transferring to the computer.

--
Anders Carlsson
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Anders Carlsson" <anders.carlsson@mds.mdh.se> wrote in message news:k2gn0fhwbel.fsf@legolas.mdh.se...

I think the only case you have to watch out for is when you get
empty string, i.e. GET#1,b$ : IF b$="" THEN b$=CHR$(0)

Right, when a CHR$(0) is read, it gets converted to the empty string, for
which ASC(B$) will fail. Also, an EOF is read as a Shift-G or something if
you keep reading past end-of-file.

It's a bit shorter to do handle the '\0' character with ASC(B$+CHR$(0)), or faster if you predefine Z$=CHR$(0) then use ASC(B$+Z$).

--
White Flame (aka David Holz)
http://www.white-flame.com/
(spamblock in effect)


--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hihi

It's been a while since I've written on a real C64, if someone could
answer these I'd appreciate it...

Firstly in Basic, when saving a file, how do you overwrite a file that
already exists? I seem to get a flashing red light and nothing saved
when I try...

When I start basic, it reports 38911 bytes free, does that mean there
are other areas of memory I can use for machine code without affecting
the basic program in memory, if so, where are they?

How do I load/save an area of memory from Basic? (like SAVE "somedata"
CODE 49152,8192 or whatever on the spectrum)

In assembler, how do I read from Basic variables? as in, if I called a
routine with say PA=1 PB=2 PC$="FOO" how would I read those? I realise
I could just poke (at least the numbers) to the relevent place but
that doesn't seem like a great solution...

The screen display seems to be from 1024 onwards, where are the
attributes stored?

Thanks :)

--
Enzo
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

have a hunt for the "programmers reference guide". that will tell you loads.

there will be an online version somewhere - I just got the vic20 one



Dave

"enzo" <enzo@fusionchat.net> wrote in message news:rf40hvk9resedm2tqg69kn61l8a4l5anrl@4ax.com...

Hihi

It's been a while since I've written on a real C64, if someone could
answer these I'd appreciate it...

Firstly in Basic, when saving a file, how do you overwrite a file that already exists? I seem to get a flashing red light and nothing saved
when I try...

When I start basic, it reports 38911 bytes free, does that mean there
are other areas of memory I can use for machine code without affecting
the basic program in memory, if so, where are they?

How do I load/save an area of memory from Basic? (like SAVE "somedata"
CODE 49152,8192 or whatever on the spectrum)

In assembler, how do I read from Basic variables? as in, if I called a routine with say PA=1 PB=2 PC$="FOO" how would I read those? I realise
I could just poke (at least the numbers) to the relevent place but
that doesn't seem like a great solution...

The screen display seems to be from 1024 onwards, where are the
attributes stored?

Thanks :)

--
Enzo

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hihi

On Sat, 12 Jul 2003 15:29:20 +0100, "Fray Bentos Dave"
<Fraybentos@nospam.com> wrote:

have a hunt for the "programmers reference guide". that will tell you loads.

Ah, I actually have the book if I could find it (assuming it's the one
with a fold out schematic), all my C64 books seem to have disappeared
-_-

there will be an online version somewhere - I just got the vic20 one

Looked online for these things, it's not easy to find C64 stuff -_-,
in particular I couldn't find out how to overwrite when saving at all
although I'm damn sure I only have to add a single character to the
filename to do it, heh, I could really do with at least a few of those answering though, my file manager has ground to a halt (well almost)
trying to do it all in BASIC, Simon's compiler seems to create the
fastest and smallest binaries but it's still not fast enough for many
things :(

ty :p

--
Enzo

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

enzo <enzo@fusionchat.net> writes:

Firstly in Basic, when saving a file, how do you overwrite a file that >already exists? I seem to get a flashing red light and nothing saved
when I try...

There is a Save-and-Replace command, but I wouldn't use it (at least one demonstrated bug exists).

Instead, scratch first, save second:

open15,8,15,"s0:program":close15:save"program",8:end

I usually make this a line in my program, and then RUN that line so I don't have to type it all the time.

When I start basic, it reports 38911 bytes free, does that mean there
are other areas of memory I can use for machine code without affecting
the basic program in memory, if so, where are they?

Sure. There is a large tract of RAM from $c000-$cfff, although a lot of
machine language utilities like this area also. There is also RAM under
the BASIC and Kernal ROMs, and under the I/O space, although these take
a little more work to get at and are hard to manipulate from BASIC without help.

How do I load/save an area of memory from Basic? (like SAVE "somedata"
CODE 49152,8192 or whatever on the spectrum)

Most people use a utility cartridge for this, and it's just handy to
have. Epyx FastLoad, Final Cartridge, SuperSnapshot and Action Replay
all have this functionality. You can find FastLoad cartridges very
cheaply (I got a box of 5 for $5 at a flea market).

If you want an actual BSAVE subroutine, ask and I'll give you a few
one-liners you can play with.

In assembler, how do I read from Basic variables? as in, if I called a >routine with say PA=1 PB=2 PC$="FOO" how would I read those? I realise
I could just poke (at least the numbers) to the relevent place but
that doesn't seem like a great solution...

It would be easier to pass the variables instead. Here is an idiom I use frequently:

jsr $aefd ; check and throw away comma
jsr $ad9e ; BASIC prmeval
jsr $b7f7 ; convert to int, store in $14-$15

So, if you were to assemble this to 49152, and did sys49152,w+3 the result
of w+3 would be stored in integer 16-bit form with low byte at $14 and
high byte at $15.

The screen display seems to be from 1024 onwards, where are the
attributes stored?

Colour memory is at $d800 (55296). Only the bottom nybble is significant.

It would be to your advantage to try and find either an electronic or
paper copy of one or both of the Programmers' Reference Guide, or Mapping
the 64. Both of these have comprehensive memory maps and intricate
instructions for manipulating the 64's more advanced features. Project64
I believe has them both in e-text form, but getting a book version is
much more convenient. I keep several copies of each, just because I'd be
lost without them if a copy disappeared.

--
Cameron Kaiser * ckaiser@floodgap.com * posting with a Commodore 128
personal page: http://www.armory.com/%7Espectre/
** Computer Workshops: games, productivity software and more for C64/128! **
** http://www.armory.com/%7Espectre/cwi/ **
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

enzo kirjoitti artikkelissa <rf40hvk9resedm2tqg69kn61l8a4l5anrl@4ax.com>

Hihi

It's been a while since I've written on a real C64, if someone could
answer these I'd appreciate it...

Firstly in Basic, when saving a file, how do you overwrite a file that already exists? I seem to get a flashing red light and nothing saved
when I try...

SAVE "@0:FILENAME",8 is the trick, though a bit buggy. Make sure you have
free disk space for TWO copies of your program.

Following will delete old version before saving the new one:
OPEN 1,8,15,"S0:FILENAME":CLOSE1:SAVE"FILENAME",8

When I start basic, it reports 38911 bytes free, does that mean there
are other areas of memory I can use for machine code without affecting
the basic program in memory, if so, where are they?

The cassette buffer (starts at 828) is good for smaller programs and area ta 49152-53247 (C000-CFFF) for larger. There is ram also "under" basic & kernal rom addresses, they'll do if you don't need OS's routines like PRINT (JSR $FFD2). You turn rom areas off by pokeing into memory location 1.

How do I load/save an area of memory from Basic? (like SAVE "somedata"
CODE 49152,8192 or whatever on the spectrum)

There are "pointer locations" for start & end of basic program area, find
them (45-48 or something), replace the values with your program's start and end, and save as normal.
You'd better get a machine code monitor :)

The screen display seems to be from 1024 onwards, where are the
attributes stored?

You mean the colours? At 55296-56295.
--
Jouni Nordlund
Pori, Finland
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm


Cameron Kaiser wrote ...

There is a Save-and-Replace command, but I wouldn't use it (at least one >demonstrated bug exists).

Instead, scratch first, save second:

Provided that there is enough room on the disk, slightly safer is:

1. Save under a temporary filename.
2. Scratch the old file.
3. Rename the temporary file.

Power failures are not common these days... but they do happen.

Best regards,

Sam Gillett aka Mars Probe @ Starship Intrepid 1-972-221-4088
Last 8-bit BBS in the Dallas area. Commodore lives!





--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

On 7/12/03 3:46 PM Eastern Daylight Time, Jouni T. Nordlund jouni.norlund@mbnet.fi wrote...

SAVE "@0:FILENAME",8 is the trick, though a bit buggy. Make sure you have >free disk space for TWO copies of your program.

Bingo. The "save with replace bug" from what I've read/experienced is that you must have enough space on the disk to write the entire program. The problem is if the program is say.. 80 blocks long and you only have 70 blocks, the s.w.r bug will not alert you to the fact that there isn't enough space left on the disk. It will merrily write 70 blocks, truncating the file and delete your good but older version (it really is still there, I believe. You may be able to recover IF you are aware right away that something has gone wrong). Next time you load your program, you may wonder what happened. You may not be aware there is something wrong. You were bitten by the "save with replace bug".

I have never.. and I really mean never, ever had the save with replace damage a file as long as there was enough room for it to be written to the disk before the old one was deleted. The problem is... if you're adding to the file, it's getting longer, how do you know there's enough room? It can be done. 664 blocks can always hold two BASIC files at their max size. Don't put anything else on the disk. I did a lot of assembly source in Buddy assembler... the one where you write/saved source code like BASIC. Never had problems, although I did believe the bug existed and went a different route, just to be safe. :)

Following will delete old version before saving the new one:
OPEN 1,8,15,"S0:FILENAME":CLOSE1:SAVE"FILENAME",8

You're building nearly the same bug into this little commandline. You shouldn't scratch the old file *before* you are sure you've properly written the new file to the disk. Seems quick, easy and reliable... it's not.

To be safe...

write new file
validate the new file is good
delete old file *
rename new file to old name *

(*optional... sometimes having a few older versions of your program is not a bad thing)

I used to put the commands on lines 1, 2, 3, 4 as REM statements in reverse order (line 4 being the write command. You'll find out why if you try it without reversing it), list 1-4, remove the rems one at a time and have a... half manual, half automated system of replacing files.. feeling pretty confident I was covered.


-= Francis Yarra =-
fyarraATjunoDOTcom
http://members.aol.com/fyarra001/ads - My drywall website http://members.aol.com/fyarra001 - My C64 website http://members.aol.com/prsnl99 - My personal website

--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

On 13-Jul-03 at 3:17am -0000, <nospam9212@aol.commune> wrote:

Following will delete old version before saving the new one:
OPEN 1,8,15,"S0:FILENAME":CLOSE1:SAVE"FILENAME",8

You're building nearly the same bug into this little commandline. You shouldn't scratch the old file *before* you are sure you've properly
written the new file...

I disagree. "It's not a bug, it's a feature." This gives you extra space by OVERWRITING (which IS, by the bye, what the original question specified) the original file.

If you have a forty-block Original Program, forty blocks Free on disk, and
a New Program seventy blocks long, with YOUR way, you're Stuck. The only
way out in this case is to DELETE the Original before Saving the New.

0 "TEST DISK " TD 2A
624 STUFF.TXT SEQ <== Try saving a 70-block "NEW PROGRAM"
40 OLD PROGRAM PRG to this disk using YOUR method!
40 BLOCKS FREE.

I have very seldom (I won't say NEVER) have any problem with Scratch-&-Save; one just has to use a little extra caution, that's all.

ANY time you overwrite an older version of a program, you should ALWAYS:

(1) immediately afterward check the drive light to be sure it's not flashing (if it is, you should always assume "disk full" and save again, to another, empty, disk before proceding any further); and

(2) even assuming there is NO disk error, you should always immediately
Verify the newly-saved program.

Furthermore, if this is possible without losing the program in memory (for example, by using JiffyDOS), always check the disk directory to be sure that the size of the new file is what you expect it to be before proceding to
other work.

With practice, these things can (and should) become second nature.

-- _____
{~._.~} >>>>>>>> [ "Glenn P.," <C128User@FVI.Net> ] <<<<<<<<
_( Y )_ ----------------------------------
(:_~*~_:) [My Sister, On Her Dog's Obedience]: "Nothing with teeth bigger
(_)-(_) than mine is going to think it's in charge around here."



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Hihi

On Sat, 12 Jul 2003 14:49:50 +0100, enzo <enzo@fusionchat.net> wrote:
[Snip]

Ah, thanks to everyone who responded to this, particularly Anders
Carlsson, Cameron Kaiser and Jason Petersen, my original questions are
now answered, I do however have a couple more now though :p

Is there an improved C64 BASIC editor? either for the C64 or for the
PC? I'm editing on the PC atm and actually saving snapshots, I
understand there's a small assembly program for the c64 that allows
you to scroll up and down long BASIC programs without all the LIST
23000-23100 etc., looked for it, but can't find it in a format I can
use -_- that or something on the PC that can edit PRG files would be
excellent, bear in mind I'd need to insert the colour control
tokens...

Is it possible to 'load' a file by sending the command to channel 15
and reading the output? (by this I mean directories as well as files)

Is it possible to read n blocks from a specific position in a file?
(could be any filetype)

Don't need solutions for the last two here, just a pointer in the
right direction if you could :p

Thanks

--
Enzo
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

"Fray Bentos Dave" <Fraybentos@nospam.com> wrote in message news:<UUUPa.526$Bc4.92@news-binary.blueyonder.co.uk>...

have a hunt for the "programmers reference guide". that will tell you loads.

there will be an online version somewhere - I just got the vic20 one

The C64 Programmer's Reference Guide can be downloaded from:

http://project64.c64.org/hw/c64.html
--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm


Nospam9212 wrote ...

I used to put the commands on lines 1, 2, 3, 4 as REM statements in reverse >order (line 4 being the write command. You'll find out why if you try it >without reversing it), list 1-4, remove the rems one at a time and have
a... half manual, half automated system of replacing files.. feeling pretty >confident I was covered.

A slightly more automatic way to save your changes is to use something like this.

Start your program at line 100. Start your save routine at line 10. Add
this line

5 GOTO 100

Use RUN to test your changes.

Use RUN 10 to save the new version.

And, if you don't want the program to run after saving, just add a STOP statement to the last line of the save routine.

Best regards,

Sam Gillett aka Mars Probe @ Starship Intrepid 1-972-221-4088
Last 8-bit BBS in the Dallas area. Commodore lives!







--- Synchronet 3.18b-Win32 NewsLink 1.113

From Newsgroup: comp.sys.cbm

Cameron Kaiser <ckaiser@floodgap.com> wrote in message news:<3f10355e$0$29001$45beb828@newscene.com>...

In assembler, how do I read from Basic variables? as in, if I called a >>routine with say PA=1 PB=2 PC$="FOO" how would I read those? I realise
I could just poke (at least the numbers) to the relevent place but
that doesn't seem like a great solution...

It would be easier to pass the variables instead. Here is an idiom I use >frequently:

jsr $aefd ; check and throw away comma
jsr $ad9e ; BASIC prmeval
jsr $b7f7 ; convert to int, store in $14-$15

So, if you were to assemble this to 49152, and did sys49152,w+3 the result
of w+3 would be stored in integer 16-bit form with low byte at $14 and
high byte at $15.

Since the variables go into memory in the order they're encountered,
I just start by creating some variables for passing stuff, they'll be at
the beginning of the variable list and easy to find, then just use them
like any other variable.

For integer variables, Basic does the conversion for you (however it stores them bigendian)

For arrays and strings it's a little more complicated, since the variable
list contains a pointer rather than the actual value but it's not that
much more complicated.
--- Synchronet 3.18b-Win32 NewsLink 1.113