Windless Posted January 9, 2020 Share Posted January 9, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 10, 2020 Share Posted January 10, 2020 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 10, 2020 Share Posted January 10, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
Windless Posted January 10, 2020 Author Share Posted January 10, 2020 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 Quote Link to comment Share on other sites More sharing options...
Windless Posted January 10, 2020 Author Share Posted January 10, 2020 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 ! Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 10, 2020 Share Posted January 10, 2020 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 2 Quote Link to comment Share on other sites More sharing options...
Windless Posted January 10, 2020 Author Share Posted January 10, 2020 @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 Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 10, 2020 Share Posted January 10, 2020 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+stephena Posted January 10, 2020 Share Posted January 10, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+stephena Posted January 10, 2020 Share Posted January 10, 2020 I will test on a Harmony later this evening, to see what happens there. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 10, 2020 Share Posted January 10, 2020 ROMs with wrong sizes fail on regular hardware too. Quote Link to comment Share on other sites More sharing options...
Kroko Posted January 10, 2020 Share Posted January 10, 2020 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 10, 2020 Share Posted January 10, 2020 @Kroko: Would such a ROM with 2 bytes missing in the end work on real hardware? With a Harmony cart they fail. Quote Link to comment Share on other sites More sharing options...
Kroko Posted January 10, 2020 Share Posted January 10, 2020 (edited) 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 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted January 10, 2020 Share Posted January 10, 2020 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. Quote Link to comment Share on other sites More sharing options...
Kroko Posted January 10, 2020 Share Posted January 10, 2020 $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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted January 10, 2020 Share Posted January 10, 2020 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. Quote Link to comment Share on other sites More sharing options...
+Andrew Davie Posted January 10, 2020 Share Posted January 10, 2020 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. Quote Link to comment Share on other sites More sharing options...
Windless Posted January 11, 2020 Author Share Posted January 11, 2020 > 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. 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.