drpeter

I think most people on the forum are using 8K solutions upwards, and using the GUI, so this may not be a good move...

Meanwhile, I plod along with my trusty 11-year-old Sony Vaio Duo 13 with i5-4200U CPU @ 1.60GHz, 2295 Mhz, 2 Cores, 4 Logical Processors. At ~10-20,000 solutions/second 😬 😄

Yeah. Although, comparing a still from the video showing ROM data with the emulated equivalent from Altirra clearly shows that the top line of each character displays correctly on a badline, followed by data from character $FF on every other line... So I think we have this nailed down.

No, I think @phaeron is right. The first line of a non-inverted 0 character (or in the case of Bruce Lee, a space character) is blank, so should display PF2- as it does in both these instances. Looking closely at both Bruce Lee and Boulderdash, the bad line appears to display the fetched graphics data for the correct character, but fetched graphics data for character number 255 for all subsequent lines. So I revise my diagnosis back to my original suggestion (and as @phaeron says)- memory cell 43 of the internal line buffer is persistently reading 255 regardless of the stored data.

Yeah, looking at it (as you probably saw already) it uses wide mode with columns of fully black characters down the right & left borders to conceal the DLI-implemented changes in background colour (which would otherwise show in the borders as horizontal grey stripes)

5 LLEN=80:MODE=4 10 SCR=PEEK(106)-16:SCRBAS=SCR*256:REM 4K BELOW RAMTOP 20 DL=SCR-1:DLBAS=DL*256 30 FOR F=0 TO 2:POKE DLBAS+F,112:NEXT F 40 POKE DLBAS+3,70:POKE DLBAS+4,0:POKE DLBAS+5,SCR 45 LBASLO=LLEN:LBASHI=SCR 48 FOR F=DLBAS+6 TO DLBAS+75 STEP 3 50 POKE F,112+MODE:POKE F+1,LBASLO:POKE F+2,LBASHI 55 LBASLO=LBASLO+LLEN:IF LBASLO<256 THEN 70 60 LBASLO=LBASLO-256:LBASHI=LBASHI+1 70 NEXT F 80 POKE DLBAS+75,80+MODE 90 POKE DLBAS+78,65:POKE DLBAS+79,0:POKE DLBAS+80,DL 100 POKE 560,0:POKE 561,DL 200 POKE 88,0:POKE 89,SCR 205 POKE 82,0 210 POSITION 0,0:PRINT "01234567890123456789" 220 FOR F=2 TO 16 STEP 2 230 POSITION 0,F:PRINT "*@+#0123456789012345678901234567890123456789#+@*" 240 NEXT F 300 FOR F=0 TO 15 301 VPOS=PEEK(54283) 302 IF VPOS>50 AND VPOS<100 THEN POKE 54276,F:GOTO 305 303 GOTO 301 305 GOSUB 400:NEXT F 310 FOR F=15 TO 0 STEP -1 311 VPOS=PEEK(54283) 312 IF VPOS>50 AND VPOS<100 THEN POKE 54276,F:GOTO 315 313 GOTO 311 315 GOSUB 400:NEXT F 320 GOTO 300 400 FOR G=0 TO 150:NEXT G:RETURN If you're still keen on experimenting, this code implements an exact copy of the BoulderDash display list in standard Atari Basic, then scrolls it...

UPDATE- looking again at BoulderDash, it seems that the 'glitched' displayed data is not always related to a '255' character misread but rather to the preceding or following character display data. So it does seem to be an issue with ANTIC's data fetch rather than storage in the buffer and I suspect it is caused by a 'rogue' memory refresh cycle occuring during screen data fetch when on these 'bad' mode lines the single memory refresh cycle should be delayed to the end of screen data fetching. (i.e. while this 'rogue' refresh memory cycle is happening, ANTIC ends up fetching persistent data from an undriven 'floating' bus relating to its most recent DMA access, rather than from the requested memory address)

