Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

5 Neutral

About Windless

  • Rank
    Star Raider

Recent Profile Visitors

545 profile views
  1. Thank you. I didn't manage to install stella from the provided packages on my debian 10 earlier, so I installed the older version from Snap store. You convinced me to give it another try and I finally managed to compile it from sources, and I feel better and will update my code thanks to your posts
  2. >On most consoles those bits usually keep the last value they were driven with, and that's what Stella emulates if the "Drive unused TIA pins.." option is disabled. How, thank you, this is exactly what I was looking for. Is it a completely unreliable behaviour, or will it be true most of the time on most 2600 ? (e.g. if I use this value in a game on every line, will I get a random glitch every 10 minutes or will it probably behave randomly several times on each frame ?
  3. Ok, the way I was testing in stella was wrong (I re-ran the same code by manually mloving the PC to my manually assembled code). I made a test rom hoping someone could run it on real hardware, but the behaviour is different : In stella, bits 5 to 1 seems to be random, and bit 0 is always 1. (7 and 6 should be from CXM1P). And yes, I know I should not be trusting this, otoh I should not be doing 6502 assembly and be looking for a serious paid job as a Rust developer, but you know... Maybe I should try understanding the schematic of the TIA to be (more) sure.
  4. Hi, TIA($01) is both the read address for CXM1P (only D6 and D7 used) and the write address for VBLANK. But what happens to other bits when we read CXM1P ? In Stella, even if we check "developer -> Drive unused TIA pins randomly on read/peek", it seems we always read %xx000001 whatever has been written to TIA($01) before. Is that true on a real hardware, or would we read random value ? The values from the bits of VBLANK at least for bit 1 ? something else ? Thanks, Windless.
  5. Thanks Good point, I need to improve this. I do need to either put some real code (and explain it) or just remove it and comment "put some code here"
  6. You don't need to emulate the TIA. You can also intercept the write to COLxx registers and inject fake colors. This way you can : -Know which object need to be displayed in which color -Know which object is currently displayed (by reading just the LUMx pins since you injected fake colors - they are way easyer to read than the COLOR signal) This can (almost) be done with a ROM and a few logic gates and buffers.
  7. Hi, I started using bank switching (for some precalculated self-modifying code - don't judge me) and though the principle is really simple (put the proper address on the address bus and voila), trying to do everything from scratch with just this information did not work first try for me. After I managed to make it work, I of course found that all the information was already available on this forum, but you needed to find and read the proper thread to pick what you needed. I then started to write a synthetic introduction... which (though still unfinished) is no longer synthetic at all but contains all the information I wished I had in the order I think it would have been the easier for me to learn them. Maybe it could be of some interest to someone else. https://gitlab.com/FTregan/bank-switching-rom-atari-2600/-/blob/master/README.md
  8. Thanks. For now, since each call to my macro will generate the same "local global" labels, I did like this : MAC GENCODE .genStart SET . nop nop _label1 SET . - .genStart lda #1 nop _label2 SET . - .genStart lda #2 nop ENDM then I use the relative labels this way : generated1 GENCODE generated2 GENCODE jmp generated1 + _label1 jmp generated1 + _label2 jmp generated2 + _label1 jmp generated2 + _label2 This works because relative labels have the same value each time in my macro. Else I would need to use absolute values and capture each one : GENCODE label1_1 set _label1 label2_1 set _label2 GENCODE label1_2 set _label1 label2_2 set _label2 But that still doesn't allow for a varying number of generated labels.
  9. hi, I am generating some code with a macro, and I would like this macro to generated global unique labels. e.g., when called twice, the macro would output : MyMacroLabel1_1 lda #$00 MyMacroLabel2_1 ldx #$00 MyMacroLabel3_1 ldy #$00 MyMacroLabel1_2 lda #$00 MyMacroLabel2_2 ldx #$00 MyMacroLabel3_2 ldy #$00 Is it possible to do so with DASM ? I thought I would use something like : IFNCONST CallIndex CallIndex set 0 ELSE CallIndex set CallIndex + 1 ENDIF ["MyMacroLabel1_" + CallIndex] lda #$00 But after one hour of trying, I didn't manage to have this working.
  10. > 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.
  11. @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
  12. 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 !
  13. 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
  14. 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.
  15. Hi, I am trying to make my first real software for the 2600. My kernel currently behave slightly differently on different emulators, and I don't yet have hardware to test it. If someone has the tool and time to test it on some real 2600*, that would help me Thanks, Windless. (I do not attach the rom since I do not want to make it public yet, I'll DM it )
  • Create New...