Rybags

For stuff I've converted from other systems, IDA Pro (The Interactive Disassembler) comes in really handy. From memory I've done at least one conversion by just using a memory dump from when the game had finished loading and initialized. There's other, free disassemblers around which can do a good job. The way I like to approach such a task is to generate initial source that will just reproduce the program near enough to identical to the original software on it's original system. Once you have that you know you're starting with good code, then start modifying to run on the target system. Much the same applies is it's just a modification of a game on the original system. Though with Stellar Shuttle 480i, I implemented that as a bunch of patches. It's something I'd like to try and tidy up once I find the notes I took about it.

Could probably work out the offset from when the byte is received - just do a frame wait if one drops out of sync to the point where the gameplay would be affected. For PAL vs NTSC I think the technical challenge might be too much for a game like this.

Possibly - in theory such a game could work, all you really need is to be in sync and receive the controller input from the other machine. Stuff like Random could be changed to do it by software rather than reading the register, a seed could be generated then shared. A potential issue is that you aren't frame-locked so VBlank on one machine could occur when the other is at mid screen. But serial data transmission by Pokey is such that you can do it at stock or the low turbo speeds and still have stuff like DLIs going on. The game might need modifying to ensure the VBlank period where IRQs are disabled is as brief as possible.

I suspect it might be an emulation bug. It is background colour and not "black" as you can get with a priority conflict that results in nondisplay of a pixel. Would need to look the docs over but I'm fairly sure priority conflicts among VBXE and GTIA graphics shouldn't occur.

Procedurally generated. It's sort of weird. During descent the starfield is done by using all the Players and the missiles form the screen bars. But on the planet Player 0 and 1 form the bars. This patch will remove the bars but it also screws up the instrument panel which isn't really acceptable: e 3c5f a9 00

If I get time later I'll see if it can be patched into the game image. Not sure if it's copied from actual data or procedurally generated.

Commands from debug: F C30 L57 0 F D30 L57 0 The windows look to be programatically generated, probably at the start of each new level so you'd have to do it just after the ship launches. On the subject, HTF do you abort the demo? I thought it was Esc but that does nothing in emulation.

Player 0 and 1 do the windscreen struts. The PMs are by single line DMA. This applies to the disk animated intro version, others unknown. The PM DMA at this point is 1-line and you can remove the bars by zeroing out the following locations: $C30 - $C87 and $D30 - $D87. Below that point they seem to be used for the curvature of the dashboard so potentially might be easily modifyable to alter that (ed - removing them completely will reveal graphical glitching where the curvature is so probably best left alone, but removing the bars is fine)

There's a bit going on there - it's a mix of mode 8, PMGs and PRIOR change to get the 16 luma mode.

I like the original style with interlock device and metal label. The later XE type are chintzy IMO. Don't mind the Activision ones, also there's similar ones that are shared with the C64 which aren't bad. I guess cost would be the big factor in the original style not being made for long, would't surprise me if the case parts BOM came to more than the board and chips.

For backgrounds, possibly something like a parallax rendering system using a modified GTIA mode - ie 80 pixel width with a height of 4 or more pixels. So maybe a scrolling area of about 100 pixels high (25) could be done, that should be doable at a reasonable frame rate.

I think I posted an answer to that one elsewhere last week - yep, the DLI method was one. The other could use a setup PM collision to do the detection.

When you tell Antic to use extended banking, then any normal read access by it to $4000 - $7FFF addresses will hit whatever bank is selected. That includes DLIst, display Ram, PM graphics. If you have need to manipulate DLists then there's plenty of options. You could cycle through 2 or more, performing updates on one while the other is active. The time to change PORTB bank isn't much different than changing 2 bytes of DList pointer. If you disable the OS Stage 2 VBlank you can even chain DLists together using the JVB at the end to point to the next one to run from, though potentially it could become a pain to debug.

Yeah, it's been a while since I looked it over. Fair enough with RIOT/TIA since it's 2600 tech - the clock speed is colourburst/3 where A8/7800 is colourburst/2 on NTSC. The Maria video accesses - I think it's something like 2 7.2 MHz cycles for RAM and 3 for ROM. So you have to sit down and calculate how much bandwidth you have available for your graphics.

I wonder how the Ram interface would be done - I'm fairly sure the 7800 Ram is somewhat higher speed SRAM and accessed at 3.6 MHz effective? So I guess it would have to have it's own dedicated Ram then the computer would need some way to also talk to it. Maybe some sort of shadowing is going on where main Ram acts as a cache that the CPU has available then Maria has less impeded access to the SRam?

Is TIA sufficiently reverse-engineered for a proper FPGA implementation? I know that even in the early 80s competitors had their own versions but there's all those quirks that aren't necessarily replicated properly and games can not work as a result.

Not sure how they are doing this - it looks like it's probably addressable and generating video locally. Not a lot of point IMO for multilpe reasons. VBXE is already here and not widely installed. Maria stocks are probably not great, why disassemble a good 7800 to allow the computer to emulate it in some capacity? Doing the Moon Cresta conversion - the graphics generation of the 7800 is somewhat different to just about everything, it's not text based or bitmap based, it's really just a sprite engine that's limited by available DMA per scanline to read the objects. Generally converting a game involves going up a level or two from the hardware and just generating objects by translating the positional and data pointers. I doubt the 7800 + Antic graphics could be combined easily. Possibly something like an enhanced Sophia could take graphics from both and combine them. But at the end of the day you'd end up with yet another graphics standard to support and I do suspect that porting games wouldn't be very direct. In all probability the Asteroids might have been reassembled to cater for different addressing to the used hardware. Additionally, you have TIA for the sound/controller inputs which is another consideration - likely games would need changes there as well.

Looks good - probably been said but it reminds me somewhat of Chaos Engine.

Antic, GTIA and PIA (for XL) are critical - video generation and system clocks, proper Rom configuration from PIA. PIA on 800 - possibly it could operate without it but SIO needs it for Command and motor control. I'm still curious about Pokey and whether eventually the polling attempt would just time out - a quick look at the code, I do suspect it probably just hangs during the command send, likely the timeout check doesn't begin until the command frame has been sent and this never occurs because the serial output needed IRQ never fires.

The polling - I'm not sure if that will time out, experimentation would be needed there. But in the case of a game cart being present - practically all don't allow the disk boot so that would be skipped. Additionally the diag mode carts will usually do a minimal initialization sequence which is part reason why they can still work on a faulty machine.

Star Raiders clears GTIA and Antic registers almost immediately. I'm guessing the failed runs are where there's a dependence on Pokey doing something. Have you tried with Pokey removed completely?

Plenty of game carts should start up in theory. Most games will have the boot flag set to disallow disk booting which should see them start up.

Try pressing Break a few times to see if anything happens. In theory the boot polling should timeout at some point then give you the Memo Pad though not sure how long that would be.

Likely it's the stock 1200XL OS. Boot without a disk drive or type BYE from Basic to see if you get the logo or Self-Test.

With lots of Ram and the right software in theory you could get sort of close to Amiga sound quality given it's 8 bit playback and you could probably brute force over 24,000 samples / second. What examples you see around could well have been done with 48K systems in mind and use fairly low sampling rates. But it's not a widespread device and there's not a huge amount of software or support for it. Know the difference old vs new? I doubt there would be much.