Gip-Gip
-
Posts
266 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Everything posted by Gip-Gip
-
It isn't as big of a mess as the Intel machines, at least That was sorta my original idea but the speed would be really bad (imagine running your daily programs in Valgrind 24/7). Granted, I wouldn't have to do some voodoo magic with the memory manager to make 32kb (or even worse, the stock 256) work with an OS, just include some large RAM chips on the cart. I needed to come up with an instruction set for the compile-when-ready idea, so I'll get that done and tell everyone about it
-
Paged memory would greatly improve the ability of the TI, so I'll find a way(not just yet, however)
-
Currently I'm getting the dev environment set up, I'll release a version of the OS by at most sunday
-
Found it! ftp://ftp.whtech.com/programming/c99/C99REL4/c99%20v4%20for%20994a%20manual.pdf I'll also attach the manual to this post incase the site goes down (I don't necessarily trust the FTP server) c99 v4 for 994a manual.pdf
-
Errors while building GCC. Might be because I'm on an oldish mac, but I've personally never been able to build GCC, even when I follow the directions
-
TI - Cartridge Based Operating System -- (Potential & Discussion)
Gip-Gip replied to Omega-TI's topic in TI-99/4A Development
I may get started on my own OS once I find out the quirks of C99. Would anyone happen to have the documents to the compiler? ftp://ftp.whtech.com/programming/c99/C99REL4/c99%20v4%20for%20994a%20manual.pdf P.S. I started my own dedicated thread if anyone wants to discuss the idea -
I'm taking a break from VePseu development, and I would like to make an OS named wem/yt (loW rEsource Memory/sYstem inTerface) for the TI I have lying around. The reason being so I can use the computer for something AND learn enough to port it to more systems, say an Intel. The idea is pretty simple in my opinion you have a memory manager which is powered by barebones I/O (keyboard and display) you can save, load, and execute blocks of memory it would implement voluntary multitasking (have programs jump back to a certain point once they're done) Implement a portable compile-when-ready executable format for non-critical executables drivers like disk or tape would be built-in, and would be run as essentially high-priority executables. The OS obviously isn't made for performance, rather to allow the lowest usable level of the system. I see use in programming and debugging, along with basic file editing tasks (I also plan to make an Arduino interface, but that's for later). Here's the thing Looking at the list of programming languages isn't very promising, as C (the best language for the job) lacks documentation (C99) or won't compile properly (GCC). I'll learn new languages if I have to, but I don't want to (learning a language and building an OS at the same time sounds like hell to me). If anyone has any suggestion I would greatly appreciate it Now that I have the manual for C99 I'll be using that
-
Replaced the polystyrene caps (in my 2600) with mica and the 4.7 electrolytics with mylars. Only thing I'll have to recap in 20 years is a low-ESR panasonic
-
I've released VePseu II.III.MMXVII Rev. 0 to push some huge optimizations to the master branch. I still need to optimize it further before the addition of features.
-
I have some bad news: VePseu is in some serious need of size optimization. I'll continue to work on the project but keep in mind my finals are coming up so I'll be doing schoolwork for quite a while. It would be Greatly appreciated if anyone contributes to the code base, in any way they can. The in-development (unstable) branch can be found here.
-
Finally got the sprite kernel working for the entire screen! Needs a ton of size optimization before I'm comfortable with giving the engine another release. All the game ideas sound great!
-
It's been a long week of school, optimization and procrastination, but here's a screenshot for 'ya It's been a pain getting the instruction count down to fit in a good and simple sprite kernel, but overall I'm happy with the progress/results (not to mention I learned a lot trying to optimize this thing) Expect a sprite kernel and size reduction next update
-
Since I'd like to make some games with this myself, the next update will hopefully include sprite support
-
The background (our new shaded walls ) would be colored in PF0, while the normal walls wouldn't even touch it (unless you blanked the background, which would require precise timing and would be a general pain).
-
This is not a maze renderer. You would also have to make the effect work for 2*X hallways and multiple hallways displayed at once.
-
It would (in theory) be simpler, but it would also mean you would lose (color) shaded walls. Plus, it would look kinda weird with the fact that PF0 isn't colored in, and the last PF2 is also mostly empty. It wouldn't take that long to add, but it would look uglier.
-
The draw code is already kinda crammed, and since you mentioned that I'm not so sure it's going to happen. II.II.MMXVII is equal to 2.0.0 in your standard version. If I wanted to make it equal to 2.0.1, I would write II.II.MMXVII Rev. 1. If I wanted 2.1.1, II.III.MMXVII Rev. 1.
-
In order to be more efficient I have only used 1 variable per wall, and 2 variables per shadow. That means you would have to add another variable to allow walls to take on the same shapes as shadows. Now this may not be difficult to implement, but it would take up another 20 bytes of RAM, plus the code to set and alternate the colors. I view it as kinda wasteful to get a small effect, but I may be wrong.
-
My 3d renderer finally draws to the full screen! It's much better looking than before
-
Version II.II.MMXVII is up! A bigger viewport has been added, and that's about it.
-
Can someone explain pointers to me?
Gip-Gip replied to Electrk's topic in 2600 Programming For Newbies
right, it's actually 2^16-1, or 65535. -
I'm replacing the regular 82pf polystyrene caps(2600) with high-quality Mica caps. Has anyone else done the same?
-
I'll add wall smoothing after I'm finished sorting the code. I may also add smooth movement in the future, but I really don't want to waste the players on that (you couldn't make more than a maze game, and that's mundane and limiting)
-
After I clean up VePseu's code I'll push the full-screen version to the master branch! Afterwards I'll add more features and eventually get started on a game!
-
The colors wouldn't be the problem, rather the whole rendering path
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord