| |
Krill
Registered: Apr 2002
Posts: 2839 |
Alt-history no-cost design changes with great value
Which things in the C-64 could have been implemented or connected differently without conceivable extra cost, for coding advantages?
Thinking of things like shuffling the chip register bits like VIC's $d011 and $d016 differently (such that some effects can be achieved with fewer register writes or less twiddling).
Or putting some IO register to $01 (and move the memory configuration somewhere else, somehow).
Maybe also having different PLA memory configurations (not necessarily more).
Or connecting external signals to the CIA port pins in a different order.
Discuss! =) |
|
... 65 posts hidden. Click here to view all posts....
|
| |
wil
Registered: Jan 2019
Posts: 42 |
Guys, if you plan to go back in time to add improvements to the C64 *please* be careful!
Remember what happened last time when we went back in time to improve C128's VDC. We wanted to add a blitter function instead of the limited hardware sprites and a separate memory to avoid cycle stealing. And we ended up losing the sprites for good and the separate memory is damn slow to access now... |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
that polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldthat polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally Pixels are output one by one along a scan. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
Quote: Quoting Oswaldthat polygon filler will never work, as VICII never reads bytes continously nor vertically nor horizontally Pixels are output one by one along a scan.
my bad, havent read CJ's suggestion fully... edit: or did I ? CJ talks about eoring bytes, however eoring horizontally per pixel as you suggest would work.
then just max 2 extra onboard bits for the eor mechanism or 1 for hires, should be doable from a few dozens transistors :) or less |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting wilRemember what happened last time when we went back in time to improve C128's VDC. We wanted to add a blitter function instead of the limited hardware sprites and a separate memory to avoid cycle stealing. And we ended up losing the sprites for good and the separate memory is damn slow to access now...
No direct access to VRAM on the Commander X16 either. Most un-c64 like. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting ChristopherJamNo direct access to VRAM on the Commander X16 either. Most un-c64 like. It does have auto-increment on VRAM pointers, though, so you can pump in sequential data pretty efficiently with a single store per datum. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1378 |
Quoting Krillbut mustn't the XOR be bit-wise for a left-to-right filler to work?
Not at all! It needs to be bytewise for pattern fill to work. This is exactly what I implemented in software for the 3d renderer in Effluvium
Quoting Oswaldthat polygon filler will never work, as VICII never reads bytes continuously nor vertically nor horizontally
Well, that's the point - it needs to XOR with the previous byte displayed, not the previous one in memory. The byte immediately before in memory is on the wrong line altogether in bitmap mode. And we need to do a horizontal fill to keep the cost down; a vertical fill would need a 320 byte buffer internal to VIC, and I can't see that being cheap.
(also, it's easier to do pattern fills with a horizontal fill than with a vertical one) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
I see that it needs to be byte-wise (or word-wise) for vertical fill (with a buffer spanning the entirely horizontal width), but i don't see why simple bit-wise from left to right wouldn't work for horizontal fill.
The latter i've done in software in the zoomscroller of +H2K (but of course it uses a 256-entry lookup table to be somewhat efficient).
Edit: Oh, pattern fill... now that's a more complex beast anyways, certainly not a cheap add-on. :) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
I dont understand how a byte-wise-horizontall eor fill would work in higher res than bytes ? :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting OswaldI dont understand how a byte-wise-horizontall eor fill would work in higher res than bytes ? :) Filling is performed right-to-left.
Current fill state is held in the N flag.
Pick one out of two lookup-tables according to that state bit.
Read next unfilled input into an index register.
Look up filled output.
Store filled output.
Repeat. =)
(So yeah, two 256-entry tables, actually, but they're just inverted versions of each other. Probably you could use just one with shifting the previously-stored output still in the accu, then conditional inversion of the looked-up next filled value according to carry flag.) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
