Cray Ze, to you it's obvious what you are doing there, but for us I think it isn't.
Would be awfully nice if you could just add a little bit of text to this screenshot.

Hmm... when looking at that screenshot...
If one would have a character set with all characters rotated by 90 deg.,
and if one would build the ROW and COLUMN counters etc. a bit different to make them run a different video address sequence,
I think it might be possible to display an entire text screen rotated by 90 deg., that's 40 lines of text, 25 characters per line.

Might be fun when writing code in assembly on such a screen...
after manually turning your TV set by 90 deg., that is.

Sprites won't be displayed rotated, of course.

But a good mystery sets the imagination to work. Mystery pause over, of course I'll elaborate a bit on what's going on.
I implemented many of the ideas mentioned previously in the thread, just not in TTL.......you are seeing:
A 40x25 window into an 80x50 memory space/screen. The 40x25 can scroll about the 80x50 but in this case it's at the bottom right extent,
this is entirely because the data in my 80x50 screen memory consists of the spicing of four screens created in an online (40x25) PETSCII editor.
Along with the 80x50 screen memory, there is a matching 80x50 attribute memory. The character set is obtained from an image of the standard
C64 character generator ROM, there are no redefined chars. All attributes are applied on the fly.
I implemented XFLIP, YFLIP, ROTATE RIGHT 90, UPPER/LOWER CASE attributes. I hadn't gotten around to INVERSE text before putting the design
down for a while, but it's easy, the hardware cursor already uses the principle.

Rotation is easy enough but requires a lot of memory access, though the whole design runs the high memory access rate so at least nothing special
has to be done for a rotate. A pixel is a single bit, so if you're accessing ram at the pixel clock frequency, you're only ever interested in a single pixel.
Just exchange the vertical and horizontal counter bits used in the character decode and there is your rotation, on the fly, we don't care about the other
bits in the addressed byte.I actually have an FPGA based 6502 dissembler that decodes memory straight into 6502 assembly listing on a VGA screen,
with selectable start address and both HEX and disassembly display modes. On the fly, not even a CPU
I could combine them....hmmmm. Whooops, wandering off topic again.

Edit: Actually a full screen rotated mode (and monitor on it's side) might not be such a silly idea for arcade style games.

Here is the same screen in the PETSCII editor, before exporting and splicing.
Colour translates nicely to attributes, except for when it's the same as the screen colour.
I had to massage the attribute output before using it as I'd used the wrong colours, search and replace in a text editor did the trick.

Link to mentioned editor:
http://petscii.krissz.hu/

Hmm... 4 screens, probably VGA... one pixel per read cycle.. I'm getting odd results when trying to calculate that memory bandwidth.


If you happen to have an operating system written in VHDL, please tell.


Just gives me a blank screen in my browser...
but now I started to wonder, for what exactly a text editor aiming at PET\C64 needs Google analytics, googleapis and paypalobjects.

For the video calcs, you only need to think of the one 40x25 character 'screen' that's displayed on the monitor, so if you have 4 x anything
in your calcs, your result will be 300% too high. I should have said 'pixel rate' instead of 'pixel clock' for ram access though.

I'm using a higher res video mode than needed, though that's just personal preference for the mode.
I'm using 800x600@72Hz (50 MHz clk) with a pixel rate of half the pixel clock to simulate 400 x 300 so RAM access is at 25MHz.
You could use 640x480@60Hz (25 MHz clk), and RAM access will be at 12.5 MHz.I've thought about simplifying something like a C64 KERNAL ROM by shifting most of the functions to
hardware, but it's only ever been a thought. I wonder how small the remaining ROM could be?
I hadn't noticed, but that's probably a very good question. It could be that it was created with malicious intent, though I haven't found any
reports suggesting as such. It could be that the author coded in the option to turn it into a pay app, though unlikely. It's possible that it was
developed with a framework that is also used to develop paid applications and it's inserted by default regardless.

EDIT: I just noticed it has a 'Donate' button in the bottom left corner. That's probably a fair enough explanation.

When using the editor it did occur to me that it would be quite simple to re-implement the whole thing in VHDL with the modifications I needed,
those being 80x50 mode and my new attributes. Most of what's required is already covered in the current design anyway, just a case of throwing
in a couple graphical selectors, or make them drop down tabs, wire up some input devices (which I really should do anyway) and think of a method
to get the data out, maybe spew it out through a UART in nice ASCII encoded HEX.

Pretty sure that if we can afford the latency of 40 chars, we don't need the high RAM access rates, and can divide those figures by 8. Just need to think about implementation.
This would prevent another idea from working though (needs the fast access), which would be a shame, I was thinking the 80 x 50 should have sub-pixel smooth scrolling,
rotating and zooming within the displayed 40x25 window (screen). Probably getting to big for TTL, that's a lot of adders.

This explanis it, thanks for clarifying.


System initialisation should be 6502 code, because it would allow more flexibility and it doesn't have to be fast.
Serial IEC bus routines are timing critical and better should stay 6502 code.
The Kernal won't have to emulate an UART when just adding UART hardware to the system.
The rest is somewhat "debatable"... when debating about compatibility to existing code (which makes use of the kernal routines) first.

...You could try to build a "custom" 6502 core in VHDL that also runs BASIC tokens as "Bytecode" and does floating point math by hardware.


Hmm... web designers using frameworks with "potentially malicious content" without being aware of it.
Suddenly, internet seems to make sense again.


Or displaying selectors, status etc. in the border around that text screen...


It would complicate things like "line crunching tricks" by software, but when having enough colors maybe nobody would need to use such tricks anyway...


Hey, we are just collecting ideas here. Implementation would go into a different thread.
Just post your idea, so we can see what could be done.

Compatibility would be out the window, but with a well behaved OS and software it could be interesting.If I was to design a BASIC interpreter in VHDL, there would be no CPU, so it probably wouldn't be relevant to the forum. Maybe not, I need to think about it a bit more. The latency should all happen transparently before the char fetch so certain effect wouldn't be effected.

The idea is to increase the X and Y pixel counters to somewhere between 19 and 24 bits, and map the 80x50 onto a giant rotoplane that shinks the resolution back down to a 40 x 25 window
into an 80 x 50 addressable space, the expansion of bits in X and Y will give me the subpixel rotation and scaling I want. Sounds fine in theory.....

Nah, my suggestion was more about building a CPU that runs NMOS 6502 machine code as usual... until it fetches a special instruction that puts the CPU into BASIC mode.
In BASIC mode, the CPU executes BASIC tokens as sort of a "Byte code"... until it fetches a special BASIC token (something like 'sys') that puts the CPU
back into using the 6502 instruction set.
This way, you wouldn't have to implement the complete BASIC interpreter in VHDL, and there would be a chance of mixing BASIC and 6502 machine code
in the same program. //Ain't exactly like using "inline assembly"...

Hey, an ARM with integrated hardware Java Bytecode interpreter still counts as an ARM, so a 6502 with an integrated "BASIC interpreter subset"
still counts as a 6502 (and IMHO still would be relevant to the forum).


Suddenly, I feel reminded to the DAGs (data address generators) used in DSPs... //innocently humming the "Jaws" theme.
ADSP21065L manual, page 165.

Now let's suppose, one would try to modify the DAG concept to use it as ROW\COLUMN counter when fetching data to be displayed from screen memory...

I'll look at that 780 page datasheet soon, for now I've got to go feed some lizards.
I just though I'd post I've remapped onto a virtual plane and it works.
I was quite a way off with the bit requirements, I forgot about the multiplying effect.
19 bits would have lead to (1111111111111111111 x 1111111111111111111). That's 2.537329231×10⁴³ pixels, in both X and Y, whoops!!
For reference, the diameter of the observable universe is only 8.8 × 10²⁹mm in comparison.
The 16 Bits I'm using is overkill.

Take care that your brain won't go into overflow.
Only page 165..181 would be relevant, that's 16 pages.


Please post a picture someday.


...So you decided not to make use of the "libration zone" between the 4th and 5th dimension ?

Attached: Don't look at the background too closely, I've saved adjusting for my register delays until after feeding (lots more to go).
You think I should have extended to a full 24 Bits?

Cute, especially the second picture.

No lizards around me, only a cat:




Nah, I think you should have tried to get around those multiplications somehow by using some more odd tricks.

I see gravity isn't an issue for this special cat.
The only multiply in the design is the x 80 mentioned previously. Getting the proper parameters to feed to the rotation unit
would require four multiplies to calculate the correct rotation angle, but this only has to be done once per angle change and
it's probably better to leave this to the CPU/programmer and keep the design within the possibilities of TTL. The rotation itself
doesn't use a multiply. I'm clocking the ROTO at the pixel clock, this turns some of the sub-pixels (virtual pixels) into real pixels,
effectively upscaling the resolution and decreasing jagged edges.

I fixed the timing so the glitches in the background of the lizard pics are gone. Locking the boarder to the rotoplane on the 40x25
window gives an interesting effect. I recall various flight sims and racing games that would shake the screen about when you crashed,
well, now the screen could be bounced about like a ping-pong ball, rotated, zoomed in/out or whatever.

Oh what a twisted path these pixels weave!

Well, it's not normal for tigers of any size to sleep while lying on the back like this...


Hmm... so I guess it's about more memory bandwidth... and about using parameters with a fractional part or such.

BTW: In TTL terms, multiplication could be done with a lookup table in a ROM.
For instance, an 8*8 Bit multiplication then would take 64kWords of ROM...
but there is a neat mathematical trick that would reduce the lookup table to 512 Words of ROM.


Rotating a screen like that sure would be useful for a flight simulator... can you do this with sprites, too ?


Nice.

It's running at the pixel clock now to gain the up-sampling, but could still run at the half pixel rate, resulting in no up-sampling and the same bandwidth as before.
Yes, calculating the correct parameters requires multiplying by a sin/cos lookup table. The roto unit can also stretch X or Y and I'm pretty sure it can flip/mirror as well
so it's probably best to leave the programmer to decide the function. I'd leave the option for raw control even if adding the multiply function to the hardware.While not quite as fast, an 8*8 Bit multiplication can be done with four reads of a 256 Byte lookup table and three adds, quite easily done in CPU land.Yes, you could have rotating/stretching/scaling/mirroring sprites