Jentzsch/Davie '2600 tile/character graphics engine

[+Andrew Davie]

On 8/6/2019 at 2:41 AM, RevEng said:

Complaining that various downloaded releases of bB have delivered various updated releases of dasm as being evidence of "a bad thing"... I'm really at a bit of a loss for words on that.

That is not what I wrote. Don't twist my words.

[+Karl G]

While I'm sure that no one intended to criticize RevEng or his distribution/maintenance of DASM, I can understand how if I were the one putting in the work, it could easily feel like that effort wasn't appreciated, and appreciation is the only payment one gets for maintaining open-source tools.

 

In reality, issues with versioning and having an "authoritative" source for a project are features of the open-source world. Maintainers sometimes drift away due to other interests and real-world concerns, and others pick things up, and distribute their own releases from their own sites. Also, open-source projects tend to have a lot of releases, which can make it a bit more work to ensure you have a stable, updated version.

 

Even though I'm not using batari Basic at the moment, since I have the latest RevEng release if it installed, I haven't had to worry about looking for an up-to-date, stable version of DASM for my assembly projects. I just wanted to say that I appreciate the work he has put into this, too.

[RevEng]

Andrew, you certainly didn't say those specific words. Saying "An almost textbook example of why where we are at, regarding multiple DASM sources, is a bad thing." when presented with evidence of four different dasm's on someones computer, one official, and three of which were dropped there by historic bB downloads, amounted to the same thing to me. I'll accept that wasn't your intent (though unsure of your point then) and we can just move on.

 

@all, thanks all for the kind words. I really do appreciate the likes and sentiments, but I really think we should let the issue die now. I should also point out that Andrew has historically done much more work for dasm than I have, and he has my well deserved thanks for that.

[+Andrew Davie]

3 hours ago, RevEng said:

Andrew, you certainly didn't say those specific words. Saying "An almost textbook example of why where we are at, regarding multiple DASM sources, is a bad thing." when presented with evidence of four different dasm's on someones computer, one official, and three of which were dropped there by historic bB downloads, amounted to the same thing to me. I'll accept that wasn't your intent (though unsure of your point then) and we can just move on.

 

@all, thanks all for the kind words. I really do appreciate the likes and sentiments, but I really think we should let the issue die now. I should also point out that Andrew has historically done much more work for dasm than I have, and he has my well deserved thanks for that.

 

I wasn't having a go at you. I do not think it even 'clicked' for me that they came from bB.

I'll make it even more clear - I think it's *wonderful* that you have bug-fixed and supported DASM.

I just think that we - the community - need to have a centralised, single, place for distributing and maintaining it.

Otherwise we get the problem the OP has had.

 

If your intention is/was to have a "bB specific" DASM, then maybe the versioning/command line output should say so.

If your intention is to have it be the latest and greatest DASM, then that's fine too, but I believe it should be a stand-alone, separate distribution.

 

I would really love to see the "official" DASM repository updated. OR replaced, if someone else wants to do that, in which case the "official" one should die. Yes, I am actually one of those with access to it - but I retired from that role many years ago, and it is/was maintained by Peter Frolich. I do not know if he is contactable or active, but that would be a good first point of call, to see how he feels about passing on the reins.

 

[CPUWIZ]

Damn foreigners. ?

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Oh, wait.

[Retrac]

On 7/30/2019 at 3:10 AM, Andrew Davie said:

I buried a release of the tile engine, that Thomas and I wrote from 2003-2011, in the Sokoban forum. I am re-posting the source code here, so that I have a logical place to explain how it all works, how to use it, and answer any questions.

The engine uses the $3E bankswitching scheme.

 

Thanks for posting this.  It's been very instructional!  You are both wizards.

 

I'd love your opinion on something.  I've been working on a bit of code that displays a bitmap stored in RAM for my game idea.  I'm working on rendering proportional text from fonts at the moment.  I've been using 3E bankswitching too, but as you say, it is pretty limiting.  My code's only a small demo so far, so I'm not experience with how larger programs should be laid out yet.

 

I've thought about creating my own mapper.  Probably something like 1 KB pages which can independently be set to a 1 KB RAM read, RAM write, or ROM bank.  I think I can see how to do that in hardware.  It would allow fast and easy direct copying from RAM and ROM to the bitmap RAM.

 

Anyway, do you think you could you share some insight on what to look for in a bankswitching system, when it comes to choosing or designing one for a large bitmap or tile-oriented game?  Did you find 3E limiting or unwieldly for Boulder Dash?

[+Andrew Davie]

16 hours ago, Retrac said:

Anyway, do you think you could you share some insight on what to look for in a bankswitching system, when it comes to choosing or designing one for a large bitmap or tile-oriented game?  Did you find 3E limiting or unwieldly for Boulder Dash?

 

3E was very limiting because there was a bottleneck in the single fixed-bank. As you know, 3E offers a single fixed bank at $F800 (2K), and switchable either ROM or RAM living at $F000.  If you switch in ROM there, you have 2K accessible. If you switch in RAM there, you have just 1K accessible. The other 1K is used for WRITE access to the RAM. So, read from $F000 will get the first byte of RAM. And write to $F400 will write the first byte of RAM.

 

