splendidnut
-
Content Count
500 -
Joined
-
Last visited
Blog Comments posted by splendidnut
-
-
I take it that Ambidextrous is Robotron 2084?
-
Just realized that since I'm not going to allow assignments in expressions (in other words, I'm only allowing assignment statements), that probably helps alleviate some of the use cases that would otherwise require semicolons.
-
Yup, currently semicolons are optional. I set it that way when I was debugging some parser issue and then just never removed the conditional check for them. Seems to work good for now. Although there are probably a few potential issues that will have to be dealt with from not enforcing them. I'm still in the early stages of adding error reporting in the parser and am leaning towards a "one and done" since any syntax error can throw parsing completely off. While enforcing semicolons would allow multiple syntax errors to be reported... I grew up with Turbo Pascal so I am very used to the "one and done" error reporting
I'm not sure how helpful it would be to have multiple syntax errors thrown. My experience with various C/C++ compilers was that it wasn't really helpful since anything beyond the first error could be a false positive due to the first error.
Currently I'm using a hand-written recursive descent parser with no look-ahead. I've thought about adding look-ahead, but I haven't run into the need for it yet... and that might just be because I'm only doing a subset of C. Or that might more due to that being a "grammer to parser" parser generator issue... I'm really not sure.
-
Fair enough @RevEng. In my bit of research, adding kernels to BatariBasic was not obvious to me... that is a pain
So I looked around a bit, and came upon your title screen examples and it seems "easy" enough. Maybe it's just me, but it doesn't seem "Basic" enough. (quotes are for laughs) To be fair, I'm not going to magically solve that problem here either. Display kernels, for the most part, will always have to be written in assembly. Until someone proves that wrong... (Note that I'm not including my own sloppy example above).
My goal is to reach the middle ground between Batari Basic and Assmebly. By it's very nature, a C-like (or any Algol derivative) language falls nicely in that area.
Over the weekend I've added code to my compiler to handle inline assembly (in a better way than CC65... similar to KickC), which I personally think makes it easier/more flexible to add/include display kernels than in BBasic.
-
Yes I have. The KickC developer and I appear to have similar ideas (like how inline assembly blocks should work). The big difference is KickC requires Java (it's written in Java) and mine (written in C) does not.
And semicolons are optional in mine
-
There's really no need for the standard C library as I plan to use this mainly to write games for the Atari 2600. While my experience with working on Chaotic Grill (my Atari 2600 port/remake of BurgerTime) in 6502 assembly has been a nice experience, I'd like to try and speed up that process by writing in a higher level language. After seeing how quickly @johnnywc and cohorts brought Galaga to fruition (which was partially attributed to the use of C on the ARM/Melody platform), I figure that my biggest issue with ChaoticGrill had been the lack of flexibility that assembly language provides... There were a few times in which I needed to rewrite large portions of the code to move forward.
You may ask: So why not BatariBasic (Bb)? Well, while Bb provides a nice way for coders and non-coders alike to develop games for the Atari 2600... It relies on canned kernels... and it seems to be a little bit of a pain to include/use your own assembly display kernels. Granted this is all from what I gathered from reading thru posts, especially @Karl G's posts in which he does a great service to the Bb community by using his skills to help others in this aspect.
Overall, developing this compiler has been surprisingly rewarding. It's been a great learning experience and a good way to help me improve my C coding skills... which have partially rusted since I spend most of my time (at work) in Java/Javascript land.
I am hoping that the compiler will also serve the purpose of providing a base compiler for any other compiler related projects I'd want to do in the future. I've been pondering something like a C / Javascript hybrid compiler... which is partially how this compiler project started... hence the name/codename Mocha.
TLDR;
Yes, challenging and rewarding. Plan to use for game making. No need for standard C library. Trying to solve the problem of slow development time. It's already produced good results (see attachments)
-
Ah yes... Fast Fetching not "bus stuffing"... Fast Fetch overrides the immediate load by substituting the value being passed from the Harmony memory to the CPU (6507); whereas, bus stuffing overrides the data sent from the CPU (6507) to the Atari 2600 TIA chip.
And to clarify, by 10 cycle TIA writes I meant 10 cycles to write both color and PF data.
Thanks for catching that SpiceWare.
-
Before, the hotdog only chased you around on the bottom platform. There was a flaw in the code that handled the vertical movement of the hot dog. He use to get stuck after moving up just a little bit. The fix for that came along with the fix needed to get the chef to actually obey the ladder locations. So now they truely obey the ladder locations. I still need to work on getting them both to obey the level platforms.
-
Adding just a RAM chip would do as the 6507 already can easily share RAM since it only uses half of a clock cycle (the Apple ][s RAM was shared between the CPU and the video display circuitry) It really depends on how the ARM chip utilizes the address and data bus.
-
Lol, I see what you mean... and it was just my luck that when I took the screenshot, he was looking straight at me, making the accidental reference even more obvious. But he is a hot dog, so what do you expect?
-
M-Network (Ron Surratt, specifically) actually did a really good job with it. The display engine of the original was as crammed as it could be. The extra RAM they had in the cartridge was used for storing the game variables since the main RAM in the Atari was almost completely used by the display engine; mainly for the burgers. The extra RAM/bankswitching also made it easy to make it a two player game. There really was no way they could make it better at the time.
My original idea was to finesse their engine, but that would have been way too much work. I started without using any special bankswitching, but soon gave up and switched to using DPC. Which worked for the most part, but didn't quite have the power needed for really improving the burgers. To display the burgers with differentiating colors requires 8 TIA updates per burger display line. With DPC handling the sprites, I had something working that just fit within a display line and updated at least the colors (4 of the 8 TIA updates). I didn't have enough time left to also update the playfield display of the burgers for showing them being knocked by the Chef.
If I really wanted to, I probably could have come up with some way to do it... I had that bouncing around in the back of my mind since August... but then November came around and nothing had come to me, so I had to come up with some other idea.
I started digging around and hit upon the DPC+ Demo. I remember reading about the bus-stuffing capabilities back during the summer. It sounded cool... then when I saw the demos, it really hit me how much power it would give me. One of the big benefits outside of the 10 cycle TIA writes was the ability to write back to display RAM... which should give me everything I need to really make it work and look good. Maybe even make the burger pieces look like real pieces on the level.
-
Sorry about the lack of updates; I got distracted by a trail of other things: acquiring an Atari 5200 and games, working on the house, dealing with fleas in the basement, etc.
But I'm off of work till the end of the year, so I now have lots of time to work on it.
I'm thinking about reworking the engine to use DPC+ instead of DPC... I really need the extra capabilities to do a better job and of course free up some extra cycles when drawing
-
1
-
-
Thanks for all the positive feedback guys!
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Homebrew 6502 Computer Project
in bluejay's corner of random shit
A blog by bluejay
Posted
You might also want to check out the Veronica project: https://blondihacks.com/veronica/