Rybags

I don't have a problem when it's a CPU enhancement/coprocessor such as some of these examples. Even despite the assistant being potentially 100x faster than the host. VBXE enhances video and is largely accepted. It can also assist in doing better legacy graphics or emulating other systems (my Quadrillion conversion from Plus4 does C= bitmap to Atari translation) The 2600 module for 5200 is somewhat different. Such a device uses the host as a passthrough and it barely participates in the experience.

That is the disk SIO sound being used. There's a pretty long thread somewhere around here along the lines of "Atari appearances in TV and movies".

Dos 1 had DUP incorporated with no choice to not load it, no? Also I think there were various bugs that made it not highly usable.

I don't think it would work. VBXE can only override system Ram, not actually access it.

Is it known how it was generated internally? Procedural generation. Compression. Mix of both? Or maybe scrambled either deliberately or because a particular ordering is more efficient. I think I did a search through the core file a long time ago without success.

Diag mode gives the advantage that it can be used for testing a half dead system but disadvantage of practically nothing being initialised. Some games (I think Donkey Kongis one) take the route of using the INIT vector to run the game. At that point the system is mostly initialised but no screen is yet open and no booting has been tested for or performed. That gives the advantage of having things mostly setup but not the untidy looking blue text screen appearing for a fraction of a second before your own display takes over.

It uses hotswap of the cartridge. The copier has a routine which waits for you to insert it then press a key. A couple of seconds later the screen should change colour then you remove the cart and press another key. It should copy non banked 8 and 16K carts that can then be saved to a file. Generally after that the game might need to have protection removed - many cart games have routines that overwrite that area of memory to try and stop Ram based copies running.

Looks good. The VCR fast forward artifacts a nice touch.

It's not the bug, in normal usage you can go weeks without encountering it. In this case it's almost on demand. So this computer does have some genuine issues going on.

Looks quick. Would be nice to see how RC handles that title pic, which in itself looks very well done. And would be interesting to see this running on our computer from the Plus/4 code - a sort of quick and easy way would be to use VBXE to do blit translation of the graphics.

Yeah, no GTIA problem. If the memory upgrade isn't done properly you have potential for trouble. Can you load games from disk or emulated devices? Need to be ones that require 32K or 48K minimum. Most carts will use 16K or less so not much use for testing.

Strange - the values are as you'd see on the 4 LUM pins and you'd expect 8-B to be affected as well but they aren't. It's as if the colour is completely ignored and luma goes to maximum (or even beyond that) I don't know a great deal about the UAV but I'd be checking for shorts between connections and check the jumper settings are correct. And +1 to suggestion of trying this GTIA elsewhere / putting another one into this computer.

What if you enter some normal commands? Like: A=1+2 SE. 2,0,0 RAD BYE Type something such as L. in between each to verify if a lockup occurs. Generally if Basic locks up it's an unrecoverable situation that needs a fresh powerup to fix it. It could be a bad Basic Rom. On 600XL the Basic has it's own socket. Top right IC is Basic, the slightly bigger one below it is the OS. If socketed then you might try prizing each end up a bit then reseating it. If it remains bad, Rev C replacement can be obtained.

Try a fresh powerup then type GR. 8 If it works then your original problem is probably the Rev B Basic lockup bug caused by it's memory move routine. Sort of unavoidable, Rev C fixes it, the workaround is to save your program as you go along.

I don't see a lot of point of such computers unless they can use old cartridges and peripherals from a legacy machine. Otherwise, why not just do the thing as an emulated device and/or use a platform such as RasPi to create it? If I was to jump on board something, I'd like an Atari computer that could attach carts and SIO devices but also have enhanced Antic/GTIA, VBXE, Component and DVI video out, and while there may as well throw in Maria, TIA, other sound chips, and a turbo CPU.

2 problems I see - lack of Maria chips and the fact you'd render a 7800 dead each time you harvested one. The Atari could potentially become a peripheral, merely supplying joystick input and possibly uploading Rom images to the box but otherwise not participating or much benefitting from the experience.

You could try it (simulated) in the emulator. Load your final object from DOS 2.x with the /N option so it doesn't run. Press F8 to get the debugger. F 700 L4000 00 E 9 01 E C 00 6E .warmreset Press F8. Emulated machine should then warmstart and run the game.

Possibly the game assumes Ram will be clear since the normal scenario is loading in one go from coldstart. If loading from DUP then that's definitely not the case. I thought this game was crammed to work in 16K - but loading the APX version, CHBASE=$60 and PMBASE=$50. Maybe if you added a final segment that cleared RAM from $700 through to the lowest loading address.

Probably not. I actually passed the work onto kjmann before he got sick and he was going to get someone else to work on it. I don't know if that went ahead. I have limited time to do stuff and this would be pretty low on my to-do list.

There's a DLI/kernal that changes the colours. From memory the original game used the single routine with various branches depending on what level you were on. I'm fairly sure the change I made gave each level a unique DLI to help with game speedup. By referring to the DLIs it should be fairly simple to deduce where colour change occurs. Not sure if it would be straightforward to change to Tarzan. The required change sequence looks similar so it might be easy.

As good as animated cash being shown would look I think ultimately it could become an unwanted slowdown. There's 2 reasons to play this game on a computer instead of the board version - computer player/s to make up for lack of present humans, and the speedup aspect of the entire thing.

Off topic but relating to Atarimania's collection - I have a manual for Eastern Front which seems different from that on the webpage http://www.atarimania.com/game-atari-400-800-xl-xe-eastern-front-1941_5986.html The first inside page, the text is somewhat different. Not sure about the remainder. I could scan it if it's not archived anywhere.

Maybe an S-Video to HDMI converter. You could mix the S-Video into composite but the result probably wouldn't be very special.

Your sm_ptr value is wrong. It's should be decimal 88 which = $58 Also, that will only show one character (letter A) - your loop code needs changing. In this case you could also use Y as the character value to be stored so it should go: loop tya sta sm_ptr,y iny bne loop

Fairly sure even some early games had it, but at the time it was in plain sight, e.g. they'd have a routine to clear hw registers on startup then put in an extra instruction or 2 that zeroed out part of the Rom space. Later on it became a lot harder to find - I cracked probably a dozen carts but couldn't work out any of the Thorn/EMI ones. And Super Cobra I couldn't work out so I just added some code in the VBlank that restored the region that got corrupted.