A Point About Speed

Heyden

New Member
Sep 21, 2019
1
0
1
At large in Europe
Hi All/Murray,

I'd like to discuss the jumper settings for the clock divide that currently exists on the prototype board. You mentioned you are likely to get rid of it in the future. Please don't. You could even set the boards with a higher frequency crystal and then divide it down to the default speed. The clear reason for this is to allow for faster CPU's to be installed later. There could be issues with the sound etc. but I think for the few cents and board space it allows for further tinkering... hacking and realistically taking this 8bit platform forward. This system seems like it will end up in the longest legs of all current 8bit systems to survive into the future as long as the options are taken to allow for expandability and speed improvement. I hope this makes sense.

8MHz might seem like a lot but 16MHz is fast enough to play doom smiley face

Regards,
H
 

Wertyloo

Member
Sep 15, 2019
72
7
8
8MHz might seem like a lot but 16MHz is fast enough to play doom smiley face
sadly in the current HW there is no way to move huge load of gfx data into/from the vera
so just by-central-cpu style,its got be hogged whatever you transfer larger data into the vera-ram[so no-no for a gfx os with overlaping/resizeable windows]
so maybe then the fastest cpu you/they can get include there,to not let the user xperience the i-can-see-as-the-gfx-drawn phenomenon[or jus to be able play any platformer/sidescroller with ecceptable speed]
 
May 22, 2019
486
250
43
Again, you're making incorrect assumptions based on faulty data. As I've said before, The CX16 CPU is capable of writing to VERA just as fast as it can write to main memory. And regardless, memory bandwidth is not the problem here.

Doom uses something called raycasting to compute the color of every pixel on the screen. This technique works by drawing a line from the bottom to the top of the screen, checking for the presence of a wall texture as the ray is drawn.

This technique is much faster than the vector graphics techniques previously used to draw 3D scenes, but still requires a lot of math, including trigonometric functions (Sin and Cos) to position the camera in 3D space.

The 6502 simply doesn't have the horsepower to render a raycast scene at anything approaching a playable frame rate on an 8MHz machine. Even the Super CPU demo is super slow and basically just a tech demo.

My guess, based on the sheer math involved, is you could do about 2 FPS at 160x120.
 
Last edited:

Wertyloo

Member
Sep 15, 2019
72
7
8
most good looking texture filled 3d scene,that uses any form of dynamic lightning requires massive double precision float numer chruncing in parallel with additional matrix-cpus[tensor_cores,heh]
so ofcoz' its not possible on a single general-purpose 8bit cpu
you CAN,if you have enough money and hw-design knowledge to build 1 full hw-accel-to-any-3d-atomic-instruction gpu unit in 8bit,but in real life none would do that
but physically possible... :)
 

thetraintomars

New Member
Nov 10, 2019
2
0
1
Would such near real time calculations be possible with some sort of math coprocessor installed in one of the expansion slots? Perhaps something written to run on an Arduino?
 

Wertyloo

Member
Sep 15, 2019
72
7
8
Would such near real time calculations be possible with some sort of math coprocessor installed in one of the expansion slots? Perhaps something written to run on an Arduino?
with a considerably faster cooproc,yes,BUT:
then needs faster ram,higher bandwidth fsb[at least equivalent to the bitwidth of the largest float you would use],etc to be able to feed/read fast enough the cooproc with/from data

why would you want use another faster general cpu as a math coprocessor? use that cpu as the main cpu
[be avare, math cooproc.s are integrated _into_ the main cpu with a reason, and those cpus (mostly) needs spec. instructions to be able utilize the cooproc efficiently]
please dont beat the dead donkey (any)more... 😄
 

BruceMcF

Active Member
May 19, 2019
139
42
28
Would such near real time calculations be possible with some sort of math coprocessor installed in one of the expansion slots? Perhaps something written to run on an Arduino?
Someone using the CX16 as a bench computer because they like cutting the internet cord while they are doing their bench projects might well have an application where overcoming the 65xx multiply/divide bottleneck is the only thing standing between the CX16 and the way they want to use it. In that case, there are SPI based FPU's that would be excellent choices for that task.

But these are not high bandwidth applications ...you may well load operands into the chip and leave them there, so you are pushing an operand in and reading a result. And the reason SPI is appealing is that even at it's slower bandwidth, the FPU will still be much, MUCH faster than doing it with the 65xx.

This is more like motor control or software driven digital ham radio than Doom raycasting.

If a 20MHz 65816 supported by DMA gives a Doom WAD player that is like the person in the first person shooter is wearing goggles covered in cooked oatmeal, then, no, a 16MHz 65C02 on it's own is not going to "support Doom" in the way that a Nintendo DS can player Doom WAD's ...
... instead, it is only going to "support Doom" in the sense that somebody has ported some Doom WAD's to a simpler, less demanding graphical display approach.
 
May 22, 2019
486
250
43
Would such near real time calculations be possible with some sort of math coprocessor installed in one of the expansion slots? Perhaps something written to run on an Arduino?
Like I said, the memory bandwidth caps your maximum frame rate. At its peak, the CPU can write about 500KB/sec, which would give 26FPS of raw data transfer at 160x120x8. That doesn't account for any computation time, just the time it takes to draw the screen. That is about 38 milliseconds per frame. If you rate-limited the redraw cycle to 15FPS, you would have a 66ms window to draw the frame, so you would have 28ms to compute geometry.

So yes, you could use some sort of FPGA or microcontroller to do the multiplication needed to compute geometry, you could do some sort of raycast engine... but at that point, you might as well just replace the CPU with an external processor and call it a Super CPU.
 
Last edited:
  • Like
Reactions: BruceMcF

thetraintomars

New Member
Nov 10, 2019
2
0
1
Like I said, the memory bandwidth caps your maximum frame rate. At its peak, the CPU can write about 500KB/sec, which would give 26FPS of raw data transfer at 160x120x8. That doesn't account for any computation time, just the time it takes to draw the screen. That is about 38 milliseconds per frame. If you rate-limited the redraw cycle to 15FPS, you would have a 66ms window to draw the frame, so you would have 28ms to compute geometry.

So yes, you could use some sort of FPGA or microcontroller to do the multiplication needed to compute geometry, you could do some sort of raycast engine... but at that point, you might as well just replace the CPU with an external processor and call it a Super CPU.
Thanks for the concise reply with those specific numbers. I find the idea of building peripherals and add-ons for what I hope is a well documented system fascinating so may try something like this on a lark just to see what happens. Of course first I need to get that Arduino kit in....