Boulder Dash™ 2 - a new engine in development

[hizzy]

Is there anything from Sokoboo that you carried over to the new Boulder Dash or is this a completely new programming method? I really enjoyed Sokoboo, btw! 

[+Andrew Davie]

Just now, hizzy said:

Is there anything from Sokoboo that you carried over to the new Boulder Dash or is this a completely new programming method? I really enjoyed Sokoboo, btw! 

Sokoboo used the same ChronoColour(TM) display technology and basic board size, but no - everything in this demo/experiment was written from scracth. I do have some inclination to rewrite Sokoboo in CDFJ... maybe... not sure.  I should finish that game sometime, and get it out the door. But I seem to stall at about 85%, so there's that.

[+mksmith]

13 hours ago, Andrew Davie said:

I think at this stage I've pretty much learned all that I wanted to know about CDFJ and its capabilities.  A fantastic bankswitching scheme that offers some significant assists to programming - in no particular order, I found that ability to have a "flat memory model" for all of my graphics most useful. I didn't need to care at all about banks, and could just have all the graphics (sprites, playfield) in standard C structures. I loved the data streams that let the 6507 access streams of data with simple lda/sta instructions. Very easy to use, and it made the sprites effectively like those on the 400/800 machines (that is, an 8-bit wide sprite that is the whole-screen deep). I just needed to copy sprite shapes into a 200 byte block of memory, that represetned the 200 scanlines I reserved of screen. I liked that I could effectively "idle" the 6507 during vertical blank, and use that time to do some impressive ARM processing. The full-screen draw every frame wouldn't be possible without it. Actually it's still not possible WITH it, because I'm going way overtime - I'm doing the full-screen draw AND the full board scan/processing.  But that's a fix for another day - the proof of concept was fine for me, even if it only runs on Stella. This engine won't run on hardware and would need a rewrite to do so.  I've taken this demo to the point where I'm not interested in working on new features - sound, title/selection screens, etc. Just not going to happen, and as noted this was always just a test/demo/exploration of capability. To some degree I regret choosing BD as the game on which I based the experiment, but what's done is done. I loved being able to do the vast majority of my coding for the machine in C. It made things so much easier and faster to implement; firstly the ease of programming with the C-language, but also the flat memory model, as noted. It's a game-changer. I really really loved thinking about some idea (for example the overview screen) and being able to program it quickly. In this case, the very first workable-ish version took half an hour. That's astounding. CDFJ is also an eye-opener as to what the actual machine is capable of .

I'm thinking of taking the lessons learned - for example, the overview screen seems well received and works very well IMHO, and the super smooth-scrolling, and the gajillion animation frames that you can have, and of course ChronoColour(TM) and moving on to a game which would be suited to these capabilities.  That is, "character graphics", a "board" of 40 x n tiles, 8-colour ChronoColour(TM) display. Perhaps a hexboard; I have been thinking this would be possible and work OK. One thing I haven't played with yet, but will obviously be possible, is digitised sound/effects. The only limitation I can see there is ROM space. But CDFJ+... mmh.

Maybe I'll move on to one of the games suggested in the show, or perhaps one suggested in this thread. I'll have to look at what's around and who owns the IP. But for now, I'm pretty much done with this engine and showing demos and I'll archive it for posterity. I'll start another thread if/when I choose a game to actually write with what I now know.

Sometimes the best part of coding is doing something different or using some new technology that you haven't before.  If this leads to another awesome project down the track then that's great news too!

 

Theoretically, I'd be interested in your thoughts around your chess engine and what type of speed benefit something like CDFJ might make to that? 

 

 

[+Andrew Davie]

10 minutes ago, mksmith said:

Theoretically, I'd be interested in your thoughts around your chess engine and what type of speed benefit something like CDFJ might make to that? 

 

I have thought about this, too. The way "forward", I think, is to implement CDFJ as an interrupt-driven scheme, rather than polling.  When the ARM is servicing the 6507 bus, it sits in a tight loop polling the address lines for a change, and reacts accordingly. So there's a LOT of ARM cycles going exclusively to bus servicing. Pretty much all of them, actually.  Only by setting the 6507 to a "hack" idle state can you do unrestrained ARM processing, but then you can only do it for a very short time - you need to get the 6507 active again before (a) your vertical blank time expires, and (b) the 6507 PC goes off-planet, so to speak.

I have a dream of changing the bankswitching handling in the ARM code so that it's interrupt driven.  That is, when there is a change on the address bus, an interrupt is triggered and the ARM does exactly what it does now in response to the new address.  The difference being, after it's done, the ARM returns from interrupt.  This frees up the ARM to do background processing -- and in particular, you could run a chess engine in the background in the spare cycles - no matter how many or few there actually were - without having to worry about servicing the 6507 while you're doing that.

I think it would be a game-changer. I know how to do it; I'm sure it will work. I just don't have the spare time at the moment to give it a go.

 

As to speed benefit - well, the engine running in the ARM spare cycles would allow me to use C as the source for the engine, and there are many engines written in C which will be MUCH stronger than my 6507 variant. Not only would they be bug free (bonus!), but they would probably run significantly faster.  I can't tell exactly how much ARM time would be free in an interrupt-driven scenario, but if I had to pull a ballpark figure out of my pocket, I'd guess of the 70MHz ARM capability, probably 75% of that would be servicing the bus (interrupts) and thus 25% of the remainder which is very very roughly 20 MHz.  So, I think you'd effectively have a 20MHz ARM processor unencumbered to allow you to run a chess engine, with the '2600 completely independent of that. But again, I pulled those figures out of thin air.

 

 

 

 

 

 

 

 

[+mksmith]

Good stuff Andrew - thanks! All very interesting!!

[+Propane13]

This thread has been great to watch.

 

Technical question-- for "Pixel mode" is it possible to draw player/missile/ball sprites on top of the PF graphics?  Or, is the engine pretty much fully utilized?

 

 

[+Andrew Davie]

1 hour ago, Propane13 said:

This thread has been great to watch.

 

Technical question-- for "Pixel mode" is it possible to draw player/missile/ball sprites on top of the PF graphics?  Or, is the engine pretty much fully utilized?

 

 

The "overview" screen is just a big playfield buffer (6 bytes/line x # scanlines) into which the "bitmap" is pre-drawn. The 6507 just dumps the buffer to the screen via simple lda/sta (6 per scanline). With CDFJ these take 5 cycles each, so there's 30 cycles of the 70 used for the PF draw. That leaves you with 46 for sprite and other stuff. Another way of saying this; there's heaps of time -- look into CDFJ data streams.

 

Edit: Add +5 cycles for changing PF colours on each line. Add another +3 for the loop/JMP (CDFJ does this specially and doesn't rely on index register for scanline, or a comparison for end of screen.  So it's +3 total. That leaves 38 for sprites. Still heaps.

 

 

Edited April 20, 2021 by Andrew Davie