Jump to content

Recommended Posts

Hi,

 

I'm confused about using WinVice.

 

How can I develop in an ASM program (like DASM, or other) on Windows and then run it within WinVice.

 

 

I can't figure out how to make that jump.

 

 

I'd rather just develop right on WinVice (on the emulated C64), but I don't know how to.

 

I am going through the super cool ASM book, "Machine Language for Beginners" and that book is doing all development on the C64 (of course) using a little ASM program that the user types in first and then uses for the remainder of the book.

 

 

Is this the best way? Suggestions?

 

 

Thx!

I'm confused about using WinVice.

 

How can I develop in an ASM program (like DASM, or other) on Windows and then run it within WinVice.

 

Assemble program, drag generated PRG file to WinVICE, type SYS followed by the start address (set in the assembler) to start the program. There's ways to streamline things but that's viable to begin with.

 

I am going through the super cool ASM book, "Machine Language for Beginners" and that book is doing all development on the C64 (of course) using a little ASM program that the user types in first and then uses for the remainder of the book.

 

i don't know the book in question, but you can treat WinVICE like a C64 and just type in everything it tells you to. As to if it's the best way, for short programs written for learning purposes that's okay but it'll be unwieldy for actual projects and that's where you should be using an assembler.

OK, with the knowledge that I am a "super-novice" at DASM, how do you generate a PRG file in DASM? Or is this automatic? Or maybe I should just read the DASM documentation a bit closer(?) :-D

 

 

Yeah the program is a bit too big to type in (READ: I don't want to), so I like the drag and drop idea. Much better! ;)

 

 

Thank you for your help!

OK, with the knowledge that I am a "super-novice" at DASM, how do you generate a PRG file in DASM? Or is this automatic? Or maybe I should just read the DASM documentation a bit closer(?) :-D

 

You remember how i recommended against using Dasm previously...? This is one of the other reasons after the biggie about error reporting.

 

ACME has the !to directive that sets the output filename and target platform from the source code, just adding !to "filename.prg",cbm at the top of a source file will generate an assembled program called filename.prg which is ready for dragging and dropping to VICE. Here's a "complete program" in ACME format with BASIC stub (it adds a BASIC line reading 0 SYS2066 which auto starts the code when it's dragged and dropped into VICE) to experiment with:

 

; Select an output filename and format
	!to "core.prg",cbm

; Add a BASIC startline (0 SYS2066)
	* = $0801
	!word entry-2
	!byte $00,$00,$9e
	!text "2066"
	!byte $00,$00,$00

; Entry point at $0812
	* = $0812
entry		inc $d020
	jmp entry

 

It doesn't do anything useful of course (the border should have thin lines of colour in it) but if you keep that as a stock starting point you can staple whatever you're doing on at entry. Lines starting with a semicolon are comments like REM statements in BASIC, they're just there for information and aren't assembled into the final code.

 

Yeah the program is a bit too big to type in (READ: I don't want to), so I like the drag and drop idea. Much better!

 

The drag and drop i was referring to was the assembled file, but it's possible to copy and paste BASIC listings into VICE as well; copy the listing from the source and select "Paste" from VICE's Edit menu, then watch as it's "typed in" for you. If the program is massive it might take two passes pasting half the code each time because there's a size limit so if nothing happens when you select Paste, that's why (i doubt the program is that long but it's worth mentioning, i think i broke it with about 400 lines of BASIC whilst testing RG Rampage).

TMR,

 

Yes I do remember you saying that, and had not really started down the DASM road, I was just using that as an example... So ACME it is then.

 

Thanks for the "complete system" included above, I will use this going forward.

 

What is the significance of 2066? Is that just where you chose to put the program in memory because you know that it is free space?

 

Which begs the question, where could one find a memory map for the 6502? (don't answer, if that is splitting this thread up too much).

 

 

Thanks again TMR, you are very helpful!

 

 

JR

What is the significance of 2066? Is that just where you chose to put the program in memory because you know that it is free space?

 

Pretty much the first space yes, BASIC memory starts at 2049 ($0801) so the 0 SYS2066 starts using space from there and 2066 is a few bytes on from the end of that BASIC command in memory - it could be a few bytes lower down really, but i've always left a little gap personally and that code fragment was just cut and pasted from one of my source files.

 

Which begs the question, where could one find a memory map for the 6502? (don't answer, if that is splitting this thread up too much).

 

You specifically need a memory map for the C64, there's a few common places between 6502-based machines but each has a different layout after the basics. Grab the Programmer's Reference Guide because it's got a couple of memory maps, opcode references and lists of registers for the various chips that'll be helpful.

 

Quick and dirty memory map (all numbers in hexadecimal):

$00 to $ff		zero page ($f0 to $ff are free space, be a bit wary of the latter half when using music drivers).
$0100 to $01ff		stack - don't touch this space unless you REALLY know what you're doing.
$0200 to $03ff		system space (used by the system for various things).
$0340 to $03ff		cassette buffer (useful for storage space - gets mangled if anything is loaded from tape).
$0400 to $07ff		default screen RAM (1,000 bytes of data and the sprite data pointers at the end of the 1K block).

$0801 to $9fff		BASIC program memory - this is your initial 39K of work space until you get used to things.

$a000 to $bfff		the BASIC ROM is shadowed in here - can be turned off to get at the RAM underneath.
$c000 to $cfff		4,096 bytes of spare space, can be used for storage.
$d000 to $dfff		The I/O - registers for the VIC-II, SID and CIA twins live here along with the screen colour RAM.
$e000 to $ffff		the Kernel ROM is shadowed in here - again, can be turned off but getting rid of this is more fiddly.

 

(Typed in on the fly when i'm supposed to be working, so if anyone spots an error just scream! =-)

Fairly similar but the start of Basic program is different and can vary depending on how much Ram is installed.

 

But if you use LOAD "file",8,1 the program will attempt to load at the address specified by the first 2 bytes of the file.

Edited by Rybags

How much of what you have stated applies to the VIC-20? I recently got one for $20, so I couldn't pass it up.

 

It seems like they are similar in a lot of ways.

 

They're similar in some ways yes, although as Rybags points out the memory map is totally different with BASIC RAM starting at 4097 ($1001) for an unexpanded machine and ending at 7679 ($1dff) where the screen RAM starts (I/O space is up at $9000). Here's my headers for ACME to assemble for unexpanded VIC:

 

; Select an output filename and format
	!to "filename.prg",cbm

; Add a BASIC startline (0 sys4112)
	* = $1001
	!word entry-2
	!byte $00,$00,$9e
	!text "4112"
	!byte $00,$00,$00

; Entry point at $1010
	* = $1010
entry		inc $900f
	jmp entry

 

Generally speaking, the memory map i wrote is correct to about $03ff for any Commmdodore 8-bit but after that all bets are off so a specific memory and register map for each machine is needed.

If you want balls-deep C64 specifics:

 

http://www.bombjack.org/commodore/books/pdf/Compute%27s_Mapping_the_Commodore_64.zip

 

There is also the C64 programmer's reference guide. You can probably snag a real copy for like 3$.

 

If I can find a spare (sometimes I have two books!) , I can give you it. I don't need two.

 

 

If you start with the Butterfield book, he explains use of memory. He even has you using the tape-drive buffer for stuff. It's a good explanation of what's going on. Check it out!

Thanks guys! Is there a reason to develop on one versus the other? V20 vs. C64. I though the only diff was memory size on these machines?

 

Or am I mistaken (happens a lot!) ???

 

P.S. I'll take any books you think would be helpful! Happy to pay the shipping or a small fee for the book. Really appreciate it.

 

 

JR

Thanks guys! Is there a reason to develop on one versus the other? V20 vs. C64. I though the only diff was memory size on these machines?

 

Umm no... the VIC 20 has a 22 by 23 character screen (176x184 pixels high res or 88x184 pixels multicolour) whilst the C64 has 40 by 25 characters (320x200 high res, 160x200 multicolour). The C64 also has raster interrupts, hardware fine scrolling, eight 24x21 (12x21 in multicolour) pixel hardware sprites, bitmapped screen modes and the SID chip for sound.

 

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...