F18A

[+OLD CS1]

My understanding was that Matthew is already doing this (or already has!), so having the discussion again is silly anyway. But to re-vote, I'd like the jumper or switch, too.

 

From what I have read, I believe this limitation is removed as well. As far as enhanced features go, how difficult would it be to implement a new register which would allow features to be activated by software? By default, the F18A would run as a standard 9918A, but software could then set a flag to enable enhanced features when needed.

 

I like software switches better than jumpers. Ick, so 1980s.

[bmcnett]

Software that relies on the four sprite limit would have worked just as well if if had uploaded partially vertically occluded sprite shapes to VRAM instead. Why bend over backwards to support such software rather than the 99.9% of software that would flicker less. I just don't get it.

[+retroclouds]

Might as well leave out multicolor mode too, then. It didn't even work in MESS and nobody noticed until last week (and LOTS of machines use that VDP core). Those apps who want to use it are out of luck.

 

The 4-sprite on a line limitation is useful for certain effects. Like others, I don't like removing it fully because I have taken advantage of it. It's not just "flicker in games" - I don't think anyone is arguing that they want that. What about new programmers who only use this chip - they can't test what it will look like on a normal console? Nothing will ever break because you can see all the sprites, it might just look wrong. But if you go the other way, your code may not work for others.

 

In fact this already happened at least once, because Classic99 didn't support the 4-sprite-on-a-line limit. I think it was Owen who released his first program only to be confused that nobody could see his title graphics. That was when I implemented it.

 

My understanding was that Matthew is already doing this (or already has!), so having the discussion again is silly anyway. But to re-vote, I'd like the jumper or switch, too.

 

True, I don't know of many games using multicolor mode. There is one game for the TI-99/4A that uses multicolor mode. It was some kind of Scramble clone if I recall correctly. Dunno about the other platforms. I do think some of the MSX demos made use of the multicolor mode.

 

As far as the 4-sprite on a line limitation is concerned. I really would like to have that option in place. It does come in very handy for smoothly removing sprites from part of the screen. You can for example see that in the Time Pilot demo I worked on.

 

http://www.youtube.com/watch?v=LVNgiQRHZV4

[+OLD CS1]

True, I don't know of many games using multicolor mode. There is one game for the TI-99/4A that uses multicolor mode. It was some kind of Scramble clone if I recall correctly. Dunno about the other platforms. I do think some of the MSX demos made use of the multicolor mode.

 

As far as the 4-sprite on a line limitation is concerned. I really would like to have that option in place. It does come in very handy for smoothly removing sprites from part of the screen. You can for example see that in the Time Pilot demo I worked on.

 

I was pretty fascinated with multicolor mode for a while. I wrote several intro screens and what-not using it after I got my Mini Memory. I cannot imagine it has much practical use in games since you lose so much resolution.

 

But, really? "Time Pilot?" What other bad-ass arcade games are you going to convert, dude? (And when can we buy it?) I always wanted a TI version of "Xevious," but I am not sure I can stand to see someone else get to it before me. Though, if you wait for me, most of our TIs might be dust -- I tend to get distracted or otherwise project-overloaded. Plus there is the little thing about getting a LOT better at TI assembly.

[Tursi]

Multicolor mode is nice mostly for how little data it takes -- it's similar to the Apple2 "lores" mode... I'm pretty sure if we had access to multicolor from BASIC we'd have seen a lot more use of it.

 

I always wanted to use it for a raycasting engine - maybe someday.

 

As for other uses - that 512+ color mode that Matthew (I think) mentioned the MSX guys using in a demo was done using multicolor mode and bitmap mode. There's enough VRAM to load them both at once, so once loaded, it just flickered between them to fake the additional colors through persistence of vision. A very clever trick that works pretty well! I want to put it into Convert9918 but since that uses a brute force search, the search time would be very large. (Maybe I should just start simple...?)

 

Software that relies on the four sprite limit would have worked just as well if if had uploaded partially vertically occluded sprite shapes to VRAM instead. Why bend over backwards to support such software rather than the 99.9% of software that would flicker less. I just don't get it.

 

That's clear, but it's okay. You don't have to agree. Some of us think it's useful.

 

I dunno that uploading partial sprite bitmaps is JUST AS well. First, you need to upload the patterns. If you want single pixel occlusion you need up to 31 additional frames loaded (magnify 4 sprite), that's up to 1k per sprite pattern (and you only have 16k to start with), though a more realistic case would be 16x16 sprites at up to 512 bytes each. Second, you can't use automotion at all, because you need to change the pattern based on the scanline. Thirdly, you need to devote CPU cycles on a machine that's usually CPU bound to checking for and changing the patterns on the fly. This is all impossible to do realtime in Extended BASIC due to the low speed of the language. Or you can just drop four unused sprites there and let the hardware do it for free.

 

