| |
johncl
Registered: Aug 2007
Posts: 37 |
Silly Basic question
Something I have always wondered about the "good" old Basic was that for a lot of data you had to use the DATA keyword and type lots of numbers, which you then DIM'ed array variables and read them into. Essentially you stored the data twice! As if Basic wasnt sucking up enough memory as it is.
Why didnt they allow a simple way of accessing the DATA blocks like a pointer?
And for my silly question, are all DATA number values stored as 16 bit values or what format does it have? Is there a cool way of e.g. begin your Basic code with DATA statements with assembly data and then sys this to start it? Or do you always have to READ the DATA values and then POKE them to a certain memory location which you can then SYS call to?
The reason I ask this is that I am just tinkering with a silly game on a good old PET 2001 that is programmed in Basic, and I see that I need a fast screen memory copy which I want to program in assembly (but as normal lines of basic since I want this to single load off tape). |
|
... 5 posts hidden. Click here to view all posts....
|
| |
johncl
Registered: Aug 2007
Posts: 37 |
Yes good tip there. REM is probably better to use since you can still use DATA statements for other stuff. And thanks for confirming what I thought about line length. From the structure it seemed that an actual line in basic could be much longer.
I did notice that my POKEd DATA line got corrupt if I went to the line and pressed enter again. Some characters are obviously not reproduceable. I wondered about this because it would be quite cool to write assembly code using the character set equivalents and then sys'ing into that DATA or REM line. :)
If I generate that REM statement at another spot in memory I could actually use the built in line relocator in basic to move it into my program. The same trick they used to e.g run C64 Basic programs on an old PET. (Simply by changing the $0401 and $0402 pointers to another place in memory where the "generated" basic is. Oh the fun! :) |
| |
tlr
Registered: Sep 2003
Posts: 1715 |
I'd just do a placeholder space with the REM, and then poke the data in there.
You can even do this:
10 goto 30
20 "<data...>
30 <code> no REM, no trailing ".
Max line length seems to be 255 bytes between the line start addresses.
I'm not sure what happens to embedded 00 bytes though.
EDIT: 00 bytes seems to work, but editing won't work after they are present.
|
| |
enthusi
Registered: May 2004
Posts: 675 |
you still have the adresses for next basic-line IN the code then.
use :
10 ?"ai7qcnbq7xnqmol8u3x2m"
20...
sys1024
for < 1000 byte code |
| |
tlr
Registered: Sep 2003
Posts: 1715 |
Good idea! Let's improve it.
10 POKE648,192
20 ?"<code>";
30 ...
40 POKE648,4:SYS49152 Q: Are all screen codes achievable using PRINT? |
| |
Scout
Registered: Dec 2002
Posts: 1568 |
Okay, i admit...this thread is going beyond the level of lemon64.
Excusez moi!
Oh, and please continue. Me like! :D |
| |
iAN CooG
Registered: May 2002
Posts: 3136 |
Why bothering with data/read/poke at all when you can simply link basic and binaries and crunch the linked prg? All you have to remember is to set basic pointers to avoid data being overwritten by variables and temp strings.
*=$0801
startbasic
incprg mybasicprogram.prg
endbasic
;init routine, jmp here in linker/cruncher
lda #$80
sta $d020
sta $d021
sta $0291
jsr $e536
lda #$14
sta $d018
lda #$ea
sta $0328
ldx #(dataend-datatable-1)
st lda datatable,x
sta $2b,x
dex
bpl st
jsr $A659
jsr $A533
jmp $A7AE
datatable
word startbasic
word endbasic
word endbasic
word endbasic
word endram
word endram
word endram
dataend
*=$8000
endram = *-1
incprg mydatas.prg
incprg myroutines.prg
*=$c000
incprg otherstuff.prg
or simply use
EXOMIZER sfx basic,<start>,<end>,<high> mybasicprogram.prg etcetc -o final.prg
but you have to calc the addresses manually.
|
| |
chancer
Registered: Apr 2003
Posts: 343 |
Quote: Good idea! Let's improve it.
10 POKE648,192
20 ?"<code>";
30 ...
40 POKE648,4:SYS49152 Q: Are all screen codes achievable using PRINT?
Q: Are all screen codes achievable using PRINT?
I can't imagine why not, but maybe some would cause issues, like obvious things inverted heart (clear screen) or colour codes etc. then you could just use something like print chr$ etc, if it's outside the normal range of a-z etc. if there was problems, the would get over that.
A lot of coders did used to use REM statements to code, I've seen over the years in a few interviews, Steve Turner used to on the zx80/81.
maybe I'm talking rubbish, it's been a long time since I've done any form of c64 coding.
|
| |
MorGorr
Account closed
Registered: May 2002
Posts: 47 |
Concerning the characters available via Print: Yes, you cann PRINT all characters. The fun part is that you need the <rvs on> and <rvs off> codes to do that. Thus what you need is a rountine that converts your asm bytes to a printable string. Not too difficult, and avoids any strange effects when editing or listing your Basic program.
If your asm routine is needed elsewhere than the normal screen location, you can either change the screen pointers to print it somewehere else, or make the routine copy itself to the desired location. |
| |
yago
Registered: May 2002
Posts: 332 |
The lazy ones can use Text Magic V2.2
Although done for designing screens, you can also convert any data to printable strings.
|
| |
MorGorr
Account closed
Registered: May 2002
Posts: 47 |
Or, look e.g. at my old game "The Session" and rip the routine from there. The level editor converts the screen into printable strings and saves them to disk in that format. |
| Previous - 1 | 2 - Next |
