Dave C

Aha, very cool! I was hoping there would be some techniques like that.

So - was wondering about possible techniques for a game to detect *which* hardware it might be running on. Example: checking for random vs non random values on certain read addresses, etc. I’m not thinking about this in terms of trying to detect if you are running under emulation, thinking about this in terms of games that break the fourth wall by incorporating aspects of the player’s system external to the game itself (if you have ever played Metal Gear Solid games there’s situations where the contents of your save files gets discussed, intentional glitching, asking you to switch controller ports mid boss battle)

Sorry I couldn't make the meetup but was able to drive down last minute from Seattle for Sunday, AtariAge booth was definitely a highlight, cool and fun seeing all the games there (it's not weird to lurk the Atari Age booth... right?)

So... I've been working on some way to get music into my current project (Refhraktor) and went on a little side trip into furnace... Attached is a ROM dumped from a Skate or Die demo track (for the record I'm calling my modified version "Hmove or Die" - definitely shows some TIA artifacting (or maybe it's my process - or maybe I should have picked something simpler...)) Notes: currently it just produces track data via command line (not integrated in the GUI) - not a playable rom A POC for player code (reads track data as an include) can be found in the attached archive one advantage size-wise - it's not doing a straight register dump - instead it attempts to replay the song in pattern form using tactical samples of register-dumped data Dead certain I'm missing a lot of details around how timing / effects / etc are supposed to really work. Also likely some general lack of safety in the extraction code - it will likely crash on songs that aren't extremely simple... if anyone is interested in trying this out the source branch is here: https://github.com/DChristianson/furnace/tree/dbc-tia-rom-builder r9demo.zip r9.a26

So... I've been working on some way to get music into my current project (Refhraktor) and went on a little side trip into furnace... starting a new topic here;

Very cool!

In case it helps anybody out I made myself a F8 banks switching + Superchip demo kernel modified from @Thomas Jentzsch's Atari Bank Switching for Dummies. it just flips back and forth between banks as you press the fire button using colors that were 'drawn' into SC ram, with slightly different display kernel in each bank. It also has SUPERCHIP_READ and SUPERCHIP_WRITE constants a la @Bruce-Robert Pocock's method. kernel in bank 0: kernel in bank 1: poc-banks-sc.asm bank_switch_f8.h

Ok cool, I wasn't clear on the fabrication options, if there were any serious challenges - but Melody seems like the ideal platform. thanks for the tips - that READ/WRITE constants makes sense Yeah so let me unravel my train of thought - I am actually low on zero page RAM due to using a big chunk of it to hold graphics data, and it would help to offload some of it to SC RAM. And then potentially thinking about loading graphics from one bank into RAM for use by kernel in another (vs keeping a copy of the kernel in the same bank)

Thanks for the input! I’m definitely looking for maximum cross compatibility as number one - specifically Javatari has been helpful to get play testers. So I understand that rules out some schemes. My POC fits into 4K but I’ve started doing some experiments with F8 to prove out more or less the same kernel but with some menus, audio, a little more level data… …which has also got me playing around with the idea of having a dynamic, destructable playfield and RAM would give me some breathing room on that score, and maybe also give me a way to pass data between banks. But.. I don’t see as much discussion going on about RAM and the list of classic games using RAM seems shorter…

agree lda DATA,y should not wrap around. I checked myself (dasm + Stella) by forcing the data to be on a page boundary: ldy #1 lda DATA_PAGE_END,y ; should be $02 from $f300, not $03 from $f200 ORG $f200 ; (or wherever) byte $03 ORG $f2ff ; (or wherever) DATA_PAGE_END byte $01 byte $02

I am looking at implementing bank switching for my Refhraktor project and wondering - for modern homebrew is there any preference for one scheme or the other? In case future forum members hit this post looking for bank switching advice, here's where I've been ramping up: http://www.taswegian.com/WoodgrainWizard/tiki-index.php?page=Bank-Switching

Catching up on various project progress - modest update - working with kid_snz, put in improved obstacle placement, better use of M Sohl's sounds as well as ability to restart from game over pizza-boy-20220724.bin pizza-boy-20220724.zip

These are helpful! Does the fuzziness happen - in emulator or real hardware? That's one I'm not sure I know (or maybe I'm worse at button mashing than I thought) The sticking and scoring I've seen but thought I had eliminated. The fact that it's happening a lot on on the sides is interesting - it's one place I thought I had collisions working right, since the code works off of knowing for sure when you hit the extreme left/right boundaries there versus doing weird guesswork with the collision registers. The scanlines and black bars I'm pretty sure I know the problems and can fix the bulk of them in the next pass - long story short there's a lot of kernel code that needs to find clean page boundaries to avoid timing problems - and a little bit I didn't cycle count at all (which I admit is shameful). - I already decided I'm not going to kill myself trying to keep this game <= ??K so I'm planning the next pass to be a refactor to add bank switching (my first foray into >4K outside of bB) and hopefully get those clean page boundaries back (we'll see).. - Wrt the black bars I have been thinking of just giving up on them and having a black background all over the screen - the bars were kind of a graphical experiment but I don't feel they add much other than being a cycle counting flex (maybe better to get those cycles back and use them for better things)

@KevKelley you mean use players to draw the bars? interesting. like - really tall players that actually draw the lines? That looks like it would work for this game since the rails don't have to be too far apart (or make anything nearly like a 45deg angle)

Agree it's not realistic - at best lot of work for limited ability... I think playfield has to be the natural choice for bB. Long story I spent some time messing with custom kernels working on Pizza Boy - very helpful for learning Atari assembly techniques but steep cost otherwise... - Your best chance with bB is if you are using a bB kernel that only has missile 0 and 1 - that means it probably only uses the hardware missiles and only sets the position before the screen starts - That kernel would have to be modified to leave the missile on over some number of scan lines - which might not be too hard - The limitations go down the horizontal shift rabbit hole: - You'd need to have a way to feed in horizontal shifts at the right time - OR - use the same shift every line (think 45 deg angle only) - But... the kernel can't be doing any thing funky with HMOVE pulse or you start to get limited to shift in specific directions only - And... the bB kernels I have looked at definitely all did funky HMOVE pulses - And... changing from early pulse to on time pulse is tantamount to rewriting everything @Fort Apocalypse I think I can see why you were looking at the Refhraktor POC I just dropped - FWIW I totally went down the Fishing Derby / Missile Command study route - and still want to go back and study some more.

UPDATE 20220722 : - three "levels" with different obstacles (or no obstacles) - selectable only with select switch during gameplay - still no menu system - select switch = no couch compatible seal of approval (sad face emoji) - scan lines glitch fixes - a few new glitches (long story short - a few page boundary timing bugs that I couldn't solve quickly)

Thanks! I know the math is still off for both lasers and ball movement but I particularly haven't tested high speed, and pressing the laser a lot having an effect on the path is one I haven't seen

Thanks! I’ll see if I can make a few bug fixes by then. It started out as drawing fishing lines by way of making some sort of fishing game… then went sideways.

Early WIP for a two player pinball-style game inspired by games like Ballistix (Amiga), Shufflepuck Cafe (various platforms).. and a little bit of Laser Blast Javatari Link: PLAY ON JAVATARI! Github Site: https://github.com/DChristianson/refhraktor The game: - player has a laser they can use to shoot at a reflective ball and try to knock it into the opposing goal - the playfield is larger than the screen and scrolls up/down to track the ball movement - the lasers are imagined as sitting on a gantry above the playfield so they are always at the top and bottom of the screen - laser beams automatically track towards the ball based on relative position UPDATE 20221232: - the game now utilizes a 16kb ROM with 128 bytes ram (f6 + superchip) - a lot of experimentation, culminating in a couple of simple changes - all players are effectively on autofire now - mashing the button has no benefit - each player has a power reserve that replenishes over time - behind the scenes the beams can have different physical and visual effects based on range and equipment type - a few different ship types - two kinds of saucers, the maser tank, and the drone (AI) - the maser tank projects a short range beam that acts as a shield - all the other ships play the same just with visual differences - still no score but there is a timer that ends the game after a set period of time - still no sound except for a chime that starts to play when the game clock starts to run out - just a few levels still UPDATE 20220722: - three "levels" with different obstacles (or no obstacles) - selectable only with select switch during gameplay - still no menu system - select switch = no couch compatible seal of approval (sad face emoji) - scan lines glitch fixes - a few new glitches (long story short - a few page boundary timing bugs that I couldn't solve quickly) refhraktor_NTSC_20221231.bin refhraktor_PAL60_20221231.bin

After a bit of a break I've made some tuneups - integrated MSohl's honk sounds more closely and tried to generally clean up the other sounds - I have added barriers - only one can appear at once and can either be the tree, cones or a barricade - placement is driven by data table - def needs tuning - more code annotations pizza-boy-20220515.bin pizza-boy-20220515.zip

The inside portion adds a whole other dimension. I really like the way the elevators work. Trying to time jumps over the ball makes me think of Keystone Kapers also. I don't have anything to show right now but I spent some time last weekend doing a poc on adding a few more sprites, I'm going to make a push on that this weekend.

My mistake - I added a new file that didn't get included in the zip - pizza_title.asm - that has the title graphics. And the $ sign is in score_graphics.asm but if that one is missing bB has its own version (with no $) it will use if a custom one isn't available. To edit the background graphics you can do it in the file, or... if you have an Atari Background Builder .asm (repeated, asymmetric, 4 pixels x 44 rows) you will see at the end 6 data sections PF0DataA | PF1DataA | PF2DataA | PF0DataB | PF1DataB | PF2DataB You can copy them into pizza_title.asm but they need to be renamed with a T: TPF0DataA | TPF1DataA | TPF2DataA | TPF0DataB | TPF1DataB | TPF2DataB I'm attaching the updated zip - it's got everything (including the $ sign) pizza-boy-20220215.zip

Frame+1, Scan+1, Step+1 and Debug Colors are my friends - debug colors lets you see how playfield/sprites are being used, going through the scan lines is more something I do to debug low level problems. It is hard to see from Stella how the Basic is executing though, since it all gets converted to Assembly.

Made a few updates added a title screen kernel (can use atari background builder data, asymmetric repeated, 4 line kernel, 44 rows) score/life colors replaced building collision - should be smoother now pizza-boy-20220213.bin pizza-boy-20220213.zip

Yes, how could I forget about those Radio Shack books. https://archive.org/details/Basic_Computer_Games_1978_David_Ahl/ I don't think these are going to translate easily to programming for the Atari 2600. Although now I'm thinking about how to do Zork.