ZackAttack

Wouldn't a more complete model be required in order to know that it's not more complicated? Sounds like a self fulfilling prophecy to me.

Assuming that work is made publicly available.

Using the bitwise and that RT linked to should work fine for the ones and hundreds digits. For the tens digit I'm assuming you want the result to be a number between 0-9 right? If so you should use a right shift instead of an and operation. In bB I believe you can do this by simply dividing by 16. tens = _sc3/16

Technically we should take this one step further and repeat those results with an unmodified ROM. Though, what Thomas did is already way more credible than some spreadsheet derived from an undisclosed disassembly. I wonder how much more the time can be improved before we'd hit the real minimum time.

In the beginning of the video it shows that the player is not using the original dragster rom. It's a hacked version which completely invalidates any time it produces. Thomas proved that the time is possible, which is a very different thing. Using this method to prove it's impossible would still have the flaw that you may have overlooked an exploit that allows you to exceed the theoretical limit.

Tried to find the source so we could verify omnigamer's model. He said he's not going to post it for legal reasons. (http://tasvideos.org/forum/viewtopic.php?p=453106#453106) Seems like any argument that could be made against the legitimacy of the record could be more easily made against his claims. Anyway, there is a little bit of info in his first post that could provide a decent starting point for disassembling the game. I did a quick search to see if anyone has posted a commented disassembly but couldn't find one. Does anyone know of one that exists?

I think proving it is impossible is about as feasible as proving there are no purple giraffes. Just cause you have never seen something and you don't know how to find it doesn't mean it doesn't exist. Of course proving the opposite is as simple as providing a single counterexample. So I don't think it matters. No matter how many people analyze the code and brute force different button combinations you can always claim that something was overlooked. The only way this will be fully settled is if someone can actually find away to repeat the record run.

I think that's wise. Your code looks good. One suggestion I would make is to change how you define bit variables. Instead of using org to reset the address you can simply list multiple labels for a single DS command. You may also want to consider appending the bits that apply to that variable to make it easier to spot bugs where the wrong bits are accidentally changed. This ; DIRECTION, FIRST_FRAME, and HIT_WALL are all the same location in RAM DIRECTION ds 1 ; direction of sprite ; | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ; X X O O O O O O ; 7 = facing up ; 6 = facing right ORG DIRECTION ; reuse DIRECTION variable with new name FIRST_FRAME ds 1 ; whether or not this is the first frame ; | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ; O O O O O O O X ; 0 = only set on first frame ORG DIRECTION ; reuse DIRECTION variable with new name HIT_WALL ds 1 ; bits for collision variables ; | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ; O O O O O X X O ; 2 = hit top or bottom wall this frame ; 1 = hit left or right wall this frame could become this DIRECTION_76 ; direction of sprite HIT_WALL_21 ; bits for collision variables FIRST_FRAME_0 ; whether or not this is the first frame ds 1 ; | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | ; U R X X X V H F ; 7 = facing up ; 6 = facing right ; 5 = ; 4 = ; 3 = ; 2 = hit top or bottom wall this frame ; 1 = hit left or right wall this frame ; 0 = only set on first frame Look forward to seeing what you come up with next!

No, I haven't posted a ROM for it yet.

I did. It uses the display kernel that I discussed here.

If you can limit it to a power of 2 I think you can just do a bitwise AND of 2n-1. 5 mod 2 = 5 & 1 = 1

If I'm understanding this correctly. The AFP emulation is not accurate enough to run the existing 32 char kernel that has proper orientation. So I was proposing a workaround that uses a simpler kernel which hopefully works on the AFP. It should be possible to detect if the code is running on the AFP or not. Then the sideways kernel could be used for AFP and the other one with correct orientation could be used everywhere else. Sure, rotating the AFP would be a little odd, but it's the best I could come up with. Personally I would prefer to have a solution that requires turning the AFP over a solution that uses flickering, interlacing, or venetian blinds. Has anyone tested on the AFP with the bin file I posted above? Does it render properly and is the text readable?

Here's a quick test rom. I don't have an AFP to test on. Can someone who does give this a try? I'd like to know if it displays correctly. DaveC1964 would this be a viable solution for what you want to do? Keeping it a 4K rom would leave enough room for 16 pages of text. Each page is 6 rows of 32 characters. I made each character 5 pixels instead of 3 because they looked too tall and skinny with only 3 pixels. afp-text.asm afp-text.bin

If you only do this for the AFP you could draw the text vertically on its side and require the player to rotate the AFP a quarter turn to put it in "text mode". In theory you could do 6 lines of 48 characters per page. Assuming 3 pixel chars, 192 pixel high kernel, and that the AFP can properly run the program required to do this.

Using this article as a reference I was able to put together a basic make file, linker script, and assembly source that generates a 32KB binary image. I then programmed a basic assembly program which should force the data bus low. In order to make it loadable on the harmony I put 8 NOPs to fill the first 32 bytes, followed by the 0x10adab1e magic number and another 128 NOPs to compensate for the unknown entry point. Finally there was the assembly to make the IO pins output 0 on bits 8-15. I built it and loaded it up on the harmony but it just got stuck at the loading spinner and the logic analyzer confirmed that the data bus was not forced low. Next I opened the test binary and a dpc+ binary in a hex editor and compared them. I noticed that there appeared to be a few more magic numbers adjacent to the loadable bytes. So I copied 16 bytes from offset 0x20 instead of 4. Built it again, ran it, and this time the loading spinner went away after a few seconds. I then confirmed with the logic analyzer that the data bus was being forced low and the address bus was still operating normally. The 6507 was operating as if it had an infinite stream of BRK instructions. What's interesting is that the 4 bytes at offset 0x28 is the 32bit value 0x4000008C which would be a fairly low address in the RAM. My guess is that this is how the bin image tells the harmony menu where the entry point for the game is. I plan to change it to a ROM location and remove the extra nops in order to verify that this is in fact how the entry point is specified. Another conclusion from this is that the loading spinner program is stored entirely in VCS RAM. Otherwise, it would have stopped when the ARM MCU went into a bad state. Will need to capture it in action via the logic analyzer in order to figure out how to transition control back to the arm mcu.

Here's what the harmony board looks like.

I took apart my harmony cart and traced the edge connector signals back to the MCU with a multimeter. My conclusions are as follows. 6507 D0-D7 is wired to LPC2103 p0.8-p0.15 6507 A0-A12 is wired to LPC2103 p0.16-p0.28 There is also a ROM chip, FL208KI, which is wired to the SPI0 port. That's going to require further investigation at some point because the chip select signal goes through a solder jumper, SJ5, which is open on my harmony board. A 512KB SRAM chip, AS6C4008, is also present. That's a mystery too since the LPC2103 lacks an external bus interface to quickly access external RAM.

Based on a review of the stella source there appears to be two signatures that may indicate to the harmony cart that a bin file contains executable arm code. I looked at a DPC+ rom with a hex editor and found 0x10adab1e stored in little endian at offset 0x20 and "DPC+" in ascii at offset 0x328. Here is the relevant function from the cart.cxx source file. bool Cartridge::isProbablyDPCplus(const uInt8* image, uInt32 size) { // DPC+ ARM code has 2 occurrences of the string DPC+ // Note: all Harmony/Melody custom drivers also contain the value // 0x10adab1e (LOADABLE) if needed for future improvement uInt8 signature[] = { 'D', 'P', 'C', '+' }; return searchForBytes(image, size, signature, 4, 2); } After reviewing the stella implementation of DPC+ it appears that the driver is simulated rather than executing it in an arm emulator. So there is no indication of where the entry point to the driver is. We probably need to fill the entire first 3KB with ARM NOPs and a very simple output routine at the end. Once that's verified with the logic analyzer a binary search can be performed to pinpoint the exact location of the entry point.

Spiceware created an excellent blog about how to build a DPC+ game a while back. Referring to part 6 and the collect2 source from part 7 you will see that a DPC+ game is essentially the concatenation of the DPC+ driver, custom arm code, and 6507 assembly. These 3 sections are combined into a single 32kb file which becomes the game.bin file. The harmony cart must detect the presence of the DPC+ driver and then know to turn over execution to it. Since stella is open source and also properly detects DPC+ games it should be trivial to grok the stella code for the detection method and hopefully the entry point. Then we can modify the collect2 build to output a 32kb file which effectively cuts out the DPC+ driver and any 6502 assembly code. Once the build is set up we'll take what we learned from stella and implement it so harmony detects it as DPC+ and executes our entry point. To verify this is working we can simply toggle the MCU IO port between 0x00000000 and 0xffffffff and watch for it with the logic analyzer. Once we have a good build and detection and entry point are working we can use trial and error to identify the portions of the IO port that are mapped to the data and address bus. Simply toggle one byte at a time and use the logic analyzer to map each byte to the corresponding VCS bus. At tis point we should have DPC+ detection, entry point to arm code, and port mappings to VCS busses. From there we can start figuring out how to initialize the VCS from whatever state it's in when the entry point is called.

I started thinking about how to architect this new driver. Regarding sound I think the easiest thing to do is assume there will be an audio buffer which is used to update AUDV0 onces per scanline. The last 5 scan lines of VBLANK should be dedicated to positioning the 5 moveable objects (P0, P1, M0, M1, BL). A few scanlines of overscan will probably be consumed with the overhead of jumping to the TIA RAM routine and calling the game program. There's 3 + 37 + 30 = 70 total scan lines outside of the actual tv picture. Subtract the scan lines that are consumed by positioning and function overhead and it's no more than 64. If we pack two 4bit audio samples into each byte we only need 32 bytes of RAM to hold the audio data during overscan and vblank. This leaves 96 bytes for the tv sync routine. It should also give about 3.8ms of uninterrupted ARM processing time. By dynamically generating the 6502 instructions we can limit the set of instructions to just a few and make it possible to always predict what memory location the 6502 will access next. Rather than trying to poll the address bus for a change and then calculating what data value to put on the bus after the address has changed and been read we can calculate the next data value first and then as soon as the address changes put the new value on the bus and move on to the next instruction. This allows us to be at least one step ahead of the 6502 at all times. It also will free up some valuable arm cycles during the display kernel. What's even cooler about this approach is that it opens the door for more dynamic display kernels. You can move writes to GRPx so they never occur at the same time the player is being drawn. PF scrolling at full resolution is free cause all the bit shifting can be done during the display kernel instead of during overscan. etc. The overall execution would resemble this: init: point reset vector to $f000 initialize buss stuffing driver use non-bus stuffing writes to copy syncRoutine to TIA RAM at $00A0 zero syncRoutineAudioBuffer ($0080-$009F gameLoop: //Start of overscan enable vblank read controller inputs give control to 6507 // jmp $00A0 set timer to inturrpt just prior to syncRoutine completion if last frame missed deadline resume game code execution where it was interrupted else call game code // At this point the ARM is running game code while the 6507 runs overscan and vblank from TIA RAM wait for syncRoutine to complete // PC = $f000 // ARM has taken back control, 6507 is now a slave to dynamicly generated machine instructions vblankEnding: update AUDV0 each scanline position objects during last 5 scanlines of VBLANK copy 32 bytes of audio samples to TIA RAM at $0080-$009F during the wasted cycles used to time the RESxx strobes displayKernel: disable vblank draw the screen while continuing to update AUDV0 each scanline goto gameLoop

The 2600 doesn't do 160 pixel wide bitmaps. Even with quad bus stuffing and flickering/interlacing that's a stretch. Does this mean you have modified the system as well in order to allow the ARM processor to directly access the TIA chip?

Very cool project. Could you share more details about the hardware? I assume you've got a MCU on there, which one is it?

If you haven't already, make sure you get a good understanding of the different addressing modes that the 6502/6507 supports. The difference between LDA $00 and LDA #$00 can be a large amount of cursing at stella debugger. Also, make sure you configure stella to "Drive unused TIA pins randomly on a read/peek". This option is under TIA in the debugger mode aka pressing ~ key. Driving the unused TIA pins will help you notice when you forget that # and end up with a ZP load instead of an Immediate. And you will forget, we all do.

To build the break out box for the harmony cart you need the following supplies. These same parts can be used with any cartridge type. The harmony just happens to be the one of interest at the moment. Some hookup wire to solder to the edge connector and for general bread boarding. Any 22AWG solid core wire should work. https://www.digikey.com/product-detail/en/general-cable-carol-brand/C2004A.12.05/C2004Y-100-ND/122086 24 position female connector to plug the cartridge into. https://www.digikey.com/product-detail/en/te-connectivity-amp-connectors/8-5530843-3/A101969-ND/2310830 Some assorted premade wires are very useful for attaching the logic analyzer to bread boards. I ordered mine from banggood and the colors matched the logic analyzer I bought. This makes things super easy to wire up and is well worth the money. I recommend getting both 10cm and 30cm sets because you never know when they'll come in handy. https://www.banggood.com/120Pcs-30cm-Male-To-Female-Male-To-Male-Female-To-Female-Jumper-Cable-DuPont-Line-For-Arduino-p-1058293.html?rmmds=myorder https://www.banggood.com/3-IN-1-120Pcs-10cm-Male-To-Female-Female-To-Female-Male-To-Male-Jumper-Cable-For-Arduino-p-1054670.html?rmmds=myorder A 16 port logic analyzer is good enough to see what's going on with the VCS busses. You won't be able to capture the complete address and data buses at the same time, but 8 bits of each is enough for debugging purposes. They aren't that expensive though. In theory you could buy two and use one for each bus. https://www.amazon.com/gp/product/B0027QRPIA/ref=oh_aui_search_detailpage?ie=UTF8&psc=1 Obviously, this project requires soldering tools and supplies as well as some basic soldering skills. I'm sure google has plenty of info on this if needed. A 4k donor cart is required for the PCB. You need to take out the PCB, paying attention to how it was oriented in the Atari. If you lose track you can always use a multimeter to verify the orientation by checking for +5V on the appropriate ROM pin. The ROM should be removed and some short lengths, about a foot, of hookup wire should be soldered in each pin hole where the ROM was. It is recommended at this point to label each wire with some masking tape and a pen/sharpie. Simply use the online pinout for the 4k cart pcb. Note OE is the same thing as A12, so use A12 because that's what we really care about. Some foot lengths of hookup wire can be soldered to the card edge connector pins. This is a little bit tricky, but with some patience it's not too bad to get all 24 wires on there. This wires should be labeled as well. Once the cart pcb and edge connector both have hookup wires attached you can assemble the break out box. Wire both the pcb and socket together via the breadboard. On one side of the breadboard put the databus wires in order from D0 through D7. On the other side put the address bus wires in order from A0-A12. Wire 5V and GND to the power bars on the side of the bread board, but make sure they are on separate power bars! At this point you should be able to put any working game cart into the connector and power up the VCS and play it. Once that's working it's time to attach the logic analyzer. Use the female-to-male 10CM wires and match up the colors with the logic analyzer. Put one 8bit port on D0-D7 and the other on A0-A7. While the VCS is on and a game is playing you should now be able to capture bus activity with the logic analyzer. You should also be able to group the signals into two 8bit busses to view the values in hex and create triggers so a capture occurs when a specific value is detected on the bus. You should end up with something that looks like this:

If you could help with the new bus-stuffing driver that would be awesome. Since the driver is so close to hardware you really need to be set up with a logic analyzer to be effective though. Would you at least be comfortable with doing a little soldering and bread boarding? It's nothing complicated, basically you just need to create a breakout box to attach the logic analyzer to the VCS address and data bus. It's less than $200, including the logic analyzer, to get something similar to this: