Woo hoo ... I got a Geneve! Now What?

[GDMike]

9 minutes ago, BeeryMiller said:

If you are going to program on the Geneve, then use the GenASM package.  There is a complete manual, and the associated manuals for GenPROG, GenLINK, and GenMAKE are excellent resources.

 

DSR code that you might use under MDOS mode would not be compatible with running under GPL/TI-994A emulation mode.  It's probably easier to program under MDOS mode than under TI mode due to all the XOP's which are essentially embedded code into MDOS that gives you access to memory, video, math, dsr, and utilities.

 

Beery

Very good, yes. I was hoping I wouldn't be strapped to GPL <<shrug>>. As, I'd really like to get into the machine itself, if I can learn it, but so much potential is there, I'm hoping to become a piece of showing it off.

IF and WHEN I get my machine. I'm hoping to hear something from the seller soon. biting nails

 

 

[GDMike]

3 hours ago, OLD CS1 said:

That is on your end, buddy.  When I open it there are no ads, neither in my browser nor in Acrobat.

Yes. It's embedded in my end when I pulled up the doc. It's in the file.

I have acrobat pro and it's allowing me to delete it. But it's almost in every page of the doc.

Edited October 26, 2020 by GDMike

[+InsaneMultitasker]

This has probably been stated before - if you want to get a feel for programming the Geneve, MAME is a very good way to dip your toes into the environment.   Programs that run under MDOS can be simpler to write in many respects.  Some good example source code goes a long way. 

[GDMike]

I was planning to.. but I think I need to read through the only docs  I could find, let alone MDOS docs. I'm still looking though.

 

Edited October 26, 2020 by GDMike

[+OLD CS1]

I would be pretty pissed if I was running an application that modified my downloaded documents like that.

[GDMike]

2 minutes ago, OLD CS1 said:

I would be pretty pissed if I was running an application that modified my downloaded documents like that.

Done! Corrected like 78 pages of BS

[GDMike]

It only took me a half an hour to clean it up, deleting blank pages that were inserted and finally print!

If anyone wants it..

Edited October 26, 2020 by GDMike

[GDMike]

Here is the cleaned up copy

geneve.pdf

[+9640News]

In it's simplest form, here is the basics of Geneve programming.

 

When you create a program, it loads beginning at >0400.  You are guaranteed to have a page of memory mapped at >0000 to >1FFF, and >E000 to >FFFF.  There are only two ways to have memory mapped beyond >1FFF.  One, either your program is larger than the boundary at >1FFF and the next 8K page is allocated, or you use the memory XOP to map in more memory.

 

You can obtain as many memory additional pages (more than 64K) if you have free memory or additional memory cards (not SAMS).  Only Memex or modified Myarc 512K cards can give you more memory, or, if you have a modified Geneve card that had more memory installed.

 

After that, between your particular application code, and the various XOP's, everything is open.

 

In 4 lines of code, you can configure any video mode supported on the 9938.  If you want to print text, you specify the library opcode for the video XOP, give it a pointer to the text, give it the length, and then call the XOP and it displays in any video mode.

 

That is just scratching the surface, but everything is there for you.  The PDF's on the GenPROG on Whtech has everything documented.

 

Beery

 

 

 

[+InsaneMultitasker]

And if you are not familiar with XOPs:  if you can use something like BLWP @VMBW you already know the drill.  You set a few registers and call the routine. Pretty simple. 

[+arcadeshopper]

1 hour ago, GDMike said:

Here is the cleaned up copy

geneve.pdf 651.1 kB · 7 downloads

i uploaded this to the ftp.whtech.com/geneve folder  renamed to gmanualnoads.pdf

 

[GDMike]

I'm excited to finally be getting my geneve back! And it's actually operational again!! How cool 

[GDMike]

I was trying to get an idea about the pallet available and looking for a demonstration and I ran across this.

Well, I know the processor isn't a TI, but I can get a sense of some of the radiant colors. But getting to them I've still gotta learn.

 

 

 

[RXB]

This why I always said the 9958 was the best chip for the TI99/4A!

19,268 max colors per screen! 8 Sprites per line and hardware horizontal and vertical scrolling.

XHI the Extended Basic program for TIM Card (9958) had 12,499 colors per screen.

 

[GDMike]

But didn't I hear correctly that the MK2 is Even better? I read an old post and, of course, can't remember where, but his is supposed to be greater.

[+FarmerPotato]

6 hours ago, RXB said:

This why I always said the 9958 was the best chip for the TI99/4A!

19,268 max colors per screen! 8 Sprites per line and hardware horizontal and vertical scrolling.

XHI the Extended Basic program for TIM Card (9958) had 12,499 colors per screen.

 

The 19,268 colors or YJK mode is problematic. See here: http://rs.gr8bit.ru/Documentation/Issues-on-YJK-colour-model-implemented-in-Yamaha-V9958-VDP-chip.pdf

 

It seems that the chip designers (unintentionally?) got green and blue swapped in the YJK model. Further, YJK, as implemented, is a lossy compression technique where 4 pixels share the same chrominance value, and vary in luminance. That would be ok, if there were not that bug. 

 

As such, it takes a great deal of computing to convert an RGB image or a true YJK image, to the buggy YJK. The shortcuts work very badly on real-world photos.

 

Finally, I'm not sure that 19K colors is not all it's cracked up to be. The RGB DAC of the 9958 has 5 bits per component, for a maximum coverage of 32768 colors. It turns out that around 85% of those are addressable in the YJK notation.

 

Practically speaking, each run of 4 pixels uses a crazed palette of about 27 of those 32768 colors. You would not choose those palettes if you were a digital artist. Paint programs run into the same color smear issues that you have in 9918A bitmap mode.

 