I had to deal with the issues of pre-rendering partial sprites to fake occlusion for Mario Bros, since there was no way to do it horizontally. Anyway, nobody is taking away your flicker-free system. Matthew doesn't like flicker either, and IF he puts it in you will be able to turn it off. So why raise such a fuss?

[marc.hull]

Software that relies on the four sprite limit would have worked just as well if if had uploaded partially vertically occluded sprite shapes to VRAM instead. Why bend over backwards to support such software rather than the 99.9% of software that would flicker less. I just don't get it.

 

I really wish I didn't attract arguments so much. The fact is that the game was written before anyone was contemplating a new and improved VDP. I simply took advantage of the hardware to make the screen nicer and the programming easier. As far as an improved VDP goes... I don't care one way or the other. I am sure Matt has it all under control and will do what he deems best. Perhaps before your next post denigrating the old hardware you should remind yourself of an old adage.... It's a poor carpenter who blames the tools.

[Tursi]

I really wish I didn't attract arguments so much. The fact is that the game was written before anyone was contemplating a new and improved VDP.

 

Not your fault by any means, I used it 20 years before you did. Probably my software just wasn't as notable.

[bmcnett]

Perhaps before your next post denigrating the old hardware you should remind yourself of an old adage.... It's a poor carpenter who blames the tools.

 

Whoa there cowboy, who's denigrating old hardware? The original VDP is one of my all-time favorites, and I you won't catch me saying an unkind word about it, unlike some people who can't get over the lack of hardware scrolling...

 

The VDP mode where 8x1 pixel chunks can pick two of sixteen colors is remarkably modern if you consider how "texture compression" works on a GPU. I see a lot of hate for these modes with "attribute clash" but they are really an excellent compromise, which is why all the new graphics modes in my fictional VDP upgrade have "attribute clash!"

 

If imitation is the most sincere form of flattery, then count me as a VDP fanboy.

Edited February 20, 2011 by bmcnett

[matthew180]

Wow, I lose Internet access for 12 hours and miss an entire conversation.

 

Jumpers... Hmm. There probably won't be any of those on the F18A board, mostly because I don't like choosing options via jumpers (unless it is something that you would never change, like a voltage setting or EPROM size.) Also, there are too many "options" in this case to give a jumper to each one.

 

As for what is and is not implemented: Everything *is* currently implemented *except* for the external video functionality of the original 9918A, and I won't be doing that in the F18A. I also have all 32 spites working and demoed that at the 2010 Faire.

 

Multicolor mode works fine on the F18A. Like Tursi said, if BASIC supported multi-color you would probably see more use of it. The MSX gives you access to all the video modes from BASIC and I used my MSX to troubleshoot and implement all the VDP modes. I had never even set multi-color mode on a 99/4A, but on the MSX all I had to type was: SCREEN 2. I think it is not used much because you can't get any text on the screen, or any shapes other than fat (4x4) pixels. However, on the MSX I did find an interesting use because the MSX scales its drawing commands to 256x192 no matter the mode. So, if you draw a line in GM2 from 0,0 to 128,96, then change to multi-color and draw the same line, it will still be from the top-left to the center, so basically a low-res version of GM2. It was the first time I actually found some use for multi-color.

 

Color. The CPU-to-VDP speed limit has been removed, however it is still an 8-bit interface, and trying to move tons of extra bytes for color is not practical. The way you would take advantage of more color would be to pre-load the data in the VRAM, like we do with tile patterns, and use a "reference" to display the object (like we do with the tiles and sprites.) I am considering 24-bit color, but only to be able to accurately reproduce the original colors. Currently I have 9-bit color and I can only get close. I don't think, however, that I would ever make a version that would allow 24-bits per pixel, tile, or sprite. However, the palette registers (or memory) may be 24-bit.

 

Options and enhancements. I will probably implement the new features as software selectable. Having an expanded register set makes a lot of sense and lets new software enable the F18A's enhancements if it is detected. The 9938 expanded the registers the same way. However, as soon as you do such an expansion, true hardware compatibility goes out the window and you fall back to software compatible. This is also what the 9938 and 9958 do, and the datasheet specifically states they are software compatible only. An example would be something like a program writing to a register above 8. On the 9918A, this would have no affect, however on a 9938 this would cause problems because the 9938 has expanded registers. I'm going to be in the same situation.

 

