Raycasting

[RXB]

 

Not to the F18A GPU. The GPU is using VDP RAM as its working RAM, it cannot access SAMS or 32K RAM.

So you are telling me that the F18 is running Assembly from VDP?

I find that kind of hard to believe as thee is no way for to physically happen?

[+mizapf]

Why not? A processor can run machine language programs from memory that is connected to its memory bus. The F18A is an own system with its dedicated memory - which happens to be used as video memory, since the F18A produces video output. If the TMS9918A had a kind of machine language, you would be able to run it from the VDP RAM.

 

What you are referring to is that the CPU (TMS9900) is unable to exploit the VDP memory for its operations, but simply because it is not its memory.

[RXB]

Why not? A processor can run machine language programs from memory that is connected to its memory bus. The F18A is an own system with its dedicated memory - which happens to be used as video memory, since the F18A produces video output. If the TMS9918A had a kind of machine language, you would be able to run it from the VDP RAM.

 

What you are referring to is that the CPU (TMS9900) is unable to exploit the VDP memory for its operations, but simply because it is not its memory.

Which processor are you using?

The one on the F18 or the 9900?

[matthew180]

The 9900-core I implemented inside the F18A (typically known as the "GPU"). The raycaster that Rasmus wrote is being executed by the GPU only, and thus only has the 16K of VRAM, plus and extra 2K of GPU-only RAM.

[Asmusr]

The 9900-core I implemented inside the F18A (typically known as the "GPU"). The raycaster that Rasmus wrote is being executed by the GPU only, and thus only has the 16K of VRAM, plus and extra 2K of GPU-only RAM.

 

Actually the ordinary CPU is also doing a bit of work: it is reading the joystick/keyboard and rotating/moving the player.

[RXB]

The 9900-core I implemented inside the F18A (typically known as the "GPU"). The raycaster that Rasmus wrote is being executed by the GPU only, and thus only has the 16K of VRAM, plus and extra 2K of GPU-only RAM.

So this is using a modern chip instead of the TI hardware ok.

[matthew180]

More or less, yes. Basically a really fast 9900 to take care of drawing the screen fast enough for the experience to be enjoyable.

[+Vorticon]

Would it be possible to include more GPU RAM in future versions of the F18A?

[matthew180]

Yes, 512KiB in fact, with native HDMI output. Now if only I could find the time...

 

Edit: Do you mean future *firmware* updates, or future hardware versions? If you mean firmware, then mostly no, I am limited to what the FPGA has. If you mean future new hardware versions, then yes, I have been working on a new board for the last 3-ish years but it keeps slipping.

Edited April 25, 2017 by matthew180

[RXB]

Lack of Video RAM on the TI has been the main reason we do not have a OS Mouse based Menu system using the 192K.

 

I worked on a TIM card version using the Mechatronics Serial Mouse but really what we need is a real Video card with this built into it using sprite 1 or maybe a video plain only it uses.

List of things needed for this to happen:

 

1. 512K or more of Video memory.

2. Built in mouse with own top plane so we can make a TI Graphics interface similar to Windows 95 or Macintosh.

3. Onboard memory of the device that can be expanded to allow upgrades in software.

[TheMole]

Lack of Video RAM on the TI has been the main reason we do not have a OS Mouse based Menu system using the 192K.

 

I worked on a TIM card version using the Mechatronics Serial Mouse but really what we need is a real Video card with this built into it using sprite 1 or maybe a video plain only it uses.

List of things needed for this to happen:

 

1. 512K or more of Video memory.

2. Built in mouse with own top plane so we can make a TI Graphics interface similar to Windows 95 or Macintosh.

3. Onboard memory of the device that can be expanded to allow upgrades in software.

 

Not really, it's perfectly feasible to implement a windows-like environment just the 16k of VRAM we have on a standard TI. Having enough CPU RAM is much more important, and the newly available SAMS cards provide a nice answer to that. We've had this discussion a thousand times before, but there's absolutely no reason to add more VRAM if what you're actually looking for is more memory for your program or variables, CPU RAM (like the SAMS) is a MUCH better and faster choice for that.

 

You typically only need more VRAM to support more/higher resolution/higher color depth graphics/double and tripple buffering/... . None of that is essential for a windows-like OS though.

 

When/if I ever have enough time and drive to start coding for our beloved TI again, I might just try to put my money where my mouth is .

[RXB]

 