Like, you can't have pure blue and pure green in the same chunk. You can have a muddy average. You can choose the monochrome palette if you like. These would be ok compromises for real-world photos, much like what you accept in a lossy JPG. Except for that stupid bug.

 

But how do they come up with 19,268 out of 32,768?

 

Chrominance has 6 and 6 bits for the J,K color space coordinates. Luminance is 5 bits signed or -16 to +15. Some colors in the YJK model can't be displayed on an RGB monitor and are clipped, so practically there are about 27 of the 32 levels of luminance. Since the RGB DAC of the 9958 has 5-bits per component, the RGB space would be 32x32x32 or 32768 colors. But YJK doesn't cover the whole RGB space and indeed projects some colors that are outside it. So it is more like 27*27*27 or 19683. Yet the datasheet says 19268. I guess it could be reverse-engineered.

 

The YJK mode has one more neat feature. The YAE sub-mode takes away 1 bit of "Y" and gives an Attribute bit per-pixel. Then it allows a sort of overlay of 4-bit-per-pixel graphics mode on top of YJK where A is set. So you could write text in areas of the screen using the normal 16-color palette. You could draw a crisp black-and-white icon (like a software sprite) over the YJK image.

 

YJK is weird and buggy, and the paper states that there were no professional tools  to work in it, aside from static images in games. So no Photoshop, no MacPaint--that's just not feasible in YJK mode.

 

The author does give credit to Yamaha for daring to implement a lossy color mode, anticipating JPG. Nobody else ever tried to implement lossy or JPG natively in hardware! So Yamaha tried something really out there, and unfortunately left in a horrible bug.

 

 

[RXB]

So you want to stick with 16 colors? 

I normally used XHI defaulted to 256 colors, that was 16x16 more colors then what we have now.

And 8 spites per line limitation allowing for 4 sprites used to define a single character instead of currently 1 and each sprite 2 colors!

MSX 3 was a much better over all effect for games considering we are still using MSX 1 now.

 

(Not to mention the 128K or RAM or up to 192K RAM.)

[+FarmerPotato]

16 hours ago, RXB said:

So you want to stick with 16 colors? 

I normally used XHI defaulted to 256 colors, that was 16x16 more colors then what we have now.

And 8 spites per line limitation allowing for 4 sprites used to define a single character instead of currently 1 and each sprite 2 colors!

MSX 3 was a much better over all effect for games considering we are still using MSX 1 now.

 

(Not to mention the 128K or RAM or up to 192K RAM.)

Not sure how you read that... YJK mode is what it is, bugs and all, AND you can overlay 16 color graphics on it. Much like the first VGA chips did.

 

(Early VGA palette chips like the BT476 had to support 16-color EGA palettes as well as 256-color VGA palettes. A clever frame buffer could toggle between them on a per-pixel basis. I think TI's 34C076 has a similar model. The 16-color overlay can be used to implement 16-color sprites over 256-color image, like a mouse pointer.)

 

I'm all in on V9958 for my development. Still, with experience programming for the F18A last year, I  love the bit plane approach of @matthew180 better than the V9938. F18A gives a scrollable 48x64 screen of tiles in plenty of colors. Can't quite match that look on the V9958, using its horizontal scroll registers.

 

Here's a MSX thread that had some good YJK info, but all the links are broken

 

https://www.msx.org/forum/msx-talk/software/enhanced-decoding-yjk-images

 

I copied these:

Using rather direct translation, this is a nice YJK mode image. You can easily pick out the every-4-pixels blocks.

 

 

Here is the same image with some processing tricks (the author says it is not dithering. Maybe nearest-neighbor color matching?)

The 4-pixel chunks are less discernible.

 

From https://www.msx.org/forum/msx-talk/software/enhanced-decoding-yjk-images?page=3

 

Here's the process of the converter by user 'hit9918'

 

The rainbow is what really jumps out at me from this version.

 

There is a bag of tricks for YJK mode, illustrated by 4 pictures on this page:

https://www.msx.org/forum/msx-talk/software/enhanced-decoding-yjk-images?page=4

 

For future reference, here is a Java cmd line tool that created that image?

 

https://fbbf8670-a-62cb3a1a-s-sites.googlegroups.com/site/tueftlerlabs/home/downloads/screen12converter.zip?attachauth=ANoY7coXYpWU7nquTzqaLNCwJQljXt0mRg_Qyy5hvxMHnV_yZNf7bWnHI_vHee_oSdELWgCAtuGpEIVLy4QNQ2CplgfpRGsM72gw9mHxFOtSTmIDYcpunAiouatya7pitIhJNPmQbHIkXdbO9wW_AR76V4XK6L2nCSmEJG_egucE4u9HhwORPjSkB1gRnwXnQ0Yq2cfnzbG2FkQFjCrXorE2HuRIn8b904ciTxUrKEpEHMJnYhXTkEl-SIZjt9eskBZHCV_fT96f&attredirects=0

 

And it case it goes away, here's the file:screen12converter.zip I think it's by hit9918 on msx.org

 

Here are some images that seem to trip up over the limitations of YJK:

from https://mamedev.emulab.it/kale/2013/11/20/mode-twelve/

Or maybe they were just badly processed?

Example:

 

My guess is that the dark blue pixel jaggies were meant to be very light! But the conversion algorithm overlooks the bug, and so the luminance is opposite for some light pixels that show up dark instead. I gather there are some tricks to work around this. 

 

I would guess that the titles, PUZZLE Star, are using the 16-color palette in YJK+YAE mode.