| Some c64 programming help requested [message #81711] |
Sat, 12 July 2003 09:49  |
enzo
Messages: 6
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Some c64 programming help requested [message #81713 is a reply to message #81711] |
Sat, 12 July 2003 10:29  |
Fray Bentos Dave
Messages: 3
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Some c64 programming help requested [message #81715 is a reply to message #81713] |
Sat, 12 July 2003 11:18 |
enzo
Messages: 6
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Some c64 programming help requested [message #81719 is a reply to message #81711] |
Sat, 12 July 2003 12:27 |
Cameron Kaiser
Messages: 1622
Registered: December 2011
Karma: 0
|
Senior Member |
|
|
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/ **
|
|
|
|
| Re: Some c64 programming help requested [message #81733 is a reply to message #81711] |
Sat, 12 July 2003 15:46 |
Jouni T. Nordlund
Messages: 29
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Some c64 programming help requested [message #81833 is a reply to message #81719] |
Sat, 12 July 2003 21:11 |
Sam Gillett
Messages: 2422
Registered: June 2003
Karma: 0
|
Senior Member |
|
|
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!
|
|
|
|
| Re: Some c64 programming help requested [message #81861 is a reply to message #81733] |
Sat, 12 July 2003 23:17 |
nospam9212
Messages: 26
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Some c64 programming help requested [message #81890 is a reply to message #81861] |
Sun, 13 July 2003 04:09 |
Glenn P.,
Messages: 123
Registered: April 2013
Karma: 0
|
Senior Member |
|
|
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! =-----
|
|
|
|
| Re: Some c64 programming help requested [message #81929 is a reply to message #81711] |
Sun, 13 July 2003 08:31 |
enzo
Messages: 6
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
|
|
| Re: Some c64 programming help requested [message #82166 is a reply to message #81861] |
Sun, 13 July 2003 19:25 |
Sam Gillett
Messages: 2422
Registered: June 2003
Karma: 0
|
Senior Member |
|
|
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!
|
|
|
|
| Re: Some c64 programming help requested [message #82201 is a reply to message #81711] |
Mon, 14 July 2003 07:38 |
enzo
Messages: 6
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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
|
|
|
|
| Re: Some c64 programming help requested [message #82204 is a reply to message #82201] |
Mon, 14 July 2003 08:17 |
Anders Carlsson
Messages: 776
Registered: July 2003
Karma: 0
|
Senior Member |
|
|
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
|
|
|
|
|
|
| Re: Some c64 programming help requested [message #82709 is a reply to message #81719] |
Tue, 15 July 2003 15:06 |
henk
Messages: 3
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
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.
|
|
|
|
| Re: Some c64 programming help requested [message #84645 is a reply to message #81890] |
Sun, 20 July 2003 01:47 |
nospam9212
Messages: 26
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
On 7/13/03 4:09 AM Eastern Daylight Time, "Glenn P.," C128User@FVI.Net
wrote...
>> 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.
I'll assume you are correct, that the OP wanted to overwrite the old file in
question. I am just not convinced that is a great thing to do BEFORE the new
file is on the disk.
> 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.
You did see where I wrote you NEED enough space for two complete files to be on
the disk? That was the comment I replied to and that's the point of my whole
method.
> 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.
40 blocks.... full. Next.
Can I quote myself...
---
"enough room for it to be written to the disk before the old one was deleted."
---
So your point is well taken but sidesteps my point. You are saying I don't have
enough room to save my file in your example AFTER I clearly replied in
agreement to a post stating you need the room to allow for both the new and the
old files to exist at the same time. I'm confused on what point you are trying
to make. Scratch the old one first? Ok. My point is that doing a delete/save
rather than save/delete is similar to the "save with replace bug", and it is.
My caution was to NEVER use a disk for saving a "work in progress" on a disk
with a 624 block seq file. That's not caution, that's asking for trouble. I had
disks labeled.. "work". They were blank when a work started and checked often
for ample space.
You are correct. You can NOT use my method of saving 70 blocks safely with only
40 blocks free. Even your way it's not completely foolproof. I wanted to know
that there was NEVER a time where none of my versions of my program was NOT on
the disk. Having a program in ram only, when ram is volatile, is risky. How
risky? For me... to risky. That's my personal preference. (yes, I know it's
possible to recover a scratched file..been there, done that)
> 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
I'm confused... you advocate saving 70 blocks to a 40 blocks free disk, then
saving again to an empty disk, when I say save to a disk with ample room?
Oooook.
When I wanted redundacy (and I sometimes did) I used both sides of a blank
disk. Why would you use a disk with only 40 blocks as a "work" disk is
complicating things and asking for trouble, in my opinion. Consider it full...
move on.. geeeezzzz... if that's your final version.. ok. At that point, the
file lives on the blank/work disk and you are trying to free up space on a disk
where it will stay, but on the work disk itself? Maybe that's where we are
moving in two different directions.. I am thinking a work in progress and you
are thinking of saving a work completed, in need of a home? Hell if your gonna
save to a blank... that IS my method. Save where you have enough room. Save
work on a blank, THEN delete old, save completed work on non-blank. We do agree
a blank is the key. Save there FIRST... BEFORE you delete the old file, then
the work is always on a disk... somewhere. You aren't really gonna try and
defend deleting the old file BEFORE you save to a blank, are you?
Does...
delete old file to make room (<<<risky)
save on non-blank
save on blank
....make more sense than...
save on blank
delete old file
save on non-blank
....?
Unless you have a real good reason why you should delete the old file from
non-blank disk before you save to a blank, I stand firm. Save somewhere with
ample room first.
You say my method leaves you stuck but then suggest similar. shrugg.
> (2) even assuming there is NO disk error, you should always immediately
> Verify the newly-saved program.
Yep.
> Furthermore, if this is possible without losing the program in memory (for
> example, by using JiffyDOS),
Never had JD, never will... now what? I used BUDDY Assembler that saved asm
source like BASIC and I often used the same memory areas that the wedge used...
now what? I hate software wedges anyway.
Short story...
I had a C64 that used to reset itself anytime anybody turned out the bathroom
light (voltage spike... used to hear it as a loud snap thru my guitar amp,
too). I hated when I was into a save and ... bang... one of the kids hit that
switch. Now... If I was scratching my file when that happened, I'd have to set
about recovering the blocks that were scratched and of course, all the new work
in memory would be gone. If I never scratched first, it'd be reload old file
and go.
Lighting strike outage once took out a BASIC program I was writing for hours on
my Atari65XE... I left the unit on and went for a short break on a visit next
door when it happened. That was my first experience and taught me to do
periodic saves.
I also like having a few more than just one old version of my work, so
overwriting was a no-no.
I guess there are just more than one way to do backups. It depends on your
level of comfort on what works best for you.
-= 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
|
|
|
|
| Re: Some c64 programming help requested [message #84766 is a reply to message #84645] |
Sun, 20 July 2003 16:16 |
Jason Petersen
Messages: 22
Registered: July 2003
Karma: 0
|
Junior Member |
|
|
Nospam9212 wrote:
> Never had JD, never will... now what?
What's wrong with JiffyDOS?
> I used BUDDY Assembler that saved asm
> source like BASIC and I often used the same memory areas that the wedge used...
> now what? I hate software wedges anyway.
Saving ASM source as a BASIC listing is just so.. wrong. EBUD rulez :)
--
Jason
|
|
|
|
Members
Search
Help
Register
Login
Home