For those who want to have enhanced features turned "on" by default, I'm not sure how I might to that yet. Like I said, I don't like the idea of jumpers and there would have to physically be too many. I am planning to make a new cartridge that supports GROMs, which means we will be able to change the system GROMs, and the VDP initialization could be changed. That does not help ColecoVision or MSX users though. Another option I have, but one I have not messed with yet, is storing user configuration options on the F18A board itself. The serial flash chip that is used to program the FPGA at power-on can be used as a general purpose flash after FPGA "configuration" (loading the FPGA bitstream is called configuration.) Doing this would allow a program to be written, for each platform, that would store the user default options. Each person could then set things like sprite limit, default color palette, etc. as they prefer.

 

As for the enhanced graphics modes, they *will* be there, eventually, and they will be set-up and configured via expanded registers. Thus, the F18A, as mentioned above, will always only be "software" compatible (like the 9938). Any *bad* programs that explicitly write to registers above what the 9918A supported will most likely cause problems. Maybe I could come up with an unlock sequence though, something that even a bad program would never had done accidentally. There are a lot of options.

[marc.hull]

Perhaps before your next post denigrating the old hardware you should remind yourself of an old adage.... It's a poor carpenter who blames the tools.

 

Whoa there cowboy, who's denigrating old hardware? The original VDP is one of my all-time favorites, and I you won't catch me saying an unkind word about it, unlike some people who can't get over the lack of hardware scrolling...

 

The VDP mode where 8x1 pixel chunks can pick two of sixteen colors is remarkably modern if you consider how "texture compression" works on a GPU. I see a lot of hate for these modes with "attribute clash" but they are really an excellent compromise, which is why all the new graphics modes in my fictional VDP upgrade have "attribute clash!"

 

If imitation is the most sincere form of flattery, then count me as a VDP fanboy.

 

 

Re-reading this in the light of day, my response was too harsh.

Edited February 21, 2011 by marc.hull

[bmcnett]

I am considering 24-bit color, but only to be able to accurately reproduce the original colors. Currently I have 9-bit color and I can only get close. I don't think, however, that I would ever make a version that would allow 24-bits per pixel, tile, or sprite. However, the palette registers (or memory) may be 24-bit.

 

Since there aren't any backwards compatibility issues to consider, other than the one you just mentioned, this is where I've been doing the most radical work in my (fake) VDP. I don't understand why you would consider 9-bit colors, but I guess it has something to do with the FPGA, and I'd love to hear the story behind that one.

 

Currently my colors are HSV (hue, saturation, value) and not RGB. Historically, HSV was used instead of RGB on older systems like 2600 because it more closely matches how an analog TV signal works. I don't care about analog TV, but I like HSV for other reasons:

 

1. Sprite transparency is typically done via a dedicated bit pattern (like a 0 bit in a VDP sprite.) This however consumes a proportion of colors equal to 1/(2**N) where N is the number of bits per pixel. That seems to be a reasonable tradeoff when you have four bits per pixel, because then you lose only 1/16 of your colors and you probably weren't using that color anyway. But for two bit imagery, you lose one of four colors, which is pretty horrible IMO! Therefore I would like to use "color key" for transparency in sprites. I want each sprite definition to have, in addition to X, Y, etc. a "transparent color" which is to say, a HUE which will be transparent. So a color space where HUE is a primary is convenient for that purpose.

 

2. The app developer sometimes desires to "recolor" imagery cheaply, which is to say for example have one sprite definition for a soccer player with a red shirt, and somehow cheaply get him to show up with a blue shirt instead. Historically this has been done with palettes, but these are usually a limited resource (e.g. Genesis had only four in the whole system) and moreover if you just want to change one color, you end up storing copies of all the other colors in each palette, which is wasteful. So I would like ANOTHER two values in the sprite definition that gives two HUES: the hue of the color you want to change, and the hue of the color you'd like to change it to. So again, a color space with HUE as a primary is convenient.

 

3. Sometimes the app developer wants to do something programmatically to a color on the CPU, and in my experience this is typically a change in value (brightness), hue, or saturation. If they get these as color primaries, no need for them to deal with conversions to and from a linear space like RGB, which a really old CPU is bad at anyway, because it might not even have a MUL instruction

 

So right now, I'm considering either a 16-bit HSV color space, or a 32-bit HSV color space. Leaning towards the 32-bit because 16 isn't enough to reproduce the VDP's original hardware palette. So that would be:

 

16 bits: luminance, with the same nonlinearity as sRGB.

8 bits: hue. the "angle" of the color as rotated around the luminance vector.

