[CSDb] - User Forums - KickAssembler: Is initializing mem *=$0400 .byte $00 and so on equivalent to lda/sta?

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > KickAssembler: Is initializing mem *=$0400 .byte $00 and so on equivalent to lda/sta?

2024-12-10 12:43

Sam

Registered: Aug 2010
Posts: 21

KickAssembler: Is initializing mem *=$0400 .byte $00 and so on equivalent to lda/sta?

First: I'm just setting up my win 11 dev environment for C64, and finally got my VS Code + KickAssembler to build and run in VICE. I'm hitting a lot of beginner problems though, and I'm not sure if it is something that I'm not understanding right or if there is still somethis off with my dev setup.

If there is a better place to ask KickAssembler-related questions, I'll be bothering them instead. Thanks.

The newbie question: Is initializing memory in KickAssembler with

*=$0400
.byte $00, $01, $02, $03

equivalent to just lda/sta:ing the data to $0400?

I tried an example from the net (https://github.com/nealvis/c64_samples_kick/blob/master/sprites..) and added a simple custom charset test with $d018, then tried to init some chars to $0400. With the lda/sta it works as I expect, but with the *=$0400 mem init the sprites disappear, the upper left corner is havind @ABC and the rest of the screen is @.

What am I missing here?

2024-12-10 13:09

Martin Piper

Registered: Nov 2007
Posts: 722

Line 9 of that source file has: *=$0801 "BASIC Start"
Then proceeds to put the data for a BASIC SYS 4096 statement etc. This starts your code at 4096.
The start of the data in the output prg file is the expected default starts of BASIC code, for the SYS, then the sprite data follows, then the code.

If you add "*=$0400 .byte $00, $01, $02, $03" this changes the memory start to be $0400 and the prg no longer has the BASIC SYS at the start. You're changing the memory layout of your PRG file. The rest of the screen is filled with @ because that is the default memory clear value for any uninitialised memory between $0400 and $0801.
Using the .byte directive just puts the data in the prg file, this prg is usually directly injected into the emulator's RAM, or the emulator might pretend it is in a virtual drive and "load" the data, which yeah sure the kernal will then load and sta the data usually from the kernal $f51c code areas. It's not really the same as lda#/sta... since the CPU isn't usually executing those instructions, but the end result is roughly the same for those memory locations.

The prg file is just a single contiguous block of memory from the start address to the end address. So it will have to have any spare memory between those ranges initialised to a default value, or filled with data.

If you load the PRG, since it does not start with BASIC SYS anymore, you will have to issue your own SYS 4096, or use the emulator/cartridge monitor to start the code at 4096 (in decimal).

2024-12-10 13:30

Sam

Registered: Aug 2010
Posts: 21

Thanks! Trying to wrap my head around how prg's and the basic upstart works. I changed to basic start code from the example to use the BasicUpstart2(start), but the cause of my problem is the same, prg start memory address changes with the *=$0400.

I thought I could do *=$0400 then some .byte stuff, at the start, then do *=$0801 BasicUpstart2(start) and so on, but this doesn't work. Does the prg file need to start from the $0801 all the time for the basic upstart to work? Can't I just generate a file say from $0400 to $4000 with the basic stuff at $0801?

2024-12-10 13:34

Frantic

Registered: Mar 2003
Posts: 1648

If you load you asssembled file directly on a C64/VICE, it has to obey the requirements of BASIC upstart, but if you pack your file using a packer like exomizer your own assembled file ("inside" of the packed file, so to speak) can be start at 0400 or so, since the packed executable file generated by exomizer will be loaded at 0801 and then the exomizer unpacker code will move your assembled data to the correct place (such as 0400) as it unpacks it.

2024-12-10 13:54

Mixer

Registered: Apr 2008
Posts: 449

Do you mean something like this? This is 64tass example, not kickass, so pardon the digress.. The autostart settings in Vice may also influence how it runs.

*=$0400
.byte 0,1,2,3,4,5,6,7

.fill $3f8,$20 ; rest of the bytes until 0800==$20
; $0800 is not defined so it is 00

*=$0801
.byte $0c,$08,$0a,$00,$9e,$32,$30,$36,$34,$00
*=$0810
inc $d020
jmp $0810

2024-12-10 14:13

Sam

Registered: Aug 2010
Posts: 21

Yes, thanks Mixer! Love the efficiency, you probably remember the "basic part" hexas by heart :-)

My current Win 11 setup loads it to memory correctly to $0400-->, but the autostart doesn't work so I have to read about the VICE autostart settings. Currently it works quite oddly, in my opinion, the thing loads but doesn't start. Doing an immediate "LIST" lists the row and also does a RUN:, but if I move the cursor first and then do a "LIST", I just get the "10 SYS 2064". Also VICE runs at 20x speed before the list.

I do feel dumb at the face of these, but even the Turbo Assembler was a new thing for me back in the years, I had gotted used to just coding stuff just directly to memory, then load "*",8,1 and sys away.

2024-12-10 14:32

Mixer

Registered: Apr 2008
Posts: 449

It'll come back quickly, it is just like riding a bike they say. Great to see you back in c-64 business. :)

And yes, Post mortem those numbers can be carved out of the brain flesh of many c-64 coders. ;)

2024-12-10 14:53

Martin Piper

Registered: Nov 2007
Posts: 722

Quote: Yes, thanks Mixer! Love the efficiency, you probably remember the "basic part" hexas by heart :-)

My current Win 11 setup loads it to memory correctly to $0400-->, but the autostart doesn't work so I have to read about the VICE autostart settings. Currently it works quite oddly, in my opinion, the thing loads but doesn't start. Doing an immediate "LIST" lists the row and also does a RUN:, but if I move the cursor first and then do a "LIST", I just get the "10 SYS 2064". Also VICE runs at 20x speed before the list.

I do feel dumb at the face of these, but even the Turbo Assembler was a new thing for me back in the years, I had gotted used to just coding stuff just directly to memory, then load "*",8,1 and sys away.

I tend to just use $0200 to $ffff (or however much) for my prg, then use my compression tool to make it smaller and wrap it all in a nice BASIC SYS with any start address I like.

2024-12-10 16:05

Sam

Registered: Aug 2010
Posts: 21

Thanks for all the answers, just updating here in case someone else has similar issues: there seem to be some glitches with the way the VS Code extensions that I tried autorun "prg"s with unorthodox starting memory addresses. I tried with two different VS Code KickAssembler extensions and both had issues autostarting the built file, but it autostarted just fine from the command line "x64sc output.prg".

VS Code extensions tested: Kick Assembler 8-Bit Retro Studio v0.23.3 (by Paul Hocker) and KickAss (C64) v1.5.0 (by Captain JINX)

2024-12-10 18:14

Dr.Science

Registered: Oct 2011
Posts: 41

@sam: maybe you can give the Sublime/KickAss package a try?
https://github.com/Swoffa/SublimeKickAssemblerC64
Atleast that's what I use :-)

2024-12-11 06:11

Grue

Registered: Dec 2001
Posts: 162

I use VSCode with 64tass, but I don't use integrated building tools.
There's a shell available at the bottom of the screen where I run manually handmade build.bat which does all the magic which current project needs at the time.
Then again my projects often have multiple files and need .d64/other extra steps.

Refresh

Subscribe to this thread: