Wrathchild

No, the 2 lumas cover the background and foreground. You have a separate border. Using Player/Missiles you can decorate the text area as you'll see in titles such as Manic Miner

Leaderboard - assuming the island doesn't have its own course! (and will try and not lose the dongle! This just pips Hardball) International Karake (or the plus version) - avoid thoughts of hunger by listening to a crunching stomach punch 😟 Dropzone - "To not include one title, Mr. Maclean, may be regarded as a misfortune; to not include both looks like carelessness." Rainbow Walker - will always remain a "go-back-to" game Rescue on Fractalus! - still tops Koronis Rift or The Eidolon for me Alley Cat - "Love them mousies" Ballblazer - tough choice but pips Encounter! due to the fantastic music Telengard - can have an occasional giggle at the artwork in the manual (plus I can print this in A4 and call it "Wilson") Book - Mapping The Atari (with an up to date Addendum) Assuming base machine is a RAM expanded 600XL with ROM based would have the Basic ROM swapped with Phaeron's, the Luxury Item would be the MyIDE-II cart blown with onboard SDX + OSS ROMS, specifically MAC/65 for working on my WIP sources that would be stored on a CF card to do the development upon Who knows... if any rescue is delayed I might even have finished Elite!

That's a Z4 title available not on the A8? Will work on my list...

@electrotrains should be able to confirm, but if you followed the Excel article then I should think you are able to design your own PCB layout based on the connections from the breakout board? [Edit] and in doing so there could be potential for adding a second button which @flashjazzcat could take advantage of, e.g. for disk rotation. [Edit2] Another option is to move to the STM32F765VIT6 and use the extra flash space for importing 1MByte cart images from the SD card when as they don't fit in RAM, plus the extra MIPS would be great

http://www.righto.com/2012/12/the-6502-overflow-flag-explained.html

Consider: A = unsigned, B = signed if (A >= 129) and (B is +ve) then for A + B, 'C'arry indicates overflow if (A >= 129) and (B is -ve) then for A + B, there cannot be an overflow if (A < 129) and (B is +ve) then for A + B, there cannot be an overflow if (A < 129) and (B is -ve) then for A + B, 'C'arry indicates overflow So because the test on A is not a nice BPL/BMI a CMP #129/BC[CS] would have to be employed so might be be so efficient.

Does Xagon count? Is D. Pentecost the Harper Lee of the Atari world and thought "Well I'm not going to better that!"

I'm assuming there's clearance if the eprom is socketed, although if not the whole board could be put under UV so not essential?

Would be nice to have a PCB for the switchable XEGS model done as I think any out there are mod'd XEGS boards? The ideal would be to use a PLCC32 socket and so be able to choose which size (010, 020, 040) to use as the AM29F080 would require soldering onto the board and so would have to be flashed up front unless a GAL similar to the AtariMax could be made to enable reflashing. Although an 010 is 128KB it should be OK to run 32KB or 64KB images by repeating the binary to fill the space. (of course this is for making dedicated releases as users of AVG/UNO/Ultimate/The!Cart etc can emulate the S/XEGS model from a binary image)

Add me to the list for one please. From last night, non-EU based (UK).

I don't mind giving you a hand as have done many ports from A8->5200 So long as the working RAM is not > 16KB then it should be possible. Also some of the data can be compress to ROM and extracted to RAM if needs be and might squeeze in, but bank switching a possibility too I'll drop you a PM later

This isn't true as the result of flash chip byte write can be viewed as the 'and' of the existing and new value. Due to the erase all bits have been set 'high' and so the AND of the intended value is the intended value. Therefore if you were to write the same values over an already written area then that will still read correctly. So think of it as 1's can become 0's but 0's cannot become 1's. The chip spec's tend to state a 10,000 writes limit though in reality it is probably higher. So if wear is a concern then a form of write levelling could be employed to extend the life. An example approach could be one that permits smaller save areas to be used across a larger block. e.g. if your save data area was only 1K then you could cycle these over 8 save positions *. Done by checking the first byte of the block (i.e. $A000) and if not $FF then add 1K ($400) to the address pointer and test until a $FF is found. Then write the save data to that block, ensuring the first byte is not $FF. If all 8 blocks are full then the block can then be erased and so the save takes place from the beginning again. * - chosen for the simplicity of keeping things in the cart window, you'd actually do this over the whole erase block size. This causes a little bit of trickiness in terms of identifying the 'last' save block, for example when the game is powered on it loads the high-score table. By walking the $A000, $A400, $A800 etc addresses, when you find the $FF, or the address reaches $C000, then you read data from the preceding 1K block.

It was asked recently here

Something cool about the 8Mbit cart is that you can mix an 040 and an 010 inside and address them accordingly. You get a smaller overall size (512+128 = 640 KBytes, still about 7 single-density disk sides!) but can utilise the smaller erase block size of the 010. My ideal would be to put an SST29SF010/020/040 in there instead as these have a uniform 128 Byte sector erase layout and so effectively you can treat them as sectors on a disk. This way I had envisioned implementing Seven Cities of Gold as a cart so that the map building would be able to read/write to flash memory whilst creating the world. The 128 Byte sector size should also permit you to use an xBios approach to read/write sectors and treat the cart memory as a file system.

Best to clarify here that it means a 1 Megabyte (8 Megabit) cartridge which has two 29f040 chips, each 512 Kilobytes, with a 64 Kilobyte erasable block size. So (512 / 64) = 8 blocks per chip The 128 Kilobyte (1 Megabit) cartridge has one 29f010 chip with a 16 Kilobyte erasable block size. So 128 / 16 = 8 blocks.

Or hook Contiki to it?

I disassembled the ROM 10 years ago for @Rybags who was looking at things like VBXE and digital sound enhancements. PolePosSrc.zip

The newer (windows based) freeware version cruelly doesn't support the older processors but this older one does, e.g. use "IDA -pz80 file.mem".

The old DOS freeware version of IDA Pro is also worth checking out as its DOS/Borland style menu/windowing system with mouse use is certainly usable. Grab it here.

Yes, either the AtariAge store or AtariMax can make carts from a binary and label image or run from a multi-cart menu.

? It's on the first post of the linked thread

If the graphics mode is OK with 4 colours then this can be done using the 5th player (same colour as background) and a prior mode such as 3 or 9 so that the 5th player is behind the playfield.

So you have little control over where that check takes place, maybe before the h/w collision register is set or maybe after. So even though it was correct for the previous frame, you may get a fake reading for the next frame depending on whether you've already moved the M0. If you instead moved the shadow M0 and in the VBI copied that to M0 then in wouldn't interfere. Hence doing the collision check and potential PMG movement in the VBI is preferable as this is outside of the screen rendering.

Yes they would but you can also consider that something like basic (*) can prepare the values in its own shadow registers and then a VBI can either copy these to the h/w registers each VBI or selectively, e.g. when a flag is set from basic which is then reset by the VBI so say it's been done. Similarly the VBI can do the same for h/w 'read' values such as the PM collision status, copy them to shadow registers after which the h/w status can be reset. Then basic simply reads the values from the shadows instead. (*) although I say basic this means any language, including assembler.