Great! That makes four of us here that I know of. What city?jrubin wrote:Hey neighbor, as far as this forum goes, you're right down the block from me!
These features (and more) will be used in the Taipan game, and will also be released to the public as a standalone SuperCPU API, complete with 24-bit DOS functions and full mouse support. Later, when we really start working on the Winc64 operating system these functions will be used extensively. Right now I am concentrating on making everything jive with each other. Interestingly enough, and because the SuperCPU possesses such a powerful instruction set, the only zero page locations used so far have been $fb-$fe! Nearly all the variables are stored on the stack, or in the case of text -- in the 192 bytes following the hires bitmap screen at $A000.
The functions are fully 16-bit, the text is 64-columns, and the screen you see is hires. It just looks like the Commodore 64 startup screen! The blue background is really a 40x25 color fill function, as is the green box with the white frame. The SuperCPU graphic was created on Photoshop and the on/off pixel data was copied by hand into asm .byte statements. The SCPU graphic is using one of the bitmap display functions.
Source for the macros used in Print64 (64Tass format):
Code: Select all
;------------------------------------ ;local variable create/destroy macros ;makes space for local vars on stack ;------------------------------------ Prologue .macro VarCount sei tsc sec sbc # \VarCount sbc # \VarCount tcs cli .endm Epilogue .macro VarCount sei tsc clc adc # \VarCount adc # \VarCount tcs cli .endm ;----------------- ;go to 8-bit acc ;go to 8-bit index ;----------------- go8axy .macro .as ;go to 8-bit .AXY .xs sep #$30 ;#%00110000 .endm ;------------------ ;go to 16-bit acc ;go to 16-bit index ;------------------ go16axy .macro .al ;go to 16-bit .AXY .xl rep #$30 ;#%00110000 .endm
Since each character cell is 5 pixels wide (64 cols * 5 px = 320 px) many of the characters overlap the normal 8x8 cells. What I did here was break the x-axis into 8 zones of 40 pixels (5 normal 8x8 cells). Eight 64-column chars can fit into each 40-pixel zone. So when determining where the next character should go, the routine divides the x-coordinate (range --> 0-63) by 8 to get the correct 40-pixel zone, numbered 0-7. Once the correct base address is calculated for the Y-row ($a000 + (320 * Y) we add (40 * zone #) to get the base address for this zone. The x-coordinate is further masked for the lowest three bits (range --> 0-7), which determines which of the eight custom draw routines will be used in this 40-pixel zone. When calculating complicated addresses I don't even think about messing around with math, even at 20 MHZ. Every component comes from a look-up table; tbl_320, tbl_40, even tbl_8. The final, effective address then becomes a matter of simple addition -- something the 65x family does very well.
Each custom sub-zone drawing routine is accessed via an indirect jump table. Within a 40-pixel zone, character locations 0, 2, 5, and 7 are fairly easy (relatively speaking, that is) and only require one pass, because all 5 pixels fall within one 8x8 normal character cell. Character locations 1, 3, 4, and 6 are a different story, however. There is a left and a right component to these, and it was quite a challenge to figure all of it out with the right pixel masks (and offset from the beginning of the 40-pixel zone). Lucky for me I did this 25 years ago when the brain still had a little life! Just kidding. Something like this stays with you forever. Over the years I expanded the function to include four different types of blending masks, so that you could place the text behind other foreground objects, combine, exclude, or replace other objects, much as you can do with hardware sprites. If you have been thinking the 40 pixel zones seem a little like GCR encoding, you would be correct -- the process is vaguely similar.
I encourage anyone who has the inclination to learn about goofy stuff like this to look at the source. I did manage to scrape up the 8-bit versions for the C64 and have included them here. Unfortunately, I did not include all of the equates, zp locations, checks for non-print chars, etc. with these, and they are not really commented at all because they were written a long time ago directly from formulas and drawings on graph paper, and then ripped from the original 5 1/4" floppies and dot-matrix fan-fold paper in 2008, but they are still great examples to work from. It might be a little like putting a puzzle together, however. The version with the blending code (6425long.asm) does add an intense amount of complexity to the function. As it is now, even the 8-bit version puts up 64-column hires text faster than the kernal displays normal text characters.
If there is any part you may want clarified please do not hesitate to contact me. This 64-column text is my 25 yr. old child and I definitely don't mind talking about her...
Not 100% sure what you meant, but the 16-bit code needs a '816 cpu, and the 8-bit code should work fine on any c64. Right now it is not in its final form -- the code is being worked on constantly. I uploaded the d81 (above) with an exe you can see, but you will need a SuperCPU (or VICE) to run it. This is just a small progress update. All the actual game logic was written for a generic text screen, so it's not in this build at all.
Once this takes shape a little more the plan is to make an api (not just graphics) you can use in any program -- BASIC or ML, optimized using some modern ideas. The '816 version will always have more capability, but our idea is to make it so anyone can use it to make their programs more functional (and appealing to the eye), and enjoy life in a hires environment.
Some hex numbers (8/16/24/32-bit), PlotString, and text alignment (types = LEFT/CENTERX/RIGHT/TOP/CENTERY/BOTTOM) ...
Users browsing this forum: No registered users and 1 guest