The bottleneck is where you need to access RAM or other ROM from the switched in RAM/ROM bank. The only way this is really practical is to go through an access function in the fixed bank.  So, save the current bank # somewhere, call the fixed-bank routine, which switches in the desired bank, and accesses it (function call or RAM read/write). Then it switches back the current bank # and returns. This can be very slow - a hundred cycles, say. So, it became pretty much a requirement to have the data you need in an already switched-in bank. That meant a lot of duplicated data, but also a heavy use of the fixed bank for storing stuff to avoid having to go through all the problems of accessing data in other banks.

So, 3E isn't the best. Also, it does have that quirk of being unable to do (zp),y across page boundaries.  If you didn't know that, you should! It was a limitation of the Krokodile cart limitations.  if $80/$81 points to a table at (say) $F9F0, you CANNOT get the 17th byte (at $FA01) by using . ldy #17 / lda ($80),y.  In that case it will actually retrieve the byte at $F901. Very non-standard and the cause for much heartache. All of Boulder Dash (and hence the tile engine) was very carefully written to avoid this situation.

Now, Thomas has developed a modified version called 3E+ and we have had some discussions about moving to this. I don't know a lot about it, but my understanding is that it has 4 1K switchable banks. But don't quote me on that. It sounds much nicer than 3E.

To address your specific question, a bitmap game needs RAM to hold the bitmap. You need enough RAM switched in to allow you to pull data on-the-fly as the screen is being drawn. The tile engine manages to achieve this in the 1K RAM banks by having multiple copies of a "character line" - one line per bank, and in each of those 1K is ALL the code to draw the screen, all the bitmap data, and also the code to switch to the next character-line bank/drawer.  All self-modifying, of course, as that was the only way we could see to get sufficient speed to do everything required.

So, I think at this stage I would be looking closely at 3E+ if I were you. But I'm not a bankswitching wizard, and there are no doubt other bankswitching schemes which might be more useful. The one big advantage for me of 3E/3E+ is that I'm familiar with it, and there is the already-written tile engine that does most of what I need.

Edited August 13, 2019 by Andrew Davie
Fixed a minor fact.

[Kroko]

4 hours ago, Andrew Davie said:

So, 3E isn't the best. Also, it does have that quirk of being unable to do (zp),y across page boundaries.  If you didn't know that, you should! It was a limitation of the Krokodile cart limitations.  if $80/$81 points to a table at (say) $F9F0, you CANNOT get the 17th byte (at $FA01) by using . ldy #17 / lda ($80),y.  In that case it will actually retrieve the byte at $F901. Very non-standard and the cause for much heartache. All of Boulder Dash (and hence the tile engine) was very carefully written to avoid this situation.

Hi Andrew, I am not sure if you would only have this problem for 3E. I think it is a general problem of the 6507 crossing page boundaries. For the write instructions STA, STX, STY, SHA, SHX, SHY the 6507 is doing the following:
 

In  cycle #4  a wrong address appears on the bus. In cycle #5 the address is fixed, but then it is too late. The bankswitching hardware always monitors the bus and if you have a wrong address on the bus, then the hardware is reacting to it.

So if you were using such an instruction on the write port of the RAM area, you would first put the wrong address to the bus in case you were crossing a page boundary.

In case you want to construct a bankswitching method that does not have this problem, you need to find a way to detect, the wrong dummy address from cycle #4 (which may be difficult).
Or you could think of a different mechanism to read/write to the RAM (not using the Superchip approach).

 

        #   address  R/W description
       --- --------- --- ------------------------------------------
        1     PC      R  fetch opcode, increment PC
        2     PC      R  fetch low byte of address, increment PC
        3     PC      R  fetch high byte of address,
                         add index register to low address byte,
                         increment PC
        4  address+I* R  read from effective address,
                         fix the high byte of effective address
        5  address+I  W  write to effective address

 

       Notes: I denotes either index register (X or Y).

 

              * The high byte of the effective address may be invalid
                at this time, i.e. it may be smaller by $100. Because
                the processor cannot undo a write to an invalid
                address, it always reads from the address first.

 

[Dionoid]

I was just playing the popular Indie puzzle game 'Baba Is You', which I think would really fit this '2600 tile engine.

https://hempuli.itch.io/baba-is-you

[+Andrew Davie]

20 minutes ago, Dionoid said:

I was just playing the popular Indie puzzle game 'Baba Is You', which I think would really fit this '2600 tile engine.

https://hempuli.itch.io/baba-is-you

 

I've seen it before - it's neat. A quick review of a couple of the levels (just watching) I think most of it would be workable. The words would be squashed into 4 pixels, but you could use different colours for the letters so you'd be able to get away with that, I think.

So... you have the tile engine.... go for it!

[Dionoid]

On 10/6/2019 at 10:05 PM, Andrew Davie said:

 

I've seen it before - it's neat. A quick review of a couple of the levels (just watching) I think most of it would be workable. The words would be squashed into 4 pixels, but you could use different colours for the letters so you'd be able to get away with that, I think.

So... you have the tile engine.... go for it!

Hmm, I think the rule-blocks will be more difficult to use if the words are not written out.

Maybe I'll give it a try sometime; for now I've too many projects on my To Do list already ?