splendidnut

The DPC chip is essentially a display data processing chip and would require a ton of logic chips to recreate. It contains 8 self-decrementing data address pointers called data fetchers which allow the user to access it's internal ROM data. The data fetchers allow the cartridge program (Ex. Pitfall 2) to read the data in numerous ways (rotated, nibble swapped, or masked). The DPC chip also has the capability of 3 channel music which is done by mixing 3 channels of sound data into a sample stream to be played back thru a single TIA audio channel. Here is a link that summarizes it's capabilities: https://www.taswegian.com/WoodgrainWizard/tiki-index.php?page=DPC If your goal is to make a DIY cartridge, you will need to use an FPGA chip or something similar (ARM, PIC, etc...) to recreate those capabilities.

Some work has been done: I figured it was time to start my own topic about it.

So... over the summer I rewrote my Congo Bongo POC/demo in C. This was done to help with testing out the C-like language/compiler I'm working on. Also, I'm hoping this will help with handling the two (or more) planned ports of the game (2600 and 7800). So far, I've got: -- The player in full color - He can move around, jump, and climb. Movement is still a bit rough as it doesn't compensate properly for the "diagonals". And there are a couple of quirks with jumping. So still a bit rough, probably even a bit more rough than before in the previous POC releases. -- The monkey in full color - I copied the code from my 7800 demo and rewrote it in C. The monkey has a simple path he follows. He moves between grid spots, pausing after each move, and jumps up/down when necessary.... The jumping is still quite rough, but it suffices for now. -- The coconut - Just bounces up and down... This is something I've just started working on. Just ignore the tail... -- Bongo... well, some of his data is in the ROM, but there's no code for him yet. The cool thing is this demo is currently clocking in around 3k of code/data. Which leads me to believe I might be able to end up with a playable one-level demo that fits within 4k. But, that all depends on how much more game logic is needed, and what kind of craziness the drawing kernel will turn into. At this point, I haven't gone thru the trouble of figuring out exactly how I want to do the kernel to get multiple sprites on the screen. I am currently using a 2 line, doDraw-based kernel. I'm basically out of cycles (save for a single NOP), but was able to have the 4pf colored background (single line) with 2 full color sprites (double line) and a missile (for the coconut(s)). ----- For me this demo serves as a POC. Being able to see the player in multi-color on the alternating line-color background gives me confidence that this is worth doing. With the previous POCs, I was a little worried that it wasn't going to look good enough. Now, the only thing I'm worried about is how well flickering sprites will look. I've got an idea of how to display a decent looking Bongo, but it involves flicker, so we'll have to wait and see how that looks. ------ So, with all that said, here are the ROMs for NTSC, PAL50, and PAL60. For NTSC, I chose the colors specifically to somewhat match those I've already chosen for the 7800 version. For PAL, I've provided both PAL50 and PAL60. I've chosen different palettes for each of those, with the PAL60 being the one trying to match NTSC. My Stella settings for PAL are a bit out of whack, so let me know if I've made some grave error in color selection. I know PAL might be somewhat of a pain to get right, since I don't have access to PAL hardware. Anyways, Enjoy! congo_20210909_NTSC.bin congo_20210909_PAL50.bin congo_20210909_PAL60.bin

Here's another alpha release of Neolithic for those of you ambitious enough to grind thru figuring out how to use the compiler and what it can and cannot do. This should be more usable than the last version, as I've recently added direct binary generation. And I remembered to turn off the "debug" code that botched up the first (subtle) alpha release. Included below is a zip file containing both a Windows and a MacOS executable. It's a command line program, so you need to use either Command Prompt (in Windows) or Terminal (on MacOS) to run it. To run, use one of the below lines followed by the file to compile: neolithic.exe (in Windows Command Prompt) ./neolithic-mac (in MacOS Terminal) Make sure everything is in the same directory when you compile. Source file(s) should end with the ".c" extension. The compiler outputs an ASM file (DASM compatible), a BIN file (4K Atari 2600 binary), a SYM file (symbol table compatible with Stella) and a bunch of AST files (abstract syntax tree files for each source file #include(d)). If you're looking for documentation, I don't have any good documentation yet. I have a quick little write-up, but it really needs to be filled out more. If you have any questions, please ask, as that will be the easiest way for me to know what needs documenting. The Congo Bongo demo source code included below is probably you're best bet for figuring things out. --- Some notes of what I've been working on: The big user feature for this release is the direct binary generation. DASM is no longer necessary as the compiler can generate a binary file that can be used in Stella. Besides the direct binary generation, the other big feature is function call tree analysis. I implemented this feature to be able to: (1) track function usage - whether a function is used or not, whether it can be inline-d or not, etc. (2) track overall call depth - to know where the zeropage RAM ends and the stack begins (very important on the 2600) (3) statically allocate stack frames - allocate local variables based on absolute memory locations vs. stack relative locations The feature is not fully complete, but I'm going to push the code generation more in this direction. Using statically allocated frames instead of stack seems to be the right way to go, as the lack of stack ops on the 6502 tend to minimize the usefulness of a stack-based approach to function arguments and complex expressions. The compiler still does not fully support 16-bit ops... mainly because I have to switch up how the expression processing and code generation work. I'm currently using both the A and X registers to do this, but that doesn't seem like the right idea... This is where having a second accumulator register would come in handy. I'm thinking I might need to switch to utilizing my memory-based 16-bit accumulator I've created for the multiply op support, or maybe even adding in more temporaries as needed... Which leads into flattening the expression trees during code generation, which is something I've already started working on the code for. Part of the stall-out with 16-bit support comes from me not really needing robust support yet in any of my own Neolithic-based projects. I'm too good at avoiding and working around the issues/shaky support of this feature in the compiler. With the 6502, I found it's better to favor array constructs over pointer ops; then only using pointers to set a base offset into an array of data... and then accessing that data with array operations. i.e. set spriteFramePtr to point to current sprite frame, then use spriteFramePtr[y] to access the data. Which makes me wonder if Pascal would have been the better language to base this language on. Hmmm... ----- Anyways... Enjoy. Neolithic-v0.2alpha.zip congo_c_2021_08_15.zip

