splendidnut

I see your problem... you forgot to put the chips on it

@8th lutz Thanks for the link. Definitely makes more sense now.

I believe Rikki & Vikki was developed specifically for the 7800 hardware first... The Steam version of the game is actually running the game in a 7800 emulator developed by the game creators specifically for assisting with developing the game and the new bank-switching hardware it uses. Hopefully I didn't misinterpret what you meant by that.

Thank you @Nathan Strum for taking the time to document all of this... I really enjoyed reading thru it.

I didn't realize there were already similar color demos out there... then again, I probably never searched for them. Here's the one I did recently... with source code!

Awesome game and graphics engine! Thanks for sharing those details. Kudos for trying something different and using the E7 bankswitching scheme.

I don't know about anyone else, but I would be interested in hearing some narration during the gameplay. Either colorful commentary or interesting informational bits.

Mind blowingly awesome!

And here's something fun, a screenshot of FridgeGrid showing all the fun joys I had with squeezing everything into the display kernels: I don't think it's quite up-to-date, but it gives the general idea

While starting to look thru the code again, I thought I would share some stats for those who are curious (As of February 2020?): 19 source code files (6502 assembly) 3 outside header files (vcs.h and the DPC+ headers) ~12,700 lines of code

A limitation of the DPC+ kernel in Batari Basic is that it can only use 32 of the Atari's 40 playfield pixels. Per @Random Terrain 's page: https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#dpc_playfield_resolution

Thanks for doing this! A nice, quick bit-sized review show. I feel a bit honored to have my game chosen to be first. I'm glad you enjoyed playing it.

Yup, I understood all that when I read the first post. I found the phrasing of the statement about 32 character kernels requiring DPC/DPC+/ARM to be a bit misleading. It's my fault for not articulating that better, earlier. That's what I get for posting when tired. My apologies for the confusion... That description will be really helpful for others. This is a nice simple, nifty kernel for displaying a good amount of text. It's dynamic nature is nice and allows a multitude of 'text-mode' style games. It'll be interesting to see how this develops.

Ah... ok... I misunderstood your original statement: Made it sound like you didn't see the demo that was done with a "vanilla" cart in 4k. ---- Though... There's probably a way to make that 32 char kernel a bit more dynamic...

I do like that yours has lots of color options

Very cool. For the record, there was a 32 char, 5 row kernel done in 4k (no extra RAM/ROM/DPC/ARM):

Previously discussed here:

Yes, a processer's bit-width is generally determined by the size of the registers. Instruction set width doesn't really matter... Ex: eventhough an Intel 80386 still used 8-bit opcodes, it's a 32-bit processor (32-bit registers and 32-bit ALU). Things can start to get a bit murky though. Consider the Pentium MMX chip - for the most part, it's designed to execute 32-bit software... but also has a subset of instructions that access the MMX registers which are 64-bit. You can argue whether it's a 32-bit or 64-bit processor depending on whether you consider MMX as part of the main CPU or as an add-on like the FPU that just happens to be built-in. So, with that in mind, if a 64-bit processor is only ever used to run 32-bit programs, are you really gaining anything with a 64-bit processor vs. a 32-bit processor? (assume same clock speed).... I'd say you really aren't since the programs aren't taking advantage of the 64-bit registers. I asked the question about the ARM's Thumb mode because it can make a difference with performance. IF the Thumb instructions were only allowed to run 16-bit code (code that worked only on 16-bits at a time), I would argue that eventhough the ARM itself is 32-bit, if it's running ONLY in a 16-bit mode, we shouldn't keep saying 32-bit ARM vs 8-bit 6502 since it would really be 16-bit vs 8-bit code. BUT as Thomas has answered, that is NOT the case since the ARM is running 32-bit code in Thumb mode. So it is 32-bit ARM vs. 8-bit 6502.

@Mr SQL While I do stand by my use of the word impression, I'll agree that perception also applies. In general, people should keep in mind the impressions they are making and the perceptions they are generating when posting I'll try to stop derailing now.

Ah, ok.... that makes sense. I once designed a CPU architecture like that (16-bit instructions with 8/16/32-bit registers) for a college project.

@Mr SQL I believe RevEng quoted the things he had issues with. His reaction seems to give me the impression that he felt attacked. Being as you called them discussions... Would you prefer that I use the word accusations? Because there were a lot of them without facts or links to back them up. Sorry if my word choice was not the best. I was just trying to get to the root of the issue. I would have corrected/elaborated on my post, but @Karl G beat me to it and handled things much better than I did. @ All Are Atari 2600 ARM games really 32-bit? Being as most/all of them run in Stella and Stella only has Thumb emulation... and the Thumb instruction set is only 16-bit, right?

@orange808 What is with the attacks?

9 months ago... https://hackaday.com/2019/09/30/emtombed-secrets-partially-unearthed-as-researchers-dissect-clever-maze-generating-algorithm/ Even further back to the Research Paper: (Submitted December 2017, Published November 2018) https://arxiv.org/ftp/arxiv/papers/1811/1811.02035.pdf And previous talked about here on AtariAge:

Or you could make the keys themselves smaller: It happens every single time... And yet there are no issues with the backslash (the more prominent escape character).

Neat. Found a couple of issues though. There seems to be a wrap around issue with the musical keyboard display when the blend 4/12 is selected: Also, the forward slash seems to get stuck on with this combo selected.