JAC!

Two videos in a video - great :-)

Are you doing this on Atari itself (only) or in some cross dev environment? In the latter case thismight be interesting for you, once I've finished it.

#13 means read & write with read from screen. It causes the handler to not wait for "RETURN" to read a line. It can be use to autorun basic programs for example also. You print 'RUN "D:PETER.BAS", put the curso above the text and type. OPEN #16,13,0,"E:" From OS: ; AUX1 EQUATES ; () INDICATES WHICH DEVICES USE BIT APPEND = $1 ;OPEN FOR WRITE APPEND (D), OR SCREEN READ (E) DIRECT = $2 ;OPEN FOR DIRECTORY ACCESS (D) OPNIN = $4 ;OPEN FOR INPUT (ALL DEVICES) OPNOT = $8 ;OPEN FOR OUTPUT (ALL DEVICES) OPNINO = OPNIN+OPNOT ;OPEN FOR INPUT AND OUTPUT (ALL DEVICES) MXDMOD = $10 ;OPEN FOR MIXED MODE (E,S) INSCLR = $20 ;OPEN WITHOUT CLEARING SCREEN (E,S)

First: ICSTA = $343 not $342 Second: Yes you are right. The command $0d = ICSTAT = GET STATUS is something different. The equivalent of STATUS #1,A is ldx #$10 ; Channel 1 lda #ICSTAT ;$0d jsr ciov bmi error lda ICSTA,x ;$343 a=Status of the device error: y=Error code of the CIO operation This is what CIO defines or all devices. But all device drivers, like R:, may of course extend the list of supported commands and parameters. For specifically for R:, I don't now more..

Hi, Every CIO call returns the status in the Y register. Also LDA ICSTA,X ($342,x) should contain the value for x=$00/$10/$20...

Have you tried to save as "G2F"? You will get a "myname.scr" containing the screen/char map.

Just a thought: You could simply the common parts in include files and use ICL. Simple replacement for "#define" if you like.

Hi, just a short teaser When I coded Silly Things, I really had some trouble with converting images and graphics to various Atari formats. Now I found the time to clean up all my hacks and after many years I see a solution at the horizion. I have extended the Graphics Editor in the following ways: - The easy part: The converter from (Atari) file to image now supports almost everything that is also supported by Fail (incl. HIP, APAC, ...) with good heuristics to guess the file type - the ard part: The converter from PC Image to (Atari) files has come to life finally. I have included the Rhino JavaScript engine and it is great. No need to install the Java SDK, no need for compiling - just edit and run. Now you can simply write a few lines for the conversion as part of the conversion file. You can create up to 10 different Atari files from the image. You can use loop in the code to arrange the bytes in the files just as you like. Here's the sample for converting a PC picture to a Graphics 8 picture. The image size is taken 1:1 in this case. function convertToFileData(data) { var bpsl = (data.getImageDataWidth() + 7) / 8; var bytes = [] var offset = 0; for (var y = 0; y < data.getImageDataHeight(); y++) { for (var x = 0; x < data.getImageDataWidth(); x = x + { var b = 0; for (var p = 0; p < 8; p++) { var color; color = data.getPixel(x + p, y); if (color != 0) { b = b | 1 << 7 - p; } } bytes[offset++] = b; } } data.setTargetFileObject(0, bytes); }

Excellent work Richard: for i=1 to 1E6: ? "" : next i

... I also guess so. When saving as XEX, G2F creates an assembler file, compiles and save only th result. If you PM me the XEX I'll be able to rip-back the bitmap, screen and PM data. PM positioning and so on will probably be lost as it is spread all over the (unrolled) code.

>But then it gets a bit messy, and you might end up with something that's not reentrant. I have used a lot of self-modifying code together with the MADS approach listed above. For the caller it still looks the same, but "copy.source" is suddenly no variable but a label in the routine. And as mentioned before: In normal cases your code does not have to be reentrant. And as long as you don't save also all used ZP locations to the stack, you have to be carefuly anyway which part of the code is executed in interrupts and so on. .macro copy_memory mwa #:1 copy.source_adr mwa #:2 copy.destination_adr mva #<:3 copy.bytes mva #>:3 copy.pages jsr copy.copy_memory .endm .local copy copy_memory ldx #0 stx bytes_count ldy #$00 pages = *-1 beq no_pages jsr copy_loop no_pages lda #$00 bytes = *-1 beq no_bytes sta bytes_count ldy #1 copy_loop lda $ffff,x source_adr = *-2 sta $ffff,x destination_adr = *-2 inx cpx #$00 bytes_count = *-1 bne copy_loop inc source_adr+1 inc destination_adr+1 dey bne copy_loop no_bytes rts .endl