What these games have in common is that ANTIC is fetching 48 bytes of character data per character mode line into ANTIC's internal buffer: in Bruce Lee because wide mode is activated, in BoulderDash because scrolling is activated (which causes 48 bytes of character data to be fetched even in standard screen width). I think this means that the character data for the 'glitched' column is sitting in the 43rd byte of that internal buffer, which is not used in standard-width, unscrolled ANTIC character modes 2-5, where only the first 40 bytes of the buffer will be filled. The character displayed appears to be the inverted 'right-pointing triangle', representing 255. So, when ANTIC fetches the character data to be stored in the 43rd byte of the internal buffer, either it is always getting 255 from the data bus (which happens when an 800XL 'pulled up' data bus is undriven, such as when refresh DMA is taking place, but in a stock 400 the data bus is left 'floating' during refresh DMA cycles so will usually just show persistence of the last data put on the bus by ANTIC or 6502 activity) or that byte is not stored properly in the buffer and always reads back as 255 whatever value was stored. So my conclusion is that either something is interfering with ANTIC's DMA at precisely this point of each wide-mode '40 character' mode line data fetch, or more likely there is a fault in storing/reading the 43rd byte of the internal ANTIC buffer. So, first thing to try is definitely reseat/swap out ANTIC.

This one I previously suggested to @ilmenit (link) seems worth looking at...

Printer emulation troubles... @ebiguy I have RespeQT 5.3 running in Windows 10 Pro hooked up via a USB port on COM7 using SIO2BT handshaking at 19200 bps and 10ms write delay When linking to an emulated 1025, 1027 or 1029, any printing, whether through LPRINT or an open "P:" device, causes an Error 138 in BASIC on the ATARI and RespeQT on my laptop to terminate. Anyone else seen this? Any idea what the problem could be? I've tried various handshaking and other settings, but none of it made any difference. The 32 bit & 64 bit versions behave the same. Disk emulation works fine. I should add that the printed text appears in the RespeQT printer window before the Error 138 happens and the RespeQT application exits.

That's odd. A Rastaconverter xex shouldn't be able to crash the host computer- only the emulated Atari. Can you post a screenshot of the crash? Have you had this issue with any other Rasta xex files? This sounds like an issue from whichever emulator you have running on Linux. It was Atari800 if I remember correctly? (Am I correct in thinking that it is the xex executable which is causing a crash when executed, not the Rastaconverter exe executable?)

Just to clarify for @Sheddy's peace of mind, there were no artifacts in the sense of things that Rasta thought should display differently due to errors in emulation- there were just areas in which, due to the limitations of the semi-random choices of the Rasta optimisation algorithm and the Atari hardware, a few simple hand-tweaks of the bitmap & kernel visibly improved things.

I've recently acquired a spare 48K 400, and also have an 800 if necessary that I could lend to the cause. Let me know if and when you might have the time to work on this, and we can arrange for them to come & live with you for a while...

Hello @Magic Knight, as a fellow UK resident, where do you source your Chinese boards from for under £5? Looking to make up some of these for a project I have in mind...

So it seems to me that for both the emulated 800 and 800XL, the virtual DMA cycle for playfield character data coinciding with a refresh cycle and therefore an undriven data bus results in fetching persistent data on the bus from the preceding character map DMA cycle- i.e. emulating a floating data bus

It seems to reflect the result of these character map DMA cycles:

This is my test code: 5 SCRBAS=PEEK(88)+PEEK(89)*256 10 DLBAS=PEEK(560)+PEEK(561)*256 20 POKE DLBAS+3,82 30 FOR F=DLBAS+6 TO DLBAS+28:POKE F,18:NEXT F 40 POKE 559,35 50 FOR F=0 TO 3999:POKE SCRBAS+3,(F/250)+16:POKE 54276,F/250:NEXT F

Hmm... in emulation the behaviour on bad lines is the same in both the 800 (floating undriven data bus) and 800XL (pulled up undriven data bus)? In both it reflects the screen code data of the first character beyond the extreme right display border- i.e. in horizontal blank