8 bits: saturation. the "distance" of the color from the luminance vector.

 

A 16 bit nonlinear luminance has a few things going for it:

 

1. You can set just the top byte and it's still sRGB so you don't lose all your dark values even though you're poking only eight bits of precision

2. If you poke all 16 bits, You won't get "banding" on any display device I've ever encountered (unlike 24 bit color!)

[Tursi]

Funny we talk about multicolor mode - I forgot that someone uploaded a nice little multicolor Tetris game to my forums for me to look at - I just did and it's rather well done. http://www.harmlesslion.com/hl4m/viewtopic.php?f=3&t=519&p=1820 (scroll to my reply where I post the fixed files). So we have two multicolor games for the TI now, hehe.

 

bmcnett... your color scheme reminds me a lot of the Atari Jaguar's CRY mode. CRY was a 16-bit mode that used the top 8 bits for luminence, and the bottom 8 bits selected a color from a table. The table selection did limit the colors available, though, IMO too much (but many people liked it.) A full HSV system as you list is probably better, the Jag just didn't have the bandwidth to pull it off.

[Opry99er]

I just ran that Tetris program on Classic99. That's really cool! That fella should join us over here and get involved. =)

[matthew180]

Since there aren't any backwards compatibility issues to consider, other than the one you just mentioned, this is where I've been doing the most radical work in my (fake) VDP. I don't understand why you would consider 9-bit colors, but I guess it has something to do with the FPGA, and I'd love to hear the story behind that one.

 

Well, it has to do with physical reality for the most part. The current 9-bit color palette is because:

 

1. I don't like 8-bit color because you have to drop a bit for one of the colors, usually blue. So you would have rrrgggbb. I don't like unevenness, even though a byte is nice and even, it does not work with 3 colors.

 

2. 6-bit color (rrggbb) was not enough color space to give me a palette with enough colors to get close to the original colors.

 

3. I'm using a discrete resistor DAC, and you can only go so far before it gets real mess with discrete components.

 