Up to 3 parameter I use A/X/Y registers. The the smallest and fasted way. For more complex stuff is pass the parameter via MOVE into the local variables defined in a procedure (MADS). This is very readable and creates no overhead. MADS even optimizes the MOVE statements where possible. .proc copy .var start .word .var target .word .var length .word real code... rts .endp mwa #$1234 copy.source mwa #$4567 copy.target mwa #$91 copy.length jsr copy Note that MADS automatically places the bytes for the variables after the "RTS" and that you can use local names which a globally visible. That makes it very handy. For the cases which ware user very often in a program (like "WAIT 50") I normally define macros for the call. They hide which is actually done inside. If you really (and I cannot remember if I ever had such a case) have recursive calls, MADS also offers full support for that via it's software stack for procedure parameters.

Yeah, I always liked that one. Double E in BEWESOFT makes it possible, and it's even at the right location - you dont have to update the GRAFPx register So this actually shows 3 repositionings and 2 updated players "only".

Yesterday I decided that my next demo release will contain BOOBS and today I find this thread... Are you guys hacking my laptop?!

I use MADS together with my WUDSN IDE. Works very well and MADS is compatible with many other assermbers.

Hi Doc, Just don't let some forum trolls annoy you. There will always be some who give statements like that ("Europe is better than USA" or "Atari is better then C64" just to stare endless and useless discussions). I'm the 8-bit scene for more than 20 years now with contacts all over the global an across all systems and I can tell you: 99% of all people are friendly and "normal" - You can safely ignore the trolls (which is also the only way to make them quiet). Cheers, Peter/JAC!

Now I see how bad my example was. Hawkeye on C64 has very nice backgrounds for the parallax. See .

So your are looking for "useful" code in a demo . For game maps with good parallax scrolling, copying the map is required (combined with 4 preshifted charsets). Like this one. But the way of moving by charcopy preshift and offset is also very good for large soft sprites in char mode. I used is several times (unreleased stuff, like always when I start coding games).

I took all remaining pills and here is the result: Single executable for both PAL and NTSC, full framerate. And as special gift: Additional scrolling of the foreground controlled by the joystick in port 1 Please test on real hardware. MADS source included. atallax-jac.zip

I now have a working version which has about 80% free CPU per frame (rainbow effect while waiting for VCOUNT). Before I upload it, I have to restore the animation sequence (first no parallax...). So it is time bed again. It'll take the next pill when I'm back from office.

My thoughts: The NMI line of the CPU is falling edge triggered. The NMISTA bits are NANDED together. If the NAND results in a constant 0, for example because one of the bits is not reset/still set when another is set, no edge will occur. Strobing NMIRES resets all bits in NMISTA so the next NMI will cause a falling edge again. I'll try to verify this when I have access to my real machine again. The original version is a pretty small reproducible test case.

I was quite surprised by the implementation which copies the screen with masking. My expectation was that there are 2 (forground + backgrpound) x8 shifted charsets and you copy the proper charset data into the actual charset. It would come at the cost copying 2x 512 bytes with simple loops an would have been easy to unroll/optimize. So now I hope somebody with NTSC can confirm that it actually runs

... and so I took the red pill to find the answers I was seeking. Now I'm a "serious computer expert" . I checked for 5 minutes, added a single line and now it works on real hardware. That's what I did yesterday, really. And before you think "Why is he posting such rubbish", I should tell you what I means to be a "serious computer expert". It simply means that you are the one whose software is always failing first. So you are always to the first loser to go mad about a bug (or feature). Four weeks ago, I was in EXACTLY the same situation as MaPa with my Silly Splitter. I had VBI and 5 DLIs. Everything was fine in all EMUs but completely mixed up on the real iron. I took me 4 days to find the solution and I still can hardly believe it. For more than 21 years, my NMI routine worked fine, but it seemed as if Atari hardware changed in 2011. To make a long story short: If you do not strobe NMIRES during VBI, the NMIs may drop out sometimes. vbi bit $d40f bmi dli sta $d40f ; Add this if you want cool effects in 2010 pha This is all that is required to make the PAL version run. If you look at the OS ROM NMI routine, you'll see that the Atari people knew well about this. The speed up for NTSC was more difficult, but finally it runs - at least in the emulator. I did not adjust the speed of the music, because it really sounds nice at 60HZ. But since this thread is just about "emulators are not the real hardware", somebody please test it. The two fixed versions (now also including detection of correct GTIA to prevent mixing up) and source is attached here. The source is in MADS format because I was not sure about ".rept" in XASM. atallax-jac.zip

Hi, I got it fixed. I'll check also for the NTSC timing and post it tomorrow. First I have to get some sleep, sorry.