Jump to content

Windless

New Members
  • Content Count

    64
  • Joined

  • Last visited

Community Reputation

5 Neutral

About Windless

  • Rank
    Star Raider

Recent Profile Visitors

430 profile views
  1. 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"
  2. 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.
  3. 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
  4. 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.
  5. 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.
  6. > 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.
  7. @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
  8. 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 !
  9. 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
  10. 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.
  11. 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 )
  12. Hi, according to 8bitworkshop and stella, the VBLANK bit if set to 1/0 affects the cathod ray 1 TIA Cycle avec it's commited on the bus by the CPU. Is this documented somewhere ? I couldn't find reference to this in the documentations I have. Thanks, Windless. Test code : ldx #64 ScanLoop sta WSYNC SLEEP 20 lda #$aa sta COLUBK lda #$34 sta COLUBK lda #$aa sta COLUBK sta WSYNC SLEEP 20 lda #$aa sta COLUBK lda #%00000010 sta VBLANK lda #%00000000 sta VBLANK sta WSYNC dex bne ScanLoop Result : https://8bitworkshop.com/v3.5.0/embed.html?p=vcs&r=TFpHAAAQAAAAAJFODB%2FcAQMEBQZ42KIAiqjKmkjQ%2B6kChQEGYQCFAgYiqQCFAKIlhQLKBREAhQGiQIUC6gYHqaqFCak0BmEG4QQPEAV%2FBSoFc8sFRaIeBb5MC%2FD%2FBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GHwYfBh8GDADwAPA%3D
  13. ho,ok. This would be testable with a fast oscilloscope. I'll try with mine (maybe pushing it a bit) when I'm done with the schematic and I can resolderparts andtry to feedthe TIA with a PAL-I signal
  14. Do we have schematic of the PAL TIA ? I couldn't find one so I'm trying to random guess lot of things . Ok I am not sure I understand. My hypothesis was that the color register (left part of sheet 5) contains the same value, but that the bit are XORed before being used to selected the Color Phase Shift Delay cell on odd lines. From what you tell, I think (and it's very likely since it would be simpler and would work) that they probably just delay or NOT the color burst and leave the COL signal the same. But I don't understand how that would explain the need to remove 3 lines of colors nor to loose the possibility to have a 0° color ? On the other hand, some sources say the phase is reversed on odd/even lines, but some indicate (as you do) that they are 90° rotated. With 90° rotation, I can't explain the organisation of the PAL palette.
  15. Something else just came to mind: If the delay is the same on PAL tia as it is on NTSC, then color adjustement potentiometer would only increase delay between the cells of the color phase shift delay. So instead of having e.g. 0°, 15°, 30°, ... for colors $1x, $2x, $3x, ... you could get 0°, 16°, 32°, ... This would work on NTSC, but on PAL if what I guess about the XORing on odd line is true, that means that if you add by adding 1° per cell, colors $Ex would get 13° shift when $1x would only get 1°, which means that the phase shift between them would go from 180° to 193°. Maybe the delay pot works differently (e.g. adjust only the first color) and this has some impact on the possibility to display 0° colors, hence leading to suppression of color $1x and $Ex ? Anyway, this would be a good way to test if the colors are indeed XORed on even lines : either the col adj pot adds the same delay on all cells (and that would partially confirm the hypothesis), or it works as on the NTSW TIA and then adjustment of colors would not be the same for ODD and EVEN lines.
×
×
  • Create New...