24-bit color is great and all, and the FPGA can do it, no problem. But it would require another chip on the board, and that increases cost, size, power requirements, complexity, and time to getting version 1 out the door. As it is, I increased the color space to 4-bits per pixel, and the board is getting really congested and it is going to be a pain in the ass to route (not to mention soldering all those !@#$% resistors on my prototype... I'm *not* looking forward to that!)

 

This is kind of what I was talking about before when people would post how they were going to make a new video chip and have all these features, etc. It is *easy* to say "24-bit color", but a totally different situation to implement 24-bit color on a circuit board. If you Google for RAMDAC, you will notice most modern video cards have a triple-DAC running at like 330MHz or so... There is a reason for that, and I don't think I can even design a circuit board that will be stable at 330MHz.

 

As for an alternate color space, it probably won't happen unless someone else does it. Monitors are RGB, so if I did color internally in any other color space, I would have to convert to RGB for display, which is added circuitry, cost, complexity, etc. Also, I'm "color space" stupid, and I don't know anything about most color systems, so I could not tell you advantages or one over the other.

[matthew180]

Here you go, just uncross all the wires... Let the routing begin! Ugh.

[bmcnett]

re: matthew's color space

 

Yeah I'm using RGB internally like you. I do the HSV to RGB conversion only when a palette register is set, and keep an HSV copy lying around in the imaginary chip, for color key, recoloring and CPU palette readbacks.

 

Sounds like doing this in a real FPGA is pretty hard! I admire your work ethic.

 

I've been hearing about this "propeller" processor that can be programmed to output an analog RGB or NTSC signal from binary data comparable in density to an 8/16 bit home computer from the past. Someone got a "spectrum" emulator working, I hear. Wonder if it could do a 9918.

Edited February 22, 2011 by bmcnett

[matthew180]

I have a few propeller microcontrollers. I was going to go that route before I decided on the FPGA. I'm sure a propeller could emulate a 9918A. It runs at 80MHz and has 8 parallel RISC processors they call "cogs". Hopefully I'll have time to mess with them before I die...

[Tursi]

Here you go, just uncross all the wires... Let the routing begin! Ugh.

 

Looks beautiful, Matthew! Looks very feasible to route, too!

[marc.hull]

Here you go, just uncross all the wires... Let the routing begin! Ugh.

 

All right progress !! Looks good Matt. I am guessing that the DIL holes on the right side are for attaching to the MoBo socket ? If so it appears that half the pins original pins are not needed? Also what is the row of pins on the top for ?

[matthew180]

Here you go, just uncross all the wires... Let the routing begin! Ugh.

 

Looks beautiful, Matthew! Looks very feasible to route, too!

 

Thanks. I did get about half of it routed last night, and I hope to finish routing it today. Then I get to begin the arduous task of finding a place to have the prototype boards made, and consider if I'm going to try and solder the prototypes by hand.

[matthew180]

Here you go, just uncross all the wires... Let the routing begin! Ugh.

 

All right progress !! Looks good Matt. I am guessing that the DIL holes on the right side are for attaching to the MoBo socket ? If so it appears that half the pins original pins are not needed? Also what is the row of pins on the top for ?

 

Of the 40-pins on the 9918A, I actually only need 16:

 

1. VCC (passive)

2. GND (passive)

3. GROMCLK (out)

4. #INT (out)

5. #RESET (in)

6. MODE (in)

7. #CSW (in)

8. #CSR (in)

9. CD[0..7] (I/O) (bidirectional 8-bit data bus to the host CPU)

 

The rest of the pins on the 9918A are for controlling the DRAM, CPUCLK (unused), video output, and video sync input, and an external crystal. I don't need any of that and the pins just take up space and make it hard to place parts because they are through-hole. So, I left them out.

 

My only concern at that point was having enough pins to support the F18A board in the socket, so I added 4 pins (1,2 and 39,40) at the top for added stability. They are not used though. The row of 6-pins on the top left are a Serial Peripheral Interface (SPI) header so I can program the serial flash chip that is used to configure the FPGA at power on. I figured most people would want a programmed board.

 

The JTAG header at the bottom is similar, and simply there in case something goes wrong with the SPI interface. Basically, at this point, I don't trust myself to get it right the first time.

[bmcnett]

I have a few propeller microcontrollers. I was going to go that route before I decided on the FPGA. I'm sure a propeller could emulate a 9918A. It runs at 80MHz and has 8 parallel RISC processors they call "cogs". Hopefully I'll have time to mess with them before I die...

 

To a PS3 programmer like me, this sounds suspiciously like an SPU but at 1/40 the speed and probably without floating-point. If I had one of these things, I could knock out emulators for old chips left and right, but I'm totally clueless about how to deal with the electrical connections to the host computer. Any pointers about what a person like me should read or experiment with, in order to reduce the cluelessness?

[matthew180]

Start here:

 

http://www.parallax.com/propeller/

 

Parallax has a lot of documentation, programming manuals, tutorials, examples, etc. for the software side. For the hardware side they have kits of all kinds for all levels of knowledge. You can get a complete starter board, or build your own. If you are planning on connecting to a real computer, then at some point you will have to learn some of the electronics. Of course there is nothing stopping you from making an entire 99/4A SoC, which would be nice to have, and you don't have to worry about real interfaces with an existing 99/4A like I did with the FPGA in the 9918A's socket. You might want to look at the Demo Board:

 

"The Propeller Demo Board demonstrates the Propeller's varied capabilities in a compact and fun platform. It has the necessary hardware to interface with VGA, TV, mouse, keyboard, and headphones."

 

There you have everything on one board to do a complete SoC, all you have to do is the software implementation.

[Tursi]

Here you go, just uncross all the wires... Let the routing begin! Ugh.

 

Looks beautiful, Matthew! Looks very feasible to route, too!

 

Thanks. I did get about half of it routed last night, and I hope to finish routing it today. Then I get to begin the arduous task of finding a place to have the prototype boards made, and consider if I'm going to try and solder the prototypes by hand.

 

I'm not considering myself an expert by any means, but KSkunk and I had good enough luck with a place up in Seattle called Sunstone Circuits (http://www.sunstone.com/) - they partner with Screaming Circuits for assembly. They did the prototypes, second run, and are currently doing the third run of our Jaguar Skunkboards.

 

It would be difficult to help you get the pieces together as I still don't fully understand the process (this run is the first time I've done it myself), but I can help you piece it together if any parts are confusing.

[matthew180]

Oh cool, you are using SunStone then? I looked at them when I was sourcing a company for the Bank Switch Mini boards, but ultimately I went with SparkFun's BatchPCB service. It took a little longer (3 weeks), but I got 4 boards for $20, and that is hard to beat!

 

So are you happy with SunStone? I think they were a little pricey for me. I suppose most board houses are pretty much the same in price if you are going to do a large run, but for doing 4 boards, or prototypes, quick turn-around and assembly == $$$$. The Screaming Circuits people probably do a good job, but their prices will leave you screaming (at least for a hobbyist.) But any info you about about them (SunStone or Screaming Circuits) would be greatly appreciated.