Failing at 3F BankSwitching

[Windless]

Hi,

 

  I want to try using bank switching. I choose 3F (because why not). From what I read, I expected to write my code with :

-Three 2kb section that would each need to be relocated to $f000

-A fourth 2kb section that would be relocated at $f800 containing the reset vector 

 

 made this test code :

                processor        6502

                seg	Code

;-------------------------------------------------
                org             $f000
                rorg            $f000
start1
                lda             #1

;-------------------------------------------------
                org             $f800
                rorg            $f000
start2
                lda             #2

;-------------------------------------------------
                org             $ff00
                rorg            $f000
start3
                lda             #3

;-------------------------------------------------
                org             $10800
                rorg            $f800

loop
                lda             #1
                sta             $013f

                lda             #2
                sta             $013f

                lda             #3
                sta             $013f

                jmp             loop


                org             $10ffc

                .word           loop

And compiled it as usually :

../dasm.exe org.a -obuild/org.3f -lbuild/org.lst -sbuild/org.sym -f3

but this does not work at all it stella.

 

First if I dump $1800 or $f800 where I should find my code, it is off by two bytes :

 

 

It's the right opcodes, but padded with FF FF, as if stella read the file header (two bytes giving the starting address) as raw data.

 

Secondly, if I manually set PC to jump in my code to switch the banks, my code disappear thought I thought it was in the non switched slice.

 

Any idea f what I did wrong ?

 

Thank you,

Windless.

 

 

Edited January 10, 2020 by Windless

[+Andrew Davie]

Firstly, $3F bankswitching uses $3F to switch, doesn't it?

So right off the bat, I'm wondering why you're writing to $13F?

I've not written $3F code, but $3E is similar, I think.

In $3E, the very top bank of the ROM is the bank switched at startup to $f800...  

would be interesting to see your .lst file which might make those two bytes clear.

 

[+Andrew Davie]

org             $10800

 

I don't get it. You're making a 64K + 2K ROM here, right?

how about changing that to $F800 and see how things go.

Edit: and also, of course, put the reset vector at $FFFC

