I think I have now resolved the permissinos problem for new users (causing 404 errors on attachments). New users should now be correctly assigned to a user group with correct permissions, and I no longer need to do this manually.  Please let me know if you are unable to download!

Here are the title screens using the composite Interleaved ChronoColour + 6-sprite system...

As I understand how the new Atari 2600+ works, it essentially dumps a copy of the cartridge you plug into it, probably at startup/reset. Once it has a binary copy of the ROM in the cartridge, the binary is "run" by the inbuilt Stella emulator. At this point, the cartridge is probably dead weight - not needed as the Atari 2600+ has everything it needs to run the game.

This is all good and well, provided that "dumping" process works. If the binary is a faithful copy of the original cartridge's ROM, and the emulator correctly emulates that particular cartridge's bank-switching scheme (if any) - then for all intents and purposes the game should run as if it were an actual cartridge plugged into an actual Atari 2600.

But, and here's the rub... if that's how the Atari 2600+ works, then there are some real gotchas involved here.  Firstly, the "assumption" is that the dumping process works. It will definitely work for a lot of cartridges. But not all.  And very few "modern" cartridges. Why? Because there's a fundamental flaw in the concept of dumping a cartridge and then emulating the dumped ROM with a Stella variant inside the machine.

That flaw is the assumption that it is possible to dump the ROM in the first place. Modern cartridges such as nearly all of the high-end games from Champ Games, for example, use on-board hardware in the form of an ARM chip which actively interacts with the signals on the address and data bus on the cartridge port on the Atari 2600. This works because the Atari 2600 is actively "talking" to the cartridge port in real time, setting addresses on the address bus, and reading data on the data bus.  The ARM chip is monitoring the address and data bus and placing appropriate signals on the data bus in response to whatever the current "state" of the game/ROM might be. More specifically, many cartridges offer various bank-switching schemes where the ROM data is not readily accessible via any sort of "normal" dumping algorithm. You just do not see the ROM by asking for data at a particular memory address. Bank-switching is handled on-board the cartridge, and so dumping that cartridge needs intimate knowledge of the bank-switching scheme. And even with such knowledge, it is/will be incredibly difficult to dump a complete copy of many cartridges. And for some, impossible.

The concept of dumping a ROM and then emulating it presupposes that the ROM is "ready to go" on the cartridge, and that an attempt to dump via reading all ROM addresses will work. But all "software-based" multicarts do not have the ROM available until you select the ROM from an onscreen menu.  The PlusCart, the UnoCart are two examples - you can have many games selectable via menu, but until you select and start a game, it is not visible to the Atari (2600 OR 2600+). On an original Atari 2600, these "software multicarts" work by running a little menu program in RAM and then switching the selected ROM in via that.  The Atari 2600+, by reading the ROM contents at startup, does not appear to be able to work with cartridges that later switch in different ROMs.

It's a fundamental incompatibility as things currently stand.  I see it as a distinct difference between the Atari 2600 and the Atari 2600+ - the latter being an entirely different beast which is only able to run a subset of the hardware/games that the original can.  Yes, it can be updated but I do not know if it will be at all possible given the current methodology (dumping ROMs) for it to be able to run modern games with ARM-processors. In my view, to be Atari 2600 compatible and to be able to run ALL cartridges, you need to be *actively* talking to the cartridge. That is, writing addresses to the address bus and reading and writing data at the data bus. This way, you work with multi-carts, you work with ARM-based hardware on board the cartridge - in fact you work with everything.  It's a way forward, but pre-dumping is not, in my view, a credible solution in terms of 100% compatibility.

But maybe 100% compatibility is not the goal for the Atari 2600+.  It's an expectation that is being managed/tempered by the production of compatibility lists. There's no deception here - it is clearly stated that there are some cartridges/games which don't work with this machine.

So we now have a split in the "Atari 2600" community. There are the gazillion new people who are buying the Atari 2600+ and who will no doubt dig up their old cartridges and revel in the memories. Things will mostly work for them. And some of those will look at the newer homebrews and simply expect those to work compatibility lists or not. They will simply consider games that don't work with this new machine as "broken". Now who is going to "cop the blame" for this?  Should a seller of a homebrew game which works perfectly well on the Atari 2600 (original) have to give refunds to people who have purchased their game and find it doesn't work on the Atari 2600+?  Well, I'd say absolutely not. It's the machine itself which is incompatible, in terms of not being able to run all cartridges/games which the original machine can. The fact that it cannot run a particular newer cartridge is not a concern of the seller of that game - it should be Atari's concern.

