6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 10, 2024 5:47 pm

All times are UTC




Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Sat Mar 16, 2019 11:36 am 
Offline

Joined: Sat Jun 04, 2016 10:22 pm
Posts: 483
Location: Australia
My opinion on the matter are thus:
While this conversation is interesting to spectate, I don't particularly care whether Doom did full-display redraws, or partial redraws, or delta redraws. It did what it did well enough to create a considerable stir. I do think this conversation highlights the reasons that GPUs became the dominant technology.

Looking to the present, I think being able to access the raw bitmap is nice. I think hardware acceleration for such things as sprites, scrolling, text rendering, and drawing primitives(line, circle, etc) are probably more useful for the types of computers that the members of this site are likely to build. The Gameduino series do some of these things, if I remember correctly. I'm not sure if they do all of them.


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 16, 2019 11:39 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
> probably more useful for the types of computers that the members of this site are likely to build.

I wouldn't be comfortable summarising the members of this site - they are varied, and many are quiet. I think mostly of text-based computing but I like to see graphical patterns and graphs. I have also played some games in my time.

I would expect, in the fullness of time, over the course of years, to see everything here: textual displays, bitmap displays, tiled displays, displays with sprites, displays with VLSI engines, with FPGA engines, with TTL engines. Even vector displays.


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 16, 2019 12:02 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
There's a project using micro controllers which might be relevant. I've put it in its own thread:


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 16, 2019 11:13 pm 
Offline

Joined: Fri Nov 27, 2015 10:09 am
Posts: 67
BigEd wrote:
There's a project using micro controllers which might be relevant. I've put it in its own thread:


Interesting, they use a couple of AVRs. One to generate the video display and one as a blitter.

One idea I had was to use dual port RAM for this. The 6502 only accesses RAM on every other cycle anyway and most RAM is much faster than that, so you could probably do a decent 8 bit/pixel bitmap streaming via CPLD, with the other port used for a GPU made from an MCU.


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2019 2:30 am 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8539
Location: Southern California
mojo wrote:
The 6502 only accesses RAM on every other cycle anyway

?? If you do for example,
Code:
        LDA  FOOBAR1
        ADC  #<some_number>
        STA  FOOBAR1
        JMP  <label>

with the code in RAM and the variable not in ZP, that's already 13 cycles in a row of RAM access with no let-up. It should be pretty common to have 50 in a row with no let-up. I think the percentage of dead bus cycles is something like 25%, not 50%. There are ones like CLC, INX, etc. that are two cycles, with one being a dead bus cycle.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2019 8:17 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10976
Location: England
(I imagine mojo meant 'every other phase' - with an adequately fast RAM, the 6502 can share it with other machinery, with no loss of performance.)


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2019 9:20 am 
Offline

Joined: Fri Nov 27, 2015 10:09 am
Posts: 67
Aye, that's what I meant.


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2019 9:41 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1485
Location: Scotland
mojo wrote:
Aye, that's what I meant.


It was a common technique used by early computers like the Apple II and so on. That's why their clock frequency looks weird, but it's a good fraction of the NTSC (or PAL) line rates. It's also why you need memory that's (over) 2x as fast in a 6502 system than you might initially think. Effectively you get dual-port RAM "for free" - not free in that you need additional logic (like the tristate buffers in the early NMOS systems) and more "glue" but a good way to make video if you get it right ... the 6502 gets full access on one half cycle and the video generator uses the other half cycle all synchronised to the clock.

Which (and someone correct me if I've mis-remembered) the UK-101 didn't quite get right and you got "snow" over the screen when writing to it due to some fractional timing issues.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2019 6:13 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
I think some CGA hardware had a similar problem. There was a software workaround but I'm not certain whether it eliminated the problem (at a performance cost) or only reduced it.


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 18, 2019 3:18 am 
Offline

Joined: Sat Dec 13, 2003 3:37 pm
Posts: 1004
Chromatix wrote:
I think some CGA hardware had a similar problem. There was a software workaround but I'm not certain whether it eliminated the problem (at a performance cost) or only reduced it.

As I recall using the BIOS to run CGA had the snow problem, but stuffing data straight in to the frame buffer did not.


Top
 Profile  
Reply with quote  
PostPosted: Tue Mar 19, 2019 7:27 am 
Offline

Joined: Tue Feb 24, 2015 11:07 pm
Posts: 81
drogon wrote:
I settled on a library called SDL which is ostensibly cross-platform, however what it gives is a buffered "poke pixels at the display" type of interface. So I poke pixels into it then call an "update" function which magically blits the software framebuffer I have to the real screen. It can do this very, very fast - even on a Raspberry Pi without using the GPU.

Of-course after doing it, the cool kids told me I was doing it wrong, however it worked very well for me (and still does today), but I know it's "wrong".


I used SDL on the Nokia N900 and it was faster and more responsive than Hildon, which was using the "accelerated" features of that platform. SDL was so quick that I was doing 60fps animation with Ruby. IIRC, the N900 is an ARMv5 so Ruby should be pretty slow in theory.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5

All times are UTC


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: