Use ARM to change ROM for super KERNAL? (Per scanline)

[Ecernosoft]

Hello!

I was wondering if a special area of ROM (Like 128 bytes) could be changed per scanline by read/writing to a specific register to set the scanline counter to 0 and then another to "Increment it" and then have registers for stuff.

 

Using this method lots of things are posible (1 scanline kernal with many different sprites, multicolor AND using Hmove and it's registers to do per-scanline offset stuff). 

 

I was wondering if this could work. It could possibly also work for the 7800 by changing GFX ROM on the fly.

[Astal4]

You cannot do this as the Atari 2600 does not have any clock output to the cartridge, it is impossible to synchronize it without manual clock bit banging from the CPU.

 

Edit: this can be done with RAM though, which my new cartridge has 32 128 byte banks.

Edited October 16, 2022 by Astal4

[Ecernosoft]

Just now, Astal4 said:

You cannot do this as the Atari 2600 does not have any clock output to the cartridge, it is impossible to synchronize it without manual clock bit banging from the CPU.

Oh... How unfortunate.

 

Not even with writing to this register, having the arm wait some, and then having a NOP or two that dosen't change for the ARM to update the "Rom" ?

[Astal4]

Check the edit, you could do this with RAM and moving around the data with CPU I'd think. If I'm understanding properly, but you can't automatically do it by detecting a TIA cycle or anything.

 

Edit 2: Unless you mean mid-scanline, that would cause data corruption.

Edited October 16, 2022 by Astal4

[Ecernosoft]

Just now, Astal4 said:

Check the edit, you could do this with RAM and moving around the data with CPU I'd think. If I'm understanding properly, but you can't automatically do it by detecting a TIA cycle or anything.

Not by checking a specific TIA cycle, but starting the edit when a certain memory adress is "looked" at. (Read from or written to)

[+splendidnut]

Sounds like you might want to check out Spiceware's DPC+ demo:

 

 

[Ecernosoft]

15 minutes ago, splendidnut said:

Sounds like you might want to check out Spiceware's DPC+ demo:

 

 

Hmmm..... i already saw that. But it's been a while,  so i'll see it again!

[Mr SQL]

Great idea!  The current method to stuff the RIOT RAM with the ARM has the 6502 sending NOP's in the vertical blanks when the ARM is active. 

 

Therefore an every other scanline method could be implemented to do this on the scanlines too by leveraging four horizontal blanks and an entire scanline similarly while the 6502 nops:

 

Breakout2000 has an "every other scanline" two line kernel design, that would be ideal for this as it turns off the playfield registers every other scanline allowing for three horizontal blanking periods and a scanline worth of cycles, which is enough time to do cool stuff in the horizontal blanks even without the ARM.  

The design is from Scrollout which also featured an "every other frame" design complementary to the "every other scanline" kernel design for expanding the CPU time available between frames. 

 

ARM developers may find the scanline based version of this technique equally applicable and inspiring for extending horizontal blanking time for greater ARM enhanced games!

 

Edited October 16, 2022 by Mr SQL
horizontal blanks

[Ecernosoft]

1 hour ago, Mr SQL said:

Great idea!  The current method to stuff the RIOT RAM with the ARM has the 6502 sending NOP's in the vertical blanks when the ARM is active. 

 

Therefore an every other scanline method could be implemented to do this on the scanlines too by leveraging four horizontal blanks and an entire scanline similarly while the 6502 nops:

 

Breakout2000 has an "every other scanline" two line kernel design, that would be ideal for this as it turns off the playfield registers every other scanline allowing for three horizontal blanking periods and a scanline worth of cycles, which is enough time to do cool stuff in the horizontal blanks even without the ARM.  

The design is from Scrollout which also featured an "every other frame" design complementary to the "every other scanline" kernel design for expanding the CPU time available between frames. 

 

ARM developers may find the scanline based version of this technique equally applicable and inspiring for extending horizontal blanking time for greater ARM enhanced games!

 

See?

You could also have SPECIAL stuff like HMOVE offset and Scaling.

 

A simpler way to do it was lda #something sta ???? a number of times and then jmp to the KERNAL unless the end of the screen approaches.

I can write an example kernal to do my idea if it were to work. 

Edit: It would look something like this:

Superkernal

lda P0gfx

sta GRP0

lda M0gfx

sta ENAM0

lda M1gfx

sta ENAM1

lda P0col

sta COLUP0

lda P1col

sta COLUP1

lda BKcol

sta COLUBK

lda FGcol

sta COLUPF

lda PF0gfx

sta PF0

lda P1gfx; Do this later since P1 and the ball have VDELP1 and VDELBL respectively.

sta GRP1

 

lda BLgfx

sta ENABL

lda PF1gfx

sta PF1

lda PF2gfx

sta PF2

sta WSYNC

jmp Superkernal; This would be overwritten with 3 NOPs when  the Kernal ended

 

Edit 2: You could also change this for an Asymetrical playfeild and/or having the missiles and ball be able to have a different offset per scanline for diagonal lines!

There's infinite possibilities.

 

Edited October 16, 2022 by Ecernosoft

[+splendidnut]

2 hours ago, Mr SQL said:

The current method to stuff the RIOT RAM with the ARM has the 6502 sending NOP's in the vertical blanks when the ARM is active.

I don't think ANY of the ARM-based games stuff the RIOT RAM.  When the ARM is executing user-provided code, the data bus just idles with a NOP on it for when the 6507 attempts to read the ROM area.  You could argue that it is "stuffing" the data bus, but really it's just emulating a ROM filled with NOPs. It is definitely NOT stuffing them into RAM.  I'm not sure where you got that idea from.

[+splendidnut]

@Ecernosoft Your Superkernel idea is basically how the DPC+ / CDFJ display kernels work.  I figured that's what you were looking for and is why I suggested @SpiceWare's DPC+ Demo.

 

There are other ways if you want to avoid ARM-based hardware that you might be interested in.  One of which is the original DPC scheme (8k ROM with 2k Display RAM accessed via LDA abs/STA tia_reg - 7-cycles).  You can't do as much on a scanline, but it does do alleviate some of headaches of working with sprites.

 

The Supercharger scheme would be something to look into too.  6K RAM (3 banks of 2K) that are relatively easy to write to (just a little tricky)... AND you'd have to write self-modifying, but that would give you something similar to DPC.

 

It all depends on the compromises you want to make.

[Ecernosoft]

3 minutes ago, splendidnut said:

@Ecernosoft Your Superkernel idea is basically how the DPC+ / CDFJ display kernels work.  I figured that's what you were looking for and is why I suggested Spiceware's DPC+ Demo.

 

There are other ways if you want to avoid ARM-based hardware that you might be interested in.  One of which is the original DPC scheme (8k ROM with 2k Display RAM accessed via LDA abs/STA tia_reg - 7-cycles).  You can't do as much on a scanline, but it does do alleviate some of headaches of working with sprites.

 

The Supercharger scheme would be something to look into too.  6K RAM (3 banks of 2K) that are relatively easy to write to (just a little tricky)... AND you'd have to write self-modifying, but that would give you something similar to DPC.

 

It all depends on the compromises you want to make.

Supercharger could be a good idea..

Using the second 2K bank, you could have tall, 192 byte buffers for 'Sprites'.

Might use that for ICT3. (And then the cart version would just have 2K of RAM)

And really, it would be 384 byte buffers since the color info too.

I'd still be using a 2 scanline kernal though, so it would be 192 byte buffers anyway.

Edited October 16, 2022 by Ecernosoft

[+SpiceWare]

1 hour ago, splendidnut said:

I don't think ANY of the ARM-based games stuff the RIOT RAM.

 

Early versions of BUS stuffing supported it, from an early bus.h:

; Note: The same maps are used to BUS Stuff RAM addresses $80-$AF 
;       recommended to use TIA registers that you wouldn't normally BUS Stuff
;       $80 = VSYNC
;       $81 = VBLANK
;       $82 = WSYNC
;       $83 = RSYNC
;       $A8 = RESMP0
;       $A9 = RESMP1
;       $AA = HMOVE
;       $AB = HMCLR
;       $AC = CXCLR
;       $AD = $2D
;       $AE = $2E
;       $AF = $2F

 

 

It was intended for flow-control during the kernel, the STY ZP instructions are bus stuffed:

 

        sty NextKernel      ; 3 23 DS1 - RAM $80, uses same fetcher lookup entry as VSYNC
        sty NextKernel+1    ; 3 26 DS1 - RAM $81, uses same fetcher lookup entry as VBLANK
...
        jmp (NextKernel)    ; 5

 

 

That was later replaced by @ZackAttack's Fast Jump idea, which saves 8 cycles per scanline. Fast Jump ended up in CDFJ as well.

 

FASTJUMP = 0

...

        jmp FASTJUMP    ; 3

 

 

Looking at the BUS driver source it still supports bus stuffing RAM, though the address range has been reduced to $80-$A4:

/*********************** STY Bus Stuffing Handler ****************************/

  /* Fetch next byte */
  add     r3, r1, #1                    /* Next address */
  ldrb    r4, [r3, +r8]                 /* Next byte */
  
  /* Get fetcher address */
  and     r13, r4, #0x7F                /* Map $80 (RIOT RAM) to same space */
  cmp     r13, #0x25                    /* Only 0x00 through 0x24 */

 

 

[+splendidnut]

Ah, that's a piece of the bus-stuffing history that I did not know about.

 

But was it used / or is it currently used in any of the ARM-based games that are available?

 

[+SpiceWare]

9 minutes ago, splendidnut said:

But was it used / or is it currently used in any of the ARM-based games that are available?

I used it in test ROMs while we were developing BUS Stuffing, though I don't think any of those were released outside of the Harmony/Melody development group.

 

DPC+ and CDF[J] drivers never did bus stuffing, so none of the released games could have used it.

[Ecernosoft]

3 minutes ago, SpiceWare said:

I used it in test ROMs while we were developing BUS Stuffing, though I don't think any of those were released outside of the Harmony/Melody development group.

 

DPC+ and CDF[J] drivers never did bus stuffing, so none of the released games could have used it.

And plus, why would you want to?

If you want you're kernal in RAM, then just use (I forgot the name, but Atari used this bank switching scheme a lot and it gave 128 more bytes of RAM) or Supercharger, or RAM+, or......

[Mr SQL]

11 hours ago, Ecernosoft said:

And plus, why would you want to?

If you want you're kernal in RAM, then just use (I forgot the name, but Atari used this bank switching scheme a lot and it gave 128 more bytes of RAM) or Supercharger, or RAM+, or......

 

13 hours ago, splendidnut said:

I don't think ANY of the ARM-based games stuff the RIOT RAM.  When the ARM is executing user-provided code, the data bus just idles with a NOP on it for when the 6507 attempts to read the ROM area.  You could argue that it is "stuffing" the data bus, but really it's just emulating a ROM filled with NOPs. It is definitely NOT stuffing them into RAM.  I'm not sure where you got that idea from.

 

Great questions! Scrollout was designed with a soft blitter chip that uses double buffering:

 

I used double buffering in the soft blitter design to stuff not just the registers between frames, but also a 60 byte display buffer in RIOT RAM (for the playfield camera) and a 240 byte virtual world buffer either in CBS RAM or SuperCharger RAM:

 

 

 

 

Per the Scrollout thread I got the inspiration to create the soft blitter from seeing Boulderdash.

 

Because their display kernel runs on the 6502, ARM games that do a lot of graphics manipulation look like they would similarly have to support double buffering by updating RIOT RAM and/or SuperChip RAM with the ARM chip while in the vertical blank in order to prepare it for the kernel.

 

It was described that once the data is prepared the 6502 display kernel could still run without the ARM present and would display a static image. The soft blitter design works similarly and can be disengaged leaving a static image for the display kernel. 

 

From that description it seems like they must work similarly. I'm curious if they do not, Boulderdash has an ingenious 100 kernel array in leau of a blitter so perhaps another method could be to rewrite the display kernel on the fly using the ARM to create dynamic multi-kernels.

 

[+splendidnut]

48 minutes ago, Mr SQL said:

Because their display kernel runs on the 6502, ARM games that do a lot of graphics manipulation look like they would similarly have to support double buffering by updating RIOT RAM and/or SuperChip RAM with the ARM chip while in the vertical blank in order to prepare it for the kernel.

Double buffering (graphics data buffers) is typically done in ARM RAM (emulating and expanding upon the Display Data area in the original DPC Ptifall 2 scheme).  That data is read via memory mapped registers (data fetchers) which auto-increment.  They can either be read from the cartridge region (LDA abs) or thru the fast fetch capability (LDA #).  Nowhere in that process involves stuffing RIOT RAM with data.

 

I would highly recommend you investigate this yourself by trying to use the ARM-based schemes for your own fun experiments.

[Mr SQL]

4 hours ago, splendidnut said:

Double buffering (graphics data buffers) is typically done in ARM RAM (emulating and expanding upon the Display Data area in the original DPC Ptifall 2 scheme).  That data is read via memory mapped registers (data fetchers) which auto-increment.  They can either be read from the cartridge region (LDA abs) or thru the fast fetch capability (LDA #).  Nowhere in that process involves stuffing RIOT RAM with data.

 

I would highly recommend you investigate this yourself by trying to use the ARM-based schemes for your own fun experiments.

 

Thank you spendidnut that is a very clear explanation.  

 

I think the original DPC spec worked better for sound than graphics co-processing because unless index registers are also surfaced on those data registers the gameloop would need to be on the ARM to index the graphics buffers for any additional processing.  

 

I found the quote I read about being able to disconnect the ARM chip yet still display a graphical screen from an ARM game; it would require hard coding to get the ARM data stream for the graphics into a buffer the 6502 could read on it's own:

 

 

Per the thread discussion by updating graphics RAM buffers on the 2600 directly instead of streaming graphics buffer data from ARM registers the 2600 could be made less of an I/O device and more of an active co-processor for enhanced games.

 

[+splendidnut]

20 minutes ago, Mr SQL said:

I think the original DPC spec worked better for sound than graphics co-processing because unless index registers are also surfaced on those data registers the gameloop would need to be on the ARM to index the graphics buffers for any additional processing. 

ChaoticGrill runs all the game code, generates the graphics, and loads the graphics data into the DPC+ RAM using only the 6507.  It does not need nor use a gameloop running on the ARM.  It's probably the only example (outside the DPC+ Demo I linked above) that does it this way... but it is indeed doable.

 

29 minutes ago, Mr SQL said:

I found the quote I read about being able to disconnect the ARM chip yet still display a graphical screen from an ARM game; it would require hard coding to get the ARM data stream for the graphics into a buffer the 6502 could read on it's own:

Yup, a hard coded kernel would be necessary.

 

31 minutes ago, Mr SQL said:

Per the thread discussion by updating graphics RAM buffers on the 2600 directly instead of streaming graphics buffer data from ARM registers the 2600 could be made less of an I/O device and more of an active co-processor for enhanced games.

Not sure why you'd want to do this as 128 bytes of RIOT ram is not a lot of room for graphics.  If you're heading down that route, you're better off sticking to one of the original schemes (like one of your favorites, the Supercharger).

 

---

Here's where I'm going to start off relatively sane, and then get a bit ridiculous... you have been warned:

 

At the end of the day, I'm sorry to tell you, but ultimately your 2600 is mainly an I/O device.  Your controllers are the Input, and the sound and graphics on your TV is the Output.  The 6507 spends most of it's time LDA-ing and STA-ing just to deliver a gaming experience to you.

 

Regardless of what's running, when the system is on, the 6507 is always running, as are the TIA and the RIOT chips... If you're uncomfortable with how you think ARM games turn your system into "just an I/O device", I'd hate to break it to you, but your "modern" computer probably suffers this WAY more.  You can ultimately solve this calamity by giving away all your electronics and becoming a hermit in the woods.

 

---

 

I personally like both the original schemes and the modern schemes.  I'm also a bit crazy and would like to see people appreciate all schemes for what they are... the world might become a better place if that happened

 

[+splendidnut]

... and my cat just stole part of my sandwich while I was writing all that.

[Ecernosoft]

3 hours ago, splendidnut said:

... and my cat just stole part of my sandwich while I was writing all that.

My ferrets decided I'm candy at time of writing this.  

[Mr SQL]

3 hours ago, splendidnut said:

Regardless of what's running, when the system is on, the 6507 is always running, as are the TIA and the RIOT chips... If you're uncomfortable with how you think ARM games turn your system into "just an I/O device", I'd hate to break it to you, but your "modern" computer probably suffers this WAY more.  You can ultimately solve this calamity by giving away all your electronics and becoming a hermit in the woods.

 

I agree the 2600 design is I/O driven. I would find it more interesting to use the ARM as a co-processor and let the 2600 run the gameloop like you did with Chaotic Grill.  

 

I was going to create an ARM implementation of the soft blitter compatible with Flashback BASIC and SuperCharger BASIC, but decided to port it to the Commodore 64's VIC-II instead. I think the VIC-II may be more powerful than the ARM in some ways for making enhanced Atari games.

 

[+splendidnut]

22 minutes ago, Mr SQL said:

I would find it more interesting to use the ARM as a co-processor and let the 2600 run the gameloop like you did with Chaotic Grill. 

Indeed.  I think there's a lot more territory to explore in that domain... that's mainly skipped because people either go full ARM, or completely un-ARMed with their projects.  Which is understandable as it is a weird kind of middle ground that I just ended up in with ChaoticGrill.  I kind of like the technical challenge of "how much game code can I run within the constraints of the 6507 while still leveraging the enhancements of DPC+". 

 

26 minutes ago, Mr SQL said:

I was going to create an ARM implementation of the soft blitter compatible with Flashback BASIC and SuperCharger BASIC, but decided to port it to the Commodore 64's VIC-II instead. I think the VIC-II may be more powerful than the ARM in some ways for making enhanced Atari games.

I think you're comparing apples to oranges a bit... i.e.  a CPU in a cartridge (ARM) with a Video chip (VIC-II).  The current ARM-based cartridges on the Atari 2600 are limited by what the TIA can do.  So yeah, the VIC-II is going to be more powerful than the TIA in most ways... except maybe with color, since the TIA has more colors available (128 vs 16 with NTSC).

 

I think creating a "soft-blitter" ARM driver that's made available across all the ARM-based Atari 2600 SD carts would be a worthwhile effort.  Even more so if someone took the time to integrate it into the various Basics floating about.  I started fleshing out some ideas of how to do that a while ago, but really haven't made much headway in that area as I've mainly been focused on other things.