But it won't be seen that way. I'm now sensing a split in the community and a dilution of the ability of developers to continue to create great modern games using new hardware developments on cartridges. Will we see continued interest from developers in pushing CDFJ games, for example - assuming these cannot be dumped by the Atari 2600+.  Maybe it can, and all will be OK. But I assume it cannot, in which case if there's a large demand from Atari 2600+ owners for new games, but only new games that run on the Atari 2600+ ... then that has created a division.  No longer are we developing for a shared, common, platform. We have those who will restrict themselves to what the Atari 2600+ is capable of running.

I see this as a big loss for the community. I would welcome a fully compatible console. One that could run anything and everything that the original could run - with HDMI to boot and support from Atari itself would be fantastic. But we don't have that. We have a hobbled system which is in my view muddying the waters. Already we have these half-baked lists of what games will and won't work; and those are not even correct... as a game that boots will not necessarily work.  I find the fact that the community is now building up a list of games that are compatible or not... incredibly sad.  Sad because this could have been a community win, a fully compatible machine and support for modern homebrewers. But instead I see it as creating division.

I started this Tiki quite some time ago, and it hasn't had much love. But it has some useful info in it. Feel free to modify/add content.

https://www.taswegian.com/WoodgrainWizard/tiki-index.php

You'll see in the blurb on the YouTube video I've had a bit of a bitch and moan about YouTube limiting my account because I use adblockers. Basically my view is that *I* choose when to look at ads, not other companies/people. Because YouTube don't want me to bypass their ads, they are preventing me watching videos. My thinking is that I'm a content provider for them, which they get to use for free... so I have no qualms about not watching ads they try to serve to me.
But it may mean I need to find a new host for my content because yeah, I'm not going to be held hostage to watching ads. This is not the internet I knew/grew up with.

Anyway, this version has a bit of work done on the particle system. Lots of action, almost too much. But it's fun just to clear out the screen and watch dots everywhere. One of the screens has the gravity switch (a sort of up-arrow block). If you hit that with the rope (or maybe with your man), the game will crash/reset. I'll get around to fixing that one day. Maybe.

WenHop - the Search for Planet X, Copyright (c)2023 Andrew Davie
Free for personal use. Must not be sold or redistributed.

This picture appeared in an unrelated group on my FB feed just now. Wow!  The text was "what would you do with these?"

The fuse, recently implemented, shortened and lengthened the "rope" as the fuse got shorter. That was pretty cool - see earlier video. I went back to the rope, but kept the lengthen shorten code - by accident, really - and adjusted the particle generation a bit. And now we have this just super-cool looking and incredibly fun/destructive weapon that lets you just decimate everything on the screen. It's actually quite fun, and that pulsing effect is way interesting; it doesn't look like rope or math at all anymore. Just some really weird superweapon. So neat.

This is a first attempt at representing a "fuse". I put a sort of sparkle (basically randomly generating particles) at the end of the rope, and decrease the length of the rope as it's animating. When it gets zero-size I reset it to full length. Interesting effect. A fuse, though, could be a very interesting/useful game mechanic. For bombs, for example

WenHop - the Search for Planet X, Copyright (c)2023 Andrew Davie
Free for personal use. Must not be sold or redistributed.

The rope and particle system are now separated. The rope is a "weapon" selected through double-click (menu) and then click again. It may be turned on/off via this seuqence. When the rope hits a rock it turns to geodoge, and a geodoge turns to a dogecoin. Dirt is vaporised.  Here you see a number of game components running together. There's a little slowdown happening, particularly when the screen gets super super busy. You may see a spiral of particles from the wyrms, from the rope hitting objects, and of course all the various actions that happen from the player.


This is a copyrighted work. Please do not redistribute the binary; linking to this site/page is the way to share my work. TY.

I like when it seems like YouTube is exclusively for WenHop...

Here's a first pass at some code to use the particle system for a rope object. Or a whip. Or an electical arc. Whatever. Basically grouping the particles together with a few parameters to adjust the position between each. Looks quite interesting.

More work on the particle system. I've added different 'behaviours' such as expanding from a center position at a given speed, rotating as that happens, bubble behaviour (move upwards, wobble as you do), implode, lava surface. spiral outwards, recursively generate.  Each basically moves a particle in a different way. In this video (with interleaved Chronocolour turned off, for a a change) you can see some of those in action. The wyrm is trailed by spiral particles, which in turn generate recursive spiral particles. That's the sort of spinning blob of particles you see occasionally.
Since this game is now unlikely to be published - that is, it's clearly not going to be an AtariAge project, and I really can't see doing it myself, it's now becoming just a fun testbed for me to play with graphics and behaviours - pushing the '2600 as far as I can but basically enjoying myself without any pressure. So I'm having fun, basically.