Not really, it's perfectly feasible to implement a windows-like environment just the 16k of VRAM we have on a standard TI. Having enough CPU RAM is much more important, and the newly available SAMS cards provide a nice answer to that. We've had this discussion a thousand times before, but there's absolutely no reason to add more VRAM if what you're actually looking for is more memory for your program or variables, CPU RAM (like the SAMS) is a MUCH better and faster choice for that.

 

You typically only need more VRAM to support more/higher resolution/higher color depth graphics/double and tripple buffering/... . None of that is essential for a windows-like OS though.

 

When/if I ever have enough time and drive to start coding for our beloved TI again, I might just try to put my money where my mouth is .

1. 16 colors only in a crappy pallet.

2. No mouse plane but forced to always use sprite #1 thus killing off all programs access to OS interface in the process.

(Once a program is loaded the OS can no longer be used.)

3. Lack of memory to draw anything as again even in bit map mode VDP is needed for buffers and other stuff to make the OS work.

(Again once a program is loaded the OS can no longer be used.)

4. Added to this mess is no mouse unless we use a Interrupt driven mouse that lags the RS232 and CPU to death.

(Lastly many programs uses the same space in memory to work thus takes out Sprite #1 and Mouse support and again making the OS useless.)

5. What kind of OS just goes dead in the water once a app is loaded? (I will wait for a answer on this one!)

 

No amount of RAM is going to solve these inherent hardware problems to a Windows/Mac like interface.

I know as I attempted to do this using a Mechatronics RS232 Serial Mouse and GPL with Assembly support to do this.

 

Know what the main problems turned out to be over and over?

Lack of exactly the above problems.

The entire reason to have a OS interface is to have access to it ALL THE TIME not on a piecemeal basis or REBOOTS!

[Asmusr]

So, back to raycasting. My latest version doesn't use double buffering, and still looks OK, so that saves 6K of VDP RAM. 2K I want to use for increasing the bitmap by 1/3, and the remaining 4K can be used for graphics.

[matthew180]

This is going way off topic, but I'll bite...

1. 16 colors only in a crappy pallet.

Good enough. The palette was designed for shading, especially green. And the F18A gives you a 4096-color palette.

2. No mouse plane but forced to always use sprite #1 thus killing off all programs access to OS interface in the process.
(Once a program is loaded the OS can no longer be used.)

Having the OS out of the way on a limited system is a good thing IMO. Also, using a sprite for a mouse cursor has nothing to do with a program being able to access an OS.

3. Lack of memory to draw anything as again even in bit map mode VDP is needed for buffers and other stuff to make the OS work.
(Again once a program is loaded the OS can no longer be used.)

No, you don't need a bitmap display to have an OS, or windows, or menus, etc. An OS should *NOT* be using video memory for anything other than displaying the screen. No data, no programs in video memory, ever!

4. Added to this mess is no mouse unless we use a Interrupt driven mouse that lags the RS232 and CPU to death.
(Lastly many programs uses the same space in memory to work thus takes out Sprite #1 and Mouse support and again making the OS useless.)

I'm sure there are ways to do a mouse in a way that has the necessary performance. However, a mouse is not necessary to have an OS, and we have survived a long time on the 99/4A without a mouse.

5. What kind of OS just goes dead in the water once a app is loaded? (I will wait for a answer on this one!)

Uh, can you say DOS (MS DOS, Apple DOS, etc.)? The entire PC industry was built on this model, and it is a very good model for limited systems like the 99/4A.

No amount of RAM is going to solve these inherent hardware problems to a Windows/Mac like interface.

Good! I would hate to see a GUI OS on the 99/4A, trying to make it like a modern Windows/Mac interface. If I want a modern bitmap-like GUI, I already have a PC. The appeal of classic computers is that they DON'T have these things getting in the way.

I know as I attempted to do this using a Mechatronics RS232 Serial Mouse and GPL with Assembly support to do this.

Because you made an attempt and were unsatisfied with the results means it cannot be done? In the last few years we have seen a lot of things done on the 99/4A and 9918A that were thought to be impossible.

Know what the main problems turned out to be over and over?
Lack of exactly the above problems.
The entire reason to have a OS interface is to have access to it ALL THE TIME not on a piecemeal basis or REBOOTS!

That is your opinion. IMO a computer like the 99/4A does not need an OS and is better without one. Some ROM-based support routines for accessing hardware in a consistent way is good enough. Maybe a shell to manage files and launch programs (sound familiar, i.e. MS-DOS) would be fine.

[RickyDean]

I am always thinking of something like this for formatting, file management, writing. Something like funnel web only resident. Play a game , quit, and bingo, back in the OS able to click on the next big thing. And in TI colors of course.

 

Edited April 25, 2017 by RickyDean

[Retrospect]

Guys .... as much as I respect you all, and I really do there's some lovely people here - so, no disrespect to anyone, but will you for the love of god not allow Rasmus's Raycasting thread to turn into a discussion about an OS?

 

I'd be doing my nut if this was my thread. And I bet Rasmus isn't far off doing that. If you ask me he's got a lot of patience for folk round here.

 

Maybe write up a seperate thread to discuss an OS?

Edited April 25, 2017 by Retrospect

[RickyDean]

Guys .... as much as I respect you all, and I really do there's some lovely people here - so, no disrespect to anyone, but will you for the love of god not allow Rasmus's Raycasting thread to turn into a discussion about an OS?

 

I'd be doing my nut if this was my thread. And I bet Rasmus isn't far off doing that. If you ask me he's got a lot of patience for folk round here.

 

Maybe write up a seperate thread to discuss an OS?

Of course your right, my apologies, for my part.

[+Vorticon]

Yes, 512KiB in fact, with native HDMI output. Now if only I could find the time...

 

Edit: Do you mean future *firmware* updates, or future hardware versions? If you mean firmware, then mostly no, I am limited to what the FPGA has. If you mean future new hardware versions, then yes, I have been working on a new board for the last 3-ish years but it keeps slipping.

 

Cool! I did mean future hardware versions.

 

And for the record, my question was relevant given that Rasmus' raycaster is using the GPU and would likely have loved to have more CPU RAM available

[Omega-TI]

 

Maybe a shell to manage files and launch programs (sound familiar, i.e. MS-DOS) would be fine.

 

Even that would be an improvement. Sounds good too.

[Omega-TI]

Yes, 512KiB in fact, with native HDMI output. Now if only I could find the time...

 

... If you mean future new hardware versions, then yes, I have been working on a new board for the last 3-ish years but it keeps slipping.

 

OMG! I'm like Pavlov's dog drooling with anticipation over here! +1

 

I'm having visions of how Rasmus would exploit the thing!

[matthew180]

Rasmus, in the two tutorials I found online for raycasting, the one by F. Permadi states (http://permadi.com/1996/05/ray-casting-tutorial-8/) that:

 

 

Two ways of finding distance:

PD = sqrt((Px-Dx)^2 + (Py-Dy)^2)
PE = sqrt((Px-Ex)^2 + (Py-Ey)^2)

or

PD = abs(Px-Dx)/cos(a) =
     abs(Py-Dy)/sin(a)
PE = abs(Px-Ex)/cos(a) =
     abs(Py-Ey)/sin(a)

The sine or cosine functions are cheaper to implement because they can be pre-computed and put into tables. This can be done because ALPHA (player’s POV) has to be between 0 to 360 degrees, so the number of possibilities are limited (the square root method has a virtually unlimited possible values for the x’s and y’s).

 

I have not looked at your code, but which method did you use? I noticed that Lode's example (http://lodev.org/cgtutor/raycasting.html) uses the sqrt() method. Maybe an opportunity for an optimization?

[Asmusr]

I have not looked at your code, but which method did you use? I noticed that Lode's example (http://lodev.org/cgtutor/raycasting.html) uses the sqrt() method. Maybe an opportunity for an optimization?

 

I'm using a more or less direct conversion Lode's code. The code is not calculating the length of an entire ray but the "Length of the ray from one x or y-side to next x or y-side". It is adding up these small steps until it hits a wall. I don't fully understand how these calculations work, so it would be tricky for me to replace the square roots with trigonometry.

 

Regarding optimizations, if the GPU could do signed multiplications and divisions that could probably speed up things a lot. With the existing instructions I have to record the signs, abs the values, do the multiplication or division, and then reapply the sign.

 

I also spend a lot of time shifting values around because I have to work with 9.7 fixed point numbers most of the time (8.8 FP numbers overflow too often).

[Asmusr]

I finally managed to add a few sprites. And this version also has a bigger screen, which can be afforded because it's no longer using VDP RAM for double buffering.

 

 

I still have slightly less than 3K VDP RAM left.

raycaster80.dsk

raycaster8.bin

src.zip

[ti99iuc]

Wow Rasmus... unbelievable result... congratulation.

 

[Sinphaltimus]

This is incredibly slick. I couldn't get it to work in classic99 (with f18a enabled) so I went to real iron and it took me about 3 minutes to pick up the joystick when the keyboard wasn't working out - LOL. I am astonished by the performance. You've done it now. Time to get that red button working.