help getting started in homebrew!!

[Tom]

__sp is just a label.

 Similar if I did this

array:
array_header: .ds 2
array_data:    .ds 256

Even when using ram, a label is just a label. array points to the same location as array_header. A routine accessing __sp (which is an internal stack for arg passing, not the processor stack itself) might do something like; lda __sp+2 etc.

[Charlie]

Ok,thanks, the lack of the colon confused me, as I thought labels always needed a colon.

So,
__sp
__stack    .ds 2

is the same as
__sp:
__stack:    .ds 2

Yes?

Thanks
Charlie

[Tom]

Ok,thanks, the lack of the colon confused me, as I thought labels always needed a colon.

So,
__sp
__stack    .ds 2

is the same as
__sp:
__stack:    .ds 2

Yes?

Thanks
Charlie

 Correct. Though I always use ":" too (wow, that sounds soo dirty. (Wait! That wasn't a pun!. Ahhh man... )). It's confusing sometimes without it and not as easy to spot (no laughing! .... dammit.).

[Charlie]

OK, next question:

When I compile(?) the HelloWorld example with HUC, the resultant ".s" file has, as it's last couple of lines:

   .bss
__arg:

(Minor question:  Is "__arg" related to argc and/or argv?)

When I link(?) the HelloWorld example with PCEAS, the resultant ".lst" file has...gasp!..the same thing
(also at the end). And, slightly prior to the location of this label, is the directive ".bank CONSTANT_BANK"

Somewhat further back, there is another ".bss" section:

    .bss
  msflag: .ds 1
  msvert: .ds 1
  mshorz: .ds 1

And, slightly prior to the location of THESE labels, it the directive ".bank  LIB1_BANK"

So, does this mean that, although both sets of labels are in ".bss" sections, they are not related to each other since they are in different banks?
--OR--
The ".bank" directive has no effect on the ".bss" directive, and all the ".bss" sections are sequential.
That is, in memory would they look like this:

.bss
msflag: .ds 1
 msvert: .ds 1
mshorz: .ds 1
__arg:

Thus, "__arg", as a label, is in the memory location immediately/sequentially following "mshorz"?

Thanks,
Charlie

---------Modified/Edited----------
Sorry, Tom, I honestly do not get the pun!  Should I translate ":" as "colon", therefore "I alway use colon too"?

[Tom]

Thus, "__arg", as a label, is in the memory location immediately/sequentially following "mshorz"?

 Correct. BSS (and ZP) are only attached to bank $f8 (initial scratchpad ram of the PCE). BSS keeps its own counter and starts from $2200. Every time you declare a label and length, the counter is incremented. It doesn't matter where you use BSS or what bank. It makes code very portable and dynamic. Especially if you were going to write a lib for someone else to use, you don't have to include a separate variable list file. Take note though, the ORG directive does effect BSS.

 If you were to do

  .BSS
  .org $2800
some_array: .ds 8

 It does effect where it's placed in static mapped ram. It's not a good idea though to do that. The BSS counter will continue after $2800+8, so you'll potentially skip over allocatable ram/space. Or, if memory was already defined there, you'll get conflicting/overlapping addresses and the assembler (iirc) won't spit out any warning or errors. Using ORG before BSS has no effect on BSS defines.

Sorry, Tom, I honestly do not get the pun!  Should I translate ":" as "colon", therefore "I alway use colon too"?

 Yup.

[Charlie]

Ok, thanks.
But both of my previous questions were actually to get some basic knowledge leading up to this:

If this is correct:
msflag: .ds 1
msvert: .ds 1
mshorz: .ds 1
__arg:

then I can think of it like this (example addresses)
$0000 msflag
$0001 msvert
$0002 mshorz
$0003 __arg

Yes?

So then how is code like this valid?:

sta    __arg-(\1),Y

If the parameter is $01 and Y is $00,for example, I read this as "store the data in the A register into mshorz", which obviously is dangerous to the data in mshorz.
Am I mis-interpreting this code, or is it expected that there will never be a combination of parameter-and-Y values that cause this?

Charlie

[Tom]

Ok, thanks.
But both of my previous questions were actually to get some basic knowledge leading up to this:

If this is correct:
msflag: .ds 1
msvert: .ds 1
mshorz: .ds 1
__arg:

then I can think of it like this (example addresses)
$0000 msflag
$0001 msvert
$0002 mshorz
$0003 __arg

Yes?

 Correct. (And just double verified by checking the sym file on a test file).

So then how is code like this valid?:

sta    __arg-(\1),Y

If the parameter is $01 and Y is $00,for example, I read this as "store the data in the A register into mshorz", which obviously is dangerous to the data in mshorz.
Am I mis-interpreting this code, or is it expected that there will never be a combination of parameter-and-Y values that cause this?

 Yes, it would store Acc into mshorz. Assuming you used that in a macro. Expanded it would be sta __arg-$01,y. But if you'd using Y index reg, why use a system like that?

[Charlie]

It's in "huc_opt.inc", and it hurts!

But, I just wanted to make sure I had it right.

Ok, moving on....

This works:

========
   .code
   .bank START_BANK,"Base Library 1"
   .org  $E000
_reset:
sei                                   ; interrupts off
cld         ; clear the decimal flag
ldx   #$FF      ; initialize the stack pointer
txs
lda   #$FF      ; map the I/O bank in the first page
tam   #0
lda   #$F8      ; map RAM bank in the second page
tam   #1
nop
nop
nop
bra *

==============

This doesn't work:

   .code
   .bank START_BANK,"Base Library 1"
   .org  $E000
_reset:
sei                                   ; interrupts off
cld         ; clear the decimal flag
ldx   #$FF      ; initialize the stack pointer
txs
lda   #$FF      ; map the I/O bank in the first page
tam   #0
lda   #$F8      ; map RAM bank in the second page
tam   #1
jsr MySub
bra *
MySub:
nop
nop
rts
==================

Don't yet know enough to figure out why.  Here's some hints:
1. Prior to this code is the typical "include" directive. The include file has the format:

(list of EQUates)
.zp
(list of ".ds")
.bss
.org   $2680
(list of ".ds")
__arg:              <==This should look familiar!!!

2. I am 99% sure the failure is at the "RTS" in the sub.  My admittedly incomplete knowledge leads me to believe that the stack pointer is not being stored properly, and thus the Instruction Pointer doesn't return
back to the calling routine. 

3. I note, with irony, that the include file does exactly what Tom said is dumb:
" .BSS
  .org $2800
some_array: .ds 8"
Of course, I did not know until now that BSS starts at $2200. 

So, could it be the ORG directive inside the BSS? How would that affect the stack operation? Or is it something else?

Thankls
Charlie

[Tom]

3. I note, with irony, that the include file does exactly what Tom said is dumb:
" .BSS
  .org $2800
some_array: .ds 8"
Of course, I did not know until now that BSS starts at $2200.

So, could it be the ORG directive inside the BSS? How would that affect the stack operation? Or is it something else?

 Ohh... That has to do with the CD system card. On the system card they reserve some ZP space and a chunk of ram from $2200-27ff(or maybe 26ff , don't remember offhand) for internal registers and stuff. HuC tends to mimic the system card even for hucard projects. The video interrupt system for hucards also mimics the system card one.

==============

This doesn't work:

   .code
   .bank START_BANK,"Base Library 1"
   .org  $E000
_reset:
sei                                   ; interrupts off
cld         ; clear the decimal flag
ldx   #$FF      ; initialize the stack pointer
txs
lda   #$FF      ; map the I/O bank in the first page
tam   #0
lda   #$F8      ; map RAM bank in the second page
tam   #1
jsr MySub
bra *
MySub:
nop
nop
rts
==================

 How do you know it doesn't work? You've stepped through it in the mednafen debugger? Assuming that's the very first thing from the reset vector, that *should* work fine. Stack is initialized, ram is mapped, interrupts are disabled, hardware bank mapped. Call mysub, return, then infinite jmp.

[Charlie]

ok, given the "That has to do with the CD system card......." stuff, I can (or should) move the org to
$2000, or maybe even remove that directive totally and .BSS will default to it?

Don't know what a system card is/does.

"How do you know it doesn't work? You've stepped through it in the mednafen debugger?"
Used a hardware emulator/debugger, don't know what a mednafen is/does.  The RESET vector definitely works.  I have similar code snippets on both the TurboExpress and the TurboGrafx16, and both fail in the same way.  It is also quite possible that I have mis-configured the emulator.  I was just hoping that there would be some glaring error in the code relating to some specific TE/TG16 hardware setup that I was missing, like maybe another TAM configuration; that is the main reason this is such simple code, without multiple blocks/sections, etc.  If you are reasonably confident this is good code,  I'll go back and do a "redo from start" (Ha!  remember that?).

Thanks for the help
Charlie
 

[Arkhan]

system card is for CD ROM system attachment....

and Mednafen is a command line emulator with a built in debugger.  Check it out and be sure to check the debugger manual too so you are using it right

[Tom]

ok, given the "That has to do with the CD system card......." stuff, I can (or should) move the org to
$2000, or maybe even remove that directive totally and .BSS will default to it?

 Well ORG $2200 - cause ZP is 2000-20ff and stack is 2100-21ff. But by default it starts off at $2200.

Don't know what a system card is/does.

 Just a bunch of subroutines (bios) for CD games But it reserves/setups the main ram bank. Not really much of a problem because for CD games, it's all ram.

[Charlie]

HA!  I was going to ask this next:
"cause ZP is 2000-20ff and stack is 2100-21ff"

And I guess this ram is located inside the console, rather than on the HUC card.  What I'm going to do next is to do an "STA" into ram, then attempt to read it back.  This should tell me whether or not I can actually access the ram; if not, I certainly can't expect the JSR/RTS to work. 

Thanks for your assist.

Charlie

[Charlie]

First step success!  I can now write-to/read-from RAM, and therefore JSR's work.  Here's some pictures of my prelim HuCard simulator:

1.Full PCB
 

2.Inserted in TE


3. Close up
 

My test proggie is simple, a lot of NOP's and one JSR.  But at least I am talking to PROM-vs-RAM with  proper address decoding.  (The ribbon cable connects to the IDE/emulator)

Charlie

[Arkhan]

wait wait

youre making a board thingy that will let you send code from PC to huCard slot?