Back in 2003 I released a limited run of "special edition" Qb. This was in a custom wooden box (made at a sheltered workshop) with rare wood squares on the top (Huon Pine, Myrtle, Sassafras and Blackwood, from memory). I shipped most of these to the USA, but a number of them came back "return to sender" and I was unable to contact the buyers so I just kept them stored away.

The killer with this title was that I had a fatal crash/bug in the released version. I ended up manufacturing a fixed board, and offered to replace the original cartridges at my expense, OR, I could send just the fixed board and buyer could keep the original buggy version AND have the fixed board. Collectors being collectors, most opted for the fixed board and keep the original. This mitigated the loss I was making on this title, but still it cost me hundreds of dollars.

Some of the items still in my possession as shown are original boxes, a cartridge or two (buggy) and one or two of the fixed boards. The "return to sender" envelopes seen here are those where the buyer's address was incorrect; these envelopes remain unopened and should have replacement boards in them (fixed).

Qb is a 4K game and still holds up quite well today - in particular the playfield animation is quite complex and well done, even by today's standards. This was from the very early days of homebrew, and we didn't have the quality, professional boxes and manuals that we see today. It looks all rather amateurish now.

It's been a "hot second" since I did anything with Wen Hop. Today I felt a little "recovered" and had a play with the code.
Previously, the particle system had a whole bunch of variables - x and y position, x and y speed, and this was fine for straight-line movement. But I had this idea of "spiral" movement, and that old system really didn't work well with that. So I changed it to use a vector (angle), and a distance. The x,y pixel position is calculated from those, so now it's easy to rotate and move particles around an origin. The effect isn't quite what I hoped for, but it does work, so that's what this video is showing.  The spiral of particles as you do various things.


Please do not upload/republish this binary on other sites/forums.

What's this icon mean...?

I was thinking about ChronoColour and the effective 20Hz "shimmer" -- that is, changing colours in triplets at 60Hz --> a 20Hz cycle.  If the frame rate increased, then the shimmer would become less obvious. And then I realised I don't think I've seen much discussion about increasing the frame rate on NTSC. Of course we do PAL60, which is pretty much a standard. But what about (say) NTSC 66?  I wonder just how much we can go above 60Hz and still be compatible with most CRT NTSC TVs?

A couple of years ago I was working on my chess display, and wanted to put some text overlay on top of the asymmetric playfield. I did not manage to get this working - simply not enough processing time on the scanline to change 6 PF registers + 6 sprite shapes + 3 colour (PF, sprite 0, sprite 1).  However, I did manage to get it working if I used a mirrored playfield and dropped the left/right 4 pixels.

So, this is that - a 32-PF pixel asymmetric playfield with colour change on every scanline + an overlaid 6-sprite routine also with a colour change on every line.  I found only one horizontal position where this all worked perfectly, though I have not extensively tested to try other positions. The positioning is somewhat determined by the positions in which PF writes must be updated, and also of course the sprite graphics writes.  What you see here is a bit of luck; my first implementation did not work (sprites garbled), but the second - after a little bit of shuffling of the kernel - worked perfectly. 

Here's the kernel code...


                    ldx #%00110011
                    stx NUSIZ0                      ; three copies close, missile x8
                    stx NUSIZ1                      ; three copies close, missile x8
                    stx VDELP0                      ; vertical delay on
                    stx VDELP1                      ; vertical delay on

OverScanMenu

    ; axiom: D2 of X == 1

                    sta WSYNC
                    stx VBLANK              ; video output off (D2 of X is 1 always!)


                    ldx kernel
                    cpx currentKernel
                    beq thisKernel

                    jmp startAnyKernel
thisKernel


                    ldx tv_type
                    lda TimerOS,x
                    clc
                    adc #1
                    sta TIM64T              ; set timer for OS

                    lda #_DS_AUDV0
                    sta AUDV0
                    lda #_DS_AUDC0
                    sta AUDC0
                    lda #_DS_AUDF0
                    sta AUDF0

                    lda #_DS_AUDV0
                    sta AUDV1
                    lda #_DS_AUDC0
                    sta AUDC1
                    lda #_DS_AUDF0
                    sta AUDF1


    IF _ENABLE_ATARIVOX
        jsr speakJet
    ENDIF

                    ldy #_FN_MENU_OS
processArmOSMenu    jsr CallArmCode
                    ldy #_FN_MENU_IDLE
                    jsr CallArmCode
                    ;jsr safeTimerCheck
                    ;tmp bcs processArmOSMenu

safeTimerWait2      lda INTIM
                    bpl safeTimerWait2
                    ;jsr safeTimerWait


VerticalSyncMenu

                    ldy #2

                    ldx tv_type
                    lda TimerVB,x

                    sty WSYNC

