ScumSoft

And then there was that one bug, where it seemed like it was transmitting data but things just didn't work properly. You'll spend the next week trying to hunt down the issue only to discover there was a bad solder point on IO pin 37 140 wires...I certainly hope it just works

Been a long while since I touched bB, but I think we needed to divide the players X position by 5 to get the playfield X offsets.

It is beyond simple to learn the 6502's ASM. It really really is! You only need to know two instructions to do everything really, but only knowing two wont lead to very elegent code. LDA #$xx STA #$xx xx is any hex value between 00 and FF If you look at VCS.h for the DASM VCS compiler includes it has a table of names assigned to hex values. So if you want to store hex FF into the color for player 0 and AA into the graphics of player 0 you would do this: ;Semicolon is used for comments in DASM and are discarded during compile time LDA #$FF ;This says LoaD Accumulator with a hex value, hex is declared with #$ regular 0-255 uses just the hash LDA #255 like so STA COLUP0 ;STore whats in the Accumulator into COLoUr Player 0, in this case 255 or FF, will go into the player0s color LDA #$AA ;LoaD the Accumulator with hex value AA STA GRP0 ;Store this value into GRaPhics of Player 0 That is all you need to make the VCS do stuff, but if you want things more fancy and in sync with the TV you will need to know how to repeat code parts with branching: ;Place a starting counter outside the loop above the label LDY #192 ;LDY will load the Y register, LDX loads the X register, and LDA is for loading values into the Accumulator Loop: ;Simple labels use a colon to say hey mark the address here so code can jump over to me when needed STA WSYNC ;Store anything into WSYNC will make the VCS wait until the scanline is finished STY COLUBK ;Store something into the background color, in this case its the current value in the Y register DEY ;Y and X registers can be incremented by 1 or decremented by 1, this is DEcrement Y BNE Loop ;Branch if Not Equal says if whatever instruction was done last made the value zero then let them pass to the instructions below, otherwise we need to jump to Loop label and do this again Now its just a matter of figuring out what you want to stick into the VCS addresses and placing values into them at the proper times. You can do alot with only a small bit of code, the 6502 is very simple and easy to learn.

I had stopped working on everything when school started up back in Jan this year and didn't touch it again till last week when I cleaned out my closet The bus stuffing isn't interrupt driven only the "Hey A12 went high I better go service the FIQ routine now" is, this way the ARM can be crunching C code getting everything ready for the bitmap output stuffing. The actual stuffing happens while in the FIQ, I am currently working out the logic required at this point, but I should be able to make use of the three timers in the ARM for gating the values on the bus we want. I already have a working kernel I wrote for the regular DPC+ core, but it repurposes all the datafetchers and more to display my bitmap output. 2016 will be a great year for more complex games.

Before my hiatus here, I was writing a new Harmony core centering around bus stuffing for bitmap displays. Fred's default core polls A12 for rom access then decodes the address and figures out what the VCS wants from it. This is why 70% of the ARM is busy feeding the bus and not so free to do other stuff. I figured it should have been interrupt driven instead of polled so I got the source, the schematics and saw that we could use an FIQ on A12 and set it to trigger on the rising edge. I did this all in C and optimized it as best I could. It didn't work because there were a few configuration errors I didn't catch last time. I revisited my project a week ago and got it working properly, so now all of the ARM cycles are free to do other things while not servicing A12 requests. I still have to implement my stuffing kernel and setup a few things but the hard part is over. Now you can focus on programming games in C and let the FIQ handle all the updates the VCS is requesting. I've chosen to load a display kernel ran from RIOT ram and have key A12 requests trigger the bus stuffing sequence all timed from the ARM. So far the core is only 600bytes big and all of the 8kSRAM is free for display output bitmapping. I also plan to implement the ability to stream in data off the SDcards for larger games. College is keeping me really busy this year, so I'm only dabbling on the code a few hours a week at the moment, but it's looking pretty promising so far. Though I'm sure ZackAttacks implementation is a much beefier solution than the LPC2103 in the Harmony.

