Rybags

I did a search but there's not much info around - supposely maybe 5 applications of this faster clock speed. In theory, like the C128 you might be able to use Raster IRQs to implement the speedup during the 112 non display scanlines. That is assuming it doesn't screw with the overall display timing.

I'm fairly sure Atari never used Ram over 250 ns. It just wouldn't work. 250 ns equates to half of a 2 MHz cycle, so gives a little leeway for our 1.79 MHz systems. "Make use of" isn't really relevant. Whether a given cycle is granting memory access to the CPU or for DMA, the timing requirements are still the same. We don't have wait states like PCs where we're waiting for long latency memory operations, any given memory access is always done in a single cycle. Plus/4 is a mid 80s machine so chances are it was using 150 ns chips or better. Though just like our 90 ns chips in the XE, it makes no difference, so long as it works it doesn't make the machine any faster or slower. The 2.2 Mhz thing - seems strange to me though it is about a 4:5 ratio over the 1.78 Mhz base clock - and our Atari and the Plus/4 has a 4:5 ratio of the CPU vs half the colourburst cycle.

The "2 MHz Ram of the BBC" - somewhat irrelevant. RAM doesn't really have a speed, it's got access time which in the case of most 8-bit computers will have plenty of headroom below what's needed, e.g. 250 ns was the original spec but most XEs will have DRams that are under 150 and as low as 90. The BBC has an advantage in that it's actually running at full speed all the time (from what I could deduce using one) - so in fact it's likely the Ram is probably clocked even higher.

I've got a real machine, so will have to get it out and see for myself.

I'm fairly sure that doesn't happen - the screen blanking just prevents the cycles lost for screen generation in the same fashion as setting DMACTL to 00 on the Atari - the PAL/NTSC setting would just toggle between 312/262 scanlines at ~ 50 & ~ 60 FPS. There's no valid reason for the CPU to overclock to that speed (though it does seem somewhat close to half the PAL colour clocking rate)

Refresh on C64 AFAIK never steals cycles. Many accesses on the C64 are transparent since the CPU runs at half the relative speed of the video generation compared to the Atari. You can alter the refresh cycle generation on the Atari but at the cost of losing most of the cycles to the character and map fetches. With programing tricks you can make 240 badlines which disables the bulk of the refresh cycles in a frame.

I forgot the ribbon cable at the time... I have one also, which is still yet to be used. Extra bit colours - yes, you have to store them yourself to the shadow registers - a DLI at top of screen would be the best method. IMO sort of pointless doing a modded OS - you could then have the situation of the extra colour working for you but not others. Plus it's not a straightforward byte change - the $FE value is used twice, also as the counter/flag value when attract mode becomes active. An $FF value wouldn't work there as the counter incrementing back to $00 would disable the attract mode.

The refresh rate I would think should be the same on both computers. Some computers use 263/313 scanlines NTSC/PAL but both Atari and Plus 4 should use 262/312, so assuming the CPU clocks are identical the refresh rate should also be. Re the inexactness - in both cases it's not a reliable source of timing to assume 50 or 60 FPS but in a comparitive situation between the 2 computers any deviation due to the slightly lower actual rate should be the same.

The actual frequency fed to the CPU I'm fairly sure should be identical in both cases for one machine compared to the other for both PAL and NTSC. Back to the differences, I'm not sure what the Plus 4 does for refresh on badlines, whether it is still 5 cycles or not. The Atari has just 1 cycle on the badlines and 9 on the remaining ones. And 32 cycles lost to DList fetches. Doing the calculations (assuming Plus 4 does 5 refreshes always per line) PAL Atari = 2616 refresh + 32 DList + 960 character cells + 7680 character set fetches for a TOTAL 11,288 cycles lost per frame PAL Plus4 = 1560 refresh + 1000 character cells + 1000 attributes + 8000 character set fetches for a TOTAL 11,560 cycles lost per frame. So, Atari slightly faster. If the Plus 4 does only one refresh on badlines that would return 200 cycles which would make it slightly faster. I think if you're benchmarking and seeing the Atari as slower then it might come down to VBlank overhead. Possibly a better way could be to devise some bit of work in 6502 Asm which takes about a minute. Run on both machines with interrupts disabled and time them by hand.

The Atari should be faster. It has less refresh cycles - usually 5 per scanline vs our 9, but it has 2 badlines in succession since there's attribute fetches as well as character cell and bitmap data. So the net effect is that Atari has DList and more refresh lost cycles but overall that is less than the extra 25x40 badline cycles of the Plus 4. Though all this doesn't take the VBlank overhead into consideration. Likely that Atari's VBlank code path is somewhat longer than the Plus 4 timer IRQ which would swing things the other way a bit.

With deferred mode - the actual swap will be a frame behind since the VBD vector is called after the DList pointer and other shadow registers are copied. Also, you have the real risk of missing interrupts since VBD is skipped if IRQs are masked - which is a common thing when there's keyboard activity.

I'll get an independent PF1/PF2 colour pic next time if nobody else has put one up first. Re the 8-bit palette mode, it's more than just enabling by the bitsetting since the OS VBlank routine zeroes out the low bit when copying from the shadow registers. So, you need to have a VBlank, DLI or other routine that copies them without doing that.

tep392 produced the Pac-Man arcade modified version, I imagine he'd have plenty of reverse-engineering information.

I can't think of any to add, not that I've extensively browsed through the code on lots of games looking for such. Sort of strange given the typical high memory catered for was 48K and only SD disks for virtually all commercial releases which makes it seem a logical method to get more content in. Not sure if C64 fared any better though it was fairly common practice for cracked games and I think some of the snapshot cartridges like Isepick and Freeze Frame could do it also (probably just RLE though)

I learned Basic on a woeful thing called the Compucolor II which my school had but was onto the Atari around the same time. Intermediate Basic then 6502 Assembler pretty much all on the Atari, though I also started doing stuff on the C64 probably in late 1982/early 1983. My first ever fulltime job was working on the C64 which required reasonably advanced Basic + some Asm so it helped out for that. Around 1988 I got an ST and had 68000 programming down in about a week - as it turned out that was handy as I was learning IBM System 370 Assembler about 1.5 years later. Another helpful element in the earlier days from Atari is the fact that the OS has it's elements formally structured (device handlers etc) which was rare among 8-bit computers - most others just had the OS slapped together and usually tightly integrated with the Basic Rom.

The fruit in Pacman would be characters (2 ajoining?) - from the 8K Rom version at least it seems the game uses a character set based at $3000 probably due to elements being animated/modified dynamically. I would say the fruit is probably copied into the character definitions per level since there's a fair variety and you never get more than 1 type on a level. So it could live anywhere within the Rom space and not necessarily based on an 8 byte alignment. To find it, probably just a tool or program to be able to explore the Rom as if it was a bunch of character sets would be sufficient.

VBXE output is (almost) completely seperate from Sophia or any other alternate video out for that matter. VBXE emulates GTIA - though the GTIA is retained as VBXE only renders video, doesn't do stuff like read buttons or PM collision detection. I'm sort of unsure about the video above PBI there - it then limits your options a lot, ie the likes of IDE +2 or Ram 320XL. I'm thinking about just running it off the left hand side of my 600XL. Aside from 64K Ram inside it's got no other upgrades but I want to take as little space as possible to allow other thing to live inside.

Tried the crappy Viewsonic 4:3 gigantor thing and it works. Though not very good colour representation (it's an old & tired monitor).

Likely it didn't much like the generated DVI resolution. I tried some others and just got blank where the other monitor showed them fine. Tried another monitor - Asus VW161D - a VGA only input thing I bought years ago and have barely ever used. Annoyingly it comes up with "Out of range", so no good there. I've got another monitor I was going to throw out because it no longer works on DVI - might try it on VGA and if it works OK it might get a reprieve.

Just tried the VGA on the Acer (correction the model name is S221HQL) - the quality isn't far short of the DVI output and no dot artifacts. And... tried 1280x1024 as the DVI mode which is also fine.

First startup in my PAL 600XL tonight. I removed the RF shielding and the first try was through RF. Picture quality worse than stock though I suspect lack of shielding would have been a big contributor there. Went out and only got back a short while ago so only just tried it on 2 LCD PC monitors. Glad to say it works on both out of the box - just had to set both to detect the aspect ratio. Though on the Acer monitor I'm getting red dots that show up on any line that's got text on it. Next up might try the software to alter settings. And I've got a few more monitors I can try it on. So far positive result on my Benq 22" GW2265 and an old Acer 21.5" S221MQL - I've also got my main Benq 24" GL2450 but I've ran PAL HDMI devices through it before just fine so I think it can be safely assumed Sophia would be OK on it. Pics attached showing output from the smaller Benq and the dot artifacts on the Acer.

Generally you'd just convert it to an Xex. In the modern day, ATR for a single game that doesn't do subsequent disk access can be pretty wasteful. In the day there were loaders around that could handle single stage tape files that were copied to disk file without any manipulation. Of course though, a lot of games boot to a very low memory location which means they will usually overwrite a Dos and often overwrite a loader.

I got busy with some TV and other stuff, with luck I might get time tomorrow night.

Mine arrived earlier in the week. I'm thinking it's ultimate home might be in my 600XL with internal 64K + 320XL plugin. I just dummy fitted it to a spare 800XL board - I assume plenty of people are just using the factory cheap socket? It seemed to stay in there OK.

No. RAMTOP is set by the OS to be the first non RAM page, then the screen will open immediately below it. MEMTOP (2E5, 2E6) is maintained by the OS and will point to the address just below the Display List which should be the top of free RAM. MEMLO is also wrong, it's the first free location once the OS has started then updated if a Dos or handler reserving memory is booted. APPMHI (E,F) is maintained by language processors as the highest location in use (+1) - the OS refers to it when opening a screen to ensure memory corruption doesn't occur. So, to deduce free RAM you'd subtract the value held in APPMHI from that in MEMTOP.