; --- start scanline 1 of Vertical Sync ---

                    sty VSYNC           ; turn on Vertical Sync signal
                    sta TIM64T
                    sty WSYNC

; --- start scanline 2 of Vertical Sync ---

                    ; use otherwise wasted time to zero out some TIA registers

                    ldx #0              ; 2  2
                    stx PF0             ; 3 17
;                    stx CTRLPF          ; 3 26
                    stx WSYNC           ; 3 29/0

; --- start scanline 3 of Vertical Sync ---



    ; IF _ENABLE_ATARIVOX
    ;     jsr speakJet
    ; ENDIF


                    ldy #_FN_MENU_VB
                    stx WSYNC           ; end of VerticalSync scanline 3
                    stx VSYNC           ; turn off Vertical Sync signal
                    jsr CallArmCode

                    ldx #1
vbSetInitialMenu    lda #DSCOMM                 ; P1_X, P0_X

PosObject

    ; A = X position value
    ; X = 0=P0, 1=P1, 2=M0, 3=M1, 4=Ball

                    sec
                    sta WSYNC
DivideLoop          sbc #15
                    bcs DivideLoop

                    eor #7
                    asl
                    asl
                    asl
                    asl
                    sta.wx HMP0,X
                    sta RESP0,X

                    dex
                    bpl vbSetInitialMenu

                    lda #DSCOMM
                    sta tv_type                 ; _TV_TYPE = NTSC, PAL, PAL-60, SECAM
                    lda #DSCOMM
                    sta kernel
                    lda #DSCOMM
                    sta COLUBK

                    sta WSYNC
                    sta HMOVE




processArmVBMenu    ldy #_FN_MENU_IDLE
                    jsr CallArmCode
                    ;jsr safeTimerCheck
                    ;tmp bcs processArmVBMenu
                    ;jsr safeTimerWait
safeTimerWait3      lda INTIM
                    bpl safeTimerWait3


                    ldx #0
                    stx VBLANK              ; video output on
                    stx PF0

                    ldx #%00000001
                    stx CTRLPF              ; reflect PF

                    lda #_DS_COLUPF
                    sta COLUPF

                    sta WSYNC
    ;                sta WSYNC
                    jmp FASTJMP1


_MENU_KERNEL

;@3

                    lda #_DS_PF1_LEFT
                    sta PF1                         ; 5
                    lda #_DS_GRP0a
                    sta GRP0                        ; 5
                    lda #_DS_GRP1a
                    sta GRP1                        ; 5
                    lda #_DS_GRP0b
                    sta GRP0                        ; 5

                    lda #_DS_GRP1c                  ; 2
                    tay                             ; 2

                    lda #_DS_PF2_LEFT
                    sta PF2                         ; 5

                    lda #_DS_GRP0c                  ; 2
                    tax                             ; 2
                    lda #_DS_PF1_RIGHT
                    sta PF1                         ; 5
;@41
                    lda #_DS_PF2_RIGHT              ; 2
                    nop                             ; 2
                    sta PF2                         ; 3

                    lda #_DS_GRP1b                  ; 2
                    sta GRP1                        ; 3
                    stx GRP0                        ; 3
                    sty GRP1                        ; 3
                    sta GRP0                        ; 3

;@62

                    lda #_DS_COLUP0                 ; 2
                    sta COLUP0                      ; 3
                    sta.w COLUP1                    ; 4

                    lda #_DS_COLUPF                 ; 2
                    sta COLUPF                      ; 3
;@76=0

                    jmp FASTJMP1                    ; 3

;@3--> start of line again :)


_EXIT_MENU_KERNEL

                    ldx #2
                    stx VBLANK
                    ldy #0
                    sty PF1
                    sty PF2

                    jmp OverScanMenu

; EOF

As you can see, it's CDFJ-centric, using data streams to retrieve graphics data rapidly.  The "magic" starts at the label _MENU_KERNEL.

I'm happy for others to use this idea/code. A simple acknowledgement if you use my code would be all I'd expect.

Here's a screenshot of it in action - you see the menu text right-of-center. In reality, this is a vertical strip of 6 sprites occupying the entire screen height, so you can put graphics/text there to your heart's content.

Full source code for WenHop is available at Github WenHop Repository - released under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license..

I'm very lenient with regard to sharing my code/creations. I do require attribution and respect of my IP. I am very happy to help you understand this project. You will have a fair bit of effort required to get this building (tool installation, etc).

I made the font size in code blocks a bit smaller.
Let me know if this doesn't work for you on your setup.

Woodgrain Wizard Tiki

I worked a bit on this a while back, and haven't promoted it too much. I'd like to see it become a central store of technical information about '2600 programming, and I invite you all to contribute.