Ah yes, I hadn't tried character modes. I notice that on the 'bad lines' of IR mode 2, for example, when HSCROL is 2,3,6,7,10,11,14,15 the 'garbage' pixels don't represent 6502 use of the bus but are constant and seem to be something to do with ANTIC's final fetches of character data for that line. What's going on there? EDIT- ah- after some more experimentation I see that it's the screen code of the first character that is beyond the right margin of the display- presumably because ANTIC is continuing to load the internal buffer with these characters but not fetching display data for them

@phaeron While messing about with wide playfields recently, I noticed something I didn't expect: When horizontally scrolling a 48 byte wide playfield, the 4 bits of 'garbage' at the extreme right border that show up on extended overscan scroll out of view when HSCROL is 2,3,6,7,10,11,14, or 15. This gives a usable playfield width without 'garbage' of 178 rather than 176 color clocks. I've been unable to confirm this behaviour on real hardware because I have no monitor that will show extended overscan. Is this correct? I ask in particular because there's been discussion recently of making use of these 2 'garbage' color clocks in static images by ensuring predictable data on the bus at the critical moment, using DLI or screen kernel techniques. Just scrolling the relevant mode lines 10 color clocks (10 rather than 6 or 2 so as to to minimise 6502 cycles 'stolen' by DMA) would seem a very much simpler means to the same end...

(for some reason double-posted!)

Another stunner! A question- although it seems to be for a PAL palette, the proportions of this image and many of your other recent ones seem slightly vertically flattened- see for example the very obviously elliptical moon in this one- and the proportions look more 'normal' on an NTSC display where the almost square but very slightly vertically flattened PAL pixels are instead noticeably vertically stretched. Is this because of the kit you are displaying images on? Or is it a deliberate compositional thing to vertically squeeze images into 240 vertical pixels?

The way to do this is in pre-processing: produce two (or more) output.png-dst.png images with different types of (or no) dithering then combine the output.png-dst.png images into a single input image with the right kind of dithering in the places you want them and finally run Rasta with that as input and no dithering or other tweaks. I did this in my recent Stonehenge image: the sky below the clouds has knoll dithering strength 3 and the clouds and foreground low strength jarvis dithering.

OK, thanks. That confirms that there are no player repositioning artifacts in that image- there are no discrepancies between output.png and the displayed xex, also Rasta Slide detects no potential player positioning artifacts. So that's a pass for @Sheddy's new Rasta version.

I think this relates to use of the wide playfield setting, which Rasta doesn't currently use (it uses standard width playfield). The black quadruple-width missiles at the left and right borders of Rasta images are used currently to mask stripes created by changes to the background colour (which displays in these borders) not the 'garbage pattern' 'Virtual playfield DMA' ANTIC/GTIA glitch seen at the extreme right of wide playfields. Rasta could in theory be reprogrammed to use a wide playfield, but it would reduce the CPU cycles available for enhancing the image through register updates because of increased ANTIC 'cycle stealing' for playfield graphic DMA memory access. A wide playfield in the usual Rasta resolution would display 176 pixels (160, plus 4 extra pixels to the left and 12 extra pixels to the right) plus 2 pixels of 'garbage' at the extreme right border of the image (seen only on real hardware coupled to displays capable of fully showing these extreme widths, or on emulators programmed to display them- currently I believe only Altirra with certain display options set). It would also in theory be possible to furthermore program Rasta to use the 2 'garbage' pixels at the extreme right border of each image, using a technique similar to but slightly different from that described for the Death Of The Right Side Garbage demo- as described in detail here- but this would eat up further CPU cycles, so again the result would be a marginally wider image (178 pixels vs 176 pixels) but at the cost of some degradation of the quality of the rest of the image. So, yes, these things are possible but I doubt anyone is going to implement them as options to Rasta any time soon, as unfortunately those with the requisite skills have repeatedly said they don't have sufficient time or interest to invest in making further improvements to the app.