(that's for a 64K rom). But really, you could build a smalller ROM and adjust accordingly.

 

Edited January 10, 2020 by Andrew Davie

[Windless]

There is definitively something I got wrong.

Let m try to explain how I came to this code :

 

First the "sta $013f" was a test I forgot to remove -> reverted to "sta $3f"

 

Then, the fist bank, if selected, will be seen by the processor at the start of the cartridge area ($f000) hence the rorg $f000. I guess stella expects to see it at the same place in the rom image that it usually find the first bytes of a rom, so  also addd "org $f000" which should make "rorg $f000" useless. It s a 2KB bank,so it should extend to $f800 in both the rom file and the memory mapping

 

The second is also 2k, since it is the second I guess stella expects to see it after the first one (hence "org $f800). When it is selected, the code in it will also be seen at $f000 by the cpu, so I put a "rorg $f000" to tell DASM that this code will be relocated to $f000

 

For the same reason, I made bank three follow bank two ($f800 + $0800 = $ff00) and relocated it at $f000 (org $ff00, rorg $f00)

 

Then the last bank should be always seen by the cpu after the first slice (rorg $f800), and be placed in the rom file after bank 3 (org $10800). But dasm was not happy with an origine that did not fit in 16 bites. At I foudn this informations about mirroring :

*****************************************
* $1000-$1FFF = ROM Addresses $000-$FFF *
* ------------------------------------- *
*                                       *
*     mirror: $x000                     *
*                                       *
*     x = {odd}                         *
*                                       *
*****************************************

So apparently instead of putting everthing at $F000 I put it at $1000 so it compiles. But that does not make much sense since it's the addresses as seen by the CPU that is mirrored, so that should affect rorgs, not orgs. So I tried othors things (like org 0/800/f00/1800 my code to put it at the beginning of the .rom image and rorg it to try to match where I think the code would be seen by the cpu) but that does not wok either. With this last solution, I also have the 2 bytes offset problem :
 

 

 

 

 

I'm lost

[Windless]

Ok, one thing I got wrong is that the addresses should not be counted from $1000 or $F000 but should be stacked from from the end (last bank at $f800 - $ffff, previous at $f000 - $f7ff,  then $e800 - $efff, $e00 - $e7ff,...)

 

Now if I jump to $f802 (instead of $f800) my coderun and bank swtchignis working. Still have to understand the offset !

[+Andrew Davie]

Here's a quick n dirty shell for you to play with...

Place vcs.h and macro.h in the same directory, then assemble ... you should be able to load the binary in stella, hit esc and step through.

3f.asm

[Windless]

@Andrew Davie thank you, but found the answer the very same second I heard the notification form your post

 

So n case some has the same probleme as me :

 

-Sometimes my built file was not replaced (due to stellan or my hex viewer,or my stalled git bash using it ?). I made build script that deleted the old one before build and that saved me some trouble

-Stella indeed load the om from $ffff and backward. This means the ORG in the file should be built from the end, but it also means the last byte of the source file must be at $ffff. My mistake was that I used an "org $fffc" then put the reset vector, but forgot to add the break vector. Then everything was loaded 2 bytes forward

 

It's working now

[+Andrew Davie]

2 minutes ago, Windless said:

@Andrew Davie thank you, but found the answer the very same second I heard the notification form your post

 

So n case some has the same probleme as me :

 

-Sometimes my built file was not replaced (due to stellan or my hex viewer,or my stalled git bash using it ?). I made build script that deleted the old one before build and that saved me some trouble

-Stella indeed load the om from $ffff and backward. This means the ORG in the file should be built from the end, but it also means the last byte of the source file must be at $ffff. My mistake was that I used an "org $fffc" then put the reset vector, but forgot to add the break vector. Then everything was loaded 2 bytes forward

 

It's working now

I strongly strongly suggest you look at and understand my example.

Stela does NOT load "backward". The ORG should definitely NOT be built from the end.

Look at how the example does things. It's much much easier that way.

 

Edited January 10, 2020 by Andrew Davie

[+stephena]

The generated binary is not a power of 2.  In this case, it's 8190 bytes, not 8192.  If I append two null bytes to the binary, it works fine in Stella.  And I can confirm when I look in the binary (outside Stella) that the code does start @ $1800.  So the question left is, is this a bug in Stella, or a bug in how the ROM is being built?  I'm actually leaning towards the former, since whatever is at $1800 in the binary should be seen in Stella as well.

 

Anyone with more experience on the 3F scheme care to give an opinion?

 

EDIT:  I see the problem in Stella code now, but still unsure if it's a bug or undefined behaviour.  According to the docs, "The last 2K segment always points to the last 2K of the ROM image".  So Stella looks at the last 2048 bytes of ROM and makes that a 'segment'.  However, since you're 2 bytes off, everything is offset by 2.

 

So the problem is really, are non-power-of-two binaries legal for this scheme?

Edited January 10, 2020 by stephena
Found problem

[+stephena]

I will test on a Harmony later this evening, to see what happens there.

[Thomas Jentzsch]

ROMs with wrong sizes fail on regular hardware too. 

 

 

 

 

[Kroko]

4 hours ago, stephena said:

"The last 2K segment always points to the last 2K of the ROM image"

I guess nobody really thought of ROM files with a wrong size. This sentence just means that the last 2K block found in the ROM will be the fixed block. You should start counting blocks from the beginning of the file and put the last 2K block to the fixed bank, no matter if the last block is really 2K or not. This is also what would happen if you flash the ROM to some real memory. You would not flash it "backward" but from start of file until end of file, which leaves the last two bytes undefined or empty.

[Thomas Jentzsch]

@Kroko: Would such a ROM with 2 bytes missing in the end work on real hardware? With a Harmony cart they fail.

[Kroko]

As far as I know, the last two bytes are the IRQ/BRK vector. If this vector is unused and can contain random data, I see no reason why a ROM should fail on "real hardware".
In case of Harmony I guess there is also some strategy to fill internal memory from a binary file. And here there could be a problem if the size is incorrect. The
ROM content may be written to the wrong memory location, but that depends on how Harmony maps the file to its memory ...

So there is no answer for "real hardware". You could only tell it for some specific device ...
 

Edited January 10, 2020 by Kroko
typo

[DirtyHairy]

The question of whether a ROM with 8092 bytes would work on real hardware does not seem very meaningful to me. The original 8F bankswitching hardware uses an 8k ROM. If you replace the chip with one that contains less then 8k well-defined bytes, you have to decide on which addresses are undefined and how the chip answers when they are selected; the result will depend on that. If they are at the end, then IRQ/BRK will be messed up, as Kroko says. But there is no "historically right or wrong" way to do it that would prescribe the correct behaviour of emulation.

[Kroko]

$3F is a little bit difficult, because the last 2K chunk in the rom file plays a special role. It needs to be placed at the fixed bank. So you could be tempted to open the file and read the last 2K to place it in the fixed bank.
If you do it like that, then it is almost sure you will not produce a working ROM if the last chunk is not exactly 2K.

In my opinion, a 3F ROM that does not have a file size that is some multiple of 2K is broken.
 

[+stephena]

OK, so that's two people that consider Stella's behaviour correct, since the ROM is by definition broken.  So I won't change anything in Stella for now.

[+Andrew Davie]

Just now, stephena said:

OK, so that's two people that consider Stella's behaviour correct, since the ROM is by definition broken.  So I won't change anything in Stella for now.

Make it 3. I've been sleeping.

[Windless]

> So the problem is really, are non-power-of-two binaries legal for this scheme?

 

The problem I had (as a beginner VCS developer who has not really done assembly in the last 20-25 years) was not that stella failed at running the rom (I would be totally happy with an error message telling me "wrong rom size"), but more the weird behaviour : The code was loaded, the symbols where loaded, but the symbol <-> code was not the same in Stella (debugger) than it was in the .lst / .sym files. Quiet confusing

 

I totally agree this is not superimportant and that your time would certainly better be used otherwise. Otoh if you think it would be quick for you to add a warning in the (debugger ?) console when wrong size roms are loaded, that would probably help the next person who will do the same weird error I did

 

And while I'm there,  I'll take the opportunity to thank the stella team the wonderful work. I probably would not have spent two weeks coding for the VCS if great emulators didn't exist. You really made my life a little happier

 

windless.