Kylearan

Very nice set of bankswitching macros, thanks for posting those! Very easy to use. One problem, though: While JSB works, JMB doesn't because of a typo in the file "ARPM_Bankswitch.h" on line 376: ldx #[>[.{1}-1]]>>5 ; Calculate the target bank. Just remove the "." to make it work. Here's the correct line: ldx #[>[{1}-1]]>>5 ; Calculate the target bank.

For the sake of completeness, while digging around in this forum I found this set of bankswitching macros, by Robert M: http://atariage.com/forums/topic/180561-atari-rapid-programming-modules/ It's not optimal speed- or sizewise, but it's *very* easy to use, provides nice source readability and has some nice compile-time convenience macros for debugging. As long as I won't need to optimize my code for every byte to spare (unlikely when you do bank-switching in the first place), I go with this.

Thomas, SeaGtGruff, thanks! Good that I asked before writing my kernel; too bad it won't work on real hardware. Robert, I know that table, but thanks anyway. My question was about multiple HMOVEs on a single scanline, which works under Stella but apparently not with the Real Thing.

Hi, right now I'm looking into ways of repositioning an object for the next scanline more than the standard -7/+8 pixels, without having a blank scanline inbetween (i.e., without having to do a full RESx, WSYNC, HMOVE). So I thought about what happens if I do sta HMOVE repeatedly after WSYNC, and sure enough, in Stella I can move P0 21 pixels to the right with $e0 in HMP0 and 3 consecutive sta HMOVEs, for example. Searching this forum I couldn't find anything about this topic even though it looks quite useful in certain cases, and reading the TIA hardware notes left me more confused than enlightened on the topic of how HMOVE works exactly. Now the problem is that my Harmony cartridge hasn't arrived yet so I cannot test this on real hardware, so here's my question to more experienced people than I am: 1) Do multiple HMOVEs per scanline work on real hardware? 2) If yes, are there any known limits or problems with this? One thing I know I'd have to keep in mind is that repeated sta HMOVEs would happen on later cycles than usual, thus the movement would be different (according to that table about how HMOVE on different cycles behaves). But what I don't know yet is if I can simply add up the movement values, or if there are any limits or unexpected behaviors. And before I write a systematic testing kernel, I thought I'd better ask if this works on real hardware first. Thanks, -Kylearan

"Real" or "professional" programmers, the most important thing is that the code they produce is maintainable and good for others to read, understand, extend and modify - regardless of what language is used or how quickly the code is produced. That's something many people who consider themselves "good" programmers miss, and it's a PITA when they switch jobs, the project grows, or they stop working on the project and others want/have to take over. And yes, needless use of polymorphism just for the sake of it, excessive testing beyond what's really necessary, or "clever hacks" are annoying in that regard, too. There's a lot of ideology flying around in that area (language, tools, methods like SCRUM... *rolleyes*)...

I'm developing a demo and use Notepad++ for editing, a shell (and a make.bat) and dasm for assembling, and Stella for testing. For debugging, I prefer a long hard look at the code and doing some small changes to weed out the cause of a bug, instead of using Stella's debugger. I use that for reversing other people's programs, though. I also use some quick python scripts to help me generate some code snippets, like unrolled loops. I find this setup to be more than good and fast enough for 6507 assembly coding, with no need for a full-blown IDE. The challenges when coding for the VCS, like speed- and size-coding, counting cycles, the limited RAM etc. are nothing an IDE could help me with much. I have heard of JAC!'s WUSDN IDE and had planned to take a look at it someday, but until now don't see the need (yet). I *could* envision an IDE that would be helpful, like automated mapping from instructions to scanline cycle numbers in the source and a corresponding visual editor, and maybe I'll develop something like this someday. But until now, that's a luxury I don't really need yet. Happy new year!

Oh, I see. I guess I hadn't spotted this as the displacement didn't happen with the standard HMOVE, but only because the timing was then slightly different and the displacement wasn't really related to the HMOVE . Ah, okay! I didn't realize that. I'll also have a look at your source. Thanks a lot!

Sorry for not posting screenshots and code. Somehow I thought this might be a known limitation with late HMOVEs, but maybe it's not - or, more probably, it's a mistake I made, so I'd appreciate some help. Here's the relevant code: sta HMCLR ; just to be sure... ; position vertical lines (M0) without enabling them yet sta WSYNC SLEEP 26 sta RESM0 lda #$30 sta HMM0 SLEEP 37 ; sta WSYNC sta HMOVE lda #%0000011 ; Three copies close sta NUSIZ0 ; show horizontal lines (P0) sta WSYNC lda #%11111111 sta GRP0 SLEEP 20 sta RESP0 ; Disable P0 and enable M0 on next scanlines sta WSYNC lda #0 sta GRP0 lda #%00000010 sta ENAM0 This is what it looks like (the grey borders to the left and right in the screenshot are the window decorations from Stella): Notice the odd spacing between the horizontal lines (P0). If I comment out the SLEEP 37 in line 9 and comment in the sta WSYNC in line 10, it looks like this: This is how I had expected the first version to look like, minus the black comb bar. (This is Stella 3.8.1 by the way; unfortunately I won't have my Harmony cartridge before next year, so cannot test on real hardware.) So now I'm confused: I manipulate HMM0 with a sta HMOVE on cycle 71/74, and the display of P0 gets changed in an odd way...? What am I missing here?

Hi, I have some problems with strobing HMOVE on cycle 71 (so it completes on cycle 74, avoiding the black bars). When I use this on M0 set to three copies close, only the first copy gets moved; the other two are not moved (or moved differently, which is hard to tell). Am I doing something wrong here, or is it just not possible to move all copies? Somewhat related (noobish) question: Regarding RESM0, HMM0, ENAM0 (or RESP0, HMP0, GRP0 etc.), is there a specific order in which to set those up, or is the order irrelevant for the exact position in the end? Thanks in advance, -Kylearan

Oooh, looking forward to this! If by any chance this happens to be at Revision, expect some competition. (Which would be entirely your own "fault", as your talk at this year's Revision prompted me to start coding a demo for the VCS. ) Anyway, thanks to all for showing the different ways of doing bank switching; I'll borrow some ideas when it comes to linking my demo...