Hello again it's been a while, nice to see your project coming along nicely. Did you modify the Stella source to allow for single cycle bus stuffing?

Eggventure was done in batari basic and used RevEng's titlescreen bitmap framework, I didn't do it from scratch. What I did at the time of that spritetest demo was rediscover flicker blinds in column flicker mode. The way it was coded doesn't leave much time to do other things in an actual gameplay. So I moved onto DPC+ for the extra umpf, however I didn't like the setup the stock framework has so I started recoding a new framework that focused on Bitmap engines and routines to augment such. I modified an older version of Stella to prototype the DPC+ changes that needed to happen since the Harmonys new core wasn't written yet. I'll look through my coding backup and see how far I got on the actual project, I don't recall at the moment where I left off on it. [edit]Looks like I left off coding the Harmonys new core using Keil. I was working out the cycle exact timing involved to have the 2600 run a display stub kernel from internal ram and have the ARM stuff the game display onto the bus during this time. Polling of A12 would occur only during certain windows to ensure we stayed synced up rather than all the time thus freeing up the ARM for pure C coded games.

[EDIT] Thank you all so VERY much for the offers, I think with the items that have sold now, things should be okay for me. This way I don't have to part with anymore of my history

Many thanks! Here's one I forgot. q) How much time do we have after initial power on before rom is first requested?

[ROM ACCESS] 1) When the Atari wants rom data, it sets the A12 line high to read from the higher address space correct? 2) Does it ever flip A12 high for other things? 3) How long will it allow A12 to remain high with no data before the data valid window expires? 4) If the data valid window expires what state does the Atari end up in? 5) Once valid data is retrieved does the A12 line remain high if the instruction doesn't have the VCS access a lower address space? such as INY, JMP, ect... [DISPLAY] 6) What is the currently achieved copy limit of the RESP0/1 trick? ignoring any alignment issues. 7) What is the max amount of player copies you could get had you sent RESP0/1 directly to the TIA? (bypassing the 6507)

missing a sta WSYNC at the beginning of drawscreen?

Thanks for the PM, got the info I needed. I cannot edit the original post nor delete the topic.

I don't want to open my harmony to see, but does someone know the VCS to LPC2103 pinout? To clarify, which pins the LPC2103 has directly connected to the cart slot.

What would you estimate the sprite count to be, per sprite heavy homebrews? Do you think a tile_map count of 144 (8x8 tiles) would suffice for most games?

Sadness, Repairable?

Robotniks Gameboy anyone? 00:45 for reference.

Much sadness!!!

A few years ago when I was learning to write display kernels, I did a Flickerblinds vs ColumnFlicker test. decided Flickerblinds looked better on CRT's and ColumnFlicker looked better on LCD's I've attached the ROM (DPC+), use the BW/COLOR switch to toggle between FB and CF FBvsCF.bin

Reminds me of N

I am certain if he took the time to cut out the sdk fat and code at "the bare metal" level on that platform, it's code size would be very tiny.

Atari = The We'resari. Sega = Xbox 1 (original, not "one" but 1 as in first damn you micro$.. for confusing everyone) was in many ways the "DreamCast2". http://kotaku.com/5859934/the-xbox-was-as-close-as-we-got-to-a-dreamcast-2

Or he could have watched one of the other talks available (like the vids I linked to) and got his info correct. It was rather painful to watch, he seems very unsure and misinformed.

There are certain things which are proprietary to the functions of the Harmony which shouldn't be openly shared. Or sample code which might prove dangerous to use except in certain circumstances for devs, like bus stuffing. I don't want to post a bus stuffing kernel I wrote which might smoke other VCS models/Harmony revisions. Getting source code to the Encore bootloader to adapt this project, ect should not be public.(yet) So there are great reasons to have a special dev only forum, and I "need" some red key card access.