Fixed the symbol loading issue in Stella. Easy fix: I just had to move the Loc (memory location) column to be the 2nd column and remove the '@' sign.

Lol. Yeah, that would help. I was thinking about fixing that, but then I saw the bug and the missing code in the sort algorithm, so now I've got it working. As to why: The symbol file being loaded is from my compiler instead of DASM. It has a vast amount of information that I use as a reference, but it is currently incompatible with Stella: Symbol Table: Symbol Name Kind Flags Pntr Loc BS #El Size Value ----------------------------------------------------------------------- playerSpr const 4001 false @f1d0 01 13 0013 playerColors const 4001 false @f1e2 01 13 0013 enemySpr const 4001 false @f1f4 01 02 0002 spriteX var 4001 false @0082 01 08 0008 spriteY var 4001 false @008a 01 08 0008 spriteOrder var 4001 false @0092 01 08 0008 initOrderArray func 0000 false @f1f5 01 00 0017 Locals: idx var 0401 false @009b 01 01 0001 0 sortSpritesViaInsert func 0000 false @f20c 01 00 006e Locals: curSprY var 0401 false @009b 01 01 0001 sprOrdIdx var 0401 false @009c 01 01 0001 foundSpot var 0403 false @009d 01 01 0001 sortedSprNum var 0401 false @009e 01 01 0001 workingSprNum var 0401 false @009f 01 01 0001 curSpr var 0401 false @00a0 01 01 0001 0 drawKernel func 0000 false @f27a 01 00 0052 Locals: sprY var 0401 false @009b 01 01 0001 0 playerY var 0401 false @009c 01 01 0001 1e row var 0401 false @009d 01 01 0001 57 main func 0000 false @f2cc 01 00 0000 Locals: mainTimer var 0401 false @009a 01 01 0001 0 At some point, I'll probably looking into fixing the compatibility issue and/or adding support to Stella for this format (once I've got the format nailed down).

But can be summed up in less than 100: Using Stella to debug a rudimentary sprite sorting algorithm (in C compiled to assembly then run thru DASM to run in Stella) WHICH is being used to help with developing a better multi-sprite engine for ChaoticGrill WITH the added layer of complexity being it is using a C compiler which is still in-development (Neolithic C) AND debugging issues with that (the C compiler) at the same time. Oh, the joys of debugging. Just thought I would take a moment to share this madness with the masses. Enjoy, ---- And yes, that is the Congo Bongo code from the previous blog entry loaded in the background in Notepad++.

That drill is awesome. In fact, this whole project is pretty awesome. Hopefully we get a "playable" demo in the near future!

If you're getting consistent results with working and non-working cartridges, that would point to the cartridges themselves being the issue. Either the PCB contacts are worn out or the ROM chips have been zapped. If you cleaned the PCB contacts, then the cartridge is likely dead.

For the color conversion from NTSC -> PAL, it can get a bit complicated depending on how colors are loaded and where they are stored. A simple software solution would only be able to handle simple cases. More complicated cases require analysis of the ROM which would take a lot of time to develop. It's quicker and easier for a human to disassemble and attempt to analyze the code, then to write code to analyze the code. The easiest option would be to contact the original developers to ask them about it. A Pal60 -> Pal50 conversion involves digging thru the code to figure out how to change the speed of the game objects. That may be simple and easy to do, or it may be complicated depending on how the developer designed it. With that said, I believe there is ROM hacking software somewhere that would assist in converting colors, but it would still be a lot of manual work. @Nukey Shay is one of the guys to talk to about hacking ROMS. ---- As for Palomino, the developer keeps to himself. No one has been able to contact him.

I would think detecting a DPC+ game using only the DPC+ ARM driver vs a game using Custom ARM code would be a bit difficult. But, maybe I'm wrong? ADDENDUM: Really, I'm just wanting to see how many extra platforms will support ChaoticGrill. That's my evil plan anyways. Now, if I could just get off my butt and finish it...

@llabnip ChaoticGrill is DPC+ without the need for ARM. So you could probably get that working if you really wanted to. You just need a way to detect that there's no custom ARM code, which would probably be a pain and not really worth it. You could probably also support bBasic DPC+ games... but then again, I'm guessing detection would be a pain. ADDENDUM: I probably should clarify that first statement lest my head get bit off. ChaoticGrill is a DPC+ game that doesn't use CUSTOM ARM code as it only relies on the DPC+ driver.

The 6502 chip uses the last 6 bytes in the address space to define 3 pointers that point to code in memory to call when Reset, Interrupts (IRQ), or Non-maskable Interrupts (NMI) occur. On the 6507 chip, the IRQ and NMI lines were cut from being accessed, so they will never need to be handled. BUT, the IRQ vector also is used by software interrupts: the BRK instruction. Vectors in memory: $FFFA - NMI $FFFC - Reset $FFFE - IRQ/BRK You really only need to worry about Reset. But it's always good to set BRK to the same thing as Reset... so that if your game resets, you know when your code has gone astray. Equates just assign a value to a label and don't ever take any space. DS and company usually define space within the file, similar to DATA command in basic. BUT if you use DS in an "uninitialized segment", then it wil work more like defining variables that get assigned memory spots when the program is loaded. Example of using an "uninitialized segment" to define variables: (from Paint The City) SEG.U variables RORG $80 mainGameTimer ds 2 ;-- uses $80,$81 mainGameTimerHi = mainGameTimer+1 bgScroll ds 1 ;-- this ends up being $82 lvlOfs ds 1 ;-- this ends up being $83 Here I use DS instead of having to track the individual memory locations for each variable that I would have to do when using EQU/=. You can think of a stack like "a stack of papers" on your desk. You can stack up the papers by putting each one on top of the other (PUSH onto the stack). Then pick them up individually (POP from the stack). Typically, the stack is used to store the return address when a subroutine is called (JSR pushes current address onto the stack before jumping to the provided address, RTS then pops the address and JMPs to it to return from the subroutine). The stack can also store temporary variables. In higher-level languages, stack space can be used to store function-local variables. For Atari 2600 programming, you probably won't need to touch it. --- Hopefully that cleared some things up... Andrew Davie has probably explained this stuff better in his tutorials. If you don't have it already, you should probably grab a copy of the book: https://www.lulu.com/en/us/shop/andrew-davie/atari-2600-programming-for-newbies-revised-edition/paperback/product-1jq2q2wp.html?page=1&pageSize=4

Welp, I've made quite a bit of progress on the compiler/language I've been working on, but it's still a major work in progress. I consider this an unofficial preview alpha version. After development had stalled out sometime around July 2020, my focus shifted towards game projects... first Chaotic Grill, then Paint The City, with a some proof of concept work on a port of Congo Bongo, both for the 2600 and the 7800. My focus has been jumping between all of those projects until about April when my focus shifted back to developing the compiler... now dubbed Neolithic C. The compiler definitely needs a lot more work... mainly 16-bit integer support. Currently, there's only enough for supporting the minimal usage of pointers that I've needed. My recent focus has been on developing a way to manage local variable frames and better parameter passing support, and possibly moving away from "stack" operations. I've been on the fence about releasing the compiler prematurely... but with a few other heads popping up displaying other compilers/languages, I figured now would be a good time as any, as long as I don't make a big announcement (general forum post) about it. So I'm posting it here, and seeing what kind of feedback I get from those that actually dig thru/read the blogs. So... here's a basic demo of Congo Bongo written in Neolithic. It's at the point where I'd need to rewrite the display kernel in assembly to move beyond just having the explorer on the screen with the background. Note that the background is not being displayed correctly due to missing support in the compiler for data structure alignment (planned feature). Also, having the two score displays of debugging info pushes the scanline count beyond the usual 262 for NTSC. I've attached the BIN file as well as a zip file. The zip file contains the source code which includes the compiler with DASM (windows versions) if anyone wants to play around a bit. The code displays all the "available" features currently. If you do play around, I make no guarantees of good code generation if you write code that's more complicated than what is already there. Enjoy. congo.bin congo_src.zip

Interesting... Glancing at the language, it appears to be straddling the line between C and Basic. Probably not for me though. There's a few things that are off-putting to me... and I'm already knee deep in my own compiler/language development for the Atari 2600. BUT, I would still be interested in hearing more about your experiences with Millfork though.