BitWise wrote:
backspace119 wrote:
I'm actually checking for direct addressing mode, I was following the syntax found
hereOn the '816 the direct page is can start at any address in bank 0 so you can have code like this ...
Code:
; These routines expect the caller to have set $DF00 as the direct page address
; so that direct-page instructions are used to access hardware registers.
00000020 = SPI_SCK .equ 1<<5
00000040 = SPI_MOSI .equ 1<<6
00000080 = SPI_MISO .equ 1<<7
.dpage $df00
.longa ?
.longi ?
SpiInit:
00:F177 08 : php
short_a
+ .longa off
00:F178 E220 + sep #$20 ; Make A register 8-bit
00:F17A A920 : lda #SPI_SCK ; Set SCK as lo output
00:F17C 0424 : tsb PDD4
00:F17E 1420 : trb PD4
00:F180 A940 : lda #SPI_MOSI ; Set MOSI as an output
00:F182 0424 : tsb PDD4
00:F184 A980 : lda #SPI_MISO ; Set MISO as an input
00:F186 1424 : trb PDD4
00:F188 28 : plp
00:F189 60 : rts
.. where the hardware registers PDD4 (at $DF24) and PD4 (at $DF20) can be accessed with direct page instructions as they are here.
Sorry for the very late reply, got deep into working on this thing.
Presently, my assembler makes no assumptions about where the direct page is. You configure where you want DP to be at startup, and the assembler will lay out any vars you declare as DP vars there. The one issue here is the DP cannot be relocated at runtime (other than initially setting it to where the assembler is told it will be at) yet, as I do not have a system for changing that up.
I realise that this creates another conundrum now, the one you've been pointing me to, that LDA $00 could be either DP or not, but it must be assembled correctly.
The way that I set up compiling is not optimal at this point, it was much better than my original design, but I realize now it will be better to determine addressing mode before passing information to compiling code. Because of this, I'll probably rewrite that system so it takes in addressing modes along with the data, and then spits out an opcode plus the data appended.
Until then, it may be dangerous to relocate the DP on my system. Fortunately, this isn't an incredibly hard fix, it will just be tedious.
I'm going to push my code soon and put some release information here, I've added lots of features (.BYTES directive, CONST vars (that get values written into EEPROM at a location determined by the assembler from parameters setting where CONST vars should be stored) bug fixes to some compilation stuff, and the ability to connect over serial to an arduino EEPROM programmer like the one I built (and I may extend functionality to others out there like it, and eventually let it talk directly to the computer over a serial connection)).
I think that I didn't quite realize what dangers you were pointing me to until I wrote this message. At the very least, I can protect against it by requiring some form of denotation when accessing the DP, to ensure that the correct opcode is used.